Axel Hecht Mozilla in Your Language

I’d like to congratulate Tim Babych and the Ukrainian localization team for the initial landing of the Ukrainian localization of Firefox 2 on the trunk.

If you know someone that would like to test it, there is a language pack in the landing bug, and a bugzilla component for feedback. The remaining steps for getting the localization into the release process are tracked in bugs blocking the Ukrainian release bug.

I’d like to award Phil Ringnalda with the L10n cookie of the week-award for hunting down the unused strings on the trunk. Not just that, but also the bug comment of the week, as far as I’m concerned, goes to the initial comment of bug 375485. If you ever wondered if there are low-hanging fruit to make our applications easier to localize, and to improve the quality of our localizations, removing dead strings by the time you kill them in one of them. Phil not only tracked down which strings are not used anymore, but also why, finding strings which death dates back to 2000. Strings which our localizers worked on, or, 56 ways to lose your lover. It’s a nice demo of our font rendering caps, though.

Lesson to take away is, if you kill a localizable string, kill it, if you add one, use it.

We had our first l10n impact meeting for Firefox 3, places was on. The meeting minutes are on the wiki, but there are few key points that are of more general interest.

Firstly, the l10n impact meetings are held for the first time for Firefox 3, so we’re going forward with open eyes, ready to continue with what works, and change what doesn’t or could work better. The places meeting worked out good, so we’re going forward in this direction. The general idea behind these meetings is, if the PRD lists one P1 item for you, you’re stuck with 7. Your feature is supposed to be in an up-to-par quality not only in English (US), but in another 6 languages, too. And that number may grow, even. As you as a feature developer can’t make that yourself, the key is to jointly develop features. It’s the “help us to help you” dance.
Secondly, we have loads of documents on how to write localizable software, most of which are old. Writing localizable code on MDC is the newest and the only currently maintained one. I’m happy to see comments on that document, as always, the discussion page is a good place for that in general. Bigger discussions are best held in .l10n.

There are two areas where we don’t have a good set of documentation,

• how to design localization of features
• how to develop features in an l10n-friendly way

The first area is something we just need to learn about, and doing meetings on that topic is likely the only way to really understand what needs to be done, and to carry experience from one area to the other. I guess we’re just too creative in our features to have ready-built recipes for this. To clarify, this is not about whether you use a DTD or a properties file for something, or if an RDF file is cool.

This is about answering the question what a German speaking user in Rwanda would expect Firefox to do. What is supposed to happen if some user decides to install an, say, Khmer version of Firefox 3.0.0.3 over an English (US) one, just because we started supporting that language with that release? If you look at your Feature Plan Template, this is what sidegrading is supposed to be. Installing a partner build or non-partner build over an existing install goes by the same name.

Let me give you an example, in the Firefox 2 default bookmarks. There are links to Getting Started, customization, about etc. Those generally go by the name of in-product pages, and are really just extensions of Firefox on the web. If you decide to use a French build, you’d expect to get help and extensions in French, so actually, these links should probably follow the currently installed language. It’s an interesting question whether the titles should do, too. On the other hand, there is one link in there to demo the live bookmarks, a news feed. In that case, my personal expectation would be to not change that. All of this of course only if the user hasn’t changed the default. Whatever that means for a link collection. As you can see, even something as old as bookmarks has interesting stories to tell when it comes down to localization design.

Once these questions are properly answered, the technical implementation of those is a lot less cumbersome and surprising, too. At least that’s my expectation.

These questions get more involved as soon as you touch services and web properties of third parties. We have quite a bit of experience in that, and even more rules, but as they involve 3rd parties, it’s tricky to put them on public paper. So you want to check in with Mic and me on that. Rules of thumb, we can’t do anything without permission; not everything good in Amercia is good in Germany; permissions can be revoked. Mic and I can help create good public guidelines for localizing whatever you need, too.
Next step, assuming we know what a feature is actually supposed to do, how do you go about and code it such that localizers can make your feature rock in the localized versions? The first and foremost step is the quality of the en-US code. It needs to be understandable by users, of course, but on a code level, it needs to be understandable by localizers, too, even more than that, it should be understandable by looking at tests (**) and localizable files only, even. One way to tackle this, and I’m suggesting that you go this route until we have contradicting evidence, is to separate writing localizable code from exposing the localizable content to localizers.

Writing localizable code

This is the technical process of putting UI strings into DTD files or properties files. You shoud rethink your architecture if you need something else, please ask me for comments then, too. More on MDC, as linked above.

Exposing localizable content to localizers

Now you’re actually putting the DTD and properties files into the locales/en-US, exposing them to localized builds.

Why the difference? Whenever you change (see MDC doc) a UI string in your feature, you’re going to break all localized builds. That’s a bug, it can be fixed, it’s not trivial to do so, though. Break as in, there won’t be anything uploaded to ftp, localizers can’t test the trunk. This is the technical reason. The software engineering reason, and that’s more important and likely to stick even if we get the technical one fixed, is that unless you know what your UI is supposed to look like and what the UE is supposed to be like, localizers are going to play a guessing game. They’ll guess stuff, and it’s much harder to fix the guesses later on than to just not start guessing. Before you start to expose your code to localizers, you want to go through the following check-list:

• Is the functionality of the feature specified and documented?
• Are the policies published, if necessary, in particular for 3rd party hooks? Were those policies published early enough for localizers to comply today?
• Are the localizable files proper? No unused strings, good key names, good comments etc? Is the content in there sufficiently stable, or would I be wasting the time of localizers? (*)
• Can this work in RTL languages? Don’t forget accessibility, too.
• Are the tests up? (**)

If you can run through this check list and be fine, it’s time to get your code out there in the wild. Be prepared for some half-a-dozen reviews of your code instantly. You want to write an announcement for the l10n newsgroup, too.

As far as I’m concerned, it’s fine to ship UI strings in content for alphas, as long as you keep an eye on landing them in locales/en-US in time.

(*) Finding out when your code is stable is not exactly science. As long as you follow the guidelines, you want to work and improve on your code. You need to find a balance between releasing early and just adding noise.
(**) Tests? Yes, tests. Please provide tests for exposing all strings you have to end users, so that localizers know how to test their work in action. Litmus tests are probably fine, you should explain how to open all dialogs and panes etc. Writing tests for error messages is harder, yet more important, too.

We’re having a string change on a stable branch, and I’d like to give an overview of what I did how to make this less painful. Less is intentionally a relative measure, it’s still really very badly painful.

The biggest part of this change was to actually settle on the intended outcome. How should locales behave that make the change, how should locales behave that don’t. What should happen to users with language packs, and what with the language pack versioning. In this particular case, language packs aren’t loaded yet, so they don’t really matter, but in general, it’s a question worthwhile answering.

Now, how to get those changes? The (IMHO) best way is to get patches from the localizers that apply easily. The previous step should identify a concrete patch to implement by the localizers. That didn’t work out perfectly this time, but we caught the difference in time.

Landing seperate patches in tracking bugs leads to all kinds of messy problems, so I went for one bug per language in CVS, whether built or not, and one central tracking bug.

Bugzilla magic, part 1: How to file 50 bugs without getting totally frustrated? I created an HTML form which takes an initial comment, the summary, a blocked bug, and then, on the press of a button, creates bug-filing links for all locales. I hard-coded the list of locales for now. It substitutes @AB_CD@ in all fields for the current locale, and picks the right component in the Mozilla Localizations product, which works for all languages but Slovak right now. The goodness of us hunting for bugzilla components now. I can then click on each link, or just use keyboard navigation. Just opening the links via window.open() works, but really stress tests bugzilla (and Firefox), so that’s not that good. Anyway, it took me about 50 minutes to file 57 bugs. That includes a bunch of distraction while waiting for bugzilla, I’d wish filing bugs would be a snap. Still, not bad, less than a minute per bug. Released lanuages block the tracking bug, others don’t, which was hand-work for now.
For the non-released languages I made those block the central bug once they had a patch.

Within 24 hours, we had 20 patches, within 48 hours, we had 36 (plus 1 which I still have to find out why it didn’t apply). I had to adjust only two patches myself, all others where either fine from the start, or fixed by the localizer on my comments.

YAY on our localization community.

Now, do you want to apply some 36 patches by hand? I don’t, so

Bugzilla magic, Part 2: Creating a bad big patch. Create a bug query that gets all bugs that block the tracking bug and have an attachment that is a patch (“Attachment is patch”, “is equal to”, “1” is the magic trio) . Then click on the XML button, which creates one XML document of all bugs on that query, including all the information. And attachement IDs :-). Now open Jesse’s jsshell bookmarklet and get the attachement IDs:

res=document.evaluate(‘bugzilla/bug/attachment[@isobsolete=”0″][@ispatch=”1″]/attachid’,
document, null,XPathResult.ANY_TYPE,null);
out=[];nd=res.iterateNext();
while (nd) {out.push(nd.textContent);nd=res.iterateNext();}
out.join(‘ ‘)

Now I moved over to bash:

for att in <insert list of attachement IDs here> ; do wget –no-check-certificate -O- ‘https://bugzilla.mozilla.org/attachment.cgi?id=’$att > $att;done

cat all those patches together, test the patch and fix the chunks that don’t apply, and off you go with 36 fixed locales in 48 hours.

I’d like to introduce you to Planet Mozilla L10N, a new resource that’s hosted on the l10n server. We’d like to syndicate blog posts by our localization community that are of interest to other localizers. We started off with a few feeds that are already on planet.mozilla.org, but really only a few of general interest to the Mozilla community. I for one syndicate only the posts in my l10n category, for example.

If you would like to participate on Planet Mozilla L10N, please drop me a line. If you’d rather not appear on there, but do, too, of course, which currently only affects Mitchell, SethB, Pascal, and me.

For those reading my blog and not planet, Seth blogged about how you can get access to l10n.mozilla.org, just file a bug. We’re all set up for you to have files hosted on there. For more involved services, file a bug in the same component. The server is set up for VMs, if you’re doing something that would better fit a new VM, that’s cool. Disclaimer, we sadly have to turn down services that support user posts, basically. Think wiki, forums, blogs with comments/trackback. Sad, but true, that’s the world we live in.