(What You Need to Look Out For When Developing an App with Localization)
If you are an app developer and you are reading this, there’s a good chance you are thinking about app translation/localization. This is a wise decision on your part, as it dramatically increases your pool of potential users, allows your app to be used globally, and can potentially lead to significantly more revenue from your increased user-base.
As great as that all sounds, you may be confused as to how you even go about localizing your app. Many developers will overlook the localization process, or at the very least, wait to worry about it until after they finish with the development process. However, doing so will only add to your frustrations later on. So let’s take a look at localization and the reasons why it’s such a ‘tricky’ issue.
While this may not be a complete and in-depth guide to all things app development, I can perhaps help shed some light on the best industry practices for localization.
- The first thing you should do in planning for localization is to resource all of your strings. By putting your text into resource files, you can easily separate the text from the coding, translate the text into whatever language(s) you want, and have your app easily differentiate between which language to display.
- There are many differences between languages in terms of structure, so as a general rule refrain from concatenating strings. For example, some languages place the modifier before the noun, others place it after. So if you concatenate and then translate the sentence, the structure will be completely wrong. It is best practice to separate items such as modifiers from the item and create a function specific to the language you wish to translate into.
- Refrain from concatenating punctuation as well. It may seem like a good idea to concatenate punctuation so that you can reuse the same string in multiple types of sentences. However, even punctuation has different rules for each language. For example, in French there is a space before a colon, while in English the colon is placed directly after the word.
- Use full locale to take into account various dialects within a particular language. For example, there is European Portuguese and Brazilian Portuguese, European French and Canadian French, Castilian Spanish and Latin American Spanish, and many other examples. Within each dialect exists its own grammar rules as well, not to mention different language translations and spellings. By using locale, it includes both the language and country code, supports alternate spellings, date formats and other variations between dialects.
- Time and date formats are subject to various inconsistencies between different languages and locations. Some countries put the month first when writing the date, in others it’s the day. Some rely on a 24-hour clock, others use 12-hour time along with AM and PM (which also can differ in terms of position placement). In order to account for all of these differences, you should store dates and times in a standard format such as ISO time or epoch time and use a library to format them for a given locale.
- Be sure to make the formatting of people’s names customizable in order to account for the name structures in different languages. For example, in English, the given name comes first, followed by the family name (last name). However, in most Asian countries it’s presented the opposite way. The family name comes first, followed by the given name.
- Allow enough room for text length to grow and shrink, depending on the language being translated into. Some languages require much more room than others to say the same thing. German and Finnish both usually run a lot longer in their translations, while character-based languages such as Korean and Chinese tend to run a lot shorter. Without taking these lengths into account, you can end up with overlapping text or have too much space between words. Neither are a desired result. Many developers have their own methods for dealing with such issues, as there is no one perfect way, unfortunately. Some will align their texts to the right or place them above the controls or both. For this issue, perhaps consult a developer forum to see how other developers deal with the issue.
- Right-to-left languages such as Arabic and Hebrew can pose a unique issue by completely reversing the direction of the text presented. However, you can work with these languages without too much difficulty by utilizing HTML properties that indicate the direction of the text. Just be sure to set your alignment properties to the opposite side to ensure proper text spacing.
- Don’t forget to test throughout the development process. Undoubtedly you’re going to run into some snags. So it’s best to test early and often to avoid being hit with a bunch of issues at the end. It’s much easier to test one aspect at a time, that way you can tell exactly where an issue lies and fix it before moving on to the next aspect.
While this list may not necessarily be a complete and total accumulation of everything you need to look out for when developing an app for multiple languages, it is certainly a great starting off point as these are the main issues most developers run into during the process. If you find you have these under control, then you should be in good shape for presenting a well-rounded and well-formatted multilingual app.