Vue-i18n: Feature Request: Fallback Locale as array for cascading fallbacks.

[nchutchind]

It would be nice to be able to specify fallback locale as an array that could cascade when falling back. For example, if someone selects "Canadian French" as their current locale, it would be nice to have a fallback locale of "French" and then an ultimate fallback of "English." This would be helpful for any locale that has sub-locales.

[martinhbramwell]

Other i18n packages offer "ultimate" fall backs directly with the text such as :

<span>{{ $t('label.signup', 'Sign Up') }}</span>

Does vue-i18n have no such capability? I don't see how to do it, but I certainly believe it's necessary.

[nelson6e65]

@martinhbramwell Sometimes I use the string as the key, which could be useful for you if you need a "ultimate" fallback:

<span>{{ $t('Sign Up') }}</span>

And then, set up your fallback to (Spanish in this example):

const i18n = new VueI18n({
  locale: 'es-VE',
  fallbackLocale: 'es',
  messages: { }
})

But, would be useful if the @nchutchind suggestion is implemented. :100:

[drorweissweiss]

This feature seems trivial when handling locale, I guess @kazupon originally intended this project to support only languages.

@nchutchind , did you perhaps manage to solve this yourself somehow?

[nchutchind]

@drorweissweiss No, I did not put much more effort into it. I just noticed that it wasn't supported and figured I'd bring it up.

[martinhbramwell]

In my opinion, fallbacks are obligatory for any package that wants to use I18N in its name. I appreciate the point @nelson6e65 makes, but @nchutchind is right in his original request, that easy automatic fall back from dialect, to major language, to English is essential.

[nelson6e65]

Yes. I think auto-fallback are necessary, @martinhbramwell. If locale: 'es_VE', it should auto-fallback to es and then pass to the fallbackLocale in the same way. And, as ultimate, to the en.

[alexcarruthers]

What's the status of this idea? It would be very useful. Especially if we have per-language translation strings and want to add per-locale date formatting.

[louisameline]

I also think that fallback handling must be improved. As described here: https://www.i18next.com/principles/fallback, let me reexplain what should be done.

For the vocabulary, let me remind you that a "locale" like "fr-ca" is composed of the language ("fr") and the territory ("ca").

First of all, the developer should provide defaut messages for a language, then potentially variations for a territory. Then here is what should happen:

Simple use cases - keep working with a string

If

• I provide en (which would be English from USA), fr (French from France) and fr-ca (French from Canada) messages
• I set en as default fallback: fallbackLocale: 'en'

Then

• If someone with fr-ca locale comes, he will get fr-ca messages. If a fr-ca message is missing, the first fallback must be fr, then en if the fr messages are also missing.
  This first level of fallback is what must be done in priority.
• If someone with fr (should not happen often nowadays) or fr-be for example comes, he will get fr messages, and fallback to en if missing.
• If someone with en-us comes, he will get en messages.

More complex use cases - provide an object

The above should suffice for most people but more must be done to accomodate other use cases. Let's say that:

If

• I provide en (USA), en-gb (British), sp (Spanish) and pt (Portugese) messages
• I set en as default fallback

Then, just as explained above:

• People with en-us get en messages
• People with en-gb get en-gb messages, then fallback to en messages
• People with sp get sp messages, and then fallback to en
• People with pt get pt messages, and then fallback to en

However, if I want

• Spanish-speaking to fall back to en-gb first rather than falling back directly to en messages
• Portugese-speaking people to fall back to es before falling back directly to en

...that is not possible with fallbackLocale being a string

So here is the object I would need to be able to pass to achieve it:

fallbackLocale: {
  sp: ['en-gb'],
  pt: ['sp', 'en'],
  default: ['en']
}

Remarks:

• If the fallbacks in an array are not enough to find a message, I tend to think that we should see if the last value of the array itself has a set of fallbacks, and if not, finally use the default fallback. It means that:
  
  
  
  • for sp, if the message is missing in en-gb too, we must then look up in en
  
  
  • for such a config:
  
  

fallbackLocale: {
  sp: ['en-gb'],
  pt: ['sp-ar'],
  default: ['en']
}

The order of checks for someone who comes with pt-br should actually be 'pt-br' => 'pt' => 'sp-ar' => 'sp' => 'en-gb' => 'en'

• Note that en is specified in the pt array to force en right after sp, because otherwise we would go to en-gb after sp (as sp has en-gb as its first fallback)

• If a message is missing in a territory, it would make sense to automatically look for it in the territory language set even if it's not specified in the array. So for example, in my mind:
  pt: ['sp-ar', 'en-gb']
  should be considered the same as
  pt: ['sp-ar', 'sp', 'en-gb', 'en']

• We could imagine an edge-case scenario where territory messages fallback on other territory messages first (before falling back to language message), like

fallbackLocale: {
  sp: ['en-gb'],
  'sp-cl': ['sp-ar'],
  default: ['en']
}

Going fully manual - provide an array

If I wanted to easily use some custom pattern for example based on the user preferences (rather than a config file), I should be able to provide an array rather than an object:

fallbackLocale: ['en-gb', 'fr', 'sp', 'pt']

But honestly I dont' think this third stage is a priority. It allows every kind of scenarios but it lets the developper do all the work of computing the fallbacks. And it can be achieved with an object too, although less simple to elaborate.

[exoego]

Thanks @louisameline
Multi-value dictionary fallbackLocale in your suggestion helped me a lot to understand use cases and how it should be used.
It totally make sense to have such feature for languages that have many locales.

It would be happy if vue-i18n users understand kazupon, the vue-i18n creator, is currently very busy on productivity toolset around vue-i18n and also organizing huge Vue conference in Japan.
I (collaborator) also have very limited time nowadays, but am happy to review and merge if someone opened a pull request 🙏

I think vue-i18n is well architected and have great test suite, so you will smoothly dive into code base and implement feature with confidence (no breaking change), as same as me last year.
Feel free to ask something if you need help to implement this.

[louisameline]

@exoego I thought some more about this and amended my previous message with a more definitive wrap-up of the subject. As you'll see, there are actually 3 layers of improvement that don't need to be done at the same time.

It would actually be fun to code, but I don't know when I'll have time for this, so I'm not making any promises. Thank you very much

[nelson6e65]

Spanish-speaking to fall back to en-gb before falling back en messages.

I think this should be implicit, instead of explicit. I mean... you should only need one fallback.

If you set your locale to es-ve and your fallback to en-gb, It should be resolved to es-ve locale and then search in es language. If not available, use your fallback locale en-gb, that shall reach the en language if missing strings.

---

I would like enjoy learning how can I help to this issue, but... I have not time right now. 😭

[louisameline]

@nelson6e65 Yes that's what I have in mind too. I reformulated the sentence in case it wasn't clear enough.

[jxn-30]

I would really love to see this feature soon.

[kazupon]

close, due to release v8.17.0

[kazupon]

See the fallback section docs:
https://kazupon.github.io/vue-i18n/guide/fallback.html#fallback-localization

[louisameline]

Awesome, thank you very much !

[nelson6e65]

🎉 Amazing!