L10n:Firefox in 2016

Background: We started the rapid release cycle in 2011, and in the almost 5 years, learned quite a bit about it. Within this document and its children, we'll mention some of the weak points.

This document is about quite a bit of change, for various parts of mozilla involved with developing, localizing, and shipping Firefox (Desktop and Android). FxOS and Fx for iOS are out of scope.

Explaining this will depend in which role you contribute to Firefox, and your personal way of doing so. If this plan doesn't sound good to you, we might have not explained it for you yet. Please raise questions in L10n:Firefox in 2016/FAQ.

Engineering Changes

Jumping right in to it. As everybodies head is wired slightly differently, here are three ways to look at it:

An English string exposed for l10n begins its life cycle in mozilla-central, and lives and dies until it merges to Aurora. At that point, it's frozen until the end of its lifetime, which comes when we stop shipping any version that has a code path using that string. As long as code on any of aurora/beta/release/esr use a particular string, it can't be removed.

Or, in sets:

All English strings that we use in any shipping version (aside Nightly) on any release channel are in the hg repository for aurora and central.

• A string in ESR is also in aurora and central.
• A string in release is also in beta, aurora, and central.
• A string in beta is also in aurora and central.
• A string in aurora is also in ... right, central.

In reverse,

• central has all the en-US strings from central, aurora, beta, release, esr;
• aurora has all the en-US strings from aurora, beta, release, esr;
• beta has all the en-US strings from beta, release;
• release has all the en-US strings from release;
• esr has all the en-US strings from esr.

What do we win?

There's only one l10n repository (per locale) to localize all versions of Firefox we're currently shipping. Localizers have one place to add strings, and to supply fixes. Localizers can also freely change if they want to work on central or aurora.

For Developers

How do we get there? When changing existing strings, we need to add the new version, with a new ID like we used to. Just that we don't remove the old one. In detail, this only affects strings that are already on aurora. Strings that landed only after the last merge day can be safely removed, as they're not in any other channel, i.e., neither aurora nor esr.

We'll have tests and/or hooks to help validate these rules.

Each cycle, we'll go and remove strings that were only in the version(s) we stopped shipping. Having automation to support this process is part of the engineering efforts to implement this plan.

For Localizers

Localizers will work on one repository per locale, with compare-locales giving results against ESR, release, beta, and aurora. Instead of landing strings in different repositories, the l10n work lands in one repository, with the different en-US repos giving information about the urgency of the strings in question.

Localization Tool Changes

Parallel to the changes to how we expose strings to localize, and get them back, we're also expecting a series of changes coming to the tools that localizers actually use.

Interaction with VCS will become bidirectional. Localization tools like pontoon and pootle will save their work with attribution of the localizers to version control (hg). They will also read back changes from version control into their own databases. This will include support for refactorings and format changes.

Localization Infrastructure Changes

We'll see use of l20n rise incrementally in Firefox-related development. This will include a new paradigm for how to get strings from l10n.

• Retrieving a localized string is fallible
• Retrieving a localized string is asynchronous
• Retrieving a localized string falls back over a list of languages at runtime

Being able to fall back at runtime, and doing so without blocking mainthread IO, will decouple the localizations we ship from the binaries they're running against.

Installers

There will be experiments to create multilingual installers on all our platforms for desktop. The intent of these is to be performing at least as good as the language choice UX we offer on the web via language negotition there, and serving single-locale installers.

This project needs an owner, and might start out in native UX land. We also need to ensure that the metric we use to decide go-nogo has a sound baseline in our current installers.

Not Changing

There are even things that don't change.

Version Control

Version control and hg.mozilla.org in particular will remain the canonical source of truth for which localizations we ship, and in which state.

Sign-off for Official Branding Builds

We'll continue to use a known-good revision for each localization to be shipped to channels with official branding.

This allows us to do technical reviews based on source code diffs, and linguistic testing in non-branded builds in parallel.

TBD

A few topics haven't yet been discussed with all stakeholders, or don't have all data we need. For those, we need to have conversations and/or collect data.

Shipping l10n updates to release/ESR

With the single repository containing release strings, we have the opportunity to ship updates to localizations to release audiences, in particular to ESR.

• needs agreement with release management

Aurora Channel

There's an open question which value the aurora channel provides to l10n going forward. Right now, it looks as if localization needs more time and not less. But that might be skewed by the fact that we're not exposing strings on a continuous basis. We should measure contributions frequencies in the new model, and reap benefits where they appear.

Bugs

As we get to having bugs that actually track engineering tasks, we should have a table below that shows the status of these.