L10n:B2G/Adding Locales

Here are the steps to follow by l10n drivers to add a locale to Gaia.

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 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.

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. [NEEDINFO] timdream?

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, 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.

Edit locales/languages_all.json in Gaia. Native language names can be found in the product-details lib.

Edit shared/resources/kayboard_layouts.json to enable the desired layout during the FTU setup.

See bug 838516 for example and the corresponding pull request.

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.

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] ?

Marketplace

This product has a lot of legacy content. As a result, the priority of product readiness is currently defined as such:

• P1: Fireplace - frontend, and consumer pages - must be ready
• P2: Webpay - payment system must be ready (through Mobile partner at the backend)
• P3: Zamboni - can be ready over the course of time even after product launch. Content is being updated on a weekly basis.

Content

Relevant apps on the marketplace [NEEDINFO] ?

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] {{{1}}}

Website

[NEEDINFO] ?

Sumo

[NEEDINFO] ?

Ready-to-ship criteria

QA

We have internal QA procedures we should go through, and our partners may as well.

 Methodical testing of String overuns.
 Performance Evaluations of adding one more locale
 other test plan and test automation areas
 ...
 ...

[NEEDINFO] delphine