How We Localized the Firefox Home iPhone Application

On Wednesday, August 25, 2010, Mozilla submitted an update to its Firefox Home application for the iPhone. Among other new features, this update included support for 15 localizations. Executing this global release was not an easy task, so if you’re interested, please read the rest of the story.

(understatement alert) It turns out that localization on the Apple iPhone platform has some pieces that are very easy to understand and manage, and other pieces that are unique, complex, and do not align well with a global open source project like Mozilla.

A Brief Technical Description on How to Localize an iPhone Application

I worked closely with the Firefox Home lead developer, Dan Walkowski, to learn how iPhone applications are localized. I will paraphrase some specific technology tidbits provided to me by Dan to give a brief description on what was necessary.

To begin, all Mac/iPhone localization projects use strings files, which are very similar to property files. After translation and testing, all of the localized files are built into a binary and loaded at run time. The twist from Apple is that there are two ways to generate strings files, and they are used differently.

Way #1: For all places where the application uses a localizable string in code (ex: displayAlert: “uh oh!”), strings are wrapped in a macro. The developer then runs a tool to generate strings files for everything. That is the easy part.

Way #2: Most of the Firefox Home UI is defined using Interface Builder, which generates serialized object trees known as xib files. These xib files are loaded at runtime, ready to go, and attached to the rest of the running code. Most of the strings a user will see are embedded in xib files. In this case, xib files require a two-step process to create. A different tool is run over each xib file to generate a strings file mentioned above. After that new file is translated, an inverse tool runs to create a *new* xib file by substituting in the new, localized strings from the strings file. The new xib file is placed in the project in the correct place and loads at runtime when that locale is active.

The disadvantage of this is that, unlike the code-based strings, the strings files from xibs are only an intermediate step, not the actual entity needed for the build. The advantage is that since every locale gets their own serialized object tree, and we can actually alter the arrangement of UI elements (resize buttons, etc.) to better suit the locale.

Here is how Dan set it up in Hg.

Project Management with the Localizers

For this project, I chose to file all tasks needing l10n as individual bugs inside Bugzilla. Under this scenario, every locale would have several bugs representing tasks that would block a locale-specific tracking bug. Then, all the locale-trackers would block a project-wide tracking bug. Here is the dependency tree from Bugzilla showing all the bugs and the structure of the tasks.

The Localization Work

To provide the easiest way to localize the application strings, we loaded them into our Verbatim web translation tool. Once translations were gathered in Verbatim, I downloaded the .po files, and with the help of the Translate Toolkit, converted the .po files to strings files. Many thanks to Dwayne Bailey who updated the po2prop script in his toolkit that I used for this project. Dwayne also blogged about his experience with this project.

For other tasks like localizing the Mozilla website, the Application Store Description, and the emails that are sent to Firefox Home users after download, we filed bugs to gather the localization work. You can see from the dependency tree above all the tasks that needed l10n.

In hindsight, I would have like to used Verbatim and the Translate Toolkit to do more with the project. After chatting with Dwayne, we could have used Verbatim to manage most of the tasks that needed l10n. Furthermore, I intend to follow up with our French localizer’s recommendation to use SVN to store all of our text based translations, rather than text files in Bugzilla. Luckily, I learned from Alex Buchanan, who is the Mozilla webdev on this project, that he has placed all the translated emails into Github. Because of that, we should be able to extract them as .po files from Github and put them into Verbatim.

Testing

Because many of our localizers do not have iPhones, and because Apple gives us a limited pool of beta testing slots, we decided to place an emulated iPhone with the multi-locale build on a remote machine for our localizers to test. I wrote a test plan with Dan and we left that as an open text document on the desktop of the remote machine where the emulator was running. Localizers logged in with a VNC client and followed the test plan. Because more than one person was able to log in at the same time, everyone had to state in bold font at the top of the page that their locale was testing. When finished, the localizers had to return the OS of the emulator back to English so the next team could test. I think my tweet says a bit about how tricky this was. It may have been a bit of a rudimentary solution, but it was the best way we could think to get 15 different locales testing under the constraints placed by Apple.

Next Steps

Firefox Home’s past minor update (1.0 -> 1.0.1) took Apple seven days to approve. Unfortunately, I do not know how long this time will take because Apple tells us very little. We are presently waiting to hear from them.

Since the app is served as a multi-locale build, users will be able to shift to any of the supported 15 locales we are shipping. In some cases where Apple provides a localized App Store, special content localized by our community will help advertise our app.

Thank you to everyone who participated to make this a success.

Tags: Firefox Home, iPhone, planet | Categories: Uncategorized