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?
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.
Hi Marian,
I can’t reproduce the behaviour you describe. I attach a sample.
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,
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
Please login first to submit.
