Closed Bug 1469684 Opened 6 years ago Closed 6 years ago

Allow a user to switch to an installed locale

Categories

(Firefox :: Settings UI, enhancement, P2)

Product:
Firefox
Component:
Settings UI
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 63
Tracking Flags:
Tracking Status
firefox63 --- fixed

People

(Reporter: mstriemer, Assigned: mstriemer)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Keywords: feature)

Attachments

(7 files, 1 obsolete file)

Current Restart modal in preferences
559.39 KB, image/png
Details
Bug 1469684 - Allow switching between installed locales
59 bytes, text/x-review-board-request
jaws
: review+
flod
: review+
Details
switch-language-final-strings.mov
2.25 MB, video/quicktime
Details
Screenshot 2018-07-20 21.50.48.png
84.06 KB, image/png
Details
Screenshot 2018-07-17 11.00.43.png
63.30 KB, image/png
Details
multi-line-message-bar.png
42.99 KB, image/png
Details
Visual Studio Code langpack dialog
26.03 KB, image/png
Details 
If a user has more than one installed language pack they should be able to easily switch between them in preferences.

The installed (and active) languages can be accessed with `Services.locale.getAvailableLocales()`. 

The currently active languages can be accessed with `Services.locale.getRequestedLocales()`.

You can set the active languages with `Services.locale.setRequestedLocales()`.

Listing disabled language packs and enabling them when they are selected would likely be best, but maybe treat that as a follow up.
Priority: -- → P2
Attached video change-language.mov (obsolete) — 
Here's a video of how this currently looks. I haven't implemented the restarting yet but I think this is the direction we were planning on going?

Comments welcome.
The video looks great!

The only question I have is about the choice of what to show in the drop down, you do `Language (Country)`, I think I'd like to consider doing `Language (Country) [ab-CD]`. The added locale code is useful to recognize your language even if you somehow read it in a foreign one.

For example  `(الألمانيّة) ألمانيا` may be very hard to understand for a German person, but `[de] (الألمانيّة) ألمانيا` gives them a fighting change.
Great job here, Mark! It's always a pleasure to work with you.

I have feedback.

A) Restarting
For the restarting, I thought we're aiming for the same behavior we have when in history, you select the choice 'never remember.' See screenshot. 

The copy should be in the new language you select. 
>>> Restart Firefox to apply these changes. 
>>> [Restart] [Cancel]


B) Information Architecture
In this section we should order items as follow:
- Installed locale
- Webpages
- Spellchecking / Dictionaries 


C) Copy
The copy should follow the one in mock. @Mark, let me know which is the best way to provide the strings to you (.txt? google doc with the images close by? comment on invision? Oh my, so many different way!)


D)`Language (Country)`

