Axel Hecht Mozilla in Your Language

I’ll be presenting on l20n at FOSDEM this weekend. The slides are mostly done, and to the extent that slides without the presenter are any useful in general, are up for everyone to see. Note, that link may not stay there.

I posted to several open-source i18n/l10n lists last night, and got some feedback triggering a new example, declensions and special cases.

What would l10n be without grammar problems, and l20n is no better. Check out the initial grammar on my people page, which corresponds to the Von allen Gedanken version of the proof-of-concept implementation.

Comments welcome, probably best in .i18n.

Welcome to another round of l20n. I finally added expressions and macros. Expressions are closely following the C grammar, I ripped out the bitwise operators and some C-isms. Macros are a new grammar struct to implement things like plural forms, with the additional benefit that I didn’t limit this to one form, but actually embedded this into the grammar. That is, if a localizer feels like having to use a different implementation for plurals, (s)he can. This should be useful in particular when it comes down to limiting the plural forms on integers, non-negative numbers, general floats, if you want to handle NaN etc. An example for such a macro would be

<plural: (n) -> {n != 1}>

which happens to be the gettext plural macro for English and German. You can see that in action on my new plurals example.

I’m looking forward to see folks submitting patches to add locales here. If someone feels like improving the web pages a bit, I wouldn’t be offended either, I know that most of this feels really as hacky as it is.

If you are like me and would like to see the grammar and more spec work online, I’d appreciate your opinions on the licensing of that, just asked today in .legal.

… schätze ich doch am meisten … die interessanten.

One of the untold stories of Firefox is that localizing Firefox is something different. Inside our localization community, it is an often heard complaint that we’re doing this while every other project in its sane mind does that. I have been thinking about that often, but we haven’t actually made a story out of it, so here is my take.

When thinking about Firefox, I see four major distinguishing features.

• Firefox is not just a piece of software.
• Firefox has users. A few dozen million users a week, even.
• On top of that, a good deal of those users never installed Firefox themselves, or would have. Our strong community with USB sticks did that for them, and for us.
• Mozilla keeps those users safe. The internet is a rough place to hang out, and we’re updating the Firefox installations of our users to our best knowledge.

In particular the first and the fourth point make an essential difference to our localization story. We want our users to be using the safest version of our software. Not doing so puts our users at a real life risk, and thus we’re compromising on the language. We don’t offer downloads of Firefox 1.0 versions on our website, just because that happens to be the last version of Firefox in a particular language. The amount of users we have and the variety of their technical skills make us do automatic updates to keep our users safe.

What does that mean for a localization? It means, Mozilla can’t use a localization of any particular version of our software. We’re making a long term commitment to our users, and we need our localization teams to join us in that commitment. We want and need the localization teams to join our community.

Which brings me to the first point from above, Firefox is not just a piece of software. Firefox is a community of users, contributors, and developers forming around a piece of software, including moms, dads, and neighbors just as well as xptcall ports haxxors. And localizers. That’s why users of Firefox in a particular language expect to see more than “just” the software. The website is one part (yay to mozilla.com localization), AMO (yay) is another. MDC (yay) is another level in which local communities can engage and help. Most locales have already organized forums and other community-building sites in their own regime, which is a great thing. We’re trying to be conservative in what we require localization teams to do, but the variety in opportunities in our ecosystem should give you a good idea why localizing Firefox is much more successful when it’s a team effort. I’m excited to see how many of the items in this paragraph moved from yikes to yay, btw.

Of course, being a joint development community is a two way road. We made some good progress on that on the MOZILLA_1_8_0_BRANCH and Firefox 1.5.0.x, freezing that for changes that would require localization changes. That way, we can, and do, ship the currently most secure version for all our languages, and serve automatic updates for those. Same of course holds for our newer stable branches.

Looking forward, the next big step will be the major update from Firefox 2 to Firefox 3. Optimistically, we want to offer Firefox 3.0 to all existing Firefox 2 users, in their language of choice. If that won’t work due to resource constraints, we should be able to take all the 2.0.0.x locales on Fx3 by the time we offer an automatic major update. We will remain to rely on our contributors for localization, but there is a clear commitment to not break this by BD, QA, or build/release, let alone engineering.

That makes us different, and good. IMHO.

I’ve been doing some investigation on localization architectures in the last two months or so, triggered by parts of the 50-2-100 thread in .l10n and .planning. In particular, I’ve been reading the archives of translate-i18n, which happens to be the (main?) gettext mailing list. Looking at the problem reports there and following the links out to stuff like XLIFF, I looked for solutions to the following tasks:

• attractive for coders
• attractive for localizers
• support for both XML (XUL) and js (C++)
• support for plurals
• … and genders
• fix problems with labels and accesskeys, too
• play nice with version control systems (and not necessarily with mail)

and found … nothing.

Thus, I have been spending the good half of my time recently to actually work on a solution that can match all of the points above. The code name for that project is L20n, as it takes L10n a significant step further. And we’re all heading 2.0 anyways.

I invite you to spend some time looking at the details on the wiki, as well as to look at some of the examples I have so far, targetting HTML and JS. That’s a bazaar rep, too.
The scope of the project is not limited to Mozilla, if we care for acceptance in our localization community, we should care about other projects, too. And the problems we tackle here are not our very own problems, everybody is hitting them, so our chances are not too bad. I already have some limited feedback from folks outside of Mozilla, and I’ll send further pings if all goes well. The timeline as far as it impacts Mozilla is Mozilla 2.

If you can help, I’m looking for feedback in general, either here, on the wiki or in .i18n. I need some tips on writing specs in general, too. If you have experience in code generation based on grammars, I’d love to see some pleasant surprises, using antlr hasn’t been one so far. If you want to join working on the spec, I’d be happy to add some editors. And of course, I need help in showing this off in other languages, both spoken and programming. If you have a sample you’d like to see done, let’s get it on. Some of the open issues are on the wiki, too.

I intend to have a discussion on this proposal at FOSDEM, too, leveraging the gathering of all kinds of Open Source projects there, hopefully.

Oh, and I get to choose the code names, so Meet Pete ;-).