Although swapping out language resources is something that happens somewhat automatically when the user changes system language, sometimes you want to know that directly.
There are a number of APIs in WinRT that relate to this (thanks to Erik Fortune for this):
- Windows.System.UserProfile.GlobalizationPreferences contains all of the languages requested by the user, in priority order. This list is the user-specific set from the “Languages” area ub control panel, and might include languages that any given app cannot support.
- Windows.Globalization.ApplicationLanguage.ManifestLanguages lists all languages that the application supports, as defined in the app manifest, and might include languages that the user does not understand.
- Windows.Globalization.ApplicationLanguage.PrimaryLanguageOverride is a persistent single language setting that can override user and app defaults. Because this is persistent (and expensive), it should not be used for temporary overrides.
- Windows.Globalization.ApplicationLanguage.Languages is the list of languages actually used to display the app UI. It’s constructed from the User Language Profile, the Manifest Languages and the Primary Language Override.
That said, you’ll notice that none of these just say “this is the language that’s in use across the system.” What a number of developers have done, then, instead of trying to infer this from the above APIs, is to simply include a language tag in your localized resources. Because one set of resources will be loaded for the current language–assuming there’s not an override–you need only retrieve that string and you know the language in use.
Do note that all of this applies only to language; if you want to know where the user actually is, always use Windows.System.UserProfile.GlobalizationPreferences.HomeGeographicRegion. That is, people can be using any language in a system regardless of where they’re located in the world, so you need to use the specific region instead.