Globalization Guide for Oracle Applications Release 12

这篇博客详细介绍了Oracle Applications Release 12的全球化特性,涵盖了如何在多语言、多地区环境中部署和配置应用程序,确保全球一致的用户体验。
摘要由CSDN通过智能技术生成

Section 1. Overview

Audience

This document, the Oracle Applications Globalization Guide, provides key information for using Oracle Applications in global organizations. Much of the information is also applicable to smaller organizations that may be located in a single country but trade globally. This guide follows a task-based approach for presenting information, and different chapters (marked with an X in the table below) will be of interest for particular users.

Section System Administrators End Users Application Developers Translators
Overview X X X X
Installing X      
Configuring X      
Maintaining X      
Using   X    
Customizing     X  
Translating       X
Troubleshooting X      

This guide provides an overview of internationalization concepts and associated operations in an Oracle Applications system. Several appendices serve as reference guides for a number of specific internationalization topics. These are intended for consultation on an as-needed basis, depending on the specific requirements of an installation.

Terminology

This section explains some terminology related to international language support in Oracle Applications.

National Language Support (NLS)

In Oracle Applications, National Language Support (NLS) refers to the ability to run an Applications instance in any single supported language, including specific regional or territorial number and date formats. Typically, in order to support a given language, only the customer-facing components of the Applications software (user interface, lookup tables, online documentation, and so on) are translated. Translations are delivered via NLS patches.

Multiple Language Support (MLS)

In Oracle Applications, Multiple Language Support (MLS) refers to the ability to run multiple languages in the same Applications instance. MLS provides multiple language architecture, while NLS provides the individual language translations.

NLS_LANG

Many Oracle products use the NLS_LANG environment variable to specify locale behavior. NLS_LANG has three components, concatenated as LANGUAGE_TERRITORY.CHARSET; for example,

NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1.
The NLS_LANG character set should be set to match the character set of the database.
Base Language and Installed Languages

An Applications instance has one base language, and may have one or more installed languages. An instance will always have at least American English. All products, whether MLS-enabled or not, can store data in the base language. MLS-enabled products or components can store data in the base language as well as any installed languages. Most products in Applications Release 12 are MLS-enabled.

Unicode

UTF8 and AL32UTF8 are encodings of the Unicode character set and include all the characters in all modern languages. UTF8 and AL32UTF8 allow Oracle Applications to be run from one database instance using any combination of supported languages. The advantage of AL32UTF8 over UTF8 is in the handling of supplementary characters, which are increasingly used in certain languages. AL32UTF8 is the current default database character set for Oracle databases.

Locale

A locale is a collection of information relating to the linguistic and cultural preferences for a particular region. In an Oracle database, a locale consists of language, territory, and character set. An Oracle locale is associated with certain formatting behavior, and provides defaults for the user profile options in Oracle Applications.

Localizations

Localizations provide additional business functionality that is required for certain countries. This is distinct from translations, which are the text data for a language used in Applications products: in contrast, a localization results in an application functioning differently.

In the OA Personalization Framework, localizations exist at the Localization level of personalization, and can be overridden by more specific functionality at the Site, Organization, Responsibility, User, or Portlet personalization levels. For more information, see the Oracle Application Framework Personalization Guide

Country specific functionality is included in the base code called globalizations, and is licensed using the Rapid Install Wizard or the License Manager in Oracle Applications Manager. For details on installing country-specific functionality and languages using the Rapid Install Wizard, see the Oracle Applications Installation guide. For more information on License Manager, see Maintaining Oracle Applications. Once installed and licensed, localizations can be turned on and off for testing purposes using Help > Diagnostics > Custom Code.

Personalizations

Personalizations are settings that affect applications behavior, and have a built-in precedence of levels. For instance, the labels appearing in a OAF-based web page can be modified or hidden for a given level, such as Site level or Responsibility level. See the Oracle Application Framework Personalization Guide for more details on personalizations.

Date Formatting

Dates can be entered in any valid format, such as 12-31-07 (US standard), 31-12-07 (British standard), or 2007-12-31 (ISO standard). The setting is controlled by the Date Format Mask profile option.

Number Formatting

