L10n:Starting a localization
This document outlines what you should expect in order to start building a new language.
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. Building your localization team and a community around it is something that will stay on your todo-list forever, too. It's the essential part of being an open source project and, basically, you're never done.
- 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.
Localization work
Now you and your community are set up to do the actual localization work. 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 to get some central repository for your work together with mailing lists, newsgroups, and website. Or you can just use plain files and regular backups, or just set up your own P2P VCS. Whichever way you go, it's a good idea to start out in a way that is open to new collaborators and offers a smooth path going forward. That means, you should localize the Mozilla sources instead of the built files, and make your work publically available. You won't need all this for just finding out if localizing Mozilla apps is something for you, you should be good to go with just a bunch of local disk space.
To make your work available for users to download and test, you create a language pack, which can be hosted on AMO. AMO offers many advantages for both you and your testers and users, starting from download capacity, and ending in 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 rougly 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 with this and are working on programs to do so. (You can read more about this on Seth's blog about our global program).
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 work 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:Localization Process Middle.
Useful tips. We 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.