Runtime: .NET Core 2.2 CultureInfo derivation from .NET Framework 4.7.1

Created on 1 Apr 2019  路  11Comments  路  Source: dotnet/runtime

While using CultureInfo provided in .NET Core 2.2, I noticed a difference in one of the values from its counterpart in .NET Framework 4.7.1.

new CultureInfo("es-ES").DisplayName;

.NET Core 2.2 displays the value as: "Spanish (Spain, International Sort)"
.NET Framework 4.7.1 displays the value as: "Spanish (Spain)"

Is this intended?

area-System.Globalization bug

Most helpful comment

I am closing this one again as duplicate of dotnet/corefx#36531

Here is some more information:

  • We have different behavior when requesting DisplayName on .NET Core than the full framework. The full framework try to get the needed data from the resources. In .NET Core we don't carry such resources (so far by design).
  • For this specific es-ES, the full framework resources has the name Spanish (Spain) and that is why you are seeing that.
  • In .NET Core looks most of the time we call the OS to get the name. and we use what we get here.

We'll continue having some discrepancy between .NET Core and the full framework because we don't carry any resources.

All 11 comments

Could you tell what the CultureInfo.CurrentCulture was when running? I cannot seem to test it because the DisplayName depends on the UI culture (it's giving me Spanish in Korean.)

@Gnbrkm41 - Both were run under en-US

Can repro on Core 3.0 P3.

Duplicate of dotnet/corefx#36531

Is it a duplicate? this one is about DisplayName returning slightly different text when compared to netfx, and mine's about DisplayName not following the CultureInfo.CurrentCulture.

Fair, the descriptions were too similar, so I thought it was dupe, sorry ...

In my opinion, I think the current behaviour is somewhat desirable; Sure, it is different from what .NET Framework did but it actually is including more detail than what it used to. I can't imagine what kind of things this will break due to incompatibility between full framework and Core.

@Gnbrkm41 - If that bit of data is what you want why not just use EnglishName? In this context both .NET Core and .NET Framework's EnglishName return "Spanish (Spain, International Sort)".

I don't have a use for it, to be honest. It's just a thought about it.

Also, documents for both properties mention that this returns the locale information in the same languagefull [country/regionfull] format (albeit one in the localised format), which makes me think that both should be the same if the language used in the current locale is English. If they are supposed to be in the same format, and if the system locale uses English, then by definition EnglishName is already _the full localized culture name_, and therefore they should be the same, aren't they?

I don't disagree with the fact that this is a breaking change from .NET Framework. Even the example given in the CultureInfo docs shows the result being Spanish (Spain). It's just that I don't think it should be changed only because it is different from what .NET Framework did, given that this actually is more descriptive about the CultureInfo instance.

Other way around, why do you want the string to be in that format?

I am closing this one again as duplicate of dotnet/corefx#36531

Here is some more information:

  • We have different behavior when requesting DisplayName on .NET Core than the full framework. The full framework try to get the needed data from the resources. In .NET Core we don't carry such resources (so far by design).
  • For this specific es-ES, the full framework resources has the name Spanish (Spain) and that is why you are seeing that.
  • In .NET Core looks most of the time we call the OS to get the name. and we use what we get here.

We'll continue having some discrepancy between .NET Core and the full framework because we don't carry any resources.

Was this page helpful?
0 / 5 - 0 ratings