Localizing Firefox - creating parts?

Axel Hecht axel at mozilla.com
Tue Sep 24 17:07:55 UTC 2013

I would hope that we'd get away with per-directory basis, or even 
top-level dir.

Also, this doesn't need to be pixel-perfect, at least in one direction. 
I.e., if there are 3 devtools strings in the Firefox menu bar, that's 
just fine with the menu bar strings. Might actually be better there.

It's harder the other way around, if there's prominent UI that's 
accidently in an area that some of our localizations would ignore.


On 9/20/13 11:27 PM, Dave Camp wrote:
> Buckets would be decided/split on a per-l10n-file basis, or a
> per-l10n-directory basis?
> Either way, this seems reasonable for devtools.
> -dave
> On Fri, Sep 20, 2013 at 9:44 AM, Axel Hecht <axel at mozilla.com
> <mailto:axel at mozilla.com>> wrote:
>     Hi,
>     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 purpose.
>     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, Russian.
>     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:
>     https://github.com/translate/__mozilla-l10n/blob/master/__phases.rst#firefox-phases
>     <https://github.com/translate/mozilla-l10n/blob/master/phases.rst#firefox-phases>
>     and
>     https://github.com/translate/__mozilla-l10n/blob/master/.ttk/__firefox/firefox.phaselist
>     <https://github.com/translate/mozilla-l10n/blob/master/.ttk/firefox/firefox.phaselist>.
>     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.
>     Axel
>     _________________________________________________
>     firefox-dev mailing list
>     firefox-dev at mozilla.org <mailto:firefox-dev at mozilla.org>
>     https://mail.mozilla.org/__listinfo/firefox-dev
>     <https://mail.mozilla.org/listinfo/firefox-dev>

More information about the firefox-dev mailing list