Welcome to the Localization Library project

The Localization Library is a collection of reusable software components that provide support for localization. This library enables you to localize WPF (Windows Presentation Foundation), Silverlight and WP7 (Windows Phone 7) applications.

Author: Nicola Gallo (Email: nicolagmt@hotmail.it, Web site: www.nicola.gallo.name, Blog: dotnetslang.wordpress.com)

M$Logos
wp7Runtime

Quickstart: Hello World

LocalizationLibrary for WPF

In the the solution “HelloWorld.Desktop.sln” you can find a simple example of how to use the Localization Library.

NOTE: The solution’s path is “…\LocalizationLibrary\Quickstarts\HelloWorld\HelloWorld.Desktop”.

LocalizationLibrary for Silverlight

In the the solution “HelloWorld.Silverlight.sln” you can find a simple example of how to use the Localization Library.

NOTE: The solution’s path is “…\LocalizationLibrary\Quickstarts\HelloWorld\HelloWorld.Silverlight”.

LocalizationLibrary for WP7

In the the solution “HelloWorld.WP7.sln” you can find a simple example of how to use the Localization Library.

NOTE: The solution’s path is “…\LocalizationLibrary\Quickstarts\HelloWorld\HelloWorld.WP7”.

Localization Library overview

WPF and Silverlight represent a big step forward in the user interface development. MVVM (Model-View-ViewModel) pattern has born with WPF and Silverlight.

MVVM is an architectural pattern that enables you to develop modern UI and allows the separation of roles. When you use MVVM you can develop in multiple work streams each single layers of your application.

MVVM pattern is composed of:

  • Model: Represents the model and refers either to an object model (object oriented approach) or the data access layer (data centric approach)
  • ViewModel: Provides a specialization of the Model that the View can use for the data binding and also an abstraction of the view. The ViewModel contains data-transformers that convert Model types in View types and also could contains Commands that the View can use to interact with the model
  • View: Consists of all visual elements displayed by the GUI such as ListBoxes, Buttons, TextBlocks etc.

By using MVVM and other framework such as CAL (Composite Application Library), MEF (Managed Extensibility Framework) etc. you can develop dynamic application, but if you want to localize your application you have to define it within the view.

The Localization Library extends the MVVM pattern and implements the MVVM and LocalizationModel (MVVM-L) pattern.

MVVM-L introduces the concept of LocalizationModel that allows the separation of the localization role in the same way as the Model of MVVM allows the separation of the roles (View, ViewModel and Model).

MVVM-L_Pattern_LocalizationLibrary

The LocalizationModel is a localization abstract layer which can implements a collection of localized properties that the View should use for the localization.  The LocalizationModel is an abstract concept. You can create a LocalizationModel integrated in a ViewModel or as a single component.

The Localization Library introduces the following concepts:

  • StaticResource: It’s a static resource that is implemented as a resource file
  • DynamicResource: It’s a dynamic resource as the localization is provided through the use of a LocalizationProvider
  • LocalizatedProvider: It’s a component that provides dynamically the resource’s localization and any application can implements custom LocalizationProvider (for example you can create a LocalizationProvider that uses the Microsoft Translator Service to localize the resource on the fly)
  • Localized Property: These properties by means of attributes can instruct the localization’s engine and bind the property’s value to a localized resource value.

Localized properties: StaticResource and DynamicResource

A localized property value can depends on either a StaticResource or a DynamicResource. Localization Library defines some attributes in order to instruct the localization’s engine. Using this attributes you can decorate either the LocalizationModel’s properties or the assembly.

There are three types of attributes:

a) LocalizeAttribute: An attribute that can be applied to a property and indicates that the target property should be localized using a StaticResource. It’s not allowed to apply more than one instance to the same target property.

b) LocalizeDynamicallyAttribute: An attribute that can be applied to a property and indicates that the target property should be localized using a DynamicResource. It’s allowed to apply more than one instance to the same target property

c) DynamicResourcePartAttribute: An attribute that can be applied to an assembly. It defines a dynamic resource part and provides directives, for the localization’s engine, in case of version conflict

LLSRDR

The base concept that you have to keep in mind about the dynamic resources, is that at runtime the resources are identified univocally by the ResourceID. So if you define a DynamicResource with the same ResourceID in either property or assembly, at runtime will be created only one resource’s instance. So it is easy to understand that at runtime we might have version conflict if you provide many different localizations for the same language. The solution to avoid this conflict is to define a version’s conflict policy.

There are two kinds of policies:

  • KeepExisting: Keeps existing version.
  • OverrideExisting: Overrides existing version

the default value for the version conflict is KeepExisting.

LLRuntimeDynamicResource

Following some examples with regards the use of the above attributes:

a) LocalizeAttribute

StaticResourceHomeSample

In this particular case the property named “MyProperty” is bound to the localized Value that belongs to the resource defined in the attribute (Resource of type “Resources.AccountResource”) with Name equals to “MyPropertyKey”.

b) LocalizeDynamicallyAttribute

DynamicResourceHomeSample

In this particular case the property named “MyDynamicProperty” is bound to the localized  value of the resource wich is identified by ResourceID equals to “MyDynamicPropertyKey”.  In addition, in this case, the resource’s localization (for English language) has been provided in the attributes definition. The resource’s localization for all the other languages, if not already existing, will provided by the LocalizationProvider.

c) DynamicResourcePartAttribute

ResourceLocalizedHomeSample

In this particular case the resource’s localization, identified by ResourceID equals to “MyDynamicPropertyKey”, has been provided for the Italian language.  In addition has been provided a policy of type “KeepExisting”.

MVVM and LocalizationModel (MVVM-L) pattern overview

MVVM-L is an architectural pattern that enables you to develop modern UI and allows the separation of roles.

  • Model: Represents the model and refers either to an object model (object oriented approach) or the data access layer (data centric approach)
  • ViewModel: Provides a specialization of the Model that the View can use for the data binding and also an abstraction of the view. The ViewModel contains data-transformers that convert Model types in View types and also could contain Commands that the View can use to interact with the model
  • LocalizationModel: Represents a localization abstract layer which can implements a collection of localized properties that the View should use for the localization (The ViewModel could be used also  as LocalizationModel and therefore, in this case, you have to define the localized properties within the ViewModel).
  • View: Consists of all visual elements displayed by the GUI such as ListBoxes, Buttons, TextBlocks etc.

The implementation of MVVM-L is the same as MVVM, the only difference consisting in the fact that you have to implement the LocalizationModel (If you don’t know how to implement the MVVM you can find more information at WPF Apps With The Model-View-ViewModel Design Pattern).

The best way to understand how a  LocalizationModel is implemented is to jump right in the implementation. Let’s suppose we need to implement a use case to  create a new Account.

AccountView

The first step is to create the LocalizationModel and derive it from the LocalizationModel class (namespace LocalizationLibrary). A good name would be AccountLM (Account LocalizationModel).

Once you have created it, we have to add a property for each label that we want to localize in the view. Below you can see the AccountLM code implementation.

    /// <summary>
    /// Defines the account's <see cref="LocalizationModel"/>.
    /// </summary>
    public class AccountLM : LocalizationModel
    {
        //Properties

        public String FirstName { get; set; }
        public String LastName { get; set; }
        public String Address { get; set; }
        public String Town { get; set; }
        public String Postcode { get; set; }
        public String Birthday { get; set; }
    }

As we have no resource that contains our properties’ localization, it could be a good idea to use the dynamic localization by implementing a custom LocalizationProvider. The custom  LocalizationProvider enables the localization on the fly by means of Microsoft Translator Service (You can find the code implementation in the Localization Library’s quickstart).

Next step is to decorate the properties with the attribute for dynamic localization. Below you can see the implementation.

    /// <summary>
    /// Defines the account's <see cref="LocalizationModel"/>.
    /// </summary>
    public class AccountLM : LocalizationModel
    {
        //Properties

        [LocalizeDynamically("FirstNameKey")]
        [LocalizeDynamically(Language = "en", Value = "First name")]
        [LocalizeDynamically(Language = "it", Value = "Nome")]
        public String FirstName { get; set; }

        [LocalizeDynamically("LastNameKey")]
        [LocalizeDynamically(Language = "en", Value = "Last name")]
        [LocalizeDynamically(Language = "it", Value = "Cognome")]
        public String LastName { get; set; }

        [LocalizeDynamically("AddressKey")]
        [LocalizeDynamically(Language = "en", Value = "Address")]
        [LocalizeDynamically(Language = "it", Value = "Indirizzo")]
        public String Address { get; set; }

        [LocalizeDynamically("TownKey")]
        [LocalizeDynamically(Language = "en", Value = "Town")]
        [LocalizeDynamically(Language = "it", Value = "Città")]
        public String Town { get; set; }

        [LocalizeDynamically("PostcodeKey")]
        [LocalizeDynamically(Language = "en", Value = "Postcode")]
        [LocalizeDynamically(Language = "it", Value = "Codice postale")]
        public String Postcode { get; set; }

        [LocalizeDynamically("BirthdayKey")]
        [LocalizeDynamically(Language = "en", Value = "Birthday")]
        [LocalizeDynamically(Language = "it", Value = "Data di nascita")]
        public String Birthday { get; set; }
    }

The AccountLM defines the English and Italian localizations for our property whilst the  localization for the other languages will be provided by the custom LocalizationProvider. In this way we have completed the LocalizationModel’s implementation.

Finally  we should only define the bindings among the properties and localized properties and enjoy the localization.

<TextBlock Text="{Binding ElementName=view, Path=LocalizationModel.FirstName}"/>
<TextBlock Text="{Binding ElementName=view, Path=LocalizationModel.LastName}"/>
<TextBlock Text="{Binding ElementName=view, Path=LocalizationModel.Address}"/>
<TextBlock Text="{Binding ElementName=view, Path=LocalizationModel.Town}"/>
<TextBlock Text="{Binding ElementName=view, Path=LocalizationModel.Postcode}"/>
<TextBlock Text="{Binding ElementName=view, Path=LocalizationModel.Birthday}"/>
If you want to use a ViewModel as LocalizationModel, the only restriction is that the ViewModel have to implements the INotifyPropertyChanged interface.
AccountPMLM
 
NOTE: This is only a simple sample, all the features provided by the Localization Library will be described in detail in the documentation.

Last edited Sep 28, 2011 at 11:03 PM by nicolagmt, version 143