WPF Multi-language support plug-in development

This article describes an implementation method that supports dynamically changing program run language support at design time and run time. WPF multi-language support we expect to achieve the following features:

(1) Ability to integrate directly with WPF's XAML;

(2) Support encoding method to access resources;

(3) Supports dynamic switching and dynamic editing of languages at runtime.

1 overview

In the past, multilingual methods are supported using the resource file, which is eventually compiled into a resource DLL file. The advantage of implementing multiple languages in this way is that the IDE can be used directly in development, but the disadvantage is that the dynamic support is poor, and it is difficult to implement dynamic language switching, and it is not possible to implement language editing at runtime. is the language switch page.

is to switch the display effect to English. Here, the navigation bar, the System menu, the status bar, and the content area all implement language dynamic switching.

The following is the dynamic switch to Chinese display effect.

Is the run-time language editor. The resources are translated directly here and translated into effect immediately after translation.

2 Design Implementation

The localization framework is based on the osgi.net framework design, and as a plug-in for Osgi.net, its design adheres to the following principles:

(1) The plugin does not depend on the specific localization support method. Methods that support localization can have resource files, custom XML files, and so on to store localized resources. However, a plug-in cannot rely on a specific implementation.

(2) The implementation of localization uses a hierarchical approach, the first level is independent of the application environment, and the second level is WPF-related. WPF-related localization support must be well considered in conjunction with WPF's XAML interface technology to maximize ease of use in WPF.

(3) Support localization resource design time, runtime dynamic editing, especially runtime editing. Support for changing the locale at run time.

The localization framework has a localization base service (uishell.localizationservice), WPF localization Services (uishell.wpflocalizationservice) plug-in implementation, and its dependencies are as follows.

As shown, when third-party plug-ins need to access localized resources, they only need to rely on the localization base service, which can be easily extended to other localization implementations without changing the plug-in code in the future.

The localized base service interface is defined in the Uishell.localizationservice plug-in, as shown below. It defines a resource acquisition interface, a list of supported languages, and a language change event.

The following is a description of the localization service interface. Each plugin has its own localized storage space, with GetResource and getstring to get localized resources for the plugin itself.

<summary>///Localization Services.    </summary>public interface ilocalizationservice{//<summary>///list of supported languages.    </summary> dictionary<string, cultureinfo> supportcultureinfos {get;}    <summary>//Current language.    </summary> CultureInfo currentcultureinfo {get; set;}    <summary>///Get resources. </summary>//<typeparam name= "T" > Resource type. </typeparam>//<param Name= "bundle" > Belongs plugin. </param>//<param name= "ResourceKey" > Resource key. </param>///<returns> returns the resource object.    </returns> T getresource<t> (ibundle Bundle, String ResourceKey, T defaultvalue);    <summary>///Get resources. </summary>//<typeparam name= "T" > Resource type. </typeparam>//<param name= "Bundlesymbolicname" > belongs to the plug-in identification. </param>//<param name= "ResourceKey" > Resource key. </param>///<returns> returns the resource object. </returns>t Getresource<t> (StRing Bundlesymbolicname, String ResourceKey, T defaultvalue);    <summary>///Get string resources. </summary>//<param Name= "bundle" > Plugin. </param>//<param name= "ResourceKey" > Resource ke. </param>///<returns> returns string if not present. Empty.    </returns> string GetString (ibundle bundle, string resourceKey);    <summary>///Get string resources. </summary>//<param name= "Bundlesymbolicname" > plugin name. </param>//<param name= "ResourceKey" > Resource ke. </param>///<returns> returns string if not present. Empty.    </returns> string GetString (String bundlesymbolicname, string resourceKey);    <summary>//language change events. </summary> event eventhandler<cultureinfoeventargs> cultureinfochanged;}    public class cultureinfoeventargs:eventargs{public CultureInfo previouscultureinfo {get; set;} Public CultureInfo Currentcultureinfo {get; set;}}

The WPF Localization service implementation method is described as follows:

(1) language files are stored in XAML format, and in the language directory of the plug-in root directory, the language file filename is called the resource.< language >.xaml, and the custom language file is Resource.xaml. Simplified Chinese language file is Resource.zh-cn.xaml, Traditional Chinese language file is Resource.zh-tw.xaml, English is Resource.en-us.xaml.

(2) Support to set the current language, once the current language changes, the service will dynamically search the current language of the file, and use the XamlReader class to read the resource, the resource file serialized into the ResourceDictionary class.

(3) When editing a language, dynamically generate a DataGrid column according to the supported language, each of which is a resource for the corresponding language, and the key for the language is a merged collection of all languages.

(4) After editing the language, use XamlWriter to serialize the ResourceDictionary to the specified language file.

After the WPF interface framework loads the plug-in's user control, the WPF localization service loads the plug-in's resources and merges its resourcedictionary with the plug-in user control, so that for the user control that is rendered directly in the interface frame display area in the plug-in, You can access the service directly using the following methods.

{DynamicResource [ResourceKey]} can be set directly in a control property that supports bindings.

In addition, plugins can use ilocalizationservice.getresource/getstring to obtain resources for the current language.

For controls that are not loaded in the main interface frame content area, such as a popup window, in order for the window to support access to resources through DynamicResource, The resource collection for the plug-in must be obtained through the Iwpflocalizationserivce.getresourceditionary method and merged with the window resource. The service implementation is as follows.

Wpflocalizationserviceimpl has dynamic features:

(1) It can dynamically monitor the status change of the plug-in, when the plug-in starts, loading the plug-in language resources, when the plug-in stops, the language resources are deleted.

(2) When the current language changes, all language files will be reloaded and issue a cultureinfochanged event to notify the interface to refresh.

3 processing of XAML resource files

The implementation of multiple languages relies on the processing of XAML files. The following code converts a resource file to ResourceDictionary using XamlReader.

The following code uses XamlWriter to save ResourceDictionary as a XAML file.

This XAML-based localization implementation method is well-used in WPF interface localization, code localization resource access, and supports dynamic language switching and runtime language editing.

WPF Multi-language support plug-in development