L10n:B2G

WIP version: https://l10n.etherpad.mozilla.org/b2g-masterplan

String freeze

The string freeze will happen in two phases. Apps and system pieces are owned by Moz, unless indicated otherwise.

Bucket 1 (September 28)

Apps

• Browser
• Calculator (no strings?)
• Camera
• Clock
• Contacts (TEF)
• Dialer (TEF)
• FM Radio
• Gallery
• Lock
• Music
• PDF Viewer
• SMS (TEF)
• Video

System

• Keyboard

Bucket 2 (freeze date TBD)

Apps

• Calendar
• Cost Control (TEF)
• Email
• Notes (3rd party)
• Settings

System

• App Install
• App Updates
• App Security (prompts should live within individual apps)
• Bluetooth (pairing prompts, etc)
• Cost Control (non-app elements, such as Utility Tray widget)
• Errors (eg: app crash)
• First Run Experience
• Home (Moz + TEF, including Search)
• Status Bar (Utility Tray is the relevant component)
• System Overlays (eg: Low battery, etc)
• System Updates
• Trustworthy UI (still unclear how this will come together. Will know more by 9/21)
• Wrapper

Unknown

Am not clear on who handles the following:

• Identity (part Gaia, part Marketplace)
• Marketplace (all Marketplace team?)
• Payment (part Marketplace, part payment processor)

Changing strings after the string-freeze

(This is sometimes referred to as the gecko dance.)

Step 1. File a bug

If you need to change a string (add, remove or edit) after the string freeze, please file a bug in Bugzilla in Boot2Gecko > Gaia and add the late-l10n keyword. This is done for better transparency and archiving purposes. Each change post-freeze will need to be reviewed by the l10n-drivers.

Step 2. Change the string and its identifier

When changing a string post-freeze, you will need to change the identifier of the string so that the l10n toolchain picks up the change and notifies the localizers.

For instance, if the "Clear History" button is changed to clear both history and cookies, you'd need to change the ID of the string from

 clear-history=Clear History

to

 clear-history-and-cookies=Clear History & Cookies

(and the same in the HTML code).

It's preferred for the new ID to reflect the new meaning of the string but in some cases, especially for less impacting changes, you'll want to simply bump the ID revision, i.e. clear-history2.

Step 3. Attach a patch and request a review

Attach a patch to the bug. A simple way of generating the patch is:

   git diff master...your-feature-branch [FILE]

Please request a review of the patch from :stas.

After an r+, continue as you'd normally do to get your pull request merged in.

Plurals

For plurals, we're using the Unicode CLDR spec with a slight modification to how we handle the zero, one and two cases.

Unicode defines the following cases for plural forms:

    zero, one, two, few, many, other

Not all languages use all of them, for instance English only needs "one" and "other", but we still need all the cases present in the .properties files. Read on to see why.

The list of cases for all languages can be consulted at http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html.

Editing .properties files

Here's how to use plurals in .properties files.

    unreadMessages={[ plural(n) ]}
    unreadMessages[zero]=No unread messages
    unreadMessages[one]=1 unread message
    unreadMessages[two]={{n}} unread messages
    unreadMessages[few]={{n}} unread messages
    unreadMessages[many]={{n}} unread messages
    unreadMessages[other]={{n}} unread messages 

"n" is a variable passed by the developer. The first line defines a call to the plural rule macro. The macro is defined in the l10n library and is based on Unicode's CLDR, so you don't have to define it or choose you yourself.

The plural rule checks the value of "n" and returns an index. E.g. if "n" is 3, for English the rule will return "other", and the string will be translated as "3 unread messages".

Explode all the cases, always

In the example above, note that even though some of the strings are repeated and redundant, you must include all six cases in the .properties file.

This is because compare-locales relies uniquely on the presence of keys (or identifiers) in the files it compares.

The number of keys needs to be constant. We always explode all plural cases (zero, one, two, few, many, other), even if your locale requires fewer cases. See the example for English above: "two", "few", "many" and "other" are exactly the same, but we'd still to have all of them present and accept some redundancy. Otherwise, compare-locales would report Slovenian's unreadMessages[two] as obsolete, and we don't want that!

Special cases for zero, one, two

If "n" is 0, 1 or 2, we can use the [zero], [one] and [two] indexes respectively, even if the plural rule returns something else. For instance, the English plural rule returns "other" for 0, but we can detect that unreadMessages[zero] exists and is not empty and use it to say "No unread messages" instead of a more generic "0 unread messages" in order to create a better user experience.

Same thing would happen for 1 and 2, although if your locale uses the same grammatical plural form for multiple numbers, like [one] for 1, 21, 31 etc., you'll have to remember to use "{{n}}" in those strings and not a literal "1" or "2" (or "eins", "zwei" etc.).