L10n:Becoming an Official Localization: Difference between revisions

* language-specific upgrades to the latest version releases for each release channel

* localized web services experience (e.g., search, RSS Readers, RSS Feed/Live Bookmark and content handlers).

[http://mozilla.github.com/process-releases/draft/development_overview/ Mozilla's rapid release cycle] gives L10n teams six weeks to localize the latest version of Firefox and other products before they are officially released. Each release channel represents a different stage of development and thus requires a different type of work for each L10n team. Once a team's work has been approved for inclusion in these release channels, it is critical for the teams to continue to localize and fix bugs in the appropriate channels for each release.

Once L10n teams have largely completed their work for a Mozilla product, it becomes the L10n drivers' responsibility to review that work for it to be added to the rapid release cycle. This can be a tricky process, as once a team's work is approved, they are expected to localize within the appropriate channel for each new release of that Mozilla product.

Many people have described the rapid release cycle as a train. A L10n team's first localized build is like the head of a train, and each additional version after that is another car added to the train. Essentially, once the head of the train begins to roll forward, all of the cars follow it. New cars (i.e., new versions of the product) are added while it's in motion within each channel, meaning that the train does not stop for any car.

At Mozilla, we have four release channels: <b>Central</b> (which produces the Nightly build), <b>Aurora</b>, <b>Beta</b>, and <b>Release</b>. Builds of the product are pulled from locale-specific code repositories stored in hg (our version control system for Mozilla products).  

When a L10n team is ready to put their train in motion (i.e., produce their first, official, localized build), a locale registration bug is created and their localized code is placed into a L10n repository (repo) within hg. This is typically done by the L10n drivers. The first builds are Aurora builds pulled from their repo in the <b>Aurora channel</b>. This is the channel in which the team will localize each new version (i.e., train car. Becoming clearer?), every six weeks. Once their L10n work is done for each version, it is submitted for review by the L10n drivers.  

While the L10n team's work is under review, their builds are migrated to the Beta channel. If problems are discovered during review, they are filed as bugs and the L10n team fixes them in this channel. As with Aurora, they have six weeks to fix all bugs. If they're successful and pass their review, their beta builds are migrated to the Release channel.

If this is a L10n team's first official release, the review may take longer because of the larger amount of work to be reviewed. In addition, it is possible that the first Beta build may not be approved to move to the Release channel by the end of the six week Beta period. This is why it is absolutely necessary for each L10n team to continue localizing on Aurora, even if their first build is currently under review in another channel. This ensures lasting stability for the localization and reduces the overall amount of new source strings that each team will have to localize for each new version.

This channel is also where the L10n drivers monitor the total number of downloads for a new L10n team's work. It's what we call the user experience review (which you will learn about in just a bit). This helps us determine the demand for the language. The more Beta downloads, the more likely the build will be approved and migrated to the Release channel. The fewer the downloads, the more likely the localization will be released as a language pack instead of an official build on the Release channel.

Congratulations! Making it to the Release channel is the culmination of all of the L10n team's hard work! If a team has a build distributed on this channel it means that they have:

*100% completed their L10n work,

*resolved all bugs filed in Beta,

*recieved a green light approval on their reviews,

*begun localizing subsequent versions of their Mozilla product on the Aurora channel,

*earned a huge celebration!

From this point forward we will consider the L10n team officially responsible for their L10n effort (they should consider this a several year commitment). Mozilla is a community project and as such, we understand that each contributor's schedule has more on it than just Mozilla. Localizing Mozilla is an ongoing effort nevertheless, and if a L10n team runs short on manpower, we need their help with getting new volunteers on board.

Mozilla will take a look at the reviews by native speakers that L10n teams recieve and point to in their registration bug. In addition to that, we do a few different types of reviews depending on the state of the localization: a user-experience review, a technical review, and a sign-off review.  

The [https://developer.mozilla.org/en/Localization_technical_reviews technical review] is done on first time builds to evaluate the technical correctness and localization coverage.  

The [https://developer.mozilla.org/en/Localization_sign-off_reviews sign-off review] is done on all subsequent builds. It is less intensive, as it concentrates only on the newest work done in the new version release instead of the entire repository.