L10n:B2G/Adding Locales
Here are the steps to follow by l10n drivers to add a locale to Gaia.
Contents
Prerequisites
Before being able to pursue a localization effort, there are a few requirements that need to be met. They're not in any explicit ordering, and the ordering might depend on locale. In particular, a few open spots in font support are probably best fixed once the localization effort is on the way, whereas complete lack of font support probably means that the localization effort doesn't need to start until there's progress on the font front.
Localization Team
Someone needs to do the actual initial and on-going translation work, of course. A team of two or three is healthy, and it's best if the motivation to start the effort comes from the community itself. See L10n:Teams for existing teams to reach out to. We should make sure that there's no detriment to already ongoing projects. This section also includes setting up the technical infrastructure things listed below as well as setting up bugzilla components and contributor accounts if not yet established.
Fonts
It's not clear which font combinations we need to test, but fontconfig's fc-validate is likely the right start. Axel also has a project on [1], but the examples don't work against the current font setup.
fonts.mk in https://github.com/mozilla-b2g/moztt has which Android and which moztt fonts we're using. Axel's investigating fc-scan now.
Keyboard/IME
We need keyboard support for new languages, both in terms for keyboard layouts, as well as typeahead wordlists for at least alphabet-based languages.
For alphabet-based languages, we need the basically three things:
- Keyboard layout [NEEDINFO] UX
- wordlists for typeahead. Ask Kevin Scannell for help, he can create word lists for 1500 languages, pick your poison
- an actual implementation. Probably good to just file in the keyboard app component.
For non-alphabet languages, we need real input methods (IME).
i18n
We need things like collations for sorting, date formatting, number formatting, search capability with relevant result in target locale. Email/SMS sending and receiving displays correct font rendering. JS i18n API will help with some of that.
Technical Infrastructure
Create the repository
File a repository creation request to get the repository created. See bug 834221 for an example. Note that this only creates the mercurial repository.
Push to the repo at least once before you enable the locale in Elmo. For example, you could push a README file, similar to this:
This directory contains the vi locale for Firefox OS. For English files, see https://hg.mozilla.org/gaia-l10n/en-US/
(See example.)
Add to Gaia
When the locale is actually ready and approved to be included in b2g builds, several additional steps need to be performed.
- File a bug requesting the locale be mirrored to git.mozilla.org (see bug 897581 for an example of gaia only request). If you also need localized gecko strings, include that in the request. Be sure to include the FFOS version numbers for which the locale should be enabled.
- Wait for the repository bug to be resolved. The builds will break otherwise.
- Make the following modifications and obtain approvals:
- Edit locales/languages_all.json in Gaia. Native language names can be found in the product-details lib.
- Edit build/config/keyboard-layouts.json to enable the desired layout during the FTU setup.
- After approval, file the corresponding pull request. See bug 838516 for an example.
- per clee, when a new locale is enabled in a given branch, we need to also enable that locale on all newer branches (for example, adding a locale to v1.2 means also adding it to v1.3/master). This helps with updates, amongst other things.
Add to Elmo
Edit l10n-master/dir-builds.json in master-ball.
See this pull request for an example.
Localization work
The localization work consists of doing the actual l10n work, but it also consists of testing the work on a device. There's no food like dogfood.
l10n
The actual localization work is done by the localization community. We're talking about 2700 strings, so there needs to be a significant amount of time allocated for this.
Doing sprints can help, with the help of Reps and community engagement.
e.me
everything.me is a mix of server-side localized content by e.me, and content hosted in homescreen l10n. [NEEDINFO] ? for getting a specified behaviour. See also bug 855119#c31
testing
Nothing compares to actually using the localization as the real product. We need to get real hardware in the hands of volunteers that either participate in the l10n work, or have close ties to them.
- Ensure capacity for the right hardware
- Ensure that we can actually ship it to people, taxes, import regulations
- Possibly reimburse stock hardware bought locally
- Possibly involve local partners to help with the distribution of test devices
Related projects
Depending on whether the localization targets a new market or an existing market, some of these projects might be dealt with, or have good fallbacks.
3rd party apps
These would be apps we're bundling on the device like maps, etc. [NEEDINFO] ?
- list of apps that are bundle to all phones
- list of partner specific apps, which has what. A table might be good to illustrate this.
Marketplace
This product has a lot of legacy content. As a result, the priority of product readiness is currently defined as such:
- P1: Categories: This is the first thing a user see after clicking the category button. This component lives on the "addon" side of the repo.
- P1: Fireplace - frontend, and consumer pages - must be ready
- P2: Webpay - payment system must be ready (through Mobile partner at the backend)
- P3: Zamboni (AMO) - can be ready over the course of time even after product launch. Content is being updated on a weekly basis.
- P4: Communication Dashboard: This is front-end code for the developer communication dashboard - a dashboard which enables communication between reviewers and developers about their apps.
- P5: Rocketfuel: This is a management tool for curators and operators to adjust featured apps, collections, and "operator shelves."
Content
We do have local content/app available. Marketplace inventory suggests that we have over 1000 apps [2] as of July 2013.
Many developers submitting the apps choosing en-US or en as default language, which is counted as such as of now. However, many known apps do offer other languages, but are not indicated so in the manifests. For example known apps such as Wikipedia, Facebook, Twitter are offered in many languages.
Some apps are developed in non-English to start off. Search capability to locate these apps in target language is key.
Legal docs
Some documentation like privacy policy and TOS may need to be translated, within specific legal constraints. We'll need an established process [NEEDINFO] ?
- Need to list all en-US legal doc URLs here
- Legal decides which one(s) must be localized/customized
- List all sites that have legal links/footer for QA purpose.
- There are several versions of Privacy policies:
- FFOS - Marketplace (customized content per locale) - e.me (e.me) - Partner specific (partner)
Website
[NEEDINFO] ?
Sumo
[NEEDINFO] ? Peiying to speak to Ibai Garcia on this soon.
Ready-to-ship criteria
QA
We have internal QA procedures we should go through, and our partners may as well.
Internal procedures
- Methodical testing of String overruns
- Methodical testing to detect any un-localized string, hardcoded strings, etc
- Performance Evaluations of adding other locales
- Test plans (screens pass, internationalization issues, notifications, late-l10n) and test automation areas (automation using Marionette is a work in progress)
- Regular testing of Partner Builds, to verify l10n changes are correctly uplifted from the Mozilla Builds
- Verifying the resolved l10n bugs
