New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Support providing a locale in i18n.ts
instead of reading it from the pathname
#1017
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Would be awesome ! Thx for your work |
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 Looking through all the options we support in
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 I need to investigate if there's a way where we can call Note that as long as we advertise this feature as something to be used without routing APIs from 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 |
# Conflicts: # packages/next-intl/package.json # pnpm-lock.yaml
# Conflicts: # docs/pages/docs/getting-started/app-router.mdx
# Conflicts: # docs/pages/docs/environments.mdx
Resolves #960
Use cases
locale
should be read from user settings instead of the[locale]
segmentPrerelease
Changes
The gist is instead of reading the locale from the argument that's passed to
getRequestConfig
ini18n.ts
you can now return alocale
from the function:This simplified setup comes with some benefits:
[locale]
segment needs to be addedExample implementation
Docs changes
→ Proposed docs