iOS Localization: The Ultimate Guide To The Right Developer Mindset - Part II

In Part 1 we have been talking about localization and Internationalization and how to start on localizing your iOS App. In Part 2 we will continue right where we left off.

Add Comments for Translators

You can add comments for translators directly in Interface Builder. NSLocalizedString allows you to include both a unique key and a comment destined to help better understand what is to be translated. For example, in English, the same word “clear” is used as an adjective and a verb, whereas in many other languages two separate words are used. The same is true of the English word “run”. A comment for translators to indicate how the word is being used will help them to make a suitable translation and enhance the user experience for the app in the target language.

Within base Internationalization, the NSLocalizedString macro will pick out the hard-coded texts in your app. Base Internationalization will also pick up the .xib files (the XML files defining graphic user interfaces developed in Interface Builder, with resources like “Label” and “Button”). However, Xcode builds a .strings file for every .xib resource, so you may want to deal with this before sending extracted text to be translated. One option is to add a comment to describe the resource (you can do this in Interface Builder directly) to say what it is, and (therefore) whether translators should translate it or ignore it. Another option is to simply delete such .strings files from the files that are given to translators.

Auto Layout

Other languages may differ significantly in average word length, compared to English. Continental European languages such as French, German, and Spanish may be 20% to 50% longer, whereas Asian languages tend to be 30% to 50% shorter. By using Auto Layout, the views in your storyboard will not have fixed origins, widths or heights. Views will therefore be repositioned or resized appropriately if changes in a language or a locale cause changes in text length. Auto Layout is another reason why developers can work with one set of .storyboard and .xib files for all languages.

Plurals, Numbers, and Dates

Languages differ in how they handle plurals, whether for objects or for units of measurement. Some languages have one plural form, some have two, and others have three or more. For different plural rules, alternate strings are specified in a .stringsdict file, which is an XML property list with a .stringsdict extension. This allows you to use one string in your code that will then be localized using the plural rules in the .stringsdict file. The NSLocalizedString macro (see above) will search an existing .stringsdict file (such as Localizable.stringsdict) before searching any associated strings file with the same prefix (such as Localizable.strings). A .stringsdict file can be considered to be an addition to the corresponding .strings file to indicate which rules the system must follow when plurals are involved.

To represent or convert numbers in different formats, use a class in the iOS SDK called NSNumberFormatter. This class automatically adjusts any number to the user’s locale. For example, using NSNumberFormatter would result in displaying 5.4 in the US locale, and 5,4 in the French locale. For managing dates, there is the corresponding NSDateFormatter class.

Beware of English Short-Cuts

Some phrases in English allow you to freely interchange the subject and the object, where this would be impossible in other language. For example, the phrase “Chris told you” can be inverted to give “You told Chris” in English. If this worked in every language, then the string to be localized might be represented as “%@ told %@” with the localized version of “you” inserted in the right place. Unfortunately, this approach fails in both German and French, among other languages. In French, for example, “Chris told you” is “Chris t’a dit”, whereas “You told Chris” would be “Tu as dit à Chris”. So in this case, two localizable strings are required, “%@ told you” and “You told %@.” As a general rule, sentences (like these) should be kept together as complete localizable strings, instead of being divided into parts.

Avoid Automatic Translation

After the marvels of the various tools for the iOS platform, you might be tempted to try automatic translation of your strings files. This is unlikely to be a good idea, however. Even if the best automatic translation system can be surprisingly good in some cases, it may be abysmally bad in others. The problem is that you will never know when it is good or bad. Automatic translation is handy for making sense, more or less, of content created in a foreign language. However, it cannot provide the quality you need to make a favorable impression on native language speakers in the country or region where you wish to sell your app. Instead, you should choose a competent, reliable translation resource (a translator or a translation agency) to translate your strings properly.

Pseudolocalization

