Mozilla Webdev

If you’re reading this, you’ve probably noticed that AMOv3 still hasn’t taken over addons.mozilla.org. We’ve hit some unforeseen problems that have been plaguing us since our attempt to launch on Monday.

Without getting into the details, we’re having some issues with the way our infrastructure is caching (or not caching) the new AMO v3 pages. Rather than risk a slow, (and thus, frustrating) user experience at launch, we’ve decided to iron out the problems with the servers before deployment.

That means the new site still isn’t live, and won’t be until we can get things fixed. I assure you that we’re all working hard on bringing the community the best possible experience.

Thanks for your patience.

As I’m sure many of you are aware, today (Feb 12th) was the scheduled release day for Remora, which will bring localization, a more inclusive review system, and discussion capabilities to the addons.mozilla.org site. We had a maintenance window scheduled for today from 7-11pm Pacific, and during that period we discovered a number of issues related to differences between our test environment and the production one, as well as some late-breaking bugs found by our testers.

While we were able to resolve all but one of those issues to our satisfaction — and that of our test suite — we ended up making sufficient changes to the system that we wanted to take another day to test it in the production environment before we put it in front of Firefox’s tens of millions of users.

It’s a heart-breaking decision for the Remora team, but we think it’s the right thing for our users, and we’d rather have 24 hours of disappointment than put the users’ experience at risk.

On the bright side, this will give us an extended window to take updates from our intrepid localizers, as those changes are sufficiently low risk that we’re comfortable taking them during tomorrow’s test-and-test-some-more window.

Thanks to everyone for their patience and support; we’re so close now that we can taste it.

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:

1. Check to make sure that nobody has already done the localization that you’re interested in!
2. Get the English string file to start from.
3. Translate the msgids with names_like_this into your language.
4. 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.