If your app will be used by people all over the world, take the time to consider localizing it appropriately. Localizing your app is a great way to increase downloads and grow your user base.
Here are 5 basics to consider when localizing your app:
1. Different Word Lengths
Some languages, such as German, have longer words than other languages like English. When designing your UI controls, you’ll need to account for this. A common way is to make the buttons large enough to accommodate the longest text.
You could also add code to the UI controls to have it resize itself if the localized text would not fit. But resized controls can also affect other controls on your layout, so a system like auto-layout can also help greatly to ensure that your UI adjusts itself appropriately when the text changes.
2. Don’t use Google Translate
Find someone that natively speaks both languages to do your translation. Obviously, you will need more than one person if you are translating to many languages.
Google Translate has its uses, but it’s translations often have unusual (or wrong) words and phrasing. So even though the text will be in the localized language, it could still remain difficult for native speakers to understand.
You don’t want your translations to say “Throw me down the stairs my shoes.” when it should say “Toss my shoes down the stairs to me.”
3. Don’t forget about dates
Date formats vary, so be sure to consider how they are displayed. What is the date for 3/7/14? Is it March 7th, 2014 or July 3rd, 2014? For internal dates that are not displayed to the user, you should use a standard format, such as SQL Date: YYYY-MM-DD.
When displaying dates, you should always use the user’s OS settings. This applies to both short dates with just the numbers and long dates where the month and day are spelled out.
And remember the position of each date component. Some places might use “March 7th, 2014”, but others would use “7 march 2014”.
As with dates, numbers are also displayed differently. Not all countries use a “.” as the decimal separator. Not all countries use “,” as the thousands separator. The display of 3456.78 could be “3,456.78” is one location, but “3 456,78” in another.
Ask the operating system for the values specific to the user’s system settings.
And as with dates, when using numbers internally always use a standard and consistent format so that you can read them correctly regardless of the localization.
This trend continues with currency. Don’t presume that “$” is the currency symbol. As above, you should ask the OS for the specific currency symbol. And when storing currency values, do not include the currency symbol as that could make doing math on the values more difficult.