Thread.CurrentUICulture not set correctly anymore

0
0

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?

  • You must to post comments
0
0

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.

  • You must to post comments
0
0

Hi Marian,

I can’t reproduce the behaviour you describe. I attach a sample.

Attachment
  • You must to post comments
0
0

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.

  • You must to post comments
0
0

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

 

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.