Country-specific conventions determine how a number is entered and displayed. For example, the number "one million" is usually represented as 1,000,000.00 in the United States and United Kingdom, with the period (.) being used as the decimal separator, and the comma (,) being used as the grouping separator between thousands. In contrast, many European countries use the comma as the decimal separator and the period as the grouping separator, so "one million" may be represented as 1.000.000,00. The characters used for the decimal separator and grouping separator to be changed to suit user preference when numbers are entered or displayed.

NLS Patches
NLS patches are special patches that provide language translations including user interface labels, menus, and some Oracle seeded setup data.
Translation Synchronization Patch
The Translation Synchronization patch (TSP) feature allows you to synchronize your existing translations with the American English file versions or to install new languages on your Applications instance. By applying just one patch for each language, you will be able to bring your translations up to your Applications patch level. You can also choose to get the latest translations to bring your translations up-to-date.
Lightweight MLS
The lightweight MLS feature, introduced in Oracle E-Business Suite 12.1.3, allows you to use a language without applying its corresponding NLS patches. This type of language enabling option is referred as lightweight mode. In contrast, full translation mode refers to the traditional language enabling option that requires NLS patches to be applied for all languages in use. In lightweight mode, the user Interface (UI) will be in English, but you can still translate the relevant seed data, reports, and Forms/Oracle framework pages. You can later switch to full translation mode by applying the language NLS patches.
Lightweight-only Language
A language which can be enabled in lightweight mode only. A lightweight-only language cannot be switched to full translation mode because Oracle does not provide NLS patches, including Translation Synchronization patches, for such languages.

Related Documents

Section 2. Installing

This section is intended for use as a supplement to the standard Oracle Applications documentation: it does not replace the Oracle Applications Installation Guide, or Upgrade manuals, or the NLS Release Notes. The intended audience is an administrator installing an Applications instance.

Oracle Applications Internationalization Architecture

Tiers and character sets

An Oracle Applications system consists of three tiers: the database tier, application (middle) tier, and client (desktop) tier. The most important language-related feature on the database tier is the choice of database character set. AL32UTF8 is the recommended character set for instances providing multi-language support, as it can accommodate all the characters from the installed languages. However, for an installation that needs to support a single language (besides English), a specific character set could be chosen to accommodate that language and no others. For example, in the case of an organization operating only in Western Europe, the WE8IS08859P15 character set could be selected to support Western European languages specifically. This helps to optimize database performance, at the expense of flexibility. It would not, for example, be possible to later support Eastern European languages with this character set, if the organization opened a branch in Eastern Europe.

The Applications components on the application tier utilize two language-related settings: the user profile and the NLS_LANG environment variable. The user profile stores user preferences such as session language, date format, and number format. It is stored in the database, but users can configure it from a browser using the Preferences page.

Users set their preferred language in the web browser (the client tier), set their time zone, and verify that they have any required fonts and OS locales installed.

The settings of the Applications user profile and the NLS_LANG environment variable play a significant part in mediating communication between the database tier and application tier, and between the application tier and client tier. For communication between the database tier and the application tier, the setting of NLS_LANG indicates the character set to be used on the application tier.

Note: Use the same character set on both the database tier and application tier, to avoid the risk of losing characters on conversion.

NLS_LANG and user profile are also used in communication between the application tier and the client tier. For example, OC4J generates HTML output based on the language setting in the user profile. With the Forms client, the character set is determined by the value of NLS_LANG, but the language is determined by the user profile.

For more information on setting the NLS_LANG correctly in Unix environments, see 264157.1 

Planning the implementation

Prior to installation, decide on your database character set. Create your database with a character set that supports all of the languages that you are installing or may install in the future. To minimize restrictions on the language combinations you can use, choose UTF8 or AL32UTF8. The Oracle Applications Installation Guide describes this in more detail. For a list of the supported non-Unicode character sets for each language, see the section on languages and character sets in this guide.

You can use this SQL command to check the database character set:

select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
Usage Requirement Analysis

The starting point for deciding on a suitable NLS and MLS specification is the organization's requirements for languages. The languages needed are determined by two factors: languages of the organization's end users, and legislation where the organization conducts its business.

Examples of the first consideration include:

  • A company operating in one country. For example, if a company located in Japan only uses the Japanese language, then only Japanese language support needs to be installed. American English is always installed by default, so the above system would have both American English and Japanese.
  • A global company operating in one language. For example, multi-lingual support is not required for a U.S. company that has Chinese branches, but uses English in all those branches.
  • A global company operating in multiple languages. For example, a company with an instance in its headquarters which hosts the service for its worldwide subsidiaries would need to install languages to meet the requirements of its subsidiaries.

