[PATCH] kernel32: Respect the LANG environment variable on Mac OS.

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

perhaps I should contribute to this thread given that I
indirectly triggered it via bug #20377.

IMHO Wine, due to its sandbox nature, needs a way to switch
   language/locale independently on the desktop settings.
Much like gcompris allows to choose a language other than the desktop's.
No discussion, the default should be the desktop setting.
So here, and in bug #20377, the issue is not the default setting.
The issue is how to depart from the default.

Now use LANG or LC_xyz to switch?

The MacOS Terminal.app (as of 10.5.8) sets/shows very few environment
variables.  LANG is among them, none of LC_xyz is.

Therefore I argue that LANG= is the canonical and reasonable choice for
a local override on MacOS.

It has the additional benefit of being
 + what Linux users are typically told to use (quick Google survey);
 + what the Wine Wiki recommends in http://wiki.winehq.org/TestingLanguages

What's the relationship between LC_xyz and LANG? The official answer for
programs using glibc is: "the library will
test the environment variables LC_ALL, LC_CTYPE, and LANG in that order"
But is glibc actually used on MacOS??

The Unicode FAQ says http://www.cl.cam.ac.uk/~mgk25/unicode.html
"The LANG environment variable is used to set the default locale for
all categories, but the LC_* variables can be used to override
individual categories."
So I don't understand the isolated recommendation of using LC_MESSAGES
in this thread.  My use-case is how to mimick a French, or Dutch, or Turkish,
or any Asian MS-Windows environment, without switching my desktop to any of
these (the "sandbox" idea again).  LC_MESSAGES is not enough AFAIK.

Ken Thomases writes:
>I see no upside at all to changing LANG into an override where that's  
>not how it functions in any other context.
I see no override involved here.  On my Mac OSX 10.5.8 which is pretty
much a base install, no LC_xyz is set.
Therefore LANG does not override any LC_xyz setting.
All I ask about LANG is that it overrides the desktop settings.
If any LC_xyz were set, I expect them to take priority over LANG,
like is documented and quoted above for glib and has been done for
years in Linux.

>Terminal (at least, recent versions) has a setting in its preferences
>to set the locale environment variables in shells it creates.  However,
>it really only sets LANG according to the Region selected on the Formats
>tab.  It does not set individual LC_* variables.  It completely ignores
>the user's preferred language.  
I fail to see the problem.  Only LANG is set, no LC_xyz therefore all UNIX
apps launched within Terminal.app (or at least the glibc-based ones)
should give a consistent answer, dictated by the LC_xyz/LANG defaulting rules.

Should the next Apple update have Terminal.app set LC_xyz instead of
LANG, I'd expect wine to obey them, because they take precedence over LANG.

So actually, my wish is that Wine follows the LC_ALL/LC_xyz/LANG defaulting
rules.  Currently it does not.
(I still need to check back on the Mac whether Wine follows LC_xyz).

>(e.g. Japanese language, U.S. formats)
Ken, is the use-case that you have in mind a Japanese user traveling
to the U.S. (Jap. language, U.S. region/format)?  Terminal.app sets LANG
to US which you believe is wrong?
My issue is not whether Terminal.app is broken or not. My issue
is that if LANG is set, it should be obeyed, so the user gets
consistent results (from a UNIX environment point of view).

Regards,
	Jörg Höhle