Next: , Previous: Gcal Utilities, Up: Top


Appendix C Aspects in Internationalization

Starting with version 2.00, Gcal is able to display message texts using any native languages instead of using the English language only, because parts of the GNU gettext package are integrated into the Software. See Introduction, for more details.

By default, Gcal displays all message texts using the English native language in case no other native language is wanted. A so-called message catalog is read by Gcal at run-time if message texts from another native language are required. Gcal 3.6 supports the following native languages:

Native Language Language Code

English en
German de
French fr
Dutch nl
Polish pl
Russian ru
Swedish sv

It is only necessary to set one of the environment variables1:

1. LANGUAGE
2. LC_ALL
3. LC_MESSAGES
4. LANG

with a language code to select another native language instead of the English native language.

Normally, users only have to set the LANG environment variable to tell Gcal the native language to use at run-time level. Presuming users want to run Gcal using the German native language for displaying message texts, they merely have to execute ‘setenv LANG de (in csh) or ‘export LANG; LANG=de (in sh) at the shell prompt. Of course they could even do this from their .login or .profile file. See The User's View, for more details.

As shown above, a simple setting of de in the environment variable LANG is sufficient to enable German message texts. de is the two-letter language code for the German language defined in the ISO-639:1988, and is called simple language code information in the further context. Other language codes can be taken from this ISO-document2.

Because Gcal as calendar program must also comply the specifics of a used native language concerning the ordering of day, month and year (and further things) of a displayed date, the period of Gregorian Reformation, the type of week number and the representation of calendar sheets, these criteria are likewise bound to the language code3.

A en language code causes the following internal defaults of above criteria:

And a de language code4 causes the following internal defaults:

Remember, all these internal defaults are modifiable by the options --date-format, --gregorian-reform, --starting-day, --iso-week-number and --type.

If no language code is detected, Gcal takes the internal defaults of the en language code5.

If a language code is specified for which no message catalog is installed, Gcal takes the internal defaults of the de language code, but displays the message texts using the English native language. Actually, this behavior seems to me the most proper solution in such a case. The English native language is spoken all over the world unlike the German or other native languages, so it is wise to use it here. But the other criteria bound to the English native language are so special for users of other native languages, that it is wise to use the criteria taken for internal defaults of the de language code, because most European countries (taken as standard) essentially use them.

Now British users will certainly ask whether they could use their date format as an internal default6. The answer to this is a simple yes, nevertheless, these users have to set the environment variable LANG with an extended language code information instead of a simple language code information.

The usual template of an extended language code information is as follows:

Both syntaxes contain the language and territory components, which are used by Gcal to select the native language and the other criteria. The language component is equivalent to the simple language code information and the territory component is a two-letter territory or country code as defined by the ISO-3166 like ‘GB’ for Great Britain or ‘US’ for the U.S.A. See the pertinent literature for more details. So British users only have to set the LANG environment variable with a en_GB contents, and after that, they can use the British date format as an internal default.


Footnotes

[1] Listed in decreasing priority as they are respected.

[2] For example fr for French, es for Spanish...

[3] Strictly speaking, an extended language code information.

[4] Or other language codes, for which a message catalog will be created and distributed in future.

[5] Or to be more precise, of the extended language code information en_US.

[6] All other internal defaults of the simple en language code information just meet their criteria.