i18next theme load all locales

[theowenyoung]

Hi,

I suppose the following code, the webpack will load all files in GATSBY_THEME_I18N_REACT_I18NEXT, is there a better way to only load the current locale?

https://github.com/gatsbyjs/themes/blob/fead1c23870cf37e8ce1a5476a43ef580ca1d509/packages/gatsby-theme-i18n-react-i18next/src/wrap-page-element.js#L14

[oddui]

I think there is a similar issue in gatsby-theme-i18n-react-intl. All the language files can be seen in the app-xxx.js file in production mode.

[LekoArts]

I'm not sure I understand your question, can you please clarify what you expect to happen and what currently happens?

[oddui]

Hello, in my case I was testing with the gatsby-theme-i18n-react-intl package. I no longer use the package but i can try to explain what i saw.

When a page was built, for example for the en locale, the built assets contain translations in all languages that I had. I could see messages in different languages in the app-xxx.js file.

What I expect is that a page built for a locale only contains translated messages for that specific locale.

[remimarsal]

Hi @LekoArts, see below the screenshot for what's happening when using gatsby-theme-i18n-react-intl.

The whole i18n folder gets included in the app-xxx.js chunk so every page gets the translations already compiled in the HTML from SSR then proceeds to download all the translations from every locales.

I would expect the translations to be in their own chunks or better yet not having to download them at all.

I'm certainly missing some insights but with a static site generator, we don't need the <IntlProvider> on the client side once compiled. Even without the app bug mentioned it still forces us to download all the translations for that locale. If the reason is that we need exactly the same code between SSR and browser, then maybe react-intl is not the right tool for gatsby?

[IstoraMandiri]

This is especially bad with large sites, as bundle size can be huge and a change to any string anywhere means all pages need to rebuild.

It seems that the problem is that webpack will statically anylyse require and include all files that match the dirname/**/**.json pattern, assuming that, as with JS, there may be dependancies in that "library" directory. Unless there's some way of configuring webpack to not do this, and to bundle the JSON/YAML only, it seems this technique is not a scalable solution.

The technique may work with import rather than require, as import can target only specific files, but as import is async it would require some more logic to deal with SSR/hydration - this is perhaps made easier with React 18's (currently alpha) SSR Suspense?

@LekoArts perhaps a warning should be added to the i18n themes that this technique isn't suitible for large sites?