From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18768 invoked by alias); 9 Sep 2011 09:18:55 -0000 Received: (qmail 18756 invoked by uid 22791); 9 Sep 2011 09:18:54 -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 out4.smtp.messagingengine.com (HELO out4.smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Sep 2011 09:18:37 +0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0940721202; Fri, 9 Sep 2011 05:18:36 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 09 Sep 2011 05:18:36 -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 9D35F760258; Fri, 9 Sep 2011 05:18:35 -0400 (EDT) Message-ID: <4E69D9EA.2050004@cwilson.fastmail.fm> Date: Fri, 09 Sep 2011 09:18: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: Bruno Haible CC: cygwin@cygwin.com, bug-gnu-gettext@gnu.org Subject: Re: cygwin started speaking German today References: <7856072A9D04C24B82DFE2B1112FE38A0C27492B56@MCHP058A.global-ad.net> <201109081246.23238.bruno@clisp.org> <4E68AF35.9030002@cwilson.fastmail.fm> <201109082344.55506.bruno@clisp.org> In-Reply-To: <201109082344.55506.bruno@clisp.org> Content-Type: text/plain; charset=UTF-8 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-09/txt/msg00094.txt.bz2 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. 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. > 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." -- 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