This chapter gives an overview of internationalization and localization issues for Oracle Communications Billing and Revenue Management (BRM) developers.
For information about using BRM internationally, see "Using BRM in International Markets".
Localization and internationalization are related but not identical:
Localization (L10N) is adapting a software product for a specific market (locale). This requires the following procedures:
Translating the product interface and help files into the locale language
Supporting the date, time, number, currency formats, and collation order of the locale
Supporting the input methods of the language
Possibly changing the content of the application, depending on the product and market
Internationalization (I18N) is a process of developing software products that are independent from cultural, language, or other specific attributes of a market and can be easily localized.
This includes designing user interfaces to handle languages that need more space, placing text strings in a resource file instead of hard-coding them, and using icons that have meaning across cultures.
BRM client applications are internationalized to work with languages using text that is both non-complex and single-direction (left-to-right), including most languages of Western European and East Asian origin.
For European languages, the client applications support any Windows Regional setting locale that uses code page 1252. These are languages of Western European origin or languages that use a very similar alphabet including Afrikaans, Basque, Catalan, Dutch (standard), and Dutch (Belgian).
For East Asian multibyte locales, the client applications support Japanese (code page 932) Korean (949), Simplified Chinese (936), and Traditional Chinese (950).
For more information on languages BRM does and does not support, see "Localizations Supported".
For information about localizing client applications, see "Creating a Localized Version of BRM". For information about using localized client applications, see "Using Localized Client Applications".
To use the Windows Regional Settings for a locale, you must follow the Microsoft Developer Network standards. Some of the most important APIs are those for:
String manipulation
Locale-related APIs such as GetLocaleInfo and enum, as well as LC_* types for currency, date, and so on
Code pages
For international development, text strings must be isolated from other parts of the software. For information about:
Using the proper conventions for storing text strings, see "String Manipulation Functions" in BRM Developer's Reference.
Storing non-ASCII text, see "Handling Non-ASCII Code on the BRM Server".
Loading your strings into the database, see "load_localized_strings".
Canonicalization is a process of presenting text in a standard way, called canonical form. For example, two strings such as "àbc" and "abc" are equivalent, but the second one is in canonical form because it is written in the most common way. Strings in canonical form are easier to compare for searches and sorts.
Canonicalization is based on the account's locale. To add canonicalization for a non-Latin 1 locale, you must customize the PCM_OP_CUST_CANONICALIZE opcode. If you use a multibyte code set or Unicode, you need to convert it to UTF8. For more information, see "Handling Non-ASCII Code on the BRM Server".
BRM supports canonicalization for some of the Latin 1 languages and locales in ISO 8859. For a list of supported languages, see "Locale Names".
In these languages Event Browser ignores capital letters, accents, and diacritical marks when searching by name or company name.
With localized versions of BRM, the sort order returned from searches is byte order.