Localizing Firefox - creating parts?

Mike Connor mconnor at mozilla.com
Fri Sep 20 22:13:40 UTC 2013


Overall I really like this, it seems like a solid step to help smaller localization teams 

How would this work with things like Date.toLocaleString()?  Might not be quite as good.

I'd have to spend some time iterating over all of the places this would matter, but if we're building the ability to include buckets from other locales, I'd really like to look at starting to do some separation between language and locale, specifically around how we incorporate services (search, mail providers, etc) for divergent locales that share a language (en-GB being a really prominent one with India, Australia and New Zealand as obvious places where the default options aren't really delivering the best choices for those countries.  If it was really easy to share the translation bits we could deliver a much better experience for those users.

-- Mike

On 2013-09-20, at 12:44 PM, Axel Hecht <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 and 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
> https://mail.mozilla.org/listinfo/firefox-dev




More information about the firefox-dev mailing list