L10n:Driving
From MozillaWiki
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
- Make sure project owners follow the instructions for getting their projects localized.
- Document important procedures, se wo can carry on the project in case someone goes on holiday, etc.
- Release cycle of the project should give localizers enough time to finish their work before each release (aim at minimum 2 weekends).
- 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.
- 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.
- 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?
- Extract strings and merge them with existing translations.
- README file on how to run the scripts will come in handy.
- 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.
- 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.