A GLS locale
In a client/server environment, both the database server and the client application must know which language the data is in to be able to process the application data correctly.
- The name of the code set that the application data uses
- The classification of the characters in the code set
- The collation (sorting) sequence to use for character data
- The user format for monetary, numeric, date, and time data
Type of GLS file | Description |
---|---|
GLS locale files | Specify language, territory, writing direction, and other cultural conventions. |
Code-set files | Specify how to map each logical character in a character set to a unique bit pattern. |
Code-set-conversion files | Specify how to map each character in a “source” code set to corresponding characters in a “target” code set. |
The registry file | Associates code-set names and aliases with code-set numbers that specify file names of locale files and code-set conversion files. |
Each database is limited to a single locale, but different databases of the same database server can support different locales.
A single database can store character data from two or more languages that require different character sets by using the open source International Components for Unicode (ICU) implementation of the Unicode code set (UTF-8). This code set is available in GLS database server locales for many languages and territories. (Locales for some client-side systems also support the ICU code set UTF-8 and the ICU code sets UTF-16 and UTF-32.)
The SET COLLATION statement of HCL OneDB supports more than one localized collating order to sort NCHAR and NVARCHAR character strings.