Closed Bug 846269 Opened 7 years ago Closed Last year

Firefox OS i18n model only uses first subtag


(Core Graveyard :: DOM: Apps, defect)

Not set


(Not tracked)



(Reporter: marcos, Unassigned)


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".
Component: General → DOM: Apps
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
This sounds problematic and could impact us for localization. Worth noming to block?
Ever confirmed: true
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.
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.
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.
We'll fix this bug, sooner or later, but it's not tracked as something "important" right now.
Product: Core → Core Graveyard
Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.
Closed: Last year
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.