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:
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.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.