Notes:
- The compiler looks for occurences of
<NextIntlClientProvider messages="auto">
- For every occurence, the module graph is traversed (static imports as well as lazy references), looking for client entry points.
- The namespaces within client module graphs are collected (e.g.
useTranslations('ns1')
) - The provider is replaced with something like
<NextIntlClientProvider messages={pick(useMessages(), ['ns1', 'ns2'])} />
<NextIntlClientProvider messages="auto">
must be rendered in a Server Component whenmessages="auto"
is used- The compiler doesn't traverse nested segments. This is important, as it will not pull messages from segments that might not render into parent layouts.
Open questions:
- When
<NextIntlClientProvider messages="auto">
is used in a layout, do we auto detect sibling entry points (page
,not-found
, …) and traverse those too? Or should the provider be explicitly used in each file and we only follow module references? Consider thaterror.tsx
must be a Client Component, therefore at least for this file it would be helpful if sibling entry points are traversed from a layout. Not sure. It would be helpful to not traversepage.tsx
though, as it might not render. Maybeerror.tsx
is the only exception, as it's strongly coupled to the layout and will mount as part of the error boundary in any case? The other routes load/mount only on demand AFAIK (e.g.not-found
).
Example structure:
app
[locale]
page.tsx
layout.tsx
Navigation.tsx
C1.tsx
C2.tsx
In this example the following namespaces are loaded on the provider: C1
, C2
.