Sun Surveyor is now available in 13 languages (English, German, Japanese, Spanish, Italian, French, Czech, Russian, Turkish, Norwegian, Afrikaans, Dutch and Danish), mostly due to an army of passionate user-volunteers. Localization goes beyond language translations, and I’d love to share what I’ve learned so far.
First Lesson: A Picture is Truly Worth 1000 Words
The more pictures, icons, or otherwise universal symbols a piece of software contains, the less words, and thus, the less translations will be needed. And with Sun Surveyor, I’ve written several help files which are included in the app, which contain a lot of text and almost no images. In addition, there’s more than a few UI Elements which contain text. So this can directly affect the UI/UX of the application since some languages are more verbose (German) than others (Japanese). So we can potentially have a problem of both imprecise translation of text and inconsistent UX.
If I were to do it all over again, I’d make sure to use more standard graphical elements and remove as much text from the UI as possible that made sense to do so. In fact this is a long term goal, to streamline the UI and make it less “texty.” Better documentation with screenshots versus textual descriptions will help, too. After all, that’s just a matter of taking multiple screenshots, with a few pointers for context, instead of translating reams of descriptive help text. The Android widgets for Sun Surveyor reflect this lesson, as I’ve used images to represent the various solar and lunar events within UI constraints that do not offer much room for varying size words.
Second Lesson: Localize Early and Often, and Pass the Turkey Test
Here’s where localization goes beyond language translation: different regions of the world like to look at dates, times and numbers differently, and indeed software applications may display text using different encoding. These 2 posts (here and here) describe what the Turkey Test is, but in essence, will an app look right to a Turkish user, whose date format is something like 09.2.2013 versus 02/09/2013 in America, and whose numbers are typically expressed in the form 50.000 (fifty thousand) versus 50,000 in America? Less esoteric to those of us in the US is a comparison of European or Canadian date formatting which puts the day before the month.
Thankfully, the Android and iOS SDKs (and the underlying platforms they’re built on) offer and recommend constructs to handle these issues. Using Date and Number formatters by specifier (short, long, etc), and configuring them (decimal length limits, rounding rules, showing grouping, precision), rather than hardcoding a format string, makes for pain-free number and date display. Placing strings in the appropriate locale-specific resource bundles and accessing them that way, versus magic strings or “constant” files also, similarly makes for painless, abstracted text localization. Sun Surveyor does actually have a Turkish translation, and Google and Apple have made it quite easy to make it pass the Turkish Test.
Taking the “extra” (it’s not much!) effort to set this up on day one, even without immediate localization plans, offers more benefits such as properly abstracting text resources and formatting logic such that they are properly separated from the rest of the application logic. Writing some simple utility classes to handle tricky formatting specific to the application allows that code to reside in one place, for reuse throughout. For custom formatting beyond the SDK or language-supplied “short” and “long” abstracted format types, one might get a handle on the current locale, and build formats that way.
Android also has a system setting to toggle 24 hour date/time formatting, so making sure to respect that helps users respect the app!
// iOS: configuring a number formatter _shortDecimalFormat = [[NSNumberFormatter alloc] init]; [_shortDecimalFormat setMaximumFractionDigits:1]; [_shortDecimalFormat setNumberStyle:NSNumberFormatterDecimalStyle]; [_shortDecimalFormat setRoundingMode:NSNumberFormatterRoundHalfUp]; // Android - get some information about the date format from the context char dateFormatOrder = DateFormat.getDateFormatOrder(context); boolean is24HourFormat = DateFormat.is24HourFormat(context);
Beyond mobile: character encoding can be a large discussion on its own, but suffice to say, learning which encoding the platforms are using (in this case, UTF-8), and ensuring that translated assets are using the same encoding is key (ie: not Western Latin, not MacRoman, etc…). I’ve worked in the past on web applications and database applications which have had trouble with “special characters” (in some cases this was considered to be an apostrophe: ‘). This experience shows that the application simply just needs to work, regardless of what characters are in the text; there is no excuse to not get this right as appropriate utilities and facilities exist to properly encode any and all text correctly, it’s a problem that’s been solved over and over again at this point.
Third Lesson: Google Translator Toolkit is Your Friend
When the first few people approached me about doing translations for Sun Surveyor, I was not sure how to handle the translation process. I wound up sending .xml and .html files, which were edited and sent back. I may have done some further editing and cleanup, and in the process learned that various text editing applications and IDEs may convert text encoding, or otherwise not properly handle different encodings. Working through these things was a largely manual and time consuming process beyond the translation itself, and those folks deserve medals for their efforts.
Thankfully before the next set of translations, I discovered Google Translator Toolkit, which as of March 2012 began supporting Android string.xml files. It also currently supports iOS Localizable.strings files. This is amazingly useful by allowing one to upload files to be translated, with a UI that has the original text on the left, and editable translated text on the right, with the ability to comment, share, and more.
Supporting Android and iOS simultaneously: since most of the text of Sun Surveyor is the same on both platform versions, I’ve written some simple python scripts (shared here) to clean up the Android strings.xml file and convert it to the iOS Localizable.strings format. The help text (.html) is good to go with some minor edits.
Fourth Lesson: Localization is Empathy; Horizontal Expansion
The majority of Sun Surveyor adoption is in English-speaking countries, but there are many slivers of adoption across countries where English is not the native language. Presumably where there was no localization for these places, some knowledge of English was likely required to figure out this application; it would be nice to presume that it’s intuitive enough otherwise, but I doubt it. Proper localization (internationalization) of date and number formatting solves one issue (the Turkey Test), and translation of text and graphic assets solves another (language barrier). All creating an experience that is local and specific, and more importantly: comfortable, familiar. We, and our applications through us, express empathy for our user community when we take care to properly localize and translate our applications.
Finally, from a business perspective we can think of localization as horizontal expansion. Localization opens our application up to a whole new market of users who may not otherwise read or speak the default application language. This can only be a good thing, and lead to more adoption or sales, but the main added value here is in being customer-focused and having empathy for our users via providing a more optimal experience.
This image of a slide, in Russian, showing Sun Surveyor to a group of cityscape photographers was sent to me by Sergey Louks, who along with Nikita Sidorov performed the Russian translation. It thrilled me to know that something that didn’t exist less than 2 years ago can now be presented to an audience with whom I might not be able to communicate with otherwise.
In the wild journey this application’s taken me on, I’ve interacted with many other warm-hearted individuals who have helped with the translations. I hope to meet them all in person some day soon. Through the translation process, I’ve learned little bit about each language, and there’s really a huge richness of history and tradition behind them, alongside curious aspects. For example, beyond the use of Chinese characters in Japanese, Norwegian (Sun Surveyor is in Norsk Bokmål) has an intriguing story currently playing out that’s been fun to explore.