1005927 - Switch Settings locale selection to a fallback chain list

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

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

Currently, UI language selection in Settings is a single value list.

Once bug 889335 lands, we would like to start moving towards a fallback chain model.

I prototyped how it might look like: http://labs.braniecki.net/i18n-ui/

Or, alternatively, one can look at MacOS or Windows since they use similar fallback chain lists.

I believe this is a bug for UX team.

Comment 1

[Stephany Wilkes]

Flagging Omega on Settings to give UX feedback here.

Comment 2

[Omega Feng [:Omega] [:馮於懋]]

ni? new UX owner Jenny.

Comment 3

[Jenny Lee]

Hello Zibi, a proposed tweak to your prototype: separate the selected languages from the list of languages (to select from). Please refer to current keyboard selection: Settings > Keyboards > Selected Keyboards. 
We still need to take list rearranging into account. Is there a targeting milestone for this?

Comment 4

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

Hi Jenny,

(In reply to Jenny Lee from comment #3)
> Hello Zibi, a proposed tweak to your prototype: separate the selected
> languages from the list of languages (to select from). Please refer to
> current keyboard selection: Settings > Keyboards > Selected Keyboards.

The UI for selecting keyboards separates the screen with the list of selected keyboards from the one where you enable them (by clicking on a checkbox).

The options in the "Add more keyboards" UI are not sorted and the options in the "Select keyboards" UI are not sortable.

Do you want to have similar separation for languages?


> We still need to take list rearranging into account.

Yes, we need three things that I don't see in keyboard selection:

 - list of selected options have to be sortable
 - list of available options must have sub-options (for specific dialects - see fr, fr-FR, fr-CA etc.)
 - list of available options should probably have a filter box - we expect to have up to 100 options

> Is there a targeting milestone for this?

No, we just landed necessary platform changes for Gecko 32 (bug 889335) and we have a bug filled for changing the l10n API to use it (bug 1005965).
This part is relatively straightforward.

Comment 5

[Jenny Lee]

(In reply to Zibi Braniecki [:gandalf] from comment #4)
 > Do you want to have similar separation for languages?
Yes. Since selecting language isn't something user would often come back and make changes to, separating the selected and selection keeps the screen clean.

>  - list of selected options have to be sortable
We can add rearrange icon on the list item of selected language so that user can rearrange them right on the spot (this rearrange feature is confirmed to land on 2.1).

>  - list of available options must have sub-options (for specific dialects -
> see fr, fr-FR, fr-CA etc.)

I think we can get rid of the parent option, so for fr, there won't be a "fr", just "fr-FR", "fr-CA". Based on your prototype, when user selects the parent option (say "fr"), the rest of the sub-options would disappear. However, the system still needs to know the preference for the 3 sub-options, so unless selecting the parent option means automatically selecting the 3 sub-options (and only the sub-options will appear on the selected page), we don't really need it.    

>  - list of available options should probably have a filter box - we expect
> to have up to 100 options

Adding a search field on top of the selection page should cover this part, it's the most efficient way for filtering purpose here. For users who prefers browsing over searching, I'm thinking of creating an extra field that will show a list of "most used language around your area" for quicker access (so if you are located in Taiwan, the items shown here would be Chinese traditional and English as it is the international language). See below for the page structure of selection page:

-------
< select languages
--------
search field
Section 1 - Most used languages around you (optional)
Section 2 -All languages

Comment 6

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

Thanks Jenny! I will get to work on that once we have the backend.

One more thing we have to keep in mind that in the future we will have locales that are available for the user to use, but are not yet loaded on the device. When user will select the locale we will download it and activate.

I was thinking about marking the locales that are not on the device by color or some icon.

Comment 7

[Sam Foster [:sfoster] (he/him)]

To summarize a conversation we just had: 

* User may have primary (prefered/native language) and secondary language selection. If an app (including system/keyboard) isn't localized for that primary language, we should fall back to the secondary. E.g. my native tongue is Welsh, but if no welsh translations/keyboard are available, use US English. En-us is my secondary language however, so if a regional app or page has been localized for welsh, prefer that over en-us. 
* Phones may ship with a short list of localizations, selected by the vendor as appropriate for that region. The marketplace hosts a full set of language packs. Once there is a network connection, we can download the list of available languages and offer the user the ability to install alternative primary/secondary languages
* Navigating to select a language is difficult if the UI is in a language you do not read. The FTE should provide a simple, guided way to make language selections.

Comment 8

[BMO Automation]

Firefox OS is not being worked on