I’m betting, however, you want to jump in and see how localization works right away. So let’s do that; it won’t causeany issues for this project. You’ll get to internationalize your code shortly.
Localizing your project is a three-step process:
1. Add the languages you want to support to your project
2. Choose which resource files need to be localized, and into what languages
3. Edit the localized version of the files
Begin with the finished Pigeon project from Chapter 18. Select the project in the project navigator, and then select the Pigeon project (not the target) in the editor pane, as shown in Figure 22-1. Choose the Info tab and scrolldown until you find the Localizations section.
Figure 22-1. Project localizations
Your project has two localizations already: a Base localization and one for the development language. The development language is the language of the developer who created the project—that’s you.
The base localization is thelocalization used when no other localization is a good fit for the user.
Notice that Xcode says that some files have already been localized. You won’t find any indication of this in project navigator (yet), but if you open the project folder in the Finder (choose the Pigeon folder in the project navigator, right/control+click, and choose Reveal in Finder), you’ll see the structure of the
localization bundle, as shown in Figure 22-2.
Figure 22-2. Default localization bundle structure
In Pigeon, the InfoPlist.strings and the two storyboard files are localized. A localized file is one that has been moved into one or more specific localization bundles. Files that have not been localized are stored outside the localization bundles and are used for every language.
Since there’s still only one version of every file, the distinction between localized and non-localized resource files is largely meaningless. Let’s change that.
Back in Xcode, return to the Project Info tab, click the + button at thebottom of the Localizations group and
choose to add a localization for Spanish (es), as shown in Figure 22-3. Common languages are listed in the main menu. Many (many!) more languages can be found in the Other submenu at the bottom.
Figure 22-3. Adding a localization to the project
Xcode will then prompt you for which files to localize, as shown in Figure 22-4.
The list will include all of the files that are currently localized. If a file doesn’t need to be localized for this language, uncheck it. The ReferenceLanguage is the version of the file that will be copied to create this
localization. If you’ve already localized for some languages, it might be easier to choose a language that’s similar to the one that you’re creating. If you werecreating a localization for Icelandic, it’s probably easier to start with the existing Norwegian translation, rather than English.
Figure 22-4. Choosing files to localize
In the File Types column, some files have a choice of how that file is localized. There are two ways to localize Interface Builder files: localizing the entire file or creating just a string translation file. If you choosethe former, a copyof the entire Interface Builder file is placed in the localization bundle. This permits you to
change anything in the interface for the new language. You can change the titles of buttons, choose different images, set different text alignments, specify different fonts, add
Localizing for languages like Hebrew, that read right-to-left, often require radical alterations to the layout of the interface. Views might need to be resized to accommodate longer (German)or shorter (Chinese) titles.
On the other hand, if the only changes required are the textual titles of buttons and other control objects, you can localize the interface with a Localizable Strings file. You’ll learn about, and create, these files later in this chapter.For this demonstration, change the file type of both storyboard files to Interface Builder Cocoa
Touch Storyboard, as shown in Figure 22-4. Click the Finish button.
In the project navigator, the InfoPlist.strings and the two storyboard files now have expansion triangles next to them, as shown in Figure 22-5. Expand them and you’ll see the localized version for each language.
Figure 22-5. Localized files in the navigator
The files in your project folder have changed too. If you return to the Finder you’ll see that Xcode has created an es.lproj bundle and copied the three resource files into it, as shown in Figure 22-6.
Figure 22-6. Project file structure with multiple localization bundles
Xcode, thankfully, hides the bundle structure from you in the project navigator. Instead, it presents the much more rational picture of your resource files, grouping together the specific localizations of that resource into a single,expandable, item.
To localize a file, just edit the language specific version. Really, that’s it. Expand the Main_iPhone.storyboard (or _iPad)
file group and select the Main_iPhone.storyboard (Spanish) localization, as shown in Figure 22-7. Selecting the filegroup is the same as selecting the base or development language version. So if you don’t choose to
edit a specific localization, you’ll be editing the default one.
Figure 22-7. Editing the Spanish version of the iPhone storyboard
Edit the button titles in the two view controllers, resizing them as needed, using Table 22-1.
Table 22-1. Spanish button titles
English Title Spanish Title
Remember Location Recordar Ubicación Map Mapa
Satellite Satélite
Hybrid Híbrido North Norte
Heading Rumbo
Run the app. You won’t notice any difference, as shown on the left in Figure 22-8,
because the preferred language is still English. Press the home button and open the Settings app.
In General ➤ International ➤ Language, change the language to Español and tap the Done
button. The simulator, or device, will perform a “warm” restart. This will cause all running apps to stop. When they start again, they’ll be using a different set of localized resources.
Figure 22-8. First attempt at localizing Pigeon
From Xcode, run the Pigeon app again. This time, it’s in Spanish! The middle of Figure 22-8 shows localized labels for the buttons, and even some of the map labels have changed (courtesy of the Map Kit).
You’re not done yet, though. Tap the Recordar Ubicación button and take a look at the alert (on the right in Figure 22-8). That doesn’t look like Spanish to me. That’s because you didn’t internationalize your app first. It’s time tocircle back and do this right.
Internationalizing Your App
Internationalizing your app consists of making the code and project changes needed to support localization. This breaks down into four tasks:
n Adding language bundles to your app
n Translating string constants
n Getting localized properties
n Using iOS formatter objects
You’ve already done the first one in the previous section, adding an es.lproj localization bundle to your app. The problem in Pigeon is that it has string constants that are in English. These need to be replaced with localized versions.
Internationalizing String Constants
The Cocoa Touch framework has a set of macros—they look like C functions, but they’re not—that make localizing your string constants (relatively) easy. These macros work hand-in-hand with a development tool that extractsyour app’s string constants and turns them into resource files, stored in your localization bundles. Here are the four macros:
NSLocalizedString NSLocalizedStringFromTable NSLocalizedStringFromTableInBundle NSLocalizedStringWithDefaultValue
The first one is the mostly commonly used, and the only one you’re going to use in Pigeon. The others are useful in situations where you have a lot of strings and need to organize them into groups, or read them from other bundles,but none of that applies here. The workflow for all of them is the same:
1. Embed your string constants in NSLocalizedString... macros
2. Run the genstrings tool to extract the strings in your code
3. Localize and edit your .strings resource files
I could explain how this all works, but it’s so much easier to just show you. Select the HPViewController.m
file and find all of the strings the user will see. In Pigeon, these are in just two sections of code. In the
-dropPin: method, edit the alert object construction code so it looks like this (modified code in bold):
UIAlertView *alert = [[UIAlertView alloc]
initWithTitle:NSLocalizedString(@"What's here?",@"Pin alert title")
message:NSLocalizedString(@"Type a label for this location.",
@"Pin alert message")
delegate:self
cancelButtonTitle:NSLocalizedString(@"Cancel",@"Pin alert cancel button")
otherButtonTitles:NSLocalizedString(@"Remember",@"Pin alert save button"), nil];
The string constants are rewritten as NSLocalizedString statements. The first argument is the original, untranslated, string literal. The second is a hint or a description of what the string means
or how it’s used in the program. This second argument doesn’t become part of your program. It’s used solely to aid the translator.
There’s only one other English string constant in this program, and that’s in the -alertView:clickedB uttonAtIndex: method. Find and edit this statement (modified code in bold):
name = NSLocalizedString(@"Over Here!",@"Default location label");
The strings in your app have now been internationalized. The next step is to turn them into resources.
No comments:
Post a Comment