L10n:Driving

This document is an internal resource for L10n drivers, helping them manage localization of various projects. If you are interested in getting your project localized, take a look at the New Projects wiki.

The process

1. Make sure project owners follow the instructions for getting their projects localized.
2. Document important procedures, se wo can carry on the project in case someone goes on holiday, etc.
3. Release cycle of the project should give localizers enough time to finish their work before each release (aim at minimum 2 weekends).
4. Review English source strings.
   • You have a good chance of catching obvious errors, which will make you break the string freeze if you don't fix them in time, which requires extra communication, PO extracting, Verbatim juggling etc.
   • Common mistakes: spelling, double spaces, almost duplicate strings, unnecessary escaping.
   • A python script to check for similar strings will come in handy.
   • Project owners should request a review by QA.
   • Jeff is also happy to help.
5. Pick the opt in mechanism: webby or the mailing list (dev-l10n-announce, dev-l10n-web, dev-l10n). We don't give localizers access to strings automatically, there are several reasons for this:
   • Get a decision process triggered in the communities and a commitment to follow up.
   • Statistics: we need a descent status for the project across locales, localizers need motivation.
   • We don't want to look like we're imposing projects onto communities.
   • In Verbatim, adding 100 locales means clicking 100 times to add each one separately.
6. Reach out to localizers on the appropriate mailing lists.
   • What is the project about?
   • Are we targeting all or only specific locales?
   • How many strings and/or words are there to be localized?
   • When is the deadline and what does the release cycle look like?
   • Web projects: where is the staging server available for localizers to review their work?
   • Where can localizers opt in?
7. Extract strings and merge them with existing translations.
   • README file on how to run the scripts will come in handy.
8. Handle localizers' requests for string changes.
   • Decide if you want to break the string freeze or move them to the next release.
   • Connect localizers' requests with project owners or change strings in the codebase on your own.
9. Prepare the list of shipping locales for project owners.
   • Make sure that localizers are aware of the shipping policy (do we ship incomplete locales?).
   • If we also ship incomplete locales, let localizers know how to sign off (usually on the mailing list).
   • In Verbatim, a script can be used to get the list of fully localized locales.
   • In Verbatim, some locales might be at 100%, but they forget to commit to VCS. Identify such locales with the help of a script.

Working with Verbatim box

If the project uses Verbatim, Verbatim Administration Dashboard allows you to perform most of the tasks. But some operations (e.g. adding new locales to projects) require access to the Verbatim box.

• You can only ssh to sm-verbatim01 while connected to Mozilla-MPT VPN network.
• For easier access to strings, link them to your home directory:

   ln -s /data/www/localize.mozilla.org/verbatim/pootle_env/Pootle/po po

• When working with SVN, switch to "verbatim" user:

   sudo su verbatim

• To add a locale to a Verbatim project:

   1. Add it through Administrate tab in Verbatim (check "Update from templates" box).
   2. SVN add and then SVN commit the new locale folder.

• To avoid committing all uncommitted translations from Verbatim DB to SVN, make sure you commit only what you need, e.g.:

   svn ci sl -m "Adding Slovenian for browserid"