weltkante
commented
5 years ago The problem is that WPF expects the XmlLanguage name to be equivalent to the CultureInfo in some places, so the name must be unique and must not cause mismatches between the true CultureInfo and a customized one.
I'm using this as a workaround:
public static void InitializeCurrentLanguageForWPF()
{
// Create a made-up IETF language tag "more specific" than the culture we are based on.
// This allows all standard logic regarding IETF language tag hierarchy to still make sense and we are
// compatible with the fact that we may have overridden language specific defaults with Windows OS settings.
var culture = CultureInfo.CurrentCulture;
var language = XmlLanguage.GetLanguage(culture.IetfLanguageTag + "-current");
var type = typeof(XmlLanguage);
const BindingFlags kField = BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.DeclaredOnly;
type.GetField("_equivalentCulture", kField).SetValue(language, culture);
type.GetField("_compatibleCulture", kField).SetValue(language, culture);
if (culture.IsNeutralCulture)
culture = CultureInfo.CreateSpecificCulture(culture.Name);
type.GetField("_specificCulture", kField).SetValue(language, culture);
FrameworkElement.LanguageProperty.OverrideMetadata(typeof(FrameworkElement), new FrameworkPropertyMetadata(language));
}To make something like this possible without reflection we just need to be able to define a custom XmlLanguage based on a CultureInfo. Since the IETF language tag is not optional the only way to make this working is by adding a custom suffix. Even though this is not an "official" IETF language tag it should be as close as you can get compatibility wise. (You don't want to use an official IETF language tag with a custom CultureInfo because that can cause bugs when roundtripping, using a custom tag at least makes it clear what the cause is when anything goes wrong, and "correctly written" code can still generalize the custom tag properly to actually existing languages.)
mrlacey
Dunge
prlcutting
miloush
Problem description: Applying
FrameworkElement.Languageand relatedLanguageproperties does not take into account current culture settings. There is no way how to supply a specific instance of CultureInfo to the WPF infrastructure.Minimal repro:
(this assumes English (United Kingdom) to be used for formatting. Use other cultures accordingly.)
Go to Settings > Time and Language > Region > Change data formats and change Short date format to a non-default option, e.g. yyyy-MM-dd. Run the WPF app.
Actual behavior: Current culture settings not respected, the date is shown as dd/MM/yyyy.
Expected behavior: The date to be in the selected format.
Ultimately, the
XmlLanguagecallsnew CultureInfo(name, useUserOverride)when converting the string into culture. The actual behavior passesfalsefor theuseUserOverridewhile the expected behavior would mean passingtrueinstead.As a result, there isn't any way I am aware of to make the WPF infrastructure use the current culture that user prefers other than annotating all data bindings and template bindings with converters with explicit cultures, which is a considerable performance hit if possible at all.
Clearly changing the current behavior would not only be a compatibility break but also prevent people from using non-overridden cultures, but there might be other solutions, such as (in decreasing number of scenarios it would allow):
CultureInforather than just a name string, possible with an extra property of typeCultureInfothat would be used if set (either onXmlLanguageor FE, otherwise fallback toLanguage.UseLanguageOverrideonXmlLanguagesupporting returning user overridden cultures, possibly but not necessarily with an extra property on FE too.Any thoughts?