Click here to Skip to main content
Click here to Skip to main content

WPF Multilanguage Markup Extension

, 21 Sep 2009 GPL3
Rate this:
Please Sign up or sign in to vote.
An alternative way of providing ML in WPF applications.

Introduction

There are many ways to "multi language" your WPF application - here's another one! Features:

  • Simple to use via a custom WPF markup extension (like the "Binding" extension).
  • Switching the language dynamically in runtime will update the associated controls immediately.
  • Can be used with various sources like CSV, Excel, or databases (rather than satellite assemblies).
  • No memory leaks by using weak references.

Using the code

First, you have to configure your ML resources. In this example, this is done in code using the DummyContextProvider (see below). Now, we want to use the framework, means: We have a WPF project with some WPF elements which we would like to assign our ML texts to. This is done by carrying out the following steps:

  • Reference the "Technewlogic.MultiLanguage" assembly.
  • Initialize the MultiLanguage framework when the application starts.
  • Make use of the "MultiLanguage" markup extension in your XAML.
public App()
{
    // Initialize the MultiLanguage provider with just a dummy here.
    // Implement another IContextProvider to get the ML configuration
    // from another source, e.g. Excel / csv, etc.
    MultiLanguageProvider.Instance.Initialize(new DummyContextProvider());
}
<TextBlock Text="{ext:MultiLanguage MainWindow.CloseApplicationText}" />

If you are interested in the implementation details, continue reading.

The Configuration Model

Internally, the framework consists of a ConfigurationContext class which is the entry point for the ML configuration. It aggregates a list of LanguageCategorys. A LanguageCategory can be used to summarize certain ML keys. For example, you can create a LanguageCategory for each page in your application. A LanguageCategory consists of several LanguageEntrys which represent a logical ML text in your app. For example, in the "MainPage" category, you can find a "CloseText" entry which can be applied to a button that will close the page. Each LanguageEntry holds a list of LanguageTexts - one for each language you want to support. Have a look at the DummyContextProvider class. There you can see how the model can be built up.

Implementation of the Framework

The API to work with is the MultiLanguage markup extension class which can be used in XAML. To keep things simple for the user of the framework, the instances of that class access the static MultiLanguageProvider which holds the ML configuration. The required information has to be provided by an implementation of IContextProvider. Implement this interface if you want to store your ML info in an external location, for example, in a CSV or Excel file. In this example, there's just a dummy implementation which shows how it should look like. The MultiLanguageProvider class also manages language changes and informs all the MultiLanguage instances which will update the properties they are bound to. This is done via WeakReferences.

History

  • 19 Sep 2009 - Initial release.

License

This article, along with any associated source code and files, is licensed under The GNU General Public License (GPLv3)

Share

About the Author

Ronald Schlenker
Software Developer (Senior) www.technewlogic.de
Germany Germany
No Biography provided

Comments and Discussions

 
QuestionWhy have you used "long weak references"? PinmemberJochen Kalmbach [MVP VC++]4-Mar-10 0:26 
AnswerRe: Why have you used "long weak references"? PinmemberRonald Schlenker4-Mar-10 22:19 
As far as I can remember - no. I think you are right, there's no need for long references here. The reason for a weak reference was this: A WPF control uses the ML markup extension to provide ML functionality to it's user. Each instance of the markup extension registeres itself to the _static_ MultiLanguage Provider which holds a reference to the markup extension to be able to call back. But there would be no chance to deregister the markup extensions from the ML provider, which means that the whole WPF control would remain in memory. If we use a weak ref, we can prevent this. But as you said, there is no need to retain the weak reference after it is destroyed!
GeneralRe: Why have you used "long weak references"? PinmemberJochen Kalmbach [MVP VC++]4-Mar-10 22:27 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.1411023.1 | Last Updated 21 Sep 2009
Article Copyright 2009 by Ronald Schlenker
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid