The community is working on translating this tutorial into Danish, but it seems that no one has started the translation process for this article yet. If you can help us, then please click "More info".
If you are fluent in Danish, then please help us - just point to any untranslated element inside the article and click the translation button to get started. Or have a look at the current translation status for the Danish language.
If you see a translation that you think looks wrong, then please consult the original article to make sure and then use the vote button to let us know about it.
Please help us by translating the following metadata for the article/chapter, if they are not already translated.
If you are not satisfied with the translation of a specific metadata item, you may vote it down - when it reaches a certain negative threshold, it will be removed. Please only submit an altered translation of a metadata item if you have good reasons to do so!
Application Culture / UICulture
If you have worked a little bit with numbers or dates in your WPF application, e.g. because of one of the articles found in this tutorial, you may have noticed something cool: Numbers and dates are automatically displayed in a format that matches the format used on your computer. If you live in an English-speaking country, this is probably doesn't seem like a big thing, but if you live in one of the MANY countries where dates and/or numbers are displayed differently, this is really cool.
And if you're thinking "surely there can't be that many differences when formatting simple stuff like numbers and dates?", I suggest that you have a look at this sample app, where I have formatted the same number and the same date in accordance with how they prefer it in the US, Germany and Sweden:
So as you can see, there are many subtle differences in how numbers and dates are displayed. The good news is that the .NET framework can help you out a lot - in fact, it already does: By default, dates and numbers are formatted in accordance with the system settings of the computer where your application are executed. The bad news is that this behavior might not always be what you want. But don't worry - you can easily change this. It all relates to the use of the CultureInfo class, which you can read much more about in the C# Tutorial article on CultureInfo. For now, let's discuss how to apply these techniques to your WPF application.
If you only need to apply formatting for a specific piece of information, e.g. the contents of a single Label control, you can easily do this, on-the-fly, using a combination of the ToString() method and the CultureInfo class. For instance, in the example above, I applied different, culture-based formatting like this:
double largeNumber = 123456789.42;
CultureInfo usCulture = new CultureInfo("en-US");
CultureInfo deCulture = new CultureInfo("de-DE");
CultureInfo seCulture = new CultureInfo("sv-SE");
lblNumberUs.Content = largeNumber.ToString("N2", usCulture);
lblNumberDe.Content = largeNumber.ToString("N2", deCulture);
lblNumberSe.Content = largeNumber.ToString("N2", seCulture);
This might suffice for some cases, where you just need special formatting in a couple of places, but in general, you should decide if your application should use system settings (the default) or if you should override this behavior with a specific culture-setting for the entire application.
CurrentCulture & CurrentUICulture
Applying another culture to your WPF application is quite easy. You will, potentially, be dealing with two attributes, found on the CurrentThread property of the Thread class: CurrentCulture and CurrentUICulture. But what's the difference?
The CurrentCulture property is the one that controls how numbers and dates etc. are formatted. The default value comes from the operating system of the computer executing the application and can be changed independently of the language used by their operating system. It is, for instance, very common for a person living in Germany to install Windows with English as their interface language, while still preferring German-notation for numbers and dates. For a situation like this, the CurrentCulture property would default to German.
The CurrentUICulture property specifies the language that the interface should use. This is only relevant if your application supports multiple languages, e.g. through the use of language-resource files. Once again, this allows you to use one culture for the language (e.g. English), while using another (e.g. German) when dealing with input/output of numbers, dates etc.
Changing the application Culture
With that in mind, you now have to decide whether to change the CurrentCulture and/or the CurrentUICulture. It can be done pretty much whenever you want, but it makes the most sense to do it when starting your application - otherwise, some output might already be generated with the default culture, before the switch. Here's an example where we change the Culture, as well as the UICulture, in the Application_Startup() event which can be used in the App.xaml.cs file of your WPF application:
private void Application_Startup(object sender, StartupEventArgs e)
Thread.CurrentThread.CurrentCulture = new CultureInfo("de-DE");
Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
Since we use the Thread class as well as the CultureInfo, don't forget to add the required namespaces to your file, if they are not already present:
With this in place, numbers and dates will now be formatted according to how they prefer it in German (de-DE). As mentioned, you can leave out the line defining the culture for the UICulture (the last line) if your application doesn't support multiple languages.
Changing the culture during the Application_Startup event, or at the latest in the constructor of your main window, makes most sense, because values that are already generated aren't updated automatically when you change the CurrentCulture property. That doesn't mean that you can't do it though, as illustrated by this next example, which also serves as a fine demonstration of how the output is affected by the CurrentCulture property:
Title="ApplicationCultureSwitchSample" Height="200" Width="320">
<RowDefinition Height="Auto" />
<RowDefinition Height="Auto" />
<ColumnDefinition Width="*" />
<ColumnDefinition Width="*" />
<Label Name="lblNumber" Grid.Column="1" />
<Label Name="lblDate" Grid.Row="1" Grid.Column="1" />
<StackPanel Orientation="Horizontal" HorizontalAlignment="Center" Margin="0,20">
<Button Tag="en-US" Click="CultureInfoSwitchButton_Click" HorizontalContentAlignment="Stretch">English (US)</Button>
<Button Tag="de-DE" Click="CultureInfoSwitchButton_Click" HorizontalContentAlignment="Stretch" Margin="10,0">German (DE)</Button>
<Button Tag="sv-SE" Click="CultureInfoSwitchButton_Click" HorizontalContentAlignment="Stretch">Swedish (SE)</Button>
public partial class ApplicationCultureSwitchSample : Window
private void CultureInfoSwitchButton_Click(object sender, RoutedEventArgs e)
Thread.CurrentThread.CurrentCulture = new CultureInfo((sender as Button).Tag.ToString());
lblNumber.Content = (123456789.42d).ToString("N2");
lblDate.Content = DateTime.Now.ToString();
The interesting part is found in the CultureInfoSwitchButton_Click event, where we set CurrentCulture based on which of the buttons were clicked, and then update the two labels containing a number and a date:
Culture & Threads: The DefaultThreadCurrentCulture property
If your application uses more than one thread, you should consider using the DefaultThreadCurrentCulture property. It can be found on the CultureInfo class (introduced in .NET framework version 4.5) and will ensure that not only the current thread, but also future threads will use the same culture. You can use it like this, e.g. in the Application_Startup event:
CultureInfo.DefaultThreadCurrentCulture = new CultureInfo("de-DE");
So, will you have to set both the CurrentCulture AND the DefaultThreadCurrentCulture properties? Actually, no - if you have not already changed the CurrentCulture property, setting the DefaultThreadCurrentCulture property will also be applied to the CurrentCulture property. In other words, it makes sense to use the DefaultThreadCurrentCulture instead of CurrentCulture if you plan on using multiple threads in your application - it will take care of all scenarios.
Dealing with the culture of your WPF application is very important, but fortunately for you, WPF will do a lot of it for you completely out-of-the-box. If you need to change the default behavior, it's quite easy as well, using the CurrentCulture and CurrentUICulture properties, as illustrated in the numerous examples of this article.