Fennec support for downloadable localization files

NEW
Unassigned

Status

()

Firefox for Android
General
4 years ago
6 months ago

People

(Reporter: rnewman, Unassigned, Mentored)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

unspecified
All
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec+)

Details

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
Depends on: 968172
(Reporter)

Updated

3 years ago
Depends on: 1095719
(Reporter)

Updated

2 years ago
Blocks: 942609
(Reporter)

Comment 1

2 years ago
Firefox 39 has 5MB of APK size allocated to locales. 15% of the APK is multilocale support.
Mentor: rnewman@mozilla.com
tracking-fennec: --- → +

Comment 2

2 years ago
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?
(Reporter)

Comment 3

2 years ago
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.
(Reporter)

Comment 4

2 years ago
(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).
(Reporter)

Comment 6

2 years ago
(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.
(Reporter)

Updated

2 years ago
See Also: → bug 1194338

Updated

8 months ago
Depends on: 1272354

Comment 7

8 months ago
Adding bug 1215247 (Android Intl/ICU support) as a blocked bug, as we treat it as such.
Blocks: 1215247
(Reporter)

Comment 8

8 months ago
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?
Flags: needinfo?(l10n)

Comment 9

8 months ago
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.
Flags: needinfo?(l10n)

Updated

6 months ago
Blocks: 1344625
You need to log in before you can comment on or make changes to this bug.