Alessandro Del Sole's Blog

/* A programming space about Microsoft® .NET® */
posts - 159, comments - 0, trackbacks - 0

My Links

News

Your host

This is me! This space is about Microsoft® .NET® and Microsoft® Visual Basic development. Enjoy! :-)

These postings are provided 'AS IS' for entertainment purposes only with absolutely no warranty expressed or implied and confer no rights.

Microsoft MVP

My MVP Profile

I'm a VB!

Watch my interview in Seattle

My new book on VB 2015!

Pre-order VB 2015 Unleashed Pre-order my new book "Visual Basic 2015 Unleashed". Click for more info!

My new book on LightSwitch!

Visual Studio LightSwitch Unleashed My book "Visual Studio LightSwitch Unleashed" is available. Click the cover!

Your visits

Follow me on Twitter!

CodePlex download Download my open-source projects from CodePlex!

Article Categories

Archives

Post Categories

.NET Framework

Blogroll

Help Authoring

Microsoft & MSDN

Setup & Deployment

Visual Basic 2005/2008/2010

WPF: localization foundations with Visual Basic

Localization can be an important improvement when developing applications. Windows Presentation Foundation offers to .NET developers the capability of localizing applications, even if this can be accomplished in a quite different way regarding what we are used to do in Windows Forms.

 

The first thing to be noticed is that, at the moment, localizing WPF applications is something that you can do manually. In fact there is just a command line tool and no support for visual designers. Even if this can appear annoying, in my opinion the localization in WPF apps is well organized because it takes the advantage from satellite assemblies.

 

What do we need?

 

The first thing we need for localizing WPF applications is a command line tool called LocBaml. You won’t find an executable version, but it’s available as source code through the MSDN Library. You can find LocBaml in this page. In the appearing page of the MSDN Library, you’ll find the link for downloading the source code for LocBaml. It’s constituted by a Visual C# project that you just need to open in Visual Studio 2008 and compile it. Once compiled, you can move LocBaml.exe from the Bin\Debug or Bin\Release folder to another folder that is easier for you to find.

 

Localization foundations

 

Localizing WPF applications is a task that is accomplished using resources. In a very few words, resources that are declared in XAML are first converted into .Baml files (that are more efficient to parse) and each of the .Baml files is defined as a resource inside the executable assembly. This is the reason about LocBaml’s name.

 

The first step you need to do to make a WPF application localizable, is editing the Visual Studio Project File (.Vbproj for Visual Basic and .Csproj for C#). You can create a new empty WPF project with Visual Basic for the sake of simplicity. So let’s open the .Vbproj file with a text editor, such as Notepad or any other editor you like. As you may know, the .*proj file is an XML file containing information about all the things that constitute our project. Inside one of the PropertyGroup sections, add the following line of markup code:

 

    <UICulture>en-US</UICulture>

 

This XML element allows us specifying what Culture object must be used for the user interface. In my example I’m telling VB to use the English (USA) culture.

Now we have to edit the AssemblyInfo.vb file (you can click the “Show all files” button in Solution Explorer). Locate and uncomment the following line of code:

 

<Assembly: NeutralResourcesLanguage("en-US", UltimateResourceFallbackLocation.Satellite)>

 

This will set the neutral culture. Next step is establishing what UI elements must be localized.

 

Localizing elements in the User Interface

 

Consider the following, very simple XAML code that declares a Window which contains one Button and one TextBlock:

 

<Window x:Class="Window1"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    Title="WPF localization demo" Height="300" Width="300">

   

    <StackPanel>

        <TextBlock Text="Unuseful text" Name="WelcomeTextBlock" />

       

        <Button Name="TestButton" Content="Click here" Width="100"/>

    </StackPanel>

</Window>

 

We want to make localizable the Window title, the text stored inside the TextBlock and the Button’s content. Each localizable item must be marked with an x:Uid attribute that receives a value represented by an identifier recalling the name of the item itself (this is required by MSBuild.exe behind the scenes). So let’s edit the above XAML as follows:

 

<Window x:Class="Window1" x:Uid="Window_1"

 

        <TextBlock Text="Unuseful text" Name="WelcomeTextBlock" x:Uid="Welcome_TextBlock"/>

       

        <Button Name="TestButton" x:Uid="Test_Button" Content="Click here" Width="100"/>

 

Let’s run the application:

 

 

As you can see, there is nothing different from what we would expect. But if you go and take a look to the Bin\Debug folder, then you’ll find a surprise. There is in fact a new folder called en-US, which contains an assembly named as your project followed by .Resources.Dll. This assembly stores, among other things, the resources that we marked as localizable. Basically this is a satellite assembly that is loaded when the application runs, with localization purposes. Things are now clearer: according to the Culture naming rules (e.g. it-IT, en-GB, en-US, fr-FR) we need to create as many sub-folders as many Cultures we need to implement. These steps are not difficult but they have to be accomplished manually. So let’s see what we have to do about.

 

Using LocBaml and Microsoft Excel

 

First of all, let’s copy LocBaml.exe to the subfolder that contains our executable, e.g. Bin\Debug (this is mandatory). We have to extract all the localizable content from our assembly and we can accomplish this by writing the following simple command line:

 

LocBaml.exe /parse en-US\MyApplication.exe

 

Where MyApplication.exe is the name of our application. LocBaml will generate a .Csv file, with fields separated by commas. Each row in the .Csv defines a particular resource and among resources we can find the localizable ones. The name of the .Csv file becomes, in our example, MyApplication.Resources.Csv. Let’s try and open this file with Microsoft Excel. As you can see in the following picture, there are the resources that we marked as localizable:

 

Let’s now imagine that we want to generate a localization for the English language based on the “it-IT” Culture object (Italian). We could edit the .Csv file as follows:

 

 

 

Let’s submit our changes saving the .Csv file with another name, e.g. MyApplication.Resources.itIT.Csv. Now we are ready to build our satellite assembly for the Italian localization.

 

Buiding the satellite assembly

 

Let’s go back to LocBaml and let’s type the following command line:

 

LocBaml.exe /generate en-US\MyApplication.Resources.dll /trans:MyApplication.Resources.itIT.csv /cul:it-IT /out:it-IT

 

Such command line tells LocBaml that the new assembly’s structure must be based on the previous one (/generate), that it has to translate the new .csv file (/trans), then it specifies the target Culture (/cul) and the target folder for the new satellite assembly (/out).

 

After running LocBaml, you’ll find a new folder called it-IT that will contain an assembly called MyApplication.Resources.dll (same name as the original one) that contains localized information.

 

Testing the application

 

We can try to simulate the it-IT culture for our application. Let’s switch to the Application.xaml.vb file and inside the Application’s class constructor we can type the following line of code:

 

        System.Threading.Thread.CurrentThread.CurrentUICulture = New Globalization.CultureInfo("it-IT")

 

The above code assigns the “it-IT” Culture to the UI thread and if we try and run now the application, we’ll get the following result:

 

 

 

Obviously, localization is usually complex, for example you may have the need of localizing and referencing external files. Anyway, we began understanding how localization works and the MSDN Library gives us lots of information. You can click here and here for deeper contents.

 

Alessandro

Print | posted on venerdì 8 maggio 2009 02:09 | Filed Under [ Visual Basic Windows Presentation Foundation ]

Feedback

No comments posted yet.

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 2 and 1 and type the answer here:

Powered by:
Powered By Subtext Powered By ASP.NET