Feedback for v4

[amannn]

Let me know about your experiences with next-intl@4!

[jspm2013]

hi Jan, thanks for the beta and your work on all those updates lately to the react/next ecosystem - but i am seriously not at all able to make it run with next15. But as far as I understood it should work there... Can you please share an app router example with next15?

[jspm2013]

hi Jan, they have relaesed 15.2 two days ago, but it doesnt mention vercel/next.js#73431 to be included... :(
Do you have any communication with them about it...?

[amannn]

It was in fact included, just not prominently advertised: #1442 (comment)

[jspm2013]

ahhh thats cool - would you mind giving a short reply here when you updated your docs? 🙏

[amannn]

As mentioned in the other thread, the docs and examples have been updated to Next.js 15 now!

[jspm2013]

oh thank, you Jan!!! 💪

[frenchki]

I believe there is a bug with the typings in <NextIntlClientProvider> that makes messages still expect the old messages typings before doing the new TypeScript augmentation in v4

As a workaround, I have just done messages as unknown as AbstractIntlMessages | undefined

[amannn]

It's true that NextIntlClientProvider currently expects AbstractIntlMessages, yes. However, I'm wondering why you have to cast your messages to pass them to the prop? Do your messages not comply with AbstractIntlMessages?

Note that your typed AppConfig['Messages'] can not be used directly for the messages prop of NextIntlClientProvider. While in your case this might be true since you're passing all messages, if the developer is more selective and only passes some messages, TS would complain about missing keys.

What we could do though is expecting a deep partial of AppConfig['Messages']. I made a note about this in #1412.

Would be curious to learn more about your use case though!

[frenchki]

I found the issue that I was having. 😄 The typings will work as expected when the translation JSON does not have an array of items.

This will work:

{
  "common": {
    "test": "We are testing"
  }
}

This will not:

{
  "common": {
    "test": "We are testing",
    "listOfItems": [
      "item 1",
      "item 2"
    ]
  }
}

I was doing this as an example on the page to get an array of items rendered.

export default async function Home({ params: { locale } }: HomeProps) {
  setRequestLocale(locale)

  const t = await getTranslations()
  const messages = await getMessages({ locale })

  return (
    <ul>
      {messages.listOfItems.map((value, index) => (
        <li key={index}>{value}</li>
      ))}
    </ul>
  )
}

[amannn]

Ah yep, I see! I'd suggest to follow the array pattern as outlined in the docs, this is guaranteed to work. Future optimizations for next-intl might also not work with arrays in your messages definitions, therefore I'd encourage you to update this.

[JOsacky]

build: ./middleware.ts:2:8
build: Type error: Module '"/Users/jonathanosacky/WebstormProjects/meter-backend/node_modules/.pnpm/[email protected][email protected]_@[email protected]_@[email protected]_@playwright+tes_8522c377d6769f2abe5601dcb81264e0/node_modules/next-intl/middleware"' has no default export.
build: 
build: > 2 | import createMiddleware from 'next-intl/middleware';

After migrating to 4.0.0, I'm getting a new import error for createMiddleware. I didn't see any mention of migrating the middleware in the 4.0.0 guide so I was wondering if this was an issue in 4.0.0 or an implementation issue on my end. Congrats on the major release!

[amannn]

Hmm, interesting. Nope, the middleware export wasn't intentionally changed.

Any chance you could provide a repro with https://github.com/amannn/next-intl-bug-repro-app-router? I'm wondering if there's an edge case for a certain bundler configuration.

[JOsacky]

Yes looks like an edge case with certain budler config. I believe if the tsconfig moduleResolution is set to node then this happens. Try switching "moduleResolution": "node" in tsconfig

"module": "esnext",
"moduleResolution": "node",

[MiXeR54]

I have the same issue.

Module '"../node_modules/next-intl/middleware"' has no default export.ts(1192)

tsconfig:
"moduleResolution": "node",
"module": "esnext",

[JOsacky]

[{
	"resource": "/Users/jonathanosacky/WebstormProjects/meter-backend/node_modules/.pnpm/[email protected][email protected]_@[email protected]_@[email protected]_@playwright+tes_8522c377d6769f2abe5601dcb81264e0/node_modules/next-intl/middleware.d.ts",
	"owner": "typescript",
	"code": "1203",
	"severity": 8,
	"message": "Export assignment cannot be used when targeting ECMAScript modules. Consider using 'export default' or another module format instead.",
	"source": "ts",
	"startLineNumber": 4,
	"startColumn": 1,
	"endLineNumber": 4,
	"endColumn": 27,
	"modelVersionId": 1
}]

here is the full error in next-intl/middleware.d.ts

[amannn]

Thanks for the details, I was able to reproduce it with moduleResolution: 'node'! There was indeed an oversight here as part of the ESM switch.

Should be fixed as of [email protected]! 🚀

[daveycodez]

It would be awesome to have a <Trans> component similar to i18n that automatically creates JSON entries for the default language when rendered.

For example if my defaultLocale is "en" and I have:

<Trans>
    Welcome!
</Trans>

Whenever this component gets rendered in dev environment or during build, it automatically creates an entry in messages/en.json with a random key hash:

(md5 hash example)

{
    "9a843f20677a52ca79af903123147af0": "Welcome!"
}

This would enable me to easily write automatic translations using scripts, and streamlines the dev process since you can write the main copy directly in the components instead of needing to manually track keys. And manually editing JSON files is pretty un-fun

could also accept an optional tKey prop and use that as the key in the json instead of hash. But default to hash if tKey is not present.

[daveycodez]

It would also be great to have a trans() function that accepts a string or object

e.g.

<p>
    {trans("Welcome!")}
</p>

<p>
    {trans({ message: "Welcome!", tKey: "welcome" })}
</p>

[daveycodez]

Might be more clear to rename it to <Translate> and translate() though

[daveycodez]

I've been planning to make this as my own separate package that works alongside next-intl but would much prefer to have it baked in

[amannn]

There's a bit of existing discussion on this here: #456

[dsm-ostec]

After upgrading to 4.0.0 I'm getting a import error from createNavigation. I'm not sure if this is an implementation issue on my end or if there has something changed due to the esm-only build.

[amannn]

Any chance you could provide a reproduction based on https://github.com/amannn/next-intl-bug-repro-app-router?