Loading...
 

Location-specific data (Locales)

Location-specific data (locales)

Locale data(Locales) manage regionally dependent values:

  • Country, Region
  • Language
  • currency symbol
  • Display of numbers, date, time, amounts of money
  • Time zone
  • Summer / winter time (daylight saving time)
  • Information and rules on the structure of telephone numbers
  • Information on specific calendar days (public holiday, working day, anniversary, date)

They are represented by the following classes:

Class names and short descriptions of the CX_LOCALE classes

CX_COUNTRY_LOCALE

A CX_COUNTRY_LOCALE object is used to manage all information for a country (nation state): e.g. Germany, United Kingdom, United States of America, etc. The coding is numerical in the field countryCode according to ISO 3166-1. The field localeCode is alphanumeric according to ISO 3166-1 ISO 3.

CX_STATE_LOCALE

A CX_STATE_LOCALE object describes the largest entity within a country (federal state for Germany, canton in Switzerland, state in the USA ...). It is directly subordinated to a CX_COUNTRY_LOCALE object.
State Locales are e.g. for Germany the federal states of Bavaria, Baden-Württemberg, etc. (coded according to the Official Municipality Code (AGS); for the United States of America, e.g. the states of Massachusetts, California, etc.


CX_LOCALE

This locale is used for further subdivision of CX_STATE_LOCALE or other CX_LOCALE objects. Any depth of nesting and thus subdivision is possible. Thus a hierarchy can be built up down to city, district, street, building or even office level. As a rule, data of regions are managed in a CX_LOCALE object.

The own company is usually also represented as a CX_LOCALE object, e.g. to store the telephone data (central number, number of extensions, number for getting an outside line, etc.) or other infrastructure data. It can also be useful to extend the subdivision even to individual departments of the company in order to define which days are working days in which departments: For example, in production (in some weeks), Saturday and Sunday should be considered working days (necessary information for automatic capacity planning), whereas this should not apply to administrative staff.

Subordinate locales can inherit values that they do not define themselves from the parent locale(s).

The hierarchy of these classes is shown in the following figure:

cxlocale.png

CX_HOLIDAY
Each locale object can use objects of class CX_HOLIDAY to define properties of certain calendar days (public holiday, holiday day, ...).

CX_DIALLING_RULE
Each locale object can use objects of class CX_DIALLING_RULE to format telephone numbers (filtering of country or area code, ...).

Managing and saving the locale information

The distinction between universal and custom locales was abandoned. A user can extend and change all locales. Locales modified by the user are stored separately from the locales provided by ClassiX®.
Locales are always saved as XML files, whereby the locale objects can be extended with further information (slots).
Persistence of locales - saving in the database - has been abandoned.
Loading locales from the LOCALES.TXT file is still supported for backward compatibility.

For loading the locales at the start of the ClassiX® system or via methods like CX_SYSTEM_OBJECT::GetAllLocales these priority rules apply:

- search for the file defined with CX_LOCALE_FILENAME. Default value is CustomLocales.xml
- search for locales.xml
- search for locales.txt

Search in the system folders - starting with the most project-specific.

Locales edited by the user are saved with CX_MASTER_LOCALE::StoreXML.

The environment variables CX_COUNTRY, CX_STATE and CX_REGION

When the machine is started, a locale can be specified. For this purpose the desired locale must be specified via environment variables. This is done via the three keywords described below.

For example, if the region "002" (Hamburg Altona district) in the state "006" (Hamburg) of the state "049" (Germany) is to be selected, the following environment variables must be set:

CX_COUNTRY=049

CX_STATE=006

CX_REGION=002

(Of course these locales have to be defined - see above!)

The value for a country (CX_COUNTRY) and a state (CX_STATE) can be between 0 and 255, but the coding for a region can be any length, as the nesting of regions is not limited. The individual region codes are numerical and are separated from each other by a ';'. If, for example, the region "004" (Hamburg Blankenese) is to be selected within the above mentioned region "002" (district Hamburg Altona), the entry for the environment variables looks like this:

CX_COUNTRY=049

CX_STATE=006

CX_REGION=002;004

If only state or federal state information is to be loaded, no CX_REGION details need to be entered. If none of the keywords is specified, the country information of the computer is used to load the corresponding country (if defined).

After starting the system, any location information can be reloaded with the function SetLocaleByName. With the function CreateSublocales the locale hierarchy can be rebuilt starting from a certain locale.