InterSystems IRIS Data Platform 2019.2  /  Orientation Guide for Server-Side Programming

Orientation Guide for Server-Side Programming
Localization Support
Previous section           Next section
InterSystems: The power behind what matters   

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

Previous section           Next section
Send us comments on this page
View this book as PDF   |  Download all PDFs
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA
Content Date/Time: 2019-10-18 05:16:51