BLOG / POSTS
Internationalization
Internationalization, commonly abbreviated to i18n, is not a feature. It is not something you do after you have shipped your product. It is something you need to build in right from the beginning as part of your core design and architecture.
If you only ever intend to sell your app in one particular region of the world where only one language is spoken, where business is conducted in a single currency, then you can ignore this article. Still reading? Of course you are because in this day and age, no software product is developed with such a narrow focus.
Your app, whether it is translated or not, must be internationalized. It must work just as well for the jogger in France who is tracking his runs in kilometers and meters, as it does for the Korean gamer who goes by the name “전우치”. And don’t forget about the user in England who needs to understand that 1/4/2013 is April Fool’s Day and not 4 January 2013.
And now to add one more dimension to this. A truly internationalized app is one that can be easily translated into another language, without having to change any code. When you choose to actually translate your app is a whole different subject, but more on that in another article.
Here are the things you need to do when designing your app in order to make it an internationalized app:
* Externalize all of your UI strings from code into the appropriate externalized resource files.
* Use the international date and time utilities provided in the SDK to input, process, and display dates and times. Timezone support is not something you need for foreign languages - time zones exist in the English speaking worlds of North America and Australia.
* UTF-8 all the way. Make sure that every piece of text or data entered by the user and persisted to your database is UTF-8. Usernames, comments, annotations, tweets, product descriptions etc. should all be in UTF-8.
* Use the international sorting libraries when sorting data. The bubblesort or quicksort that you learned in school will not work on non-ASCII data.
* Separate localizable text from graphics and render this text at runtime, and not in Photoshop.
Remember that English speaking users require your app to be fully internationalized from day one. Such people can live in faraway places, where the “Quarter Pounder” might be known as the “Royale with cheese”. Building a truly internationalized app from the start will also allow you to easily localize the app when the time comes for you to market and sell your app to the non-English speakers of the world.