Telerik blogs

When building an application for Windows 8 we find the same known feature for Globalization through the CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture properties, used in many cases where it comes to using culture-specific strings, formatting dates, numbers, etc. And while developing, you might be surprised that, in the common scenario, the current culture does not derive from the OS culture for the current machine.

Then, how the current culture is resolved?

It turns out that there is a way to get the correct OS UI culture. To understand the process I will start from a blank app and modify it for our needs.

Package.appxmanifest default language

When creating a new app the package default language is set to en-US. Although you can change it, this will result that your app running in that particular culture, ignoring OS settings. Even if you try to fool it and leave an empty value Visual studio will “donate” its process culture to the result package.

The solution is behind the scenes 

The described behavior results from default settings in the Package.appxmanifest not visualized in the designer. If you look in the xml file you will find this tag:

<Resource Language="x-generate"/>

As you might assume this attribute value tells the package manager that we need a hardcoded culture.

So, the solution will be to define the application-supported (allowed) cultures. The xml can look like this:

<Resources>
  <Resource Language="de" />
  <Resource Language="el" />
  <Resource Language="bg" />
  <Resource Language="fr" />
  <Resource Language="en" />
</Resources>
That way when the application is initialized, it will look for the OS locale and if supported by the app it will use this culture. If there is no match it will simply use the first record defined (in this case German culture).

About the Author

Tsvyatko Konov

Tsvyatko Konov was the Lead of UI for Xamarin and UI for UWP team.

Comments

Comments are disabled in preview mode.