Michel Smola

one could use next/dynamic for this: One would need to wrap each locale file for each component in a NextIntlProvider. Then the component rendering that NextIntlProvider can be lazy loaded...

you could to something like ```js const i18n = { 'en-US': dynamic(() => import('./en-US')), 'en-CA': dynamic(() => import('./en-CA')), ... } function MyComponent() { const { locale } = useRouter() const...

Wrap that pattern in a couple of HOCs and you end up with ```js // en-US.js makeI18n({ MyComponent: { title: "bla", } }) // index.js export default withI18n(() => {...

to my understanding, dynamic does not load anything until the dynamic component is rendered so only the active locale providers would be loaded. The messages would therefore be loaded whenever...

Yeah you might have to manually handle the loading state. Blank should be fine for most cases though as nextjs * renders dynamic components during SSR so SEO is fine...

I assume it would be possible to use a server component to fetch some i18n data and then a isomorphic component to provide it as context ```tsx // locale/Common.server.tsx export...

Then you might wrap any component that needs the 'common' messages within this component and it would be passed the right messages like `provideI18n(CommonMessages, ...)(MyComponent)`. Then one would only have...

How the `I18nProvider` works depends a bit on how the react team will implement the context api for server components

This would be great. `Html.Attributes.batch` would work, too. I end up using ```elm List.filterMap identity [ Just some_attribute , Maybe.map conditional_attribute ] ``` a lot.

But then you have to be careful not to use classList somewhere before that in the attribute list. `Html.Attributes.batch []` would be consistend and kind of cool for other purposes...