Software globalization in JViews

Software globalization includes:
  • The internatiionalization mechanism
  • The process of localization of an application
Applications based on JViews use the normal globalization mechanism provided by the Java 2 Platform for both these items. This mechanism includes Locale, ResourceBundle, and other Java classes. If you are new to globalization, this link to Java globalization is a good starting point.
JViews uses ICU for advanced globalization services and includes support for base text direction for languages with right-to-left writing direction.

Use of ICU

JViews uses the ICU library; see International components for Unicode. The product ships with ICU4J version 55.1. The JAR file is in jviews-framework89/lib/external/icu4j-55_1.jar. Newer versions of ICU4J might also work.

Locale and Ulocale classes

The JRE class java.util.Locale and the ICU class ULocale specify the locale of a user, that is, the preferences of a user that are related to globalization.
The class ULocale can be considered an extended and extensible counterpart of Locale:
  • Locale contains only language, country, and a variant specification in undetermined syntax; ULocale also contains the script, calendar, collation, currency, and other possible detail specifications.
  • A Locale object can be converted to a ULocale object by the method ULocale.forLocale.
  • A ULocale object can be converted to a Locale object, and thus loses attributes such as script, calendar, collation, and so on, by the method ULocale.forLocale.
For more information about ULocale, see the user documentation and the reference documentation.
The class Locale provides sufficient support for the lookup of string translations or the formatting of numbers. For services that include calendar computations, date formatting, or sorting, pass a ULocale object to JViews. A Locale object does not contain the user’s preferences about these topics.

ULocale in Swing and Eclipse RCP applications

In standalone applications ULocale can be specified through a set of system properties:
  • The user.language property: the value should be an ISO 639 language code.
  • The user.country property: the value should be an ISO 3166 country code.
  • The user.variant property: the syntax of its value is unspecified.
  • The user.script property: the value should be a four-letter ISO 15924 script code.
  • The user.calendar property: the value is described in the ICU user’s guide.
  • The user.collation property: the value is described in the ICU user’s guide.
  • The user.currency property: the value is described in the ICU user’s guide.
  • The user.numbers property: the value should be a four-letter ISO 15924 script code or one of the system identifiers listed in Unicode UTS #35.

ULocale in web applications

In web applications the locale is inferred by default from the Accept-Language information that the browser sends. It does not contain information about script, calendar, collation, and so on.
If you want to use a different locale from the inferred locale, for example, a locale specified by corporate policies, the user’s explicit selection for the current section, from the previous session, or from the user’s registration profile, you must specify it by using IlvLocaleUtil.setThreadULocale(ULocale locale) for the duration of the current request. If the locale changes within a session, you might also have to call IlvLocaleUtil.setThreadULocale(ULocale locale) on the relevant web components.

ICU services: implicit use

The following classes produce objects that comply with the java.util or java.text interfaces, but use ICU services internally.

ICU services: explicit use

To use ICU services with ICU specific customizations together with JViews API based on the java.util and java.text interfaces, you might want to use the following bridge classes: