Preparing Your Nib Files for Localization
The native integrated development environment (IDE) for OS X consists of Xcode, Interface Builder, and a suite of build, debugging, and performance tools. Developers use Interface Builder to create user interfaces for their applications. Interface Builder saves these interfaces as archives called nib files. You can localize nib files just as you can localize image and sound files.
Nib files store the user interface of your application, including windows, dialogs, and user-interface elements such as buttons, sliders, text objects, and help tags for these elements. A nib file also stores the connections between these objects that cause actions to be performed when the user activates controls.
Using Nib Files Effectively
Translators typically localize the pieces of the user interface all at once, adjusting graphic elements to account for changes in string lengths. In any medium-size or large application, it’s usually a good idea to put each window or panel (that is, dialog) in its own nib file. This practice not only makes it possible to load the user interface lazily (that is, to load pieces as they’re used), but it also permits localization to progress in more incremental steps. It’s also a good idea to put the menus of the application in a separate nib file.
Translators can use a combination of Interface Builder and
ibtool to localize nib files. Using these tools, the translator would open the nib files in a given language
.lprojdirectory, localize the strings, change the sizes of the user-interface elements to accommodate the new strings, and save the changes back to the nib files. There are a few other things to watch out for:
Objects in a nib file typically have connections between them that should not be broken. Make sure you lock all connections before handing your nibs off to translation. For information on how to lock down your nib file, see “Localization” in Interface Builder User Guide.
Dialogs and windows usually have minimum or maximum sizes that are specified through the inspector. If a dialog or window must be made wider for a given language, the translator should check to make sure that the minimum size is also updated to an appropriate value.
Some user-interface objects support help tags—explanatory text that appears when the user moves the mouse over the object for a short period. You can define the help tags for an object in Interface Builder’s inspector, where the translator can also localize those strings.
In your nib files, it is also important to remember that localization will likely change the size of visible text in your windows. If text labels do not have room to expand, the localizers may have to adjust the size of your window or the positions of the label or other controls. In general, you should expect text labels in English to expand by up to 40% in length during translation.
Viewing Localizable Strings in Interface Builder
In Interface Builder 3.0 and later, you can obtain a list of the strings in your nib file by choosing Tools > Strings. The window that appears (Figure 1) contains a list of the objects in your nib file along with entries for each property that contains a string that might be displayed to the user. The Value column shows the string (if any) that is set for each property when the nib file is loaded into memory.
In addition to viewing all of the strings in a nib file, developers and translators can also use the Strings window it to edit the string values. Double-clicking the value for an entry makes that entry editable. If you specify a new value, Interface Builder applies that value to the specified property.
For more information about using the Strings window, see Interface Builder User Guide.
It can be tedious to translate nib files manually and even more tedious to propagate subsequent design changes to the already localized nib files in your project. Fortunately, the
ibtool command-line utility makes propagating changes to other nib files much easier. This tool operates on a dictionary of all the strings in your nib file. Using it, you can extract the strings from the nib file, translate them, and then inject them back into the nib file. Alternatively, if you already have valid translations, you can inject the already-translated strings into a master nib file containing any recent design changes to update the localized nib files.
The following example shows you how to extract the English strings from the main nib of a project into a new strings file. You can store a copy of the resulting file for use later or give the file to the translation team.
ibtool --generate-strings-file MainMenu.strings en.lproj/MainMenu.nib
The following example takes the original English-based nib file and merges it with the translated strings to create a localized version of the nib:
// The translated strings are in the de.lproj directory
// with the same name as the original file.
ibtool --strings-file de.lproj/MainMenu.strings --write de.lproj/MainMenu.nib en.lproj/MainMenu.nib
For more information about how to use
ibtool, see “Localization” in Interface Builder User Guide.
Generating Localized Nib Files
Internationalizing applications for OS X involves, in part, putting localized resource files in the proper location in your bundle. Fortunately, Xcode provides help with organizing your localized resource files. To internationalize a resource file in Xcode 3.1, do the following:
Add the resource file to Xcode.
Expand your project in the Groups & Files pane.
Select the Resources folder.
Choose Project > Add to Project….
Use the file browser to navigate to the resource, select it, and click Open.
In the dialog that Xcode displays, select “Copy items into destination group’s folder”, choose one of the “relative” reference styles (for example, “Relative to Project”), and select the desired target. Click Add.
Select the resource file and open the Inspector window (File > Get Info).
If the file is not already localizable, click the Make File Localizable button in the General tab of the Inspector window.
In the General pane again, click the Add Localization button. In the sheet that appears, select or type the locale you want to add. Xcode copies the resource to the other
If your resource file is a plain text file, you should be sure to set the File Encoding for each localized copy. You can set the default localization of the file before you make the file localizable. You can use different encodings for different localized versions of the file. To set the encoding for a specific localization, choose that localization in the Groups and Files pane and change the setting in the Inspector window.