cygwin started speaking German today

[Charles Wilson]

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