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?

# WPF Localization@ Monday, August 25, 2008 7:08 AM

WPF Localization

# re: WPF Localization@ Tuesday, September 09, 2008 10:45 AM

Hi,

I have *almost* the same point of view as PierreMF:

1: i want to set my uids. I don't like the command-line tool because we do not master what it does (UID names,...) and a lot of useless UIDs are set (it depends on which level of localization we do, but most of the time i don't want to set an UID to every column definition of my grid...)

But this is very constraining. Because i want a tool to do this. Something customizable, inside of Visual Studio.

2: Same

3: I would like the locbaml-like tool to output a specific file (why not your controversial OpenXML format :)), which can be editable with a complete new localization tool, same as Alchemy Catalyst (see also http://www.sisulizer.com/ and www.lingobit.com/products for those I know)

4: Same. Make it as simple & clean as Winforms !!!

Please :)

Do you have any date or preview of the future of localization in WPF?

Thanks

Aline

# re: WPF Localization@ Sunday, October 19, 2008 8:46 AM

Hi Rob,

I"m now begining to think about localization in a new hugh application. and wanted to know what's the current best approach.

our application consists of many many dlls, in each many usercontrols.

is there somewhere out there a sample top to bottom how to accomplish this?

also, what do you think about those two tools?

www.codeproject.com/.../WPF_Localization.aspx

www.codeproject.com/.../ZetaResourceEditor.aspx

thanks,

Yanai

# re: WPF Localization@ Friday, October 24, 2008 12:03 PM

A simple way to do localisation in WPF is to write a custom markup extension. This allows you to chose the kind of resource dictionary you like and to switch the language at runtime.

You can find an article about it here: www.wpftutorial.net/LocalizeMarkupExtension.html

# re: WPF Localization@ Tuesday, December 16, 2008 5:12 AM

Hi Rob,

I am using LocBaml for a localization process about WPF resource. However I got garbled strings on German and French. I don't konw why that is. How could that be fixed?

Thanks

Paul

# re: WPF Localization@ Saturday, January 31, 2009 10:43 PM

www.codeproject.com/.../LocBamlClickOnce.aspx

# REG. Locbaml Vs ResX | keyongtech@ Wednesday, February 25, 2009 5:08 PM

Pingback from  REG. Locbaml Vs ResX | keyongtech

# re: WPF Localization@ Thursday, February 26, 2009 4:31 PM

i am writing a code to load resource manager

if (Thread.CurrentThread.CurrentCulture.Name.Equals("de-DE"))

{

               rm = new ResourceManager("test.Resources.test.de_DE", Assembly.GetExecutingAssembly());

           }

however i want to load a different resource named abc.resx as below

rm = new ResourceManager("abc.resx", Assembly.GetExecutingAssembly());

           }

code compiles fine, but i am getting an xml parser error when i used rm.getstring method on it.

-Bob

# re: WPF Localization@ Saturday, February 28, 2009 11:02 AM

Quick question, with maybe a long answer :)

So I've looked over a several options of localizing my large-scale app, and have had a hard time deciding on which methodology to use.  At this point, we're thinking it might be wise to struggle our way through the Uid/LocBaml route, even if it is a bit of a hassle to do so much manual labor with it - I really liked the idea of using resx files and the ability to switch languages at run-time, but decided it wasn't a necessity.  We figured that in .NET 4.0 there would be a large upgrade and improvement to WPF's localization features.

So the question...  what improvements and additions are being worked into to the next version?  Is there any sort of ETA?  Would it be safe to say that if we plug in the current WPF Localization, that .NET 4 would be semi-backwards-compatible?

Longer question than I expected.  Sorry :)

# re: WPF Localization@ Tuesday, May 12, 2009 9:26 AM

Came upon this blog and found some interesting points.

We also have a very large application platform built on WPF, to localize. These components have mixing of XAML, RESX. In my opinion, post-build localization is the only way to effectively tackle enterprise level WPF localization. Guys, we are not developing our own little application by ourselves (I mean, myself) any longer - those days are long gone.  

We have since developed an effective approach to localize .Net applications, including WPF, using techniques such as post-build resource construction.

Rob, I have an MSDN case pending with you guys on BamlLocalizer which loads all references in execution mode while examining BAML resources as you rightly pointed out in the beginning of your post. How did that go - was it in 3.5SP1?

Drop me a line to: RoundRobin AT Gmail.com if you want to reach me offline.

# re: WPF Localization@ Monday, June 22, 2009 11:14 AM

Hi,

Our developers at Alchemy Software are constantly working to make your localisation process simpler.  

At least try Alchemy Catalyst out, send an email to shamusd@alchemysoftware.com and I will send you a free 7 day full licence for Alchemy Catalyst.

Version 8.1 is due to be released at the end of this week, version 8.1 will be incorporating even more wpf, xamal improvements.