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

[Gert van den Berg]

On Tue, Dec 1, 2009 at 06:12, Ken Thomases <ken at codeweavers.com> wrote:
> On Nov 30, 2009, at 9:34 PM, James McKenzie wrote:
>>
>> The idea behind most of the MacIntosh 'magic' is that the user is
>> deliberately oblivous to this.
>
> I agree that Wine (well, anything) should meet the user's expectations without the user having to even be aware of their expectations.  Unfortunately, "respecting" LANG does not lead to this...

An important question is: Which environment should Wine emulate under
OS X? Unix apps under OS X, Windows in the same locale as OS X or OS
X-native apps?

(I tend to prefer emulating OS X by default and allowing overrides
using LC_ALL (in order to allow one override method on all platforms,
which LANG is unsuitable for, since it is a last resort option))

In addition Wine should leave the registry settings alone if the
settings on which they were based were left unchanged. This allows a
user to fully customize Wine's "regional settings" without changing
anything in the environment where Wine is run.

>>  I just ran the set command in a
>> terminal.app session, of which I have several running right now, and it
>> was set to en_US.utf8, which is what I expect because the 'American'
>> flag is displayed in the top information bar (also called the 'Apple'
>> bar.)  Gert may want to run the set command in a terminal session and
>> given what was said, the LANG setting should be en_ZA.utf8, which is
>> what I expect for South African English.
>
I'm paste it in here soon... My Ubuntu settings is:
mohag at mohagpc:~$ locale
LANG=en_ZA.UTF-8
LANGUAGE=
LC_CTYPE="en_ZA.UTF-8"
LC_NUMERIC="en_ZA.UTF-8"
LC_TIME="en_ZA.UTF-8"
LC_COLLATE="en_ZA.UTF-8"
LC_MONETARY="en_ZA.UTF-8"
LC_MESSAGES="en_ZA.UTF-8"
LC_PAPER="en_ZA.UTF-8"
LC_NAME="en_ZA.UTF-8"
LC_ADDRESS="en_ZA.UTF-8"
LC_TELEPHONE="en_ZA.UTF-8"
LC_MEASUREMENT="en_ZA.UTF-8"
LC_IDENTIFICATION="en_ZA.UTF-8"
LC_ALL=

My OS X settings is: (Language set to "English", "Formats" set to
"South Africa")
MoHaGLaptop:~ mohag$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

I would interpret that as default language, C for numbers, currency,
etc, which would not be correct. (I think a (Perl/Python if any of
them support native locale under all OSes?) script to quickly test the
behaviour under Wine / OS X / *nix might be handy to figure out what
applications are actually seeing....)

> But, more importantly for this discussion, the fact that LANG will be appropriate for you and probably Gert does not mean it will be appropriate "often enough" for Wine to rely on.  As I have said, there are many ways in which users configure their language and formats settings that will not be properly reflected in LANG (and, indeed, cannot be).
>

>
>> The Wine project could use this as a default with the Mac, which is not
>> POSIX compliant.
>
> You are suggesting using a proxy for the real thing rather than the real thing.  If we want to maintain the "magic", Wine should just use the settings from System Preferences directly (via CFLocale, CFNumberFormatter, and CFDateFormatter), with an optional way to override them for those rare users who want Wine's behavior to deviate from the system's.

That makes sense to me... (If Wine tries to be a good OS X app under
OS X, rather than a good POSIX app under OS X)

(And what is suggested was current Wine settings of environment
remained the same, LC_ALL (to allow for similar override everywhere),
platform specific settings (e.g. individual settings from OS X's
"Formats" settings), LC_* (which only contains specific settings, not
"country" / "language"), LANG (for unset settings, and locale/country
itself). On OS X this should mean that the variables other than LC_ALL
only gets looked at if reading the OS X settings fail for some reason)

For consistency with *nix override via LC_ALL makes sense (ignoring
all other LC_*/LANG settings on OS X, in favour of OS X specific
settings)

> LANG doesn't help maintain the magic.  It's a hindrance.
>

LC_ALL should be used to override settings, not LANG. LANG doesn't
work (on Linux at least) if LC_ALL is defined. Telling users to use
LANG if it only works in certain cases does not make sense...

mohag at mohagpc:~$ LC_ALL="en_US.UTF-8" LANG="en_ZA.UTF-8" wine regedit
/E - 'HKEY_CURRENT_USER\Control Panel\International'|egrep
"Country|Locale"
"iCountry"="1"
"Locale"="00000409"
"sCountry"="United States"

mohag at mohagpc:~$ LC_ALL="en_ZA.UTF-8" LANG="en_US.UTF-8" wine regedit
/E - 'HKEY_CURRENT_USER\Control Panel\International'|egrep
"Country|Locale"
"iCountry"="27"
"Locale"="00001c09"
"sCountry"="South Africa"

I'm actually quite impressed with Wine's handling of the locale under
Linux, it seem to be possible to overwrite the individual settings
with LC_*, which I did not think was possible based on Vitality's
comments on Wine-users. In addition it seems not to mess around with
the settings if the environment stays the same. (Which is mostly the
behaviour that I prefer, since it starts with defaults based on my
settings (whether it is based on Windows' or Linux's idea of my
settings is not easy to test, since I don't know of any obvious
differences to test) and allows me to customize it under Wine to fix
broken defaults / specific settings needed by applications) Under
Linux it seems to emulate native apps quite nicely.

I don't currently have an OS X Wine installed to test effect of
different settings. The environment variables does seem to be affected
by the language settings, which might be caused by OS X's decoupling
of "Formats" settings and "Language" settings, which can result in
some weird combinations. (e.g. Dutch language with "Formats" country
set to "China" )

(Parts of this might be in need of some reordering, had internet
issues and might have repeated myself)

Gert