Mail Archives: cygwin/2011/10/17/09:17:15
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
- Raw text -