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:
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.