Localization of XAML, WPF applications.

As you may know, localization and globalization of user interfaces have been a topic I like to discuss. Being bilingual, I like to give the opportunity to applications to show their glory in several languages.

In my previous jobs, I have localized ASP.NET Web Forms and ASP.NET MVC forms, and also Windows Forms, but the other day someone asked me about WPF/XAML and MVVM. How to localize a XAML markup.

This is what this post is all about. Back in 2007, a coworker and I wrote a Localization Toolkit and published all the code Open Source at CodePlex, after writing an article about the new features in .NET 2.0 and Visual Studio 2005 that allowed you to generate resources files from the literal strings embedded on an ASP.NET web form.

Fast forward a few years to the end of 2007 and beginning of 2008, with the outcome of WPF, are resources files still in use?

Yup, they still are, and they are selected by the same mechanism that selects a given satellite assembly given the UI Thread Culture. The same mechanism that was available in the .NET world in 2005 for ASP.NET Web Forms.

Satellite assemblies are nothing but key/value pairs stored in a resource file that the ResourceManager type can search by Key.

Now, let’s say I generated resource file (.resx) for a given locale and region (fr-FR or fr-CA) and I want the resource file key bound to the XAML view after the UI Culture Thread is set to the OS locale and region, or after the user selects the locale and region he would like. Notice there are two settings to set with the locale and region: the UI Thread and the current thread. They are different.

            CultureInfo ci = new CultureInfo("fr-CA");
            Thread.CurrentThread.CurrentCulture = ci;
            Thread.CurrentThread.CurrentUICulture = ci;

 

How are the literal values bound to the proper resources file holding the locale and regional translation?

Within the Window tag of your XAML window file, add the following line of code:

xmlns:properties="clr-namespace:YourAssemblyName.Properties"

For each control within our grid (Button, Labels and Window Title) do not set the Title or Content values to static text. Instead use the resources file value.

<Label Content="{x:Static properties:Resources.LabelFirstName}"…/>
<Button Content="{x:Static properties:Resources.ButtonSubmit}"…/>

There are also other projects at GitHub that have been added recently specifically for WPF: WPFSharp.Globalizer which offers a better option than the LocBalm tool to generate and  maintain the resources files for translation.

LocBaml is the de-facto tool documented on MSDN for WPF resource generation, but there are other projects such as the one mentioned above and the NuGet package ResXManager that offers more features.

LocBalm will generate UiDs on your XAML markup that will link automatically to the regional resource after the Current UI Thread is set. LocBalm can also be used to generate the different resource files after the application is developed, using the option to parse the main assembly for XAML markup.

Parlez vous Français? Oui, mais mon interface ne parler pas.

To nvarchar or to varchar in SQL Server to accept French text

I found one single character from the French language that its binary representation is not the same for Unicode and Windows-1252. The oe ligature. Let me rant about it…

create table test_table
(name1 varchar (1) ,
name2 nvarchar (1) )

insert test_table
values (‘œ’, ‘œ’)

select * from test_table

select ASCII(name1), ASCII(name2), Unicode(name1), unicode(name2) from test_table

select COL_LENGTH(‘test_table’,’name1′) as Length1, COL_LENGTH(‘test_table’,’name2′) as Length2 from test_table

select char(156), char(339)

drop table test_table

This character is used in the word “eggs” in French
‘des œufs’ means some eggs…

These first two sets of characters from the Latin alphabet have identical Unicode and Windows-1252 (ASCII) character code.
(Basic Latin)
http://en.wikipedia.org/wiki/Basic_Latin_Unicode_block
and
Latin-1:
http://en.wikipedia.org/wiki/Latin-1_Supplement_Unicode_block

Their binary representation is the same as they all fit in one single byte or octet.

However, the extended Latin characters do not have the same Windows-1252 (ASCII) code and Unicode code.
http://en.wikipedia.org/wiki/Latin_Extended-A_Unicode_block

From this character set, French only uses the oe ligature though.

French accents and ligatures and how to type them with the number pad:
a with grave accent
à ALT + 133 À ALT + 0192

a with circumflex
â ALT + 131 Â ALT + 0194

a with tréma
ä ALT + 132 Ä ALT + 142

a e ligature
æ ALT + 145 Æ ALT + 146

c with cedilla
ç ALT + 135 Ç ALT + 128

e with acute accent
é ALT + 130 É ALT + 144

e with grave accent
è ALT + 138 È ALT + 0200

e with circumflex
ê ALT + 136 Ê ALT + 0202

e with tréma
ë ALT + 137 Ë ALT + 0203

i with circumflex
î ALT + 140 Î ALT + 0206

i with tréma
ï ALT + 139 Ï ALT + 0207

o with circumflex
ô ALT + 147 Ô ALT + 0212

o e ligature
œ ALT + 0156 Œ ALT + 0140

u with grave accent
ù ALT + 151 Ù ALT + 0217

u with circumflex
û ALT + 150 Û ALT + 0219

u with tréma
ü ALT + 129 Ü ALT + 154

French quotation marks
« ALT + 174 » ALT + 175

Euro symbol
€ ALT + 0128

The Windows-1252 encoding can be seen here:
http://www.visibone.com/htmlref/char/webascii.htm

For more, see Joel on Software rant :-p

As most questions in technology, the answer is: it depends.

http://stackoverflow.com/questions/35366/varchar-vs-nvarchar-performance

Performance wise, varchar is more efficient, less memory space, 20% to 30% smaller indexes.
Most database drivers will interpret the incoming stream and convert to Windows-1252 encoding, if the server code page is Windows 1252.
If you use way too many characters in the extended Latin group, you have no choice but using nvarchar…if you deal with other languages that are not Romance Languages, you have no choice but nvarchar.

Cheers!