Fennec should allow users to determine the language in which they would like to view web content, just as they're able to do in Firefox desktop. The W3C Internationalization (i18n) standard for language negotiation using the Accept-Language request-header when determining the localization of a website to download from the site's server would be a good option for how to approach this task. In addition, ECMAScript offers another possibility within section 9 of their (i18n) API (http://www.ecma-international.org/ecma-402/1.0/ECMA-402.pdf). Use case: User downloads Fennec in Spanish but would prefer to be directed to websites in Catalan when surfing on their phone.

Setting intl.accept_languages in about:config should work in Firefox for Android just as desktop. The pref is a string of comma delineated locale codes. Does this work for you?

Resummarizing to clarify the intent. We'd like to have a UI that allows users to express their intent in website languages on Firefox for Android. There's pretty horrible UI on desktop, so I wouldn't frame this as "parity with desktop". We should do better, which shouldn't be impossible. I don't have a concrete proposal, but we'll want some UI that makes the 250+ options we have from intl OK to use.

Irina, are you a good candidate to ask what other mobile browsers allow in customization of the accept-languages header? Notably, android stock, android chrome, iphone safari?

(In reply to Kevin Brosnan [:kbrosnan] from comment #1) > Setting intl.accept_languages in about:config should work in Firefox for > Android just as desktop. The pref is a string of comma delineated locale > codes. Does this work for you? this option doesn't really work for users. it depends on users knowing a list of arcane language codes and getting the list right for specifying the order of preferred languages. that's mostly why desktop has UI for this. this article explains how this feature and the web standard is intended to work for both users and website developers. In my mind its ok to try and lead with some improved UI that can lead, but if not its more important that we find a way for non-english speakers to get access to the wealth of content that is out there and can be access if mobile browser start send the right information to sites, and user can set up their language preferences for content.

FYI, I just played around with the android simulator for 4.2.2 and stock browser: There doesn't seem to be a an option to set your content language prefs, and the browser sends ui-locale, en-US as accept-lang, tested german and catalan. Notably, catalan sends "ca-ES, en-US", and doesn't mention Spanish.

Hi, the approach I would love is having a really simple language list option which could change at the same time: * UI language * Accept-header language preferences (as defined in intl.properties for each Mozilla locale) If there is not an available translation in the build, it would simply change the latter. IMVHO, a good model is Mac OS X language selection. If I'm not wrong, Firefox for Android is taking into account Android preferences. I would not be surprised if some presently shipped languages may be actually being excluded in some terminals. Of course, apart from what I comment above, there could be a more advanced option (à la Firefox Desktop) for those very few people (and developers) who may be interested in fine-tune their preferences. My 2 cents!

UI language selection is outside of the scope of this bug, please don't distract the conversation here.

(In reply to Axel Hecht [:Pike] from comment #8) > UI language selection is outside of the scope of this bug, please don't > distract the conversation here. I don't think I'm distracting here. Please, re-read my message. As you also point in comment 2, I'm concerned that resulting option may end up being ineffective for presently affected user. Do I understand from your comment that UI language (which might not be available in the shipped build) and accept-header language preferences might not be linked as I suggest? Thanks in advance!

Hi everyone, here is a proposed design to support users who want to customize their preferred web content language. As you can see our updated Settings UI lends itself quite nicely to supporting this kind of feature (yay!). The key part of this design was trying to make choosing from a list of 250+ languages a little easier to digest. To do that, I set up a step where users choose their region first, and after that they are presented with a list of languages specific to that region -- it could still be somewhat long for certain parts of the world, but certainly much more manageable than one long list.

a couple of thoughts. the devil is in the details when trying to bind languages to regions. there are some languages, in some regions, where some governments expressly prohibit the acknowledgement and use of some languages, or in some cases places that require pairs or groups of languages if one language is offered. e.g. see http://en.wikipedia.org/wiki/Kurdish_language and http://en.wikipedia.org/wiki/Official_bilingualism_in_Canada for the first of a very long list we could generate. How do we comply with local laws and norms, yet provide choice when we have them in certain logical regions, and avoid problems if we don't have the locale to offer? The closer we get to associating a language to regions and countries the more intense these problems become. then we also have cases like Spanish where its spoken around the world. that problem is a bit easier to solve by living with a bit of duplication. a variety of other issues also exist. We have taken a crack at some language groupings in https://docs.google.com/spreadsheet/ccc?key=0Aru_NzvpgGcgdGFBRUtYMEp5Wm82TGQtR0Nkb3VsbEE#gid=0 but found it really hard.

My thoughts: This looks good from a flow perspective, but yeah, region -> language seems like it's missing something. There are more than 200 languages spoken or read in California alone; presenting those in a scrollable list pretty much requires excluding and confusing some users. There were some great suggestions in one of the l10n panels that Jeff ran at the Summit in Toronto. Some concepts I can remember (Jeff, please add more!): * Tying languages directly to regions (and making that your only navigation approach) is bad... but suggesting languages based on (region, OS/app language) is smart. E.g., if you're in Barcelona, with a phone set to es_ES, we should bias our additional list in favor of Catalan (ca_ES). The important part is that this is a starting point, not the only way to find a language. * Similarly, we know the sites you visit. That could be a start on suggesting a language, either in a sophisticated way (looking at content, headers, web-level statistics) or a rudimentary way (visit a lot of .ru sites? Maybe we should suggest Russian!). * The main body of the discovery should probably be search, matching against both native script/name and English descriptors. So perhaps a screen like: [ Can Firefox use your location? ] [ [ ] ] => ---------------------------------- | ADD LANGUAGE | | Based on your location … | | English / US | | English / GB | | Español / México | | | | or search by name: | | [ es| ] | | Español / México | | Español / Costa Rica | ----------------------------------

Chris, Axel showed me this earlier, which looked to be a fairly comprehensive list of languages and their respective continents of use -- https://github.com/wikimedia/jquery.uls/blob/master/data/langdb.yaml (notice I said continents, not more specific regions than that; would that get around the specific country laws to which you are referring?) Richard (or Jeff), can you provide a little more explaination as to why "tying languages to regions is bad"? For the record, I'm not proposing we list *every single* language that is spoken in a region to that region, but rather the dominant languages of that area -- see the link I pasted above. To that end, I agree that providing the option to search and quickly filter the list would be a useful addition. Getting into location services and tracking where people visit to make language recommendations starts to feel a little gimmicky / creepy though -- for a preference users will likely set only once, I would be more inclined to err on the side of simplicity: selecting an additional language via search and/or region.

(In reply to Ian Barlow (:ibarlow) from comment #13) > Chris, Axel showed me this earlier, which looked to be a fairly > comprehensive list of languages and their respective continents of use -- > https://github.com/wikimedia/jquery.uls/blob/master/data/langdb.yaml (notice > I said continents, not more specific regions than that; would that get > around the specific country laws to which you are referring?) > > Richard (or Jeff), can you provide a little more explaination as to why > "tying languages to regions is bad"? For the record, I'm not proposing we > list *every single* language that is spoken in a region to that region, but > rather the dominant languages of that area -- see the link I pasted above. > > To that end, I agree that providing the option to search and quickly filter > the list would be a useful addition. Getting into location services and > tracking where people visit to make language recommendations starts to feel > a little gimmicky / creepy though -- for a preference users will likely set > only once, I would be more inclined to err on the side of simplicity: > selecting an additional language via search and/or region. See chofmann's comment above. Language can often be as volital of a political issue as determining a sovereign state's boundary lines. In addition, some languages are not entirely region-specific (e.g., chofmann's Spanish example). Richard, looking over the notes, you seem to have nailed all of of the options discussed. One reccommendation was to use the wikipedia, region-based list of languages, but I'm not really in favor of that because of the language grouping issues that have already been mentioned. I'm more in favor of the search approach, but could be persuaded to combine an auto-detected, region-based list of suggestions approach that doesn't limit selection exclusively to that region should the user enter in a language that lies outside of that region.

(In reply to jbeatty from comment #14) > See chofmann's comment above. Language can often be as volital of a > political issue as determining a sovereign state's boundary lines. In > addition, some languages are not entirely region-specific (e.g., chofmann's > Spanish example). Yep, totally get both of those points. My question to Chris was about whether this volatility becomes less of a problem in the case of my designs, where the regions are defined by *continents*, and not countries? I absolutely appreciate the issue you are calling out, I am just trying to understand if it is actually an issue for the designs I am proposing, where the map is far less granular. As for your second point about not all languages being region-specific, the link I posted in comment 13 (https://github.com/wikimedia/jquery.uls/blob/master/data/langdb.yaml) shows many languages that are tagged with more than one region, which is very much how I imagined this working in our language settings as well -- that some languages would appear in more than one area of the map.

> My question to Chris was about whether this volatility becomes less of a problem in the case of my > designs, where the regions are defined by *continents*, and not countries? It probably does a bit, but I think we will still see a few problems. As the map becomes far less granular it also becomes less effective in reducing complexity and results in the need to show long lists. for example in the langdb.yaml file they reduced the map to 7 regions, with the distribution looking something like 185 EU] Europe 146 AS] Asia 59 AF] Africa 53 AM America 38 ME] Middle East 21 PA] Pacific Asia 12 WW] World Wide We aren't going to get to the extreme numbers of the list above since we have about 80 languages not the 250 supported by wikipedia but the distribution pct. is going to be roughly the same where there are intense language regions and other regions with dramatically fewer languages in use. This list raises a variety of usability issues. Is looking at a list of 80 languages much different than a list of 50 or 60?, or 30? At what point does the list become easier to look at? Also what happens for user at the edges of these regions. If I'm from Turkey do I look for my language under the middle east because of my association of geography, or under Europe because of the affiliation with the EU? There are a number of balkan, nordic, and former USSR countries that struggle with these kind of affiliations. Navigation into the regions to find languages like this either becomes difficult because the lists get longer if we add them in both places, or is difficult because user need to bounce up and down into regions searching for there language. This is why the search options or one long list get attractive v. a regional directory hierarchy.

(In reply to chris hofmann from comment #16) > We aren't going to get to the extreme numbers of the list above since we > have about 80 languages not the 250 supported by wikipedia … Bear in mind that this particular bug is about Accept-Language selection, rather than UI selection (another problem that we're going to tackle soon). I might be wrong, but I would expect Accept-Language to encompass the entire set of values, not just those for which a Firefox UI lang was available — that I'm forced to use en_GB for my UI doesn't mean I shouldn't be able to specify en_IN for my preferred web page language. As far as I can tell, there are 184 primary ISO-639-1 codes (en, es, etc.), ignoring the country code suffixes, so we certainly could (should?) be attempting to handle that entire Wikipedia list, if not more!

One quick thought about searching languages (and the list in general): 1) Am I supposed to search for Croatian or Hrvatski? I hope the second. 2) How do I search for 中文 (简体) if the keyboard is set to English? Maybe the solution could be to expose a string like "Hrvatski (Croatian) [hr]" and make it completely searchable. Another point emerged in a similar session in Brussels: which criteria can I use to order the list of available languages? Geolocation, even if creepy, was one of the suggestions.

The UI challenge is how to pick a locale from a huge list (+200 items). IMVHO, Breaking locale list in regions is not a good approach. Because each list is long too, it's not usable. So, the UX will remain bad and new non-tech problem will arise: mapping languages to regions. Major websites use a single list of languages. Wikipedia is the best know sample. Facebook website approach is very interesting (~50 languages). It suggests an initial 10 language list and provides link to language lists (all languages and 5 region based list). It should be considered that Accept-language header customization is very-low-used feature. Many users never used it, because default Accept-language header based in UI locale is good. Probably, header customization will be done once by users witch need such feature. So, I think the best approach for Firefox Android is: 1.- Suggest an small initial list (up to 10 languages) based on geolocation and browser history. 2.- Provide a link to a single full language list. Avoiding language to region mapping. 3.- Such full list should provide some autocomplete feature, to improve UX.

