Moving a locale out of beta
For the upcoming release of Firefox 3.0.5, we will be moving 5 languages out of beta into official translations of Firefox. These include the following locales:
- bn-IN, Bengali
- eo, Esperanto
- gl, Galician
- hi-IN, Hindi
- lv, Latvian
It’s fair then to ask just what we do to assess whether a language is ready to be moved out of beta and into official status. When we release a new language, we place them in beta so users of this new translation know that it is a new version and might contain errors. Over the course of the next few months and leading up to the next Firefox update, we encourage our localizers to test their versions and provide feedback to us so we can assess whether or not to move the langauge out of beta. I typically ask localizers to answer the following questions:
- Has the localizer been able to ‘advertise’ the localization so others know they are available for testing during the beta period?
- Has there been any press or blogging activity to generate visibility? Can Mozilla help on this?
- Has the localizer gathered feedback from end-users? Is the feedback positive and do end-users believe that the release is ready to become ‘final’?
- Does the localizer have access to systems or volunteers to help with testing coverage of builds on all three platforms (Mac, Windows, Linux)?
- Are there any outstanding blocker bugs (or other bugs) that the localizer or community has filed that need to be resolved before moving out of beta? If so, what are the bugs and known issues?
- Has the localizer been able run, or have plans to run, any specific or targeted tests to check things like:
- General “smoke tests” to check the operation of the build to make sure all parts of the UI are working as expected? Mozilla has Litmus (http://quality.mozilla.org/node/71) and this is a good time to create a test group and create tests for each locale.
- Dialog sizing checks?
- Spell or grammar checking tests the correctness and accuracy of the translation?
Once the localization teams have provided responses to these questions, we can together assess whether or not they are ready for final version. To help with QA and testing, we are presently conducting a study with our localizers to learn where the community needs support and where/how they are doing testing. We will publish results by the end of this quarter.
Have you taken the Mozilla QA/Testing survey? If you are a Mozilla localizer, please take it. Follow this link to the survey.
I would also recommend that anyone using PO files to localise Firefox also run the Translate Toolkits QA tests as follows:
pofilter –mozilla po-files/ po-files-check/
#Review all PO files in po-files-check and fix errors
pomerge -t po-files po-files-check po-files
These steps are best done against files stored in a version control repository.
We maintain a list of the QA checks here:
http://translate.sourceforge.net/wiki/toolkit/pofilter_tests
Ones that are most interesting are:
* XML checks – makes sure you don’t destroy any XML, in many cases human QA won’t find these they’ll only appear after you move out of beta when you get a flood of users.
* Variables – ensures you haven’t inadvertantly translated or mistyped a variable.
* Cosmetic – extract unchanged messages so that you can review them, spellcheck, overly long, emails, filepaths, etc, etc
Many of these are impossible to find as a human since we quickly fuzz out when looking at text and can stare at errors without even realising it.
Give it a whirl. When we first started checking translations we found errors in official languages. So you definately won’t regret the effort.
If you’re in beta it might even win you some points with Seth on his activity scale to get you out of beta.
A direct link to pofilter itself:
http://translate.sourceforge.net/wiki/toolkit/pofilter