An example of the second consideration would be:

  • A company submitting documents in a language stipulated by the government or trading partners. For example, the South Korean Government requires all financial reports to be submitted to it in Korean. Korean language support is mandatory in Oracle Applications installations for companies that conduct business in Korea, even if the application users are based in the US and speak only English.

Organizational requirements should be collected with both of these aspects in mind. Once this information is available, the appropriate languages and character sets can be chosen for the Applications system. Due to business changes such as mergers or entry in new markets, language requirements may change in the future.

System Requirements Analysis

Consult the Oracle Applications NLS Release Notes to ensure that the system has enough resources for enabling NLS and MLS; pay particular attention to disk space, memory, and database size.

Also look for information on the space needed per language, to accommodate:

  • Forms files
  • Forms executables
  • Report files
  • Seed data and related files
  • NLS software temporary staging area
  • Minor increase in database size per language at installation time
Language and Character set Requirements Analysis

In Oracle Applications, choosing a language means choosing a set of translated resources. Choice of character set is the most important factor for configuring NLS and MLS with Oracle Applications. The character set must support the all the characters of the languages that are to be installed. In addition, platform-specific characters or user-defined characters (UDC) may need to be supported. The character set should be determined based on these requirements, and then specified for the database as well as each HTTP server and APPL_TOP.

Database Tier - Oracle Database Character Set

The database character set is chosen during initial installation of Oracle Applications. A default character set is suggested by Rapid Install, based on the languages selected. This default character set will support the system"specified language requirements. While the database character set can subsequently be changed to another character set that supports the language requirements, it is always desirable to choose the correct one at install time, as it is very time-consuming to alter it later. Thus, the database character set should be chosen after careful consideration of an organization's long-term needs.

Adding languages after the implementation is complete may require a change in character set, unless UTF8 or AL32UTF8 was chosen. For this reason, AL32UTF8 is a good choice when planning for expansion. For maximum flexibility in meeting future requirements, Oracle recommends employing the AL32UTF8 character set, as this makes it easy to add other languages in the future. However, AL32UTF8 or UTF8 is not recommended for the Thai language, since it uses three bytes per Thai character and thus reduces the number of Thai characters that can be stored to one third.

The available character sets are described in the Oracle National Language Support Guide and Oracle Globalization Support Guide. The following table lists the supported languages grouped into language categories, with the supporting database character sets (also known as code pages) that can be used with these languages. The non-Unicode character set suitable for a language depends on the language category, whether Euro currency symbol support is needed, and other customer requirements. Remember that a Unicode character set, such as AL32UTF8, is also supported for any of the languages listed.

Languages in the same language category can be supported in a single instance using either Unicode (UTF8 or AL32UTF8) or the character set listed with the category. Languages from different language categories in a single instance can only be supported using Unicode. For example, since German is in the Western European language category and Polish is in the Eastern European category, only Unicode can support both German and Polish. However, English data is supported in any language category, because English characters are included in all of the other character sets.

This table also indicates if the language is translated in Forms (F), Reports (R), and UIX (U).

