Closed Bug 1356939 Opened 5 years ago Closed 4 years ago

Language xpi do not function (general.useragent.locale not set automatically)

Categories

(Toolkit :: Add-ons Manager, defect, P3)

52 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 383582

People

(Reporter: luweitest, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170323110425

Steps to reproduce:

Using Firefox 52.0.2esr, downloaded and installed zh-CN.xpi



Actual results:

UI do not change to zh-CN, even after restart, or in a new profile.


Expected results:

UI should change to another language
Does you changed the "general.useragent.locale" to "zh-CN" in about:config?
(In reply to YF (Yang) from comment #1)
> Does you changed the "general.useragent.locale" to "zh-CN" in about:config?

Thanks, changing "general.useragent.locale" to "zh-CN" and restarting solved the problem. Why it is not changed automatically after installing the xpi?
Summary: Language xpi do not function → Language xpi do not function (general.useragent.locale not set automatically)
Thunderbird has the same problem. Should I open another bug for Thunderbird?
Reproducible on Windows 10 with latest nightly.
Status: UNCONFIRMED → NEW
Component: Untriaged → Localization
Ever confirmed: true
Product: Firefox → Core
In the use-case of multiple language packs in a single install, this get's a little more interesting.

Moving over to addons-manager for triage. I think the only way to do something constructive here is on install. Or, anything else probably has edge cases that I wouldn't like to think about.
Component: Localization → Add-ons Manager
Product: Core → Toolkit
I'm not sure what we (people responsible for the Add-ons Manager component) are being asked to triage here.  I don't have much first hand experience with or knowledge about language packs so I'm not very well equipped to decide what is most desirable behavior when installing one..  If there's a specific proposal, I'm happy to help with estimating the work required to implement it (though just setting a preference at the appropriate time sounds pretty simple once "the appropriate time" has been clearly defined).
Flags: needinfo?(l10n)
Well, that's part of the problem, there's no defined UX for people wanting to switch languages.

On Android, where we ship a multi-locale build, we have https://support.mozilla.org/en-US/kb/change-default-language-firefox-android. But that doesn't need to do anything for install experiences, as those don't exist on Android (we can't dynamically extend the java strings.)
Flags: needinfo?(l10n)
The documentation for installing language packs is here: https://support.mozilla.org/en-US/kb/use-firefox-interface-other-languages-language-pack#w_how-to-change-the-language-of-the-user-interface and it mentions changing things in about:config.

Perhaps we'll add UX support for doing that it would be nice. Not sure where the bug should live, since its in this component, moving it onto the potential feature backlog. If anyone wants to take it in the meantime go for it.
Priority: -- → P3
My report of the bug is intended to make language xpi extension work, based on the logic that an extension|addon should just work after install, no about:config trick needed. Then Axel Hecht [:Pike] mentioned Firefox for android could change the language just on the menu, which I think is a better way of handling this. Release sites could hold less space too.
Duplicate of this bug: 1447789
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 383582
You need to log in before you can comment on or make changes to this bug.