Globalized store design
A store typically contains several types of pages. A globalized store is a store in which all pages are enabled for globalization. In WebSphere Commerce, globalization enablement of store pages is accomplished through the use of language-independent and culturally sensitive templates.
In WebSphere Commerce, the management and storage of templates in a globalized environment is referred to as template management. For more information, refer to programming models for globalized stores.
Globalized page framework
While there are various options from which to choose when creating a globalized store, the one that offers the most globalized approach is that of a single, culturally neutral template that calls or includes culturally sensitive content at runtime.
This model makes maintenance simple since changes to the design of a page only need to be made once. Adding or removing languages or cultures is simple because the culturally sensitive content is kept separate from other features of the page. For more information about this template, refer to programming models for globalized stores.
Resource bundles
Resource bundles allow you to maintain collections of Java objects that are locale-specific for your JavaServer Pages. When the page needs a locale specific resource, such as a form field label, a graphical user interface message, or a value for a drop-down menu, the page can load it from the resource bundle or property file that is appropriate for the selected locale, allowing the customer to view the page in their own language.
In WebSphere Commerce, using PropertiesResourceBundles to separate translatable text as the format of the ListResourceBundles (properties file) is easier to translate and maintain than the Java files associated with ListResourceBundles. Unless the performance of your application is severely degraded or there is a need to use non-string type, the use of PropertiesResourceBundles is recommended.
The search order used to retrieve properties files in Java (ResourceBundle.getBundle) is:
- basename_language_region_variant
- basename_language_region
- basename_language
For example, the Japanese property file should be named either AddressText_ja.properties or AddressText_ja_JP.properties.
Native2ascii tool
The native2ascii tool converts files that contain other character encodings into files containing Latin-1 and Unicode-encoded characters. ISO-8859_1 characters are represented as they are, while characters other than ISO8859_1 are represented in the Unicode escape sequence, which is preceded by \u. For example, the phrase DDHello, where DD represents one DBCS character, is converted to \u3053Hello.
The properties files of languages other than Latin-1 languages (ISO-8859_1) must be converted to the Unicode-encoded characters format using the native2ascii tool.
Note: The native2ascii tool is included in both the SUN Java2 SDK and IBM JDK. The JRE, which is the runtime environment only, does not include native2ascii.
Support for bi-directional languages
Languages such as Arabic, Hebrew, Farsi, Urdu, and Yiddish have their text written from right to left. Numeric and embedded segments of Western language text are written from left to right. Because of this possible mixture of text segments in two directions, those languages are called bi-directional or bidi for short.
The HTML specifications provides bidi support through the use of a number of language information and text direction attributes or elements. The main such attribute is the dir attribute. The dir attribute is used to define direction:
- Portions of document's text
- Entire document (at the <HTML> declaration level)
- Table structure
The possible values of the dir attribute are either RTL (read as right-to-left) for bidi languages or LTR (read as left-to-right - the default value) for non-bidi languages. The following figure shows how the RTL attribute for bidi languages displays:
