Indonesian and Hebrew (and others?) are represented as different codes in our two systems. As a follow-on from Bug 936756, we need to make sure that these are translated correctly when set.
I see Indonesian on our roadmap for 30. Flagging for tracking; this needs to be done before that can be adequately tested.
Java translates the locale codes for Indonesian, Hebrew, and Yiddish from the ISO 639-1 two character codes into their depricated counterparts automatically. See "Class Overview" here: http://developer.android.com/reference/java/util/Locale.html I'd like to verify that this is true, but without adding the locale code to maemo-locales and switching the locale within Android, I'm unsure how to proceed. Also, the roadmap is being revisited. Indonesian may be bumped up to 28 due to the emphasis being placed on the region.
(In reply to Jeff Beatty [:gueroJeff] from comment #2) > I'd like to verify that this is true, but without adding the locale code to > maemo-locales and switching the locale within Android, I'm unsure how to > proceed. Probably by doing that :D It doesn't matter what the content is -- we just want to verify that the right files get picked for whichever code we use to identify the locale. We can start by copying an existing locale in-place and testing that way (which at least gives me a fighting chance to read the menus!). There are two code paths to check. We want Indonesian to work correctly regardless of whether you set a locale in Android settings or inside Fennec, which means we definitely need to take the Java-native deprecated values as input and translate them for Gecko. We also need to test that whatever code we use internally gets translated in all the paths we send it through into Android (not just the Java Locale class). > Also, the roadmap is being revisited. Indonesian may be bumped up to 28 due > to the emphasis being placed on the region. Ooh, exciting. How likely is that "may"?
The patch in Bug 955805 makes this work with the locale switcher. I haven't tested the behavior when you pick the locale in Android settings; presumably it works as well as it always has.
Brad thinks we might already have some code for this. Maybe a regression?
We never shipped any locales that needed it, so I doubt this has ever been tested, so I doubt it's a regression. The old (commented-out) scheme had Gecko manage locales, and then hand them off to Android. Java's Locale class already handles both sets of locale codes. We're now going in the other direction, and Gecko is very brittle (e.g., Bug 955805). After Bug 955805 landed, there *should* be no work left in this bug, unless Gecko mishandles the Java environment when the locale-setting code isn't involved. (Which it might: again, we've never tested this, because those locales aren't involved.) When we've determined that everything's working well, I'll close this.
I think we still need bug 700289
Making this a meta bug, then!
We don't track metas.
Jeff, Axel: is this still an issue, or can we close this as WORKSFORME?
Did we get bug 700289 comment 6 right yet? That seems to be the only open issue, and I don't see a related fix in nsLocaleService.
(In reply to Axel Hecht [:Pike] from comment #11) > Did we get bug 700289 comment 6 right yet? That seems to be the only open > issue, and I don't see a related fix in nsLocaleService. Switching locales to Bahasa Indonesia seems to work fine, which means the Java -> Gecko bit is working, so I'm going to close this in favor of that bug.