This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin started speaking German today

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

> >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/ and lang.csh is about.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]