Last Updated 24-Mar-2004

General Description

Internationalization is the process of adapting Oracle applications for use abroad. Internationalization requirements vary from one country to another, depending on language, formatting conventions, and cultural values.

If an application is not compliant with Internationalization requirements, it will be much more expensive to translate it into some languages, and prohibitively expensive or impossible to translate into others. The net result is that the application may have an extremely limited market outside the USA, and thus hinder the overall marketing effort for Oracle Applications worldwide.

This document includes the following sections:

Note: The long term "Internationalization" is commonly abbreviated to "I18N" (the initial "I" plus the middle 18 letters and the final "N"). I18N groups were formally known as NLS (National Language Support).

Guideline Attributes

Spec Version # - 3.1
Spec Contributors - Betsy Nute, Mervyn Dennehy
UI Models - all models
Example Products - all products
Related Guidelines - all

General Recommendations

Applications that are BLAF-compliant will also be in large part compliant with Internationalization requirements. These requirements can be grouped as follows: Oracle provides Internationalization support at multiple levels: The following sections provide additional recommendations for UI designers and developers, as well as links to BLAF guidelines specific to each section.

For a general public domain reference on internationalization, see:

National Languages

Applications developed in US English must typically be translated before being marketed in other countries. Even if translation is not required by another country, some changes must still be performed to localize the application for the target country.

General Translation and Localization Issues

Readiness of Text for Translation

The difficulty and cost of translation depends largely on the readiness of the source material, and the degree of deviation from Oracle standards:

Character Set Support

Applications must be able to display different character sets to support languages such as:

For the most part, support for character sets is provided automatically by the UIX and OA Core tech stacks. However, some applications may still need to process character set information directly (for example, applications that support client PC upload and download).

BiDi Language Support

Applications must support bi-directional (BiDi) languages, such as Arabic and Hebrew, which read text right to left, but read numbers left to right (within the same body of information). This support is provided through style sheet settings, so it is essential not to hard code any element that must be translated into a BiDi language.

BiDi languages require that all horizontal directional UI images, such as arrows, be flipped to match the reading direction. Most BLAF icons and symbols are automatically flipped by UIX based on locale settings. In certain cases, an alternate image is created by BLAF designers for BiDi use. See the BLAF Icons guideline for details.

Layout and Style Issues

Page layout may also change in translated applications:
Untranslatable Sentence Formed from Fields and Labels

Untranslatable Instruction Text with Embedded Images

Contrast of Generic US and Japanese Address Forms
US and Japanese address forms have different fields

Cultural Values

Some colors, symbols, and images may be interpreted differently in different cultures.

Problems with Colors

BLAF limits extensive color usage to avoid culturally-sensitive colors. In general, blue is the most acceptable color across all cultures: Note: Avoid using large green flags as banner images, as a green flag commonly signifies Islamic organizations in some countries, such as Indonesia and Malaysia. Use of red/green/yellow flags as status indicators is not problematic because the primary association is with traffic lights, which are understood internationally.

Problems with Images

When creating images and icons for use in applications there are three key rules to enable internationalization: The following types of images should be avoided or used with caution in applications that target multicultural users:

Formatting Conventions

Many format conventions vary from one country to another. Some of these, such as date, time, currency, and numeric formats, are controlled by user preference and locale settings. Locale settings modify the display of data to match language, and national and regional requirements.

For example, many European locale settings substitute commas and periods in numeric formats. User preferences include choices between a minus sign and angle brackets to display negative numbers, choices between 24-hour and 12-hour time formats, and comma or period for numeric formats. See Global Button Flow: Preferences for more details.

In addition, name and address fields vary from one country to another, requiring different fields or a change in field order. For a detailed discussion of name and address field options, as well as date, time, currency, and numeric formats see the Common Formats guideline.


Internal Oracle Internationalization Resources

External Internationalization Resources

Open/Closed Issues