Latest revision as of 19:01, 18 May 2015

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

Next >>

@@ Line 1: / Line 1: @@
-=The Middle=
+__NOTOC__{{L10navbar}}<p><br>
-As mentioned in the [[L10n:Localization_Process_Start| start]] section you will likely be building an "unofficial" build at this stage also called a language pack (or language pack installer xpi file type). The written material in this next section should get you started, show you how to launch your build, and work towards becoming "official". Mozilla Corporation provides the QA and Build resources to support builds they categorize as [[L10n:Localization_Process_End| "official"]].
+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.
-=Mozilla Localization Build Categories=
+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 [[L10n:Web parts|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).
-Generally speaking at this stage Mozilla Corporation categorizes this stage as either of:
+[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.]
-*"name" language packs with no source (not in CVS); users are able to get your build through AMO [insert link here to sample], so they'd download either en-US or other related versions and then apply a language pack listed in the [https://addons.mozilla.org/en-US/firefox/browse/type:1/cat:37 AMO directory] to enable the language you've translated
-*"pre-Beta" which means your build would be put in the tree, but not considered "official" in terms of the high level of QA and Build support made available; user has the same experience for this build as for the one above
-*"Beta" in shipped-locales; users access to your build from the main Mozilla [http://www.mozilla.com/en-US/firefox/all.html page] except the build is listed as "Beta-language" versus just the name of the language.
-Over the next few paragraphs we will better define the process that moves towards official build status.
+=The release train=
-The first thing you should do is create a wiki page similar to this [[L10n:Teams:de]] page, which indicates to the community you've started working on a new language. These pages will eventually replace this team  [[L10n:Localization_Teams| directory]]. The reason we suggest this is to help you create the building blocks you'll need to create bigger success, e.g., additional resources from the community who can help you build web pages, promote your edition, etc.
+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.
-==Preparation stage==
-The section attempts to guide you through the various technical documentation available in Mozilla open source knowledge repositories.
+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.
-As you will be working first to build a language pack, we suggest you start at these [http://developer.mozilla.org/en/docs/Creating_en-X-dude Creating en-X-dude] pages and focus on creating an installable language pack xpi.
+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).
-If you haven't already you should get onto the IRC Channel, #l10n. You will be able to get real-time help from other Localizers and members of the L10n-driver team. In addition, you should have already created for yourself a bugzilla account as the majority of our work is started and tracked to completion in this way. There is more helpful documentation on the [http://developer.mozilla.org/en/docs/Create_a_new_localization#Starting_a_new_team Mozilla Development Center]. You can also post questions or offer suggestion to either L10n on Google forums or post an [mailto:l10n-drivers@mozilla.org email]
+==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.
-Useful tips. I'd really like to improve on this section, so if you feel you have some useful tips please feel free to edit this section with additional helpful sources of information.
+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.
-==Source==
+==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.
-In this stage you are finalizing your language pack and should expect to have it hosted on [https://addons.mozilla.org/en-US/firefox/browse/type:1/cat:37 AMO].
+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.
-Even though this looks like the smallest written section, this is where the BIGGEST amount of your work will happen. There are many code strings to change so read the documentation we provided above carefully and use the resources we offer extensively to get you through it successfully!
+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].
-The critical elements of this stage are to ensure your build has been reviewed by the community (particularly those interested in your language) and is being used on AMO and updated regularly by you. It's important to collect input from any and all sources about your language pack as this is the first time that people will be using it on a day-to-day basis and giving you feedback about the quality of your work.
+==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:
-Something to think about all throughout your work is expanding the people around you who can help you with the language you're working on. This is a good thing and will be useful for you for testing, celebratory events (i.e, launch parties), and possibly web pages or other areas you might need or want help with. We want to help with this and are working on programs to do so. (You can read more about this on Seth's blog about our [http://blog.mozilla.com/seth/2007/06/04/support-update-3/ global program]).
+*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!
-To move forward from this stage you would request a review to make your build "official".
+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.
-==Review stage==
+=A couple of words about reviews=
-This stage is your formal request for a review. This means that you are willing to commit over the longer term to sustain your build and in particular to be relied upon by the community and Mozilla to keep up to date with major releases. (Mozilla will do the work for the minor releases). You'll also expect to move from having language pack xpi to a robust build.
+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.
-* Review the source (checking for completeness and obvious areas) and effectively [http://www.mozilla.org/projects/l10n/mlp_howto.html#mlp_qa QA] your work; further information is available on [http://developer.mozilla.org/en/docs/Create_a_new_localization Mozilla Development Center]
+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.
-* if you haven't already done so, file a [http://www.mozilla.org/projects/l10n/registration.html registration bug]. We want this to happen as early in process as possible, because this gives us the notification that you are ready to connect more permanently to us and to your users. Consider it your official signing up moment for being responsible for this effort, think of this as a mid-term commitment to continue with the effort of localization. We consider this a "must" do in order to move forward. This is also the best way to effectively let people across all geographies and user groups (e.g.,Mozilla, Localizer community and users) know what's happening
-* You will need to open an l10n account [http://developer.mozilla.org/en/docs/Create_a_new_localization#File_CVS_account_bug| request] (on CVS). This enables Mozilla to create builds for minor updates without involving you. This means the user experience is consistent across the world (or across all of our builds).
-* Create a bugzilla component (so language is created in bugzilla for tracking purposes)
-==Incubator Stage==
+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.
-[[User:AxelHecht| Axel]] does this part for you. The result of this stage is a review of your language pack to ensure its working the way we all expect and then it moves to the branch.
-*This is what we refer to as the incubator stage. Mozilla's objective is to get an idea of how things are working, collaboratively go through an evaluation criteria for moving to the branch: trunk l10n with branch language pack for testing. At this stage you won't have a public product launched, or web pages (yet).
+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.
-* More specifically, you should attach a language pack to your bug, we'll put language pack for you on branch to take a look at and see if its working reasonably well, and then you test it to be sure it's fine
-* Once landing tests fine then Axel will move it onto the trunk.
-* Our intent is to make this more powerful with tools, for example we've built one called [http://l10n.mozilla.org/buildbot/| buildbot] to give us an idea of how your language pack is performing
-*For landing on the trunk: land-ab-CD alias
-==Productization==
+=Testing and getting feedback=
-* This stage is when you create  your language-specific search engines, RSS readers or feeds and [http://wiki.mozilla.org/Firefox3/Product_Requirements_Document#Content_handling| content handlers].
+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.
-* The way you do this is within your bug propose what local options you'd like to include and we collaboratively review it (in a similar way as we did in the stage before) and once it's approved, you check in the changes.
-* [[User:MicBerman| Mic]] is the one who does the reviews with you over this stage
-* the best way to make these recommendations is to get input from your local community as to what they use or want to use in your local language version. For examples check out bugs: [https://bugzilla.mozilla.org/show_bug.cgi?id=375198| 375198], or [https://bugzilla.mozilla.org/show_bug.cgi?id=375818| 375818]
-* also check out the current list of [[Firefox3/L10n_Requirements| requirements]] for the upcoming release of Firefox 3
-==Morph==
+;Pre-release train testing
-Axel handles this part again and specifically,
+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.
-* This is the stage when your landing bug gets into branch
-* It is completed after initial landing is done
-* We create a bug for build automation
-* We then create a bug for test automation
-* once this step is complete you will then be building on branch
-* evaluations are then done by you to ensure all is done the way it's supposed to be: this is where testing starts to ensure all strings are translated, etc. You should rely on your community if you can for testing here as we all want the user experience to be the best and the crux of this stage is making sure all the translations are completed and appear "right".
-==File Web==
+;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!
-* This is the stage when you build your [http://wiki.mozilla.org/L10n:Web_parts#Firefox_in-product_pages in web product] pages
+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.
-* [mailto:pascal@mozilla.com Pascal] work with you to guide the building of these pages
-* Pascal is working to create an [http://wiki.mozilla.org/L10n:Web_parts explicit instruction set] and you can check out [http://chevrel.org/fr/ current pages] in French
-* We can help you with hosting costs if you need, we have been working on a [http://blog.mozilla.com/seth/2007/06/04/support-update-3/ global program],  [mailto:l10n-drivers@mozilla.org email] for this type of support.
-==Ship Beta==
+;Infographics on the l10n process
-* This is our QA stage, it is heavily dependent on a community review
+*[[File:Mozilla_localization.pdf|frame|none|alt=Alt text|Infographic of l10n process (front)]]
-* Effectively we're asking and you're asking to get as much community feedback as you have access to to review these builds
+*[[File:Firefox_localization_back.pdf|frame|none|alt=Alt text|Infographic of l10n process (back)]]
-* The build is not on web official, it's on Ship (all.html)
-==Community input==
-* Generally you will need and want as much community input as you can get throughout your build process
-* We'd suggest at the very beginning getting friends or family to help you with your testing.
-* The 'best' testers have a passion and interest to create a browser in your language, use the browser for daily browsing, and are constantly testing against basic functionality as well as new builds
-* we'll also help you to develop your own skills across the different areas you need to complete a build
-==Notes==
+<div style="text-align:right">[[L10n:Official_Localized_Releases|Next >>]]</div>
-this are placeholders to figure out where they go later
-We also have a new feature you may or may not be aware of, you can check how you're localization is [insert link|performing]. We would like to help you continue to do well or do better at letting users know that your build is available to them. One thing we're committed to do this year generally to help is creating an easier way for users to find your build from our most trafficked pages. We also think expanding your community is helpful to you and so we've developed some tools with the help of some of the larger communities like Poland. Check out Seth Bingernagel's blog to read about what they're up to. The Japanese team has done an amazing job at this and between them and Paris I hear they have the best launch parties ;-).
+[[Category:L10n]]
-Seth/Asa: need help here. How do we assess the "health" of a localization team and how we could better support them to develop their team or their skills.

L10n:Becoming an Official Localization: Difference between revisions