This guide provides details on what a localization technical review is, what criteria are used for the technical reviews, and the process for requesting one and following its progress.
The technical review process we use for new localizations can be confusing for any trying to start a new localization. We use this review process to perform quality assurance (QA) testing on your L10n efforts. This ensures that every user who downloads your localized Mozilla application receives all of your hard work in a functional product. Each QA review helps us in these ways:
- Ensures that your L10n work is visible and functional within the Mozilla application.
- Allows us to understand how each L10n team is performing their localization work.
- Allows us to discover potential bugs within L10n tools.
Overview
You've completed most, if not all, of your localization work. The merge date for migrating from one product release channel to the next (e.g., aurora to beta, or beta to release) is rapidly approaching. You need to make sure that your work can effectively be compiled into a build for the next release channel. Here is a detailed overview of what a technical review is and who it's meant for:
A technical review:
- is performed as a QA measure on a revision pushed to a new locale's L10n aurora repo in Mercurial.
- is very comprehensive and covers the entire product.
- focusses on technical accuracy and completion of L10n work, not translation quality.
- is only performed on the first revision a new locale wants to have released to the public.
- must be approved prior to migrating your revision from Aurora to Beta.
Technical review evaluation criteria
In principal, a technical review's criteria looks for localization issues common to localizing software but within the Mozilla context. Since it is performed on the first revision a L10n team proposes for release, this first revision requires a very detailed and comprehensive form of review. That being the case, there are some criteria in a technical review that will only ever be considered once, as all reviews after this only evaluate the changes you're adding on top of this revision from release to release.
Here is some of the criteria we use to perform technical reviews:
- Revision attachment contains only relevant files
- We run into exports that contain
.xpilangpacks and other random files. Make sure the top-level directory doesn't contain garbage. - compare-locale
- We run the compare-locales tool on the new locale to get the statistics on translation of strings and report basic errors.
- defines.inc
- The file for each app (like
browser/defines.inc) contains the names of all contributors that a localization team would like to credit the work to. Localizers can specify the team responsible for the work by listing the name just after theMOZ_LANGPACK_CREATOR. The team can also wrap contributors with<em:contributor>tags just after theMOZ_LANGPACK_CONTRIBUTORSsection. Make sure that the the text content is wrapped with emptyLines. Leading comments are OK, but watch out for#filter emptyLines #define ... # comment #define ... #unfilter emptyLines
In
toolkit/defines.inc, the native name of the language is specified, which is used as description for the built language packs. - region.properties
- Though locales might like to specify changes from the beginning, the
region.propertiesfiles will be reverted to en-US. Changes will be discussed in productization bugs filed for each locale. - Search plugins
- Similar to the
region.propertiesfiles, thelist.txtfile should be reverted to en-US and amended accordingly as the search plugin productization bugs are completed. For this initial review, all XML files should be removed. - String lengths in pipnss.properties
- There are some character limits in the
security/manager/chrome/pipnss/pipnss.propertiesfile that you should be aware of. It is best to look into each of these files to see if the localizer's strings might be too long. This is something to look for, but can be difficult to diagnose immediately. For more info, see bug 435874. - Check for bad migration of access keys
- In the past, it was common to find broken access keys for Safari and Camino in
browser/chrome/browser/migration/migration.dtd. For this review, we look at this file to make sure that the access keys look normal. If they don't, we report any strange access keys or translations that localizers might have changed during their initial translation process. For more info about access keys in the technical review process, see bug 421893. - No UTF-7 in the intl.properties file
- Firefox no longer has a UTF-7 parser. There should not be any UTF-7 encodings in the file
toolkit/chrome/global/intl.properties. For more info about UTF-7 in Firefox, see bug 441876. - More intl.properties checkpoints, cont
- We also check the plural rule for the locale, that the
general.useragent.localeis set to the locale code, thataccept-langshows the locale code(s) (like ab, ab-CD,...) and is followed by en and en-US, and finally thatintl.menuitems.insertseparatorbeforeaccesskeys = true, where "true" should be left untranslated. - Inspect firefox-l10n.js
- We ensure that there are no odd preferences, or
#filtersubstitutions forgeneral.useragent.locale. Most locales should have the following:
#filter substitution
pref("general.useragent.locale", "@AB_CD@")
How it all works
A large part of the review process takes place before you even submit your request for a technical review. To put it simply, when we receive your request, we expect that you have spent time testing your work and making sure all strings have been localized and that your language pack is relatively functional. Your review request symbolically represents that you have worked on your localization, tested it successfully, and found it to represent the best of your work. So before you request your technical review, be sure that it is as ready as it can be.
There is a specific process to follow in Bugzilla for requesting these reviews:
- File a bug requesting the review.
- Attach your files to the bug. Once attached, open the attachment details.
- In the attachment details, select the ? from the dropdown menu next to the review flag. This will display a text box to assign the review to someone.
- Enter :Pike as the Requestee.
We will perform a technical review of your work and provide you with feedback. We're happy to work with you to make sure that your work is fully functional.
Tracking your progress
You can track your reviews progress two ways: within the bug and through your team's dashboard.
If your work is approved, you'll see a + review flag next to your attached revision in your request bug.
If bugs are discovered, your technical review is rejected (- review flag) and the bugs are filed in Bugzilla. Once they are fixed, push your fix to your repo, attach it to the corresponding bug using the same Mercurial revision number as before, and then request another review. The process is then repeated until the bug is fixed to satisfaction.
These bugs are also pulled into the dashboards, which track your revision's progress. In order to ultimately have your revision included as an official build, your dashboards must be at 100% green.
To the right, you'll see the current dashboard page for a German localization. Revisions are approved using the buttons in the furthest column to the right.
As your work is approved, you'll see a green circle in the furthest column to the right as well as a measure of percentage in the middle column.
First round approved!
Once your work is entirely approved, go out and celebrate! You've accomplished a massive undertaking and you deserve to be rewarded! Go grab a drink with friends and enjoy your latest success!
After you've finished celebrating your first approved release, it's time to start planning for the next one! When you update your localization for the next release, you'll need to put it through a different form of QA review called a sign-off review. Visit the wiki page for sign-off reviews to learn what's involved when maintaining a localized Mozilla product.