1605358 - GeckoView localization request

Status: NEW

(Mozilla Localizations :: Other, task)

Description

[Axel Hecht [:Pike]]

Filing this on behalf of the mobile team to get tracking on what we ship l10n-wise in GeckoView. GeckoView, by inspecting the beta aar, ships a few localized resources, both chrome:// and Fluent.

Open questions from our project-request template:

Project owner:
Description of target audience:
Where the source content (will) lives:
Target locales:
Reference materials (e.g., style guide):
Project's roadmap (URL preferred):
Project's target release date:

David, snorp, who's our partner on your side here?

I'd also like to share my speculations, and see if they're correct:

We're just shipping what used to be used for Fennec? l10n-central, multi-locale logic, changesets, covered files?

If so, we're probably not maintaining that configuration with the intent of doing the right thing for GeckoView on nightly. We just maintain it to do the right thing for Fennec on ESR 68 (which uses the config on mozilla-central).

We also talked about dropping the files in mobile/ from the l10n process completely, which might have bad impact on what we'd need for GeckoView?

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Axel Hecht [:Pike] from comment #0)

Filing this on behalf of the mobile team to get tracking on what we ship l10n-wise in GeckoView. GeckoView, by inspecting the beta aar, ships a few localized resources, both chrome:// and Fluent.

Open questions from our project-request template:

Project owner:
Description of target audience:
Where the source content (will) lives:
Target locales:
Reference materials (e.g., style guide):
Project's roadmap (URL preferred):
Project's target release date:

David, snorp, who's our partner on your side here?

I'd also like to share my speculations, and see if they're correct:

We're just shipping what used to be used for Fennec? l10n-central, multi-locale logic, changesets, covered files?

I don't know for sure, but that seems likely.

If so, we're probably not maintaining that configuration with the intent of doing the right thing for GeckoView on nightly. We just maintain it to do the right thing for Fennec on ESR 68 (which uses the config on mozilla-central).

That sounds bad.

We also talked about dropping the files in mobile/ from the l10n process completely, which might have bad impact on what we'd need for GeckoView?

Right, I think we still want to do that. We don't have localized strings in the Java bits of GeckoView. We only care about strings and other l10n data from Gecko proper.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

AFAIK, all of the multi-locale work for GV was done in Bug 1496190. So...we're doing whatever was done in there, I guess?

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

So I don't believe there is any l10n under mobile/ that we care about. There may be some stuff from toolkit that matters, however. Can we verify that those bits are being included?

As soon as Fennec is gone, we can remove the confusing files from m-c.

Comment 4

[Axel Hecht [:Pike]]

FWIW, you can change the jar.mn to whatever needs we have right now. The only file we shouldn't remove stuff from yet is the l10n.toml.

It'd be good to know what exactly we're using in geckoview, to help us evaluate the options going forward.

Looking at locale coverage we have from Firefox, Fennec has additional locales:

co
es
ml
nv
su
vec