Localizing Firefox - creating parts?
axel at mozilla.com
Tue Sep 24 17:25:29 UTC 2013
On 9/21/13 12:13 AM, Mike Connor wrote:
> 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.
Right now, we just ask the operating system for those. This might change
if we get ICU and the globalization API on its top built and sticking.
Are you asking if we could make it such that toLocaleString adheres to
French within devtools and Fulah within the download manager?
Interesting question. Once we own the number and date formatting stuff
via ICU, I guess we could. There have been arguments that consistent
date formatting across the OS would be more important than within the
app UI, too. I'm not really in either camp on this one.
> 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.
I've always been thinking about those cases as "fork en-GB, do your
productization, and merge en-GB every 6 weeks".
I also think that en-X-fork teams need to be more technical than other
localizations, because they need to triage incoming bugs more deeply.
Not just do they need to figure out if it's a bug or not, but also if
it's their bug or en-GB's. They also need to be more collaborative to
get the fixes they want into upstream, if they're upstream.
> -- Mike
> On 2013-09-20, at 12:44 PM, Axel Hecht <axel at mozilla.com> wrote:
>> 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.
>> firefox-dev mailing list
>> firefox-dev at mozilla.org
More information about the firefox-dev