• Creating culture-specific resource files
• Translating message or resource files
• Setting date, time, and money formats
• Translating the product user interface
Localization might also include the translation and production of end-user documentation, packaging, and collateral materials.

To localize a database application, you create a database application for a specific language, territory, and code set. Localization involves the following tasks:

• Ensure that GLS locales exist for the desired language, territory, and code set.
• Translate the character strings in any external resource or message files that the application uses.

Important: An internationalized application is much easier localize than a non-internationalized application.

To localize your application, choose a locale that provides the culture-specific information for the language, territory, and code set that the application is to support. For information about locales, see Setting a GLS Locale.

An internationalized application makes no assumptions about how these locales are set at runtime. Once the application environment specifies the locales to use, the application can access the appropriate GLS locale files for locale-specific information. As long as Informix provides a GLS locale that supports a particular language, territory, and code set, the application can obtain the locale-specific information dynamically.

The current processing locale (sometimes called just the current locale) is the locale that is currently in effect for an application. It is based on one of the following environments:

• The client environment

ESQL/C creates client applications. Therefore, the current processing locale for ESQL/C applications is the client locale.

• The database that the database server is currently accessing

The current processing locale for DataBlade client applications is the client locale. The current processing locale for DataBlade UDRs is the server-processing locale, which the database server determines from the client, database, and server locales.

An internationalized application should not have any language-specific text within the application code. This language-specific text includes the following kinds of strings:

• Strings that the application displays or writes

Examples include error messages, informational messages, menu items, and button labels.

• Strings that the application uses internally

Examples include constants, filenames, and literal characters or strings.

• Strings that an end user is expected to enter

Examples include yes and no responses.

Tip: You do not need to put SQL keywords (such as SELECT, WHERE, INSERT, and CREATE) in a message file. In addition, language keywords (such as if, switch, for, and char) do not need to appear in a message file.

In an internationalized application, these strings appear as references to external files, called resource files or message files. To localize these strings of the database application, you must perform the following tasks:

• Translate all strings within the external files.

The new external files contain the translated versions of the strings that the application uses.

• Set the DBLANG environment variable to the subdirectory within INFORMIXDIR that contains the translated message files that the Informix products use.

The INFORMIXDIR environment variable indicates the location where the Informix products are installed. You can use the rgetmsg() and rgetlmsg() functions to obtain Informix product messages. For more information on these functions, see the Informix ESQL/C Programmer's Manual.