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