Js-lingui: Add fallback languages for the i18n instance.

Created on 29 Oct 2020  Β·  4Comments  Β·  Source: lingui/js-lingui

First of all, I would like to thank all of you, your work on this library. Actually, v3 was launched before due date, so congrats!! :tada:

Is your feature request related to a problem? Please describe.
Linguijs does not allow you to decide fallback locales for specific languages.

Instead, lingui will show source language strings.

Describe proposed solution
Add fallback specific languages for the lingui instance. It could be similar to i18next API.
~
{
es-MX: ['es'],
es-AR: ['es'],
default: ['en'],
}
~

Describe alternatives you've considered
For the moment, this handling relies on yourself, loading the catalog inside if statements in case of unknown/unsupported language. This is kinda tedious, because it's not that easy as "just load english for every new locale". For example, we would like to handle all hispanic locales ("es-MX, es-AR") to be have a fallback in "es", but, every other to use the default fallback locale (en).

πŸ’‘new feature πŸ“¦ cli

Most helpful comment

Automatically resolve fallbacks according to CLDR data, (probably we should add to config file if the user wants to enable that fallback or should we enable this for every config?)

I would enable it by default, but make it opt-out using fallbackLocales: null. It won't break existing configurations if we at the same time deprecate fallbackLocale and automatically migrate it to fallbackLocales (see below).

Allow overriding it in config

Definitely, exactly as you say πŸ‘

We should keep fallbackLocale as string, in the future probably with fallbackLocales would be enough

I would make it deprecated, show a warning in a console, but convert it to:

{
  "fallbackLocales": {
    _: fallbackLocale
  }
}

There're 2-3 similar deprecation warning in @lingui/conf with automatic conversion to new version β€” It's user friendly and it's easier to maintain when we have a single source rather than two.

Which reminds me that we should figure out how to configure a catch-all locale:

{
  fallbackLocales: {
   // this?
    _: "en",

   // or this? I guess `default` keyword it's safe, because there's no such locale
    default: "en"
}

What do you think?

All 4 comments

Related issue #280

I think it would be great, if Lingui used the default fallback locales specified by CLDR which users of the lib could customize to fit their needs

I can work on this feature this week.

I tough about:

  • Automatically resolve fallbacks according to CLDR data, (probably we should add to config file if the user wants to enable that fallback or should we enable this for every config?)
  • Allow overriding it in config, sth like:
{
  fallbackLocales: {
    "en-GB": ["en-US", "en"]
  }
}
  • We should keep fallbackLocale as string, in the future probably with fallbackLocales would be enough

Automatically resolve fallbacks according to CLDR data, (probably we should add to config file if the user wants to enable that fallback or should we enable this for every config?)

I would enable it by default, but make it opt-out using fallbackLocales: null. It won't break existing configurations if we at the same time deprecate fallbackLocale and automatically migrate it to fallbackLocales (see below).

Allow overriding it in config

Definitely, exactly as you say πŸ‘

We should keep fallbackLocale as string, in the future probably with fallbackLocales would be enough

I would make it deprecated, show a warning in a console, but convert it to:

{
  "fallbackLocales": {
    _: fallbackLocale
  }
}

There're 2-3 similar deprecation warning in @lingui/conf with automatic conversion to new version β€” It's user friendly and it's easier to maintain when we have a single source rather than two.

Which reminds me that we should figure out how to configure a catch-all locale:

{
  fallbackLocales: {
   // this?
    _: "en",

   // or this? I guess `default` keyword it's safe, because there's no such locale
    default: "en"
}

What do you think?

default looks self descriptive so I'll go in that way

Was this page helpful?
0 / 5 - 0 ratings