Skip to main content

Building a multilingual MVVM app

Last week I built a sample multilingual app in WPF using MVVM for a proof of concept. This was the first time I've built a desktop app which supported different languages at runtime. Previously I've worked on multilingual websites and desktop apps but not ones that support changing the language of the UI dynamically via a UI control like a menu item.

The app was pretty simple, a single input field representing a number where the value has to be within a fixed range (-100 to 100). If the input failed the validation an error message would be displayed.

What I came up with is shown below, it supports three cultures - English, French & German. The culture (language) is selected by either the menu or the F1 - F3 keys. How I achieved this is what follows.
What I wanted to achieve was the model & view model being agnostic to any concern about the currently selected culture (language). The view model used for the English version should be the same for the French or German versions.

The model we'll be binding via the view model is shown below, as you can see no knowledge of the currently selected UI language.
The view model is shown below, this will be bound to the view via an implementation of the view model Locator pattern.
The view model like the model also has no knowledge of the currently selected UI language. What should also be noted is the lack of validation in the view model. Normally if one was developing an app for a single culture you could use the IDataErrorInfo interface in the System.ComponentModel to return the required validation message. This could have been done in this example, but I ddidn't want the view model to know anything about the current culture, if I had used it I would then have to worked out the current culture and then selected the correctly translated message. I see the concern of translating the validation message a responsibility of the view not the view model.

I did the validation via a custom validation rule - by implementing my own validation rule this allowed me to code up the required field input rules - a number where the value has to be within a fixed range (-100 to 100).
This is where the concerns of the UI culture start to come into play, the last two lines of the above validation rule take care of loading the correct culture invalid input message. How exactly this is done is described later. This is then used declarative in the view XAML, thus pushing the input validation to the correct area of concern, the view:
The  colours used for displaying the validation message are controlled by the style applied to the TextBox control, it defines when and how the validation tool-tip fades in & out.

What you can see from the XAML is a converter applied to the binding, this will only be called if the input validation executes successfully. The converter is also affected by the current UI culture, as you can see it is passed to each method. This means the double.Parse will correctly handle what ever number separators are defined for the culture:
That covers all the other parts required for multiple culture support, but the question still remains:

How exactly are the different cultural string being render by the view?

This is where it started to get complex for the simple reason the documentation on how to do this is confusing, I couldn't find a coherent strategy on MSDN. Googling for 'multilingual support WPF' does list MSDN as the first result, after reading through this I just started to get a headache...

I was looking for a way to declaratively define which strings need to support multiple cultures, it also need to separate the cultures into different files. I knew I was going to need to work with resource files (*.resx). The Google search above provided a lot of links pointing to solutions available on, I counted at least 5 different ways on the first page.

I decided to go with first in the list - 'WPF Localization Using RESX Files'. This solution provided both a declarative (XAML) and imperative (code-behind) methods, in fact it turned out to be so simple I can't believe you can't get this package on NuGet.

I recommend reading the article for the full details on how to add support to your app. First off I modified  the XAML by adding the a declaration at the top of the page:
Then I updated all string values that need to support multiple cultures:
The ResxExtension.DefaultResxName property in the window declaration defines where to find the required resx file. As you can see from the screen shot below there are also separate RESX files for the French & German resources:
The English & German resource properties window from visual studio are shown below:
Each RESX file needs to define the Custom Tool & Custom Tool Namespace via the properties window in visual studio. This is so the RESX file is compiled and available in C# code - that's how we access the resource in the last 2 lines in the custom validator earlier:
RESX file properties in visual studio:
The only thing left now is how to change the culture at runtime. I did this via a menu, but in theory this could be done any suitable UI control. All I did was declare a menu items in the XAML and then wire in the click events to the code-behind of the view:
Declared in the XAML:
As you can see the Header properties are bound to the resource manager and the click events are handled in the code behind. The code behind is initialised as follows;
We add an event handler for when the culture changes so we can update the menu items:
We also added the key bindings F1 - F3 to allow a keyboard drive approach. As you can see the English is represented by F1 and the command is routed through to the HandleEnglish method, this is an overload of the method wired in via the XAML for the English menu click. This is where the real magic happens the resource manager is updated with the new culture and instantaneously everything declared with a Resx binding in the XAML automatically updates:
Bring this all together gives me the ability to do any multilingual support in the view of my MVVM implementation.

I've put the implementation up on skydrive:


Popular posts from this blog

WPF tips & tricks: Dispatcher thread performance

Not blogged for an age, and I received an email last week which provoked me back to life. It was a job spec for a WPF contract where they want help sorting out the performance of their app especially around grids and tabular data. I thought I'd shared some tips & tricks I've picked up along the way, these aren't probably going to solve any issues you might be having directly, but they might point you in the right direction when trying to find and resolve performance issues with a WPF app. First off, performance is something you shouldn't try and improve without evidence, and this means having evidence proving you've improved the performance - before & after metrics for example. Without this you're basically pissing into the wind, which can be fun from a developer point of view but bad for a project :) So, what do I mean by ' Dispatcher thread performance '? The 'dispatcher thread' or the 'UI thread' is probably the most

Showing a message box from a ViewModel in MVVM

I was doing a code review with a client last week for a WPF app using MVVM and they asked ' How can I show a message from the ViewModel? '. What follows is how I would (and have) solved the problem in the past. When I hear the words ' show a message... ' I instantly think you mean show a transient modal message box that requires the user input before continuing ' with something else ' - once the user has interacted with the message box it will disappear. The following solution only applies to this scenario. The first solution is the easiest but is very wrong from a separation perspective. It violates the ideas behind the Model-View-Controller pattern because it places View concerns inside the ViewModel - the ViewModel now knows about the type of the View and specifically it knows how to show a message box window: The second approach addresses this concern by introducing the idea of messaging\events between the ViewModel and the View. In the example below

Implementing a busy indicator using a visual overlay in MVVM

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v