[Mono-dev] Mono.Unix.Catalog.Init where does it get the locale from?

[Vladimir Dimitrov]

Thanks for the quick answer I tried your suggestion and set the variable
using this code:

                    CultureInfo culture = new CultureInfo
(config.Localization);
                    Thread.CurrentThread.CurrentCulture = culture;
                    Thread.CurrentThread.CurrentUICulture = culture;
                    Environment.SetEnvironmentVariable ("LANG",
config.Localization.Replace ("-", "_"));

Right before calling Catalog.Init but still no luck. If I set the
environment variable before running the application it works. My guess is
that the environment is read before that, but I am not sure how as I don't
call anything from the Catalog class before the initialization and so no
static constructors would have possibly read it.

P.S. I really don't want to set and use the localization per thread but this
is the only way I know of setting it.

Thanks,
 Vladimir

-----Original Message-----
From: Jonathan Pryor [mailto:jonpryor at vt.edu] 
Sent: Thursday, March 13, 2008 6:30 PM
To: Vladimir Dimitrov
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] Mono.Unix.Catalog.Init where does it get the locale
from?

On Thu, 2008-03-13 at 15:49 +0200, Vladimir Dimitrov wrote:
> On windows when I set 
> 
>  Thread.CurrentThread.CurrentCulture = new CultureInfo
> (config.Localization)
>
> I can change the localization of the current thread and if I call
> Catalog.Init after that the localization is properly initialized, and
> Catalog.GetString gives me correct string from the localization setup
> I have for my application.
> 
> But if use the same code on Linux Catalog.GetString does not respect
> the changes I made and does not return the messages for the
> localization I set.
> 
> If I use 
> 
> LANG=cs_CZ.utf8 mono MyApp.exe 
> 
> Then everything is fine and the localization works. Is there something
> I am doing wrong or is this a bug in Mono.Unix?

This isn't a bug in Mono.Unix, as Mono.Unix is a very thin wrapper over
libc/libintl, and these will use the appropriate environment variables
for initialization.

What it sounds like is happening is one of two things:

1. INTL.DLL on Windows doesn't use the environment variable, but instead
uses the thread's current Win32 locale to do the lookup (which would
explain why setting Thread.CurrentCulture would impact the behavior of
INTL.DLL); or

2. Win32's SetThreadLocale() sets the environment variable that INTL.DLL
uses during initialization.

I'd bet that (1) is what's happening, implying that INTL.DLL behaves
differently from libc/libintl on Linux (but consistent with other Win32
libraries).

If this is the case, the "real" bug is that Mono's Thread.CurrentCulture
property should also set the LANG/etc. environment variables, as
appropriate, so that libc/libintl will pickup on this change...

...which also isn't quite appropriate, as Thread.CurrentCulture is a
per-thread property, while environments are per-process.

So the short version is that Mono.Unix.Catalog is behaving sensibly, and
INTL.DLL/libc/libintl are (presumably) behaving sensibly, but the
interaction between them isn't consistent across all platforms.

I'm not sure what the correct answer is, but I'm quite sure that
Mono.Unix.Catalog should NOT change the LANG environment variable
automatically...

Short term, I'd suggest modifying your app to set LANG when you also set
Thread.CurrentCulture, and realize that Mono.Unix.Catalog is a
per-process translation mechanism, not per-thread.

 - Jon