web-ext should have an option to test in a locale/language

[Pike]

Is this a feature request or a bug?

Feature request

What is the current behavior?

Testing a localization of a web-extension is currently finicky. While modifying intl.locale.requested is pretty straightforward (and works via --pref and localizes the about:addons display), modifying the UI language requires to add that language to the available languages in the locale service. For example by installing said langpack, too. You can also fake it, though, see the WIP docs in https://reviewboard.mozilla.org/r/231002/diff/1#index_header.

What is the expected or desired behavior?

It'd be great if we could just do web-ext run --locale=de

Version information (for bug reports)

• Firefox version: 59 and newer
• Your OS and version: all
• Paste the output of these commands:

node --version && npm --version && web-ext --version
v10.0.0
5.6.0
2.5.0

The fix is two-fold, setting the pref and adding the locale to the available locales. The first is easy, the latter has two ways of doing it:

• add a dummy language pack to the test profile
• talk to Services.locale

Is the latter possible? If so, that'd be probably the most straightforward way of doing it.

CC @zbraniecki

[zbraniecki]

In 62 we'll make this easier with bug https://bugzilla.mozilla.org/show_bug.cgi?id=1440969

[M-Reimer]

How can this actually be faked?
I want to test locales from time to time but don't want all the language packs installed...

[Pike]

https://firefox-source-docs.mozilla.org/intl/locale.html#testing has some hints.

[M-Reimer]

But this doesn't help me as an addon developer, right?

[GrayedFox]

Agreed that this would be a nice CLI option, see this comment for a workaround.

[Rob--W]

I've been looking into implementing a cli flag to support locale switching.

This is not an easy task:

Build type	can install dummy*	can reasonably easily find real langpack
Release	no	yes
Beta	no	yes
Developer Edition	yes	no (bug 1564433)
Nightly	yes	no (possible but very complicated; see below)
Unbranded builds	yes	not at all

* dummy langpacks can only be installed if the extensions.langpacks.signatures.required pref can be applied. This pref is ignored on Release and Beta (where MOZ_REQUIRE_SIGNING=1 at build time), but available on DevEd, Nightly and unbranded builds.

Real langpacks for Release and Beta

1. Run firefox --version to get the version.
2. Use the AMO API to find a suitable langpack https://addons-server.readthedocs.io/en/latest/topics/api/addons.html#get--api-v4-addons-language-tools-
3. Download the langpack (xpi).
4. Pre-install the xpi in the profile, set intl.locale.requested to the desired language.

To reduce the overhead of startup, it would be ideal if the downloaded langpacks are cached on the disk.

Real langpacks for Nightly

This is complicated....

1. SOMEHOW get the buildID of Nightly (and also the platform).
2. Find the langpack by scraping https://download-origin.cdn.mozilla.net/pub/firefox/nightly/
   (I can find the xpis for Linux and one for macOS, but not Windows at the first glance; this might imply that langpacks are cross)
3. Download the langpack (xpi).
4. Pre-install the xpi in the profile, set intl.locale.requested to the desired language.

Dummy langpack for Developer Edition and Nightly

1. Create dummy langpack, zip it up as [extensionid].xpi.
2. Pre-install the xpi in the profile, and set the following prefs:
   • intl.locale.requested to the desired language
   • extensions.langpacks.signatures.required to false

[Rob--W]

An alternative to installing real lang packs on Beta and Release is to create and sign dummy langpacks, and bundle them with web-ext.

[Pike]

I don't think you need actual langpacks at all, you just need

Services.locale.availableLocales = ["de"].concat(Services.locale.availableLocales);
Services.locale.requestedLocales = ["de"].concat(Services.locale.requestedLocales);

from https://firefox-source-docs.mozilla.org/intl/locale.html#testing-locale-switching (with some tweaks to the values).

I didn't test that recently, but our automated tests do the same thing, so that should still work.

[Rob--W]

@Pike "Actual langpacks" as in "real langpacks? I figured that, yes. The snippets that you've shown are to be run in the browser process. I'm not sure if it is possible to run code in the browser process through the remote debugging protocol, but in any case the logic should work without depending on browser internals:

• availableLocales is set by installing a (signed) dummy langpack.
• requestedLocales is set through the intl.locale.requested.

Do you see any issue of this approach over your suggestion?

[Pike]

I think you listed out all the problems with the approach of trying to install the actual languages.

Maybe add that language pack discovery might change at some point.

[Rob--W]

Maybe add that language pack discovery might change at some point.

What do you mean by this? That while setting the intl.locale.requested pref works today, that it might be ignored in the future? If that's the case, are there any bugs that I can reference (from comments in web-ext?)