L10n:Becoming an Official Localization: Difference between revisions
(Update broken calendar link) |
|||
| (45 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
__NOTOC__{{L10navbar}}<p><br> | |||
Releasing a localized Mozilla product is the ultimate goal for each L10n team. It is the culmination of all of their hard work and truly cause for celebrating! Each team has the option of releasing their work as either an official language pack or an official build. | |||
There are many advantages to releasing as an official build. This gives the L10n team's users the following: | |||
* a download link on | * a download link on for all three major platforms in each release channel | ||
* a localized install experience, including profile migration | * a localized install experience, including profile migration | ||
* a localized start page | * a localized start page | ||
* localized [[L10n:Web parts|Web parts]] like first-run page, or get-involved | * localized [[L10n:Web parts|Web parts]] like first-run page, or get-involved | ||
* automatically generated security updates | * automatically generated security updates | ||
* language-specific | * 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. Whether a team choses to release as a language pack or as a build, they all have to kick off their releases on the train. [https://www.google.com/calendar/embed?src=bW96aWxsYS5jb21fZGJxODRhbnI5aTh0Y25taGFiYXRzdHY1Y29AZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ We use this calendar to track when each six week period is over.] | |||
=The release train= | |||
= | |||
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). | |||
==Aurora: the localizer's workspace== | |||
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. | |||
By this time, members of new L10n teams should have access to hg. To get write access to the l10n hg repositories on the Mozilla server, there's a bit of paper work to be done. See the wiki page, [http://www.mozilla.org/hacking/commit-access-policy/ "Localizing with Mercurial"] for more info. | |||
==Beta== | |||
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. As with the L10n teams' language packs, the L10n teams need to gather feedback on their localized Beta builds. Users can provide feedback on these builds by following going to Tools>Feedback and then providing their feedback about the localization (simple enough, right?). The L10n teams check up on the feedback they've received by visiting [http://input.mozilla.org input.mozilla.org]. | |||
== | ==Release== | ||
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: | |||
*completed their L10n work (100% translated strings), | |||
*resolved all bugs filed in Beta, | |||
*recieved a green light approval on their sign-off or technical 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. | |||
= | =A couple of words about reviews= | ||
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 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. | |||
These reviews are done to ensure that the quality of the localization work meets the high standards people have come to expect when they download a Mozilla product from the official Mozilla site. A successful review gives the OK for moving from a language pack to a fully localized product. | |||
We | =Testing and getting feedback= | ||
Testing and getting feedback about the quality of your localization is critical to delivering a browser that will meet your users' needs. We want to attract people in your region to the world's best browser by making sure that it is the best <b><i>localized</i></b> browser available in your region. Gathering feedback is done in two different ways, depending on whether your localization is on the release train or not. | |||
;Pre-release train testing | |||
If you're not yet on the release train, the best option for you to distribute, test, and get feedback about your localization is to regularly create language packs (langpacks) and distribute them through the [http://addons.mozilla.org Add-ons Manager]. Firefox users can download and install your langpack from there and even leave comments about its quality. This feedback will often help you to greatly improve your localization prior to boarding the release train. [https://addons.mozilla.org/en-US/firefox/language-tools/ Here's a list of langpacks] that are currently updated and distributed through the Add-ons Manager. | |||
;Release train testing | |||
Not only is Aurora the channel for localization, but also for testing your localization. If you're already on the release train, you can encourage users in your region to download your locale's Aurora build and leave feedback using Firefox's Input feature (Found here: Tools > Input). As an official localization, you have access to your [https://input.mozilla.org/ locale's Input dashboard] to see what your users think of your work. You may even be able to recruit new localizers to your l10n team this way! | |||
You might be asking, "how do I get users in my region to download my langpack/Aurora build?" People have done this through many different and unique ways. Some have written a blog post describing how to download and install either the langpack or Aurora build and how to leave feedback for it. Others have gone to their local internet cafes, downloaded and installed Firefox langpacks or Aurora builds on every computer. Others still have teamed up with their colleges, universities, and local hackers to download, test, and give feedback about their work. You can email the [http://groups.google.com/group/mozilla.dev.l10n/topics m.d.l10n newsgroup] to learn what other l10n teams have done and try it out in your region. These are some ideas, but the best ideas are those that fit with your region's local customs and culture. When considering how to reach out and evangelize your work, consider what has worked before and give it your own unique, regional touch. | |||
;Infographics on the l10n process | |||
*[[File:Mozilla_localization.pdf|frame|none|alt=Alt text|Infographic of l10n process (front)]] | |||
* | *[[File:Firefox_localization_back.pdf|frame|none|alt=Alt text|Infographic of l10n process (back)]] | ||
* | |||
= | <div style="text-align:right">[[L10n:Official_Localized_Releases|Next >>]]</div> | ||
[[Category:L10n]] | |||
Latest revision as of 19:01, 18 May 2015
Main | Join Mozilla | Overview | L10n Drivers | Communities | Meetings | Blog | Resources
Releasing a localized Mozilla product is the ultimate goal for each L10n team. It is the culmination of all of their hard work and truly cause for celebrating! Each team has the option of releasing their work as either an official language pack or an official build.
There are many advantages to releasing as an official build. This gives the L10n team's users the following:
- a download link on for all three major platforms in each release channel
- a localized install experience, including profile migration
- a localized start page
- localized Web parts like first-run page, or get-involved
- automatically generated security updates
- 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).
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. Whether a team choses to release as a language pack or as a build, they all have to kick off their releases on the train. We use this calendar to track when each six week period is over.
The release train
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: Central (which produces the Nightly build), Aurora, Beta, and Release. Builds of the product are pulled from locale-specific code repositories stored in hg (our version control system for Mozilla products).
Aurora: the localizer's workspace
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 Aurora channel. 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.
By this time, members of new L10n teams should have access to hg. To get write access to the l10n hg repositories on the Mozilla server, there's a bit of paper work to be done. See the wiki page, "Localizing with Mercurial" for more info.
Beta
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. As with the L10n teams' language packs, the L10n teams need to gather feedback on their localized Beta builds. Users can provide feedback on these builds by following going to Tools>Feedback and then providing their feedback about the localization (simple enough, right?). The L10n teams check up on the feedback they've received by visiting input.mozilla.org.
Release
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:
- completed their L10n work (100% translated strings),
- resolved all bugs filed in Beta,
- recieved a green light approval on their sign-off or technical 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.
A couple of words about reviews
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 technical review and a sign-off review.
The technical review is done on first time builds to evaluate the technical correctness and localization coverage.
The 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.
These reviews are done to ensure that the quality of the localization work meets the high standards people have come to expect when they download a Mozilla product from the official Mozilla site. A successful review gives the OK for moving from a language pack to a fully localized product.
Testing and getting feedback
Testing and getting feedback about the quality of your localization is critical to delivering a browser that will meet your users' needs. We want to attract people in your region to the world's best browser by making sure that it is the best localized browser available in your region. Gathering feedback is done in two different ways, depending on whether your localization is on the release train or not.
- Pre-release train testing
If you're not yet on the release train, the best option for you to distribute, test, and get feedback about your localization is to regularly create language packs (langpacks) and distribute them through the Add-ons Manager. Firefox users can download and install your langpack from there and even leave comments about its quality. This feedback will often help you to greatly improve your localization prior to boarding the release train. Here's a list of langpacks that are currently updated and distributed through the Add-ons Manager.
- Release train testing
Not only is Aurora the channel for localization, but also for testing your localization. If you're already on the release train, you can encourage users in your region to download your locale's Aurora build and leave feedback using Firefox's Input feature (Found here: Tools > Input). As an official localization, you have access to your locale's Input dashboard to see what your users think of your work. You may even be able to recruit new localizers to your l10n team this way!
You might be asking, "how do I get users in my region to download my langpack/Aurora build?" People have done this through many different and unique ways. Some have written a blog post describing how to download and install either the langpack or Aurora build and how to leave feedback for it. Others have gone to their local internet cafes, downloaded and installed Firefox langpacks or Aurora builds on every computer. Others still have teamed up with their colleges, universities, and local hackers to download, test, and give feedback about their work. You can email the m.d.l10n newsgroup to learn what other l10n teams have done and try it out in your region. These are some ideas, but the best ideas are those that fit with your region's local customs and culture. When considering how to reach out and evangelize your work, consider what has worked before and give it your own unique, regional touch.
- Infographics on the l10n process