I recently got a note around a pestering issue in utilizing StringFormat as a part of XAML binding expressions and how it doesn't respect current user’s culture settings. This is genuine that there is an issue in that it doesn't in WPF or Silverlight. In the event that you don't hear what I'm saying, Silverlight acquainted the capacity with utilization StringFormat in data binding expressions (WPF has had this since 3.5 SP1) so you could do some formatting in-line in your binding.  Like this:

<TextBlock Text="{Binding Path=CurrentDate, StringFormat=Current Timestamp is: \{0:G\}}" />

This would bring about content that future organized straightforwardly utilizing your string Formatter without the requirement for code-behind or any non specific ValueConverter. This is an extremely accommodating gimmick for organizing UI values and at times trading ValueConverters for straightforward assignments.

The issue is that StringFormat isn't regarding the client's way of life settings. Take for instance this complete XAML:
<StackPanel x:Name="FooContainer">
<TextBlock x:Name="CultureInfo" />
<TextBlock x:Name="UICultureInfo" />
<TextBlock Text="{Binding Path=CurrentDate, StringFormat=Current Timestamp is: \{0:G\}}" />
<TextBlock x:Name="CostField" Text="{Binding Path=Cost, StringFormat=Cost is: \{0:c\}}" />
 <toolkit:GlobalCalendar  />
</StackPanel>
This is being sure to a straightforward item that uncovered two properties for the reasons of showing: CurrentDate (DateTime) and Cost (double). Utilizing my standard US-English settings and territorial inclination the result would be:

Presently, give me a chance to tell my Silverlight application that I have an alternate culture information.  I can do this without having to force a language pack installation of sorts and completely change my machine. Including the way of culture/uiculture params to the <object> tag does the trap. I'll transform it to "de-de" for German. Here is the new output:

Indeed the settings perceive an alternate culture, StringFormat is not doing what I anticipate. I would have expected an alternate date show for German settings (d.m.yyyy) and an alternate currency display instead of dollars.

Shockingly this is an issue in StringFormat at this time, however there is a simple workaround that if you are creating a localized app you can add to your code that shouldn’t affect your default language settings either.  In my constructor I add this line of code:
this.Language = XmlLanguage.GetLanguage(Thread.CurrentThread.CurrentCulture.Name);

This advises the markup system to utilize the current culture settings as the UI language. XmlLanguage is a piece of the System.Windows.Markup namespace, so guarantee you get that out explicitly or add a using statement.  Now refreshing my German settings sample I get:

Not surprisingly. Changing (or removing the explicit setting of culture in my  <object> tag) back to my default culture settings brings about my US-English preferences being used and no need for me to change the XAML.

HostForLIFE.eu Silverlight 5 Hosting
HostForLIFE.eu is European Windows Hosting Provider which focuses on Windows Platform only. We deliver on-demand hosting solutions including Shared hosting, Reseller Hosting, Cloud Hosting, Dedicated Servers, and IT as a Service for companies of all sizes. We have customers from around the globe, spread across every continent. We serve the hosting needs of the business and professional, government and nonprofit, entertainment and personal use market segments.