fallback not working as expected about vuex-i18n HOT 14 CLOSED

Hi @Zambiorix,

Thank you for your feedback. The locale system is actually very crude and does not include any "intelligence". It is somewhat intentional, as for our use cases the fallback is somewhat of a last resort if the key was not defined for the current locale.

To avoid putting to much into one plugin, It would probably make sense to have an additional complementary plugin that would determine what the ideal fallback locale is, based on the browser locale and the available locales in the store and then set the corresponding fallback locale for the vuex-i18n-plugin.

Would this make sense to you?

from vuex-i18n.

I'm fairly new to Vue :-)

Why would you want an extra plugin for that? If the i18v plugin would allow a handler (to define the actual locale) wouldn't that be enough?

from vuex-i18n.

It is basically about separation of concerns and there are two possible problems that I see with the scenario of determining a fallback locale:

1. We need a sensible way to detect the users current locale. This is not necessarily straightforward especially for older browsers, and might lead to problems if the library is used with server side rendering.
2. The fallback locale translations must be present in the browser in the vuex store. This would mean, that on page load, one would need to load all available locales, many of which would never actually be used.

Therefore I would suggest a workflow as follows:

1. Fetching an array of available locales from the server. The vuex-i18n plugin would not handle this, as we do not want to impose any restriction on how people setup server communication or specify available locales.
2. Use a separate vuex-i18n-localization plugin to determine what the best locale would be, depending on the users locale and the available locales.
3. Load the respective locale from the server and set it as current locale (or as fallback)

Alternatively, one could also use a server side mechanism to detect the users locale and send the correct locale translation to the client on the first request.

from vuex-i18n.

1. You could leave locale detection out of any plugin, and up to the developer. Indeed many scenario's are possible. A good x-platform locale detection plugin would be handy indeed, but totally disconnected from the i18n plugin.
2. You could also leave locale loading up to the developer, I am doing this in my projects already.

It is possible to give some advice on how to implement those scenario's in the form of examples.

I often build my websites (and api's, native apps, etc ..) with maximum 3 locales loaded at any time.
For example the project I am working on now has the following pattern:

1. get x-platform browser locale
2. check if language cookie has been set, if yes take that locale (anonymous user can change language preference to override browser locale)
3. check if user has signed in, if yes, get language preference from user profile and set that locale (known user can change language preference that overrides both anonymous user and browser locale)
4. define locale list to load: examples:
   nl-BE => load => nl-BE, nl, en
   en-UK => load => en-UK, en
5. set locale and fallback locale

Usually, a region specific locale has much less content than a generic locale. Only the texts that are specific to that region. Between nl-BE and nl-NL, there is not much difference for example.
I always use "en" locale as final fallback in case not all texts are translated during development/staging. And english is generic enough for most translators ;-)
en => all texts during development
nl => all dutch texts
nl-BE => some texts that are flemish and differ to official dutch

That said, your plugin is perfect for the work it has to do. All the locale handling and loading is done by myself. It is, in my opinion, only missing one feature of (natural fallback order):
region locale => generic locale => fallback locale
nl-BE => nl => en

Now there are only 2 levels.
A simple solution that does not break current code is to:
when a text is requested:

1. check if the text is available from the set locale, yes -> return, no -> next step
2. check if the set locale is region specific, no -> step 5, yes -> next step
3. make set locale generic (split on "-", take first part, normalise)
4. check if text is available from the generic locale, yes -> return, no -> next step
5. check if text is available in fallback locale, yes -> return, no -> not available

This way, there are no breaking changes and offers a solution for a 3 level fallback

from vuex-i18n.

Hmm.. That sounds quite feasible. I will take a swing at it and see if I can get this to work.

from vuex-i18n.

Currently, I organise my root language file as follows:
This way it is easier for translators to find out what all the texts mean, see the translations of a text together + with a good json editor you don't see one long list but collapsible blocks

When done, I flatten and split the file in a format that i18n can load

i18n.en.json =>
"all.account.toolbar-menu.links.sign-in": "Sign in",
...

not sure how to insert multiline json here :-/

{ "all": { "account": { "toolbar-menu": { "links": { "sign-in": { "en": "Sign in", "nl": "Aanmelden" }, "sign-up": { "en": "Sign up", "nl": "Registreren" } } },

from vuex-i18n.

Hi there,

there is a new version 1.6.0 that should implement the fallback locale as you proposed.

from vuex-i18n.

that was fast :-)

from vuex-i18n.

That sounds like a reasonable way to go about organization of language files. Do you already have some tooling available to split the files into language specific translations?

It would be nice to have sort of a command line interface tool to
a) gather all translations in the source files and generate – or even better update – the translation source files and
b) transform the translation source files into language specific files

from vuex-i18n.

I have some stuff done in golang for api projects, but I am looking into webpack plugin to create statics on the go based on my global file

from vuex-i18n.

the idea is to do this automatically on dev / deployment builds

from vuex-i18n.

My initial thought was also to use golang for this, as we are programming practically all of our server stuff in golang and I am though quite familiar with it.

But I agree with you that a webpack plugin would probably be easier to integrate into the build pipeline directly.

from vuex-i18n.

javascript / vue / webpack, it is all fairly new for me .. steep learning curve, it will take some time
I'm backend (golang/.NET) and native mobile app developer

from vuex-i18n.

it is working!
thank you!

from vuex-i18n.