Closed Bug 1506102 Opened 6 years ago Closed 5 years ago

English is available in the main dropdown but only applies to Fluent elements

Categories

(Firefox :: Settings UI, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 67
Tracking Status
relnote-firefox --- -
firefox65 --- wontfix
firefox66 --- verified
firefox67 --- verified

People

(Reporter: flod, Assigned: mstriemer)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Simple scenario: take an Italian build and enable intl.multilingual.enabled

At this point English ("Inglese (Stati Uniti)") will be available in the dropdown, but it can only translate Fluent parts without a language pack.

I'm not exactly sure what a solution could be for this, besides hiding en-US until we fully migrate to Fluent, in lack of a language pack?
So it's listed in `Services.locale.availableLocales`, but it isn't _entirely_ available?
Priority: -- → P3
I discussed this with Zibi and it seems like we might need to explicitly check if the extension for English is installed to include it in available. If the extension isn't installed then it is just the fluent fallback strings that are available.

Flod, this doesn't break your install right? You'll get mixed English/Italian but you can't remove Italian and brick your profile?
Flags: needinfo?(francesco.lodolo)
On my Italian build, both English and Italian are not removable in the UI, so I can't brick the browser.
Flags: needinfo?(francesco.lodolo)
I verified that it's only packaged `en-US` that can exist.

One way to filter it would be to do 
```
// Fluent packages last fallback locale (en-US) as a fallback
// for any packaged locale.
// Since this only provides last fallback locale for Fluent,
// we want to filter out the locale from available locales in
// this UI until Fluent transition is complete.
let locales = Services.locale.packagedLocales;
let lastFallbackLocale = Services.locale.lastFallbackLocale;
if (locales.length > 1) {
  locales = locales.filter(loc => loc != lastFallbackLocale);
}
```

Any chance that we could reprioritize this bug? It would be nice to have this fixed in 66, since we're already starting to see bug reports.

Flags: needinfo?(sescalante)

One more note (that I didn't realize): even if you want, you can't install a full en-US package from the dialog.

I assume that's because the code thinks you already installed the en-US language pack, so en-US is not listed on the Add more languages.

Assignee: nobody → mstriemer
Priority: P3 → P1
Attachment #9040810 - Attachment description: Bug 1506102 - Don't count en-US as installed when just fluent is included r?zbraniecki → Bug 1506102 - Don't count lastFallbackLocale as installed when just fluent is included r?zbraniecki
Pushed by mstriemer@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e785008a884f
Don't count lastFallbackLocale as installed when just fluent is included r=zbraniecki,Gijs
Pushed by mstriemer@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0379792adfbb
Don't count lastFallbackLocale as installed when just fluent is included r=zbraniecki,Gijs
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67

Tested on nightly with intl.multilingual.enabled enabled.

Italian build: 67.0a1 (2019-02-13) (64 bit)

No language pack installed: en-US not available in the the list.
With en-US language pack installed: en-US is available in the list.

English (en-US) build: 67.0a1 (2019-02-13) (64 bit)

No language pack installed: en-US is available in the the list.

Status: RESOLVED → VERIFIED
Flags: needinfo?(sescalante)
Flags: needinfo?(mstriemer)

Comment on attachment 9040810 [details]
Bug 1506102 - Don't count lastFallbackLocale as installed when just fluent is included r?zbraniecki

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

None

User impact if declined

Users see en-US listed as an option to switch to, but only a small part of the browser will be translated (covered by Fluent). This patch only shows en-US as an option if there's a full language pack installed on the system, and allows users to install en-US like any other language.

Is this code covered by automated tests?

Yes

Has the fix been verified in Nightly?

Yes

Needs manual test from QE?

No

If yes, steps to reproduce

List of other uplifts needed

None

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

It provides a less confusing experience for users, but doesn't make any actual change to existing settings. The downside is that we should note this change in Release Notes, to make sure people understand why en-US is suddenly not available by default in the dropdown.

String changes made/needed

None

Attachment #9040810 - Flags: approval-mozilla-beta?

Comment on attachment 9040810 [details]
Bug 1506102 - Don't count lastFallbackLocale as installed when just fluent is included r?zbraniecki

Fix for a confusing l10n issue, verified in nightly.
Let's uplift for beta 8.

Attachment #9040810 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

There are conflicts while uplifting to beta:

warning: conflicts while merging browser/components/preferences/in-content/tests/browser_browser_languages_subdialog.js! (edit, then use 'hg resolve --mark')

:mstriemer , can you please provide a patch for beta?

Flags: needinfo?(mstriemer)

Looks like bug 1518932 and bug 1514594 touched that file in the meantime, but I guess only the first one would be relevant for a conflict
https://hg.mozilla.org/mozilla-central/diff/c1032d34b5e0/browser/components/preferences/in-content/tests/browser_browser_languages_subdialog.js

Verified also on 66.0b8 (64 bit): English is not listed, and I can download the language pack for it.

I see the relnote-firefox flag is already set. Feel free to drop it if you think it's not significant enough to point out.

The idea is that we were showing en-US in the list, but:

  • It would only translate part of the UI (roughly 15%)
  • It prevented users from downloading a full language pack for en-US

Now we hide en-US, which might result in a blank dropdown if the user tried to switch to en-US in 65. Not sure how much detail we should provide in relnotes.

Possible text (in need of copy love):

Improved the experience for users who want to switch to the English (en-US) version of the browser from the browser settings.

Hello,

Confirming this issue as verified fixed in the 66.0b13(buildID:20190304101322) on Windows 10x64, 7x64, Ubuntu 18.04 and macOS 10.14.

67 is about to launch. At this point I think this can be dropped.

Regressions: 1554744
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: