Option for fetching translations from a seperate file instead of bundling it in with the HTML in an effort to reduce bundle size

[Louvki]

Is your feature request related to a problem? Please describe.

I am building a statically generated site. The site is pretty large and will be only getting larger. As of how i18n works now is that each generated html page is embeded with all the translations for the specific locale it is using. Since the translations are loaded from the HTML there's no way to cache them. Which means more network load than neccessry as the same data is being refetched on each navigation. What's worse the problem is scaling (albeit not much) with each translation added.

In nuxt.config.js
If the generation target is set to static then the translation files are repeated in the state.js for each page.
If the generation target is set to server then the translation files are repeatededly embedded in the HTML for each page.

Both of these have the same problem where the DRY principle is violated and the translations are being refethed without any possibility for cahcing.

Describe the solution you'd like

I would like an option within the i18n config which would allow to link to the translation file bundle instead of directly embeding it in the HTML. This would mean an additional network request. However It would be a worthy tradeoff (in my case anyways) for having each other load subsequently faster as the transalation files will be cached on the browser.

The way I see it - when it comes to the first load I will have to load the translations either way. However having them in seperate JS file allows me to take advantage of caching on the subsequent page loads.

as mentioned my @rchl in #1107

The reason this module puts translations in the generated HTML file is that otherwise, the client-side would still have to fetch the translations on load which means an extra network request and more delays. The amount of transferred data would be the same and there would be an overhead of another network request.

EDIT: Well, an argument could be made here that the translation file will be cached by the browser and result in faster page-loads down the road. So there is a balancing act and the results could depend on the circumstances.

Describe alternatives you've considered

The perfect solution of course would be for i18n module to automatically figure out which translations are required for each page as to completely nulify unneccessary load. However I realize this is wishful thinking and would be impossible for a lot of use cases.

In my specifc use case the translations come from a static file in the project. I wouldnt mind splitting that into multiple files and importing each one manually if this meant a reduction in bundle size. Is there a possibility for this?
Though personally I still would like to have the originally mentioned option available I understand you guys have your hands full. Until and if that beomes a possibility I wouldnt mind having some tools for dealing with the problem at hand.

[rchl]

I'm thinking the possible solution could be to allow passing an object to the lazy option (currently accepts boolean only) which would then allow passing something like { skipNuxtState: true } which would disable injecting to Nuxt state thus not include translations in the generated HTML.

Would that solution work for you?

[Louvki]

I appreciate the quick reply! Yes it would.

• Sorry if it's a dumb question just want to make sure - and then you would attach a script link to a seperate singular js file containing all the translations for the specified locale?
• From what I unerstand that would cover it both for target static and server?
• Would this be a difficult feature to implement?

[rchl]

Sorry if it's a dumb question just want to make sure - and then you would attach a script link to a seperate singular js file containing all the translations for the specified locale?

Currently, when using lazy, the module puts translations for the "fallback locale" in the main bundle and other locales each in a separate bundle. This wouldn't change with that new option.

So if the user has "fallback locale" selected and visits a page then there would be no extra requests triggered to load translations. When having another locale selected, it would have to do a separate request to fetch translatations.

From what I unerstand that would cover it both for target static and server?

Yes

Would this be a difficult feature to implement?

Very easy. Adding documentation and a test would take the most time.

[Louvki]

Currently, when using lazy, the module puts translations for the "fallback locale" in the main bundle and other locales each in a separate bundle. This wouldn't change with that new option.

So if the user has "fallback locale" selected and visits a page then there would be no extra requests triggered to load translations. When having another locale selected, it would have to do a separate request to fetch translatations.

Maybe I am misunderstanding something but wouldn't it be beneficial to have the fallback locale in a seperate bundle so to take advantage of caching?

How I see it now is that if the fallback locale is within the main bundle and that bundle is unique for each page then the same data gets refetched every time. I assume (and I might be misunderstanding something) that by the main bundle you mean state.js files (in the context of target static) which are unique for each page.

[rchl]

The main bundle is not unique per page. It's unique per app. It's where all the components and libraries are. So it's required for loading the app and also cached by the browser.

[Louvki]

Ah ok I get it now! Yeah this would do it.

I don't think I could help much with testing, especially in this scenario but I can open up a PR for the documentation.