7 iOS Localization Troubles to Avoid
Why iOS localization? Business is international and Apple proves it. Reports from a year or two ago (2015) indicated that the company had started to sell more iPhones in China than it was already selling in the US. Of course, Apple also sells its iOS based products all over the world.
For product managers for iOS apps, that means an opportunity and a threat. If you don’t move to address the needs of different international markets, competitors will fill the void, build up their user bases, and attack you in your home market from a position of globally massive strength.
On the other hand, to market an iOS app to international markets for bigger market share and higher revenues, you have a head start. iPhones and iPads are multilingual by design, and make it easy for users to select the local language interfaces they favor. In addition, Apple offers tools to help your developers to produce local language versions of your app that make sense to your target users abroad.
You may already be thinking that there is more to iOS localization than meets the eye. You’re right! Here are seven perils and pitfalls to avoid if you want your app to succeed in the language markets of your choice.
1. Thinking You Don’t Need All That iOS Localization
What? After our inspiring remarks above, could anybody who has read this far doubt that localization is important, even essential to iOS app commercial success? The point we are making here is rather subtler. Don’t think that localization is simply about translating from one language to another. For instance, if you are an English-speaking person, your point of reference in terms of search engines is probably Google, the 800 pound SE gorilla in the Western world. But not in China (1 billion plus people), where Baidu beats Google. GALA, the Globalization and Localization Association, points out that “Baidu does better than Google because it looks and feels fully native to the Chinese-speaking audience.” The moral of the story is that localization may have to be done at more than one level, and that in some cases an overly shallow approach may not get you any more business benefit than no localization at all.
2. Confusing Internationalization and Localization
This is a key point when you’re trying to hammer out release schedules of localized versions with your development team. Full of enthusiasm, you want your Japanese localized version now, and your Spanish version by yesterday. After all, it’s just a matter of handing the app over to translators, right? Not quite. What your development team is probably patiently trying to tell you is that before producing these different localized versions, the software needs to be internationalized.
Internationalization essentially insures that your app can be sensibly localized into any language. It takes care of aspects like number and date formats, changing positions of variables in sentences according to language, and plurals. As an eye-opener, ask your development team how plurals work in Russian and Hebrew, for example, compared to English. Luckily, Apple’s iOS development framework offers developers tools to help get plurals and other tricky issues right the first time for any language.
Once the internationalization has been done properly, localization into a specific language is more a matter of handing over a file for translation to a competent translator or translation agency. A decision about whether to add a new localized language can then be as simple as a calculation taking into account the potential additional revenue compared with the translation costs and support effort.
3. Not Distinguishing Between Different Versions of the Same Language
Do you think English is the same, wherever it’s used? A quick look at date formats between US and UK English will prove the contrary. If you tell a British native that it’s October 5 using a US date format (10/5), he or she will think you mean May 10. And how about Chinese? GALA suggests that 30 percent of the Chinese population does not speak the country’s national language. Chinese consists of seven different versions or linguistic classifications: Gan (Jiangzinese), Guan (Mandarin), Kejia (Hakka), Min (Hokkien), Wu (Shanghainese), Xiang (Hunanese) and Yue (Cantonese). Mandarin Chinese federates 1.3 billion speakers worldwide, but Cantonese and the Min language are in close second and third position.
The equivalent in the US market for instance would be to produce different versions of your app for New Yorkers, Texans, Californians, and Alaskans. In the US, this extra effort would be unlikely to make business sense, because standard US English is understood across the country. By comparison, for China the effort is essential, because many people using one version of Chinese will simply not understand people using another version.
4. Missing or Mishandling Key Localization Aspects of an App
Don’t expect your developers to cover absolutely all the bases when it comes to localization. While they may correctly identify the different user-facing texts in the app, including help and error messages, they may not appreciate other niceties.
One example is keyword optimization to help your localized iOS app garner more attention and more users in the Apple App Store. In this case, you cannot even rely on the correct translation of the keywords that work for your iOS app in your home market. The reason for this is that keywords that work for a given market depend on factors specific to that market, such as culture, politics, and national or regional events.
For instance, linking your app to a popular presidential candidate in the US could do wonders for take-up in America. Yet it may fall flat in Germany, where they have their own national politics to keep them busy. Localization of a keyword has to be done from the inside out, so to speak, by first finding out which local language keywords are important to potential users of your app within that country and how fierce the local competition is to be ranked on such keywords.
5. Using Automated Translation
For understanding the general sense of a text written in a foreign language, automated translation software can be useful. However, for making a favorable impression on end-users, it can leave a lot to be desired. Such software can give very good results in some cases, and very bad results in others, but you’ll never know whether you’re getting the good or the bad. A classic example is the phrase “The spirit is willing, but the flesh is weak,” ending up translated into other languages as “The wine is ready, but the meat is underdone.”
So don’t given in to pressure from your development team to simply run your app’s file for localization through an automated translation system. They may not have developed your superior sensitivity to the far-reaching linguistic and cultural issues at stake (unless you give them this article to read.) While automated systems continue to improve in quality, there is no guarantee they will be able to replace human translation, at least in the foreseeable future. Competent human translation is therefore what you need, with empathy for your targeted end-users for a given localization.
6. Expecting Your Translators to Work “Blind”
Context and situation are often vital pieces of information for a good iOS localization. A word in one language may have several completely different possible translations in another. Classic examples in English for iOS and other software applications are words like “run” and “clear.” Only additional information about the context can help a translator understand whether the words in question are nouns, verbs, adjectives, or some other grammatical construct.
Checking translations after they have been done requires painstaking verification word by word. Murphy’s Law then says that the one or two incorrect translations that slip through will be precisely the ones that do maximum damage to the credibility and reputation of your app in its localized version. A better way forward is to give information to translators ahead of time, for instance as comments in the files to be translated. Your smarter, more localization-sensitive developers will already understand the desirability of doing this; you may have to gently educate the others.
7. Failing to Use Native Language Speakers to Test the Localized Version
You need human translators to produce a localized version of your app. You also need native speaker human beings to check the final result. It is true that Apple gives developers tools to check if localization of words or phrases has been missed, or if translations will cause screen layout problems due to differences in length. These tools are valuable, but they do not replace native speaker capabilities and judgment about the overall quality of a translation, and whether the localization will meet with approval and subscriptions in the market concerned.
Conclusion
The big takeaway from all this is that successful iOS localization is about seeing things from the point of view of the customer or user in the market you are targeting. This is a simple to say, but not always easy to do. Nevertheless, two important factors can help your iOS localizations to succeed. The first is that the localization tools Apple provides within the iOS framework can help your developers better understand and handle the issues of different languages. The second is that localization tools and local market experts and are available, externally if not internally, to give you an objective appraisal of what works in your localized app and what should be improved. So with these resources to help you, good luck… or rather, good localization!
Originally published on The Phrase Blog.
