From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11373 invoked by alias); 17 Oct 2011 13:52:39 -0000 Received: (qmail 11318 invoked by uid 22791); 17 Oct 2011 13:52:13 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Mon, 17 Oct 2011 13:51:55 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id DC1962CBDA0; Mon, 17 Oct 2011 15:51:52 +0200 (CEST) Date: Mon, 17 Oct 2011 13:52:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: cygwin started speaking German today Message-ID: <20111017135152.GB908@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <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> <4E9C2AB0.50107@cwilson.fastmail.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E9C2AB0.50107@cwilson.fastmail.fm> User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00319.txt.bz2 On Oct 17 09:16, Charles Wilson wrote: > 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. If he claims that, he's wrong. Look, Cygwin was (most of the time) running in UTF-8 mode. Did anybody complain before that his or her libintl running apps were using the wrong codeset when LANG was set to "xyz.UTF-8"? I don't see that. Only with 0.18.1.1 libintl suddendly started to set the charset to ISO-8859-1 for some people, even though LANG was set to some "xyz.UTF-8". This is a very clear breakage of Cygwin, and former versions of libintl did not do that. Or, did they? Even *if* they did that, it's stll breaking Cygwin application's localization, so it's clearly a bug in libintl. > > 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? This is not correct. On Linux, the default locale is "C" or "POSIX", unless LANG or LC_xxx is set to something else. And that only happens if the startup script reads /etc/sysconfig/i18n and/or ~/.i18n. Cygwin behaves the same, except that the default locale is "C.UTF-8", unless LANG is set to something else in /etc/profile.d/lang.sh or in some user defined profile. > >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". Right now we don't need the locale of a single thread at all, because Cygwin doesn't support this. A Cygwin application must not call SetThreadLocale since the locale will not be reflected by the POSIX locale settings in Cygwin. As soon as Cygwin supports per-thread locales, a newlocale function will be available of course. http://cygwin.com/acronyms/#SHTDI. > >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... Yup. You can give him the list provided by `locale -av' and `locale -m'. This should give him a good idea what languages and codesets are supported by Cygwin. It should *especially* show him that Cygwin's default codeset for a language given by, say "LANG=de_DE" is *not* the default Windows codepage for that language. For instance, the default codeset for uk_UA is KOI8-U, as on Linux, not CP1251. > >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. The problem is that Bruno tries to impose Windows over Cygwin. That's not what Cygwin is about. Why can't he accept that? > [*] 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. That's what /etc/profile.d/lang.sh and lang.csh is about. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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