Localizing Firefox - creating parts?
mconnor at mozilla.com
Tue Sep 24 20:21:51 UTC 2013
On 2013-09-24, at 1:25 PM, Axel Hecht <axel at mozilla.com> wrote:
> 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.
If we're already relying on the OS, we're probably not making this substantially worse than it already is for smaller locales.
>> 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.
Honestly, I think that's a lot of work for what is a very small delta from en-GB, and a delta that's unlikely to undergo consistent changes (I'm asserting that the only changes would be around partner hookups, and there would be no value in forking any of the language usage). Maintaining 3-4 forks (India, Australia, New Zealand, maybe even Canada!) just to get different search plugins seems like a much more failure-prone model than leveraging a bucket system to re-use those files directly.
More information about the firefox-dev