Rob Relyea - Xamlified

# re: WPF Localization@ Thursday, April 10, 2008 9:34 AM

Hey Rob,

For information, the excellent Alchemy Catalyst just released a version which is able to localize WPF applications, including texts in XAML. We didn't test it yet, but this is very high on our todo list. I'll let you know how it works out.

Greetings,

Laurent

# re: WPF Localization@ Thursday, April 10, 2008 11:13 AM

Hi Rob!

I developed a project where I had to solve this problem. I did it by means of custom markup extension. I've written about it here: robbbloggg.blogspot.com/.../xaml-localization.html

Best regards, Robert

# re: WPF Localization@ Sunday, April 13, 2008 11:44 PM

And then there's the option of just using XAML and ResourceDictionary, which should be right up Mr. XAML's alley, right Rob?

www.geektieguy.com/.../localizing-an-xbap-application-without-using-locbaml

Works with non-XBAP WPF apps, too, of course.

It simple, maybe to the point of being simplistic, but it works well.

# re: WPF Localization@ Tuesday, April 22, 2008 12:04 PM

I would like something which is easy to use and simple.

1) I manually add some x:UId tags in the XAML tags that I want to have localized, even in my own tags ("content" property has to be translated in this case).

Sample:

<DockPanel>

 <Menu DockPanel.Dock="Top">

   <MenuItem x:Uid="MnFile" Header="_Fichier">

 ...

 <ToolBar DockPanel.Dock="Left">

   <MyNamespace:Mycontrol x:Uid="ToolSelect" Content="Sélection"/>

2) There is an option somewhere in VS that says "put the BAML resources in a separate DLL, and my default language is xx-XX". Instead of inserting <UICulture>xx-XX</UICulture> in the CSProj file.

3) Make a LocBaml-export tool that runs inside VS, parses XAML files of the project, and outputs a text file. I usually give a textfile to the people that translate softwares.

4) Make a LocBaml-import tool that runs inside VS, and which manages a list of locales (en-US, fr-FR, de-DE, etc.), a list of textfiles, and generates a list of resource DLLs, using translated text files.

Not that hard to do? Just wondering why you did not make it earlier ;)

# re: WPF Localization@ Tuesday, April 22, 2008 12:05 PM

Oh ! I forgot to say "please".

Sorry ;)

# re: WPF Localization@ Thursday, April 24, 2008 10:12 AM

Hey Rob,

since you mentioned that the WPF team still believes in post-build localization model using LocBaml: I see a couple of major issues using this approach:

1) The method which is recommended in the documentation results in storing the whole Window (or Page) as a resource in the satellite assembly. This makes changing a Window (or Page) after the localization a very hard task. Apart from the fact that the whole localization process must be repeated, one has to create new CSV files for each supported culture and synchronize them with already existing translations.

2) LocBaml has a major issue (at least for German systems): It uses a comma (,) as the column delimiter. If a text has a comma inside. LocBaml fails. If the comma was inserted within the translation process, LocBaml simply does not recognize the text from the comma (since this is simply a new column). Even if you take another demiliter, it is still highly possible that this delimiter is used within the text. My opinion is, that CSV files are absolutely not suitable for localization.

3) I assume that a company which deploys different applications using Windows.Forms, ASP.NET and WPF would really like to use the same basic method to localize their apps. The only common base for that are resx files. So: What is the reason for creating a specialized, complicated solution for WPF in conjunction with the fact, that resx files work very well since years?

4) resx fiels are very handy in terms of sending them to an external translator. Converting them into another format is also very easy.

My suggestion is: Throw LocBaml away and develop tools for the convenient handling of resx files instead (i. e. convert all .resx files of a project to a Word document, which is much easier to translate).

# re: WPF Localization@ Friday, May 02, 2008 2:40 AM

Just spent a few days playing with XAML localisation, but only just found this blog. Now, I am in awe of the .Net framework and I don't mind wpf, but quite frankly locbaml sucks...

1. Download as a "sample"??? wtf

2. copy to debug folder

3. command line only

4. extracts tons of irrelevant junk

5. source type is text file

6. app crashes when localised assembly is missing

No wonder that people are coming up with their own ways rather than use locbaml! Personally, I'll be using the resource dictionary approach.

# re: WPF Localization@ Friday, May 16, 2008 6:03 AM

I looked at WPF localisation for the first time last night and my first impressions were that it was a terrible backwards step compared to the existing .NET 2.0 WinForms approach.

I develop mainly in WinForms, but even when I write non-graphical components I use RESX file the store strings such that I could easily create localised satelite assemblies should I so wish.

I would want to retain the ability to provide additional languages post build, but would like to see the same type of integration in VS as I had in WinForms for VS 2005.

By this I mean, for a WPF form (xaml) I should set a property to Localisable = true, which should add x:Uid and create ids when first set on all existing elements and every subsequent element that is added automatically gets a Uid assigned. Should I turn off localisation by setting this property to false, then all the Uid attribute should be removed.

The strings (or indeed other types) that are mentioned in the WPF should be stored in a resx just like WinForms.

I really like the simplicity of WinForms localisation - I also use this same mechanism to go beyond localisation to help support aspects of branding and licensing - but it is a simple, effectively solution that doesn't require me think too much when creating the application as I just type in my strings and they are taken as the default localisaed language.

# re: WPF Localization@ Friday, May 23, 2008 9:22 AM

@Juergen

You want to be careful with the idea of passing RESX files to translators. It might be enough in some scenarios, but it is clearly not sufficient (even in the case of a WinForms application) for big firms. We never send RESX files to be translated, we sent DLLs. Embedded resources also need to be localized (and in the case of WPF, you also have resources in the DLL that are not "embedded" but just "resources", for the pack URI. Additionally, the translator needs to change the layout of the UI (that was very very true in WinForms, that might be less true in WPF where you have flow layout). You know like me that German (or French) words need a lot more space than English.

Additionally, for WPF, defining texts in the RESX only is not practical. You would find yourself in the same situation as in ASP.NET, where you need to have painful routines getting the strings from the RESX and assigning them to the ASP.NET controls. If we can avoid that (and I believe that the x:Uid approach allows this), then I will be a really happy camper, er, I mean coder.

Greetings,

Laurent

# When To Adopt WPF@ Friday, May 30, 2008 8:04 PM

One of the questions we frequently get when meeting with customers is whether or not to adopt WPF over

# re: WPF Localization@ Friday, August 15, 2008 3:21 PM

Was there any improvements/changes to tWPF loc with .net 3.5 SP1?