Everybody knows Mozilla makes Firefox. But there is a lot more software at work here at Mozilla that you might not be aware of. For example: What happens when you go to getfirefox.com and click on the download button?

By clicking on the button, you ask our servers to send you a specific file, for example: Firefox 3.6.3, for Windows, in German. On a small website, the server would just fetch the file and hand it to you. But if you need to handle millions of downloads a day like we do, a single server can’t handle it all by itself, so it gets more complicated. In order to provide you with downloads, updates, etc., as fast and conveniently as possible, Mozilla collaborates with a number of mirror providers that have volunteered to host Firefox and other downloads on our behalf, thus sharing the load of our numerous downloads between a number of servers all over the world.

For some years now, we have been running a bundle of software called “Bouncer” to handle our downloads for us.

Bouncer consists of of three components: The user-facing bounce script, an administrative interface called Tuxedo, and a mirror checker called Sentry.

First, the bounce script. It is the only component the “ordinary user” gets to interact with. It essentially does the following after you click on a download link:

• It determines if the product you asked for exists.
• Out of our list of mirrors, it picks one that has your file. Initially, it would pick one at random. Over the years, the logic has become more elaborate though: Meanwhile, it takes into account in what country you currently are, as well as how strong the mirrors are (stronger mirrors serve more downloads, weaker ones serve less).
• A split-second later, Bouncer refers you to the server it decided on, and that server will send you the file you asked for.

But wait, there is more! How does Bouncer know what products are available, for what operating systems, and in what languages? That’s where the admin interface comes in. We have a release engineering team who work hard every day to deliver the newest software versions to you in handy little packages. Previously, during every release, an engineer would manually tell Bouncer that a new version was available for download. But just last week, we improved this process by introducing a new interface to Bouncer, with a project called Tuxedo. The release engineering team can now, fully automatically, feed new versions into Bouncer at the time of release, with no manual intervention. With less time spent on repetitive tasks, we can spend more time making Firefox awesome.

Finally, the Sentry component is a script that periodically checks the health of our mirrors, and adjusts our settings accordingly. This is to ensure that a situation where you are forwarded to a mirror that is currently unavailable is very, very rare. So far, these mirror checks happen from Mozilla Headquarters, and therefore reflect the connectivity we get to the mirrors from here. In the future, we want to improve that by taking into account more how our users’ connectivity is to the specific mirrors (for the geeks out there: Network proximity != geographical proximity), which has the potential to result in faster download times, less expenses for mirror providers, and general happiness.

As you can see, there are a lot of things happening behind the scenes before Firefox makes its way onto your computer at home, and we are constantly working on improving the way we are doing things. Plus, as always: Bouncer is completely open source, and we have a public bug tracker, so if you notice any problems or see room for improvement, make sure to let us know.

Photo credit: “directions”, CC-by licensed by Phillie Casablanca.

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.

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.

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.