GeckoView localization request
Categories
(Mozilla Localizations :: Other, task)
Tracking
(Not tracked)
People
(Reporter: Pike, Unassigned)
References
(Depends on 1 open bug)
Details
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?
(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, bothchrome://
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.
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?
Updated•5 years ago
|
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.
Reporter | ||
Comment 4•4 years ago
|
||
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
Updated•2 years ago
|
Description
•