Runtime: CultureInfo.DisplayName do not return the string in language/culture specified by `CurrentUICulture` or `CurrentCulture`

[Gnbrkm41]

OS used: Windows 10 1903 Insiders Preview x64 (Build No. 18362.1), Korean
Runtime used: .NET Core 3.0 P3

Code used to test:

using System;
using System.Globalization;
using System.Threading;

namespace ConsoleApp19
{
    public class Program
    {
        private static void Main(string[] args)
        {
            Thread t = new Thread(Print);
            t.CurrentCulture = new CultureInfo("en-US");
            t.CurrentUICulture = new CultureInfo("en-US");
            t.Start();
        }

        private static void Print()
        {
            Console.WriteLine(CultureInfo.CurrentCulture);
            Console.WriteLine(new CultureInfo("es-ES").DisplayName);
        }
    }
}

Expected output: The DisplayName property returns the string in English.
Actual output (on Core 3.0):

en-US
스페인어(스페인, 국제 정렬) // Spanish (Spain, International Sort) in Korean

Output when ran on .NET Framework 4.7.1/4.7.2:

en-US
Spanish (Spain)

(Not sure why DisplayName is outputting the sorting as well in Core 3.0, related issue: https://github.com/dotnet/corefx/issues/36524)

[tarekgh]

@Gnbrkm41 Currently .NET Core is not supporting any localization to any language. To display the right display name in the right language you have to have a localized resources and we don't have these in .Net Core. The framework just fallback to use the native display name in such cases. what is your scenario here? if you want to display the English name, you can just call EnglishDisplayName.

[tarekgh]

@karelz I have changed the tag to infrastructure as this is a localization request which I believe we had some other issues tracking that. Maybe having a new tag for localization would be better.

[karelz]

Tag for localization would make sense if we have 10-20 separate issues in the area. Is that the case?
Let's find the dupe and close this one.
Meta area may be more fitting than Infrastructure.

[karelz]

@tarekgh actually, I may have misunderstood.
The text seems to be localized on .NET Core - it means, it comes from OS, not from .NET Core resource strings (we do not have any localization in .NET Core).

If that's the case, then we should probably just close it as by design difference between .NET Framework and .NET Core.
@tarekgh what do you think? Did I miss something?

[tarekgh]

@karelz the behavior you are seeing is just a fallback mechanism when we cannot get the right display name because we don't have the localized resources. it is by design so far in coreclr because we don't carry any localized resources. In the future, if we carry such localization resources we can revisit it.

[karelz]

OK, that makes sense.
I am closing this as By Design for now - not having any localizations is concious decision for .NET Core (at least at the moment).

@Gnbrkm41 please speak up if you disagree.

[Gnbrkm41]

I will clarify what I wanted to say initially.

From what I can see in .NET Framework, it appears that DisplayName returns the string in the language specified by CultureInfo.CurrentUICulture if the language is installed in Windows (e.g. I have Japanese, English (GB) and Korean installed on my Windows. If I set CultureInfo.CurrentUICulture to Japanese, DisplayName returns in Japanese, if I set CultureInfo.CurrentUICulture to Korean, it returns in Korean, and if I set CurrentUICulture to languages that aren't installed, e.g. German, it returns in English. (Not sure if it also appears in English if I don't have English installed.)

However, in .NET Core, the text returned from DisplayName does not appear to be affected by CurrentUICulture at all; Regardless of the locale set, it will always appear in the language of current user's locale.

My suggestion is not about including massive localisation resource to achieve the same per se, but to have a look at the CurrentUICulture of the executing thread, look if the localised text is available in the OS, and if it exists, display the data from the OS; if it does not exist, either fall back to the current user's language (just as what it does now) or do the same as .NET Framework (fallback to English).

/cc @karelz @tarekgh

[tarekgh]

@Gnbrkm41 thanks for clarification. I'll try to look at your suggestion and figure out if we can do it. Thanks.

@karelz I changed the tag back to globalization as the issue is specific to globalization now and not to localization.

[tarekgh]

@Gnbrkm41 I looked at this issue, and I am seeing we cannot be perfect here and changing the behavior wouldn't help much.

You have suggested to look at the OS UI language and if it matches the current UI we pick up the name from the OS. That is the default behavior we are doing today regardless of checking the OS UI language. Then you have suggested to fallback if the OS UI language not matching. The fallback usually will use NativeName so in the case here, the name will be shown in Spanish and not in Korean which still not perfect. We cannot use other names (e.g. EnglishName) as a fallback because this kind of promoting English over other languages.

Considering that, I would say this is not worth to change now and let's wait in the future if we'll support adding resources for culture names. let me know if this make sense or you object :-)

[tarekgh]

I am closing this. @Gnbrkm41 feel free to reply back if you disagree or have any question. Thanks for reporting the issue.

[Gnbrkm41]

I was looking at the .NET Framework's source for a while (and actually stepping through it), it appears that the localised strings (e.g. スペイン語 (スペイン)) actually come from the embedded resources in mscorlib; I originally thought these were held by OS because it didn't show me the German one (which I don't have it installed on my OS) when I tried, but it did show up when I tried the Japanese (which I do have it installed on my OS). That clears it up, I guess.

By the way, how do you think about returning the NativeName as the DisplayName if CultureInfo.CurrentUICulture == this? i.e. if the current culture is the same as the culture you're trying to get the DisplayName from, shouldn't the DisplayName be the same as the NativeName? it looks like NativeName is held by the OS, at least.

[tarekgh]

By the way, how do you think about returning the NativeName as the DisplayName if CultureInfo.CurrentUICulture == this

This may help in one culture but wouldn't help much in the main scenarios. The main scenario I am seeing CultureInfo.DisplayName used for is users enumerating all cultures and getting the display names populated to list box in the UI. populating the list using the OS UI language except one of them will come in native language would look weird here. As I mentioned before we cannot be perfect anyway here and trying to fix small issue can be perceived well in some scenarios and will not be good for other scenarios.

Thanks for your thoughts here.

[Gnbrkm41]

I see, Thanks for your time!