Infosys Microsoft Alliance and Solutions blog

« Logging Events with User details | Main | Webinar: Leap Ahead with Windows Vista »

LocBAML to Localize WPF Applications

Recently I was trying to work with LocBAML (default installation location - C:\Program Files\Microsoft SDKs\Windows\v6.0\Samples\WPFSamples\GlobalizationLocalization\LocBaml) to generate localized version of my WPF application. Things worked fine, but I did observe a few differences from what is documented on MSDN Site and this another detailed article. Two main observations

The command LocBaml.exe /parse HelloApp.resources.dll /out:c:\Hello.csv (as discussed in the MSDN article) didn't work. I got a "cannot load HelloApp.resources.dll or one of dependencies error". What worked for me was this - LocBaml.exe /parse HelloApp.g.en-US.resources /out:c:\Hello.csv.

Note that the *.g.en_US.resources file is found in the \Obj\Debug directory (for Debug build configuration).

The second observation is while generating the resources assembly by using the localized .csv file (say for fr-CA culture), the command LocBaml.exe /generate HelloApp.resources.dll /trans:Hello.csv /out:c:\ /cul:fr-CA works only if HelloApp.resources.dll is in the same folder already. This is strange, since the command is used to create the localized resource assembly and hence it can't be already present. I had to copy the existing english resource file in the same folder from where I was running this command and then pointed the output to a different location to get the french version of the localized resources assembly and then deploy it appropriately.

Will try this on VS 2008 Beta 2 also and see if there is a difference of behavior.

Comments

I've also run into the "cannot load .resources.dll or one of dependencies error" problem recently. I've been unable to get it passed even after pointing to the .g.en-US.resources file. Not sure where I'm going wrong.

As I have mentioned for the next issue, you may want to try by copying the "appname".resources.dll file to the same folder initially itself and then work.

I have a WPF application which supports globalization. But if user tries to enter Chinese numbers using IME pad in a numeric only textbox, the conversion logic to convert this entry to integer is failing.

Code I am using for conversion is:

private bool IsNumeric(char valueToCheck)
{

int result = new int();
return int.TryParse(valueToCheck.ToString(), System.Globalization.NumberStyles.Any, CultureInfo.CurrentCulture, out result);
}

I am checking if the entry is numeric or not, but this is returning false for chinese numbers.

I have set the culture of the application to Chinese by executing below lines:

string culture = "zh-CN";
System.Threading.Thread.CurrentThread.CurrentUICulture =
new System.Globalization.CultureInfo(culture);
System.Threading.Thread.CurrentThread.CurrentCulture =
new System.Globalization.CultureInfo(culture);

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter