The latest updates on your projects. Learn more about Vercel for Git ↗︎

Would be awesome ! Thx for your work

4. Static rendering works without tradeoffs

How is Static rendering supposed to work for more than one locale (most cases)?

If the value is derived from a runtime variable, such as userSession, then Dynamic Rendering will be opted for. If the value comes from predefined routes, such as ["en", "de"], then only one locale will be generated, which contradicts the concept of internationalization.

@AhmedBaset Yep, that's of course correct—thanks for the feedback! The statement only applies to using a single language, I've changed it accordingly above.

My main concern with this currently is that the locale is returned asynchronously.

Looking through all the options we support in i18n.ts, I think they can be grouped like this:

1. Definitely not async: formats, defaultTranslationValues, onError
2. Likely not async: now
3. Might be async: locale (if read from user profile), timeZone
4. Likely async: messages

So generally, it seems reasonable that we support an async config object.

However, this currently has the implication that the locale can't be read synchronously during an RSC render. This is mostly not an issue, but the navigation APIs are affected by this. For Link it's no problem since we can make the component async, but for redirect this makes a difference.

I need to investigate if there's a way where we can call redirect before we know which locale we're redirecting to …

Note that as long as we advertise this feature as something to be used without routing APIs from next-intl, this would be fine. I do however have the hope that this could pave the path to a very customizable solution to #653, in case the user could read parts of the pathname deeply in an RSC render (see vercel/next.js#58862). Let's see.

EDIT: Declaring this a non-issue for now as routing APIs don't need to be used when you're not using i18n routing. Note to self though, in case we move to a place in the future where the locale is generally returned from i18n (i.e. Next.js allows to read params deeply), we could make the locale a mandatory argument for redirect. Not super elegant, but given all other aspects that this enables (e.g. market prefixes), possibly something worth considering.