1461590 - Language pack: Incomplete translation for some languages after updating to Firefox 60

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[Shaodan Hong]

Attachment: screenshot.jpg

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180503143129

Steps to reproduce:

Updating openSUSE Tumbleweed to  20180511 with the 60.0 version of 'MozillaFirefox' and 'MozillaFirefox-translations-common' package


Actual results:

1. The Add-ons manager show a message like "*** Language Pack could not be verified foe use in Firefox. Proceed with caution." above every items of language packs.
2. The interface of Preferences mixes with English and Chinese (locale language).


Expected results:

1. The language packs should not be unsigned.
2. The interface should be shown with Chinese (locale language).

Comment 1

[Francesco Lodolo [:flod]]

Thanks for reporting. This bug doesn't belong to "Translation" (that's for translating web page while browsing), keeping it in Untriaged for now.

For 1), Language pack signing is in progress (bug 1438246).

For 2): can you clarify what's in the screenshot (top vs bottom)? Can you copy and paste the content of the last table in about:support (type about:support in the address bar, press enter, the last table is "Internationalization & Localization")

Comment 2

[Shaodan Hong]

(In reply to Francesco Lodolo [:flod] from comment #1)
> Thanks for reporting. This bug doesn't belong to "Translation" (that's for
> translating web page while browsing), keeping it in Untriaged for now.
> 
> For 1), Language pack signing is in progress (bug 1438246).
> 
> For 2): can you clarify what's in the screenshot (top vs bottom)? Can you
> copy and paste the content of the last table in about:support (type
> about:support in the address bar, press enter, the last table is
> "Internationalization & Localization")

Thanks for your help

The top of the screenshot is about the language pack, and the bottom one is the screenshot of my about:preferences, as you can see, the majority of the texts is in English rather than Chinese(local language).

The about:support output:

Internationalization & Localization
-----------------------------------

Application Settings
Requested Locales: ["zh-CN","en-US"]
Available Locales: ["ar","ca","cs","da","de","el","en-GB","es-AR","es-CL","es-ES","fi","fr","hu","it","ja","ko","nb-NO","nl","pl","pt-BR","pt-PT","ru","sv-SE","zh-CN","zh-TW","en-US"]
App Locales: ["zh-CN","zh-TW","en-US","en-GB"]
Regional Preferences: ["zh-CN"]
Default Locale: "en-US"
Operating System
System Locales: ["zh-CN"]
Regional Preferences: ["zh-CN"]

Comment 3

[Francesco Lodolo [:flod]]

