I am currently assigned to a project to come up with a best approach for the WPF application architecture right from UI design to the Data Services. It’s a complex work which involves multiple layers and modules to be designed. As a part of my work I was doing some R&D on WPF or XAML localization approach.

When it comes to localization for WPF application we have so many thoughts and approach. Let me start with my favorite site and ultimate site (MSDN). Before making any decision on solution or technology for Microsoft Platform MSDN is the best way to start with. MSDN articles give you a very good understanding about technology and the concepts…

Microsoft recommended approach

http://msdn.microsoft.com/en-us/library/ms788718.aspx

http://msdn.microsoft.com/en-us/library/ms746621.aspx

I started off by reading the above article from MSDN for localization. I felt pretty complex to perform localization for WPF, because it involves too many steps to convert resx files or resource dictionary into satellite assembly. But the advantage is no need to modify XAML, development & localization can happen in parallel and can be updated later, sounds cool rt. But I want to do further more research…

Using LocBaml tool

http://www.codeproject.com/KB/WPF/Localization_in_WPF.aspx

The above article gives a good idea about how to use the LocBaml tool. But again it discuss the same LocBaml approach.

WPF Globalization using external xml file

http://www.codeproject.com/KB/WPF/WPF-Mulit-Lingual.aspx

The above approach was so cool; they use XML and XMLdataprovider with XPath and query to load the language string. The advantage of the above approach is no binary dll or the satellite dll. All the languages are saved in the xml file and changing the language is very easy and no need to compile the resource again if the text changes. But the problem is XML file management will be night mare if the application is too big like ours. So this option also ruled out in my case.

Choice of Approach discussed in codeproject

http://www.codeproject.com/KB/WPF/WPFUsingLocbaml.aspx

Above article discusses 3 approaches:

1. Using Resx and adding namespace to the XAML

2. LocBaml tool to extract csv and compile to satellite assembly using ResourceDictionary.

3. LocBaml tool using Resx files to build the satellite assembly

Also the article discusses the pros and cons of each method at the last. By this time I finished reading all those articles, now I am well versed with the available approaches and what needs to be done for WPF globalization. But still my mind was in dilemma to which approach to use.

Additional Resource

http://robbbloggg.blogspot.com/2008/03/xaml-localization.html

The above blog is similar to mine where he discusses about all the approaches and finally used his own approach to fit his requirement. But I am not convinced with his approach. Because his one of the concern is the resource binding can be applied ONLY to the dependency properties of the DependencyObject descendants. But in my case I do binding only to the DependencyObject descendants.

LinoBit Product

http://www.lingobit.com/products/index.html

With enough knowledge on the XAML localization I don’t want to re invent the wheel so I thought of any already available component or the product which can make localization easier for my application. The above product is available but to be frank I haven’t tried that product. So I cannot comment on this. So as a default IT guy I started looking for free component which does an easy job for me.

WPL Localization Extension

http://www.codeplex.com/WPFLocalizeExtension

Finally I landed here in this site. The home page alone lists down the feature the component supports. Wow its awesome it has all the functionality which I was looking for. Its ultimate feature is that is the localized text is available in the design time in VS 2008 sp1. And another good feature is that the language can be changed at runtime without touching the Threading cultureinfo.

Below are the features it supports

• first of all: ITS FREE (and will stay free)
• supports binding-like write style like "Text = {LocText ResAssembly:ResFile:ResKey}"
• if ResAssembly and / or ResFile is the default, you can skip these parameters to ResAssembly::ResKey, ResFile:ResKey or only ResKey
• works with the .resx-fallback mechanism (e.g. en-us -> en -> independent culture)
• supports culture forcing (e.g. "this has to be English all the time")
• works with normal dependency properties
• works with control templates
• can be used in xaml (really :P) without any additional namespace
• can be used in code behind to bind localized values to dynamic generated controls
• implements INotifyPropertyChanged for advanced use
• supports formatting e.g. "this is the ‘{0}’ value"
• supports prefix and suffix values (currently with LocText extension)
• is in use in productive systems (like my public relation product)
• switching of the language to runtime affects NO time slice
• can be used with any resource file (.resx) across all assemblies (also the dynamic loaded one at runtime)
• don’t need any initializing process (like "call xyz to register a special localize dictionary")
• is available at design time (MS Expression Blend, MS Visual Studio 2008 (Normal and SP1)
• not for dynamic loaded assemblies which only can be found at runtime and as long the resource (.resx) is builded at designtime
• change of the choosen language is possible at designtime
• can localize any type of data type, as long a converter (TypeConverter) for it exists (extend LocalizeExtension)
• has build in support for Text, upper Text, lower Text, Images, Brushes, Double and Thickness
• leaves the UID property untouched
• offers a "SpecificCulture" to use as IFormatProvider (e.g. (123.20).ToString(LocalizeDictionary.SpecificCulture) = "123.20" or "123,20")
• offers some functionality to check and get resource values in code behind
• don’t alter the culture on Thread.CurrentCulture or Thread.CurrentUICulture (can be changed easily)