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

VERIFIED FIXED in Firefox -esr60

Status

()

P1
major
VERIFIED FIXED
6 months ago
6 months ago

People

(Reporter: shaodan1997, Assigned: kmag)

Tracking

({regression})

60 Branch
mozilla62
x86_64
All
regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(relnote-firefox 60+, firefox-esr52 unaffected, firefox-esr6060+ verified, firefox60blocking verified, firefox61blocking verified, firefox62+ verified)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

6 months ago
Created attachment 8975745 [details]
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).
(Reporter)

Updated

6 months ago
Component: Untriaged → Translation
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
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")
Component: Translation → Untriaged
Flags: needinfo?(shaodan1997)
(Reporter)

Comment 2

6 months ago
(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"]
Flags: needinfo?(shaodan1997)
(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 langpack-XX@firefox.mozilla.org.xpi (where XX is the locale code).
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
(Reporter)

Comment 6

6 months ago
(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 langpack-XX@firefox.mozilla.org.xpi
> (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.
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/firefox@getpocket.com: chrome.manifest
Only in opensuse/browser/features/firefox@getpocket.com: zh-CN.manifest
Only in opensuse/browser/features/formautofill@mozilla.org: chrome.manifest
Only in opensuse/browser/features/formautofill@mozilla.org: zh-CN.manifest
Only in opensuse/browser/features/onboarding@mozilla.org: chrome.manifest
Only in opensuse/browser/features/onboarding@mozilla.org: 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
(Reporter)

Comment 8

6 months ago
(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.
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?
Flags: needinfo?(gandalf)
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).
Status: UNCONFIRMED → NEW
Component: Untriaged → Internationalization
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
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.
Summary: Unsigned language packs and incompletion translation after updating to Firefox 60 → Language pack: Incomplete translation for some languages after updating to Firefox 60
(Reporter)

Comment 12

6 months ago
(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.
(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
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-*
Severity: normal → major
(Reporter)

Comment 15

6 months ago
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
(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).
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?
Flags: needinfo?(gandalf) → needinfo?(aswan)
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/langpack-pl@firefox.mozilla.org.xpi!/"

rp.getSubstitution("langpack-zh-CN-browser").displaySpec;
"jar:file:///Users/zbraniecki/Library/Application%20Support/Firefox/Profiles/4i9htvpz.test/extensions/langpack-zh-CN@firefox.mozilla.org.xpi!/"
```

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.
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
status-firefox60: --- → affected
status-firefox61: --- → affected
status-firefox62: --- → ?
tracking-firefox60: --- → ?
Is there a chance that it's something about signing? And/or related to `-` in locale code?
status-firefox-esr60: --- → ?
tracking-firefox60: ? → +
OK, confirmed that 62 is affected too.
status-firefox62: ? → affected

Comment 22

6 months ago
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

6 months ago
Does resource://langpack-zh-cn-browser work?
no, and `rp.getSubstitution("langpack-zh-cn-browser").displaySpec;` errors out.
(Assignee)

Comment 25

6 months ago
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.
Assignee: nobody → kmaglione+bmo
Component: Internationalization → Networking
Flags: needinfo?(aswan)
Summary: Language pack: Incomplete translation for some languages after updating to Firefox 60 → SubstitutingProtocolHandler should lower-case substitutions when they are added
status-firefox-esr60: ? → affected
tracking-firefox61: --- → +
tracking-firefox62: --- → +
tracking-firefox-esr60: --- → ?
Comment hidden (mozreview-request)

Comment 27

6 months ago
(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

6 months ago
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)

Updated

6 months ago
Attachment #8975928 - Flags: review?(gandalf)

Comment 29

6 months ago
mozreview-review
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?
Attachment #8975928 - Flags: review?(gandalf) → review+
Comment hidden (mozreview-request)
(Assignee)

Comment 31

6 months ago
(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

6 months ago
Forked bug 1461801 for the resource protocol handler fix, reclaiming this bug for the immediate langpack fix.
Assignee: kmaglione+bmo → aswan
Component: Networking → Add-ons Manager
Priority: -- → P1
Product: Core → Toolkit
Summary: SubstitutingProtocolHandler should lower-case substitutions when they are added → Language pack: Incomplete translation for some languages after updating to Firefox 60
(Assignee)

Comment 33

6 months ago
mozreview-review
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

6 months ago
mozreview-review-reply
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 hidden (mozreview-request)

Comment 36

6 months ago
mozreview-review
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 hidden (mozreview-request)

Comment 38

6 months ago
mozreview-review
Comment on attachment 8975939 [details]
Bug 1461590: Lower-case hostnames when adding substitutions.

https://reviewboard.mozilla.org/r/244146/#review250130
Attachment #8975939 - Flags: review?(bugs) → review+
(Assignee)

Comment 39

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

Updated

6 months ago
Assignee: aswan → kmaglione+bmo
Component: Add-ons Manager → Networking
Product: Toolkit → Core

Updated

6 months ago
Attachment #8975928 - Attachment is obsolete: true

Updated

6 months ago
Duplicate of this bug: 1461801
(Assignee)

Comment 41

6 months ago
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.
Attachment #8975939 - Flags: approval-mozilla-release?
Attachment #8975939 - Flags: approval-mozilla-esr60?
Attachment #8975939 - Flags: approval-mozilla-beta?
Comment on attachment 8975939 [details]
Bug 1461590: Lower-case hostnames when adding substitutions.

Approved for all the things.
Attachment #8975939 - Flags: approval-mozilla-release?
Attachment #8975939 - Flags: approval-mozilla-release+
Attachment #8975939 - Flags: approval-mozilla-esr60?
Attachment #8975939 - Flags: approval-mozilla-esr60+
Attachment #8975939 - Flags: approval-mozilla-beta?
Attachment #8975939 - Flags: approval-mozilla-beta+
tracking-firefox60: + → blocking
tracking-firefox61: + → blocking
tracking-firefox-esr60: ? → 60+
Flags: qe-verify+
Flags: in-testsuite+
(Assignee)

Comment 44

6 months ago
(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

6 months ago
Added this to Firefox and ESR 60.0.1 release notes.
relnote-firefox: --- → 60+
Tested 60.0.1 candidate (build2) and zh-CN language pack from TaskCluster, preferences look good.

Comment 47

6 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/3c014aea6022
Status: NEW → RESOLVED
Last Resolved: 6 months ago
status-firefox62: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
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.
status-firefox60: fixed → verified
status-firefox-esr60: fixed → verified
Keywords: regression

Comment 49

6 months ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/cb1e3d50463c
status-firefox61: affected → fixed
Duplicate of this bug: 1462071
status-firefox-esr52: --- → unaffected
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?
Flags: needinfo?(kmaglione+bmo)
Can you try with `xpinstall.signatures.required=false`?
Flags: needinfo?(ciprian.georgiu)

Comment 53

6 months ago
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.
(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.
(Assignee)

Comment 55

6 months ago
I don't have anything to add to comment 54
Flags: needinfo?(kmaglione+bmo)
(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?
status-firefox61: fixed → verified
Flags: needinfo?(ciprian.georgiu) → needinfo?(bugspam.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
Flags: needinfo?(bugspam.Callek)
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.
Status: RESOLVED → VERIFIED
status-firefox62: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.