Bug#311259: error and omission in documentation of LANGUAGE
On Tue, Jun 07, 2005 at 10:30:16PM +0200, Denis Barbier wrote:
> Basically the LANGUAGE variable is a GNU extension to allow displaying
> messages in several languages, so that untranslated messages for your
> favorite language can be displayed with other languages than English.
> This is not a replacement for LANG; your environment must be setup
> correctly to display translated messages (which means that LC_MESSAGES
> and LC_CTYPE must be set and have compatible values).
> E.g. debian-installer sets
> LANG=nn_NO
> LANGUAGE=nn_NO:nn:no_NO:no:nb_NO:nb:da:sv:en_GB:en
> when Norwegian Nynorsk is selected, because Norwegian translators
> believed that most Norwegian users will prefer Danish or Swedish over
> English. This is fine because all these locales have the same
> ISO-8859-1 encoding.
> Now compare
> $ env - LANG=ja_JP LANGUAGE=de_DE cat -h
> cat: Ung«ältige Option -- h
> ,,cat --help¡È gibt weitere Informationen.
> $ env - LANG=fr_FR LANGUAGE=de_DE cat -h
> cat: Ungültige Option -- h
> ,,cat --help" gibt weitere Informationen.
> The latter works as expected, but the former does not because of encoding
> mismatch. In order to avoid such problems, LANGUAGE variable should almost
> be set under UTF-8 locales only. You can check that the some command
> with LANG=ja_JP.UTF-8 works fine.
>
> When LC_MESSAGES and LC_CTYPE are correctly set, LANGUAGE can contain a
> list of locale components, and gettext will check in turn all these message
> catalogs and return the first translation of this msgid. In fact, the
> initial example could be shortened to
> LANGUAGE=nn_NO:no_NO:nb_NO:da:sv:en_GB
> because message catalogs are also searched in xx after xx_XX.
Yes, I realize all this now. The bug is that I can't figure _any_ of
this out from the manual.
--
Daniel Jacobowitz
CodeSourcery, LLC
Reply to: