WPF uses x:static for multi-language support

Original: WPF uses x:static multi-language support

To allow the program to support multiple languages, it is common to store the strings that need to be displayed in a static property of a resource class.

<!--[if!supportlists]--> <!--[endif]-->

Microsoft's WPF program multi-lingual Support official solution: using resource, and the resource by language compiled into a standalone DLL, the program will automatically load the most appropriate resources according to the system's current language settings. (This method is less flexible, and does not meet the diverse needs, so the online variety of multi-lingual solutions.) Here is a further explanation of the official plan.

Use XML to save language files: Put them in just because there is really such an explanation on the internet, although there is no practical value ..., resource is XML, and you define an XML with yourself, XmlDataProvider, and xml-based Data Binding, watching all tired ...
Use Project resource: Similar to the above, but put the strings in project resource, then use the ObjectDataProvider, and then the data Binding.

Assembly language: All languages supported in each assembly, setting the software language with a configuration file, and more than Microsoft's, but there are also multiple language support issues for WPF programs.

<!--[if!supportlists]--><!--[endif]--><!--[if!supportlists]--><!--[endif]--><!--[if !supportlists]--><!--[endif]-->

None of the above scenarios solves both of these problems at the same time:

<!--[if!supportlists]--> <!--[endif]-->

Switch languages at run time.

Add a new language without having to recompile the software.

<!--[if!supportlists]--><!--[endif]-->
Here, we introduce a more flexible, multi-language support scheme for WPF programs that solves both of the above issues.

The basic way is to use resource, except that resource is loaded at runtime. The structure of the solution is as shown.

The resource files for each language file are placed in the Resources/langs folder, which is not compiled into assembly, and the file structure is compiled as shown, and the language files are copied to the output folder as is.

Let's take a look at how the program works, and then look at the code more intuitively.

Here is the code for this interface.

2. MainWindow
4. <window x:class= "Localization.demowindow"
6. Xmlns= "Http://schemas.microsoft.com/winfx/2006/xaml/presentation"
8. xmlns:x= "Http://schemas.microsoft.com/winfx/2006/xaml"
10. Xmlns:c= "Clr-namespace:localization.backend.commands"
12. Title= "{DynamicResource MainWindowTitle}"
14. Width= "height=">
16. <dockpanel Lastchildfill= "False">
18. <menu dockpanel.dock= "Top">
20. <Menu.CommandBindings>
22. <x:static Member= "c:languagecommands.openlanguagebinding"/>
24. </< span>menu.commandbindings>
26. <menuitem Header= "{DynamicResource Languagemenuheader}">
28. <menuitem Header= "{DynamicResource Englishmenuheader}"
30. click= "Onloadenglishclick"/>
32. <menuitem Header= "{DynamicResource Chinesemenuheader}"
34. click= "Onloadchineseclick" />
36. <Separator/>
38. <menuitem Command= "C:languagecommands.openlanguage"
40. Header= "{DynamicResource openlanguagefilemenuheader}"/>
42. </< span>menuitem>
44. </< span>menu>
46. </< span>dockpanel>
48. </< span>window>

All the text on the interface uses DynamicResource to refer to the string in the resource file. The format of the resource file is as follows (example of an English resource file):

2. <resourcedictionary xmlns= "Http://schemas.microsoft.com/winfx/2006/xaml/presentation"
4. xmlns:x= "Http://schemas.microsoft.com/winfx/2006/xaml"
6. xmlns:s= "Clr-namespace:system;assembly=mscorlib">
8. <s:string x:key= "MainWindowTitle">Localization Demo</< span>s:string>
10. <s:string x:key= "Languagemenuheader">_language</< span>s:string>
12. <s:string x:key= "Englishmenuheader">_english</< span>s:string>
14. <s:string x:key= "Chinesemenuheader"> Chinese (_c)</< span>s:string>
16. <s:string x:key= "Openlanguagefilemenuheader">_open Language File</< span>s: String>
18. </< span>resourcedictionary>

Language files are not compiled into assembly and are somewhat different in use. The following is how the default load language for application is set in the App.xaml file.

2. <application x:class= "Localization.app"
4. Xmlns= "Http://schemas.microsoft.com/winfx/2006/xaml/presentation"
6. xmlns:x= "Http://schemas.microsoft.com/winfx/2006/xaml"
8. Startupuri= "Ui\demowindow.xaml">
10. <Application.Resources>
12. <ResourceDictionary>
14. <ResourceDictionary.MergedDictionaries>
16. <resourcedictionary Source= "Pack://siteoforigin:,,,/resources/langs/en-us.xaml"/>
18. </< span>resourcedictionary.mergeddictionaries>
20. </< span>resourcedictionary>
22. </< span>application.resources>
24. </< span>application>

The previous content is basically nothing different from other scenarios, the following is the most important point, is how to switch the language when running it? The answer is, just replace the ResourceDictionary in the above code and the interface will refresh automatically. The following is the code that implements the Replace function.

2. public class Languagehelper
4. {
6. <summary>
8. ///
10. </< span>summary>
12. <param name= "Languagefilename"></< span>param>
14. public static void Loadlanguagefile (String languagefilename)
16. {
18. Application.current.resources.mergeddictionaries[0] = new ResourceDictionary ()
20. {
22. Source = new Uri (Languagefilename, Urikind.relativeorabsolute)
24. };
26. }
28. }

The parameter languagefilename can be an absolute path to a file, such as a C:\en-US.xaml or a relative path as in App.xaml. By the way, the "Pack://siteoforigin:,,," is nothing more than the directory where the program is currently executing.

Judging by the current test results, even the interface has a large number of fine-grained text. Switching language speed is also an instant thing, if slow, also because the XAML file is too large, read the file for a lot of time.

WPF program multi-language support flaw

In fact, this is the most important, a lot of articles about a technology will be praised this technology hype, but to the potential defects or problems avoided.

The flaw is that not all things can be run and are updated. For example, the last menu item is implemented with command, as shown in the following code:

1. <menuitem Command= "C:languagecommands.openlanguage"
2. Header= "{DynamicResource openlanguagefilemenuheader}"/>

Routeduicommand itself has defined the Text property to be displayed on the interface, and there is absolutely no need to set the header property for the MenuItem using the command. But why is it still set up here? Because there is no simple plan to change the command text after the automatic update of the interface. Because the command's Text property is not a dependency attribute. In order to automatically update the interface, you have to set the header property for MenuItem.

WPF uses x:static for multi-language support