Re: gettext

[Bruno Haible]

Vlada von Strasnic writes:

> LANG | LC_ALL  | LANGUAGE | setlocale | translated | force cs_CZ | force de
>  --      --         --          C          no            no          no
>  --    cs_CZ        --        cs_CZ       into cs        yes         yes
>  --    en_US        --        en_US        no            yes         yes
>  --    de_DE        --        (null)       no            no          no
>  --    de_DE        de        (null)       no            no          no
>  --     sk          de         sk         into de        yes         yes
>  --      --         cs          C          no            no          no

I can confirm that this is how gettext is meant to behave.

> What this means ??
> 1) i hoped LANGUAGE has higher priority then anything , but this shows it's
>    not true. It's enough to set some lower priority LC_anything to illegal 
> string
>    and LANGUAGE loses 

I agree that it's maybe a bit surprising, but its very clearly
documented in the ABOUT-NLS:

   GNU `gettext' gives preference to `LANGUAGE' over `LANG'
   for the purpose of message handling, but you still need to have `LANG'
   set to the primary language; this is required by other parts of the
   system libraries.

> 2) gettext doesn't work even when LC_* are unset . Because it cannot be forced
>    to other language - line 1 and the last one !! Isn't that bug ?

This too may be a bit surprising, but it's required for POSIX
compatibility of all the many applications that use gettext. POSIX
requires that when the locale is "C" many programs have their output in a
particular form in English, without translation.

> 3) my system doesn't seem to understand de_DE . During mandrake instalation
>    i choosed just en,cz,sk . It means that locale/de/* doesn't contain all 
> that
>    monetary,ctime,numbers stuff.  But locale/de/LC_MESSAGES/* exist !!!!
>    But gettext is refusing to work . Why ?? I think that catalogs should be
>    enough to work .

gettext()'s return value could either depend on the environment
variable values or on the value of setlocale(LC_MESSAGES,NULL). On
glibc systems, where setlocale can be trusted, we have chosen to make
gettext() look at the return value of setlocale(LC_MESSAGES,NULL),
because it allows applications to change the locale of the program or
thread and have gettext() behave accordingly - requiring that the
program also changes the environment variables would be an annoyance.
Especially in glibc 2.3 or 2.4, where each thread can have its own
locale but not its own set of environment variables.

> Other programs works exactly the same way. I previously said they don't work
> at all. That was probably by several accidents that probably joined together

Thanks for telling us. It is reassuring.

>         1) it's not obvious for beginner that state of $LANGUAGE is not
>                 reflected in output of locale(3) .. So month ago, when i
>                 verified my tests with locale, i had no chance to recognize 
>                 the reason. ( i had LANGUAGE=en_US , but diagnostic program
>                 didn't tell  - maybe it should be considered a bug )

I'm submitting a change for the locale(7) manpage.

>         2) my test were usually executed in new shell, so everytime i spawned
>                 new xterm , it had executed my .bashrc and ... 

.bashrc is executed by all interactive bashs, whereas .profile is
executed only by the login shells. For this reason, environment
variable settings go into .profile and functions+aliases go into
.bashrc.

Bruno