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

[Gert van den Berg]

On Wed, Dec 2, 2009 at 22:52, Ken Thomases <ken at codeweavers.com> wrote:
> On Dec 2, 2009, at 1:22 PM, Gert van den Berg wrote:
>> As far as I can figure out, no LC_* variable, except LC_ALL specific
>> the actual locale? They only determine individual settings, which
>> overwrites the default for the locale, as set by LANG? (Not sure if it
>> effectively means set everything to LANG's locale, overwrite
>> individual settings from LC_* if they are defined)
>
> I'm not sure what you mean here.  Are you referring to the general Unix
> meaning of these variables or Wine's use of them?

General *nix meaning.

What I meant is that LC_* (not LC_ALL) don't have a setting that says
"the locale is say en_ZA" it only has we have number (LC_NUMERIC) from
en_ZA, times (LC_TIME) from en_UK, sort things (LC_COLLATE) according
to en_AU, determine whether something is a letter / number and how to
change their case (LC_CTYPE) according to UTF-8, ect. LANG is only
setting that really maps to Wine / Windows' sCountry and Locale
settings. (if all LC_* variables are set, LANG only determine things
not in any of the LC_* variables) LC_* does not have anything to
determine the actual UI language either.

What I meant above, is that you should be able to get the equivalent
effect (to the POSIX default) by setting everything to LANG's setting
and then changing them from the LC_* variables. E.g. if LANG is fr_FR
(not sure if that is an actual name) and LC_TIME is en_US, set
environment up for French, change settings affected by LC_TIME to US
English. Setting LANG to French and all individual settings to en_US,
shoulld reslut in a system where the country is France, Locale code is
0x040c, UI is French, but date / time / number / currency settings,
etc. is that of en_US.

Considering how OS X seem to set variables, that might work as well...
My interpretation of your proposed logic for OS X: Set up everything
to OS X setting, overwrite everything if LANG is set, overwrite
further settings from LC_*, overwrite everything from LC_ALL if that
is set. (the slow unoptimized way that might result in some settings
being overwritten 4 times before settling on a value...)

Resulting order:
LC_ALL
LC_*
LANG
OS X settings.

> As near as I can tell, Wine only probes the locale information by invoking
> setlocale(<category>, NULL).  It doesn't directly examine the environment
> variables.  Furthermore, it only queries using the individual categories,
> not LC_ALL.  It uses setlocale(LC_ALL, "") once to tell the C library to
> initialize itself from the environment.
>
> So, I'm not sure how setting all of the LC_* variables to a given value can
> be different from setting LC_ALL to that value.
>

Interpreting it as above, settings LC_ALL is equivalent to setting all
LC_ variables and setting LANG to LC_ALL's value.

>>> If one of the LC_* variables are set, that expresses user intent (because
>>> those variables are not set by Terminal.app automatically).  Also, it is
>>> useful to allow the user to override the System Preferences on a
>>> category-by-category basis.
>>
>> Mine gets set to C / UTF-8(for LC_CTYPE) of some reason...
>
> Maybe Terminal.app is setting LC_CTYPE when it can't set LANG.  Check what's
> actually set in your environment:
>
> env | egrep "^(LANG|LC_)"

Sorry, only LC_CTYPE is actually set, to UTF-8. (form the locale
command's output one would think that it does the same, which it
obviously doesn't)

Looking at the current values, your order for OS X makes sense. If the
actual effect is similar to the result of the overwriting above, you
can overwrite settings as in *nix, but OS X's ones are used by
default. (Not sure what it will do if OS X actually knows your
locale?)

Gert