Closed Bug 700289 Opened 9 years ago Closed 2 years ago

map he->iw and id->in in nsLocaleService

Categories

(Firefox for Android :: Locale switching and selection, defect, P2)

All
Android
defect

Tracking

()

RESOLVED FIXED
Tracking Status
blocking-fennec1.0 --- -
fennec - ---

People

(Reporter: Pike, Unassigned)

References

()

Details

As you can see on http://colincooper.net/?p=238, android is using two odd locale codes in their scheme, 'iw' instead of 'he', and 'in' instead of 'id'.

We need to map our locale codes with special case for this, http://hg.mozilla.org/projects/birch/file/f069ffc41471/embedding/android/Makefile.in#l173 should be the right spot.

Tested that that works with my AllLocales dummy app from https://github.com/Pike/android-l10n.
OS: Mac OS X → Android
Priority: -- → P2
Hardware: x86 → All
assigned to l10n@mozilla.com.  Not really sure how to fix this.
Assignee: nobody → l10n
At least half of this is in bug 702302 now.

Not sure if we need some tweaks to matchOS logic, notably:
if you set the OS language to hebrew or indonesian, and that sends the java locale codes to nsPosixLocale.cpp, map them to the gecko versions, probably in that file.
Depends on: 702302
My tests show that hebrew isn't picked up in the multi-locale build so far.

Need to investigate further.
Axel, since we are working on 'he' folder for localization and not 'iw', should it make any change in our current workflow?
LANG: iw_IL
shows my debugging in http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/nsLocaleService.cpp#167.

Simon, any recommendation on where we should make iw -> he again? Same for in->id. In nsLocaleService, or in nsPosixLocale?

(And no, the mapping is done on build time now)
I think in nsLocaleService. What about other deprecated language codes? 

From the IANA registry, there are also
ji->yi
jw->jv
mo->ro

and a bunch of deprecated three-letter codes.

<rant>
It's so annoying that we have to deal with this: in and iw were deprecated in *1989*, probably before the majority of users of Android devices were even born.
</rant>
http://colincooper.net/?p=238 claims that only Yiddish is affected, too. Blames java for that, and whatever I find on the web isn't really authoritative but also only mentions the three of he, id, ji.
Hardware: All → ARM
tracking-fennec: --- → 11+
Pike,
what needs to be done here?
blocking-fennec1.0: --- → -
tracking-fennec: 11+ → ?
Pike, of this needs to track a given release, please renom and say which one
tracking-fennec: ? → -
Not gonna work on this any time soon, unassigning.
Assignee: l10n → nobody
Blocks: 945122
Hardware: ARM → All
Component: General → Locale switching and selection
Comment 6 seems to be the remaining work item here.
Summary: map he->iw and id->in for values-ab-CD/strings.xml → map he->iw and id->in in nsLocaleService

can we close it now? We don't have nsILocaleService, Android migrated to BCP47 and it seems like we haven't hear about any issues around it in a long time.

I'm resolving this, there's a few caveats though:

Android is far from BCP47. There's some junk they do with script tags in resources, but that's not BCP47 either. They just namedrop that. IIRC, the non-standard language codes are actually java related (and no idea if kotlin exposes that).

For Fennec, we've got work-arounds in the build and in the gecko-java wrappers. For geckoview, I honestly don't know. I didn't find anything in mobile/android/geckoview, but there's some in telemetry in a-c. I just don't know where to look. We'll need to test and find bugs in Fenix once we start localizing that.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

That sounds reasonable! Let's handle that in Intl::Core for LocaleService once we start investigating. I'd also prefer to keep the platform specific quirks per-platform, so I hope that some equivalent of gecko-java wrappers will handle those outliers.

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