---

Internationalization and Localization

Internationalization is the process of designing and building an application to facilitate localization. Localization, in turn, is the cultural and linguistic adaptation of an internationalized application to two or more culturally-distinct markets. When users launch a well-localized application, they should feel fully at home with it and not feel like it originated from some other country.

Internationalization and localization are complementary activities. By internationalizing an application, you create the programmatic infrastructure needed to support localized content. By localizing that application, you then add resources that are customized for people of a different culture. Localizing an application often involves translating the user-visible text of the application, but that is only part of the work that must be done. Other parts of your application must also be modified, including the following:

• Nib files (windows, views, menus) must be modified to accept translated text.

• Static text must be translated.

• Icons and graphics (especially those containing culture-specific images) must be changed to be more culturally appropriate.

• Sound files that contain spoken language must be rerecorded for each supported language.

• Online help must be translated.

• Dynamic text generated by your program (including dates, times, and numerical values) must be formatted using the current locale information.

• Text handling code must calculate word breaks using the current locale information.

• Tabular data must be sortable using the current locale information.

The process for internationalizing a Mac OS X application is easy and the same on both platforms. Inside your application’s bundle directory, there is one file containing your application's executable code and potentially many separate files containing the localized resources. The resource files for a single localization are stored together in a language-specific project directory of the bundle. The bundle may contain any number of language-specific project directories, each one representing a distinct localization that the application supports. You can even store localizations for single-byte and double-byte languages together in the same bundle.

The first step in the development of an internationalized application is to identify all culture-specific information in your application. Scour your user interface for culture-specific text, images, and sounds and put them into resource files. As you do that, update the underlying code so that it loads the data it needs from those resource files. As you go through your code, you should also look for places where your user interface displays date, time and currency values and make sure you are formatting them using the current locale information.

Once your application’s user interface is frozen (which may be before the code freeze), you can begin to localize it. For each localization, the localization team creates language-specific versions of the nib files, text, images, and sound files. If your application is properly internationalized, the process doesn’t require modifications to your source code. You can therefore create the translations in-house or contract with an outside localization service.

Even if you do not plan to support multiple languages immediately, internationalizing your application up front is a good idea. There is also no penalty for building internationalization support into your application. Even if your application is monolingual, you still need to test all available code paths. If your code is properly internationalized for one language, it should require little additional testing to support other languages. In addition, storing resources outside of your executable file makes it easier to change the appearance of your application later without modifying the underlying code.

---