1381580 - Support multiple fallback locales in i18n API

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P3)

Description

[Danny Lin]

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:

_locales/en/messages.json
_locales/zh/messages.json
_locales/zh_TW/messages.json

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.

Comment 1

[erosman [:erosman]]

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

[erosman [:erosman]]

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?
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/ExtensionCommon.jsm#1321

Comment 3

[Rob Wu [:robwu]]

I discussed this with Eemeli and others from the WECG and I18n groups at TPAC. We are supportive of implementing this in Firefox - https://github.com/w3c/webextensions/issues/296#issuecomment-2369812944

Comment 4

[Rob Wu [:robwu]]

Patches are welcome.

Implementation pointers:

• We build a map of locale data (that directly feeds into the i18n.getMessage API) at https://searchfox.org/mozilla-central/rev/1e8cec3727d6e09f4af41bb3d202b7a4c326ed84/toolkit/components/extensions/Extension.sys.mjs#2247-2259
• The manifest.json file is localized at https://searchfox.org/mozilla-central/rev/1e8cec3727d6e09f4af41bb3d202b7a4c326ed84/toolkit/components/extensions/Extension.sys.mjs#1503-1532

Comment 5

[Carlos]

Attachment: Bug 1381580 - Fix language fallback mechanism for i18n.getMessage and manifest localization r=robwu

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/53ed203965f0
Fix language fallback mechanism for i18n.getMessage and manifest localization r=robwu

Comment 9

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/53ed203965f0

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Should we add this to the Fx139 relnotes? Please nominate if yes.

Comment 11

[Rob Wu [:robwu]]

Only as part of https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/139#changes_for_add-on_developers

... which is covered by the dev-doc-needed keyword that I have added (which should also include updated content in https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization).

Comment 12

[rbloor]

Release note added in Bug-1381580 cascading locales support release note #39013. My reading of the internationalization guide is that it already documents this behavior, so no changes are needed.