`i18n.getMessage()` language fallback paths

[carlosjeurissen]

Not all browsers handle language fallbacks the same. Considering the following situation:

An extension is using the native i18n APIs with "default_locale": "en" in manifest.json, and three messages.json files in the languages en, pt and pt-BR.

Both en and pt include the message ids message1 and message2. While pt-BR includes only message1.

In the above situation, browsers handle fetching i18n.getMessage('message2') different.

Chromium first checks pt_BR/messages.json, if the message is not present, it checks pt/messages.json, and finally, if the message is still not found, it will check the default_locale, in this case en/messages.json. In the above situation, this means it gets the message2 value from pt.

In Firefox, however, the browser first checks pt_BR/messages.json. If the message is not in this file, it will directly fallback to default_locale. so it checks en/messages.json. Resulting in message2 value becomes the one from en.

Interestingly enough, in Firefox, if pt_BR/messages.json is not present in general, it will check pt/messages.json first, before checking en/messages.json.

What is the behaviour we want in these cases?

[hanguokai]

I support Chrome's behavior, which seems more reasonable. Usually, developers want language-region locale to fallback to language locale first, then the default locale.

If the browser wants to support multiple different behaviors at the same time, I recommend add a new property in the 3rd parameter(options) in this api.

[carlosjeurissen]

@hanguokai generally speaking this can be useful to reduce the overall package size.

However, there are cases when the fallback might not always be welcome. Say your zh/messages.json is in Simplified Chinese script, and zh_TW is in Traditional Chinese. Would it be great if a different script is used as fallback? Same can happen with other languages with multiple scripts, like Serbian (Latin and Cyrillic).

[hanguokai]

I know the difference, it's better than the default(complete another language like English). For example,

en: "Software"
zh: "软件"
zh_TW: "軟體"

The difference between "软件" and "軟體" is smaller than that of English.

For the best user experience, developers need to supply full message map(1:1) if they are different. Only when they are the same or acceptable, they can be omitted.

[carlosjeurissen]

@hanguokai relying on good developer behaviour can be tricky. I can imagine there are Chinese people knowing only English and either Traditional / Simplified Chinese? I could be wrong?

[hanguokai]

Do you know how many people only understand Chinese(zh-CN and/or zh-TW) but not English? Of course, there are real examples in every situation(combinations).

I said in my previous post:

If the browser wants to support multiple different behaviors at the same time, I recommend add a new property in the 3rd parameter(options) in this api.

[hanguokai]

There are multiple possible strategies. Another possible fallback strategy is following navigator.languages order. For example:

If navigator.languages is ['zh-TW', 'en'], then the search order is zh-TW -> en -> extension default locale.

[xeenon]

I believe Safari matches Chrome here after looking at the code.

[carlosjeurissen]

Reached out to the ltli w3c group here: w3c/ltli#35.

Safari currently matches the behaviour of Chrome. If from above discussion is concluded this the preferred process, Firefox will follow.