Apple Watch Internationalization and Localization

There are plenty of articles on the blogosphere extolling the reasons why you, dear entrepreneur/product manager/software developer, need to consider internationalization (I18N) and localization (L10N) when designing your next killer application. Briefly, internationalization is the process of supporting more than one language in your application. Localization is the process of supporting local and regional differences in the display and formatting of times, dates, and currencies.

Your Apple Watch application is no different. Of course, every mockup and advertisement you’ve seen thus far has had the Apple Watch UI displaying English, but if you support multiple languages in your iPhone application and are designing an Apple Watch extension, you need to support those languages there as well.

In this article we’ll take a look at how to internationalize and localize your Apple Watch application. Our application will be a simple one and present a “Hello World!” label followed by the time (in localized format) and an appropriate time-based greeting. For example, at 9:00 AM the greeting would be “Good morning” in English.

As usual, we’ll begin with a starter application so you can jump right into internationalization and not spend time laying out the Apple Watch interface. Grab the zip file, extract, and open the applewatch18n project.

For this application we’re going to use two types of internationalization techniques with Xcode: internationalizing the storyboard, and creating a Localizable.strings file. Internationalizing the storyboard is a good technique to use when you want to provide for static labels to be displayed in the appropriate language. For example, if you have a button labeled Close and want to display Cerrar in Spanish, you likely want to use Storyboard internationalization. In our case the Hello world! label on the Apple Watch interface will be displayed as Hola mundo! in Spanish, so let’s go through the steps of creating an internationalized storyboard.

Note: While some application platforms separate the I18N and L10N steps, Xcode (and iOS/OS X) combines them into Localization. We’ll use the terms interchangeably.

The first step to adding localization to your application starts with the Localizations section of your project. Go to the applewatchi18n project in Xcode and find the Localizations section. Click on the + sign.

Choose Spanish (es) from the menu and you will be prompted to select the files you want localized. Although we won’t use Main.storyboard or LaunchScreen.xib in this example, leave them checked, and of course since we are interested in localizing our Apple Watch interface leave Interface.storyboard checked. Leave the Reference Language as Base.

Click Finish.

Notice now there is a disclosure triangle next to Interface.storyboard in the project explorer. Click on it to reveal:

Let’s take a look at Interface.strings (Spanish):

The gibberish strings you see are Xcode Object IDs assigned to the UI component when you add them to the storyboard in Interface Builder. Just think of them as a automatically generated unique identifier (because that’s what they are) for the UI components. That said, the object IDs you see when you run this tutorial in Xcode will be different.

Notice the line "neb-bX-Mot.text" = "Hello world!";. Here is where we’re going to apply our Spanish text for the label we want to display “Hello world!”. To change it, simply replace the Hello world text with Hola mundo.

Tip: The dot-notation .text indicates you are localizing the text property of the given UI element.

To test our new localization change we’re going to have to change the language of our iOS simulator from English to Spanish. This can be done by launching the simulator and going to Settings – General – Language & Region and selecting iPhone Language. Español should be the first selection. Select it and press Done in the upper-right. The simulator will prompt you to confirm that you want to change the language to Spanish, so press Change to Spanish.

Tip: This may sound obvious, but When changing the language on the iPhone it is a good idea to have a basic grasp of the iPhone terms in the target language. For example, Settings is Ajustes in Spanish. Although you can use context clues (such as the icon for Settings), when you need to drill down into multi-level menus and either don’t know the language or alphabet you’re working with, it can be difficult or time-consuming to navigate the interface.

Now that our simulator is in Spanish, run the WatchKit app. You should see something like:

Let’s move on now to localization of the time. Now I will be honest: when I see or hear time given in 24-hour (or “military time” as Americans refer to it) notation, my brain has no immediate understanding of the relative time-of-day. In the end, when I see something like 15:45 I subtract twelve from fifteen and understand it to be 3:45 PM, which instantly puts me in the afternoon. But, as I’ve discovered in my travels, many places in the world prefer and use 24-hour time.

Our goal will be to respect the localization/regionalization setting of the user’s iPhone and display the time in their preferred format. To accomplish this we’re going to add some code to our InterfaceController.swift file:

This routine looks up the iPhone’s current locale and then creates a formatted time string for the supplied date. Update InterfaceController.swift willActivate as follows:

Run the application. Assuming no changes were made to the simulator, you should see the AM/PM notation used for the label. We want to use the regional time format for Uruguay (which uses 24-hour notation), so, if your simulator is still in Spanish, go to Ajustes – General – Idioma y región – Región and select Uruguay.

Run the application again and notice that AM/PM is no longer displayed and the time is formatted in 24-hour notation.

Thus far we’ve looked at internationalizing static labels (with an Interface.strings file for our storyboard) and respecting the regional settings for the time. Now we’ll turn our attention to dynamic UI elements that can display different strings based upon the software’s logic.

To get started, let’s add a strings resource file called Localizable. Using Xcode File – New – File, select iOS – Resource and a Strings File template.

Click Next.

Name the file Localizable and ensure it is added to the WatchKit Extension target.

Now that we have the Localizable.strings file created, we need to configure it as a localized file. In Xcode select Localizable.strings that you just created and in the File inspector find the button that says Localize.

Click Localize and Xcode will ask whether or not you want to localize the file and allow you to select the base language. Select Base and click Localize.

The File Inspector pane will update and in place of the Localization button you will see the languages that the file has localization support for. The default selection will be Base (which is, in fact, English), and we want to add Spanish. Select the checkbox next to Spanish and like Interface.storyboard, Localizable.strings will get a disclosure triangle in the project navigator.

When working with localizable strings the base language string is used as the key from which to look up translations. For example, the following table lists the base strings (which happen to be in English) along with their Spanish translation.

To implement this table in the Localizable.strings file, select the Spanish version of the file and add:

Notice that you don’t necessarily have to add content to the base Localizable.strings file. The reason will become clear in a moment.

Add the following function to the InterfaceController:

The above code takes the supplied NSDate and extracts the hour component, and then derives an appropriate greeting. Now, let’s display this greeting in our interface with the following in willActivate:

The key function here is NSLocalizedString which returns the localized version of the supplied string. If there is a localized string available for the target language it is returned. If there isn’t one, the string supplied is returned. For example, if you forgot to provide a Spanish translation for “Good evening” in your Localizable.strings (Spanish) file then “Good evening” would be returned by the function. This is why technically speaking you did not have to provide a mapping for the English translation, the function greetingForTime is supplying it.

Note: The comment argument to the NSLocalizedString function is to provide a hint to human translators that are supplying translations. I have never made use of it and have only used a blank string in code.

Running our application with the simulator still set to Spanish we see:

Note: As you can see in the screenshot, there is a difference between the language and the time format. Although our phone is set to Spanish, our region was set to the United States.

Now that we have run our application in Spanish, we need to switch the simulator back to English and ensure it is functioning as expected. If you are writing applications that support multiple languages you will have to go through this process for each and every language. Nothing is as embarrassing as claiming you support a given language in your application only to let a typographical or grammatical error get published on the AppStore (it’s buenos días, not buenas dias!)

Get the Code

You can find a completed version of the application in this zip file. Try adding a German translation to the application!