12.1 What Is Internationalization?

Traditionally, software developers have focused on building applications that solve an immediate business problem. While doing so, it's easy and sometimes necessary to make assumptions about the user's language or country of residence. In many cases, these assumptions are valid and there's never a question of who the audience will be. However, if you have ever had to re-engineer an application because these assumptions weren't correct, you know how hard it can be to go back and correct the application design after the fact.

Internationalization (I18N), simply stated, is the process of designing your software ahead of time to support multiple languages and regions, so that you don't have to go back and re-engineer your applications every time a new language or country needs to be supported. An application that is said to support internationalization has the following characteristics:

· Additional languages can be supported without requiring code changes.

· Text elements, messages, and images are stored externally to the source code.

· Culturally dependent data such as dates and times, decimal values, and currencies are formatted correctly for the user's language and geographic location.

· Nonstandard character sets are supported.

· The application can quickly be adapted to new languages and/or regions.

When you internationalize an application, you can't afford to pick and choose which options you want to support. You must implement all of them or the process breaks down. If a user visits your web site and all of the text, images, and buttons are in the correct language but the numbers and currency are not formatted correctly, it will make for an unpleasant user experience.

Ensuring that the application can support multiple languages and regions is only the first step. You still must create localized versions of the application for each specific language and/or region that you want to support. Fortunately, here's where the benefits of I18N on the Java platform pay off. For applications that have been properly internationalized, all of the work to support a new language or country is external to the source code.

A locale is a region (usually geographic, but not necessarily so) that shares customs, culture, and language. Applications that are written for a single locale are commonly referred to as myopic. Localization (L10N) is the process of adapting your application, which has been properly internationalized, to a specific locale. For applications where I18N support hadn't been planned or built in, this usually means changes to text, images, and messages that are embedded within the source code. After the changes are applied, the source code may need to be recompiled. Imagine doing this time and time again for each new locale you have to support!

According to Richard Gillam from the Unicode Technology Group, which designed much of the I18N support in the Java libraries, "Internationalization is not a feature." Users will expect that the products they use will work for them in their native languages. Things can go wrong, and users get unhappy when assumptions that you make are incorrect. Start planning early for I18N support in your applications. Even if it doesn't look like you're going to need it, if you do you'll be that much further ahead, and it won't hinder development as long as you do it right from the start.

Not every application needs I18N support, and some developers and development organizations frown on adding in functionality that isn't part of the requirements. However, even if your application has no requirements to support more than a single locale, there are still benefits that you can gain from including some aspects of I18N. For example, by using resource bundles for all of your static text, you can save development and, more importantly, maintenance time. We'll see how this is true later in the chapter.