Is there any reason NOT to use standard resx+static binding for localizing WPF?

I'm looking for a dead-simple way to get my app localized to Japanese as well as the default English. The only requirement is that we be able to launch it in a specified language. We were using the LocBaml stuff which is clunky, complicated, error-prone, and makes our build process exceedingly difficult.

I'm considering moving everything back to resource files (Strings.resx, Strings.ja.resx) and just doing static binding, like this:

<TextBlock Text="{x:Static resx:MyWindow.MessageText}" />

Then at launch time finding out what language they want and switching which resource it pulls strings from:

public static void Main(string[] args)
{
  if (args[0] == "-lang")
  {
    Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo(args[i + 1]);
  }

  App app = new App();
  app.InitializeComponent();
  app.Run();
}

This is simple and it seems the only true drawback is that we cannot switch at runtime, which is not something we will ever want to do. I've seen a few localization extensions like these:

http://wpflocalization.codeplex.com/

http://www.wpftutorial.net/LocalizeMarkupExtension.html

They provide cleaner Xaml and look a bit nicer at design time, but I can't see any functional difference besides allowing you to change languages at runtime. Am I missing something here, or should we just go for the easy and built-in route? Sum total we only have ~开发者_开发技巧100 strings that need to be localized. I think that the simplest route is the best here, especially considering the relative simplicity of our app.

---

I'd definitely recommend the resx route. I've just finished building a large wpf application that will be localised in a variety of languages (currently just en_GB and it_IT but will be pushing more locales out shortly) and it's worked perfectly.

Some drawbacks to consider:

• Like you mentioned, it's not really a great solution if you wanted to switch languages dynamically (although this can still be achieved with a bit of work using markup extensions).
• As opposed to the locBaml approach you need to place resources in your resx upfront which adds a small bit of overhead
• You are pretty much limited to localising strings (where locBaml, as far as i'm aware, you can pretty much localise all element properties)

In our respects the minor draw backs of the resx approach by far trumped the drawbacks of locBaml.

One caveat is I've not used the locBaml approach on a full build project. I was in the same situation as you and had to investigate both approaches. In hindsight it was definitely the correct decision for us.

---

We use the WPF localization extension. It provides runtime switching and design-time viewing of the localized strings.

The nice part about using resx is that it has good fallback (ex. de-DE, de, default resource). Also locBaml has the disadvantage that it uses a CSV file, with all the problems that can cause (such as needing to escape strings which contain commas). Also, strong-name signed assemblies have to be resigned after the tool has run.