Guide for Locale Configuration
When configuring Lycia, you have to pay attention to localization settings: Without properly set locale, you might get issues when using different character sets and creating 4GL applications for certain languages:
Setting the application locale
Setting the database client locale
Besides configuring the environment in general (by configuring Lycia or its separate components), you can also specify the necessary environment variables for separate projects and programs.
This guide provides steps for configuring locale settings.
Step 1. Define the application locale by specifying the correct character set used in your source files.
By default, each source file is compiled using the encoding specified for its container (program or project). So, if your source files initially are using a non-default encoding, remember to specify it..
The encoding can be set:
A) as an option for the qfgl tool in the command line:
qfgl --encoding UTF-8
gfgl -e UTF-8
B) In the target file *.fgltarget:
<?xml version="1.0" encoding="UTF-8"?>
<fglBuildTarget xmlns="http://namespaces.querix.com/lyciaide/target" name="target_name" encoding="UTF-8" type="fgl-program">
<sources type="fgl">
....
</sources>
<sources type="form">
....
</sources>
</fglBuildTarget>
In the project file *.fglproject:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<fglProject name="project_name" encoding="UTF-8">
<data>
....
</data>
</fglProject>
Refer to Setting the Application Locale for more details.
Step 2. Make sure that the correct length semantics is used in your application.
Some of the character data types require their length to be predefined during declaration, for example, CHAR(n). In multi-byte locales 'n' stands for the number of bytes rather than the number of characters, like it does in the default U.S. English locale. Thus, when declaring variables in multi-byte locales, you must remember that each character will most probably take up more than 1 byte.
Different database vendors use different length semantics for character data types. Some databases use BLS (Byte Length Semantics), other use CLS (Character Length Semantics), and other support both semantics.
Refer to Character Length Semantics for more details.
Step 3. Set the database client locale corresponding to the application locale.
Make sure the database client locale and the application locale are the same. If the database client locale differs from the application locale, data will be written to the database incorrectly. Thus, you must make sure the conversion between the client locale and database locale is possible. The database server locale can be different from the database client locale.
Refer to Setting the Database Client Locale for more details.
Step 4. Check the length semantics used by the database.
For example, with Oracle, the NLS_LENGTH_SEMANTICS=CHAR database option should be set, if the application uses CLS.
Refer to Multi-Byte Values for more details.
Step 5. With UTF-8, use the proper SQL character data type to store UTF-8 data: This data type might be different according to the type of database server.
Step 6. Define the
date, numeric and monetary formats using the DBDATE, DBMONEY, DBFORMAT
environment variables.
Refer to Date and Time Settings and Numeric and Currency Settings for more details.