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 "how to" 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 Centre. 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

You need to create your language pack and then once you have a language pack ready and you're hosting it, you can start collecting user input. We can help you with hosting costs if you need, we have been working on a global program, email for this type of support.

At this stage you are effectively expanding your community, this is a good thing and will be useful for you for testing, events (i.e, celebration parties), and possibly web pages or other areas you might need or want help with.

if you haven't already done so, file a registration bug (we want this to happen as early in process as possible) - you "must" do this because we have people working in a variety of groups and in a variety of geographic locations and this is the best way to effectively let people know what's happening and move to the next steps
You will work on a set of [files] that need to be localized
Review the source (checking for completeness and obvious areas) and effectively QA your work; further information is available on Mozilla Development Centre
You will need to open an l10n account request (on CVS)
Create a bugzilla component (so language is created in bugzilla for tracking purposes)

File landing bug

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

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.

L10n:Becoming an Official Localization

Contents