Skip to content

FrameworkElement.Language does not use culture user overrides #1946

Open
@miloush

Description

@miloush
  • .NET Core Version: 3.0.100
  • Windows version: 18985.1.amd64fre.vb_release.190913-1426
  • Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes

Problem description:
Applying FrameworkElement.Language and related Language properties 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:

<Window x:Class="TestWpfBugs.StaticProperties.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:s="clr-namespace:System;assembly=mscorlib"
        Language="en-GB">
    <TextBlock DataContext="{x:Static s:DateTime.Now}" Text="{Binding}" />
</Window>

(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 XmlLanguage calls new CultureInfo(name, useUserOverride) when converting the string into culture. The actual behavior passes false for the useUserOverride while the expected behavior would mean passing true instead.

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

  1. letting developers to override language with an instance CultureInfo rather than just a name string, possible with an extra property of type CultureInfo that would be used if set (either on XmlLanguage or FE, otherwise fallback to Language.
  2. introducing new property e.g. UseLanguageOverride on XmlLanguage supporting returning user overridden cultures, possibly but not necessarily with an extra property on FE too.
  3. introducing special XML language strings meaning "current culture" and "current UI culture".

Any thoughts?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Enhancement RequestedProduct code improvement that does NOT require public API changes/additions

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions