Closed Bug 1381580 Opened 8 years ago Closed 3 months ago

Support multiple fallback locales in i18n API

Categories

(WebExtensions :: General, defect, P3)

54 Branch
defect

Tracking

(firefox139 fixed)

RESOLVED FIXED
139 Branch
Tracking Status
firefox139 --- fixed

People

(Reporter: danny0838, Assigned: carlos-mozilla)

References

Details

(Keywords: dev-doc-complete, Whiteboard: [wecg])

Attachments

(1 file)

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.
Component: Untriaged → WebExtensions: Frontend
Product: Firefox → Toolkit
Summary: Bad i18n fallback for regional message → Support multiple fallback locales in i18n API
Status: UNCONFIRMED → NEW
Component: WebExtensions: Frontend → WebExtensions: General
Depends on: 1357902
Ever confirmed: true
Priority: -- → P3
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.
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
Product: Toolkit → WebExtensions
Severity: normal → S3

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

Whiteboard: [wecg]
Assignee: nobody → carlos
Status: NEW → ASSIGNED
Duplicate of this bug: 1606239
Duplicate of this bug: 1362244
Pushed by rob@robwu.nl: https://hg.mozilla.org/integration/autoland/rev/53ed203965f0 Fix language fallback mechanism for i18n.getMessage and manifest localization r=robwu
Keywords: dev-doc-needed
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 139 Branch

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

Flags: needinfo?(rob)

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).

Flags: needinfo?(rob)

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: