This requires a bunch of other support -- build, hosting, etc. -- but a good first step is making the browser itself extensible in this regard. We might be able to achieve this goal solely via classloader trickery, but we might need to go so far as JIT-compiling some format (l20n?). Consider this bug on the back burner for the moment.

Firefox 39 has 5MB of APK size allocated to locales. 15% of the APK is multilocale support.

Can you track this down to native vs gecko? Anything in gecko of particular interest? I ask because maybe refactoring some things in toolkit to be more tailored to re-use in fennec might be a somewhat easy win?

I should write up a little guidance for this. There are two separable parts to this: strings and other locale-specific content. There are at least three places that strings are used in Fennec: 1. Manifests. For example, the names of Sync account features. These must remain hard-wired in the APK, because Android needs to look them up when we're not running. 2. Android/Java UI. We typically look these up through the Android "R" resource system. 3. Gecko strings. There are several kinds of locale-specific content: 1. Search engines. 2. Top Sites tiles. 3. … The obvious first target for this bug is to make Gecko strings and Android UI strings dynamically loadable from files outside our package. That will involve some Gecko hackery, a reimplementation of the Android string interface (fairly straightforward), and splitting up our strings into those that are packaged and those that can be downloaded. There's a lot more work to do to turn this into a shipping feature: work to download and update those strings, UX for choosing which locales to enable, error handling, telemetry, and more. This is one of the big-ticket wins we're looking at; saving 2-5MB of APK size (and more as we add new locales!) would be well worth the effort.

(In reply to Axel Hecht [:Pike] from comment #2) > Anything in gecko of particular interest? I ask because maybe refactoring > some things in toolkit to be more tailored to re-use in fennec might be a > somewhat easy win? Ships passing in the night! There are additional wins here to exclude toolkit strings that we don't use, and part of the work will be to make toolkit and other modules' strings dynamically loadable. Part of the cost here is simply the number of locales we support. Anything multiplied by 70 gets pretty big :)

(In reply to Richard Newman [:rnewman] from comment #3) > 1. Search engines. You might want to talk with mconnor. There are plans to get rid of the current structure and move searchplugin distribution to a centralized service. I don't know the timeline, nor if the first iteration involves Fennec (I'd assume it does). > 2. Top Sites tiles. Nit: that has no l10n impact, we use en-US tiles (unless I misunderstood what we're talking about).

(In reply to Francesco Lodolo [:flod] from comment #5) > You might want to talk with mconnor. There are plans to get rid of the > current structure and move searchplugin distribution to a centralized > service. I don't know the timeline, nor if the first iteration involves > Fennec (I'd assume it does). That would be great. > Nit: that has no l10n impact, we use en-US tiles (unless I misunderstood > what we're talking about). Suggested Sites. From some discussions earlier today I was under the impression that these were localized, but it actually doesn't matter much — for (perhaps obvious) reasons these can't be trivially downloaded OTA.

Adding bug 1215247 (Android Intl/ICU support) as a blocked bug, as we treat it as such.

Axel, is that the dependency direction you intended? That is, I would have thought downloading localization files would somehow depend on Intl/ICU, rather than the other way around… or do you mean we won't switch it on until we save more APK size?

The dependency is both ways, AFAICT. We need Intl for L20n, which we need for space savings. OTH, we need DLC for l20n to win back some of that space. And I'd really like to draw a dependency chain between telemetry for DLC and the Android Intl/ICU bug. I'm not all that comfortable saying that we'll be able to do DLC for l10n if we don't know how DLC performs in the wild. If you have a better way to graph that out, I'm fine with however that works.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.