In this post I will describe a solution for easy localized strings management in XAML or C#. Precisely, we will use the usual recommended material for manipulating localized strings in .NET: resx files and the ResourceManager class. However, for XAML manipulation, we will add a “type layer” on top of this. We will see that having typed resources can be very useful. The “type layer” is basically an interface where string properties contain the localized strings, then in XAML or C# code the translations are accessed by using directly these properties. To avoid painful repetitions, the implementation of the interface is dynamically generated using some very simple MSIL.
To conclude, we will write simple unit tests that check that the translation files (.resx) contains all the localized strings for all supported languages.
First, let us recall that it is really important that your localized strings are not dispersed in the source code of your application. Using a code snippet of the following form is a bad practice.
Indeed, it is very important that you keep grouped all the translations for a given language in one file. Then, you could rework your translations on your own or with a professional without having to grep the entire code base.
Fortunately, .NET comes with all the material you need to handle Culture-Specific resources with the ResourceManager. Say you support english (default) and french languages then you have two .resx files which contains key/value string entries. Such files are named LocalizedStrings.resx and LocalizedStrings.fr-FR.resx they may contain, among others, the entry SayHello (“Hello!” in english and “Bonjour !” in french). Finally, you only have to initialize the ResourceManager and getting the localized strings as follows.
It is important to note that the right file (*.resx or *.fr-FR.resx) is automatically chosen using the Tread.CurrentThread.CurrentUICulture.
When manipulating XAML for the UI of your app, creating a type for the localized string is recommended. Indeed, in XAML you can bind to properties but you cannot (at least not easily) bind to methods. So the recommended method from the MSDN is to create a LocalizedStrings class whose members are the localized strings.
So we can create the LocalizedStrings class
While the instance is retrieved using a Singleton-like pattern (there is no reason to mock this for testing so it makes sense to use a singleton here).
We can use easily the LocalizedStrings in the xaml after adding the StringLocalizer has an application resource.
Obviously we can use the same class in the plain old C#
Using this “type layer” is not only mandatory for XAML it is also very useful because we benefit from the static typing. Indeed, typing help us to create localized strings list that do not contain tons on unused entries. Even if this is not a matter of life or death, it is a good thing to remove unused localized strings from your dictionaries, because they going to cost you some effort or money when you will make new languages available or if you want to review the terminology used in your application. The only thing you have to do is to search for unused member of the class (the plugin Resharper does this well even in XAML).
As shown in the image below the XAML-intellisense of Resharper shows us all members of the interface which is handy to reuse localized strings.
Still there is one thing which is cumbersome, every-time you create a new entry you have to type the same logic for the property: _rem.GetString(“NameOfTheProperty”). Then, it’s time to be nerdy and find a way to do this automatically! Let us replace the LocalizedStrings class by and interface ILocalizedStrings whose implementation is dynamically generated. You can emit dynamically new type in .NET using the ILGenerator. So this is the implementation of the new StringLocalizer with some help from the .NET IL guru Olivier Guimbal.
So here it is what the interface looks like
And here is the StringLocalizer
To conclude let us write unit tests to ensure that all properties in the interface ILocalizedStrings are defined on all .resx files and, reciprocally, to make sure that all keys in the resx files are properties of the interface. This will help us to track non translated entries and to remove useless keys in the resx dictionaries. We basically parse the .resx files to retrieve all keys and use reflexion to get all public properties of the interface. The test fail when problematic entries are discovered and printed in the test console.