From:	"Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Organization:	Darmstadt University of Technology
To:	jeffw AT darwin DOT sfbr DOT org
Date:	Tue, 7 Aug 2001 22:01:21 +0200
Subject:	Re: gettext port
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<20010807100514.A11378@kendall.sfbr.org>
References:	<378E2A966FC AT HRZ1 DOT hrz DOT tu-darmstadt DOT de>; from ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De on Mon, Aug 06, 2001 at 07:22:00PM +0200
X-mailer:	Pegasus Mail for Windows (v2.54DE)
Message-ID:	<3938B62211A@HRZ1.hrz.tu-darmstadt.de>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 7 Aug 2001 10:05:14, JT Williams wrote:
> -: +LANG=CP437
> -: +LANGUAGE=de
>    ^
>
> This does the trick; `sed --version' now displays text correctly
> in de, sv (the only ones I tried) using cp437 (and cp850).  Thanks!
>
> So, if I understand this correctly, when I set LANG=de it was effectively
> like setting LANG=ISO-8859-1 (because the de text was prepared with that
> codepage)?  So I was telling NLS that my current codepage was ISO-8859-1
> when it was not?

No, this is wrong.
The LANGUAGE variable selects the catalog (.mo files) containing the translated
strings that shall substitute the original english strings contained in the binary.
But this translated strings shall not be displayed with the charset used to write
them (in the case of `de' this was ISO-8859-1, an unix charset). They shall be
displayed with the appropiate locale charset. This locale charset (in our case the
appropiate dos codepage) is defined by the value of LANG.
To make this clear: on DOS/WIN95/DJGPP the value of LANG will be the appropiate
codepage to display the translated strings. Of course, there is no need to set LANG
to a codepage, an valid alias is always allowed. The possible aliases are translated
to the corresponding codepage with the aid of charset.alias.
Some examples:
LANG=de
LANGUAGE=de:es
This displays german translations using CP850, because LANG=de=CP850 (from charset.alias)
charset.alias is a table with two entries: left entry is the alias (en_US, de_AT, etc.)
right entry is the corresponding dos codepage for that language code (alias).
If certain string of the binary has no german translation then and only then the spanish
string will be displayed but using the same codepage (LANG is still de=CP850; this is not
dramatic in this particular because es=de=CP850). If a spanish translation for that string
can not be found then the original english string contained in the binary will be displayed
using CP850 once again.

LANG=en_US
LANGUAGE=de:es
This will do the same than before but this time using CP437 as locale charset (dos codepage)
because en_US=CP437

In conclusion:
LANGUAGE selects the translations to be used.
LANG selects the codepage that will be used to display the translations.
Because libiconv.a needs the information about what locale charset shall
be used, if LANG is omitted by the user LANGUAGE will be ignored and no
translation will be done at all.


The reason for all this confussion is the poor quality of my readme file.
Next version will explain better what the function of LANG and LANGUAGE is.

Regards,
Guerrero, Juan Manuel

- Raw text -