X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW
X-Spam-Check-By: sourceware.org
Message-ID: <4E9C2AB0.50107@cwilson.fastmail.fm>
Date: Mon, 17 Oct 2011 09:16:32 -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: <20111004142920 DOT GA15757 AT calimero DOT vinschen DOT de> <4E8B4A86 DOT 5000607 AT xs4all DOT nl> <20111004182042 DOT GA22299 AT calimero DOT vinschen DOT de> <4E8C7FFB DOT 6060707 AT xs4all DOT nl> <20111005162714 DOT GA14661 AT calimero DOT vinschen DOT de> <4E8C948D DOT 4070707 AT cwilson DOT fastmail DOT fm> <4E8CA0AF DOT 50805 AT cornell DOT edu> <20111010172328 DOT GF30156 AT calimero DOT vinschen DOT de> <4E9474CA DOT 7080408 AT cwilson DOT fastmail DOT fm> <4E9B2585 DOT 1000409 AT cwilson DOT fastmail DOT fm> <20111017065904 DOT GB30527 AT calimero DOT vinschen DOT de>
In-Reply-To: <20111017065904.GB30527@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

On 10/17/2011 2:59 AM, Corinna Vinschen wrote:
> On Oct 16 14:42, Charles Wilson wrote:
>> 2) Fixes to the test suite related to the above changes.
>>
>> 3) Adopted Bruno's upstream changes to relocatable.c, turning off
>> "expensive" relocation support in libintl.
>>
>> Odds of #1 and #2 being adopted upstream are effectively nil, so...
>
> I don't understand this.  It's very clear that the former, unfixed
> behaviour is totally wrong for Cygwin, especially in terms of the
> used charset.  I don't see why doing the right thing, using less special
> cases for Cygwin in gettext/libintl should be unacceptable for upstream.

As for #1, I doubt Bruno would accept those changes upstream until we 
address his four points, because (I think) he is claiming that current 
(e.g. prior to my patch) libintl DOES do all of these things, and he'd 
view my change as breaking all four of them.

Bruno Haible wrote:
> OK, then the following four facilities are needed in Cygwin.
>
> 1) We need the name of the locale which is in effect when the user has
>    not specified environment variables.
>
>    Either through option a) above [*]. Programs can then do getenv ("LANG").
>    Cygwin documentation <http://www.cygwin.com/cygwin-ug-net/setup-locale.html>
>    currently says "The default locale in the absence of the aforementioned
>    locale environment variables is "C.UTF-8"." This would have to change.
>
>    Or through option b) above [**]. Programs can then peek at the return
>    value of  setlocale (LC_ALL, "").
 >
 >    Or through an API function that calls GetUserDefaultLCID() and
 >    converts that to a glibc style locale name (e.g. "zh_CN.UTF-8")
 >    or to an RFC 3066 style locale name (e.g. "zh-Hans").
 >

Option (b) has already been rejected.  Option (a) might be doable, via 
/etc/profile.d/lang.{sh,csh} + locale.exe.  But this re-opens the 
can-o-worms; what's changed since we decided that "default" user 
experience (which is distinct from cygwin::setlocale's default behavior) 
should be C.UTF-8?

> 2) We need the name of the locale of the current thread.
>
>    Either through a function newlocale(), as in POSIX.
>
>    Or through an API function that calls GetThreadLocale() and
>    converts that to a glibc style locale name (e.g. "zh_CN.UTF-8")
>    or to an RFC 3066 style locale name (e.g. "zh-Hans").
>
>    Locale per thread is mainly needed for web application servers,
>    not for GUI programs.

We need an implementation of newlocale, if we want to address this 
problem and stay "posixy".

> 3) Gettext needs the priority list of languages, if the "Regional Settings"
>    panel can specify it. MacOS X has this setting customizable, I don't know
>    whether newer Windows versions have it has well.

I don't understand this.  cygwin either does or does not support any 
give language -- and the list is pretty comprehensive, so the odds of 
"does not" is pretty low.  Unless he's talking about a per-application 
basis: "I don't have an .mo file for german, but the user has indicated 
they ALSO speak french, and I DO have an .mo file for fr_FR, so I'll use 
that -- even though LANG="de_DE"?

That seems pretty anti-posix...

> 4) Programs that do number or date/time formatting will need to access the
>    values that the user has specified. E.g. those set in
>    <http://www.sisulizer.de/_img/codepage-problems/codepage-regional.jpg>
>    <http://pc-error-free.com/blog/wp-content/uploads/2008/12/regional-settings.gif>
>    <http://www.sisulizer.de/_img/codepage-problems/w7-regions-and-languages-formats.jpg>

I guess this is talking about two different things: (1) locale.exe -s 
needs to check the win32 date/time settings when computing the proper 
value of "-c LC_TIME", and (2) *applications* would also need an ability 
to grab the *custom* date/time formatting strings from the relevant 
windows settings -- probably via a special cygwin interface.

[*] Bruno's "option a"
>   a) The system can set environment variables that reflect the regional
>      settings. For example, if the user has chosen German, Cygwin's
>      login process could set LANG to de_DE.UTF-8.
>
>      This approach is used in Linux desktops like KDE.

[**] Bruno's "option b"
>   b) The system's setlocale() function can, when the second argument is
>      the empty string and the respective environment variables don't
>      specify anything, fetch the value from the "Regional settings"
>      panel.
>
>      Cygwin could do that.


With regards to #2 *as is*...adopting those patches would break the 
tests on all other platforms.  They could be modified to use #ifdef 
__CYGWIN__ and then maybe they'd be ok -- but that depends on #1 being 
merged first.

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