feat: Support providing a locale in i18n.ts instead of reading it from the pathname
#1017
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
| {children && <div className="mt-3">{children}</div>} | ||
| </NextLink> | ||
| ); | ||
| } |
There was a problem hiding this comment.
Copied and forked from Nextra for customization (being able to add a description)
| example](https://next-intl-example-app-router.vercel.app) to explore a working | ||
| app with error handling. | ||
| </Callout> | ||
| **Tip:** You can have a look at [the App Router example](https://next-intl-example-app-router.vercel.app) to explore a working app with error handling. |
There was a problem hiding this comment.
"Downgraded" this to a tip to not have too many callouts in this area.
| @@ -163,9 +164,9 @@ export default function Error({error, reset}) { | |||
| } | |||
| ``` | |||
|
|
|||
| Note that `error.tsx` is loaded right after your app has initialized. If your app is performance-senstive and you want to avoid loading translation functionality from `next-intl` as part of the initial bundle, you can export a lazy reference from your `error` file: | |||
| Note that `error.tsx` is loaded right after your app has initialized. If your app is performance-senstive and you want to avoid loading translation functionality from `next-intl` as part of this bundle, you can export a lazy reference from your `error` file: | |||
There was a problem hiding this comment.
It's actually not the "initial bundle", but a lazy loaded one after init.
| Useful if you'd like to provide a locale to `next-intl`, e.g. based on user | ||
| settings, or if your app only supports a single language | ||
| </Card> | ||
| </Cards> |
There was a problem hiding this comment.
Another level of navigation until the user reaches the getting started guide, but I believe if developers have a use case that qualifies for "without i18n routing", it's a good idea to get them into the right "lane" quickly.
This provides an easier getting started experience (no middleware) and also easier usage down the road (no need for navigation APIs, static/dynamic rendering is decided by user).
| In order to use unique pathnames for every language that your app supports, `next-intl` can be used to handle the following routing setups: | ||
|
|
||
| 1. Prefix-based routing (e.g. `/en/about`) | ||
| 2. Domain-based routing (e.g. `en.example.com/about`) |
There was a problem hiding this comment.
The first draft used full sentences to describe these two cases, but I later converted them to bullets.
Bullets seem much more readable to me in comparison to full sentences for cases like this. From my experience developers scan docs much more than they read them and want to progress quickly. At least that's what I'm doing 😄
| export default function Layout({children, params: {locale}}) { | ||
| const direction = useTextDirection(locale); | ||
| export default async function RootLayout(/* ... */) { | ||
| const locale = await getLocale(); |
There was a problem hiding this comment.
I've adapted this example slightly to work with an async root layout. Users can still create a useTextDirection hook if desired, we just show the basic setup here.
amannn/next-intl#1017 no longer require locale routing.
Resolves #960
Use cases
localeshould be read from user settings instead of the[locale]segmentChanges
The gist is instead of reading the locale from the argument that's passed to
getRequestConfigini18n.tsyou can now return alocalefrom the function:This simplified setup comes with some benefits:
[locale]segment needs to be addedExample implementation
Docs changes
→ Proposed docs