Oracle Database Language Codes, Translated Technologies, and Character Sets
Language Language Code Translated Technologies Language Category Non-Unicode Character Set
American English US F,R,U Western European WE8MSWIN1252 - MS Windows Code Page
WE8ISO8859P15 - ISO Western European
WE8ISO8859P1 - ISO Western European*
Brazilian Portuguese PTB F,R,U
Canadian French FRC F,R,U
Danish DK F,R,U
Dutch NL F,R,U
Finnish SF F,R,U
European French F F,R,U
German D F,R,U
Indonesian IN F,R,U
Italian I F,R,U
Latin American Spanish ESA F,R,U
Norwegian N F,R,U
European Portuguese PT F,R,U
Spanish E F,R,U
Swedish S F,R,U
Albanian SQ F,R,U Eastern European EE8MSWIN1250 - MS Windows Code Page
EE8ISO8859P2 - ISO East European*
Croatian HR F,R,U
Czech CS F,R,U
Hungarian HU F,R,U
Latin Serbian LSR F,R,U
Polish PL F,R,U
Romanian RO F,R,U
Slovak SK F,R,U
Slovenian SL F,R,U
Lithuanian LI F,R,U Baltic BLTMSWIN1257 - MS Windows Code Page
Arabic AR F,R,U Arabic AR8MSWIN1256 - MS Windows Code Page
AR8ISO8859P6 - ISO Character set*
Cyrillic Kazakh CKK F,R,U Unicode AL32UTF8 - Unicode
Greek EL F,R,U Greek EL8MSWIN1253 - MS Windows Code Page
EL8ISO8859P7 - ISO Character Set*
Hebrew IW F,R,U Hebrew IW8MSWIN1255 - MS Windows Code Page
IW8ISO8859P8 - ISO Character Set - not currently supported
Japanese JA F,R,U Japanese JA16SJIS - Japan Industrial Standard
JA16SJISTILDE - Japan Industrial Standard
JA16EUC - Extended UNIX Code
JA16EUCTILDE - Extended UNIX Code
Korean KO F,R,U Korean KO16MSWIN949 - MS Windows Code Page
Cyrillic Serbian CSR F,R,U Cyrillic CL8MSWIN1251 - MS Windows Code Page
CL8ISO8859P5 - ISO Character Set*
Russian RU F,R,U
Ukrainian UK F,R,U
Simplified Chinese ZHS F,R,U Simplified Chinese ZHS16GBK - Guo Biao Kuozhan
Thai TH F,R,U Thai TH8TISASCII - Thai Industrial 620-2533 - ASCII 8-bit
Traditional Chinese ZHT F,R,U Traditional Chinese ZHT16MSWIN950 - MS Windows Code Page - meets the requirements for Taiwan, but not Hong Kong.
ZHT16HKSCS - Hong Kong Supplementary Character Set - meets the requirements for Hong Kong, but not Taiwan.
Turkish TR F,R,U Turkish TR8MSWIN1254 - MS Windows Code Page
WE8ISO8859P9 - ISO Character Set*
Vietnamese VN F,R,U Vietnamese TR8MSWIN1258 - MS Windows Code Page
Notes on Table
  • The asterisk (*) marks character sets that do not support the Euro symbol.
  • Oracle strongly recommends customers to choose AL32UTF8 if supporting Hong Kong Supplementary Character Set (HKSCS) is a requirement.
  • The Vision Demo database is set up with a database character set of UTF8 and a base language of American English.
  • The character sets ZHT16HKSCS31 and ZHT32EUC are not supported.
  • For more information see the Oracle Applications Release 12.2, 12.1 & Release 12.0 Translation Scope and Availability (405992.1)
Note: Although AL32UTF8 is supported as a database character set, Unicode supplementary characters are not currently supported in Oracle Applications. Supplementary characters are Unicode characters with code point values greater than U+FFFF.
Lightweight-only languages
Lightweight-only languages are languages that can be enabled in lightweight mode only. Oracle do not provide NLS patches including Translation Synchronization patches (see MOS 252422.1 for details) for such languages. Therefore, unlike regular supported languages listed above, which customers can enable in full translation mode or start from lightweight mode then move to full translation mode through applying the NLS patches, the Lightweight-only languages listed below cannot move to full translation mode because there is no NLS patch available.
Language Language Code Language Category Non-Unicode Character Set
Bulgarian BG Cyrillic TR8MSWIN1251 - MS Windows Code Page
CL8ISO8859P5 - ISO Character Set*
Catalan CA Western European WE8MSWIN1252 - MS Windows Code Page
WE8ISO8859P15 - ISO Western European
WE8ISO8859P1 - ISO Western European*
Notes on Table
  • The asterisk (*) marks character sets that do not support the Euro symbol.
Application Tier (Middle Tier) - APPL_TOP Character Set and ICX_CLIENT_IANA_ENCODING

The application tier is the location of a number of Oracle Applications server processes, including the Forms server and Web server, which communicate with each other and with Applications software on the other tiers. The application tier character set should be identical to the database character set... The application tier character set is specified during installation in Rapid Install, and is called the APPL_TOP character set.

The Web server, on the application tier, must use a character set that is supported by the browser, on the client tier. The application tier character set must support all the characters that the client tier languages employ. In other words, APPL_TOP character set must be identical to the database character set.

Client Tier (Desktop Tier) - FND_NATIVE_CLIENT_ENCODING

