Most Websites are customized for a specific locale, with the locale defined as a geographical region or political entity that shares a common language, culture, and customs. While this may not be a significant issue to most people, it may pose some interesting challenges to those conducting business on the Web. By its very nature, ecommerce is all about facilitating commerce across national, linguistic, and cultural boundaries. While the Web may have opened up businesses to a truly international clientele, Web-based firms have to contend with the all-too-probable scenario of non-English-speaking users struggling to understand their sites' content. As many businesses have come to realize, every Web surfer who turns away because of the site's English-centric nature is a potential customer lost.
So, is there an easy, manageable solution to this problem that keeps you from having to run multiple versions of the site? Well, if the dynamic content for the Website is generated through Java technology, there sure is! That's because the Java platform intrinsically supports the development of locale-independent applications through various classes supporting internationalization found within the
java.text packages. Internationalization itself is the name given to the design process wherein an application's country, language, and culture-specific information is isolated and typically encapsulated within some external files or objects. Consequently, making your application compatible with an entirely new language or country does not have to involve a major rewrite of your presentation logic; rather, it now merely involves creating an additional version, specific to the new locale, of the external files. The process of creating these locale-specific entities (be they files or objects), along with the associated translation of text, is called localization.
Websites based on JavaServer Pages (JSPs) lend themselves more easily to internationalization than those developed using servlets. This is because the technology facilitates the separation of presentation from application logic. Now, let us examine this premise in detail by developing a global version of the Music Without Borders online store that was demonstrated in my earlier article on JSP architecture (see the Resources section below for a link to this story). The online store is based on the Model-View-Controller (MVC) architecture to maximize the separation of presentation from content.
Although internationalizing a JSP-based Web application is not particularly difficult, it is a task best initiated at the design stage. Toward this end, all locale-specific textual data that constitute an application's user interface, such as page headers and trailers, user messages, form button labels, dates, currencies, and so forth, are first identified and isolated from the application within external files. These entities, which hold different values under different locales, are also known as resources; a grouping of resources within an external class or property file is known as a resource bundle or, simply, a bundle.
The Java 2 SDK provides the abstract base class
java.util.ResourceBundle for handling resources, along with its subclasses
PropertyResourceBundle. The bundle for a supported locale can be defined as either a classfile (by using
ListResourceBundle) or as a property file (by using
PropertyResourceBundle). Both these mechanisms then allow your application to access the values for resources by name, just as you would with a
Hashtable object. Although you can store objects of any type as values for resources using classfiles, most Web applications use property files, since they almost always customize only string types. Consequently, I will focus my discussion on the use of property files.