Orientation Guide for Server-Side Programming
This chapter provides an overview of InterSystems IRIS™ support for localization. It discusses the following topics:
InterSystems IRIS supports localization so that you can develop applications for multiple countries or multiple areas without needing to re-engineer the application. The localization model works as follows:
InterSystems IRIS provides a set of predefined locales. An InterSystems IRIS locale
is a set of metadata that specify the user language, currency symbols, formats, and other conventions for a specific country or geographic region. The next section of this chapter provides more details.
The locale specifies the character encoding to use when writing to the InterSystems IRIS database. It also includes information necessary to handle character conversions to and from other character encodings.
When you install an InterSystems IRIS server, the installer sets the default locale for that server.
This cannot be changed after installation, but you can specify that a process uses a non-default locale, if wanted.
The Management Portal displays strings in the local language as specified by the browser settings, for a fixed set of languages.
An InterSystems IRIS locale
is a set of metadata that defines storage and display conventions that apply to a specific country or geographic region. The locale definition includes the following:
InterSystems IRIS uses the phrase National Language Support
(NLS) to refer collectively to the locale definitions and to the tools that you use to view and extend them.
The Management Portal provides a page where you can see the default locale, view the details of any installed locale, and work with locales. The following shows an example:
You can also use this page to see the names of the available translation tables. These names are specific to InterSystems IRIS. (In some cases, discussed later in this chapter, it is necessary to know the names of these tables.)
External to the definition of any locale, a given InterSystems IRIS instance is configured to use specific translation tables, by default, for input/output activity. Specifically, it specifies the default translation tables to use in the following scenarios:
When communicating with an InterSystems IRIS process
When communicating with the InterSystems IRIS Terminal
When reading from and writing to files
When reading from and writing to TCP/IP devices
When reading from and writing to strings sent to the operating system as parameters (such as file names and paths)
When reading from and writing to devices such as printers
For example, when InterSystems IRIS needs to call an operating system function that receives a string as a parameter (such as a file name or path), it first passes the string through an NLS translation appropriately called syscall
. The result of this translation is sent to the operating system.
Whenever you read to or write from an entity external to the database, there is a possibility that the entity is using a different character set than InterSystems IRIS. The most common scenario is working with files.
At the lowest level, you use the Open
command to open a file or other device. This command can accept a parameter that specifies the translation table to use when translating characters to or from that device. For details, see the I/O Device Guide
. Then InterSystems IRIS uses that table to translate characters as needed.
Similarly, when you use the object-based file APIs, you specify the TranslateTable
property of the file.
(Note that the production adapter classes instead provide properties to specify the foreign character set to be used as the expected character encoding system of input data and the desired character encoding of output data. In this case, you specify a standard character set name, choosing from the set supported by InterSystems.)
InterSystems IRIS provides the $ZCONVERT
function, which you can use to manually translate characters to or from another character set.
Content Date/Time: 2019-02-17 00:53:09