0
votes

We have created a Class-Library project with some WinForms inside. We translated the Forms via build in VS designer (set Localizable=true).

VS will create the assembly and the different folders for each language with containing satellite resource files.

This assembly will be loaded by an 3-party application.

Now we have the issue, that our Forms won't get localized if we start it via the 3-party application. It seems, that our assembly isn't able to load the resource files from the language sub-directories.

Is it possible to load this resource file by code, so the default localize-mechanism of the WinForms will work?

Edit

If i copy the language folders (de, en, ...) to the main 3-party app folder, everything will work like a charm.

1

1 Answers

0
votes

As you know, the localization works depending on the thread culture. Are you sure, that the third-party application sets the right culture on startup?

// set culture on program startup
CultureInfo ci = CultureInfo.GetCultureInfo("de-DE");
Thread.CurrentThread.CurrentCulture       = ci;
Thread.CurrentThread.CurrentUICulture     = ci;

// .NET 4.5 and above
CultureInfo.DefaultThreadCurrentUICulture = ci;
CultureInfo.DefaultThreadCurrentCulture   = ci;

From MSDN:

"In the .NET Framework 4 and previous versions, by default, the UI culture of all threads is set to the Windows system culture. For applications whose current UI culture differs from the default system culture, this behavior is often undesirable. In the .NET Framework 4.5, the DefaultThreadCurrentUICulture property lets you define the default UI culture of all threads in an application domain."

So, if you are using .NET 3.5, the cultures of the thread-pool and worker threads may also differ from your wanted application culture, if that is different from the OS culture. You should check/set the culture on each threaded call, if that is required.