Skip to content
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

i18next theme load all locales #93

Open
theowenyoung opened this issue Dec 12, 2020 · 5 comments
Open

i18next theme load all locales #93

theowenyoung opened this issue Dec 12, 2020 · 5 comments

Comments

@theowenyoung
Copy link
Contributor

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?

const data = require(`${GATSBY_THEME_I18N_REACT_I18NEXT}/${locale}/${name}.json`)

@oddui
Copy link

oddui commented Jan 18, 2021

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
Copy link
Contributor

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

@oddui
Copy link

oddui commented Apr 21, 2021

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
Copy link

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?

Capture d’écran 2021-11-19 à 16 55 39

@IstoraMandiri
Copy link

IstoraMandiri commented Dec 7, 2021

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants