Staś Małolepszy

More on the l10n de-beta process

This post was migrated from my old blog. Some links might not work.

I’m happy to write this: in the upcoming Firefox 3.0.7 release (scheduled for tomorrow), four three of our beta locales will move out of the beta status!

  • Estonian (et)
  • Kannada (kn)
  • Telugu (te)

Congratulations to the localization teams that made it possible!

Seth already did two great posts about our process: So what does “getting new languages ready for release” actually mean? and Moving a locale out of beta, but I thought I’d give some more detail on how the process fits into our code freeze and release schedule.

When we first add a new localization to the tree, it’s in its pre-beta status (let’s call it alpha). This happens after an initial review of the localization by Gandalf or Pike (the review includes checking if the directory structure is correct, the encoding is OK, if all entities are used correctly etc.), at which point a flock of new bugs is filed by the l10n-drivers team, as described on the wiki. These are things like creating a new Bugzilla component for the locale, landing the localization in its brand new repository or modifying the all-locales file for each branch that’s ready. The locale’s nightly builds start to build.

Localizers then continue working on the translation, pushing changes to the repository. At this point the productization and the web parts processes start. The guidelines and the description of the productization process can be found on the wiki. Two bits of the productization process are given special priority at this point: search engine plug-ins setup and protocol handlers setup (e.g. web-based mailto: handlers). We try to find a good and final list of both of this productization bits before the first beta release of the locale, or, if deciding on the final list is not possible straight away, we try at least to only include search engines and protocol handlers that we are sure are final. This is due to the fact that changing them later in the process is hard: once a user installs a beta release, their profile is created with these settings and removing search engines and protocol handlers from the profile gets tricky. For these reason search engines and protocol handler setup are both called ‘beta blockers.’

When the localization reaches a level at which it’s ready to be reviewed by the community, it is given the beta status and is listed on website under ‘beta locales.’ This is done by modifying the shipped-locales file, which should happen before a code freeze for the next release. (Technically, the changes to shipped-locales are NPOTB, which stands for Not part of the build, so it is possible to land them after the code freeze, but is not preferred.) We also need to modify the product-details files which manage which versions are offered to download on (e.g. on the all.html page). This is done by the WebDev team and the bug needs to be filed a couple of days before the release.

At this stage we can start gathering feedback from the users testing the release. Feedback can be anything: spelling or grammar mistakes, better wording suggestions, font rendering issues, dialog sizes, better suggestions for productization (this is why deciding on the final list in the previous step is preferred – it allows us to gather feedback on productization from users too) etc. This is a very important stage and the feedback that the localizers get from beta users helps improving the quality of the final release.

All fixes to the issues reported by the testers need to be landed in a timely manner before a code freeze. A couple of simple rules should be followed:

  1. Changes to translation on the development branches can be landed freely.
  2. Changes to productization on the developement branches additionally require a review (r+) before they can be landed.
  3. On stable branches, all changes to localization (translation and productization) should be reviewed and approved by the l10n-drivers team.

For example for the 3.0.x branch, if a localizer wishes to modify the translation (e.g. fix a typo), we ask them to file a bug and request a review of the patch. The reason for this is that we want to make sure that 3.0.x builds are green at all times (in case of an emergency in which a ultra-quick build is required to address a security hole, for example). Hence the review&approval process for all l10n changes on the 3.0.x branch.

While the locale is in beta, we also continue to work on productization and web parts. If not chosen before the beta release, we can now choose a news feed that will be featured on the bookmarks toolbar as the live bookmark or select a couple of good and popular news readers that will be offered to the user when they wish to subscribe to a feed. We also focus on the Getting Started page and other web parts, managed by Pascal. Since the web parts are served from the servers, no changes to the l10n code are required to publish them. Consequently, it is possible to work on them even after the code freeze.

During all this time, the l10n-drivers team meet at least once a week for a so called triage call (Tuesdays at 6 PM CET / 9 AM PST) when we monitor and discuss the progress of the de-beta-ing process. We go through open blocker bugs for each locale and update a wiki page on which we track the whole process (for 3.0.x that’s Triage:3.0.x). From time to time we e-mail the localizers to discuss next steps, ask about the current feedback and offer help. We’d like to do a good job in this field, so if you are a localizer of a beta locale, please give us your feedback on how we did in the comments below, by e-mail or via Rypple (it’s completely anonymous).

If statistics are available, we look at the usages figures (ADU numbers and downloads) to see if they are increasing. This is a good indicator that end-users are, at least generally, satisfied with what is available. Finally, when the localizers feel good about their work, there are no more open blocker bugs, the feedback from the users is positive and the testing of the builds under all three platforms hasn’t showed any rendering/display/sizing/other issues, the decision to move the locale is taken. A couple of days before the release the product-details files are changed again to make sure that the locale will be listed as final, not beta (for 3.0.7 the bug for this was bug 480391). The release notes are changed accordingly. And when the release day comes, we party :)

UPDATE: Originally we also intended to de-beta Occitan (oc), which was on the list above, but it turned out that bug 454169 was still open. Stay tunned for 3.0.8! :)

Published on 03.03.2009

Staś Małolepszy

Thoughts about the Internet, the information society, Mozilla and human-computer interactions.

Latest notes