+++ This bug was initially created as a clone of Bug #1469688 +++ We ported this functionality to Thunderbird in bug 1487987. While testing the patch for Thunderbird I noticed these issues (from bug 1487987 comment #2): At first, the alternatives show only en-US, only if you apply a language pack will it appear under alternatives. Why don't all installed language packs always show up under alternatives. I've chosen DE, FR and en-US as primary languages, one after the other. They now show under alternatives, ES still doesn't show since I never applied it. [The alternatives windows opens too small after a restart, you can't see the buttons. (I haven't tried that in FF, maybe not an issue.)] When I restart the session after changing the alternative, I get this in the debug console: JavaScript error: resource://gre/modules/L10nRegistry.jsm, line 207: TypeError: L10nRegistry.sources.get(...) is undefined, can't access property "hasFile" of it JavaScript error: , line 0: uncaught exception: undefined Further from bug 1487987 comment #4: ..., when you disable the language packs they are no more shown in the menulist, but still in the Alternatives dialog. And when you change the language in the dialog and restart, the menulist is empty.

(In reply to Jorg K (GMT+2) from comment #0) > At first, the alternatives show only en-US, only if you apply a language > pack will it appear under alternatives. > Why don't all installed language packs always show up under alternatives. > I've chosen DE, FR and en-US as primary languages, one after the other. They > now show under alternatives, ES still doesn't show since I never applied it. The problem is that the dialog is still incomplete. It doesn't help that a similar discussion was in the Phabricator review, but not reflected in the bug. https://phabricator.services.mozilla.com/D3137 This dialog lists the "Requested locales", not "Available locales". When you select a locale in the main dropdown, you're adding it to requested locales, and set it as first in the fallback chain. When you install a language pack, you're only adding it to the available locales. This dialog is missing another dropdown, under the list, to be able to add: a) locales provided by local language packs to requested locales b) language packs from AMO I assume Mark would address both in bug 1469696. > [The alternatives windows opens too small after a restart, you can't see the > buttons. (I haven't tried that in FF, maybe not an issue.)] Can't reproduce this on Nightly. > When I restart the session after changing the alternative, I get this in the > debug console: > > JavaScript error: resource://gre/modules/L10nRegistry.jsm, line 207: > TypeError: > L10nRegistry.sources.get(...) is undefined, can't access property "hasFile" > of it > JavaScript error: , line 0: uncaught exception: undefined I don't see this, not sure if it depends on the language pack (tried fr and es-ES). > Further from bug 1487987 comment #4: > ..., when you disable the language packs they are no more shown in the > menulist, but still in the Alternatives dialog. I believe that's expected, because requested locales can have values that are not available in available locales. Once a language becomes available, it will be used. > And when you change the language in the dialog and restart, the menulist is empty. I lost you here. Once a language pack is disabled, it doesn't show in the main dropdown, but remains in the "Set alternatives…" dialog. Where do you change the language, if it's not listed anymore?

(In reply to Francesco Lodolo [:flod] from comment #1) > (In reply to Jorg K (GMT+2) from comment #0) > > When I restart the session after changing the alternative, I get this in the > > debug console: > > > > JavaScript error: resource://gre/modules/L10nRegistry.jsm, line 207: > > TypeError: > > L10nRegistry.sources.get(...) is undefined, can't access property "hasFile" > > of it > > JavaScript error: , line 0: uncaught exception: undefined > > I don't see this, not sure if it depends on the language pack (tried fr and > es-ES). This is seen on in debug build. > > Further from bug 1487987 comment #4: > > ..., when you disable the language packs they are no more shown in the > > menulist, but still in the Alternatives dialog. > > I believe that's expected, because requested locales can have values that > are not available in available locales. Once a language becomes available, > it will be used. > > > And when you change the language in the dialog and restart, the menulist is empty. > > I lost you here. Once a language pack is disabled, it doesn't show in the > main dropdown, but remains in the "Set alternatives…" dialog. Where do you > change the language, if it's not listed anymore? In the sort dialog you can move a disabled locale to the top. Then FX shows the restart button. After the restart the menulist is empty.

> In the sort dialog you can move a disabled locale to the top. Then FX shows > the restart button. After the restart the menulist is empty. Thanks, I can reproduce that (when a locale not available is set as first in requested locales, we display an empty value in the main dropdown).

Thanks, and please try a debug build to see whether you can spot the JS error when restarting and after making adjustments in the panel.

Do we need to track this for 63?

(In reply to :Gijs (he/him) from comment #5) > Do we need to track this for 63? I think so, even if 63 is only our target for testing the feature with QE. @zibi Can you take a look at the error in L10nRegistry.jsm?

[Tracking Requested - why for this release]: See comment #6

Assigning this 63-tracked-bug to gandalf as per comment 6.

(In reply to Jorg K (GMT+2) from comment #0) > When I restart the session after changing the alternative, I get this in the > debug console: > JavaScript error: resource://gre/modules/L10nRegistry.jsm, line 207: > TypeError: > L10nRegistry.sources.get(...) is undefined, can't access property "hasFile" > of it > JavaScript error: , line 0: uncaught exception: undefined I can no longer observe this in a debug build of today (20180915154027). Disabling/removing language packs is covered in bug 1488442 So I guess we can close this now.

Zibi, do you have a status update for 63?

Pascal: since this is a behind-the-pref feature which we're not planning to enable in 63 (or even 64), is there any reason to investigate this for 63?

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #11) > Pascal: since this is a behind-the-pref feature which we're not planning to > enable in 63 (or even 64), is there any reason to investigate this for 63? It was planned for 63 for QA, since this is now delayed to 64/65 we no longer need to track it for 63. Flags adjusted to reflect the current status of this feature wrt to our Firefox releases.