In the past I’ve highlighted some software design mistakes made by others and today I want to point the finger at myself and talk about a mistake I made in localizing my first iPhone app KEYBOX.  It is my hope that this article will help others avoid the same pitfalls I experienced.

I made KEYBOX to scratch a personal itch (digital privacy) and it was first released in 2005 as a J2ME app for Vodafone Japan’s market.As such it was never localized to any language other than Japanese.  That all changed this year when I ported it to iOS.  As the App Store is an international affair I naturally would like KEYBOX to benefit as many people as possible.  The main barrier to this is of course language.

For release 1 I decided to localize KEYBOX into the 4 languages with which I am familiar: English, French, Japanese and Spanish.

I now believe doing so this early was a huge mistake as it introduced two issues for me: serious delays in releasing and numerous layout changes.

In localizing KEYBOX, I underestimated the amount of effort it would take.  There are over 200 text snippets to translate from English.  Using online dictionaries to double check my translations and searching for real-world instances of each text snippet before issuing the final check of approval for each takes upwards of 20 hours for each language.  When you’re only doing this on the side (weekends and some evenings) you can imagine how much it delays the release of your app, which is otherwise feature complete and ready to go.

And then there was the EULA!  KEYBOX is unique in that it requires a rather lengthy EULA to protect myself from users who might be less than responsible with it.  Writing the English version was an experience in its own right.  Writing it in Japanese would’ve been a train wreck without help from my loving wife (also Japanese) and it took over 30 hours spread across 3 weeks.

An interesting surprise was that people in countries whose languages are not yet supported still download KEYBOX, and in droves!  Italy is perhaps one of the biggest markets and KEYBOX isn’t even in Italian yet.  I don’t know if support for Spanish and French is what makes this possible (the Romance language connection?) as KEYBOX is about privacy and I don’t solicit my users for such information.  While I’m sure that supporting multiple languages opens the door to more people enjoying my app, having so many languages supported from version 1 is perhaps less important than I initially thought.

Now to the issue of layout…  In comparison to English, Japanese can be an extremely compact language and most words are only 2 kanji characters in length.  And then there are French and Spanish whose words tend to be much longer than their English counterparts.  This naturally leads to sentences that expand and contract in length depending on the user’s locale.

Before translating the text I was tempted to avail myself of iOS’ ability to auto-adjust font sizes for a statically sized label.  I figured the sentence length wouldn’t vary so much and that an auto-adjusting font size could handle that difference.

I could not have been more wrong.  Doing so resulted in text so small that it was rendered unreadable and sometimes text that gets clipped off by the boundaries of the container label.

I learned, the hard way, that multilingual apps really are better off having multi-line labels with a fixed font size.

Going multiline however introduces a new problem.   It forces us to position controls spaced far enough from each other to compensate for the wordiest languages whose labels will expand the most.  Release 1 of KEYBOX followed this approach.  It worked for the most part but it took a lot of manual testing across languages to make sure the text was readable and that there were no overlapping elements.

I knew that I couldn’t take this approach forever and for release 2 I decided to change tactics.  I developed a high-level, goal-oriented layout utility class that lets me accomplish tasks such as “place this text field 10px under that label and center it on screen” or “left align this label 5px to the right of that icon”.  As a result I no longer have to consider the pixel locations of positionable elements across all locales at once and can focus more on the general look of the UI.  In some ways it works like HTML with the end result being one element following the last but unlike HTML it still retains simple, pixel perfect control.

Example:

KEYBOX 1 – Without Dynamic Layout

KEYBOX 2 – With Dynamic Layout (Text is directly under cloud image and the warning icon is to the left of the text)

I intend to open source this layout engine for those who want to maintain a professional layout for their multilingual apps but my best piece of advice would be to release one language at a time and just get your app out there first!  From there on, you can roll out new languages gradually.