Feedback for v4 beta

[amannn]

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

[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?

[amannn]

You can already upgrade to Next.js 15 without the next-intl@4 beta. You can check out an updated example here: #1089

[JunkyDeLuxe]

Hello amann, thanks for the great works.
I really want to upgrade my nextjs15, sorry, but i dont find a repo source with all the needed changements in order to use your library with nextjs 15.
Can you provide a link please ?

[amannn]

Here is the link: #1089. You can check how the examples were updated.

I'm currently waiting for vercel/next.js#73431 to be merged and released before I broadly recommend Next.js 15.

[jspm2013]

Hi Jan, do you like us to also comment on the change request vercel/next.js#73431 thread...to make it more visible, or would it be contra dictionary?

[amannn]

Thanks for proposing to help @jspm2013! I just pinged a Next.js maintainer again via DM, maybe it's better to reduce notifications on the PR for those who have subscribed. But you can upvote the PR if you like!

[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.