bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] cygwin started speaking German today


From: Andy Koppe
Subject: Re: [bug-gettext] cygwin started speaking German today
Date: Fri, 9 Sep 2011 13:33:20 +0100

On 9 September 2011 10:18, Charles Wilson wrote:
> On 9/8/2011 5:44 PM, Bruno Haible wrote:
>> Find below a patch which ought to fix this. But it has upsides and downsides.
>> The upside: It treats LC_ALL, LC_$category, LANG consistently, like POSIX
>> wants it.
>
> Consistently, yes.  Correctly...no.  You said earlier:
>
> "Users who want to have a German Windows but a non-internationalized
> Cygwin can set LANG=C or LC_ALL=C - exactly like POSIX specifies."
>
> With your patch, this is /technically/ true: if I set LANG=C exactly,
> without the UTF-8 charset specifier, then yes -- I'll get english cygwin
> with german windows.  But, your patch explicitly ignores "C.UTF-8" -- so
> if I deliberately select the "C" locale with the "UTF-8" charset, I will
> get...the german locale.
>
> That can't be right.
>
> Now, the reason you're ignoring "C.UTF-8" is because you want to
> override cygwin's default locale setting -- which is implemented in two
> ways: #1, cygwin's internal code for 'setlocale(LC_blah, "")' returns
> that value, and #2, some older versions of the base-files startup
> scripts (/etc/profile, /etc/skel/.*, and the like) used to set LANG or
> LC_* IIRC.  However, they no longer do so

Actually, that is still done, in /etc/profile.d/lang.sh. It's for the
benefit of other programs who think they know better than the system
(emacs, I'm looking at you) by analyzing LC_* and LANG themselves
instead of relying on setlocale().


> Now, long term, I think what we will see is that some part of your
> suggestions here:
> http://cygwin.com/ml/cygwin/2011-09/msg00084.html
> will eventually be implemented in cygwin.  When that happens, libintl
> will have to change again.
>
> Until then, what?
>
> My suggestion for the "interim" libintl behavior is this:
>
> If /no/ relevant env vars are set
> then
>        if setlocale(LC_*, "") returns C.UTF-8
>        # which we know is the /current/ cygwin default locale
>        then
>                query Win32 API for "real" default locale
>        else
>                use what setlocale returns
> else
>        use the env var value; don't ignore 'C.UTF-8'
>        # if I have explicitly set LANG=C.UTF-8 then I must really
>        # really want the "C" locale, not en_US or de.

Please, no. As Corinna said: "Do NOT call Windows functions in Cygwin
libraries, unless the lib is doing something very special which isn't
provided by POSIX functions.  Only call POSIX functions.  Don't mix
the Cygwin and the Windows environment.  Please leave the interfacing
to the underlying OS the sole job of Cygwin."


>> The downside: It makes libintl_setlocale's behaviour diverge a little more 
>> from
>> Cygwin's setlocale behaviour.
>> Should I commit the patch or not?
>
> I don't think so.  What do you think about the algorithm above, at least
> for now, until cygwin's internal behavior is improved -- I tend to agree
> with Eric:
> http://cygwin.com/ml/cygwin/2011-09/msg00061.html
> "I'd argue that if none of LC_* or LANG are set, then
> setlocale(LC_BLA,"") should indeed return the system default, rather
> than being hard-coded to C. "
> and
> "I also agree with this sentiment - if setlocale(LC_BLA, "") is not
> returning sane results (that is, if there is a system default, but
> cygwin is not honoring those defaults), then the bug should be fixed in
> cygwin, not libintl."

The 'C.UTF-8' default locale is not a bug, it was a deliberate design decision.

Of course a good case can be made for picking up the Windows language
in case none of LC_* and LANG are set, but there are also obvious
arguments against: translations are usually patchy, i.e. you end up
with a mix of English and translations of varying quality, which a lot
of people hate.

Futhermore, Cygwin is mostly a command line environment, with commands
and options having English names, its userbase is probably even more
geeky than that of your average Linux distribution, and Cygwin's
homepage and setup program are English-only anyway. Hence it doesn't
seem likely that defaulting to English is keeping a lot of users away.

Nevertheless, I'm on the fence on whether the default should be
changed, but I certainly agree with Eric in that any such change
should be implemented in the Cygwin DLL rather than in particular
packages.

Andy



reply via email to

[Prev in Thread] Current Thread [Next in Thread]