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

[Ken Thomases]

On Nov 30, 2009, at 4:35 AM, <Joerg-Cyril.Hoehle at t-systems.com> <Joerg-Cyril.Hoehle at t-systems.com> wrote:

> 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.

That logic is exactly backwards, in my opinion.  Terminal.app is setting LANG as a backstop.  It's a fallback, not an override.  It's what should be used by programs which aren't Mac-aware.

The fact that Terminal sets LANG by default suggests that we shouldn't use it as an override, because it can't express the full range of user preferences as specified in System Preferences.  It will therefore produce results in Wine different from what the user has chosen for their system.

We specifically want to require that the user specify a variable _not_ set by Terminal by default if they want to override the settings in System Preferences.


> 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??

glibc is one implementation of the C standard libraries.  Mac OS X does not use glibc, but provides its own implementation of the C libraries in libSystem.  It follows the same general precedence rules for these environment variables, though.  For example, see the locale(1) man page.


> 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.

One should set the LC_* variable or variables that make sense for what one is trying to achieve.

If one wants all categories of locale information to be overridden, one should set LC_ALL.  If one only wants to change the language of displayed messages, one should set LC_MESSAGES.


> 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.

You say you see no override and then you say LANG should override the desktop settings.  That's exactly the override that I'm talking about and recommending against.  LANG should not override the desktop settings.  It should not override anything, ever, anywhere.  It should be a fallback when nothing else has been specified.

I deem the settings in System Preferences to be roughly on par, in terms of precedence and user intention, as setting the individual LC_* variables (other than LC_ALL).

If a Wine user wishes to override the System Preferences settings, they should set the appropriate LC_* variables or possibly LC_ALL to override them all.


>> 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.

The problem is that it produces results counter to what the user said they prefer in a number of cases.  One case is where the user language differs from the region.  Another is if the region is customized (i.e. it's not one of the presets).

>  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.

Any program targeting Mac OS X should strive to do the right Mac-specific thing, not some generic Unix thing.  That most don't is no excuse for Wine not to.

> 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.

You're right that it does not, but we disagree about which direction it should go.  I think that Wine should not set LANG if it's unset.  I think it should set each of the LC_xyz variables based on the System Preferences settings, if it is not set.

As I've said repeatedly, I consider the System Preferences settings as analogous to LC_xyz in intent.  Therefore I think they should be treated analogously in precedence.

(Actually, I don't think that Wine should use any of these environment variables, because they don't properly transmit the full range of settings possible in System Preferences.  I think that Wine should directly translate the System Preferences settings into the proper behavior as far as a Windows program would see.  For example, System Preferences offers many languages and regions for which there are no /usr/share/locale definition files.  And, as already mentioned, the user may customize the formats in ways which can't be expressed via LANG/LC_*.

If we went this route, we would still have to figure out some good way to allow for a temporary override.)


>> (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)?

We (CodeWeavers) get reports from users who have a different preferred language set from the formats region.  Different users have different reasons for setting things that way.  Some may be traveling.  Others have business reasons for it (they speak/write one language, but need to work with numbers and dates formatted for some other region where they do business).  Etc.

It doesn't much matter why they might be set that way.  What matters is that Wine should behave according to their expressed preferences.

> Terminal.app sets LANG to US which you believe is wrong?

It's at least insufficient for us to rely on.  As I say, the LANG/LC_* variables are insufficient, alone or in combination, to transmit the user's preferences.

> 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).

It should be "obeyed" only as a fallback if no other information were available.  That is its defined role.  Other (indeed, better) information is, in fact, available.  That better information should be used in preference to LANG.

If you wish to override the System Preferences settings, use LC_ALL.  That's what Linux users should be using, too.  Because if a Linux user has LC_* variables set in their everyday, default environment but wants to test Wine as though in another locale, then setting LANG is insufficient.  Setting LANG to get Wine to behave differently is just wrong.

-Ken