Skip to main content
Previous section   Next section

Localization Support

This chapter provides an overview of InterSystems IRIS® support for localization.

Introduction

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.

  • You can provide localized strings for your own applications as well. See the article String Localization and Message Dictionaries. This mechanism is available for REST services and Business Intelligence elements.

InterSystems IRIS Locales and National Language Support

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:

  • Number formats

  • Date and time formats

  • Currency symbols

  • The sort order of words

  • The default character set (the character encoding of this locale), as defined by a standard (ISO, Unicode, or other).

    Note that InterSystems IRIS uses the phrases character set and character encoding as though they are synonymous, which is not strictly true in all cases.

  • A set of translation tables (also called I/O tables) that convert characters to and from other supported character sets.

    The “translation table” for a given character set (for example, CP1250) is actually a pair of tables. One table specifies how to convert from the default character set to the foreign character set, and other specifies how to convert in the other direction. In InterSystems IRIS, the convention is to refer to this pair of tables as a single unit.

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:

images/gorient_locale_details.png

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.)

For information on accessing and using this Management Portal page, see “Using the NLS Pages of the Management Portal” in the System Administration Guide.

InterSystems IRIS also provides a set of classes (in the %SYS.NLS and Config.NLS packages). See “System Classes for National Language Support” in the chapter “Customizing the InterSystems IRIS” in Specialized System Tools and Utilities.

Default I/O 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 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.

To see the current defaults, use %SYS.NLS.Table; see the class reference for detail.

Files and Character Encoding

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.)

Manually Translating Characters

InterSystems IRIS provides the $ZCONVERT function, which you can use to manually translate characters to or from another character set.