Amir said there's work on the mobile version of the wikimedia ULS, I have a hard time finding that UX though. A few thoughts that I think we cat "reuse": Search works in all languages. i.e., you can search for Russian in Greek. At least the desktop version really only selects the vertical bands of regions. I think that avoids a lot of trouble. I would expect search to be the primary entry point in the UX, and global region to merely serve as a filter for what is searched in. Not sure how the UX feels with a keyboard open, maybe there's no screen estate for a map. At least on phones. I suspect we can be richer on tablets.

Thanks for the feedback everyone, all great points and it sounds like we actually already had a pretty clear idea of how we envisioned this feature working :) Attached is an updated interaction flow that should have everything needed to get a basic implementation started. You'll see that instead of browsing by region, the user is now presented with the option to search, *or* choose from a list of suggested languages based on some combination of data we analyze (OS locale, browsing history, etc). There is also an escape hatch to browse the full list of languages, should users find themselves in a position where neither search nor suggestions are giving them what they want.

since we want to promote the idea that a user can provide/develop a prioritized list of languages should we enable an easy way for the user to view that? The feature is intended to set up background communication to websites that reflect the user preference like this example: I prefer to see Catalan content when I visit websites, if that's not available I'd prefer Spanish, and if that's not available fall back to English. Sorry we didn't make that more explicit with a comment in the bug, but there is more on this in the document linked to in comment 5.

