Support multiple fallback locales in i18n API



a year ago
29 days ago


(Reporter: Danny Lin, Unassigned)


54 Branch

Firefox Tracking Flags

(Not tracked)




a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

Say the default language is "en". And we have following locales:


zh_TW does not have an entry "foo", while zh and en have.

Now we get chrome.i18n.getMessage("foo").

Actual results:

The "foo" entry defined in en is returned.

Expected results:

The "foo" entry defined in zh should be returned.
Component: Untriaged → WebExtensions: Frontend
Product: Firefox → Toolkit
Summary: Bad i18n fallback for regional message → Support multiple fallback locales in i18n API
Component: WebExtensions: Frontend → WebExtensions: General
Depends on: 1357902
Ever confirmed: true


a year ago
Priority: -- → P3

Comment 1

10 months ago
I was going to post a similar bug/request.

There is always a problem with getting translations done in time, especially when they are done by volunteers.

The current option is to leave the translation out completely if it is not updated in time, often just for the sake of ONE entry.

I propose that any missing property in the locale language 'messages.json' should revert to the property in "default_locale"

I expect the "default_locale" must be the most up-to-date file.

Alternatively ..........

I thought abut making the fallback part of the script, but there isn't any API at the moment to allow selecting the required language. If there is an API that allows selecting the specific _locales, then the fallback can be add as part of the extension code (and not built in Firefox).
TBH, such API would be handy for testing anyway.

PS. Where is the i18n API file? I will have a look.

Comment 2

10 months ago
The presetting of the "default_locale" as fallback can be done very EASILY.

If there is a "default_locale", the API should always load it first. Once that JSON is loaded, if there is local, the object properties should be passed to the "default_locale".

What happens is that any new value in the selected local will overwrite the "default_locale" values but the missing ones will remain.

I do the same when I am updating preference data or partially updating any object.

I think that would be easy enough to implement without any complications.

Is it (Can it be) done here?


29 days ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.