On Dec 9, 2009, at 1:34 PM, Ken Thomases wrote:
So, I'm making a new proposal: the Mac formats region will be used
to set LANG unconditionally. (Passing 1 for the third argument to
setenv() rather than 0.) The current code for overwriting
lcid_LC_MESSAGES will be tweaked. Instead of look
Ken Thomases wrote:
> On Dec 3, 2009, at 11:27 AM, Ken Thomases wrote:
>
>> I propose the following (in pseudocode):
>>
>> mac_formats_locale = CFLocaleGetIdentifier( CFLocaleCopyCurrent() );
>> mac_language = CFArrayGetValueAtIndex(
>> CFBundleCopyLocalizationsForPreferences(
>> CFLocaleCopyAvail
On Dec 3, 2009, at 11:27 AM, Ken Thomases wrote:
I propose the following (in pseudocode):
mac_formats_locale = CFLocaleGetIdentifier( CFLocaleCopyCurrent() );
mac_language =
CFArrayGetValueAtIndex
( CFBundleCopyLocalizationsForPreferences
( CFLocaleCopyAvailableLocaleIdentifiers(), NULL ),
On Dec 8, 2009, at 6:39 AM, > wrote:
Ken Thomases wrote:
This results in the order I previously described:
LC_ALL
LC_* from the original environment
Mac OS X settings
LANG
In other words, LANG is completely ignored, since there presumably
won't
be a Mac without settings.
Correct. LANG i
Hi,
Ken Thomases wrote:
>Currently, Wine uses the LC_MESSAGES category to determine sCountry and
Locale.
Good to know.
>That's not quite what I proposed. I propose the following
[pseudo-code omitted]
>This results in the order I previously described:
>LC_ALL
>LC_* from the original environment
On Dec 2, 2009, at 11:25 PM, Gert van den Berg wrote:
> 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 wheth
On Wed, Dec 2, 2009 at 22:52, Ken Thomases 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
On Dec 2, 2009, at 1:22 PM, Gert van den Berg wrote:
I'm using Terminal.app using default settings (AFAIK, except for
colors). "Set locale variables at startup" is enabled.
I don't see settings for en_ZA* in /usr/share/locale (af_ZA does
exist, but if my applications turn Afrikaans I'll go insa
On Wed, Dec 2, 2009 at 18:05, Ken Thomases wrote:
> Are you using Terminal.app or some other terminal application? If
> Terminal.app, have you turned off the "Set LANG environment variable on
> startup" setting in preferences? (That's the name on Leopard. If I recall,
> that setting is slightly
On Dec 1, 2009, at 1:30 PM, Gert van den Berg wrote:
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=
Are you using Terminal.app
On Tue, Dec 1, 2009 at 06:12, Ken Thomases 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
Hi,
As the author of the support for GNU gettext in MacOS X [1], I can explain the
relation between the POSIX notion of locale and the MacOS X user preferences.
POSIX:2008 [2] says:
"All implementations shall define a locale as the default locale, to be
invoked when no environment variables
On Nov 30, 2009, at 9:34 PM, James McKenzie wrote:
>>> This algorithm is used in all programs that rely on GNU gettext and works
>>> perfectly fine:
>>> - By default, no LANG or LC_* environment variable is set, hence the
>>> programs obey the user settings.
>>> - For users of Terminal.app, who
Ken Thomases wrote:
> On Nov 30, 2009, at 5:31 PM, Bruno Haible wrote:
>
>
>> This means that a POSIX compliant program has to do the following steps in
>> order to determine the locale for a certain category of settings.
>> 1) Inspect the LC_ALL environment variable. If it is set and non-empty
On Nov 30, 2009, at 5:31 PM, Bruno Haible wrote:
> This means that a POSIX compliant program has to do the following steps in
> order to determine the locale for a certain category of settings.
> 1) Inspect the LC_ALL environment variable. If it is set and non-empty,
> use its value.
> 2) Ot
On Mon, Nov 30, 2009 at 22:01, Ken Thomases wrote:
> On Nov 30, 2009, at 4:35 AM,
> wrote:
>> 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
On Nov 30, 2009, at 4:35 AM,
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 cano
wrote:
perhaps I should contribute to this thread given that I
indirectly triggered it via bug #20377.
IMHO Wine, due to its sandbox nature ...
There is no such a nature of Wine.
--
Dmitry.
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 dis
On Nov 26, 2009, at 12:31 AM, Vitaliy Margolen wrote:
Ken Thomases wrote:
Setting LC_ALL would achieve that, plus override the various other
locale
categories. Set LANG is the wrong approach, in my opinion.
However this is not the way Wine works on all other platforms.
Sure it is, if you
"Ken Thomases" wrote:
If you as a user want to override the language that Wine displays,
you can set LC_MESSAGES in your environment rather than LANG.
Setting LC_ALL would achieve that, plus override the various other
locale categories. Set LANG is the wrong approach, in my opinion.
In the m
Ken Thomases wrote:
> Setting LC_ALL would achieve that, plus override the various other locale
> categories. Set LANG is the wrong approach, in my opinion.
However this is not the way Wine works on all other platforms. Keeping
everything in sync is more appropriate here. Or modify global Wine beh
On Nov 24, 2009, at 7:52 AM, Charles Davis wrote:
> I just realized something. The reason Wine doesn't respect LANG is that
> it overrides the LC_MESSAGES setting if it is set to the default. It
> will be set to the default if there is no LC_MESSAGES in the
> environment. So we don't want to overr
I just realized something. The reason Wine doesn't respect LANG is that
it overrides the LC_MESSAGES setting if it is set to the default. It
will be set to the default if there is no LC_MESSAGES in the
environment. So we don't want to override LC_MESSAGES if there's a LANG
variable in the environme
Ken Thomases wrote:
> The call to setenv() has 0 (false) as its third parameter, so that LANG is
> not overwritten.
Then why does Wine not repsect the LANG setting on Mac OS X? I've seen
it on wine-users. Wherever the problem lies, it lies elsewhere.
(Yeah, I forgot what that third parameter to s
The call to setenv() has 0 (false) as its third parameter, so that LANG is not
overwritten.
-Ken
On Nov 23, 2009, at 9:12 AM, Charles Davis wrote:
> ---
> dlls/kernel32/locale.c | 53
> +--
> 1 files changed, 28 insertions(+), 25 deletions(-)
>
>
>
26 matches
Mail list logo