extension: browser.i18n does not use basic language as fallback
Categories
(WebExtensions :: General, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: gdh1995, Unassigned)
Details
Attachments
(1 file)
302.04 KB,
application/x-zip-compressed
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Steps to reproduce:
Install a web extension with such folders in _locales: en, zh, zh_CN and zh_TW , and its default locales is "en".
Open Firefox and ensure its UI language to be "zh-CN" (Chinese Simplified), and restart if needed.
Then open the debug console of its options page / background page, and run browser.i18n.getMessage
with some keys, to see which text will be matched.
Actual results:
The matching order is "zh_CN" > "en", which means only those items in _locales/zh_CN and _locales/en will be matched.
Expected results:
As said in https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Internationalization#Localized_string_selection, Firefox should find a message id in "zh_CN", and if not found go to "zh" as a fallback, while if both fail, go to "en" as a last fallback.
My intent
My intent is to merge some duplicated text in a same basic language (like in zh-CN and zh-TW) into _locales/zh/messages.json, so that the extension zip file is smaller and I can maintain i18n text easier.
The attachment is one of my web extensions, and its use "_locales/zh" to store most of its Chinese text. It works well on Chromium browsers, but on Firefox it's options page is only in English - browser.i18n.getMessage
does not use "zh" messages.
Source code analysis
I find this in Firefox repo: https://dxr.mozilla.org/mozilla-central/rev/9d135cd098b700c8f0fd28b8fd374aedda89445f/toolkit/components/extensions/ExtensionCommon.jsm#2111
After debugging I've confirmed, for the extension in attachment, defaultLocale
is "en", and selectedLocale
is "zh-CN", so "zh" is discarded.
I think this should be updated to consider about "basic language" & "basic_language+regional_variant" specially.
Comment 1•6 years ago
|
||
Hi Dahan,
Could you tell me of two web extensions with such folders in _locales: en, zh, zh_CN and zh_TW , and its default locales is "en", please?
Regards, Flor.
Reporter | ||
Comment 2•6 years ago
|
||
Um, I haven't met other extensions using zh
as a fallback. But I just want to save a "message.json" of 32KB in the extension package.
Comment 3•6 years ago
|
||
Hi Dahan,
I'm getting a bit confused here. Because the first step to reproduce this bug is <Install a web extension with such folders in _locales: en, zh, zh_CN and zh_TW , and its default locales is "en".>. So you should know of at least one web extension to test this issue, right?
Reporter | ||
Comment 4•6 years ago
|
||
The attached ZIP file is just what I want. https://bugzilla.mozilla.org/attachment.cgi?id=9117982
Reporter | ||
Comment 5•6 years ago
|
||
Sorry, my old comments didn't explain it in detail. Here's what I noticed:
- The
vimium_c-1.79.1-firefox-6066671.zip
attached to this bug, is one of my web extensions and its name is "Vimium C" - I want to support both English and Chinese, so there were
en
andzh
translation messages before the last month - But when I released Vimium C on Chrome Web Store, I found the store don't display Chinese text on its extension details page
- After a few tries, a new version with
en
,zh
,zh_CN
andzh_TW
folders succeeded in making Chrome Web Store show Chinese text as expected
But when I load this version (the attached zip file) on a Firefox whose UI language is zh-CN
, it only displayed Chinese extension names - all other text are in English.
- Then I went to Google and found a way to debugging the inner code of
browser.i18n.getMessage
- the conclusion was, the function only uses an array of
[@@extension_id, default_locale, current_locale]
, - and for this extension,
default_locale
isen
andcurrent_locale
iszh_CN
If I remove the zh_CN
and zh_TW
folders, then current_locale
is zh
and the extension's options page will be in Chinese.
Comment 6•6 years ago
|
||
Hi Dahan,
Sorry for the delay in answering. Now I understand your problem. Thanks for being so clear.
So I will set a component for this bug in hope that someone with more expertise may look at it. We'll await their answer.
Regards, Flor.
Updated•5 years ago
|
Comment 7•5 years ago
|
||
This is web extensions locale negotiation.
Updated•3 years ago
|
Comment 8•7 months ago
|
||
A patch is being worked on in bug 1381580.
Description
•