Internationalization
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
Applications that are BLAF-compliant will also be in large part compliant with Internationalization requirements. These requirements can be grouped as follows:
- Support for national language and corresponding character set, such as Japanese and Arabic.
- Internationally acceptable use of images and colors. Some images, such as a hand with different fingers extended, may be interpreted differently depending on culture.
- Support for national format conventions for dates, time, decimals, currency, names, and addresses. Formats may include or omit certain fields, and require different separators.
Oracle provides Internationalization support at multiple levels:
- BLAF guidelines incorporate UI internationalization requirements
- The UIX (Cabo) tech stack both implements these BLAF features as well as incorporating other internationalization requirements that are not readily visible in the UI.
- The OA Core tech stack and its Trading Community Architecture (TCA) provides middle-tier support for internationalization.
- "Locale" customization settings configure the application to display the correct character set and format conventions for the specified country. Support for this setting is provided by UIX and OA Core.
- Application development teams use the UIX and OA tech stacks, and follow both BLAF guidelines for UI and Oracle style guidelines for Help text.
- Internationalization teams translate and localize applications for use in different countries.
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:
http://www.w3.org/International/
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.
- A single language may vary from one country to another. For example, English spelling and certain terms vary between the US and Great Britain, with many former British Commonwealth countries, such as Australia, following British standards.
- References in Help text to national organizations, telephone numbers, and addresses must be modified.
- A single country may have more than one language. For example, Canada has both English and French as national languages, with legal requirements for communications in both languages.
- Page layouts must allow translated text to expand by an average of 100 percent, and up to 150 percent for short words (less than 5 characters long) and narrow columns.
- Words in some languages, such as German and Finnish, are typically longer than their English equivalents. When placed in narrow columns, such as Content Containers, these longer terms cause additional line breaks, leading to major increases in vertical space, and added horizontal space, which causes extra scrolling.
- Some languages may not have equivalent terms to those used in the original English version, so those terms need to be translated as multiple words. For example, there is no single word for "privacy" in Indonesian.
- Some countries, such as Sweden, regard the active voice as impolite, and use longer passive voice constructions.
The difficulty and cost of translation depends largely on the readiness of the source material, and the degree of deviation from Oracle standards:
- Label text and instructions may be translated by different people even though they appear on the same page. As a result, any instructions that reference label text may be translated differently. To avoid such errors, do not reference label text in Instruction Text, Tips, and Hints unless absolutely necessary to explain a complex range of options to new users.
- To avoid problems in translation of UI labels:
- Do not use jargon, idioms, slang, or colloquialisms.
- Do not use abbreviations or acronyms unless they are approved by the internationalization team. See the Abbreviations guideline for details.
- Spell out contractions. For example, use "do not" instead of "don't."
- Do not use possessives. For example, use "file location" not "file's location."
- If you are referring to one or more, always use the plural. For example, use "pages to delete" instead of "page(s) to delete" or "page or pages to delete."
- Do not use Latinate abbreviations. For example, use "that is" not "i.e.", and use "example: 15-Dec-2004" not "e.g. 15-Dec-2004".
- For compound actions, use "or" instead of a slash, and "and" instead of an ampersand, unless constrained by space. Both translators and users may fail to understand the difference. For example, "View or Update" is preferred over "View/Update", and "Create and Add Another" is preferred over "Create & Add Another". Also, do not use the construction "and/or", because "and" and "or" are mutually exclusive.
- Use complete phrases in labels. For example, use "Replacement Text" instead of "Replace with."
- Do not rely on capitalization to indicate semantic differences; some languages do not have capital letters.
- Help text is also more readily translated if it conforms to Oracle style standards, which promote clarity and consistency. If translators have difficulty understanding content, they will have even more difficulty translating it. Oracle writers and developers can find detailed style guidelines at Oracle's internal DocTools Web site: http://doctools.us.oracle.com/standards/standards.html
Applications must be able to display different character sets to support languages such as:
- Japanese
- Chinese
- Arabic
- Russian (Cyrillic)
- Greek
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).
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.
Page layout may also change in translated applications:
- Font Families: Developers should not use hard-coded fonts, but use CSS style classes instead. The style sheet can then be customized by locale. Oracle Applications currently implements this customization using XSS, which has the locale-specific fonts for UIX and OA.
- Font Sizes: Certain font sizes are not available or legible in all languages. For
instance, Asian fonts must be rendered in larger point sizes. UIX automatically handles specific styles for different locales, so
applications should not hard code font sizes, but rather use the relative-size styles that are specified in the UIX style sheet.
- Alignment: (Left, Right, Centered, Justified) To ensure proper translation to all languages, including bi-directional languages (supported by UIX), applications must use 'Start' and 'End' alignments instead of 'Left' or 'Right' alignments respectively for textual content, and 'Right' alignment for strictly numeric content.
- Horizontal and Vertical Space: Avoid any precise layouts, for instance filling a screen with a dense amount of information that must line up correctly. Horizontal and vertical spacing can dramatically change when an application is translated to a different language, especially when that language is character based, and/or bi-directional.
- Embedded Images and Fields: Applications cannot embed images or fields for variables within sentences, or concatenate fields and labels in a sentence-like structure, such as "Add {AddressObject} From {Country}"
- Languages have different grammars which cause major rearrangements of translated sentences, thus making it impossible to predict where to place the images or fields in relation to the labels.
- Some languages, especially Romance languages such as French and Spanish, have both masculine and feminine forms of articles, adjectives, and pronouns, and these parts of speech must agree with the gender of related nouns. If a field displays a word, it is impossible to predict its gender when translating associated label text.
- Fields and Field Order: Depending on locale settings or country selection, some fields in forms and tables may be added, omitted, or change order:
- Name and address fields may change fields and field order to match national requirements.
- Some languages, such as Japanese, include additional phonetic fields (a.k.a. "Alternate" fields as aids to pronunciation).
- These changes should be implemented by individual development teams based on the localization needs of their
customers. For a discussion of name and address options and phonetic fields, see the Common Formats guideline.
Untranslatable Sentence Formed from Fields and Labels
Untranslatable Instruction Text with Embedded Images
Contrast of Generic US and Japanese Address Forms
Some colors, symbols, and images may be interpreted differently in different cultures.
BLAF limits extensive color usage to avoid culturally-sensitive colors. In general, blue is the most acceptable color across all cultures:
- Black: Signifies death or evil in many European cultures.
- White: Signifies mourning in Chinese culture.
- Red: Signifies blood in some cultures, and is generally used for warnings. Some cultures may also still associate red with Communism.
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.
When creating images and icons for use in applications there are three key rules to enable internationalization:
- Do not place text in images, as the text will not be translated by Oracle Applications. The only exceptions to this rule are images containing the Oracle logo, and login pages (such as in Portal) where language names have been specially translated. Text button images are generated automatically by UIX.
- Verify that the image is not culture-specific. For example, an image from American football may have no meaning or even negative associations in some cultures.
- When using an image as a metaphor, verify that the metaphor is not based on language. For example, English-speaking users are familiar with the expression "as different as apples and oranges" and may recognize an apple and an orange image as such. However, speakers of other languages which do not have this expression (and perhaps different types of fruit as well) have no way to interpret the image.
The following types of images should be avoided or used with caution in applications that target multicultural users:
- Hands: Hand and finger gestures have a wide range of interpretations across cultures.
- Eyes: Vary in shape and color from race to race, and may be interpreted as evil in some cultures.
- Faces: Vary in shape and color from race to race. If faces must be shown, they should include a group of mixed races, consisting of at least one Caucasian, one Negroid, and one Asian.
- National: Including flags and recognizable coins or currency, unless the application shows multiple flags or currencies.
- Religious: Including crucifixes or elongated crosses, crescent moons or sickels, six or five-pointed stars, figures seated in cross-legged positions or with hands forming gestures,and so on.
- Sports: Sports images often have strong emotional associations, which may serve well as a metaphor within a single country, but do not work well abroad, where that sport is not popular. Some countries, such as France (Soccer and Rugby) and Australia (Australian Rules and Rugby), play different sports depending on region, with people from one region disparaging the sports played in another.
- Cars: Car models vary from country to country, and year to year. Certain cars, especially luxury and sport models in third world countries, may become the focus of negative public opinion.
- Gender: Avoid showing only male or female images. US and European users may react negatively to male-only images; users from some other countries may react negatively to female-only images. If images of people are required, provide a mix of genders.
- Clothing: Different cultures have different attitudes towards exposure of the parts of the body. Where image of people are shown, they must be fully clothed, with only hands and faces exposed. Note that even such conservative images may need to be modified or removed in countries such as Saudi-Arabia.
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
Open Issues
Issues for V3.0:
- Multiple language support in OA Core technology stack
Closed Issues
02.2000 - Gif generator is NLS compliant, text strings are translated prior to rendering.