Localization in iOS
for your App to reach every part of the World.
Use of iOS devices are huge in number and people live world wide. In order to reach people efficiently and take a place in their heart and memory, speaking their language becomes essential. Simply put, your App needs to communicate in User’s native language.
By definition, Localization is feeding appropriate data in your App based on User’s language and their region. In iOS, this can be found under Settings→ General→ Language & Region.
You can change your iPhone language, region which you had set during initial iPhone setup process. Also, language preferences can be modified by clicking on the Edit button at the top, then choosing a language that you want to take over primarily in the Apps that support it. Make note that this is different from the iPhone language you have chosen above. I shall explain the significance of it at the latter part of this article. Refer Figure 1.1.
There is one other thing called Internationalization, which takes cultural differences into consideration. Information like currency, date format, number format, language etc., Essentially, Localization can be seen as a part of Internationalization. We cannot talk one without the other.
Locale and its Properties
Locale knows how different regions display symbols, dates, and decimals and whether they use the metric system. An instance of Locale represents one region’s settings for these variables. When you access the ‘current’ property on Locale, the instance of Locale that represents the user’s region setting is returned. Once you have that instance of Locale, you can know the region’s metric system, currency symbol etc.,
Likewise, when we use ‘NumberFormatter’ to present a number, it checks its Locale property and sets its format accordingly. Also using the number formatter’s instance method number(from:) to convert the string into a number, the number formatter is aware of the locale, it is able to convert the string into a number. If the string contains a valid number, the method returns an instance of NSNumber. NSNumber is a class that can represent a variety of number types, including Int, Float, Double etc., One can fetch such values represented by NSNumber through its instance.
Selecting Application Region on Xcode
Select the Active Scheme pop up and select Edit Scheme. Select Run on the left column and then select the Options tab at the top. Change the Application language/Application Region of your App’s target audience i.e Users. Refer Figure 1.2 and from here on remember to read the captions of all figures.
Double-Length Pseudolanguage
Pseudolanguages help you internationalize your App before receiving translations for all of your strings and assets. The built-in pseudolanguage, Double-Length Pseudolanguage, mimics languages that are more verbose by repeating whatever text string is in the text element. So, for example, “is” becomes “is is.” Refer figure 1.3.
The double-length pseudolanguage reveals a problem soon when lablel texts are lengthy: The labels go off both the left and right edges of the screen, and you are unable to read the entire strings. The fix is to constrain all of the labels so that their leading and trailing edges stay within the margins of their superview. Then you will need to change the line count for the labels to 0, which tells the labels that their text should wrap to multiple lines dynamically when needed.
Application of Base Internationalization
When internationalizing, you ask the instance of Locale certain questions. But the Locale only has a few region-specific variables. This is where localization — creating application-specific substitutions for different region and language settings — comes into play. Localization usually involves either “generating multiple copies of resources (like images, sounds, and interface files) for different regions and languages” or “creating and accessing strings tables to translate text into different languages.”
Before you go through the process of localizing resources, you must understand how an iOS application handles localized resources.
When you build a target in Xcode, an application bundle is created. All of the resources that you added to the target in Xcode are copied into this bundle along with the executable itself. This bundle is represented at runtime by an instance of Bundle known as the main bundle. Many classes work with the Bundle to load resources.
Localizing a resource puts another copy of the resource in the application bundle. These resources are organized into language-specific directories, known as lproj directories. Each one of these directories is the name of the localization suffixed with lproj. For example, the American English localization is en_US, where en is the English language code and US is the United States of America region code, so the directory for American English resources is en_US.lproj. (The region can be omitted if you do not need to make regional distinctions in your resource files.)
These language region and region codes are standard on all platforms, not just in iOS. When a bundle is asked for the path of a resource file, it first looks at the root level of the bundle for a file of that name. If it does not find one, it looks at the locale and language settings of the device, finds the appropriate lproj directory, and looks for the file there. Thus, just by localizing resource files, your application will automatically load the correct file.
One option for localizing resource files is to create separate storyboard files and manually edit each string in each file. However, this approach does not scale well if you are planning multiple localizations. What happens when you add a new label or button to your localized storyboard? You have to add this view to the storyboard for every language. Not scalable, not fun.
To simplify the process of localizing interface files, Xcode has a feature called base internationalization. Base internationalization creates the Base.lproj directory, which contains the main interface files. Localizing individual interface files can then be done by creating just the Localizable.strings files. It is still possible to create the full interface files, in case localization cannot be done by changing strings alone. However, with the help of Auto Layout, string replacement is sufficient for most localization needs.
NSLocalizedString and strings tables
In many places in your App, you create String instances dynamically or display string literals to the user. To display translated versions of these strings, you must create a strings table. A strings table is a file containing a list of key-value pairs for all of the strings that your application uses and their associated translations. It is a resource file that you add to your application.
To internationalize the string in your code, you replace literal strings with the function NSLocalizedString(_:comment:). This function takes two arguments: a key and a comment that describes the string’s use. The key is the lookup value in a strings table. At runtime, NSLocalizedString(_:comment:) will look through the strings tables bundled with your application for a table that matches the user’s language settings. Then, in that table, the function gets the translated string that matches the key. Refer below figures.
Remember to check ‘Base Internationalization’ checkbox from previous topic so that Xcode creates all necessary Localizable files for you. (Refer Fig 1.4 above). Also, check your App in the checkbox under Target Membership under File Inspector from the Utility Pane on the right.
Check this Out!
Remember when we talked about iPhone Language and Language preferences are different.
You can change your iPhone language and region which you had set during initial iPhone setup process. Also, language preferences can be modified by clicking on the Edit button at the top, then choosing a language that you want to take over primarily in the Apps that support it. Make note that this is different from the iPhone language you have chosen above.
Well, the drawback is that, not all languages in the World can be set as iPhone language yet. For instance, Tamil is not listed as one of the iPhone languages. Hindi and English(India) are the available iPhone languages from Indian region. So, if you have localized your App in other regional languages in India, lets say Tamil, your App is still going to run on the base development language which is English, unless the User has set Tamil in his ‘Preferred Language Order’.
Essentially, setting preferred language order will tell your App that it can display and communicate with the User in his local language if your App supports it. Our App above supports two of the User’s language(Tamil & Hindi) in the preffered language order list and runs in those languages in accordance to that priority order.
Nevertheless, if you are targetting only a particular group of Users from a specific region and if it doesn’t make sense to localize as per above process, your App needs to be harcoded and directly fed with data in that Language.
You can find the project hosted in GitHub here.
#DFTBC! — Don’t Forget To Be Curious! :)
P.S Supporting excerpts taken from: “iOS Programming: The Big Nerd Ranch Guide (Christian Keur and Aaron Hillegass)”. Due credits to the Authors.
