Last week I had the chance to travel to Berlin, Germany, and discuss “Localization on the Web” with our Localization (L10n)-drivers team. In a small series of three blog posts, I would like to point out what the “pain points” are for Web L10n at Mozilla, and start a discussion on how to fix them.
Please note that none of this is authoritative — it’s a complicated topic and making mistakes is easy. If you feel something is misrepresented, please leave a comment and speak your mind.
The status quo
Here at Mozilla, we are very proud and honored to have an awesomely active localization community that works hard to bring mozilla products and web sites to you in your language. Without them, it would be impossible to publish, for example, Firefox in 75 languages and AMO in 33.
Product localization at Mozilla works very well: The localizers show unmatched dedication to, and pride in, getting every version of Firefox to their fellow speakers. And a lot of these localizers don’t stop there: They also translate websites like AMO, SUMO, mozilla.com, or Mozilla Service Week. But the more web sites are being released, the higher the work load gets for the localizers. Our teams in some locales can handle that pretty well, both because they are mature, well-oiled teams and because their size allows them to delegate different projects to different people without overworking individual localizers. Others however, be they a newly-founded team or a locale just naturally smaller in size, can find it overwhelming to translate not only the flagship application Firefox but also many other projects that are equally as important to the end users.
I want to make clear that these localizers are not slackers: Their day has 24 hours like everyone else’s, and they have a day job and families to take care of as well. Therefore, they have to prioritize and some projects just don’t make the cut.
In addition, starting to be a localizer can be hard. Some of our existing localizers are developers with a non-English mother tongue (like myself, for example) who can check out an SVN repository, edit a .po file, submit a patch, etc. before they’ve even had breakfast. Other possible contributors might not be that technical and still want to help. Currently, when somebody asks “how can I translate project X?” the answer is often neither obvious nor trivial.
The fact that some localizers and locales cannot keep up with the amount of localization needed for various projects under the roof of Mozilla is not a bad thing. It’s rather a sign of success: All over the Web, Mozilla included, localized websites are becoming the rule rather than the exception. After users have become accustomed to a browser in their own language, websites in their language are the logical next step. But no-one can expect single localizers to bear that task all by themselves.
What can we do?
What we would like to do is lower the entry-level to localizing Mozilla websites by making it quick and easy, while not impairing the established workflows current localizers have. This will not only reduce the individual work load on existing localizers and their projects, it can also make it easier for interested community members to become a localizer, by taking on projects that are less overwhelming in size and therefore easier to digest.
Why is this not as easy as installing a production instance of the numerous “translation tools” out there and pointing it at our projects? This will be covered in the next two blog posts, addressing some organizational issues first, followed by some technical challenges.
Photo credit: “Touching Rosetta”, CC by-sa licensed by namlhots on flickr