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 your localization team and a community around it, is something that will stay on your "to-do" list forever. It's the 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 will 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.
We suggest you localize the Mozilla sources instead of the built files, and 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 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 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).
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 would like to improve this section, if you feel you have some useful tips please feel free to edit this section with additional helpful sources of information.