Caché Programming Orientation Guide
Localization Support
[Back] [Next]
   
Server:docs1
Instance:LATEST
User:UnknownUser
 
-
Go to:
Search:    

This chapter provides an overview of Caché support for localization. It discusses the following topics:

The Caché tools for creating web pages (Zen and Caché Server Pages) provide additional options to enable you to localize those pages. See Developing Zen Applications and Using Caché Server Pages (CSP).
Introduction
Caché supports localization so that you can develop applications for multiple countries or multiple areas without needing to re-engineer the application. The Caché localization model works as follows:
Caché Locales and National Language Support
A Caché 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:
Caché 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 Caché. (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 Settings Page of the Management Portal in the Caché System Administration Guide.
Caché 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 Caché System” in Caché Specialized System Tools and Utilities.
Default I/O Tables
External to the definition of any locale, a given Caché 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 Caché 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 Caché. 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 Caché I/O Device Guide. Then Caché 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 Ensemble 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
Caché provides the $ZCONVERT function, which you can use to manually translate characters to or from another character set. For example:
 IF $SYSTEM.Version.IsUnicode() {
   SET greek=$CHAR(945,946,947,913,914,915)
   WRITE $ZCONVERT(greek,"W")
   }
   ELSE {WRITE "This example requires a Unicode installation of Caché"}