User's Manual

Chapter 13.
Web Applications Tutorial
13.1. Support for Globalization
This section discusses the internationalization (I18n) features of Java and WAF, and how to use this
to localize web applications.
See Chapter 14 References for more references discussing the concepts of globalization.
WAF supports globalization in a variety of ways:
1. It allows the user to select a preferred Locale, either by registering a preference with WAF, or
by sending the appropriate Accept-Language HTTP header with each request.
2. It allows the user to send and receive data in the user’s preferred character set encoding.
3. It provides mechanisms for storing multiple localized versions of resources for an application.
This is true for both static and dynamic resources.
4. It offers APIs for creating and accessing these localized resources.
5. It provides a globalized WUI (Web User Interface) toolkit — for more information, see Section
5.4 Bebop - Reusable Web UI Components.
6. It allows stylesheets (used for styling of content) to be associated with more than one Locale,
thereby allowing you to create different layouts based on Locale. These will be applied auto-
matically by the system as determined by the user’s preferred Locale.
13.2. Locale Negotiation
When a user requests a URL, the server determines the appropriate Locale for the request. It does
this by negotiating between the client’s preferences and the server’s capabilities.
All valid URLs on the server are associated with an instance of some application.
1. If that application instance has an associated Locale, this will be used as the Locale for the
request. If the application instance does not have an associated Locale, the server checks whether
the user has a preferred Locale as kept by the WAF preferences service.
2. If there is a preferred Locale, and if that Locale is supported by the application, that is the
chosen Locale for the request.
3. If there is not a preferred Locale the server continues on to check the Accept-Language HTTP
headers. Checking each of the values in this HTTP header in order of descending q-value, the
server selects the first one that is supported by the application being served.
4. If no Locale can be determined, the server finally selects the default Locale for the server as the
Locale for the request. This algorithm is well documented in the LocaleNegotiator class.
This negotiation allows applications to support one or many languages without interacting with other
applications on the system. Thus, your application automatically tries to present itself to the user in
his or her preferred language, regardless of the other applications running on that server.