Oracle® Application Server Globalization Support Guide
10g Release 2 (10.1.2) Part No. B14004-01 |
|
![]() Previous |
![]() Next |
This chapter contains the following topics:
Global Internet applications need to be aware of the user's locale.
Locale-sensitive functions, such as date formatting, are built into programming environments such as C/C++, Java, and PL/SQL. Applications can use locale-sensitive functions to format the HTML pages according to the cultural conventions of the user's locale.
Different programming environments represent locales in different ways. For example, the French (Canada) locale is represented as follows:
Environment | Representation | Locale | Explanation |
---|---|---|---|
Various | ISO standard | fr-CA
|
fr is the language code defined in the ISO 639 standard. CA is the country code defined in the ISO 3166 standard.
|
Java | Java locale object | fr_CA
|
Java uses the ISO language and country code. |
C/C++ | POSIX locale name | fr_CA on Sun Solaris
|
POSIX locale names may include a character set that overrides the default character set. For example, the de.ISO8859-15 locale is used to support the Euro symbol. |
PL/SQL and SQL | NLS_LANGUAGE and NLS_TERRITORY parameters
|
NLS_LANGUAGE="CANADIAN FRENCH"
|
See Also: "Configuring the NLS_LANG Parameter" in Chapter 5 |
Table 2-1 shows how different programming environments represent some commonly used locales.
Table 2-1 Locale Representations in Different Programming Environments
Locale | ISO | Java | POSIX Solaris | NLS_LANGUAGE, NLS_TERRITORY |
---|---|---|---|---|
Arabic (U.A.E.) | ar | ar | ar | ARABIC, UNITED ARAB EMIRATES |
Germany (German) | de-DE | de_DE | de | GERMANY, GERMAN |
Greek | el | el | el | GREEK, GREECE |
English (U.S.A) | en | en_US | en_US | AMERICAN, AMERICA |
English (United Kingdom) | en-GB | en_GB | en_UK | ENGLISH, UNITED KINGDOM |
Spanish (Spain) | es-ES | es_ES | es | SPANISH, SPAIN |
French (France) | fr | fr_FR | fr | FRENCH, FRANCE |
French (Canada) | fr-CA | fr_CA | fr_CA | CANADIAN FRENCH, CANADA |
Hebrew | he | he | he | HEBREW, ISRAEL |
Italian (Italy) | it | it | it | ITALIAN, ITALY |
Japanese | ja-JP | ja_JP | ja_JP | JAPANESE, JAPAN |
Korean | ko-KR | ko_KR | ko_KR | KOREAN, KOREA |
Portuguese (Portugal) | pt | pt | pt | PORTUGUESE, PORTUGAL |
Portuguese (Brazil) | pt-BR | pt_BR | pt_BR | BRAZILIAN PORTUGUESE, BRAZIL |
Thai | th | th | th | THAI, THAILAND |
Turkish | tr | tr | tr | TURKISH, TURKEY |
Chinese (P.R.C) | zh-CN | zh_CN | zh_CN | SIMPLIFIED CHINESE, CHINA |
Chinese (Taiwan) | zh-TW | zh_TW | zh_TW | TRADITIONAL CHINESE, TAIWAN |
If you write applications for more than one programming environment, then locales must be synchronized between environments. For example, Java applications that call PL/SQL procedures should map the Java locales to the corresponding NLS_LANGUAGE
and NLS_TERRITORY
values and change the parameter values to match the user's locale before calling the PL/SQL procedures.
There are two things that affect an application's overall locale awareness: the development environment in which you create the application, and the target architecture for which the application is built. This chapter addresses these topics with respect to both monolingual and multilingual application architectures.
Determining a User's Locale in Monolingual Internet Applications
A monolingual application, by definition, serves users with the same locale. A user's locale is fixed in a monolingual application and is the same as the default runtime locale of the programming environment.
In most programming environments, almost all locale-sensitive functions implicitly use the default runtime locale to perform their tasks. Monolingual applications can rely on this behavior when calling these functions.
Determining a User's Locale in Multilingual Internet Applications
In a multilingual application, the user's locale may vary. Multilingual applications should do the following:
Dynamically detect the user's locale
Construct HTML content in the language of the locale
Use the cultural conventions implied by the locale
Multilingual applications can determine a user's locale dynamically in the following ways:
Based on the user profile information from an LDAP directory server such as Oracle Internet Directory
The application can store the user profile in the Oracle Internet Directory server provided by Oracle Application Server. The LDAP schema for the user profile should include a preferred locale attribute. This method does not work if a user has not logged on before.
Based on the default ISO locale of the user's browser
Every HTTP request sends the default ISO locale of the browser with the Accept-Language HTTP header. If the Accept-Language header is NULL, then the locale should default to English. The drawback of this approach is that the Accept-Language header may not be a reliable source of information about the user's locale.
Users can select a locale from a list or a group of icons such as flags.
You can use these methods of determining the user's locale together or separately. After the application determines the locale, the locale should be:
Mapped to the locale representations that correspond to the programming environments on which the application runs
Used in locale-sensitive functions
This section discusses locale awareness in terms of the particular programming language and development environment in which an application is written.
A Java locale object represents the corresponding user's locale in Java. The Java encoding used for the locale is required to properly convert Java strings to and from byte data.
Consider the Java encoding for the locale when you make the Java code aware of a user's locale. There are two ways to make a Java method sensitive to the Java locale and the Java encoding:
Using the default Java locale and default Java encoding for the method
Explicitly specifying the Java locale and Java encoding for the method
Locale Awareness in Monolingual Java Applications
Monolingual applications should run implicitly with the default Java locale and default Java encoding so that the applications can be configured easily for a different locale. For example, to create a date format using the default Java locale, use the following method call:
DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL); dateString = df.format(date); /* Format a date */
Locale Awareness in Multilingual Java Applications
You should develop multilingual applications such that they are independent of fixed default locales or encodings. Explicitly specify the Java locale and Java encoding that correspond to the current user's locale. For example, specify the Java locale object that corresponds to the user's locale, identified by user_locale
, in the getDateTimeInstance()
method:
DateFormat df = DateFormat.getDateTimeInstance(DateFormat.FULL, DateFormat.FULL, user_locale); dateString = df.format(date); /* Format a date */
Note: The only difference between the example code for the monolingual application and the multilingual application is the inclusion ofuser_locale .
|
Similarly, do not use encoding-sensitive methods that assume the default Java encoding. For example, you should not use the String.getBytes()
method in a multilingual application because it is encoding-sensitive. Instead, use the method that accepts encoding as an argument, which is String.getBytes(String encoding)
. Be sure to specify the encoding used for the user's locale.
Do not use the Locale.setDefault()
method to change the default locale for the following reasons:
It changes the Java default locale for all threads and makes your applications unsafe to threads
It does not affect the Java default encoding
The Oracle Globalization Development Kit for Java provides a set of Java classes to ensure consistency on locale-sensitive behaviors with Oracle databases. It provides an application framework that enables you to use the locale determination methods declaratively.
Perl and C/C++ use the POSIX locale model for internationalized applications.
Locale Awareness in Monolingual Perl and C/C++ Applications
Monolingual applications should be sensitive to the default POSIX locale, which is configured by changing the value of the LC_ALL
environment variable or changing the operating system locale from the Control Panel in Windows.
To run on the default POSIX locale, the applications should call the setlocale()
function to set the default locale to the one defined by LC_ALL
and use the POSIX locale-sensitive functions such as strftime()
thereafter. Note that the setlocale()
function affects the current process and all threads associated with it, so any multithread application should assume the same POSIX locale in each thread. The following example gets the current time in the format specific to the default locale in Perl:
use locale; use POSIX qw (locale_h); ... $old_locale = setlocale( LC_ALL, "" ); $dateString = POSIX::strftime( "%c", localtime()); ...
Locale Awareness in Multilingual Perl and C/C++ Applications
Multilingual applications should be sensitive to dynamically determined locales. Call the setlocale()
function to initialize the locale before calling locale-sensitive functions. For example, the following C code gets the local time in the format of the user locale identified by user_locale
:
#include <locale.h> #include <time.h> ... const char *user_locale = "fr"; time_t ltime; struct tm *thetime; unsigned char dateString[100]; ... setlocale(LC_ALL, user_locale); time (<ime); thetime = gmtime(<ime); strftime((char *)dateString, 100, "%c", (const struct tm *)thetime)); ...
You must map user locales to POSIX locale names for applications to initialize the correct locale dynamically in C/C++ and Perl. The POSIX locales depend on the operating system.
PL/SQL procedures run in the context of a database session whose locale is initialized by the NLS_LANG
parameter in the database access descriptor (DAD). The NLS_LANG
parameter specifies top-level globalization support parameters, NLS_LANGUAGE
and NLS_TERRITORY
, for the database session. Other globalization support parameters, such as NLS_SORT
and NLS_DATE_LANGUAGE
, inherit their values from these top-level parameters. These globalization support parameters define the locale of a database session.
There are two ways to make SQL and PL/SQL functions locale sensitive:
Basing the locale on the globalization support parameters of the current database session
Explicitly specifying the globalization support parameters
See Also:
for more information about globalization support parameters |
Locale Awareness in Monolingual SQL and PL/SQL Applications
Generally speaking, the initial values of the globalization support parameters inherited from NLS_LANG
are sufficient for monolingual PL/SQL procedures. For example, the following PL/SQL code calls the TO_CHAR()
function to get the formatted date, which uses the current values of the NLS_DATE_FORMAT
and NLS_DATE_LANGUAGE
parameters:
mydate date; dateString varchar2(100); ... select sysdate into mydate from dual; dateString = TO_CHAR(mydate);
If the initial values of the globalization support parameters are not appropriate, then use an ALTER SESSION
statement to overwrite them for the current database session. You can use the ALTER SESSION
statement with the DBMS_SQL
package. For example:
cur integer; status integer; ... cur := dbms_sql.open_cursor; dbms_sql.parse(cur, 'alter session set nls_date_format = "Day Month, YYYY"', dbms_sql.native); status := dbms_sql.execute(cur);
Locale Awareness in Multilingual SQL and PL/SQL Applications
Multilingual applications should use ALTER SESSION
statements to change the locale of the database session to the user's locale before calling any locale-sensitive SQL or PL/SQL functions. You can use the ALTER SESSION
statement with the DBMS_SQL
package. For example:
cur integer; status integer; ... cur := dbms_sql.open_cursor; dbms_sql.parse(cur, 'alter session set nls_language = "NLS_LANGUAGE_of_user_ locale"', dbms_sql.native); dbms_sql.parse(cur, 'alter session set nls_territory = "NLS_TERRITORY_of_ user_locale"', dbms_sql.native); status := dbms_sql.execute(cur);
Alternatively, applications can specify the globalization support parameters in every SQL function that accepts a globalization support parameter as an argument. For example, the following PL/SQL code gets a date string based on the language of the user's locale:
mydate date;
dateString varchar2(100);
...
select sysdate into mydate from dual;
dateString TO_CHAR(mydate, 'DD-MON-YYYY HH24:MI:SSxFF',
'NLS_DATE_LANGUAGE=language' );
...
language
specifies the Oracle language name for the user's locale.
This section discusses locale awareness in terms of application development for particular Oracle Application Server components.
Oracle Application Server Wireless sends all Mobile Context information as HTTP headers when invoking a request. The user locale is sent using the X-Oracle-User.Locale
header. The locale value contains the ISO language, and an optional ISO country code, separated by a hyphen. For example, "en-US", "zh-CN", and "ja" are all valid locale values for this header. Mobile service applications should use the user locale specified in this header to determine the language and cultural conventions used in the user interface.
For example, JSP applications may retrieve the user locale as follows:
<%
String userLocale = request.getHeader("X-Oracle-User.Locale");
%>
Oracle Business Intelligence Discoverer can simultaneously support users with different locales. Users may explicitly control the locale used for the user interface, or they may allow Oracle Business Intelligence Discoverer to automatically determine a default. The order of precedence for determining the language and locale is:
Language and locale settings included in the URL for Oracle Business Intelligence Discoverer
Language and locale settings specified in the OracleBI Discoverer Connection. If the locale is specified in the user's browser, then the language settings in the user's browser is used.
Language and locale of Oracle Application Server.
For example, suppose a user's browser's language and locale are set to German - Germany
and the user goes to the URL to start Oracle Business Intelligence Discoverer. The HTML page returned to the user is displayed in German. If the user clicks on the OracleBI Discoverer Connection, which has the language and locale specified as English - US
, the OracleBI Discoverer user interface appears in English. This is because the OracleBI Discoverer Connection settings take precedence over the browser's settings.