X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: sourceware.org
MIME-Version: 1.0
In-Reply-To: <4E6A2D0E.3030604@cwilson.fastmail.fm>
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>	<4E6A2D0E DOT 3030604 AT cwilson DOT fastmail DOT fm>
Date: Fri, 9 Sep 2011 21:08:17 +0100
Message-ID: <CAHWeT-b1vJ4Ryjv4MaR1DCAP3SoJ2h7kNpA67cOZ6iQU3iYhCA@mail.gmail.com>
Subject: Re: cygwin started speaking German today
From: Andy Koppe <andy DOT koppe AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id p89K8gEw014548

On 9 September 2011 16:13, Charles Wilson wrote:
> 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.

Thereby pre-empting a design decision that is duly Cygwin's. Again:
"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."

Besides, your proposal wouldn't work, due to the LANG=C.UTF-8 setting
in /etc/profile.d/lang.sh. And if lang.sh was changed to pick up the
Windows setting, libintl wouldn't need to muck about with Windows
APIs.

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

"Libintl is a library that provides native language support to
programs." It doesn that perfectly well without going against the
wishes of the platform maintainers. Users can choose a language by
setting LANG or LC_*, as documented in the Cygwin manual. In the
probably-soon-to-be-default "Cygwin Terminal", they can even choose
the locale in the options dialog.

> 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=*//

That's certainly a valid opinion. Please take it to cygwin-developers
and try to convince Corinna to change that decision.

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

True. Nevertheless there'll be complaints, and I can't remember any
demands for this. Then again, complaints would be easy enough to deal
with.

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

Maybe, but that's not Cygwin's problem to solve.

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

They do indeed usually default to the local language. This prompts
questions like these from some users:

http://askubuntu.com/questions/11601/command-line-tools-in-one-language-system-in-another
http://superuser.com/questions/235764/ubuntu-errors-in-terminal-how-to-show-them-in-english-language

> holding libintl hostage to cygwin misfeatures is not helpful.

And that's not a helpful statement.

Andy

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