NAME

hpnls − HP Native Language Support (NLS) Model

DESCRIPTION

Native Language Support (NLS) reduces or eliminates the barriers that would otherwise make HP-UX difficult to use in a non-English language.  NLS is available at the user command level as well as through commands and libraries that can be used to develop international software applications.  HP-UX NLS is a combination of standards specified by the X/Open Portibilty Guide, Issue 2 and 3, IEEE 1003.1 and ANSI C as well as HP added enhancements. 

Many existing C library routines have been modified to operate based upon a program’s locale.  A locale is the run-time NLS environment of a program which is loaded by the setlocale(3C) routine.  For a complete list of what library routines are affected by setlocale, see setlocale(3C). 

In addition to the routines which operate based on the program’s locale, there are also commands and routines which provide a messaging system for accessing program messages based on the language requirements of the end-user. 

Many HP-UX commands have been modified to operate in a manner sensitive to the language requirements of the end-user.  These language requirements are established through the internationalization environment variables (see environ(5)).  The "External Influences/Environment Variable" sections of each command with NLS capabilites describes which environment variables the command is sensitive to. 

In addition, Portnls is a set of library routines which perform miscellaneous language-dependent operations.  Portnls is intended to provide portibility between HP-UX and MPE (another HP operating system). See portnls(5) for more information. 

Below are areas of functionality which are considered language sensitive :

Character Handling
NLS provides for handling characters outside the 7-bit USASCII codeset. Most languages require a minimum of 8-bits to support all the characters needed to communicate in that language.  Characters must be handled according to the requirements of the language they represent.

  Codesets with 8-bit characters have been defined to support phonetic languages, such as the Western European languages.  The use of an 8-bit character allows for an additional 128 characters beyond the USASCII codeset. 

  More than 8 bits are needed to uniquely define codes for characters required by ideographic languages, such as Japanese.  A multibyte encoding scheme, the scheme used to encode multibyte character sequences, is used to define codesets for ideographic languages.  Multibyte codesets define character codes which are represented by one or more bytes.  The encoding scheme used to define the multibyte codesets is described in HP-UX Concepts and Tutorials. 

Character Classification
Characters have many attributes associated with them.  For example, characters may be classified as printable, alphabetic, numeric, etc. These attributes are commonly referred to as ctype characteristics. Characters and their associated attributes differ between languages. Character processing that depends on character classification must be sensitives to these differences.

Shifting
The notion of "case" differs between languages.  For example, in some languages accents are discarded when characters are shifted to uppercase.  Some languages have no notion of upper and lower-case characters.  For example, in ideographic languages shifting a character will have no affect.

Collating
Collating sequences differ between languages and most languages require multiple collating sequences.  The following collation features are available to provide a full "dictionary" or "context based" language-dependent comparsion :

Two_to_one conversions
Some languages, such as Spanish, require two adjacent characters to occupy one position in the collating sequence.  Examples are “CH” (which follows “C”) and “LL” (which follows “L”).

One_to_two conversions
Some languages, such as German, require one character (for example, “sharp S”) to occupy two adjacent positions in the collating sequence.

Don’t care characters
Some languages designate certain characters to be ignored in character comparisons.  For example, if “−” is a “don’t care” character, the strings “REACT” and “RE−ACT” would equal each other when compared.

Case and accent priority
Many languages require a “two-pass” collating algorithm. In the first pass, accents are stripped off letters and the resulting two strings are compared; if they are equal, a second pass with the accents reinserted is performed to break the tie.  The case of letters can also be first ignored and then used to break ties in this fashion.

Two common methods of collation for phonetic languages are folded and nonfolded. A folded collating sequence will be made up of the upper and lowercase characters intermixed.  An unfolded collating sequence will be made up of all the uppercase characters followed by the lowercase characters.  For example, collating the characters a b c A B C with folded collation would result in the following order :

A a B b C c

Collating the same characters with unfolded collation would result in the following order :

A B C a b c

For languages in which folded and unfolded collation methods are defined, HP-UX uses folded as the default.  The setlocale modifier "nofold" can be used to enable the nonfolded collating method (see environ(5)).  The nlsinfo(1) command will report the collating methods supported for each language. 

Directionality
Two properties of text files and Native Languages must be understood to process text in non-Western languages — the mode of the language and the order of the characters.

Mode refers to the direction that a language is naturally read.  European languages read from left to right, some Middle Eastern languages read from right to left, and Far Eastern languages usually use vertical columns, beginning from the right. 

Order describes the order that characters are written, stored in a file, or displayed.  Keyboard order refers to the order of keystrokes by a user.  Screen order refers to the order that characters are displayed on a terminal screen or printed. 

Screen order can differ from keyboard order when using a terminal that supports mixing Latin and non-Latin text, each requiring different directionality.  In the following example, the text mode is right to left; n represents a non-Latin character, l represents a Latin character, and the numbers represent the order in which the sequence is typed. 

In keyboard order, the letters would be stored in a file as follows:

n1 n2 n3 l4 l5 l6

In screen order, the letters would be stored in a file as follows:

n1 n2 n3 l6 l5 l4

However, both screen-order and key-order sequences would look identical on the screen, because the terminal would be configured to display the characters properly according to the directionality requirements of both the Latin and non-Latin languages. 

Local Customs
NLS supports customs which are specific to a particular geographic region, such as representation of numeric and monetary data, date and time.  These customs can differ not only between languages, but also between region which share a common language.

Representation of numbers
The character used to denote the radix of a decimal number varies for different regions. Similarly the use of a "thousands" indicator or grouping of digits can vary with local custom. Characters used to represent digits can also vary for different regions.

Monetary representation
The currency symbol and the formatting of monetary values varies from country to country.  For instance, the symbol can either precede or follow the monetary value.  Some currencies allow decimal fractions while others use alternate methods of representing smaller monetary values.

Date and time representation
While the Gregorian calendar is most common, some countries use other methods for determining meridian day and year, usually based on seasonal, astronomical, or historical events.  Month and weekday names as well as the format of date and time varies from country to country.  Even when a strictly numeric date/time representation is used, the order of year, month and day, as well as the delimiters that separate them, is not universal.

  The HP-UX system clock runs on Coordinated Universal Time.  Time zone adjustments for a particular regions can be specified through the TZ environment variable (see environ(5)). 

Messages
Messages issued by a program should be sensitive to the language of the end-user.  NLS provides a messaging facility for extracting hard coded strings (messages) from an application source code and storing them externally to the code. Utilities are provided which aid the tranlation of messages, such that at runtime the program accesses messages which coincide with the end-users native language.

FILES

/usr/lib/nls/*

AUTHOR

Hpnls was developed by HP. 

SEE ALSO

insertmsg(1), gencat(1), catgets(3C), catopen(3C),setlocale(3C), environ(5), lang(5)

Native Language Support, manual in HP-UX Concepts and Tutorials:  Device I/O and User Interfacing. 

For additional information, see the External Influences/Environment Variables section on other manual pages of commands and library routines. 

Hewlett-Packard Company  —  HP-UX Release 7.0: Sept 1989