On Tue, Dec 1, 2009 at 06:12, Ken Thomases ken@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@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@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@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