Reading bug 924461 comment 2 (ordering of search engines), the grippy indicates that you can drag around to change the order?

(In reply to Axel Hecht [:Pike] from comment #23) > Reading bug 924461 comment 2 (ordering of search engines), the grippy > indicates that you can drag around to change the order? Yes, that's correct.

(In reply to Francesco Lodolo [:flod] from comment #18) > One quick thought about searching languages (and the list in general): > 1) Am I supposed to search for Croatian or Hrvatski? I hope the second. > 2) How do I search for 中文 (简体) if the keyboard is set to English? > > Maybe the solution could be to expose a string like "Hrvatski (Croatian) > [hr]" and make it completely searchable. > yeah, I think this needs to be a requirement of the implementation. We can't solve item 2 above, but we can make the list searchable in english and whatever native language served by the current keyboard.

(In reply to chris hofmann from comment #22) > since we want to promote the idea that a user can provide/develop a > prioritized list of languages should we enable an easy way for the user to > view that? Ian's mocks offer this: the "Languages" window (prior to "Add a language") shows a sorted list, arranged by preference. Do you mean that this needs to be more obvious?

Ian's mocks is a great approach. Only a little remark. How do you reset Accept-lang header to default? Currently, the Accept-lang header is *dynamically* generated. If you change OS locale, the Firefox header changes too. So, in Language window it could be added a checkbox enabling customized language list (or disabling). Something like: ------------------------------------- Websites are somtetimes.... [ ] Default list, OS Language based. LANGUAGES ------------------------ English/United States :: [en-us] ------------------------ English :: [en] ------------------------ If checkbox is marked, then language list disabled and there is no custom header. Another approach is provide a "Reset to default" button. But I could be confusing, because deafault header is dynamic, what do you put in language list? Another approach could be generate a fake language "Default, OS based", and add it to first suggestions list.

Agreed, but don't tie it to OS language, as we want to break that tie going forward.

(In reply to Axel Hecht [:Pike] from comment #28) > Agreed, but don't tie it to OS language, as we want to break that tie going > forward. Good point, change the string of checkbox, :)

Ok, last set of flows and we should be good to start building this. I made a few changes to the main Language screen, to give users the option to restore the default settings if they want to.

(In reply to Ian Barlow (:ibarlow) from comment #30) > Created attachment 817865 [details] > ffxandroid-acceptlanguageheadercustomization-131016.png > > Ok, last set of flows and we should be good to start building this. I made a > few changes to the main Language screen, to give users the option to restore > the default settings if they want to. Ian, I'm a fan! Looks great from my perspective. Only want to reiterate Axel's comment for implementation of this about ensuring that this lang selection is not tied to the OS lang system preferences. Any chance some of this UX approach could be leveraged for https://bugzilla.mozilla.org/show_bug.cgi?id=917480 ?

(In reply to Ian Barlow (:ibarlow) from comment #30) > Created attachment 817865 [details] > ffxandroid-acceptlanguageheadercustomization-131016.png > > Ok, last set of flows and we should be good to start building this. I made a > few changes to the main Language screen, to give users the option to restore > the default settings if they want to. My only tweak would be to state which is default since that isn't obvious (even to us, we assume what's at the top of the list is default but I like to be explicit where I can). My two cents, although would be consistent with how we handle our search list (ie we say that the top one is default).

(In reply to Karen Rudnitski [:kar] from comment #32) > My only tweak would be to state which is default since that isn't obvious > (even to us, we assume what's at the top of the list is default but I like > to be explicit where I can). My two cents, although would be consistent with > how we handle our search list (ie we say that the top one is default). Maybe we indicate that in the second line, next to the language abbreviation. So for example, ------------------------------- English/United States [en-us] [default] -------------------------------

yep, that would be consistent with how we show it in the search list. That would make me feel better :)

On the sixth when users type to filter will it be intuitive that they need to tap the language to add it to the list? would a radio button or "+" button next to the language name, or instruction "tap language to add" help there, or do we think something like this is not needed. Also if a user makes a mistake and enters a selection they don't want, how and where might they delete a language from the list of selections? If I grab one of the languages on screen 3 then swipe it off the screen I might expect that it would be removed from the list. Is that a common metaphor or should we add something else that makes the steps to remove more clear?

I like the UX, I got a few devil-n-details questions: should we show the languages in their native name, i.e. Francais on an English and German UI? I personally think that makes sense. You're able to read the language anywho, right? should we hide languages that are already in our accepted language list? should we only show [default] if the language is at the position it is in in the default set? And most ughly, we haven't talked about en-US vs en-GB vs en, zh-CN vs zh-TW vs zh-HK at all yet. For desktop, we have this list to show which languages we show with variations of regions, and if so, which: http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/language.properties I guess we need something similar for this, too?

I like the proposed interaction. more questions: I had the same thought Pike had. If we show languages in their native name, we must be able to type them to look them up. Maybe the keyboard won't allow users do this? hiding languages that are already in use might be good to make it less error prone. in any case, do you think that having the word "default" next to the language on top makes users think that this is not an ordered list, but a set?

Some thoughts about this were in comment 18 (exposing both English/localized names, make them searchable).

(In reply to chris hofmann from comment #35) > On the sixth when users type to filter will it be intuitive that they need > to tap the language to add it to the list? would a radio button or "+" > button next to the language name, or instruction "tap language to add" help > there, or do we think something like this is not needed. Probably not needed -- the "tap a thing to add it to your list" is a fairly common interaction on Android. > Also if a user makes a mistake and enters a selection they don't want, how > and where might they delete a language from the list of selections? Users can tap the list item, and will be presented with a menu where they can delete it. Again, fairly common on Android and also consistent with how we handle our Search Engine customization UI.

(In reply to Axel Hecht [:Pike] from comment #36) > I like the UX, I got a few devil-n-details questions: > > should we show the languages in their native name, i.e. Francais on an > English and German UI? I personally think that makes sense. You're able to > read the language anywho, right? I defer to your expertise on that -- your suggestion sounds reasonable. On the other hand, though, someone whose primary language is English but might like to add German might be surprised to have to search for "Deutsch" to see it. Might it make sense to tie the way in which to display the language to whatever locale the OS is on? > should we hide languages that are already in our accepted language list? Probably, yes. > should we only show [default] if the language is at the position it is in in > the default set? Yes. Top position = default > And most ughly, we haven't talked about en-US vs en-GB vs en, zh-CN vs zh-TW > vs zh-HK at all yet. For desktop, we have this list to show which languages > we show with variations of regions, and if so, which: > http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/language. > properties > > I guess we need something similar for this, too? My assumption was that we would handle it much like desktop, where they all appear in the list -- see this screenshot of Arabic, for example http://cl.ly/image/1F35241m0b3v

(In reply to Ian Barlow (:ibarlow) from comment #40) > (In reply to Axel Hecht [:Pike] from comment #36) > > I like the UX, I got a few devil-n-details questions: > > > > should we show the languages in their native name, i.e. Francais on an > > English and German UI? I personally think that makes sense. You're able to > > read the language anywho, right? > > I defer to your expertise on that -- your suggestion sounds reasonable. On > the other hand, though, someone whose primary language is English but might > like to add German might be surprised to have to search for "Deutsch" to see > it. Might it make sense to tie the way in which to display the language to > whatever locale the OS is on? Is it possible to add dictionaries for multiple languages? Perhaps this could tie into the locale selection for the Fennec UI. Since we'll be severing the locale link between Firefox and the OS to add more locales to Fennec than what Firefox supports, we should do the same for this. > > > should we hide languages that are already in our accepted language list? > > Probably, yes. > > > should we only show [default] if the language is at the position it is in in > > the default set? > > Yes. Top position = default > > > And most ughly, we haven't talked about en-US vs en-GB vs en, zh-CN vs zh-TW > > vs zh-HK at all yet. For desktop, we have this list to show which languages > > we show with variations of regions, and if so, which: > > http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/language. > > properties > > > > I guess we need something similar for this, too? > > My assumption was that we would handle it much like desktop, where they all > appear in the list -- see this screenshot of Arabic, for example > http://cl.ly/image/1F35241m0b3v

I imagine this UI will be reusable, so blocking accordingly.

I'm going to tackle these in reverse order, because the locale picking UI is simpler.

I will probably not have the bandwidth to tackle this any time soon, though I will continue to push on Bug 1045053.

I have the same problem, I would like to see websites in Sardinian (sc) on Firefox for Android as well. The same idea that's used in Firefox for desktop (a list of preferred languages, to check in order) would be great. For example, in my case it would be like 1- Sardinian 2- Italian 3- English

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.