Zibi, I don't think we should ever show 'German' written in not latin character. The name of the locale should be always written with the characters supported by that language. E.g. If I'm looking for Russian, this should be written in Cyrillic characters, not Latin.  This is also what wikipedia does to display the same page in different languages (like here: https://screenshots.firefox.com/8DLOQRfsrLxEHKGp/en.wikipedia.org)
> Zibi, I don't think we should ever show 'German' written in not latin character. The name of the locale should be always written with the characters supported by that language. E.g. If I'm looking for Russian, this should be written in Cyrillic characters, not Latin.

This is an interesting proposal. I know Wikipedia does it, but Android/Windows/MacOS/Linux/Chrome and current Firefox/Fennec show all locales in the current locale.

Technically we can do either, so I'll leave this decision to Flod and you.
Flags: needinfo?(francesco.lodolo)
Could be interesting if there is any previous research on this point. I'll investigate while we wait for Flod.
(In reply to emanuela [ux team] from comment #3)
> D)`Language (Country)`
> 
> Zibi, I don't think we should ever show 'German' written in not latin
> character. The name of the locale should be always written with the
> characters supported by that language. E.g. If I'm looking for Russian, this
> should be written in Cyrillic characters, not Latin.  This is also what
> wikipedia does to display the same page in different languages (like here:
> https://screenshots.firefox.com/8DLOQRfsrLxEHKGp/en.wikipedia.org)

You're raising a very good point. Putting aside technical blockers for a moment, that seems like the best way to go: showing language names with their native (localized) names.

P.S. Looks like the industry's name for this feature is "global gateway", it might give you better results.
Flags: needinfo?(francesco.lodolo)
We discussed with Emanuela, and decided to go with the following:

The languages in the dropdown list are localized in their native language, e.g. Deutsch for German, Italiano for Italian, etc.

The ISO country code is displayed between parentheses if relevant, otherwise it should be omitted:
- Only Deutsch for ‘de’
- Español (ES) for ‘es-ES’

See also
https://docs.google.com/document/d/1zqBRFVHKVeRI40JJtTNB1X34oE1WlhZyFKMFvQ-n-Ak/edit#

@zibi
Do you need a separate bug for providing such list via API?
Flags: needinfo?(gandalf)
Blocks: 1476781
Here's a video of how this works. You need to click the "Apply and Restart" button for the change to take effect.

I filed bug 1476781 to update the strings from "French" to "Français".
Attachment #8987214 - Attachment is obsolete: true
Adding reference doc with copy (:mheubusch) and workflow (:emanuela).
URL: https://docs.google.com/document/d/1z...
Comment on attachment 8993110 [details]
Bug 1469684 - Allow switching between installed locales

https://reviewboard.mozilla.org/r/257942/#review265460

r=me with the below two issues addressed.

::: browser/components/preferences/in-content/main.js:786
(Diff revision 1)
> +    for (let {code, name} of locales) {
> +      let menuitem = document.createElement("menuitem");

Please append these to a document fragment here, and then append the document fragment to the menupopup after the loop has finished.

::: browser/themes/shared/incontentprefs/components.css:15
(Diff revision 1)
> +  background-color: var(--grey-20);
> +  border-radius: 4px;
> +  color: var(--grey-90);
> +  min-height: 32px;
> +  padding: 0 4px;
> +  text-align: center;

Please left (start) align the change-description text, and right (end) align the change-button.

Centered text and buttons aren't consistent with other preferences UI.
Attachment #8993110 - Flags: review?(jaws) → review+
The restart dialog close to the listbox definitely works for me but, just to be sure, did you clear it with Emanuela?

I assumed we were going to use existing dialogs, e.g. https://searchfox.org/mozilla-central/source/browser/components/preferences/in-content/preferences.js#342
Flags: needinfo?(gandalf)
I ran the banner past Emanuela, and we figured we'd give it a shot. She mentioned that the centred text was the new direction for banners, but buttons on the right does fit with preferences better.

Emanuela, how does this look?
Flags: needinfo?(emanuela)
(In reply to Mark Striemer [:mstriemer] from comment #13)
> I ran the banner past Emanuela, and we figured we'd give it a shot. She
> mentioned that the centred text was the new direction for banners, but
> buttons on the right does fit with preferences better.

Can you add a screenshot of what happens to the layout if the message wraps on two lines?
@Flod: this is how it looks with two lines. And keep in mind in this screenshot it's still missing the 'Set Alternatives...' button
Unfortunately, the current CSS doesn't have a real good line-height, so mstriemer and I took this decision. 

The UI is behind a pref, so I think we can take the risk and try something slightly different (a.k.a. the message bar and then the buttons below the description). If we realize it doesn't work, we can always go back.
Flags: needinfo?(emanuela)
Here's the message bar with a multi line string. I couldn't figure out how to get the XUL box to flex wrap to have the button on the next line. Hopefully I can figure that out though
Comment on attachment 8993110 [details]
Bug 1469684 - Allow switching between installed locales

https://reviewboard.mozilla.org/r/257942/#review265912

::: browser/themes/shared/incontentprefs/components.css:9
(Diff revision 3)
> +  --grey-90-a10: rgba(12, 12, 13, 0.1);
> +  --grey-90-a20: rgba(12, 12, 13, 0.2);
> +  --grey-90-a30: rgba(12, 12, 13, 0.3);
> +}
> +
> +.message-bar {

toolkit/themes/shared/in-content/common.inc.css is the right place for shared components, please move the message-bar css there.
@mark
According to UX specs, restart messages after switching language should be displayed in both languages (current and selected), not just in the current one. Just double checking: are there any technical blockers preventing us from doing it?

I also think that copy still needs to be finalized for the restart message?

@emanuela
I have one concern about undoing the language switch. The initial proposal was to use the same dialog that shows up, for example, when you change the history settings: that dialog has both a restart button, and an Undo.

The user can still undo the change by restoring the language in the dropdown, but it doesn't seem intuitive. Possible solutions:
1) Leave it as is
2) Add an undo link or button to the current message
3) Rephrase the message to explain that it's possible to change back the language in the dropdown if the change was a mistake

I think #2 would be the best solution, in form of an Undo button in that dialog. Space might be a bit of a concern though.

What do you think? I'd fully thrust your choice here ;-)
Flags: needinfo?(mstriemer)
Flags: needinfo?(emanuela)
After reading the thread, I'm wondering if we should continue to pursue the message bar.

I'm wondering if this is taking too much time for this iteration, considering we're struggling to get it right  (comment #18) and there are some changes we need to implement:

- Include a 'Don't Apply' cta
- Move from the generic message bar to the warning one (yellow)

Mark, let me know your thoughts.
Flags: needinfo?(emanuela)
We could display two messages, personally I don't see the purpose. A "Don't Apply", "Revert" or "Cancel" button in the user's current language makes sense to me. I'm not sure how much sense it makes to mix languages in a single message bar, but it seems to make sense to me.

Both languages seems odd to me since if I see a message in my current language "Restart to apply" and I click "Restart" then I'm not sure restarting in a different language would be expected, especially if there was another message bar that I didn't understand right beside it.

I don't think the message bar is blocking so I'll go ahead and merge this and file an issue to follow up on the specific details of it.
Flags: needinfo?(mstriemer)
For what it's worth, this is a dialog in Visual Studio Code, suggesting to install the Italian language pack.
Depends on: 1479013
Blocks: 1479013
No longer depends on: 1479013
hg error in cmd: hg push -r tip ssh://hg.mozilla.org/integration/autoland: pushing to ssh://hg.mozilla.org/integration/autoland
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 6 changes to 6 files
remote: 
remote: ************************ ERROR *************************
remote: You are trying to commit a change to an FTL file.
remote: At the moment modifying FTL files requires a review from
remote: one of the L10n Drivers.
remote: Please, request review from either:
remote:     - Francesco Lodolo (:flod)
remote:     - Zibi Braniecki (:gandalf)
remote:     - Axel Hecht (:pike)
remote:     - Stas Malolepszy (:stas)
remote: ********************************************************
remote: 
remote: transaction abort!
remote: rollback completed
remote: pretxnchangegroup.mozhooks hook failed
abort: push failed on remote
Since you're touching FTL files, it needs a r+ from l10n-drivers. 

I didn't r+ because I understood you were waiting for the final copy for that restart dialog, but I guess that's not the case anymore. In general, I'd really prefer to land approved copy, because changing it later it's painful.
Comment on attachment 8993110 [details]
Bug 1469684 - Allow switching between installed locales

https://reviewboard.mozilla.org/r/257942/#review265466
Attachment #8993110 - Flags: review+
I confirmed the copy is good as is with Michelle.
Pushed by mstriemer@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ff16973184c0
Allow switching between installed locales r=flod,jaws
https://hg.mozilla.org/mozilla-central/rev/ff16973184c0
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox63: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
Depends on: 1479377
> +confirm-browser-language-change-description = Restart { -brand-short-name } to apply these changes

Something tells me this string requires a trailing period, as it is instructive (also see the 2018-07-20 21.50.48 screenshot). Could it have slipped through?

Please remember trailing periods are (also) important info for localizers in order to be (almost) sure a string is instructive, causing them to use different verbs/moods/word order. In some cases they may consider a string to be an option/menu text instead, resulting in errors and inconsistencies.

Side note: please note that currently some strings starting with "Choose" exist in preferences that do, and others that don’t use trailing periods as a result of various changes, causing inconsistencies described. It would be good to see them addressed while reworking these strings/sections.
(In reply to Ton [:Tonnes] from comment #31)
> Something tells me this string requires a trailing period, as it is
> instructive (also see the 2018-07-20 21.50.48 screenshot). Could it have
> slipped through?
> 
> Please remember trailing periods are (also) important info for localizers in
> order to be (almost) sure a string is instructive, causing them to use
> different verbs/moods/word order. In some cases they may consider a string
> to be an option/menu text instead, resulting in errors and inconsistencies.
> 
> Side note: please note that currently some strings starting with "Choose"
> exist in preferences that do, and others that don’t use trailing periods as
> a result of various changes, causing inconsistencies described. It would be
> good to see them addressed while reworking these strings/sections.

At this point I don't think there's agreement on "period = declarative, no-period = imperative". I'm not sure we can even all agree on the fact that a specific element is descriptive or imperative.

I've been searching for a while by now, and couldn't find anything to support that (happy to be proven wrong), while there's plenty of documents stating that "both declarative and imperative should end with a period". This is also software, and doesn't always follow rules used for prose.

Having said that, consistency should be definitely a goal. Also, the specs had a trailing period, and nobody noticed it was missing in the code.
(In reply to Francesco Lodolo [:flod] from comment #32)
> Having said that, consistency should be definitely a goal. Also, the specs
> had a trailing period, and nobody noticed it was missing in the code.

Ignore this, I thought the period was missing in the "Choose…" message.

As for the "Restart Firefox to apply these changes", I'm not sure there should be a period in this kind of notification, but we also don't have a lot of these. This message went through copy and mock-up as it is (without a period), in case we'd need copy's opinion.
The general mocks for message bars [1] don't include periods and there is a blurb on when to include periods in the Copy section [2], which generally says "use periods in body copy."

[1] https://design.firefox.com/photon/components/message-bars.html
[2] https://design.firefox.com/photon/copy/punctuation.html#periods-and--other-terminal-punctuation
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: