Controlling current culture in your XAML Windows Store apps

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:

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:

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).