L10n:Starting a localization

Main | Join Mozilla | Overview | L10n Drivers | Communities | Meetings | Blog | Resources

This document outlines what you should expect in order to start building a new language, in the form of a language pack.

Here's the scoop, the Mozilla L10n program involves:

• translating application strings and customizing the application for your region;
• distributing localization work to testers who will provide feedback on the translation quality;
• localizing the installation and migration process for users to find and later upgrade the Mozilla application with ease;
• translating web pages linked from the application and Mozilla websites to help educate users and market a localized Mozilla product.

Team building

First things first, you'll want to join an existing localization team or start a new one if there isn't one already working on your language.

Join an existing team

Localizing Mozilla applications is a lot of work (and fun) - but that means there's plenty of opportunity to get involved. Some people may already be working on your language of interest; if so, they will be happy to have some help. You can find others who are already working on the same language by looking at the list of localization teams and the open team registration bugs]. A Google search might also find existing work.

• Add yourself to a L10n:Teams wiki page that identifies you and what you're working on so people can find you.

Start a new team

If there isn't any information on an ongoing effort in your language, you should begin by creating a team page on wiki.mozilla.org wiki, similar to that of the German team. Give it the same name as theirs, except replacing the language code de with your own. Firefox, Thunderbird, and XULRunner share the localization of a core piece called "toolkit", so if you start localizing one of those applications when some other team is already working on another one, you'll need to coordinate with them about that.

There are some resources available for people starting new teams. We have a server dedicated to l10n that you can get access to, or you can create a project on mozdev.org or SourceForge which will provide you with mailing lists, a place to store your code and so on. These services provide a more complete package, which the l10n server doesn't try to reproduce.

• Read more about how to register a new localization team.

Communicate

If you haven't already you should also 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. You can also post questions or suggestions to m.d.l10n, available as newsgroup or on Google groups. In addition, you would want to have a bugzilla account as the majority of our work is started and tracked to completion in this way.

Collaborate

Set up a communication channel for your language. You can use mailing lists or newsgroups, which many open source hosting partners offer, or simply open a Google or Yahoo group. You should leave a link to this forum on the wiki page for your language, so that new volunteers and members of the Mozilla community can find it. That's important because building a community around you to support your work is an essential part of being an open source project.

Localization work

Now you and your community are set up to do the actual localization work.

You may want to set up a central repository for your work (code, mailing lists, newsgroups, website). Depending on your working habits and the size of your team, you may want to look into open source hosting offers like mozdev.org or SourceForge. A very convenient way of keeping your files's version history up on the Web is to use BitBucket. It's an on-line Mercurial (hg) hosting service, which has the nice side effect of getting you started with using hg. You can also just use plain files and regular backups.

Instead of localizing a language pack directly, you should localize in the source directory structure, and then make your work publicly available. We believe this as a good way to start out because it let's people know you are open to new collaborators and enabling a smooth path going forward.

To make your work available for users to download and test, create a language pack which can be hosted on AMO. AMO offers many advantages for both you and your testers and users, from download capacity to automatic updates of your Add-on.

Starting from scratch on a new localization depends a good deal on whether you use a tool, and if so, which. On MDC, we documented bootstrapping a new locale, which works with the Mozilla build system and an UTF-8-capable editor. You won't need a compiler, though, no worries. The steps roughly include

• Check out the en-US tree.
• Once you've created your working clone, edit the resulting tree to translate the strings (perhaps with tools)
• Package up the result into a language pack
• Shipping it to some friends to test it.
• Translate more ...

Most of your work will happen here. 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 work has been reviewed by the community, particularly those interested in your language. You can use AMO to host your language packs and update them regularly. 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. It is these same users who will then download and promote your new localization.

Something to think about all throughout your work is expanding the community 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 you with this and are working on programs that we believe will do so. To read more about this, check out Seth's blog on our global program.

You only have a language pack? There seem to be a bunch of language packs floating around still, that don't exist in an up-to-date form to be used for the build. If you have one, and would like to convert it to a source, there's a tool by Cedric that can help you with the file shuffling. The build process from sources to language packs is lossy, so there will be work left to do, but the tool will do the tedious part for you.

Going beyond language packs

Working on a language packs has the advantage that your testers can get updates on your work much more easily, and it requires a lot less toolchain compared to doing fully localized builds.

As mentioned in the L10n:Localization Process, having language packs only comes with a few downsides for your users. In particular, the in-product web pages are not in your language, and the install and migration experience occurs in the language that your users installed first. Depending on your language, this may be more or less severe. Our common objective is to create fully localized official builds together, once you and your testers are comfortable with the localization thus far.

To move forward from the stage of language packs, you would request to make your build official, which is described in the L10n:Becoming_an_Official_Localization.