L10n:Review notes: Difference between revisions

Every time Mozilla receives a new localization for review, the l10n-drivers team must evaluate the status of the work to make sure it is ready for inclusion into the official build and release process. 

 

; defines.inc : This file contains all contributors that a localization team would like to credit with for the work.  It should be correct for both toolkit and browser.  Localizers can specify the team responsible for the work by listing the name just after the MOZ_LANGPACK_CREATOR.  The team can also wrap contributors with <nowiki><em:contributor></nowiki> tags just after the MOZ_LANGPACK_CONTRIBUTORS section.

; region.properties : Though locales might like to specify changes from the beginning, the region.properties files will be reverted to en-US.  Changes will be discussed in [https://wiki.mozilla.org/L10n:Firefox/Productization productization] bugs filed for each locale.

; searchplugins : Similar to the region.properties files, the list.txt should be reverted to en-US and amended accordingly as the search plugin productization bug is completed.  For the initial review, all xml files should be removed.

; string lengths in pipnss.properties : There are some limits in [http://mxr.mozilla.org/mozilla-central/source/security/manager/locales/en-US/chrome/pipnss/pipnss.properties security/manager/chrome/pipnss/pipnss.properties]. See {{bug|435874}} 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.

; bad migration of access keys : In the past, it was not uncommon to find broken accesskeys for Safari and Camino in [http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/migration/migration.dtd browser/chrome/browser/migration/migration.dtd]. See {{bug|421893}} For the review, we look at the above file to make sure the access keys look normal and report any strange access keys or translations that localizers might have changed during their initial translation process.

; No UTF-7 in the intl.properties file : Firefox no longer has a UTF-7 parser.  There should not be any UTF-7 in the file toolkit/chrome/global/intl.properties, see {{bug|441876}}

; More intl.properties checkpoints, cont : Check the plural rule for the locale, the general.useragent.locale is set to the locale code., accept-lang shows the locale code(s) (like ab, ab-CD,...) and is followed by en and en-US, and that intl.menuitems.insertseparatorbeforeaccesskeys = true (where "true" is not translated...many locales will translate the word true).

; Inspect firefox-l10n.js : No odd preferences, #filter substitution for general.useragent.locale.  Most locales should have the following: