Companies can no longer afford to think only about local marketplaces. Since the mid to late 1990s, the business world has been overrun with ideas about a world economy—all you have to do is look at what’s happening in Europe with the Euro. Businesses and even countries are realizing that they can’t just think about their traditional markets and at the same time continue to grow revenue and be successful; they must start thinking globally and attempt to bring in global customers for their products and services.
With the explosion of the World Wide Web in the mid-1990s, companies conducting business on the Internet began to find out that providing access to their products and services via a web site was an ideal way of attracting new customers from all over the world. One of the key reasons is 24/7 access. Regardless of the time zone the business or the customers are in, the Web allows a customer to shop and purchase goods and services at any time of the day or night. Traditional business hours are irrelevant on the Web. What unlimited access can mean to companies and their revenue is enormous. However, for the software developers that have to build and maintain the applications to support global customers, the task can be daunting.
This chapter focuses on what it takes to make a Struts application available to customers from around the world, regardless of their language or geographical location. As is often the case in software development, planning ahead is the most important thing you can do to help ensure success. After reading this chapter, you should be able to build Struts applications that make it possible to support a broad range of customers.
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.
Tip
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.