First off, excuse the vague-ness of some things, NDA’s are still in effect.
I’ve just come off a project working with an international client on an app that involves both english and non-english translations. This involved both the app and an application server, both of which needed to handle internationalization. Over the course of this project, I’ve come to realise, few developers actually keep international users in mind. As such, for my own benefit as much as anyone elses, here is a list of things to keep in mind when working on software with international users.
Not everyone speaks or reads english
This seems like an obvious one, but, you’d be surprised how many apps are out there which have a large international user base and which only focus on english. Simple things like using the built-in strings file feature can make translating your app easy.
Google translate is not a reliable translation source
So you have your strings file, and decide you want to add spanish to your app? You go over to Google Translate and run your strings through the translator. You happily upload the new version thinking you’ve done a great service by providing support to international users. That is, until you find out that google translate accidentally translated your welcome page header into an insult to the users mother, or that the important instructions don’t actually make any sense.
The problem with google translate is that it isn’t smart enough to take into consideration the phrasing contexts of certain sentences, and will just translate verbatim.
Do yourself a favour, if you find yourself with a number of users asking for international support, don’t be afraid to ask them for help translating.
Validation can catch you off guard
This one speaks somewhat to my stupidity. And if I’m going to make myself look like an idiot, then hopefully someone can learn a lesson from it.
In Australia, our post codes are always 4 digits long, now of course, me not having the wisdom to think beyond my own country, implemented a check to ensure the given post code was a 4 digit long number (allowing the number to have its first digit as 0). I only realised my folly when reading about Germany and discovering they have 5 digit long post codes.
The issue is, we spend so long in our own little bubble of expecting certain things to be the way they are, we forget that some people do actually do things a little different.
My suggestion – learn about a few different countries, how they print phone numbers, zip codes etc
Time and decimal numbers secretly hate you
Ask me to write out the date for you and it will probably be in the form of dd/mm/yyyy. Ask an American and it will probably be in the format mm/dd/yyyy.
Unfortunately, this is by far the most annoying thing I’ve come across, especially in the way of time. First you start off handling time the way you are used to. Then you discover that some countries don’t consider AM/PM at all and work on 24-hour time. Then you discover that some of the countries that do, do AM/PM have special translations for it.
What about decimal numbers? Here in Australia we say 1,645.43. But in some parts of the world they would write 1.645,43 which is the same number.
Luckily, in iOS we have things like NSDateFormatter and NSNumberFormatter. I’ve made a solemn vow to always use these from now on when handling dates or numbers, and you should too.
Not everyone writes english
How well does your app handle unicode? What about your server? One thing I quickly ran into was using Django-Rest-Framework with unicode characters. Even when your app is being used in an english locale, the user might have added Chinese to their keyboards and could be happily typing a slab of text containing a mix of standard ascii and unicode characters.
If you’re web framework of application framework supports unicode, I suggest using it from the start.
Now, I may have forgotten something, and some of this may seem rather obvious. But internationalization is one of those things that can easily be forgotten about until it is too late.
My Blog 