About continuous localization at Mozilla, and update on Test Pilot localization process

[Francesco Lodolo [:flod]]

Hi,
As anticipated in the discussion about the project on dev-l10n-web, Test
Pilot will use a 2 weeks cycle development; the update is that strings
will be exposed as they become available during the development instead
of being exposed in mass at the end of the cycle. We’ll keep educating
developers and review strings before they land, so content that will
reach you should be in reasonably good shape.

This change means that you will frequently see new strings in the
project available for translation, even if they will be used in
production at the end of the cycle. It might seem that the volume of
work is increasing, but the overall number of strings doesn’t change; on
the other hand, you gain in flexibility and will be able to better
decide when to work on translation.

This “continuous localization” approach is going to be used very soon in
Firefox, with the coming of cross-channel localization[1]. We believe
it's important to adopt this change and, for each of you, identify which
of its strengths play in your favor. It might require a mentality shift
in the way you approach translation tasks, and maybe even in workflows.

In our view, continuous localization means:

* Being able to expose good strings as soon as possible.
* Make them available quickly for testing, potentially in minutes
(think for example of this video
https://www.youtube.com/watch?v=16fN3EdwVmg)
* Ship localization updates often to users.
* Allow localization teams to better plan their work during the
development cycle.

Continuous localization doesn’t mean:

* Opening the localization to just anyone. We trust our localization
teams are contributing a high quality product and we don’t plan to
change that.
* Lowering the quality of the products we ship.
* Allow half-baked features to be shipped, and iterate over and over
to improve them.

We believe that this change will make localization more approachable to
existing and new localizers and will help us ship better localized
products to our users.

What’s the impact of this new approach on localizers? Having new strings
every few days means that dashboards will be rarely green; it’s crucial
to understand that this is fine. This will also represent a good
opportunity to involve new contributors: during our hackathons we’ve
often heard the observation “they approach us asking to localize, but we
have nothing to give them to work on”. This will change in a continuous
localization scenario.

This new approach to localization is going to be challenging, we are
aware of that, and will work with you to make it sustainable. We're
constantly improving our localization tools, Pontoon and Pootle, making
them more reliable and easier to use. We’re working on establishing a
complete “feedback cycle”, to give you a chance to truly review
suggestions instead of just rejecting or approving them and making these
tools a self-contained environment to translate, perform QA, and train
new localizers.
Our tools keep improving also thanks to the feedback and direct
contributions of several localizers. Thanks for that!

Manual workflows are going to become painful and high-maintenance, and
that's the reason we want Pootle and Pontoon to be usable alongside your
existing process. That’s already possible with Pontoon – you can work on
both version control (Mercurial, GitHub) and Pontoon, translations will
be automatically synced between them – and this will be available in
Pootle in 2017.
At the same time, don't forget that manual workflows constitute a steep
entry barrier for new contributors, and that’s not something we should
encourage as Mozillians.

This is one of the biggest changes to come to the Mozilla localization
process. We’ve thoroughly enjoyed speaking with you at hackathons, over
the blog, and mailing lists about all of the components of continuous
localization that we’re working on. We’re happy to see Test Pilot serve
as just that, a test pilot for our theories about continuous
localization. As with all new projects, please let us know where the
pain points are (or the pleasant surprises) and we’ll work to improve.

Francesco

[1]
https://blog.mozilla.org/l10n/2016/11/03/goals-and-vision-for-mozilla-l10n-2016/