Closed Bug 503611 Opened 15 years ago Closed 15 years ago

Allow run-time locale switching (to the system locale)

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 516492

People

(Reporter: pavlov, Unassigned)

Details

If the system's locale changes, the next time we start we should be localized to that language.  On the N810 for example, when you change locales it forces you to reboot the device.  We'll need this to be doable without the user needing to download and install extra packages.  This could also be used if we were to be bundled on a device that would ship to many locales and the user would select their locale the first time they turn on the system.
On a unix-based system, we could do this in the start-up script. It could symlink the right language pack into the chrome folder, along with its manifest file, and munge the fennec-l10n.js prefs file. That script might be optimized to do less in the standard non-switching case

I'd suggest that we'd even to a hard mapping of system locale and fx langpack code.

I'm not sure how this affects software update, though. Do we know yet how we want to do that at all? Incremental vs full vs just plain new debs?

The OS integration piece in terms of Desktop menus and links might need support, too.

Do we only need this for linux-based devices or for Windows, too?
I could be thinking of something else, but as far as I know, we have no startup-script for Fennec.

We start by launching the xulrunner-stub (renamed to "fennec").
We could certainly create a script/small app though if needed.

At least on Maemo, we end up doing full deb updates.  We will want to be able to do this on Windows Mobile as well where we are using our Windows update system, so I'm not sure 100% how it would work.  I assume we could do a partial update from one combined package to another?
If we bundled _all_ locales with the application, would this be an issue? Wouldn't normal starup just find the right language locale?
Noormal startup doesn't do any locale detection but just runs in what the preferences of the user or the app have selected.

The more locales we ship, the easier we're going to run into startup perf problems. Not sure if there'd be runtime perf problems as well.

The mapping of OS locale codes to our locale codes is hard, and is just going to get harder the more locales we ship. Doing a manually hard-coded map would be easier, but is only feasible for a limited number of locales on both sides.

Not that I see a value in shipping Frisian or Swahili xpis if there's no way that the OS is ever going to select them. And I see less value in offering a xul rich list box with 40 languages on a mobile device.

I'm not sure how the partial update code would deal with, for example, symbolic links. Or if we had to copy jars from one place to another, how that would cope, or update the copied jar with the updated one.
I'm a noob to some of this, but couldn't we use "intl.locale.matchOS" to set the locale?

http://mxr.mozilla.org/mozilla-central/source/chrome/src/nsChromeRegistry.cpp#521
Both bsmedberg and I don't consider the matchOS code to be OK to switch on. Linux distros disagree, and that's one of the differences we live with. I tried to fix that code a few years back, but I didn't come up with anything that :bs liked significantly better.

matchOS won't help the startup problems, either. Nor do we have a good grip on how good the OS locale/gecko locale matching algorithm still is. In particular things like Serbian in Latin script, which are coming up, could break the existing code.
I talked to Benjamin about the possibility of using "intl.locale.matchOS" in Fennec along with a fixed bundle of locales. We thought it could be OK, if we dealt with things like updating search plugins.

Since we would be requiring a restart, we'd just need to make sure the search service doesn't cache the list. If it does, we'd need to clear the cache if we sense a locale change at startup.

I think we should start down this path and see what problems we find.
The startup problems on the Linux distros are mostly due to the extension manager and langpacks. There is no need to use extensions for these locales: just ship all the locales as part of the builtin chrome: I'm really hoping that won't have any noticable impact on startup performance, since it's only reading a few extra lines in manifest files.
Search plugins are handled outside of xpis. They can be shipped as extensions, at which point we're back at square one. Not that we can disable extensions which would provide language packs which are not selected or something.

I.e., offering a selection of search plugins that are dependent on the currently selected locale is a different bug.

Regarding switching on matchOS, we shouldn't do that without tests, and a platform or mobile engineer on the hook for fixing problems. As I mentioned before, I expect this to be a problem in flux as we add more languages. I don't think that code got any testing in the last 10 years or so on any platform but linux, either. I guess we'd at least need a test matrix, not sure if that's OS dependent. I know that glibc works different than Windows, no idea if there are differences between for example WinCE and desktop versions, or within those.

I still think that the code that's run as matchOS is yucky, but it's not my call.

For locales we have that are outside of those testing matrices, we need to figure out something that's not a dropdown of 50 items nor about:config.
We're definitely talking about having to do additional work and QA to searchservice and perhaps some other code in order to support .matchOS reasonably. I think that we could probably have searchservice load from chrome: URIs instead of trolling the filesystem... need to talk to gavin about the best way to approach that.
Just to clarify -- this is a first run thing, right?  For example, the device ships in en-US and the user needs to change it to whatever his or her locale actually is.

Also - wouldn't something _have_ to be downloaded (not saying the user should do it manually -- he or she shouldn't have to do that)?
No, this is not a first-run thing. We would ship a set of locales as part of the basic package and on each startup we select which one to use based on the device locale.
Both of which are questions that still can be answered individually.

My personal take is:

- not only on first run, but only on startup

- rather not a download, mostly because we don't have a IT/web infrastructure for doing that
Work happening in bug 516492
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.