Message-ID: <4E6A2D0E.3030604@cwilson.fastmail.fm>
Date: Fri, 09 Sep 2011 11:13:18 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cygwin started speaking German today
References: <7856072A9D04C24B82DFE2B1112FE38A0C27492B56 AT MCHP058A DOT global-ad DOT net>	<201109081246 DOT 23238 DOT bruno AT clisp DOT org>	<4E68AF35 DOT 9030002 AT cwilson DOT fastmail DOT fm>	<201109082344 DOT 55506 DOT bruno AT clisp DOT org>	<4E69D9EA DOT 2050004 AT cwilson DOT fastmail DOT fm> <CAHWeT-bQ=Qm7qyWzb9s-=Lfgwjh-vHrEk2BvYQS6X6707+EWMg AT mail DOT gmail DOT com>
In-Reply-To: <CAHWeT-bQ=Qm7qyWzb9s-=Lfgwjh-vHrEk2BvYQS6X6707+EWMg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On 9/9/2011 8:33 AM, Andy Koppe wrote:
> On 9 September 2011 10:18, Charles Wilson wrote:
>> #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().

Ahh, I did 'grep' not 'grep -r'.  Oops.

>> 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."

"In the interim".  That is, until cygwin itself is prepared to DTRT,
allow libintl to pick up the slack.  That's the only way I can see to
satisfy both the mandates of cygwin (hide win32 from posix apps) and
libintl (provide the most natural i18n experience to all users
regardless of platform or language).

It boils down to the following: cygwin made a decision -- incorrectly
IMO -- to explicitly set the default language/locale to "C", rather than
allowing the system defaults, as established via the Regional Settings,
to control i18n behavior //when the user has not specifically requested
something else, for cygwin, via LANG=*//

Now, this might make sense in that it would allow old cygwin
English-only installations to *keep* being english-only, without
positive action from existing users.  But, I doubt German-speakers, with
Regional Settings set so that all pure-win32 progs speak German, would
be hampered if cygwin suddenly started speaking German, too.  Surprised,
maybe, but not hampered.

Ideally, cygwin will revisit this decision and add functionality to
"translate" the win32 regional settings into appropriate setlocale(LC_*,
"") behavior.

But...*until that time*...it makes sense as a temporary measure to allow
libintl to step in.

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

If you have to hardcode a specific locale, then picking "C" -- and
forcing the UTF-8 charset -- is a good idea.  But...we don't *have* to
pick a single hardcoded locale.

> 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.

So...because of bugs in the the translations of program X, Y, and Z, we
should default to a "foreign" language (English) rather than expose
those poor translations, or fix them?  Isn't this just papering over the
problem?

What do the linux distributions do?  Ignore language settings chosen in
the Installer GUI, and force Chinese users to use English?  Somehow I
doubt that.

> 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.

I agree, but that doesn't mean we shouldn't be sensitive to i18n
concerns.  If somebody has set Windows' Regional Settings to specify
German, then...they really ought to get German everywhere possible.  If
the apps shipped with cygwin have such bad translations that it becomes
annoying, then they can *explicitly* set LANG= to force English.

(Right now, libintl deliberately ignores LANG if it is set to "C.UTF-8".
 That's too aggressive, and needs to change; libintl should always
respect the $ENVVARS).  If cygwin continues to, by default, force an
explicit LANG= setting (e.g. /etc/profile.d/lang.sh's:
test -z "${LC_ALL:-${LC_CTYPE:-$LANG}}" && export LANG=C.UTF-8

...well, that's cygwin's choice, and libintl shouldn't try to override
/THAT/ by deliberately ignoring LANG/LC_* when they happen to be set to
the magic string "C.UTF-8".

> 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.

I agree -- *eventually*.  The question is, what to do *until then*.
It's obvious the current libintl behavior needs to change. Right now, it
is too aggressive (it explicitly ignores LANG=C.UTF-8); with Bruno's
proposed change it is even MORE aggressive: it explicitly ignores
{LANG,LC_*}=C.UTF-8).

My suggestion would continue previous cygwin behavior (that is,
cygwin+libintl 0.17), *unless* we also change base-files
/etc/profile.d/lang.{sh,csh}.  I would advocate that we DO change
lang.{sh,csh}, but that's a different argument.

If cygwin's default-locale behavior is improved, at that point
/etc/profile.d/lang.{sh,csh} *must* change -- probably to something like:

test -z "${LC_ALL:-${LC_CTYPE:-$LANG}}" && export LANG=$(locale -u -U)

which IIRC does exactly what libintl does now: queries the Windows
Regional Settings. Anyway, at that time we can also further change
libintl -- that is, make libintl pure posix again.

But holding libintl hostage to cygwin misfeatures is not helpful.

--
Chuck

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple