WPF Localization Guidance Paper Posted on CodePlex

July 01, 2009 • from Hood River, Oregon • 7 comments

On this page:

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.

The Voices of Reason

Mike Gale
July 01, 2009

# Warn about PDF on the link

I'm always interested in the reason's for publishing as PDF.

Are you able to share that?

(With some strong exceptions, I generally find PDF is a lot bigger [x10] for reduced impact [/3], compared to a competent web page. It can be annoying to read.)

It's worth warning about PDF on the originating link.

Rick Strahl
July 01, 2009

# re: WPF Localization Guidance Paper Posted on CodePlex

@Mike - Yeah I agree. PDF is a lousy format especially for tech articles - cutting and pasting code out of them is a pain for one thing.

I have no control over the publishing of the article. This is how the other guidance papers in the series are done on the site unfortunately. I think this may be changed at a later time once the admins have all the docs in the series, but for now we're stuck with PDF.

david
July 02, 2009

# re: WPF Localization Guidance Paper Posted on CodePlex

i wanted to ask you a globalization question in general, not specifically regarding WPF, if i may.

i've been kicking around best practices for resource key names. i tend to look at the problem from a CSS background, where it's always been by standard to not name classes like:

Arial12ptBlueBold: { font-family... }

the reason being, if you decide to change the font size, you have an "outdated" class name. instead i name the class something like:

productLabel: { font-family... }

with that said, i'm tend to try and name resource keys with a name for what they represent, not the words they contain (in the default translation).

so, for example, if i have a grid with a column that has a customer name, i would name the resx key something like "CustomerGridCustomerName" and the resx value would be "Name" or whatever. The point is, i tend to try to avoid translating word-to-word, effectively giving me a quasi-dictionary. i don't like resource files like this (key - value):

Hello World - Hello World (welcome message)
Quit - Quit (text on button to cancel)
OK - OK (text on button to Save something)

instead, i tend to create keys like the comments above

WelcomeMessage - Hello World!
ExitButtonText - Quit
SaveButtonText - OK

that way, if i decide the text changes, my resource key is not automatically outdated. so basically, my resx files aren't a 1-to-1 translation.

this is even the case for exception messages. if i have a business rule message, the key/value in the resx file will something like:

AtLeastOneAccountRequiredExceptionMessage - You must have ...

instead of making the key basically the same text (without spaces) as the initial translation.

i'm looking for input from you and your readers on best practices/experiences on this subject. what have you found to be the best standard for resource key names?

thanks,

david

Fabrice
July 03, 2009

# re: WPF Localization Guidance Paper Posted on CodePlex

Thanks for the article. It was much needed, because such detailed information was not available in one place before.
I've recently collected links to resources about the subject. See http://weblogs.asp.net/fmarguerie/archive/2009/05/12/localization-in-wpf.aspx
Of course, your article is now in the list :-)

Rick Strahl
July 05, 2009

# re: WPF Localization Guidance Paper Posted on CodePlex

@David - resource naming is really a matter of taste and lots of things work, although some are more pleasing than others to your personal taste :-}.

I tend to be fairly descriptive with 'global' resources so that I'm pretty clear on what I'm getting when embedding the value in code. For control resources I still prefer using the same control.property that WinForms and ASP.NET use - it's a simple and logical convention that's obvious and easy to work with. Also makes it easy if you use a resource editor to do batch changes of resources.

Louis Duran
July 21, 2009

# re: WPF Localization Guidance Paper Posted on CodePlex

HI Rick,

Your articles on WPF localization are great. They cleared up some messy documentation that I have been trying to follow regarding mixing WPF and .RESX approach and how that relates to fallback. The article on Codeplex seems very thorough. HOwever, I was hoping for some more guidance on font handling...

Do you have any advice on how to handle fonts for localization?

For my project I was just planning on using GlobalSansSerif.CompositeFont for everything. So I would just change all our references where we have:

<TextBlock FontFamily="Arial, Blah, blah..." />

to:

<TextBlock FontFamily="GlobalSansSerif" />

If I need to, I can just define our own compositeFont (in case our font requirements don't match the built in composite fonts.

Do you see any problems with that approach? It seems like the documentation on creating and using composite fonts is pretty sparse from Microsoft.

Johan Sundström
October 05, 2009

# re: WPF Localization Guidance Paper Posted on CodePlex

Yeah,

The document was much needed. However, I stumbled into problems using the StringFormat with a Binding Expression using dates. I expected the

<TextBlock Text="{Binding MyDateProperty, StringFormat=d}"/>

to also honor the CurrentCulture and CurrentUICulture settings, but obviously it does not. Here http://www.nbdtech.com/blog/archive/2009/03/18/getting-a-wpf-application-to-pick-up-the-correct-regional.aspx the issue is discussed in more detail.

Regards,

Johan

Rick Strahl's Weblog