L10n:Starting a localization

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

Team building

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

• Check out the L10n:Teams list to determine whether your language is already started or not.
• Add yourself to a L10n:Teams wiki page that identifies you and what you're working on so people can find you.
• 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.
• 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. You can also just use plain files and regular backups, or set up your own P2P VCS.

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 mdc:Creating en-X-dude, 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.