L10n:Becoming an Official Localization

The Middle

As mentioned in the 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 "official".

Mozilla Localization Build Categories

Generally speaking at this stage Mozilla Corporation categorizes this stage as either of:

• "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 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 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 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 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.

Preparation stage

The section attempts to guide you through the various technical documentation available in Mozilla open source knowledge repositories.

As you will be working first to build a language pack, we suggest you start at these Creating en-X-dude pages and focus on creating an installable language pack xpi.

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 Mozilla Development Center. You can also post questions or offer suggestion to either L10n on Google forums or post an email

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.

Source

In this stage you are finalizing your language pack and should expect to have it hosted on AMO.

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!

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.

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 global program).

To move forward from this stage you would request a review to make your build "official".

Review stage

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.

• Review the source (checking for completeness and obvious areas) and effectively QA your work; further information is available on Mozilla Development Center
• if you haven't already done so, file a 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 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

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).
• 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 buildbot to give us an idea of how your language pack is performing
• For landing on the trunk: land-ab-CD alias

Productization

• This stage is when you create your language-specific search engines, RSS readers or feeds and content handlers.
• 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.
• 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: 375198, or 375818
• also check out the current list of requirements for the upcoming release of Firefox 3

Morph

Axel handles this part again and specifically,

• 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

• This is he stage when you build your in web product pages
• Pascal work with you to guide the building of these pages
• Pascal is working to create an explicit instruction set, in the mean time you can check out our website policies or current pages in French
• We can help you with hosting costs if you need, we have been working on a global program, email for this type of support.

Ship Beta

• This is our QA stage, it is heavily dependent on a community review
• Effectively we're asking and you're asking to get as much community feedback as you have access to to review these builds
• 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

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 ;-).

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.