This article is compatible with the latest version of Silverlight.
Most developers would prefer to hear that “this is the right way to do Internationalization”, but as with just about anything in the software development world, there are several different ways to do it. The standard response to the “what is the right way?” question is “it depends”. None of these methods are ‘right’ or ‘wrong’, but they do each have their pros and cons. Here are just some of the options:
Method 1 - Microsoft Silverlight Business Application
You may want to create a new project in VisualStudio using this template just to see how it’s done. After creating the solution search for ResourceWrapper. This is a class in the Helpers directory that returns an instance of each .resx class.
Pros:
· The code/approach is already there for the taking.
· Promotes a consistent approach to Internationalization.
Cons:
· Strings that are added to .resx files by the developer and displayed in the UI cannot be unit tested.
· If someone changes the name of one of the .resx keys, the app will compile and there will be no runtime error…the string just won’t show up in the UI.
Method 2 - Telerik LocalizationManager
This is a very simple approach that is outlined in the Localization chapter of the Telerik RadControls Silverlight Courseware document, and can be used across all controls in a Silverlight application (not just Telerik controls).
Pros:
· Easy to implement.
· Promotes a consistent approach to Internationalization.
Cons:
· Strings that are added to .resx files by the developer and displayed in the UI cannot be unit tested.
· If someone changes the name of one of the .resx keys, the app will compile and there will be no runtime error…the string just won’t show up in the UI (in the case of a Button’s Content, the button will be blank).
Method 3 – Code behind
Because each entry in a .resx file can be accessed via code, the following would be an example of a line in the code-behind:
lblDate.Text = MyStrings.Label_Date;
And this would be the XAML:
<Label x:Name="lblDate"/>
Pros:
· The developer has access to Intellisense when typing the code. (It will appear after typing ‘MyStrings.’)
· If someone changes the name of one of the .resx keys, the app will not compile, so it is less error-prown.
· Some developers prefer a strongly-typed, code-based approach.
· The XAML is very clean.
Cons:
· Some developers prefer to keep their code-behind void of any code (other than the necessary call to InitializeComponent).
Method 4 - MVVM
With this approach, each string is returned from a property in the ViewModel class. For example, this read-only property would live in the ViewModel class:
public string ResourceLabelDate
{
get { return MyStrings.Label_Date; }
}
And the XAML would bind to the property like this (assuming that the ViewModel is the DataContext for the UserControl/Page that this code resides in):
<TextBlock Text="{Binding ResourceLabelDate}"/>
Pros:
· Unit tests can be written against the ViewModel’s resource properties.
· The XAML is very clean.
Cons:
· It bloats the ViewModel code by adding properties for each string in the UI.
Final Thoughts
Because I am an MVVM purist, I prefer the MVVM approach. I like my XAML to be clean, don’t mind having a bunch of properties in my ViewModel (I can always wrap them in a region if I want), and can write unit tests against them if I wish. I will demonstrate this technique in my next post Step by step example – MVVM approach.
Having said that, there is no right way or wrong way to implement internationalization, but whichever method you choose, it is wise to implement one of these strategies (or another one if you find a different method that you prefer).