Litmus is a great tool used by our QA community for testing purposes. With a wide range of test cases grouped in test runs, it’s probably safe to say that it covers all aspects and features of Mozilla products. You can read all about Litmus over at QMO, in the Litmus tutorial.

If you want to test your localization of Firefox 3.5 using Litmus, the best place to start is the 3.5 l10n test run. It’s a great way of giving your testing a structure, which will help make sure you cover all localization. It’s also very helpful when testing periodically—by following the test run, you’re sure not to miss anything that you tested last time.

To do a Firefox 3.5 l10n test run for your locale, go to the Firefox 3.5 l10n localizer test run on Litmus and sign in. You can also created a new account if you haven’t already. Or, go to litmus.mozilla.org and choose Firefox 3.5 l10n localizer test run from the list of active test runs. (You may have to click View all available test runs at the bottom of the page first.)

Next, fill in your Build ID, Platform and Operating System, and, most importantly, your locale. Click Submit configuration. On the following page you’ll see testcases subgroups available in this test run. Right now there are no testcases in the RTL (right-to-left) subgroup, so just click Submit in order to proceed.

As of this writing, there are 23 testcases to go through, and for each of them you can indicate a result: not run, pass, fail or test unclear/broken.  Please leave a comment when a testcase fails or the instructions are unclear or outdated.

When you’re done (you don’t have to do all testcases at one time), just click Submit All Results. Congratulations, you’ve just contributed to the testing efforts to ensure best quality of your localization!

There are other test runs available on Litmus, many of them more detailed and more thorough than the l10n test run (e.g. the catch-all test runs). You’re encouraged to perform these tests to provide even more testing coverage for your locale, but generally they’re not required to move a locale out of beta.

You may also be interested in seeing how much testing has already been done for your locale. It’s simple. Just go to the Search Results page, choose your locale on the far right and hit Show Results. You may also want to specify the product, branch and platform, as well as the timespan (e.g. show only tests performed in the last 2 weeks).

If you’d like to have more information about how to use Litmus, be sure to check out the tutorial on QMO. If you have questions, don’t be shy and do ask us in #l10n or #qa.

• Добре дошли, хора!
• Planvenguts umans !
• मनुष्यांचे स्वागत आहे!
• (Welcome Humans!)

Many thanks to Ognyan (Bulgarian), Sandeep and Priti (Marathi) and Yannig (Occitan) for their continuous work on the quality of the localization and awareness of it among local users. The 3.0.9 release is a culmination of weeks and months of the efforts by these guys, both on the localization front (translation, productization, web parts, testing) and the promotional one (advertising the beta builds, getting feedback from beta users, increasing awareness of the browser etc.). Good job!

Thanks for all the bugs we fixed together. Looking forward to working with you again soon on next updates and versions of Firefox.

• 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 Mozilla.com 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 Mozilla.com (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 Mozilla.com 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! :)