Hello,
we are using localization in our app which worked fine for a long time. Recently (after a Wisej update) it broke, which appears to be caused by Thread.CurrentUICulture not being set to ApplicationBase.CurrentCulture anymore. My guess is that it was set before, but I didn’t check back then. This leads to the .NET ResourceManager always using English strings. I have been able to work around this issue by handling Application.ThreadBegin and simply doing “Thread.CurrentThread.CurrentUICulture = ApplicationBase.CurrentCulture;”.
Was this change in behavior intentional or is this a bug?
Hi Marian,
in release 1.4.95 there was a change
| WJ-8932 | New Feature | ApplicationBase.CurrentCulture make setter public |
Before this change you had to add ?lang=<culture> to the URL, something like
ApplicationBase.Navigate(ApplicationBase.Url + “?lang=” + “fr”);
This new feature makes setting the CurrentCulture easier. As you can see on this thread, this should be used like this
Application.CurrentCulture = CultureInfo.GetCultureInfo(“fr”);
Application.Reload(); // needed so Wisej can fetch the resources for the new culture
I see, that’s nice. But why does it not set Thread.CurrentUICulture anymore? Thread.CurrentCulture appears to be set properly still, but Thread.CurrentUICulture is always en-US for me. Thread.CurrentUICulture is necessary for ResourceManager I believe.
Hi Marian,
I can’t reproduce the behaviour you describe. I attach a sample.
Found the problem. Works when changing the culture, but doesn’t work when the culture is already changed at startup. Logged, will be fixed in the current dev build.
Please login first to submit.
