National Language Support (NLS)
Oracle's National Language Support makes it possible to design multilingual applications. A multilingual application is an application which can be deployed in several different languages. Oracle supports most European, Middle Eastern, and Asian languages.
National Language Support makes it possible to:
display data according to the appropriate language and territory conventions.
extract strings that appear in your application's user interface and translate them.
The language environment variables
You can use the following parameters as language environment variables to specify language settings:
Parameter Specifies
NLS_CALENDAR: the calendar system used.
NLS_CREDIT: the string used to indicate a positive monetary value.
NLS_CURRENCY: the local currency symbol.
NLS_DATE_FORMAT: the default format mask used for dates.
NLS_DATE_LANGUAGE: the default language used for dates.
NLS_DEBIT: the string used to indicate a negative monetary value.
NLS_ISO_CURRENCY: the ISO currency symbol.
NLS_LANG: the language settings used by Forms Developer and Reports Developer.
DEVELOPER_NLS_LANG: the language for the Builder.
USER_NLS_LANG: the language for the Runtime component.
NLS_LIST_SEPARATOR: the character used to separate items in a list.
NLS_MONETARY_CHARACTERS: the decimal character and thousands separator for monetary values.
NLS_NUMERIC_CHARACTERS: the decimal character and grouping separator for numeric values.
NLS_SORT : the type of sort used for character data.
NLS_LANG
The NLS_LANG language environment variable specifies the language settings used by Reports Developer.
NLS_LANG specifies:
- the language for messages displayed to the user, such as the "Working..." message
- the default format masks used for DATE and NUMBER datatypes
- the sorting sequence
- the character set
The syntax for NLS_LANG is as follows:
NLS_LANG=language_territory.charset
language specifies the language and its conventions for displaying messages and day and month names. If language is not specified, the value defaults to American.
territory specifies the territory and its conventions for default date format, decimal character used for numbers, currency symbol, and calculation of week and day numbers. If territory is not specified, the value defaults to America
charset specifies the character set in which data is displayed. This should be a character set that matches your language and platform. This argument also specifies the character set used for displaying messages.
For example, let's say you want your application to run in French. The application will be used in France
NLS_LANG=French_France.WE8ISO8859P1
Now let's say you want your application to run in French, but this time the application will be used in Switzerland
NLS_LANG=French_Switzerland.WE8ISO8859P1
Note: It is strongly advised to set the language and territory parameters of NLS_LANG to the same values on the server side and the client side. (The value of the charset parameter on the server side is specified when the database is created and cannot be changed.) Use the SQL command ALTER SESSION to change the values of the language and territory parameters on the server side. For example, this statement changes the language parameter to French and the territory parameter to France
ALTER SESSION
SET NLS_LANGUAGE = French NLS_TERRITORY = France
DEVELOPER_NLS_LANG and USER_NLS_LANG
If you must use two sets of resource and message files at the same time, two other language environment variables are available:
DEVELOPER_NLS_LANG specifies the language for the Builder.
USER_NLS_LANG specifies the language for the Runtime component.
The syntax of DEVELOPER_NLS_LANG and USER_NLS_LANG is the same as NLS_LANG.
Use these variables instead of NLS_LANG in the following situations
- You prefer to use the Builder in English, but you are developing an application for another language, the two variables allow you to use different language settings for the Builder and Runtime.
- You are creating an application to run in a language that uses a bidirectional character set.
- You are creating an application to run in a language for which a local-language version of the Builder is not currently available.
- If these environment variables are not specifically set, they take their default values from NLS_LANG.
Character sets
The character set component of the language environment variable specifies the character set in which data is represented in the user's environment. Net8 ensures that data created using one character set can be correctly processed and displayed on a system that uses a different character set, even though some characters may be represented by different binary values in the different character sets.
Character set design considerations
If you are designing a multilingual application, or even a single-language application that will run with multiple character sets, you should determine the character set most widely used at runtime and generate with the language environment variable set to that character set.
If you design and generate an application in one character set and run it in another character set, performance may suffer. Furthermore, if the runtime character set does not contain all the characters in the generate character set, question marks will appear in place of the unrecognized characters.
PDF does not support multi-byte character sets.
Note: For Form Builder, the character set used when generating is used at runtime, regardless of the character set specified in the runtime environment.
Font aliasing on Windows platforms
There may be situations where you create an application with a specific font but find that a different font is being used when you run that application. You are most likely to encounter this when using an English font (such as MS Sans Serif or Arial) in a non-Western European environment.
This occurs because Reports Developer check to see if the character set associated with the font matches the character set specified by the language environment variable.
If the two do not match, Forms Developer or Reports Developer automatically substitutes the font with another font whose associated character set matches the character set specified by the language environment variable. This automatic substitution assures that the data being returned from the database gets displayed correctly in the application.
Note: If you enter local characters using an English font, Windows does an implicit association with another font.
There may be cases, however, where you do not want this substitution to take place. You can avoid this substitution by mapping all desired fonts to the WE8ISO8859P1 character set in the font alias file. For example, if you are unable to use the Arial font in your application, add the following line to your font alias file:
Arial.....=Arial...WE8ISO8859P1
Language and territory
While the character set ensures that the individual characters needed for each language are available, support for national conventions provides correct localized display of data items.
The specified language determines the default conventions for the following characteristics:
language for server messages
language for day and month names and their abbreviations (specified in the SQL functions TO_CHAR and TO_DATE)
symbols for equivalents of AM, PM, AD, and BC
default sorting sequence for character data when ORDER BY is specified (GROUP BY uses a binary sort, unless ORDER_BY is specified)
writing direction
affirmative/negative response strings
For example, if the language is set to French, the messages:
ORA-00942: table or view does not exist
FRM-10043: Cannot open file.
will appear as:
ORA-00942: table ou vue inexistante
FRM-10043: Ouverture de fichier impossible
The specified territory determines the conventions for the following default date and numeric formatting characteristics:
· date format
· decimal character and group separator
· local currency symbol
· ISO currency symbol
· week start day
· credit and debit symbol
· ISO week flag
· list separator
For example, if the territory is set to France
Bidirectional support
Bidirectional support enables you to design applications in Middle Eastern and North African languages whose natural writing direction is right-to-left. Bidirectional support enables you to control:
layout direction, which includes displaying items with labels at the right of the item and correct placement of check boxes and radio buttons.
reading order, which includes right-to-left or left-to-right text direction.
alignment, which includes switching point-of-origin from upper left to upper right.
initial keyboard state, which controls whether Local or Roman characters will be produced automatically when the user begins data entry in forms (the end user can override this setting).
When you are designing bidirectional applications, you may wish to use the language environment variables DEVELOPER_NLS_LANG and USER_NLS_LANG rather than NLS_LANG. For example, if you want to use an American interface while developing an Arabic application in a Windows environment, set these environment variables as follows:
DEVELOPER_NLS_LANG=AMERICAN_AMERICA.AR8MSWIN1256
USER_NLS_LANG=ARABIC_territory.charset
Bidirectional support in Report Builder
Three properties are used to specify the appearance of objects in bidirectional applications: Justify, Direction (for an object), and Direction (for the report). The bidirectional properties are added to objects in the following hierarchy:
Module
Boilerplate
Field
External Boilerplate
Button
Parameter Form Boilerplate
Objects not in this list either do not require bidirectional support (for example, images) or they are defaulted from one of the above object's properties.
