Advanced Customization > Services and Infrastructure Customization > Internationalization and Localization > The Windchill Approach
  
The Windchill Approach
Rather than try to keep all these preceding factors in mind and accommodate them individually as you develop an application, the best approach is to isolate any language- or locale-dependent code from the language-independent code (that is, the application’s executable code). Windchill is designed to allow you to do this.
Windchill takes advantage of many Java features that support international applications:
Locale class
Each locale-sensitive object maintains its own locale-specific information. The initial default for locale is specified in the system but users can specify a preference in the Web browser.
Resource bundles
In a resource bundle, you define pairs of keys and values, where the values are strings and other language-dependent objects for a specific locale. Within code, you use the key to indicate where the corresponding string or object should be inserted. For example, Windchill uses resource bundles in its online help and to identify button names, field names, and other elements of graphic user interfaces. The default or preferred locale specifies which resource bundle to use and, therefore, determines which strings and objects to display. (An example is shown later in this chapter.)
Windchill uses a structured properties file format to manage much of the localizable text. Unlike the java.util.PropertyResourceBundle properties files, these resource info files are not used at runtime. They are more like java.util.ListResourceBundle java files, where they are used to manage the information, and runtime resource bundles are built from them. These resource info files have a .rbInfo file extension. This format is required for managing the localizable information for EnumeratedTypes and display names for metadata, since these localizable resources are updated by generation tools. The resource info format can be used for storing other localizable text, but it is not mandatory.
Unicode
This is a 16-bit international character-encoding standard. A character encoding is a numeric representation of alphanumeric and special text characters. A multi-byte encoding is necessary to represent characters such as those used in Asian countries. The intent of Unicode is to be able to represent all written languages in the world today.
Localized text manipulation
The Java classes java.io.inputStreamReader and java.io.OutputStreamWriter provide the mechanism to convert standard character encodings to Unicode and back, thus enabling the translation of characters to and from platform and locale-dependent encoding.
Handling local customs
The java.text package provides classes that convert dates and numbers to a format that conforms to the local conventions. This package also handles sorting of strings.
java.text.NumberFormat. formats numbers, monetary amounts, and percentages.
java.text.DateFormat contains the names of the months in the language of the locale and formats the data according to the local convention. This class is used with the TimeZone and Calendar classes of the java.util package. TimeZone tells DateFormat the time zone in which the date should be interpreted and Calendar separates the date into days, weeks, months, and years. All Windchill dates are stored by the server in the database based on a conversion to Greenwich Mean Time.
To display Timestamps in the correct Timezone, the application programmer should use wt.util.WTContext to set the Timezone in the DateFormat as follows:
DateFormat df = DateFormat.getDateTimeInstance(
DateFormat.SHORT,
DateFormat.SHORT,WTContext.getContext().getLocale()
);
df.setTimeZone(WTContext.getContext().getTimeZone());
System.out.println("The current time is: " +
df.format(new Timestamp(current_time_millis)));
java.text.Collator can compare, sort, and search strings in a locale-dependent way.
CLDR as Default Locale Data Provider
Unicode Consortium's Common Locale Data Repository (CLDR) is the default locale data provider in Windchill on Java 11.
After upgrading to this version of Windchill and applying customizations, there may be a change in behavior of locale-sensitive services or translations, or both, in your customized setup. To verify that the change in behavior is because of CLDR or not, change the order of locale provider in the -Djava.locale.providers=CLDR,COMPAT,SPI property. The resolution for change in behavior, however, will depend on the type of custom configurations set in Windchill.