How will you know if you found everything that needed to be localized? Xcode provides the possibility of “pseudolocalization” to help you see any instances of missing localization. You’ll have to check every screen that a user would see to verify that every string has been localized. If you can see any instance of your original, unmodified user-facing text, the necessary preparation for localization has not yet been completed.

By using double-length pseudolanguage, you double any visible text in the subviews of the storyboard. This lets you see the way in which long strings are displayed, for languages using long words, where English uses short ones. For example, in French, the English word “now” is typically translated as “maintenant”, which is more than three times as long.

This is another situation in which you will have to use judgment, rather than apply predefined rules. Having said that, one general rule still applies. If the pseudolocalization for example with double-length words and strings looks ugly, then it probably is ugly and needs fixing before being distributed to users using that language.

App Store Description and Keywords

The App Store description and keywords for your app must be localized as well. Once again, resist the temptation to use an automatic translator! Good keywords could mean the difference between market success and failure, but keywords are even less amenable to literal translation. To do well, a keyword used for the App Store should have high volume and low competition. In other words, many people should search on it, but few apps should correspond to this keyword. How people from certain countries or cultures search for keywords is an extra layer of complexity on top of the differences in terms of language.

Exporting and Importing Localization Strings

Xcode offers a quick export function to export all the .strings files for a given language within a single XLIFF file. XLIFF stands for XML Localization Interchange File Format and XLIFF files are used by many translation systems. The XLIFF file from Xcode will contain the base internationalization files (one per .storyboard and per .xib file), a Localizable.strings file, and an InfoPlist.strings file.

The XLIFF file will then be translated, i.e. localized, by your translation resource. Before you send the XLIFF file for translation, check that the development language copyright notice in the Info.plist file is correct (this is a human-readable copyright notice included by Xcode.) While translation is being done, you can continue to develop your iOS app. One XLIFF file per localization should be sent back to you with the appropriate language prefix: for example, es.xliff for Spanish, fr.xliff for French, and so on.

The first time you export localizations (in an XLIFF file), the project folder contains only the base internationalization with the .storyboard and .xib files. Xcode creates the strings files from the project files, for inclusion in the XLIFF file to be exported. However, the strings files are only added to the project when localizations are imported afterwards. At this moment (import), the language and the strings files for the language are added by Xcode to the project. For example, by importing fr.xliff in the standard XLIFF format with the target language attribute, the French language is added to the project. Xcode creates an fr.lproj folder in the project folder and adds a localized copy of Localizable.strings and InfoPlist.strings to the fr.lproj folder. The next time localizations are imported, the string files are merged with the existing project files.

Locking Views While Waiting for Translations

It may be advisable to lock views to avoid unintentional modification while waiting for translations to come back. By choosing a locking level, you can determine which set of properties to lock, blocking the possibility to change those properties in the inspector or project editor. You can also choose Inherited to use the lock profile from the parent view. As an example, if you are waiting for nib, strings or an XLIFF file to be localized, choose to lock Localizable Properties. On the other hand, if you are moving translations into a nib (xib) file, choose to lock Non-localizable Properties to avoid making any unwanted changes to the rest of the file.

Testing Localizations

Localizations, like any other aspect of an app, must be properly tested before an app is released. There are various possibilities:

• Preview the iOS localization in the Interface Builder.
• Run the app with options to find text that has not been localized
• Run the app with all languages and regions supported

Perhaps most importantly, however, the app should be tested in its localized version by users who are native speakers of the language concerned.

Conclusion

The creation of versions of apps for the international market is increasingly a necessity, rather than a luxury. Depending on how you see things, iOS localization (and internationalization) of your app may offer you a stimulating challenge or take you further outside your comfort zone than you imagined. iOS and Xcode offer a range of tools to make your localization of your app easier, faster, and more reliable. However, the real success of your localization also depends on your awareness of the quirks of language, the quality of your (human) translators, and your determination to provide a great experience for your app for users of each language and culture for which localization takes place.