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