(In reply to Shaodan Hong from comment #2)
> The top of the screenshot is about the language pack, and the bottom one is
> the screenshot of my about:preferences, as you can see, the majority of the
> texts is in English rather than Chinese(local language).

Wow, I thought it was two different versions of Firefox :-\

The information in about:support seems correct to me, one possible explanation is that the language pack provided by Open Suse is incorrect.

Are you able to find the .xpi files on your system, and attach the language pack for zh-CN here? Not sure where Open Souse would put them (for some distros they are in /usr/share/mozilla, some ~/.mozilla/extensions, and even other places).

I would expect them to have a name like [e-mail] (where XX is the locale code).

Comment 4

[Axel Hecht [:Pike]]

Alternatively, install the language pack from mozilla from https://addons.mozilla.org/en-US/firefox/addon/chinese-simplified-zh-cn-la/, and see if that fixes your problem. It should be OK to install one on top, I hope.

That language pack is also signed, and the fact that yours isn't indicates that they're building something themselves.

also, the package seems to be on https://software.opensuse.org/package/MozillaFirefox-translations-common

Comment 5

[Shaodan Hong]

Attachment: [e-mail]

Comment 6

[Shaodan Hong]

(In reply to Francesco Lodolo [:flod] from comment #3)
> (In reply to Shaodan Hong from comment #2)
> > The top of the screenshot is about the language pack, and the bottom one is
> > the screenshot of my about:preferences, as you can see, the majority of the
> > texts is in English rather than Chinese(local language).
> 
> Wow, I thought it was two different versions of Firefox :-\
> 
> The information in about:support seems correct to me, one possible
> explanation is that the language pack provided by Open Suse is incorrect.
> 
> Are you able to find the .xpi files on your system, and attach the language
> pack for zh-CN here? Not sure where Open Souse would put them (for some
> distros they are in /usr/share/mozilla, some ~/.mozilla/extensions, and even
> other places).
> 
> I would expect them to have a name like [e-mail]
> (where XX is the locale code).

Thanks

I found the language pack in /usr/lib64/firefox/browser/extensions/ and it seems like a folder. The compressed package has been attached.

Comment 7

[Francesco Lodolo [:flod]]

Can you try installing it from https://addons.mozilla.org/en-US/firefox/addon/chinese-simplified-zh-cn-la/ ?

In the meantime, I'm trying to install Open Suse in a VM and failing :-\

It doesn't seem like there are significative differences in the actual localization files, the Open Suse package only has a bunch of extra files compared to the add-on available on AMO.

Only in mozilla/: META-INF
Only in opensuse/browser/chrome: zh-CN.manifest
Only in opensuse/browser: chrome.manifest
Only in opensuse/browser: crashreporter-override.ini
Only in opensuse/browser: defaults
Only in opensuse/browser/features: chrome.manifest
Only in opensuse/browser/features/[e-mail]: chrome.manifest
Only in opensuse/browser/features/[e-mail]: zh-CN.manifest
Only in opensuse/browser/features/[e-mail]: chrome.manifest
Only in opensuse/browser/features/[e-mail]: zh-CN.manifest
Only in opensuse/browser/features/[e-mail]: chrome.manifest
Only in opensuse/browser/features/[e-mail]: zh-CN.manifest
Only in opensuse/chrome: zh-CN.manifest
Only in opensuse/: chrome.manifest
Only in opensuse/: crashreporter.ini
diff -r mozilla/manifest.json opensuse/manifest.json
33c33
<       "version": "20180423053354"
---
>       "version": "20180511171035"
44c44
<   "version": "60.0buildid20180503143129",
---
>   "version": "60.0",
Only in opensuse/: res
Only in opensuse/: update.locale

Comment 8

[Shaodan Hong]

(In reply to Axel Hecht [:Pike] from comment #4)
> Alternatively, install the language pack from mozilla from
> https://addons.mozilla.org/en-US/firefox/addon/chinese-simplified-zh-cn-la/,
> and see if that fixes your problem. It should be OK to install one on top, I
> hope.
> 
> That language pack is also signed, and the fact that yours isn't indicates
> that they're building something themselves.
> 
> also, the package seems to be on
> https://software.opensuse.org/package/MozillaFirefox-translations-common

Thanks 

I successfully install this language pack and restart Firefox, the message of zh-CN language pack in Add-ons manager has disappeared while the interface of about:preferences is still in English.

Comment 9

[Francesco Lodolo [:flod]]

Do you see any error reported in the console when you open Preferences (Ctrl+Shift+J)? All the FTL files are there :-\

@zibi
Any idea of what's going on?

Comment 10

[Francesco Lodolo [:flod]]

1) Installed Firefox 60 on macOS (en-US build)
2) Installed language pack from AMO: https://addons.mozilla.org/en-US/firefox/addon/chinese-simplified-zh-cn-la/
3) Set intl.locale.requested to zh-CN

Good part of preferences show up in English (the entire General pane, side bar).

Comment 11

[Francesco Lodolo [:flod]]

de, fr, it, ja language packs work as expected, translating also the General pane and sidebar.

zh-TW has the same problem of zh-CN though.

Comment 12

[Shaodan Hong]

(In reply to Francesco Lodolo [:flod] from comment #9)
> Do you see any error reported in the console when you open Preferences
> (Ctrl+Shift+J)? All the FTL files are there :-\
> 
> @zibi
> Any idea of what's going on?

There seems has no special error reported in the console. And I had tried to remove the language pack provided by Opensuse and install the official one, even refresh firefox, the Preference is still in English.

Comment 13

[Francesco Lodolo [:flod]]

(In reply to Shaodan Hong from comment #12)
> There seems has no special error reported in the console. And I had tried to
> remove the language pack provided by Opensuse and install the official one,
> even refresh firefox, the Preference is still in English.

Confirmed. The console doesn't show any error, but for both zh-CN and zh-TW the General pane is mostly in English.

I've checked the zh-CN language pack, and those strings are available in preferences.ftl

Comment 14

[Francesco Lodolo [:flod]]

Following Axel's advice, I tried with other locales with a region (bn-BD, es-ES, gu-IN) and they all have the same issue as zh-*

Comment 15

[Shaodan Hong]

The Chinese localization version doesn't seems to have this issue.

https://download-ssl.firefox.com.cn/releases/firefox/60.0/zh-CN/Firefox-latest-x86_64.tar.bz2

Comment 16

[Francesco Lodolo [:flod]]

(In reply to Shaodan Hong from comment #15)
> The Chinese localization version doesn't seems to have this issue.
> 
> https://download-ssl.firefox.com.cn/releases/firefox/60.0/zh-CN/Firefox-
> latest-x86_64.tar.bz2

It only affects language packs. Full builds downloaded from https://www.mozilla.org/firefox/all/ should work as expected (tested es-ES).

Comment 17

[Zibi Braniecki [:zbraniecki][:gandalf]]

I started debugging it, and got the point where I suspect something is off with the resource protocol.

I followed steps from Comment 10 and installed polish langpack alongside: https://addons.mozilla.org/en-US/firefox/addon/polski-language-pack/

After installing both, I can open `resource://langpack-pl-browser` path just fine and it has the content of the polish language pack.

For zh-CN I try to open `resource://langpack-zh-CN-browser` and it doesn't open at all.

Everything else - L10nRegistry, Fluent, etc. seems to work well and recovers from that by fetching the fallback.

Andrew - sorry to bother you, but I'm on my way to the airport and won't have a working MacOS debug machine for a couple days. Any chance you could try to take a look at why in comment 10 this line: https://searchfox.org/mozilla-central/source/toolkit/components/extensions/Extension.jsm#1942 - doesn't register the right protocol?

Maybe the manifest is wrong? Or resource protocol?

Comment 18

[Zibi Braniecki [:zbraniecki][:gandalf]]

Actually, made a bit more progress:

```
let rp = Services.io.getProtocolHandler("resource").QueryInterface(Ci.nsIResProtocolHandler)

rp.getSubstitution("langpack-pl-browser").displaySpec;

"jar:file:///Users/zbraniecki/Library/Application%20Support/Firefox/Profiles/4i9htvpz.test/extensions/[e-mail]!/"

rp.getSubstitution("langpack-zh-CN-browser").displaySpec;
"jar:file:///Users/zbraniecki/Library/Application%20Support/Firefox/Profiles/4i9htvpz.test/extensions/[e-mail]!/"
```

Verified that both paths exist on the hard drive, but trying to `fetch("resource://langpack-pl-browser")` work but trying to `fetch("resource://langpack-zh-CN-browser")` doesn't.

Comment 19

[Francesco Lodolo [:flod]]

Putting on release drivers radar. I can't test 62, because we don't have language packs on FTP at the moment.

I tried 61 with es-ES language pack, and the entire Preferences are basically in English, with the exception of New Tab prefs.

This affects Linux users, but also distributions like Acer.

[Tracking Requested - why for this release]:
Language packs don't translate the UI completely for some languages

Comment 20

[Zibi Braniecki [:zbraniecki][:gandalf]]

Is there a chance that it's something about signing? And/or related to `-` in locale code?

Comment 21

[Francesco Lodolo [:flod]]

OK, confirmed that 62 is affected too.

Comment 22

[Andrew Swan [:aswan]]

I reproduced everything :gandalf describes in comment 18.  Additionally, the jar: urls load just fine, so this suggests the problem lies somewhere in the resource: protocol handler or SubstitutingProtocolHandler or something.

Comment 23

[Mike Kaply [:mkaply]]

Does resource://langpack-zh-cn-browser work?

Comment 24

[Zibi Braniecki [:zbraniecki][:gandalf]]

no, and `rp.getSubstitution("langpack-zh-cn-browser").displaySpec;` errors out.

Comment 25

[Kris Maglione [:kmag]]

URL hostnames are by definition case-insensitive, so nsStandardURL normalizes them to all lower-case. SubstitutingProtocolHandler, though, stores them in the case you give it when you add the substitution, and does its look-ups case-sensitively.

We could work around this in the langpack code, but we should probably just fix the footgun in the handler. You're not the first person to run into it.

Comment 26

[Andrew Swan [:aswan]]

Attachment: Bug 1461590 Always use lower case for language pack resource: substitutions

Review commit: https://reviewboard.mozilla.org/r/244128/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/244128/

Comment 27

[Andrew Swan [:aswan]]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #25)
> We could work around this in the langpack code, but we should probably just
> fix the footgun in the handler. You're not the first person to run into it.

I think that's a fine idea, but the narrower fix is trivial and will be easy to uplift, perhaps we could do the protocol handler changes in nightly but do the lower case hack everywhere else

Comment 28

[Andrew Swan [:aswan]]

I manually verified the attached patch in Nightly with an es-ES language pack (and confirmed the original issue was present before applying the patch)

Comment 29

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 8975928 [details]
Bug 1461590 Always use lower case for language pack resource: substitutions

https://reviewboard.mozilla.org/r/244128/#review250082

sgtm! Should we file a follow up to fix the footgun?

Comment 30

[Kris Maglione [:kmag]]

Attachment: Bug 1461590: Lower-case hostnames when adding substitutions.

Since URI hostnames are defined to be case-insensitive, we only ever see
lower-case hostnames when looking up substitutions. That means that
substitutions containing capital letters are inaccessible, which is a footgun
that has hit many people.

The handler should lower-case substitutions when they're added so that
look-ups are always case-insensitive.

Review commit: https://reviewboard.mozilla.org/r/244146/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/244146/

Comment 31

[Kris Maglione [:kmag]]

(In reply to Andrew Swan [:aswan] from comment #27)
> (In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're
> blocked) from comment #25)
> > We could work around this in the langpack code, but we should probably just
> > fix the footgun in the handler. You're not the first person to run into it.
> 
> I think that's a fine idea, but the narrower fix is trivial and will be easy
> to uplift, perhaps we could do the protocol handler changes in nightly but
> do the lower case hack everywhere else

The handler fix is just as easy to uplift. It's also cheaper, and fixes the general problem, so I don't think we should add a separate workaround here.

Comment 32

[Andrew Swan [:aswan]]

Forked bug 1461801 for the resource protocol handler fix, reclaiming this bug for the immediate langpack fix.

Comment 33

[Kris Maglione [:kmag]]

Comment on attachment 8975928 [details]
Bug 1461590 Always use lower case for language pack resource: substitutions

https://reviewboard.mozilla.org/r/244128/#review250090

::: toolkit/components/extensions/Extension.jsm:1946
(Diff revision 1)
>  
>      resourceProtocol.setSubstitution(langpackId, this.rootURI);
>  
>      for (const [sourceName, basePath] of Object.entries(l10nRegistrySources)) {
>        L10nRegistry.registerSource(new FileSource(
>          `${sourceName}-${langpackId}`,

Are the source names case sensitive? Are we sure this is going to work as expected?

::: toolkit/components/extensions/Extension.jsm:1958
(Diff revision 1)
>                                   "webextension-langpack-startup");
>    }
>  
>    async shutdown(reason) {
>      for (const sourceName of Object.keys(this.startupData.l10nRegistrySources)) {
>        L10nRegistry.removeSource(`${sourceName}-${this.startupData.langpackId}`);

This doesn't match the case of the source name added in the startup function. I suspect it's not going to work.

::: toolkit/components/extensions/Extension.jsm:1965
(Diff revision 1)
>      if (this.chromeRegistryHandle) {
>        this.chromeRegistryHandle.destruct();
>        this.chromeRegistryHandle = null;
>      }
>  
>      resourceProtocol.setSubstitution(this.startupData.langpackId, null);

This is going to fail to remove mixed-case listeners that were added in startup().

Comment 34

[Andrew Swan [:aswan]]

Comment on attachment 8975928 [details]
Bug 1461590 Always use lower case for language pack resource: substitutions

https://reviewboard.mozilla.org/r/244128/#review250090

whoops, meant to do this at https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/toolkit/components/extensions/Extension.jsm#710-711 but apparently we're doing the protocol handler fix instead so dropping this

Comment 35

[Kris Maglione [:kmag]]

Comment on attachment 8975939 [details]
Bug 1461590: Lower-case hostnames when adding substitutions.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/244146/diff/1-2/

Comment 36

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8975939 [details]
Bug 1461590: Lower-case hostnames when adding substitutions.

https://reviewboard.mozilla.org/r/244146/#review250118

The documentation in .idl needs to be fixed too.
If we do this, also Has/GetSubstitution methods should get the same behavior.

Comment 37

[Kris Maglione [:kmag]]

Comment on attachment 8975939 [details]
Bug 1461590: Lower-case hostnames when adding substitutions.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/244146/diff/2-3/

Comment 38

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8975939 [details]
Bug 1461590: Lower-case hostnames when adding substitutions.

https://reviewboard.mozilla.org/r/244146/#review250130

Comment 39

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3c014aea60227c8818ac632e79fb13a0767151a3
Bug 1461590: Lower-case hostnames when adding substitutions. r=smaug f=dveditz

Comment 41

[Kris Maglione [:kmag]]

Comment on attachment 8975939 [details]
Bug 1461590: Lower-case hostnames when adding substitutions.

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1365709/bug 1431260, along with deployment of new-style langpacks.
[User impact if declined]: Users of language packs with mixed-case locale codes (e.g., zh-CN) end up with incomplete localizations, with some parts of the browser in English and some in their native language. This especially affects Linux distributions which ship all of their localizations as langpacks, but also affects many other users who install langpacks themselves.
[Is this code covered by automated tests?]: Yes.
[Has the fix been verified in Nightly?]: Not yet.
[Needs manual test from QE? If yes, steps to reproduce]: Described in earlier comments.
[List of other uplifts needed for the feature/fix]: None.

[Is the change risky?]: Low-risk.
[Why is the change risky/not risky?]: This makes a minor change to the way that we register resource: substitutions so that mixed-case substitution names are always treated as lower-case. Since lookups are always lower-cased in order to support the requirement that hostnames are case-insensitive, mixed-case substitutions were entirely inaccessible prior to this patch, so there are no existing valid use cases we can break. The only possible risk is if we were previously registering a mixed-case substitution which would conflict with an all-lower-case substitution. We've checked in-tree code and haven't found any place where this may be an issue, and since legacy extensions are no longer supported, this is extremely likely to come up in practice.

[String changes made/needed]: None.

Comment 42

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8975939 [details]
Bug 1461590: Lower-case hostnames when adding substitutions.

Approved for all the things.

Comment 43

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/79bfebd1166db3e94387bb6d7532e408084b78dd
https://hg.mozilla.org/releases/mozilla-esr60/rev/c9846ca8c38f421be13baa5bf0d479b9637e806f

Comment 44

[Kris Maglione [:kmag]]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #41)
> We've checked in-tree code and haven't found any place where this may be an
> issue, and since legacy extensions are no longer supported, this is extremely
> likely to come up in practice.

Extremely *un*likely to come up in practice. :)

Comment 45

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Added this to Firefox and ESR 60.0.1 release notes.

Comment 46

[Francesco Lodolo [:flod]]

Tested 60.0.1 candidate (build2) and zh-CN language pack from TaskCluster, preferences look good.

Comment 47

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/3c014aea6022

Comment 48

[Ciprian Georgiu, Desktop QA]

I've managed to reproduce this bug with the STR from comment 10, on an affected FF 60.0 build and using the zh-CN language pack.

I can confirm that the "about:preferences" page is properly translated for the following locales: bn-BD, es-ES, gu-IN, zh-CN and zh-TW. Tested on 60.0.1esr build 1 (20180516032417) and 60.0.1 candidate build2 (20180516032328) running Win 10 x64, macOS 10.13, Ubuntu 16.04 x64.

Comment 49

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/cb1e3d50463c

Comment 51

[Ciprian Georgiu, Desktop QA]

I've tried to verify this bug on 61 Beta and 62 Nightly, but it seems that the .xpi language packs (donwloaded from https://archive.mozilla.org/pub/firefox/candidates/61.0b6-candidates/build1/win64/xpi/) are not compatible with these Firefox versions. I've also tried setting the following prefs to true: `extensions.legacy.enabled`, `extensions.allow-non-mpc-extensions` or `xpinstall.signatures.dev-root`, none of this have worked. 

It doesn't seem to work either on the unbranded builds (Beta/Nightly), I get the same message of incompatibility between Firefox and .xpi when installing the language pack.

Hi Kris,
I'm wondering if is there any other way I could install the language packs or verify this issue on Beta and Nightly?

Comment 52

[Zibi Braniecki [:zbraniecki][:gandalf]]

Can you try with `xpinstall.signatures.required=false`?

Comment 53

[Andrew Swan [:aswan]]

If signatures are the issue then you want the pref extensions.langpacks.signatures.required
But the user facing error message for a signature error is different, if you're getting a "not compatible" error, that sounds like you need a langpack for the specific version of Firefox that you're running.  Nightly langpacks aren't on archive.mozilla.org, but beta ones should be, you just need to ensure you get one for the exact build you're running.

Comment 54

[Justin Wood (:Callek)]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #52)
> Can you try with `xpinstall.signatures.required=false`?

Files on archive.mozilla.org should be signed, so this shouldn't be necessary.

(In reply to Ciprian Georgiu, QA [:ciprian_georgiu] from comment #51)
> I've tried to verify this bug on 61 Beta and 62 Nightly, but it seems that
> the .xpi language packs (donwloaded from
> https://archive.mozilla.org/pub/firefox/candidates/61.0b6-candidates/build1/
> win64/xpi/) are not compatible with these Firefox versions. I've also tried
> setting the following prefs to true: `extensions.legacy.enabled`,
> `extensions.allow-non-mpc-extensions` or `xpinstall.signatures.dev-root`,
> none of this have worked. 
> 
> It doesn't seem to work either on the unbranded builds (Beta/Nightly), I get
> the same message of incompatibility between Firefox and .xpi when installing
> the language pack.

The language packs are compatible only with specific Gecko versions, so you'll want 61 beta to be used for Gecko 61, and due to a bug nothing on archive.m.o right now is compatible with 62 Nightly. (I can provide you a link to a language pack .xpi from a recent 62 nightly though if you need one that is compat, just tell me what language[s] you want).

If you are indeed trying a 61 language pack with a 61 beta, then a screenshot or copy/paste of the specific message would be helpful.

Comment 55

[Kris Maglione [:kmag]]

I don't have anything to add to comment 54

Comment 56

[Ciprian Georgiu, Desktop QA]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #52)
> Can you try with `xpinstall.signatures.required=false`?

I was able to install the language packs properly from archive.mozilla.org on Beta, after flipping the pref.

I have tested with the following language packs: es-ES, gu-IN, zh-CN, zh-TW and bn-BD, on Beta 61.0b6 (20180517141400) running Win 10 x64, macOS 10.13 and Ubuntu 16.04 x64. I can confirm that the `about:preferences` page looks good.

(In reply to Justin Wood (:Callek) from comment #54)
> ...
> The language packs are compatible only with specific Gecko versions, so
> you'll want 61 beta to be used for Gecko 61, and due to a bug nothing on
> archive.m.o right now is compatible with 62 Nightly. (I can provide you a
> link to a language pack .xpi from a recent 62 nightly though if you need one
> that is compat, just tell me what language[s] you want).
> 

I'd like to verify this on Nightly 62 as well, for the same language packs mentioned above. Could you please provide me a link for those .xpi's?

Comment 57

[Justin Wood (:Callek)]

(In reply to Ciprian Georgiu, QA [:ciprian_georgiu] from comment #56)
> (In reply to Justin Wood (:Callek) from comment #54)
> > ...
> > The language packs are compatible only with specific Gecko versions, so
> > you'll want 61 beta to be used for Gecko 61, and due to a bug nothing on
> > archive.m.o right now is compatible with 62 Nightly. (I can provide you a
> > link to a language pack .xpi from a recent 62 nightly though if you need one
> > that is compat, just tell me what language[s] you want).
> > 
> 
> I'd like to verify this on Nightly 62 as well, for the same language packs
> mentioned above. Could you please provide me a link for those .xpi's?


Language packs suitable for the most recent 62.0a1 nightly (in https://archive.mozilla.org/pub/firefox/nightly/2018/05/2018-05-21-10-01-09-mozilla-central/) are at:

bn-BD: https://queue.taskcluster.net/v1/task/FaDSZ5BURiqKfqb_5jY-pA/runs/0/artifacts/public/build/bn-BD/target.langpack.xpi
es-ES: https://queue.taskcluster.net/v1/task/ek2bFfioTVq2GRQw_9rmBQ/runs/0/artifacts/public/build/es-ES/target.langpack.xpi
gu-IN: https://queue.taskcluster.net/v1/task/YsPV5ReRRdCmRIlj8ubWDg/runs/0/artifacts/public/build/gu-IN/target.langpack.xpi
zh-CN: https://queue.taskcluster.net/v1/task/IUBSUMaESpaJDtKQgtDU7g/runs/0/artifacts/public/build/zh-CN/target.langpack.xpi
zh-TW: https://queue.taskcluster.net/v1/task/IUBSUMaESpaJDtKQgtDU7g/runs/0/artifacts/public/build/zh-TW/target.langpack.xpi

Comment 58

[Ciprian Georgiu, Desktop QA]

Thanks folks, for the quick replies.

It works as expected on latest Nightly 62.0a1 too (2018-05-21) across platforms, as in comment 56. Marking this bug as verified fixed.