CODEWITHSUNDEEP
c#wpflocalization
pathrider
pathrider

Reputation: 1005

WPF localization of strings - shared between different projects?

I'm developing a WPF C# app under VS2012 where I have UserControls from different sources in separate projects in the solution. I would like to localize all the UI strings in the entire solution in one place, if I can.

It seems like locbaml isn't really set up for this kind of thing since it appears for every class library, I need to create a separate resource DLL for each class library DLL?

Can anyone give me some guidance on the Best Practice way to do this? I'm at a loss to figure out how to apply the various localization techniques to a solution with multiple projects.

Thanks for any advice. Corey.

Upvotes: 3

Views: 6781

Answers (2)

Jaska
Jaska

Reputation: 1037

WPF uses two resource formats: XAML and RESX. unfortunately almost all best practices and also all answers here recommend to replace plain and simple strings in XAML with complex and hard to maintain references to RESX strings.

For example if you had

<TextBlock Text="Hello World"/>

then the "best practices" recommend to get rid of the XAML string, add it into RESX, and finally replace the XAML with reference

<TextBlock Text="{Binding Path=Resource1.HelloText, Source={StaticResource LocalizedString }}"/>

+

<data name="LocalizedString" xml:space="preserve">
  <value>Hello World</value>
</data>

Do not do that. Put RESX only those string what are used in your code. Leave all strings of the XAML as they are. Localized both RESX and XAML files. Finally compile satellite assembly files that contains localized RESX and XAML.

Visual Studio or locbaml can only localize RESX. You can localize XAML manually using a text editor but I do not recommend to do that. The localized XAML must be identical to the original. This means that the structure must be the same. It must contains all the components, properties and event as the original XAML. The only worable way to localize XAML is to use some localization tool.

You have to be carefull when choosing the localization tool. It must performs following two things.

  1. Localize XAML and RESX
  2. Compile localized XAML and RESX into satellite assembly files.

Once you use such a localization tool your localization does not only get much more easier but you can also place your user control either in its own assembly or link it to all projects that use it.

Upvotes: -1

ianschol
ianschol

Reputation: 686

Revising my post a bit to be more inclusive:

Overarching best practices are detailed on the MSDN here.

Really, you have three choices.

  1. Localize it yourself - hand-roll your own XML/text file/database solution.
  2. Use locbaml to localize. This does not allow dynamic language switching in-app.
  3. Use resx files to localize. This does allow dynamic language switching in-app, depending on implementation chosen.

There are plenty of scenarios where locbaml is optimal, which are outlined on the best practices page, but resx files are reasonably portable (the format is simple) and will fulfill a requirement for dynamic language swapping.

If you decide to go with (1), you're on your own. Godspeed! :)

If you choose to use locbaml (2), it's best to approach the problem by first abstracting your strings into a ResourceDictionary, allowing you to put all strings into one file for localizing. See here : How to: Use a ResourceDictionary to Manage Localizable String Resources

The linked article details still using locbaml, but you should only need to use it to localize the single ResourceDictionary. Keeping the resources neatly isolated in this fashion should make your life a lot easier. Note that if desired, the ResourceDictionaries can be split categorically - just a matter of whether one monolithic file or multiple smaller files are better for your project.

If you choose to use resx files (3) and want to support painless run-time language switching, this short tutorial\example code provides an excellent starting point. It's written with Prism in mind, but can be used outside of Prism with no difficulties. There are other, simpler approaches that also use resx files, but if you want the best approach, IMHO you are looking at it. The one (maybe?) major caveat is that this approach will not work on Silverlight. This is a WPF question but I realize it may be a concern for some people.

Upvotes: 6

Related Questions