As morgamic mentioned, we’re very excited about finally being able to provide a great add-ons experience in more than just English. (Don’t get me wrong, I love English, but there are other great languages as well.)
There are three major parts to localization in the “Remora” code base:
- Localization of static web content. These are the sorts of things that you would find hard-coded into markup in the current site, and includes the text of links to different sections of the site, error messages, and help text. We’re using gettext for this, and performing the translation should hopefully be pretty straightforward.
- Localization of dynamic site content. Right now, this is pretty much only the names and descriptions of categories, but will likely grow a bit to include other kinds of database-driven site-wide text that users see. (There are a few more examples right now on the admin and reviewer side as well.) We don’t have good tools for this today, but there are few enough entries in need of this sort of translation that we can probably manage with manual entry by an admin for a while.
- Localization of user and developer content. Add-on descriptions, screen shots and their captions, review text, version notes, that sort of thing. This localized data is managed by the site users themselves, so localizers shouldn’t need to do anything special to accomodate it. (It’s possible, perhaps even likely, that localizers will want to help authors get localized descriptions of their add-ons, but that’s another discussion entirely.)
This post is about the process for doing the first part of the localization (static gettext translation) of Remora. Hopefully it’ll be quite straightforward, especially for people who already have experience with gettext-based localization. There are currently a little fewer than 500 strings to localize, but only about 300 of them affect the public site.
(If you’re the sort of person who can set up a moderately-complex PHP application, then you might want to follow the installation instructions to set up your very own Remora, but that isn’t strictly necessary for localizing the site.)
First, you should learn a language other than English. We can’t provide assistance with this step, unfortunately.
With that out of the way, you’ll want to get a copy of the English gettext “po” file. You can find the trunk version of it here. That file will be updated live with our development, so we might end up wanting to have localizers follow tags, but for now we want to let people stay as up-to-date as they’re willing, and we don’t expect a ton of changes to the public-facing strings before we deploy Remora.
You can translate that file by hand, or there are various tools to make it easier. Wikipedia has some details here, though you won’t have to compile things to “mo” format.
Note: this file contains all the strings for the site, including those for the admin/reviewer/developer parts. The strings for those parts of the site are not frozen yet, so translating them at this point will likely be a bit of a waste, since they’ll need to be revisited in the nearish future. We recommend that translators only bother with msgids that are a “key”, like “user_form_firstname”, and skip the ones that use English text as their msgids, like “Back to Review”. As strings become more frozen, they’ll be converted to use the key form.
Once you have a translation complete, you should take the .po file and attach it to a bug filed against the Public Pages component of addons.mozilla.org. The summary of your bug should be of the form “gettext for AMO (your-locale-here)” — please look for an existing bug beforehand, ideally before starting your work! If you haven’t been active in localization of Mozilla products before, you should probably try to connect with the existing localization community for your locale of choice, to avoid duplication of effort and to help you get up to speed.
(We’re going to be working with the localization leads to figure out how to best manage “module ownership” of different site localizations, so this process may change in the near future. We appreciate your patience in this matter!)
So, to summarize:
- Check to make sure that nobody has already done the localization that you’re interested in!
- Get the English string file to start from.
- Translate the msgids with names_like_this into your language.
- Attach the resulting “messages.po” file to a new bug.
As implied by the title of this post, there will be other posts to come on localizing other elements of AMO, but the static part should give people a great start on giving us an add-ons site that better reflects the global nature of the Mozilla community.
Pingback from Mozilla Webdev » Blog Archive » Teaching CakePHP to be Multilingual (part 1) on :
Pingback from El Rincón del Tio Nuke » Traducción de Mozilla Addons on :