Shulou(Shulou.com)06/02 Report--

This article introduces you how to understand the construction of multilingual WPF applications, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Download source code-84.4 KB

Introduction

Building multilingual support (Multilingual Support) in WPF applications is one of the things I've been doing recently, which improves the usability of the program for people who don't use English. To achieve this, you need to achieve the following goals:

One version holds multiple languages. This means that do not create separate English, French, Japanese, and so on. Many electronic products, such as televisions and digital cameras, support multiple languages in the same module. You don't need to buy different modules or patch the software to get a language that is different from the default setting

Allows you to switch interface languages at runtime. This means that there is no need to close the application and configure the operating system environment, everything is left to the installer.

* run to select the appropriate language. When the W application is run every time, the interface language is set as the system language of the operating system. This makes sense-French users like to install, run, and use software right away, rather than finding a place to switch languages in an unfamiliar application.

Allow UI to be expanded for translation, reducing possible cropped text

In addition, the specific implementation should not become more and more difficult to implement as the user interface grows. This is the most difficult aspect in my opinion. )

So the purpose of this article is to provide an outline of a detailed solution for my development process, based on some of the blogs and posts I have written in the past (here, here and here). Over time, I will point out the relevant parts of the examples and show you how they fit together.

Disclaimer: the text in the example is generated using an automated online translation service. Although efforts have been made to ensure that this is as accurate as possible (through reverse translation and proofreading), there may be inaccuracies or errors in the translation. Especially when it uses a completely different writing system that I don't know.

Upper level overview

This implementation for WPF applications follows a MVVM (Model-View-View Model) style. Language data is stored in embedded XML files, which are loaded into memory according to the requirement principle, that is, when the interface language changes. This is the part of the model. .

The View Model has the feature of including the language data of the current language into the entire WPF application. It is a collection of XAML files, which form a "view" containing data associated with the language. In order to select an accurate value for a particular text element, each association uses a user-defined value converter with a converter parameter to find the text key value. * use a custom tag extension to extract the details of this association, so that only key values (that is, conversion parameters) need to be specified.

Examples

To illustrate how this implementation works in practice, I create a small example application based on this feature. This application, called 'RePaver', is used to clear path marker expressions and has basic functions to flip, reverse, transform, and scale actual geometry (that is, without layer conversion). In the background, the application extracts path paragraphs with regular expressions and converts each paragraph on the spot.

To give you an idea, take a look at the following example of a Path expression, which is generally derived from a vector graphics file exported to XAML format (this path expression has nothing to do with some of the paths I am currently working on!) :

If you copy the paste data expression (in quotation marks) into the input box and click 'Go', you can see the output as follows:

M 4,16 L 4,6 L 0,6 L 6,0 L 6,16 Z

On the right, you can also see the visual results of "before conversion" and "after conversion" in real time.

You can set some options at will-you can see that these actions are flipped / reversed-> zoomed to [according to border size]-> offset. Of course, you can try it in different languages.

Module XML

As mentioned above, each text that makes up the user interface is saved in a localization table in each language's XML file, and the XML file is compiled as an embedded resource. The parent element of each text contains a key attribute to retrieve localized text. The following is an example of an English version definition file, LangEN.xml:

0 11 16 Transform Language Apply Undo Cancel Input Output Info Transform Flip / Rotate Offset Scale To Dimensions Width Height Go

In the above English version example, the theIsRtl, MinFontSize, and HeadingFontSize elements are also mentioned. Font size is used to determine the size of the rendered font, making it easier to distinguish, especially when displaying Japanese, Korean and Arabic. The IsRtlel element determines whether the language is read from right to left (as is the case with Arabic and Hebrew).

Notice that the language name does not appear in the XML file above. This is because localized language names are defined in a separate XML file, LanguageNames.xml:

English / ol Fran / ais / lambda / kappa / Espa ñ ol Fran ç ais / lambda / kappa / Italiano / Japanese / Japanese /

The naming of each language definition file follows the convention, 'LangXX.xml'. Where XX corresponds to a two-letter ISO language code, and each Language element in LanguageNames.xml corresponds to that code. Of course, this convention can be extended or modified to make it easy to handle localization (such as en-NZ, en-US), or even changed to three-letter ISO language code.

UILanguageDefn class

The current interface language data in the language definition file is loaded into an inner class (UILanguageDefn) in order to be consumed by the remaining applications. The main component is a type dictionary. This dictionary contains mappings from text keys to local text values. Other properties show the values of IsRtl (whether right-aligned), MinFontSize (minimum font size), and HeadingFontSize.

When you use this class, the local language text is retrieved by calling the following method:

/ Gets the localised text value for the given key. / The key of the localised text to retrieve. / The localised text if found, otherwise an empty string. Public string GetTextValue (string key) {if (_ uiText.ContainsKey (key)) return _ uiText[ key]; return "";}

In addition, the UILanguageDefn class has a static mapping from language coding to local language names (which is loaded from LanguageNames.xml), such as "en" and "English", "sv" and "Svenska". This is used to populate the list of available languages in the 'Language' tag and is filtered by the list of authoritative languages supported by the application. Therefore, any language that is no longer in this list will not be displayed by the interface. Even if there is a language definition file or a corresponding entity in LanguageNames.xml, the language will not be displayed. This will be further described in the following sections.

Load data

The class `UILanguageDefn` forms part of the model. The second major entity in the model is the application full state, `MainWindowModel`. It contains an example of the authorization of `UILanguageDefn` used by the entire application. This is an example of getting the boundaries of a text element in all interfaces. (via ViewModel).

When `MainWindowModel` is constructed, the authorization of the language list is registered and the localized language is loaded from the resource file named LanguageNames.xml before the current language is loaded. Let's see how it works through an example:

Public class MainWindowModel {private UILanguageDefn _ languageMapping; public MainWindowModel (int maxWidth, int maxHeight) {RegisterLanguages (); LoadLanguageList (); / / Settings are loaded here, where CurrentLanguageCode is decided. UpdateLanguageData ();} public string CurrentLanguageCode {get {/ / Retrieves the current language code from / / the Settings model (abstracted away)}} / Registers the languages by their corresponding ISO code. / / private void RegisterLanguages () {/ / Defined in Constants class string [] supportedLanguageCodes = {"en", "ar", "de", "el", "es", "fr", "ko", "hi", "it", "he", "jp", "ru" "sv"} Foreach (string languageCode in supportedLanguageCodes) UILanguageDefn.RegisterSupportedLanguage (languageCode) / Loads the list of available languages from the embedded XML resource. / / private void LoadLanguageList () {/ / Defined in Constants class string resourcePath = "RePaverModel.LanguageData.LanguageNames.xml"; System.IO.Stream file = Assembly.GetExecutingAssembly () .GetManifestResourceStream (resourcePath); XmlDocument languageNames = new XmlDocument (); languageNames.Load (file); UILanguageDefn.LoadLanguageNames (languageNames.DocumentElement) } / Updates the UI language data from that / defined in the corresponding language file. / public bool UpdateLanguageData () {string languageCode = CurrentLanguageCode; if (String.IsNullOrEmpty (languageCode)) return false; / / This follows a convention for language definition files / / to be named & apos;LangXX.xml' (or & apos;LangXX-XX.xml') / / where XX is the ISO language code. String resourcePath = String.Format (Constants.LanguageDefnPathTemplate, languageCode.ToUpper ()); System.IO.Stream file = Assembly.GetExecutingAssembly (). GetManifestResourceStream (resourcePath); XmlDocument languageData = new XmlDocument (); languageData.Load (file); _ languageMapping = new UILanguageDefn (); _ languageMapping.LoadLanguageData (languageData.DocumentElement); return true;}}

You may notice that the above code mentions the third subject-setting state. Among the many settings that can be adjusted at run time, it is this state that stores the interface language that is currently being used. Most settings are saved to disk after the application is closed and reloaded when the program is opened again.

However, if the application is opened * (no settings file exists), then these settings will be set to the default state. English is the default for the language, but it is not user-friendly-friendly. So, let's retrieve the current system language like this:

CultureInfo.CurrentCulture.TwoLetterISOLanguageName

Once the appropriate language is found, if the application does not support it, make English the default language. In this way, as long as your local language is supported, UI will display the language when your program is run *. In Setting model hierarchy, you have the following code

Public LanguageSettings () {/ / Initialise the default language code. / / In most cases this will be overwritten by the / / restored value from the saved settings, or that of the current culture. _ uiLanguageCode = Constants.DefaultLanguageCode; / / "en" string languageCode = CultureInfo.CurrentCulture.TwoLetterISOLanguageName; / / If the system language is supported, this will / / ensure that the application first loads / / with the UI displayed in that language. If (UILanguageDefn.AllSupportedLanguageCodes.Contains (languageCode)) _ uiLanguageCode = languageCode;}

Another method in this class, called the latter (used when a user settings file exists), extracts the value of the setting saved in the file and overrides it to _ uiLanguageCode.

View model

Here is a MVVM implementation, which is different from Model-View-Presenter (MVP) in WPF and Silverlight applications. In MVP mode, we need a Presenter to pass the definition of the current language (or a single localized text) to the view (View), which is responsible for displaying and updating the text in UI. Considering that we are using WPF, updating the text can be easily achieved through data binding; considering that the language definition is to be used throughout the application (component or form), we need a shared class to hold the current language property so that when data binding, the property can be retrieved in any part of the UI.

In the MVVM schema, this shared class, along with other view models, such as MainWindowViewModel, will become part of the view model layer. The class CommonViewModel is implemented as a singleton pattern (Singleton) so that the static instance property Current can be assigned as a binding source property. Non-static properties are referenced by the bound Path property. It is also important that ViewModel implements the interface to INotifyPropertyChanged so that UI can automatically update the binding when the source value changes.

Here is the CommonViewModel property bound to UI, and the UILanguageDefn class gives the definition of the data:

/ Gets or sets the language definition used by the entire interface. / The language definition. Public UILanguageDefn LanguageDefn {get {return _ languageDefn;} set {if (_ languageDefn! = value) {_ languageDefn = value; OnPropertyChanged ("LanguageDefn"); OnPropertyChanged ("HeadingFontSize"); OnPropertyChanged ("MinFontSize"); OnPropertyChanged ("IsRightToLeft") } public double HeadingFontSize {get {if (_ languageDefn! = null) return (double) _ languageDefn.HeadingFontSize; return (double) UILanguageDefn.DefaultHeadingFontSize;}} public double MinFontSize {get {if (_ languageDefn! = null) return (double) _ languageDefn.MinFontSize; return (double) UILanguageDefn.DefaultMinFontSize }} public bool IsRightToLeft {get {if (_ languageDefn! = null) return _ languageDefn.IsRightToLeft; return false;}}

MainWindowViewModel is at the front end of the ViewModel architecture and is responsible for updating the current language in CommonViewModel when the MainWindowModel value changes:

/ Refreshes the UI text to display in the current language. / / public void RefreshUILanguage () {_ model.UpdateLanguageData (); CommonViewModel.Current.LanguageDefn = _ model.CurrentLanguage; / / Notify any other internal logic to prompt a refresh (as necessary) if (LanguageChanged! = null) LanguageChanged (this, new EventArgs ());} View

As I mentioned, localized text is displayed in the view through data binding. However, WPF itself does not know how to handle UILanguageDefn classes, let alone extract appropriate localized text values. This is also a difficult problem.

Value converter

Keep in mind that CommonViewModel.Current.LanguageDefn is a UILaunguageDefn, not a string expected by the Text property of TextBlock. Therefore, a value converter is needed to complete the conversion at this time. This value converter uses ConverterParameter to specify the creation of lookup keywords that are used to recover locally qualified text from the UILanguage instance. Remember, when the interface changes, so does the UILanuageDefn.

The advantage of this work is that for each piece of text confined to the interface, eligible elements need to be added to the language XML file to ensure that the ConverterParameter and element names match. In addition, there is no need to define any additional attributes-- whether in the view layer, UILanguageDefn, or other parts of the model layer.

This converter is relatively simple. Simply specify the ValueConversion attribute of IValueConverter (in System.Windows.Data) at the class level:

[ValueConversion (typeof (UILanguageDefn), typeof (string))]

And implement a function similar to the following Convert:

Public object Convert (object value, Type targetType, object parameter, CultureInfo culture) {string key = parameter as string; UILanguageDefn defn = value as UILanguageDefn; if (defn = = null | | key = = null) return "; return defn.GetTextValue (key);} bind

Now that we have a value converter, we can place it in a Binding expression:

If you want it to work, the namespace of the XML must be set to vm (which points to the namespace of ViewModel), and the resources of UIText need to be defined (assuming that conv is the namespace of the XML of this value converter):

Zlt;conv:UITextLookupConverter x key = "UIText" / > simplicity-Custom tag extension

If your current state (like me) wants a pleasant way, in the long binding expressions in most XAML files, you find it boring and repetitive of the same thing. Don't even consider renaming classes or using attributes as part of refactoring!

Of course, there is a way to make it more concise, considering that the only change between these bindings is ConverterParameter. The solution is to use an extension using custom tags.

To do this, the custom tag extension is a simple class derived from MarkupExtension (in System.Windows.Markup) and conventionally named [name] Extension. At its core, the key point is the need to overload the ProvideValue method. But how do you do that?

The focus of custom tag extension is to write code like this in XAML:

Therefore, the custom extension is called LocalisedTextExtension, and a Key is added, whose type is public string. Exe. Because binding is always in use in the background, I create a private binding domain and instantiate it from the constructor:

Public LocalisedTextExtension () {_ lookupBinding = UITextLookupConverter.CreateBinding ("");}

The static CreateBinding method is defined in the value converter (value converter):

Public static Binding CreateBinding (string key) {Binding languageBinding = new Binding ("LanguageDefn") {Source = CommonViewModel.Current, Converter = _ sharedConverter, ConverterParameter = key,}; return languageBinding;}

So once the Binding is defined, you can get and set the value of the Key property through the ConverterParameter parameter. This also allows the ProvideValue method to take advantage of:

Public override object ProvideValue (IServiceProvider serviceProvider) {return _ lookupBinding.ProvideValue (serviceProvider);}

A Binding is a MarkupExtension, so it has its own callable ProvideValue method.

Rinse and Repeat-Font size and stream direction

The character sets of some languages contain so complex graphic elements that they become blurred when Latin-recognizable character sizes are used to display these languages. You notice that CommonViewModel provides HeadingFontSize and MinFontSize properties. This provides the font size for the localized title and the remaining localized text accordingly. For example, the font size of Japanese is larger than that of English.

Fortunately, the above text size can be bound to a shared style using a pattern similar to the following, without the need for a value converter:

The following figure shows the differences between two different languages with the same interface:

Some languages are read from right to left, such as Arabic and Hebrew. In order for UI to correctly locate these languages, it makes sense to reverse the interface, otherwise it will cause some confusion if the reading order and logic order are not consistent when using the program.

Fortunately, WPF has a convenient property that does the hard work of reversing the entire UI:

FrameworkElement.FlowDirection

What makes this quite powerful is that I only need to bind a root-level control contained in the main window, because this value is inherited at the visual level by each FrameworkElement below it. The binding simply needs to look at the IsRightToLeft property of CommonViewModel and convert to (through other value converters) the enumerated values of FlowDirection. Custom markup extensions are created, following previous similar templates and simplified to XAML:

Given the power of the above features, there are still some pitfalls and key points to consider here:

The custom panel automatically reverses the layout, so you don't need to create an IsRevered property (or something like that) or adjust the ArrangeOverride according to your estimate.

Bitmaps and shapes, such as circuits, are reversed. If you want to keep these and show independent flows (such as the company's logo or trademark), you need to rewrite FlowDirection and set it to LeftToRight.

If the interface has the FlowDirection of RightToLeft, and the element (such as Image) has the FlowDirection of LeftToRight, then the Margin of the element is displayed as RightToLeft. Because the Padding is displayed in a visual hierarchy within the element, a padding will be presented as LeftToRight.

TextBoxes contains language-constant data, and FlowDirection should be set to LeftToRight. Ideally, this property should be set to a style that minimizes duplication and ensures consistency.

So, here are the trendy screenshots of "after processing":

Note the path, rotate the selection control, and the input and output text boxes are displayed from left to right, regardless of the language. This is because these elements are specific problem areas, and if they are displayed from right to left, it doesn't make sense (which can lead to misunderstanding).

Summary

Now it's clear-- a local WPF application can change UI dynamically at run time. * the first time it was run in a French local computer environment, look, il est affich é en Fran ç ais. They all come from the same language version.

* one important point to note. Not described in detail here, the entire UI layout is arranged in a fluid manner, which is automatically adjusted to adapt to the content. Instead of explicitly setting width and height, row / column definition of the grid, and so on. These are "automatic" to the left, and minimum and * * values can be defined. This is one of the most common instances (rather than a specific localization), but such instances are not allowed to actually show up when switching languages.

Postscript

Localization is a hot topic in software development, and of course I'm not the only one who writes about it. In fact, I found some people doing the same thing:

Sebastian Przybylski (article) also stores UI text in XML files as embedded resources, while XAML is directly bound to XML resources rather than through ViewModel.

David Sleeckx (article) uses custom tag extensions to retrieve locally cached translated text, or calls the Google language API to achieve real-time translation.

SeriousM' updated the WPF localization extension on CodePlex. It is achieved by extracting localized text (or other values) from the resource file / resource assembly.

Obviously, there are many options for localizing WPF programs, and they are not mutually exclusive. According to your tradeoff, the implementation I mentioned applies only to part of your program, while the other part will appear elsewhere. So you should adjust the implementation method at will according to your needs.

On how to understand the construction of multilingual WPF applications to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.