Last Comment Bug 846269 - Firefox OS i18n model only uses first subtag
: Firefox OS i18n model only uses first subtag
Status: NEW
Product: Core
Classification: Components
Component: DOM: Apps (show other bugs)
: Trunk
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: [:fabrice] Fabrice Desré
Depends on:
  Show dependency treegraph
Reported: 2013-02-28 03:25 PST by marcos
Modified: 2013-03-11 10:02 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image marcos 2013-02-28 03:25:13 PST
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130215130331

Steps to reproduce:

When neither the default_locale or the user agent locale match any content, FireFox OS decomposes the user agent's locale to a search for just the language subtag (i.e., just the first range). So, "en-US" becomes "en".  

  "name": "unlocalized name",
  "author": {"name": "unlocalized author"},
  "locales": {
    "en": {
      "name": "en name"
  "default_locale": "unlocalized"
The name of the app is "en name"

Actual results:

Because FireFox OS currently takes the first subtag in a language range:

this will exclude language ranges initially composed of three or mroe subtags (e.g., zh-Hans-XQ). This means that if the user's regional preference is expressed as "zh-Hans-XQ", the following will not match any localized content (when zh-Hans would have been a reasonable match):

  "name": "unlocalized name",
  "author": {"name": "unlocalized author"},
  "locales": {
    "zh-Hans": {
      "name": "zh-Hans name"
  "default_locale": "unlocalized"

Expected results:

I would expect that "zh-Hans" be matched. 

In addition, decomposition in this manner can be problematic. If the user's language preferences are expressed as:

"pt-AO, pt-BR, pt-PT, pt"

Then the reduction of "pt-AO" (Portuguese as spoken in Angola), to just "pt" will take precedence over the "pt-BR".
Comment 1 User image Jason Smith [:jsmith] 2013-02-28 13:32:01 PST
This sounds problematic and could impact us for localization. Worth noming to block?
Comment 2 User image [:fabrice] Fabrice Desré 2013-02-28 13:56:50 PST
I don't know how common these locales with more than 2 subtags are. Also, we'll need to check both gecko and gaia implementations.
Comment 3 User image marcos 2013-03-01 01:19:27 PST
I've asked the W3C's i18n WG for guidance on how common language tags with more than 2 tags are:

My own investigation is that they are very rare (i.e., I could not find any) in browsers, so this bug may be invalid.
Comment 4 User image marcos 2013-03-11 04:23:03 PDT
The W3C i18n folks are insisting that this will be a problem, but have not been as forthcoming as I would like with hard data. Unsure how to proceed.
Comment 5 User image [:fabrice] Fabrice Desré 2013-03-11 10:02:23 PDT
We'll fix this bug, sooner or later, but it's not tracked as something "important" right now.

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