Re: gettext

[Vlada von Strasnic]

Yea, what is the connection between gettext & locale (or what can be).
- they can be either completely seperated  ( that's not true )
- they can be joined together and look inseparable ( also not true )
- they can cooperate 
- or the cooperation is just in one direction ( one serves to the other )
( but the cooperation can be either good or bad )  
  
Look at the table below and realize, what i have to do if i want to
translate messages to german.
( -- , de ) is not enough for any language ( especially no for german ).
               This is faulty IMO , but i can live with it.
( de , -- ) doesn't work because setlocale returns null  .... no comment
( de , de ) doesn't work for same reason
( sk , de ) this is only variant that works  ( (en,de),(cz,de) works also )

Maybe this behaviour is correct according to POSIX. But it's
counter-intuitive, and therefore useless. In one word shit,shit,shit!!!

I (and many others) think that POSIX compliance is just a label - some
sort of marketing label - that is presented to user in the way, hey
we can be P.c. but it's defaultly switched off during configure .

Once you decide, that cooperation of locale & gettext is unidirectional,
then eg. locale(1) shouldn't examine LANGUAGE variable. 
( because it's gettext variable )

But also if gettext can work without using services from locale, then
i feel that current behaviour is not right. ( There is probably smaller
number of system's where setlocale can be trusted then you thought )

HiS.

And finaly several questions more : Wherre can i found listing of all
possible categories. This is taken from mandrake /etc/profile :

man locale - just 6 basics categories
info libc  - again just those 6

locale(1) ouput - 12 categories

Where is some documentation what they mean and how they are used
and what can be in eg. /usr/share/locale/en/LC_TELEPHONE and how
can i set it.





On Thu, Apr 25, 2002 at 01:58:02PM +0200, Bruno Haible wrote:
> 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.
> 
You don't know how it was reassuring for me.

> >         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.
> 
Yes, thank's. It really solves this part of my previous troubles.