Translations are loaded for all layers to the client

[enkot]

Environment

• Operating System: Linux
• Node Version: v18.18.0
• Nuxt Version: 3.10.2
• CLI Version: 3.10.1
• Nitro Version: 2.8.1
• Package Manager: [email protected]
• Builder: -
• User Config: modules, extends, i18n
• Runtime Modules: @nuxtjs/[email protected]
• Build Modules: -

Reproduction

https://stackblitz.com/edit/bobbiegoede-nuxt-i18n-starter-qj9tuc

Describe the bug

• Build
• Run with npm preview
• Switch locale
• Open the network tab

You will see that the translations from all layers have been loaded.
Only 1 file with merged translations should be loaded.

Additional context

Logs

No response

[BobbieGoede]

This is expected behaviour, all locale files are loaded and merged, this could be beneficial for locales sharing locale files (fewer and smaller requests).

I might add functionality that merges all locale files per locale during the build step but this would only be possible if all files are static (as is the case in your reproduction).

[enkot]

This is a problem, the final bundle should not have welcome translation from the core, only from commerce layer.
If we have multiple layers, the client will be loaded with a lot of redundant data that they don't even need to know about.

[enkot]

I think it should have a bug label.
In my case we can't use NuxtI18n in its current state in our project because users will be loading hundreds of translations that have been overwritten by app layer, but are still being loaded.

[BobbieGoede]

While this functionality could be improved, this behaviour is not a bug and is working as documented. I understand that this may be a deal breaker in your specific use case but it won't be prioritized/labeled the same as a bug.

Maybe it's possible to workaround this issue by merging the files yourself at build time and filtering out the other locale files, of course if you have good ideas on how to implement this in the module itself we always welcome contributions.

[enkot]

Sure, I will try fix it.

While this functionality could be improved, this behaviour is not a bug and is working as documented.

Then it's a fundamental design problem. Loading translations from all layers and merging them should not happen on the client.
Imaging loading few Header.vue components on the client, but one of them always overrides the others. In order to load only one Header, the decision "what should be in the bundle" is made build time. The same works for translation data.

I understand that this may be a deal breaker in your specific use case

It is a deal breaker for any big project that use layers.

[BobbieGoede]

Do keep in mind that we also support dynamic locale files that could be fetching translations from a remote source at runtime.

[enkot]

How does this affect merging local translation files? :)
You can load a completely different file at runtime, but the local files in the layers must still be merged at build time.

[BobbieGoede]

If translations are fetched from a remote source these remote sources could provide different translations at runtime, any layer can provide static and dynamic locale files in any order, merging those at build time wouldn't necessarily be desirable as translations could be added or removed at any point.

I agree that it would be nice to merge all static locale files at build time, just pointing out that some users rely on the behaviour that you find a deal breaker. There are probably also projects that would prefer fetching the remote translations at build time, turning these static and merging it all, but that's not the current functionality.

[enkot]

What do you mean by "translations could be added or removed at any point"?

[BobbieGoede]

An example would be that some users use a headless CMS to provide translations, the dynamic locale files fetch these translations at runtime.

If a translation from a dynamic locale resource at the beginning of the merge order is no longer present it should be removed from the final merged result unless overwritten, if a translation from a dynamic locale resource is added and at the end of the merge order it should be added and overwrites previous translations with the same keys in the final merged result.

These projects don't want to rebuild their project whenever their translations change, which may not be performant but it is a valid use case all the same.