Skip to main content

WPF Localization - LocBaml

In my last post I talked about using resource files (resx) to localize your WPF application. This time it is about using LocBaml to localize your WPF application. The big difference in the two approaches is that LocBaml allows you to localize your application after the fact. That is, most applications you have to plan up front to do localization, but with LocBaml you can still localize your application after development. While lots of people will say this I don't really believe it. The reason this is not true in my opinion is because LocBaml only works if all your strings are sourced in XAML. This means that if you use strings that are located in a constant file or a resx file LocBaml  will not work to localize your application. Unless you are building a smaller application or you just happen to set up your architecture so all strings are sourced in XAML you are out of luck. So really when they say you can localize your application after the fact you really can only do it if you happened to conform your application to the requirements of LocBaml. On that note lets get into preparing the application with UIDs.

In my previous example I had three labels in my application. The first label had its text defined in XAML. The other two used resx files to define their text. In this walk through we will update the first label so we can localize it as well. The first thing we want to take note of is the current XAML layout of our label.

<Label Height="28" Margin="10,13,33,0" 
  Name="lblFromXAML" Content="Text from XAML" 
  VerticalAlignment="Top"></Label>
You will notice nothing special about the XAML here. Now we will run the LocBaml commands. To do this we open a visual studio command prompt and run msbuild with the updateuid command switch (msbuild /t:updateuid wpflocalization.csproj). After running this command we get the follow results in the command windows.

image

Now if you look at the XAML that makes up the label you will see the addition of UID attribute.

<Label x:Uid="lblFromXAML" Height="28" Margin="10,13,33,0" 
Name="lblFromXAML" Content="Text from XAML" 
 VerticalAlignment="Top"></Label>
This UID attribute tags each localization part of the application and will allow the LocBaml utility to find each one of these areas for localization. Now when you build the application you will have a .resource.dll file in the en-US folder. It is now time to jump through hoop 1 (really hoop two because setting up UIDs should be hoop 1). You must get the SDK and build the LocBaml project to get the LocBaml.exe. Once you have done this it is time for hoop 2. Run LocBaml against the US resource dll using the following syntax: LocBaml.exe /parse en-US/WpfLocalization.resources.dll /out:UsText.csv. This will export all the XAML fields marked with a UID to the csv file. The csv file that is created has  a few lines per UID item. Here is what the csv file looks like. Had enough yet? Sorry we are not done. You should notice that in the csv file only has the text for one of our three labels (lblFromXAML). The text that is the resource file is not pulled out into the csv file. This is because LocBaml only works when all strings are sourced in XAML (something you have to take into account at design time). Now you need to pass this csv file off to someone to translate. Now Hoop 3, it is time to run LocBaml again to create our de-DE resources.dll. Once that is done you can drop that dll into your resources directory and change your localization to de-DE and the new text should show up.

If you could not tell there are a lot of hoops to get through doing localization this way. Personal, I think the process is pretty ridiculous. I have no idea why someone would do localization this way instead of using resx files. I see only cons to this approach and no advantages over the resx approach. If you have a different opinion I would really like to hear your thoughts.

Comments

Konstantin said…
There is free addin at http://easybaml.codeplex.com, with which BAML localization process is much easier.

Popular posts from this blog

Uniting Testing Expression Predicate with Moq

I recently was setting up a repository in a project with an interface on all repositories that took a predicate. As part of this I needed to mock out this call so I could unit test my code. The vast majority of samples out there for mocking an expression predicate just is It.IsAny<> which is not very helpful as it does not test anything other then verify it got a predicate. What if you actually want to test that you got a certain predicate though? It is actually pretty easy to do but not very straight forward. Here is what you do for the It.IsAny<> approach in case someone is looking for that. this .bindingRepository.Setup(c => c.Get(It.IsAny<Expression<Func<UserBinding, bool >>>())) .Returns( new List<UserBinding>() { defaultBinding }.AsQueryable()); This example just says to always return a collection of UserBindings that contain “defaultBinding” (which is an object I setup previously). Here is what it looks like when you want to pass in an exp

Password Management

The need to create, store and manage passwords is a huge responsibility in modern day life. So why is it that so many people do it so poorly? This is a loaded questions with answers ranging from people being uneducated, to lazy, to educated but not affective in their methods and many more. This blog is to help those (in some way even myself) around me strengthen their online security. Why does it matter? To answer this let's look at a few numbers. According to the US Department of Justice (DOJ)’s most recent study , 17.6 million people in the US experience some form of identity theft each year. Ok fine but that is identity theft that has nothing to do with password management. What is one way someone can start getting information about who you are? How do they get access to steal your money? From Cyber Security Ventures 2019 report : "Cybersecurity Ventures predicts that healthcare will suffer 2-3X more cyberattacks in 2019 than the average amount for other industries. W

Excel XIRR and C#

I have spend that last couple days trying to figure out how to run and Excel XIRR function in a C# application. This process has been more painful that I thought it would have been when started. To save others (or myself the pain in the future if I have to do it again) I thought I would right a post about this (as post about XIRR in C# have been hard to come by). Lets start with the easy part first. In order to make this call you need to use the Microsoft.Office.Interop.Excel dll. When you use this dll take note of what version of the dll you are using. If you are using a version less then 12 (at the time of this writing 12 was the highest version) you will not have an XIRR function call. This does not mean you cannot still do XIRR though. As of version 12 (a.k.a Office 2007) the XIRR function is a built in function to Excel. Prior version need an add-in to use this function. Even if you have version 12 of the interop though it does not mean you will be able to use the function. The

Experience Profile Anonymous, Unknown and Known contacts

When you first get started with Sitecore's experience profile the reporting for contacts can cause a little confusion. There are 3 terms that are thrown around, 1) Anonymous 2) Unknown 3) Known. When you read the docs they can bleed into each other a little. First, have a read through the Sitecore tracking documentation to get a feel for what Sitecore is trying to do. There are a couple key things here to first understand: Unless you call " IdentifyAs() " for request the contact is always anonymous.  Tracking of anonymous contacts is off by default.  Even if you call "IdentifyAs()" if you don't set facet values for the contact (like first name and email) the contact will still show up in your experience profile as "unknown" (because it has no facet data to display).  Enabled Anonymous contacts Notice in the picture I have two contacts marked in a red box. Those are my "known" contacts that I called "IdentifyAs"

Anatomy of Sitecore Business Rule - Macros

In previous posts, we talked about  field syntax and the basic structure of business rules . This time we are going to dive into macros in the business rules. Macros are used as part of the business rule syntax. The syntax looks like this and calls for 4 parameters. [Property to set, Operator/Macro, AdditionalParameters, Display text]. When I first started working with business rules the difference between operator and macro was confusing. To add to this confusion some of the out-of-the-box macros are named with the term "operator" (like ListOperator who's configuration points to a class called ListMacro and the class implements IRuleMacro). Anything under the path /sitecore/system/Settings/Rules/Definitions/Macros should be a macro and should implement IRuleMacro. Macros have the follow characteristics: They inherit the IRuleMacro interface The interface requires this execute method void Execute(XElement element, string name, UrlString parameters, string value)