Create an international JSP application

Sing li author, Wrox Press, April 14, 2005

Designing Java Server Pages (JSP) applications for international customers is more art, not as science, but what you involve can not only meet eyeballs. The key to success is to understand the unique server-side issues related to internationalization. Java Developers Sing Li will elaborate this important issue and give two solutions that have been active and effective.

The world economy is increasingly global promoting people's demand for web-based software, as users in many countries can access Web software. The language, display, data entry, representation, and cultural needs of these users may differ. Internationalization (abbreviations I18N) is an art of an application that is created as a scattered user group.

Perhaps a little surprised, J2SE's international built-in support will exhibit some shortcomings when doing any custom modifications are used in server-side. In general, the internationalization of the server is still an art, not a science, often involving some dedicated or user-developed solutions.

This article uses the internationalization needs of the server-based JSP application to the international demand of the J2SE application. This article will introduce a variety of client / server technologies that lead to different server-side requirements. The actual code will then be viewed, which shows two solutions used to solve basic problems.

Beyond the J2SE J2SE concept (see NOTATION for A Locale) for internationalization. On a machine, the region represents the user-selected display language (eg, English or Spanish), and the formatting agreement in the date, time, currency and other aspects. Typically, the regional option settings are managed by the underlying operating system and passed it to J2SE when running.

If the running server is on the local machine, or on the LAN, then the concept of a machine-specific area is very easy. All clients and servers included are in the same area, so they use the same display language, date agreed. These scenarios will not bring trouble. But if you want to provide services to users in multiple international locations with the same server, then the situation is very complicated.

Server-side internationalization issues When deploying a server application in order to conduct international access, the application must support different areas. Figure 1 shows a possible scenario. Each machine-server and client access to the server at any time may have its own regional settings, and these areas are different.

The concept area of ​​the region is specified in the form of a national code followed by the language code. (See Resources to get more information about these codes.) The standard format is XX_YY, where the language code representing two lowercase letters, YY is the country code represented by two uppercase letters. It is also possible to see the use of a function between language and country code, or write country code into a small-writen form. It is necessary to divide the language from the state because there may be more than one country to use the same language, but the date, time, currency format, etc. may have different expressions.

Figure 1. Servers providing services for users in different regions

In Figure 1, the server machine is located in San Francisco, and the machine-specific area is en_us (US English). Users from New York and Dallas use EN_US regions, so there is no additional international demand. However, users from Seoul expect to see apps that use Korean expressed apps, their area is KO_KR. At the same time, users from Shanghai want to see the application text expressed in Chinese, and their area is zh_cn. User from Tokyo expects to display applications in Japanese, their area is JA_JP. All of these users must be met by running JSP applications on the San Francisco server. At the server side, you have all control over your own area, but you can't change the area of ​​the client or forcibly convert it into a particular area. Instead, the application must identify the user's area and ensure that the JSP page appears in the correct localization form (see detecting client locale).

Detecting the client area by checking the HTTP header passed from the user browser, you can automatically detect the user's area. However, the user or operating system may not set this information correctly. Coupled with this fact, that is, some browser processing areas exists, there is a bug, you are not difficult to understand, why make the app explicitly ask the user preferred area is a method of determining regional values.

More regional judgment complexity is that you can safely determine the client area safely and present the JSP accordingly, the new problem has appeared. Consider these very realistic scenes.

A visit personnel from Tokyo are using machines located in Shanghai, China, and the area of ​​the machine is zh_cn. Because not familiar with written Chinese, she wants to access the web application in Japanese. For this case, see Figure 2 (a).

Figure 2. Different parts of the user expectations from the client machine

In Figure 2 (a), the area of ​​the San Francisco server is en_us. The client machine is in Shanghai, and the region is zh_cn. But JSP applications need to be displayed in JA_JP, which is useful to users.

Look at another scene of weird but not impossible. Developers with international JSP applications are debugging. On a region of en_us, three browser instances running a JSP application are opened on a client system for EN_US. The server machine is also en_us on the local area network. However, it is now necessary to test the application of the application for Chinese and Japanese users. So on an EN_US client machine, a browser instance is in English (En_us), one is Japanese (JA_JP), and one is Chinese (zh_cn). Figure 2 (b) demonstrates this situation.

So far, basic internationalization should be very clear: When dealing with any special instances required to display an international application, there are some power from the server area and server. Only users can say which area to display the page.

But Xie Tian, ​​usually, certainly assume that the user does not change the display language during the use of the application. So you usually associate the regions with the session.

Solve the problem-specific language display problem For JSP applications, there are at least two general acceptance methods for displaying different languages ​​to display:

Store multiple sets of JSPs, each set of JSPs are encoded in different languages, and then switch between these JSPs according to the user's region. Separate all strings used, in which a region-specific string is obtained from resource binding. (This approach uses J2SE-specific resource binding processing mode.) This article provides two versions of the sample code, respectively, corresponding to both methods. The sample application is a login screen called developerWorks Email's fictional email service. First, use the language to select the screen prompt the user of the email system to determine the current session area required. The choices that can be made include English, Korean, Japanese and Chinese, as shown in Figure 3. If you want to try the code, use http: // /dwi18n/multdir/index.jsp This URL accesses this page.

Initial language to use pictures The usually no reliable method can pre-know what kind of font supports the introduced client. In order to save storage and memory, most modern operating systems do not pre-install support for all fonts of all Unicode characters in advance. Some browsers will try to download and install these fonts when the first visit to the web page containing the necessary font. Use pictures to display foreign characters or flags in a viable way to represent language selection screens.

Figure 3. Language selection screen for explicitly selection

In Figure 3, the language selection screen represents 4 regions in four images (see Using images for Initial Language Selection). The login screen uses the user to display the language selected here. Figure 4 shows the Japanese login screen.

Figure 4. Japanese login screen

The first version of the multi-setup-specific JSP set example is located in the WebAPPS / DWI18N / MULTDIR / directory of the sample code release package, which uses multiple sets of JSP pages. Figure 5 shows the directory structure of this application.

Figure 5. Directory structure of DWI18N / MULTDIR shows a region-specific directory

In Figure 5, there are corresponding subdirects in each region. The JSP encoded in English is in the EN sub-directory. The JSP encoded with the KO_KR region is in the KO subdirectory. For JA_JP regions, Japanese encoded JSP is in the JA subdirectory. The ZH_CN area is expressed in the ZH subdirectory. Each subdirectory contains both the JSP (Login.jsp) of the login screen, also contains data confirmation JSP (Confirm.jsp).

Data confirmation JSP is only displayed in this simple example. For example, if information is entered in the Chinese login screen, then click the button, the data confirms that the JSP will display the input data, as shown in Figure 6.

Figure 6. Chinese confirmation page

Writing a JSP code area Select JSP called index.jsp, which directly links to a language-specific JSP. This version of INDEX.JSP code is in Listing 1:

Listing 1. Region Selection JSP Direct Link to language-specific pages

<% @ taglib prefix = "c" URI = "http://java.sun.com/jsp/jstl/core"%>