Internationalization and localization —
Concepts and terms
|
|
With careful attention to design, a single PRPC application can support users who:
All this can occur while these users share the common set of underlying rules, logic, and business benefits the application provides.
These capabilities increase the value of your application by allowing enterprise-wide or worldwide use without extensive training, reconfiguration, or replication. Business logic changes (to decision rules, flows, and so on) affect users identically and simultaneously, regardless of their language or location.
A locale is one of the standard codes in the format aa_BB_CC, where aa represents the language and _BB or _BB_CC represents a country variant suffix. For example, it_IT is the locale for Italian as spoken in Italy, de_DE is German as spoken in Germany, and de_CH is Swiss German. (In Microsoft Windows, the locale codes use a dash rather than an underscore character and sometimes omit the second and third portion for the dominant country, such as fr for the French language as spoken in France.)
Every Windows workstation has a locale setting, recorded in the Regional Settings control panel. PRPC detects this setting and uses it automatically to determine the formats for dates, times, and numbers both on display and input. Thus, a United Kingdom user can enter and view dates in the format 14/12/2004 while the United States coworkers enter and view dates in the format 12/14/2004.
Similarly, the UK user sees 15:15 as the time when the United States worker sees 03:15 P.M. as the time. The internal representation of dates and times supports both users. This capability requires no PRPC configuration, and, for most Windows workstations, no additional font installations.
See also locale and About the Locale Settings tool.
Depending on the control rule used to present a property, property values for dates, numbers, and times can be presented either with or without localization. Most standard properties use localization.
Workstation fonts are managed by Windows software. If an Internet Explorer display references a font not installed, it may not render correctly. To remedy this, install an appropriate font. Select Tools > Internet Options and click Fonts to see which fonts are missing.
Consult PDN article How to enable workstation support of international fonts and languages for additional information about workstation fonts.
A language-specific ruleset name consists of an application ruleset name followed by a single underscore and a locale code. For example, for the application defined in the ALPHA ruleset, the value ALPHA_it_it identifies an Italian-specific ruleset.
Developers can create and add rules to such rulesets. Typically however, such rulesets contain field value rules that localize words or phrases from portal rules, harnesses, and sections. The decision rules, flows, activities, properties, and other rules that determine the functions and results of the application are not needed in language-specific rulesets.
Application facilities visible to application users are determined primarily by:
In addition, application users see and interpret the Short Description fields on certain class rules and flows.
Through a careful design and implementation effort, your application can be presented in a second language or in any one of multiple languages using language-specific rulesets that each contains only a collection of field value rules. Users can work in the language of their preference or the language of a customer or party with whom they are communicating by phone or email. The fundamentals of your application — flows, activities, properties, and so on — operate as before with no translation required, simultaneously supporting users who work in different languages.
The correspondence your application sends is derived from correspondence rules (Rule-Obj-Corr rule type) and correspondence fragments. By creating language-specific correspondence rules and fragments, your application can respect the language preference of a party. For example, if a party prefers French and a French-language correspondence rule is available, an English-speaking user can send an email message or letter in French (provided no editing is needed).
Your PRPC installation and PegaRULES database can be installed with UTF-16 Unicode character set support. Note that this is an installation option; you can't enable UTF-16 after installation on a system that was installed with the UTF-8 character set.
PRPC supports the Microsoft Windows Input Method Editor (IME) to enter complex characters in four different East Asian languages - simplified and traditional Chinese, Japanese, and Korean - using the standard keyboard.
The IME displays three windows to guide the user through character entry: a reading window, a composition window, and a candidate window. The details of configuration and implementation are described in Installing and Using Input Method Editors.
PRPC includes two wizards that simplify the process of identifying, translating, and creating the field value, correspondence, paragraph, and other rules that support localization:
The standard control rule CurrencyAmount presents a monetary amount in the format of a user's default currency, such as 1,234.56/USD.
The standard library Math includes two functions for currency conversion:
Number property representing one currency value to another Number property representing another currency value using division.Number property representing one currency value to another Number property representing another currency value using multiplication.No standard rules reference these two functions. Typically, the currency conversion rates themselves are provided by an external system that is accessed through a connector. Your application retains control over the source of the rate, the computation details, and when and how conversion occurs.
|
currency code, locale, language-specific ruleset |
|
About the Locale Settings tool
About the Localization wizard |