Member Avatar for Diogo Martinho

Hello.
I'm currently facing an issue with my code related to the way CultureInfo.GetCultures method is sending me the list of countries.

I have this in my getCountries method:

System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("en-GB"); 
System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-GB"); 
var cultures = CultureInfo.GetCultures(CultureTypes.SpecificCultures);

Which retrieves me a list of Cultures in associated to English Culture.

I was trying to do something like

public List<String> getCountriesNamesbyCountry(string countrycode){

    System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo(countrycode); 
    System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo(countrycode); 
    var cultures = CultureInfo.GetCultures(CultureTypes.SpecificCultures);

    var cultureList = new List<String>();

       foreach (CultureInfo cul in cultures)
        {
            var country = new RegionInfo(cul.LCID);

            if (!cultureList.Contains(country.DisplayName))
            {
                cultureList.Add(country.DisplayName);
            }
        }

        return cultureList;
}

If I try to do this

List<String> en = getCountriesNamesbyCountry("en");
List<String> es = getCountriesNamesbyCountry("es");

Both lists will give me a list of country names in english.
What am I doing wrong >.<?

Edited by Diogo Martinho
  • 2 Contributors
  • 3 Replies
  • 217 Views
  • 36 Minutes Discussion Span
  • Latest Post Latest Post by pritaeas

Dani AI

Generated

Short version: setting the thread culture is not enough because the country names you see come from the framework/OS localization resources (which is what pointed out). To reliably show country names in a particular UI language you need a localized data source — either one you ship with your app or one you query that contains translations.

Practical options (pick one based on scope and platform):

  • Use CLDR data (best for many languages). Unicode’s CLDR contains translated territory names; several .NET wrappers/nuggets expose that data (for example ). Example usage with that package:

    var factory = LocaleTranslationsFactory.ForCultureInfo(new CultureInfo("es-ES"));
string spain = factory.FindCountryName("ES"); // "España"

    This gives you translated names for a chosen display culture. ()

  • Generate and ship RESX resources from CLDR so your app owns the translations. The tool [dotnet-cldr-resx] can produce per-language RESX files you then read with ResourceManager or IStringLocalizer. That keeps translations in your control and removes any dependency on installed framework language packs. ()

  • If you only target Windows and prefer system-provided translations, call the Windows NLS API (GetLocaleInfoEx) to read the localized country string (LOCALE_SLOCALIZEDCOUNTRYNAME). This ties results to the OS/product language and requires P/Invoke. Use it only if you accept that dependency. (learn.microsoft.com)

Recommendation and tips: for web apps or anything that must serve many UI languages, use CLDR (or a NuGet wrapper) and store names keyed by ISO alpha-2 codes (fallback to EnglishName). For small language sets a few RESX files are simplest. If continuing with RegionInfo, instantiate with a specific culture name when appropriate (but remember DisplayName still depends on installed localization), and always test with explicit culture codes like "es-ES" to verify results.

Recommended Answers

All 3 Replies

Member Avatar for Diogo Martinho

What should I do then in that case?

Member Avatar for pritaeas

Build a resource yourself, which you can then include and use in your application. Perhaps you can find one online. There must've been more people facing this issue.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.