I’m happy to announce that my WPF Localization paper went live a couple of days ago on CodePlex. You can find it here:
http://wpflocalization.codeplex.com/ (click on Downloads – it’s published only as PDF <shrug>)
I’ve been working on this document for quite some time and those that follow this blog and twitter probably already know that it’s been an interesting journey. It’s a very long document as it covers a whole range of topics from some localization overview, the basic .NET localization infrastructure to the actual localization approaches using LocBaml and Resx resources as well as couple of custom approaches using custom markup extensions and attached properties. There are a lot of topics covered, and for once though it was actually supposed to be this long based on the article specs on the contract.
The reason for the length is primarily that WPF localiztion doesn’t just take a single path. Unlike previous Windows desktop technologies that preceded it, WPF does not have one clear path to localization and no direct tool support in Visual Studio or Blend. This means the choices for localization are left up to the developer to explore and figure out.
The two major choices available are using LocBaml for localizing XAML resources or using the more traditional Resx approach. LocBaml focuses on using the XAML document itself as a resource store and allows for exporting of these XAML resources for localizations after development is complete. The rigid LocBaml approach lends itself to applications that are completed and won’t change much (yeah right – is there really such a thing?) but is not a good choice for applications that need to be incrementally localized. Resx provides better tool integration in Visual Studio with support for resource editing right in Visual Studio as well as the ability to create strongly typed resource classes from Resx resources. However, there’s no direct designer support for the locailzation content which means you manually have to hook up resource keys to properties of elements or at the very least assign some sort of marker property so a custom extension can map resources to properties. For WPF accessing Resx resources involves the manual process of mapping resource ids to XAML elements for binding which is more work up front compared to LocBaml but allows for more flexibility when updating applications at a later point. The Resx approach also has number of options available. The simple x:Static binding markup extension makes for easy bindings of strongly typed resources to properties using simple, built-in binding syntax. For more control custom markup extensions or attached properties can be used to provide custom binding to Resx resources.
The LocBaml approach is interesting in that it defers localization until the end of a project, but in its current form with the limited tool support in LocBaml itself and lack of integration the process of localization is very fragile – it’s very easy to break the CSV localization files and have to start over or roll back to a previously saved version. Using LocBaml it’s definitely worthwhile to back up constantly! Resx offers a more traditional approach and while it’s definitely more work during development I feel that this is the more stable and consistent approach to localization at this time. There are lots of choices available for Resx localization as well beyond what has been discussed in this white paper, many of them interesting and innovative. Lots of innovation around Resx extensions, but nobody seems to be extending LocBaml.
The bottom line is that as a WPF developer you need to spend a little time with each of these approaches to get a feel for what works for you and what works for your localization staff. Choices are good, but arriving at the right one unfortunately can take a little extra time. I’m hoping that the white paper provides a good background on some of the tools available and a better understanding what to look for in any solution you use for WPF localization. I doubt that this is the final word in WPF localization – I suspect at some point there will be some proper tooling provided, but as of the current version of .NET (3.5SP1) and as far as I can see of .NET 4.0 Localization for WPF hasn’t seen a lot of love from Microsoft. <shrug>
I’ve also had the pleasure of working with Michele Leroux Bustamante on this project who did a bang up job on final editing and providing feedback in the course of writing. Michele of course is one of the THE experts in Localization in WPF and I felt honored being asked to help out by writing this white paper and take on the WPF Localization topic.
Anyway, I hope this article will prove useful to developers if for nothing else than putting a lot of the information that is out on the Web for WPF Localization into one comprehensive document that can act as a starter before going off looking at the wide variety of custom solutions available. It’ll be a good place to start and hopefully give you a good idea on what approach is closest to the way you like to work.
Check it out.
I'll be at DevIntersection in Vegas this fall giving sessions on ASP.NET Core with Angular and Localization. Thinking of coming? Use discount code STRAHL and save a few bucks. If you do be sure to stop by and say hello!
Other Posts you might also like