The client (desktop) character set, used for file downloads, is set during the post-installation steps in the FND_NATIVE_CLIENT_ENCODING profile option using the Oracle character set naming convention. This character set should be compatible with the OS character set of the user"s desktop machine. The administrator sets a site level default and the end user can override it in the user profile.

Note: Whether you are planning a fresh NLS install or upgrading from an older release of Applications, you must follow the instructions in the NLS Release Notes for Release 12.

Database Sort Order

Oracle Applications Release before 12.2.2 supports only binary database sort order.

  • Linguistic sort is supported in 12.2.2 and later as follows.
  • End users can see linguistically sorted result sets in the online UI (OA Framework, Forms). Batch programs or Oracle reports run via concurrent program will use a binary sort.
  • ICX: NLS Sort profile is used to control the user preferred sort language. This profile can be set at the user and site level by administrator.
  • The profile has a LOV which shows sufficient sort languages especially for case-insensitive or accent-insensitive sort filtered by by installed languages in the E-Business Suite instance.
  • NLS_SORT database session variable is set based on this profile option, and Linguistic sort is done at the database tier (SQL query results) only.
  • All SQL comparison (e.g. where clause “=”, “like”, etc) is performed as binary.
  • No linguistic index is necessary for linguistic sort support, but it is possible that there may be very rare cases where linguistic indexes would help – this will have to be determined on a case by case basis.
  • In case of linguistic sort, in-memory linguistic sort will be done instead of the in-memory binary sort, which may have some minor performance impact.

Multilingual Table Structure

Multilingual support (MLS) in Oracle applications uses a base table, containing non-translatable content, and a translations table, containing translatable content for the base language and installed languages. This section explains how an MLS table is designed, how the MLS data is created, and how the data is maintained in the database.

Translatable Applications tables are organized into pairs: a base table, whose name ends with "_B"; and a translation table, whose name ends with "_TL". For every row in the base table, there is one row in the translation table for each language, including the base language.

A _TL table always has a LANGUAGE column, a SOURCE_LANG column, and one or more translatable columns.

Column Comment
The same key fields exist in the base and TL tables.
LANGUAGE Indicates the language label associated with the row
SOURCE_LANG Indicates the actual language of the contents of the row
Hold the translatable data
Who columns exist in all tables.
How MLS tables are populated

After running Rapid Install, MLS (_TL) tables have rows for US (American English) only.

select * from FND_MENUS_TL where MENU_ID=1011274

Returns one row:

LANGUAGE=US, Description="Payables and Receivable Transactions", SOURCE_LANG=US

After running Maintain multi-lingual tables in ADADMIN, the same select returns one row per language, for instance

LANGUAGE=US, Description="Payables and Receivable Transactions", SOURCE_LANG=US
LANGUAGE=JA, Description="Payables and Receivable Transactions", SOURCE_LANG=US
LANGUAGE=AR, Description="Payables and Receivable Transactions", SOURCE_LANG=US

ADADMIN created a copy of the source row for each target language. The source language in each row is American English (US), the data is American English, and the LANGUAGE column contains the target language code. The actual translation for each language can now be installed and will overwrite the appropriate target language row. Oracle seeded translations are installed by applying NLS patches.

Files containing translated data reside in subdirectories named after the language code. For example, $AP_TOP/reports/NL, $GL_TOP/forms/F. Tables containing translatable data have a related translation table (_TL table). For tables containing translatable data, a _VL view allows the data to be selected based on the session language.

Related Documents

Section 3. Configuring

This section discusses setting administrative suite wide configurations after the initial installation or Oracle Applications is complete.

Preferences

In Oracle Applications, various locale parameters influence the characteristics of the user session, such as the data display format and behavior. Administrators should review the NLS related profile option values and override them at the Site level if necessary. The administrator can access these values in either of these two paths

  • Functional Administrator responsibility: Core Services > Profiles web page
  • System Administrator responsibility: Profile > System Form

Some of these profile options can be overridden by the user at the session level, by setting them in the Preferences page.

These parameters are stored as profile options, as follows:

Profile Option Name Specifies Available in Preferences page? Comment
ICX: Client IANA Encoding IANA character encoding used with displays for HTML-based Applications products

  For a general description of IANA encoding, visit the IANA web site.
ICX: Date format mask Date format X  
ICX: Date language Date language   Not recommended for use in Release 12. Exists for backwards compatibility.
ICX: Language
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值