Open
Bug 1381580
Opened 7 years ago
Updated 2 years ago
Support multiple fallback locales in i18n API
Categories
(WebExtensions :: General, defect, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: danny0838, Unassigned)
References
Details
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.
Updated•7 years ago
|
Component: Untriaged → WebExtensions: Frontend
Product: Firefox → Toolkit
Updated•7 years ago
|
Summary: Bad i18n fallback for regional message → Support multiple fallback locales in i18n API
Updated•7 years ago
|
Status: UNCONFIRMED → NEW
Component: WebExtensions: Frontend → WebExtensions: General
Depends on: 1357902
Ever confirmed: true
Updated•7 years ago
|
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
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•