The native integrated development environment (IDE) for Mac 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 XML 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 holds the connections between these objects that cause actions to be performed when the user activates controls.
Note: This section talks about Interface Builder and its nib files. However, much of the discussion is applicable to localized user-interface archives created by other tools.
Using Nib Files Effectively
Using ibtool
Generating Localized Nib Files
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, AppleGlot, and ibtool
to localize nib files. Using these tools, the translator would open the nib files in a given language.lproj
directory, 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 (an option in Interface Builder preferences) before handing your nibs off to translation.
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.
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.
Note: The ibtool
command-line utility replaces the nibtool
utility that was present prior to Mac OS X v10.5.
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 |
If you already have a localized nib file and want to update it incrementally, ibtool
provides several options. You can use the -I option to inject a new set of translations into the existing nib file. For more information see the ibtool
man page.
Important: Remember that translating the strings in your nib file is only one step of the localization process. The localizer may need to adjust the layout of views and controls to account for changes in string length. Also, ibtool
does not automatically update date and time formats associated with formatter objects.
Internationalizing applications for Mac OS X involves, in part, putting the resources localized for a particular language or region in the proper bundle location. In some situations, you might have to do this task by hand, such as with Code Fragment Manager (CFM) applications. Fortunately, for most occasions there are tools to help you.
Xcode provides the File Reference Inspector to assist you with internationalization. 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 pane 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 .lproj
directory.
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.
© 2003, 2009 Apple Inc. All Rights Reserved. (Last updated: 2009-01-06)