8.1 Internationalization and Localization

I l @ ve RuBoard

For the most part, software that has not been internationalized will not work outside the country for which it was originally developed. Why, you ask? To understand why, you need to be aware of only a small subset of issues that face developers who design and write internationalized software:

• Text displayed to a user must be translated to different languages. It must therefore not be hardcoded into the program but externalized and loaded at runtime.

• Many languages use non-Latin writing systems (e.g., Arabic, Chinese, Hebrew, Korean, Russian, Thai, etc.).

• Some writing systems are bidirectional (text flows both left to right and right to left).

• Colors have semantic meaning depending on the region of the world you are in (e.g., red in the Western Hemisphere usually denotes a warning, danger, or stop, while in China red denotes happiness).

• Different languages have different rules for how characters should be sorted. This includes languages that share the same writing system, such as Danish, English, French, and German.

• Numbers can have different shapes depending on the writing system and region of the world you are in.

• Dates are formatted differently in different parts of the world (e.g., 06/10/02 could be June 10 ^th 2002, October 6 ^th 2002, or even October 2 ^nd , 2006!).

This list only scratches the surface of the kinds of issues that must be taken into account when internationalizing software. Take a moment to think about the number of times you have written some code to sort a list of words. If you are like most people, you hardcoded the sort order to that of the English alphabet! ^[1] You now know from reading this list that your program wouldn't operate correctly in France.

^[1] To be more accurate, you probably hardcoded it to the sort order of the ASCII character set.

Internationalization , often referred to as i18n in the software development community, is the process by which software is designed and implemented so it can be easily adapted to specific languages, cultures, and local conventions. The process of adapting the software to a specific region is known as localization .

While the task of internationalizing software is the responsibility of software architects and developers, a completely separate team working in conjunction with the software development team usually handles the task of localization. A localization project manager who typically oversees a group of translators, technical writers, testers, and, in some cases, programmers leads the localization team. Depending on the core competencies of the company producing the software, the localization team can be either in-house or outsourced. ^[2]

^[2] A large number of localization houses exist that will gladly help you with your localization needs. For more information on localization, check out LISA (the Localisation Industry Standards Association) at http://www.lisa.org.

In this chapter, we will share with you some best practices for applying software internationalization techniques to the development of Java Enterprise applications. Although the format of this book is to address best practices, we couldn't possibly cover all aspects of Java internationalization here. For a more in-depth discussion on the topic, see our book, Java Internationalization (O'Reilly).

8.1.1 The Model-View-Controller Paradigm

Enterprise applications are typically split into three different tiers, or layers . They are more commonly referred to as the presentation layer (the application's "view"), the business object layer (the application's "controller"), and the data access layer (the application's "model"). Does any of this seem vaguely familiar to you? In a roundabout way, we have described the Model-View-Controller (MVC) paradigm that you have no doubt seen in Java Swing or JavaServer Pages .

In this chapter, we will present some of the more common issues you are likely to run into, with respect to internationalization and localization, for the various tiers in the MVC paradigm when developing an enterprise application, along with best practices to handle these issues. Our discussion will move from the presentation layer to the business object layer and finally to the data access layer.

I l @ ve RuBoard