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:[EMAIL PROTECTED] Sent: Thursday, March 13, 2008 6:30 PM To: Vladimir Dimitrov Cc: mono-devel-list@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 _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list