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


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?

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


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

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.


[*] 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.


With regards to #2 *as is*...adopting those patches would break the tests on all other platforms. They could be modified to use #ifdef __CYGWIN__ and then maybe they'd be ok -- but that depends on #1 being merged first.

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


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