Different approaches for i18n of large applications?

[dlohvinov]

Hi!

I'm struggling to find a way how to implement my i18n properly. It's a large-scale project (Approx. 5k translation keys or so), and I need to follow these criterias:

• be able to add new language, even those I don't know (as for now, usually, just pass key-value file to a localizator on customer side)
• support different languages noun cases and genders
• i really want to reuse my locales, instead of creating new ones (if they can be composed from existing ones)

I'm considering using 4 different approaches, but none of them is great enough to be sure it's a right way:

• use a external i18n tool like Localazy, so it would be easy to add new languages for non-technical people like business analyst or even customer
• just use json or js translations, with pluralizations - nothing more complex -- so that non-technical people will be able to add a new language just copying and translating this file
• use powerful vue-i18n features like Message Functions, so that i18n will be highly reusable, but someone won't be able to add new language without technical help
• or, maybe, should i have 2 files: first one is json key:value for languages tokens, and second one is for js composite locales from these tokens so it would be some way of a compromise between these previous options -- but most complicated?

Can you give me an advice please, or, maybe, share you experience with organizing i18n in large-scale apps?

[felicienfrancois]

I used to work with :

• vue-i18n
• single json translation file (per language)
• i18n Ally vscode extension (inline translation editing for developers)
• external i18n tool Phrase, with automatic synchronisation and onpage editing integration (for non developers)

I would recommend to use single json translation file (per language), to be able to integrate more easily with tools.

i18n ally and Phrase are both powerful tools which are quite easy to setup.
Both i18n Ally and Phrase work best with single file json.
i18n ally is a pain with multiple file (it ask for file to save in each time)
Phrase (or other external tool), may work properly with multiple json files but would probably not work with message functions nor with component scoped i18n tag

Then, I still have one issue with single json translation file setup, on bundling.
In my current setup , all translation keys are bundled into the root index.js bundle and I was not able to tree shake translation keys based on where they are used (i.e. to have translation keys bundled into the view bundle).
This leads to a quite big root bundle (depends on number of languages and keys).
With ~ 2000 keys x 2 languages, my root bundle is 160ko heavier (50ko gzipped).
Maybe tree shaking is achievable but I have not figured out for now.

Another tip, If you're going with single file json, you'd better normalize properly your key path in order to avoid big mess and bad reuse of keys.

[dlohvinov]

@felicienfrancois thank you for sharing your experience!
May I ask: have you been using vue-i18n with its advanced (more powerful and complicated :) ) features, or just most common features like $t and $tc?

[felicienfrancois]

@dlohvinov I'm mostly using $t (or it's t counterpart in composition api) with string or number parameters injection (indexed or named), and with a single global locale scope.
We also have a case with SSR (Vue SSR without Nuxt)
I'm not using :

• Pluralization
• Non global locale scope
• i18 tags (single component local translation)
• Function translations

At some point I tested Pluralization, and it works well with third party tools like Phrase, but we're no longer using it because we don't have a need for it.
For dates, amount or other advanced format, we were using Vue2 filters, and we're now using dedicated homemade functions since we moved to Vue3 (we're not using vue-1i18n for those).

[felicienfrancois]

To be complete, we're currently considering changing or improving our setup to solve the issues we have:

• Tree shaking / Bundle size
• Issues with scope (vue-i18n is not usable outside setup function, so not in router, stores, not in backend)
• Dates & amount formatting

We may either go with another framework (ex: i18next) or extend our usage of vue-i18n.
We're currently evaluating the opportunity to use Function translation for dates and amounts (thoose would not be synced in third party translation tool)
And also the opportunity to use i18n tags or multiple json files in other to fix the bundling/tree shaking issue.
But for now we have not found a working setup with i18n ally and third party tools.
i18n ally does not seems to support i18n tags and does not seems to work well with per component or per directory json file.
Additionally to makes i18n tag work with third party translation tool we'll need to find or implement an extracting tool in other to sync it to third party translation tool.