Localizing Firefox - creating parts?
axel at mozilla.com
Fri Sep 20 16:44:04 UTC 2013
we're proposing to cut Firefox l10n into two or more buckets. We'd like
to get your feedback on whether that makes sense for Firefox, and if the
developers are OK helping us out with keeping those buckets to their
With much of the recent UI work in Firefox being Developer Tools, about
1/3rd of the strings we localize are around devtools, and web error
messages (CSS, HTML, XSLT, XPath, etc).
Translating that content makes sense for languages like French, German,
At the same time, we think users are better served with those tools in
one of the languages above for Occitan, Fulah, etc.
We're proposing that we cut the localization files into at least two
buckets. Firefox would remain the UI that 90% of our users encounter.
Devtools would be in a separate bucket. Localizers would decide which
buckets to include in their work, and make consistent efforts in each.
Does that make sense?
The impact on developers would be: The buckets would be associated with
directories in the source tree. The extra work for developers would be
to decide which bucket their string belongs to, and not so much rely on
which l10n files the code around already uses. We'd obviously document
those buckets and the locations for files. Devtools already does a good
job here, but it'll require discipline in the future.
The concept isn't totally new, Dwayne Bailey does something along those
lines for the teams working on pootle:
I'm currently thinking that two buckets are good enough, Firefox and web
errors/devtools. What do you think, do you have other buckets?
Next steps: Gather feedback here, then in the l10n newsgroup. We'd
propose a concrete plan in .planning. We also have folks in each summit
location to talk to.
This isn't coming over night, as it'll need implementation work on the
dashboard, and maybe even releng processes.
More information about the firefox-dev