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

DZone 's Guide to

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

Here is everything you need to know to localize your iOS app and go global.

· Mobile Zone ·
Free Resource

Here is everything you need to know to localize your iOS app and go global.

iOS gets a thumbs-up from many developers as a platform for developing apps. With its integrated development environment Xcode and its storyboards, it seems like a perfect match for the ordered, logical thought that goes into app creation. But what happens when you want to release your app in languages other than the one you normally speak or work in? iOS Localization!

iOS itself may be wonderfully rational, but rules about how to move from say English to Spanish, or to Chinese, can be flaky at best. Yet, with a little broad-mindedness, you’ll find that readying your app for release in different languages is not as daunting as it seems.

For one thing, iPhones and iPads are multilingual by nature, so a specific version for a particular country or language will appear automatically on a user’s iOS device – or at least, as soon as users set their preferred language from “Settings-> General -> International -> Language.” Indeed, overall, the iOS development environment makes the mechanics of localization relatively easy.

The hardest part may be getting to grips with the idiosyncrasies of language and dialect, and the need to think beyond “just English” (assuming that English is your default language.) However, by taking this guide to heart, you can be sure to have a head start.

Internationalization Before Localization

Before you start to incorporate into your app the language content it needs for another country or region in particular, your app should be able to adapt to different languages and regions in general. For your app to succeed in foreign markets in general, it must appear as if it is a native app in each of the languages and regions supported. This is made possible through internationalization. Then, either individually or as a group, the specific language translations must be included in the app, which is the localization. People sometimes speak of internationalization and localization interchangeably, without differentiating between them. However, they are two distinct parts of the process. The iOS platform offers a number of tools to speed you through the following steps to the release of a localized version:


  • Extract language and locale dependencies from your user interface and code.
  • Use Xcode base internationalization to extract text seen by users from your .storyboard and .xib files.
  • Extract other user-facing text from your code.
  • In Interface Builder, use Auto Layout to adapt views as text length changes between languages.
  • Use standard APIs to handle different language systems and locale formats for dates, numbers, and plurals, for instance.
  • For right-to-left languages (Arabic and Hebrew, for example), mirror the user interface and change other text direction as required.


  • Export and import specific language localizations using standard file formats, such as XLIFF
  • Lock views in the user interface.
  • Send the exported files to translators.
  • Import specific language localization files
  • Check changes and ensure suitability for release through user testing.

Which Are the Language Priorities for iOS Localization?

If commercial success is the goal driving your app development, your marketing colleagues may have already answered this question, based on the marketing strategy of your enterprise. If you happen to be doing the marketing as well as the development, then estimates of sales potentials may help you establish release priorities accordingly. Base internationalization helps by organizing language support efficiently, so that additional languages are easy to add.

Don’t Reinvent the Wheel, Roue, Rueda, or Rad

As a general rule, when it comes to the mechanics of localization, iOS often already has a ready-made solution. This holds for items as intricate as the correct way to form plurals (some languages have as many as three ways of forming plurals, according the quantities involved.)  So before embarking on extra code or logic, check to see if iOS has already solved the problem for you.

Understanding Locale and Language

In iOS, language IDs represent a language, dialect, or script. They may also refer to language-specific resource folders stored in the app bundle. A locale ID identifies a specific region and its cultural conventions, such as the way dates, times, and numbers are formatted. For example, “fr-CA” indicates French (“fr”) as used in Canada (“CA”) and “de-AT” indicates German (“de”) as used in Austria (“AT”).

Base Internationalization

Base internationalization in Xcode allows you to deal with one set of app content resources for different localizations, rather than several sets or resources (one set per localization.) For instance, if storyboards are localized in an app and a new user interface element is added, base internationalization allows you to deal with that new element just once, instead of having to add it to several separately localized sets of storyboards.

Base internationalization creates individual folders for each language or localized version. Xcode prompts you to define the resources to be used within base internationalization, and also asks you to define your default language, for example, English.

  • .xib (and .nib) and .storyboard files are moved to the Base.lproj folder, which Xcode will create, if it does not already exist
  • String elements are extracted to project locale folders, such as en.lproj for English, also created by Xcode for the occasion.

By saving new UI files for iOS localization to the Base.lproj folder, you enable them to support base internationalization too.

Adding a New Localization

When you select the resource files and language for the localization, Xcode will then:

  • Scan the base storyboard
  • Identify the text/UI elements to be localized
  • Copy them into a strings file as key/value pairs.

This can include the visible strings of storyboards, such as label, button title, and navigation bar title.

Use of NSLocalizedString

The base internationalization in Xcode also provides the NSLocalizedString API to convert hardcoded strings in your app. For this, all the source files must be edited to change all the inline strings in the following way.

Suppose you have put the hardcoded text of “Greetings” into your app. With NSLocalizedString, you change this reference to NSLocalizedString(@”Greetings”, @”greetings message”). By doing this, “Greetings” becomes a token. The NSLocalizedString call will return the localized string according to the language being used for the application at that time. The other text, “greetings message” is a comment to give further information on the nature of the string (“Greetings”) being localized.

The Localizable.strings file must exist to hold all the output of the NSLocalizedString calls in one file (in the en.lproj localization directory in the first instance.) You can create your own Localizable.strings file for the outputs of the NSLocalizedString API or use the “genstrings” function. For this, in Terminal and from your project’s home directory, run the command:

find ./ -name “*.m” -print0 | xargs -0 genstrings -o en.lproj

This creates the Localizable.strings file in the en.lproj directory. The file can be modified directly, although its name should not be changed. It is also included in Xcode’s export of strings to be translated (see below.)

Localization of Different Parts of Your App

For each language for localization of your app, Xcode stores strings used in your app in a “.strings” file. Your code can simply use a method call to look up and retrieve the string required, according to the current language being used in the iOS device.

  • Strings in Main.storyboard and ViewController.m that are to be localized must be put in a separate file, where they can be referenced (for different language versions.)
  • The text of the label at the top of the screen is set in Main.storyboard, without the possibility to set this text programmatically (there is no IBOutlet.) To localize such storyboard elements without additional code, open the disclosure triangle to the left of Main.storyboard to see Main.storyboard (Base) and Main.storyboard (Language to localize into.)
  • To localize “Localizable.strings”, select this file using the left pane. Then in the right pane, open the File Inspector. Click on the button marked “Localize” and select “English” (assuming this is your default language), then click Localize.
  • Image files. Prepare or download the foreign language version of the image. In the project directory (use the finder), there should be two or more .lproj folders. One is en.lproj, and at least one other will correspond to the localization language: for example, for French, you will see the fr.lproj folder. The en.lproj folder corresponds to resource files for the English localization, and the fr.lrpoj to the files for the French localization. At this stage both folders hold the same image. In the fr.lproj folder, replace the existing image with the new localized one.
  • Audio files. Prepare or download the default language and the localized audio file. Copy the default language audio file to the project. Open the file inspector for this file and use the Localize button to select both the default and the target localization language as the supported languages. Rename the localized audio file to have the same name as the default language audio file and copy it to the folder for the localized version, selecting the “Replace File” option in the finder to do this.
  • App name. When a localized version of the app is created, Xcode also creates the localization version of InfoPlist.strings. Replace the corresponding key/value pairs in the InfoPlist.string file to override values, including the app name, currently in the Info.plist file.

Be sure to look for Part II to finish up!

ios ,mobile ,localization

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}