From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1284 invoked by alias); 17 Oct 2011 13:17:05 -0000 Received: (qmail 1267 invoked by uid 22791); 17 Oct 2011 13:17:04 -0000 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 Received: from out5.smtp.messagingengine.com (HELO out5.smtp.messagingengine.com) (66.111.4.29) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Oct 2011 13:16:44 +0000 Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C61212026E for ; Mon, 17 Oct 2011 09:16:43 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 17 Oct 2011 09:16:43 -0400 Received: from [192.168.1.3] (50-88-210-98.res.bhn.net [50.88.210.98]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7120948346A; Mon, 17 Oct 2011 09:16:43 -0400 (EDT) Message-ID: <4E9C2AB0.50107@cwilson.fastmail.fm> Date: Mon, 17 Oct 2011 13:17:00 -0000 From: Charles Wilson 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@cygwin.com Subject: Re: cygwin started speaking German today References: <20111004142920.GA15757@calimero.vinschen.de> <4E8B4A86.5000607@xs4all.nl> <20111004182042.GA22299@calimero.vinschen.de> <4E8C7FFB.6060707@xs4all.nl> <20111005162714.GA14661@calimero.vinschen.de> <4E8C948D.4070707@cwilson.fastmail.fm> <4E8CA0AF.50805@cornell.edu> <20111010172328.GF30156@calimero.vinschen.de> <4E9474CA.7080408@cwilson.fastmail.fm> <4E9B2585.1000409@cwilson.fastmail.fm> <20111017065904.GB30527@calimero.vinschen.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@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-10/txt/msg00318.txt.bz2 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 > 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 > > > 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