From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14765 invoked by alias); 9 Sep 2011 15:13:45 -0000 Received: (qmail 14746 invoked by uid 22791); 9 Sep 2011 15:13:43 -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 15:13:22 +0000 Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 94A3E28613 for ; Fri, 9 Sep 2011 11:13:21 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 09 Sep 2011 11:13:21 -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 3D69B760274; Fri, 9 Sep 2011 11:13:21 -0400 (EDT) Message-ID: <4E6A2D0E.3030604@cwilson.fastmail.fm> Date: Fri, 09 Sep 2011 15:13: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: <7856072A9D04C24B82DFE2B1112FE38A0C27492B56@MCHP058A.global-ad.net> <201109081246.23238.bruno@clisp.org> <4E68AF35.9030002@cwilson.fastmail.fm> <201109082344.55506.bruno@clisp.org> <4E69D9EA.2050004@cwilson.fastmail.fm> In-Reply-To: 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/msg00101.txt.bz2 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