wpfxamllocalizationglobalization

What is the best way to localize a WPF application, sans LocBAML?


There seems to be no good way to localize a WPF application. MSDN seems to think that littering my XAML with x:Uid's, generating CSV files, and then generating new assemblies (using their sample code!) is the answer. Worse, this process doesn't address how to localize images, binary blobs (say, PDF files), or strings that are embedded in code.

So, how might you localize an application that:

  1. Contains several assemblies
  2. Contains images and other binary blobs (eg: PDF docs) that need to be localized
  3. Has string data that isn't in XAML (eg: MessageBox.Show("Hello World");)

Solution

  • Not an expert here, but "littering" your xaml with x:Uids is not worse than "littering" your Windows Forms code with all the string table nonsense you have to do for localizing them.

    As far as I understand, WPF apps still support "all the Framework CLR resources including string tables, images, and so forth." which means you can have localized resources.

    Of course, it would be much simpler if you created a markup extension that handled much of this nonsense for you. You can find an example of someone doing this here. And there was another, similar solution at http://blog.taggersoft.com/2008/07/wpf-application-localization-pattern_29.html, but that link no longer works.