ResourceManager.GetString() method returns wrong string from different assemblies

Asked 4/10, 2012 at 15:30 Answered 27/6, 2019 at 13:49

I have 2 resource files, one with english and another foreign. When I call

ResourceManager.GetString("Hello")

from the .Designer.cs file it is always returning the english translation. I have checked my locale and language etc. and everything is correct.

it returns properly translated strings from my main assembly, but from loaded assemblies it is always returning the english.

Ious answered 4/10, 2012 at 15:30 Comment(4)

How have you set the language? It should be set using the UICulture. Have you done this? – Genic 4/10, 2012 at 15:37

Can you post the code you use to instantiate ResourceManager? – Tetrachloride 4/10, 2012 at 15:56

Yes set language, all that is correct. It turns out that having it as an embedded resource is what the issue is. It seems to ignore locale and load english. Have it as a Resource solves this and the correct language is loaded. only happens to embedded assemblies, investigating why now. – Ious 4/10, 2012 at 16:23

I dont instanciate resource manager, but i was looking and seeing that it was getting called but passing me back the english instead of foreign. I simply call Namespace.Strings.Hello and it should return me the correct one, which it does except for loaded assemblies. Have them as resources and package them into the external assembly dll instead of embedding and it seems to work. – Ious 4/10, 2012 at 16:24

Here is what was going on. I had an assembly with several translation resource files. These were all embedded resources.

When I compiled the assembly it was putting the default English inside its .dll. As for the other languages it was creating folders, fr, da, de, etc. with the languages in.

I had to move all these as well if I wanted them to be picked up by my main application which was loading in all these other assemblies. Thought as I told the assembly that they were all embedded resource files it would actually embed them!

I now have a AssemblyLoader which loads all the required .dll's when it cant find them from their current locations, packaging it will be determined on whether I want to include all languages or select the ones I want before building the project. More work than I had hoped, but solved in the end.

Anyone have any question, feel free to ask.

Ious answered 5/10, 2012 at 16:11 Comment(4)

How exactly did you do to solve this? I'm having this exact issue. – Torpid 4/4, 2017 at 17:2

did you set the NeutralLanguage of the application? maybe that was your whole problem – Emblematize 17/2, 2018 at 14:27

Batmaci's comment was useful for me. I experienced the same issue, a dll generated for each language except from the default (english). Then I set the neutral language to None (Assembly Information > Neutral Language) and I get the translated strings correctly instead of always english – Thereupon 15/10, 2018 at 12:13

The separate folders is the important part. I'm supporting one language besides English so all I had to do was referencing the projectname.resources.dll file in my main project and ResourceManager took care of the rest. – Orren 4/5, 2020 at 12:1

The first overload of GetString, ResourceManager.GetString(string), uses the current thread's CurrentUICulture (Thread.CurrentThread.CurrentUICulture).

Referring to MSDN:-

The resource that is returned is localized for the UI culture of the current thread, as defined by the CurrentUICulture property.

In a background thread, do not assume the thread's CurrentUICulture is the same as your main (or UI) thread's CurrentUICulture.

A better way to access the resource from a background thread is to use something like the following to get the correct localised string:-

var localString = Properties.Resources.ResourceManager.GetString("ResourceKey", CultureInfo.CurrentCulture);

Ultramicrochemistry answered 28/1, 2014 at 14:22 Comment(0)

Not sure how you are instantiating ResourceManager, but when you call ResourceManager.GetString(), you can specify CultureInfo, which helps you fetch the string in correct locale. So you can do something like:

var string = ResourceManager.GetString("ResourceKey", new CUltureInfo("en-GB"));

This will make sure that the string key is from the en-GB specific Resource file.

Tetrachloride answered 4/10, 2012 at 15:58 Comment(1)

My problem was that those resource files with the foreign translations were not getting loaded. Discovered this was because it was packaging them into seperate dll's inside each languages folder which sort of makes sense, but thought it would have embedded them in my .dll in the first place – Ious 5/10, 2012 at 16:14

Try changing build action to "Embedded Resource" I faced this problem recently when adding Tamil resource. After spending couple of hours, I figured out this simple step was missed after adding resource file.

Denier answered 27/6, 2019 at 13:49 Comment(0)

In my case problem was with resx-file. Invalid resource strings had incorrect format in the resx-file:

<data name="HeaderColumnsCountGreaterThenDataColumnsCountTestData" xml:space="preserve">
  <settings>
    Month   Date    Department
    01.05.2015  01.05.2015  OIR
    01.05.2015  02.05.2015  OIR
  </settings>
</data>

Correct format:

<data name="HeaderColumnsCountGreaterThenDataColumnsCountTestData" xml:space="preserve">
  <value>
    Month   Date    Department
    01.05.2015  01.05.2015  OIR
    01.05.2015  02.05.2015  OIR
  </value>
</data>

Attainture answered 4/8, 2015 at 10:22 Comment(0)

-1

The easiest and fast way I found to resolve this issue dynamically was by getting the language which was currently used in the Operating system where the application is running, and calling the appropriate resource Here is the code to Accomplish this.

string lg = CultureInfo.CurrentCulture.TwoLetterISOLanguageName;
            return resourceManager.GetString(text, new CultureInfo(lg));

Apologist answered 1/12, 2018 at 13:58 Comment(0)

Recommended topics

Hot tags