WPF Binding uses the wrong CurrentCulture by default - by omjbe

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


58
0
Sign in
to vote
ID 442569 Comments
Status Closed Workarounds
Type Bug Repros 29
Opened 5/6/2009 1:11:22 AM
Access Restriction Public

Description

WPF Binding uses always "en-US" for the TypeConverters, although you meight have changed the Regional Options in Windows to another culture (e.g. de-DE).

This behavior differs to the one of Windows Forms applications or Console applications.

I would like the WPF Binding to respect the Regional Options of Windows by default, without the need to write extra code.
Sign in to post a comment.
Posted by Rob Grainger on 8/14/2014 at 8:45 AM
Its stunning that this is considered closed. Typical of arrogant US attitudes to the rest of the world!

This is an internationalization bug. It should be fixed.
Posted by lspcity on 7/24/2012 at 12:05 PM
Is Silverlight starting to favour US-american users?
The United States are not the world!

It's okay that the default behaviour points to en-US, but please implement a possibility to switch it to the current region-code the device is using!
Posted by DanDan19 on 5/16/2012 at 2:45 PM
Please fix, I am not American by default.
Posted by YismanOl on 3/25/2012 at 8:37 AM
this is one horrible "by design"!!
Posted by RNEELY on 12/2/2011 at 11:11 AM
For whom is it "designed"- people at Microsoft that want to lower the bar so they can get credit for closing this issue? If this is "by design" then the CultureInfo argument in IValueConverter calls are misleading for developers, by default WPF is not for end-users outside the US, and it is a symptom there is something wrong at Microsoft. Fix it.
Posted by Richard Deeming on 10/5/2011 at 10:15 AM
Worse, with .NET 4.0, you now *cannot* override the default language for the entire application using the OverrideMetaData workaround.

The workaround fixes the culture for elements derived from FrameworkElement, but not for elements derived from FrameworkContentElement, such as the Run. With the workaround, data bound to a TextBlock will use the user's culture, but the same data bound to a Run will use en-US instead.

Trying to extend the workaround to override the meta-data for FrameworkContentElement.LanguageProperty will result in an error, since the meta-data has already been overridden.

The *only* way to make WPF data-binding work as expected is to replace the built-in Binding class with the CultureAwareBinding class (workaround 3).

If this is "by design", then your design is broken. >:(
Posted by Moby Disk on 9/15/2011 at 3:07 PM
This issue still happens in VS2010 SP1 and WPF 4. Microsoft: it is time to re-evaluate this.
Posted by Brett Ryan on 7/11/2011 at 8:23 AM
This is absolutely not acceptable, so what you're suggesting is we hard code our languages into our XAML? That means our applications are not culture aware and must require different XAML versions for the different target countries. This is an arrogant comment from Microsoft.

Please reopen and fix the bug ASAP. If you ask the community and is exposed as the current comments state, we want the expected behaviour of using the current culture.
Posted by Oren Chapo on 6/22/2011 at 6:52 AM
An undesired "by design" behavior means a flaw in design. I would define this issue as a bug in the framework.

It is unacceptable that a UI element will default to a specific language. Please think what would happen if this default was Chinese rather than "EN-US".... I beleive you would then say "well, it IS an undesired behavior". There are too many "non-EN-US" systems deployed around the world to just ignore it.

THIS THROWS AWAY THE ENTIRE IDEA BEHIND LOCALIZATION !!!

The two suggested workarounds are also unacceptable:
1. The "FrameworkElement.LanguageProperty.OverrideMetadata" workaround can only work once (changing the UI culture during runtime will throw an exception the second time you call OverriteMetadata).
2. The custom converter solution is awkward. Why should I write a bugfix myself to a bug in the framework?

Microsoft, please supply either a permanent fix to this problem (in form of a framework patch) or a more reliable workaround.
Posted by Moby Disk on 3/25/2010 at 8:56 AM
I am confused on this -- so how do I make an application that formats date/time strings using the user's current culture settings? It looks like Microsoft is saying that I should make a XAML file for every single language and culture.

Window1-en-US.xaml.cs:
<TextBox Text={Binding Path=DateToDisplay} xml:lang="en-US" />
Window1-en-GB.xaml.cs:
<TextBox Text={Binding Path=DateToDisplay} xml:lang="en-GB" />
Window1-de-DE.xaml.cs:
<TextBox Text={Binding Path=DateToDisplay} xml:lang="de-DE" />
Window1-es-ES.xaml.cs:
<TextBox Text={Binding Path=DateToDisplay} xml:lang="es-ES" />
etc.

Surely that isn't what you are suggesting. There is a workaround, but that workaround still doesn't use the current culture formatting since it loses custom culture settings.
Posted by Horst Klein on 3/18/2010 at 4:32 AM
I hope "By Design" will be the word of the Year!
A lot of things looks great in WPF, but if you use WPF deeper, you will see it dosn't do the thing you think it will do.
And if you read the Online-Books you can't find the reason, why it dosn't work.
So this behavior here should be documented in the Property description!
Today I found this article and i got a workaround, but if this would written in the doc i will found it faster.
So please extend the doc!

StringFormat will be used also outside the US ;-)

Thx Horst
Posted by Stefan 000000 on 10/28/2009 at 3:33 AM
If you change such basic behavior it should be reflected in the documentation; p.E. http://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.stringformat.aspx doesn't mention it.

And I would bet that 99% of the applications that are written in USA cannot be properly used in other countries with different cultures.

Best regards!
Stefan
Posted by Microsoft on 8/26/2009 at 3:07 PM
The default behavior of TypeConverter, String.Format, etc. has led to a number of real and/or perceived bugs. In fact, FxCop now has rules to discourage the use of these APIs without supplying a specific culture. WPF is intentionally different in this respect, trying not to repeat the mistakes of previous frameworks.
Posted by omjbe on 5/24/2009 at 11:49 PM
Thanks for your explanation. Unfortunately, that’s not what I except. Every component (e.g. WinForms, string.Format, TypeConverter) of .NET uses the CultureInfo.CurrentCulture by default which reflects the culture settings of the operating system. Just WPF uses always “en-US” by default.

The result is that most WPF applications I have seen so far show a date or number always in the “en-US” format although the application is running on a German Windows PC.
Posted by Microsoft on 5/22/2009 at 8:39 AM
Binding converters never use the CurrentCulture - this is by design, so that their behavior is predictable across all machines and regional settings.

However, you can specify the culture a converter should use. There are two ways to do this:
1. Set Binding.ConverterCulture. E.g. <TextBox Text="{Binding Birthday, ConverterCulture=de-DE}"/>
2. Set the xml:lang (or equivalently, Language) property on the target element. E.g. <TextBox xml:lang="de-DE" Text="{Binding Birthday}"/>

The converter uses the ConverterCulture if present, and the xml:lang otherwise. The latter property is always defined - it defaults to "en-US". It's an inherited property, so you can set xml:lang="de-DE" on the root element of your markup to get all the converters on the page to use the desired culture.
Posted by Microsoft on 5/6/2009 at 8:02 PM
Thanks for your feedback.

We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team