Users first, no matter where they are

Process changes for releasing new locales

There are a bunch of new teams out there who have been waiting on progress. Sorry for the wait, but here’s what you’ve been waiting for.

We changed a few things around releasing new localizations. Many things did not change, but I’ll start off with the new.

We’ve redone the process points from review request to being on the rapid release cycle. The purpose was to put less emphasis on the bugs and the technical details, and more emphasis on the l10n dashboard.

We hope to get to a point where localizers are working on the aurora branch on each cycle, and the contribution gets wider testing on beta, and then seamlessly goes to release. We want to have most things lined up before going into aurora and having aurora ready in one 6 week period. Then migrate to beta, get wider testing, and on the same version go to final, if the community review passes.

To do that we did the following:

dropped the requirements to have new contributors do search engine patches, etc. We’ll need your input on what services to hook up, but Milos will do the technical implementation. We also call these “productization bugs”.

be more crisp on what’s required on the web site. Sure, you can do more, but we’ll set you up with what’s required, and nothing more.

And again, we put your team page front and center. That’s where you find what’s up to do, in the initial phase and beyond as we move from one cycle to the next.

Things that did not change:

We still only start taking your contributions upstream if they’re close to done. We don’t have a setup where we can take the first 20% and then care or not.

The tooling story is as difficult as before. Right now, narro is tougher than the locamotion (Pootle) setup, but none are without serious caveats.

The next batch of localizations we’re taking is going to ride along Firefox 18, coming on to Aurora next week.