introduction

the last days i finished a small pocket pc clock application to use when i am working in another city (i am boring to wake up in morning with the windows sound). the application was ok, and a friend said me, why not i localize the application and sales it? the localization was not easy for me, because despite the simple methods that the framework implements, a bug in cabwiz.exe application make the work complicate.

here i presented condensed information, that i found in different sources, about a methodology to implement the resources localization under the net compact framework 2.0 and visual studio 2005.

background

visual studio 2005 comes with a very practical feature to localize resources, in particular you can localize the strings in the forms to individual languages and also you can localize internal strings in individual resources files.

in this article will be described how to localize in three languages the example project form, how to localize internal string, and how to do a wordaround to deploy the application cab file to the target device to avoid the cabwiz bug.

we use a simple application as example, of course, the "ineffable" hello world. we localize the application in english (default), german and spanish. the application shows a hello label and a button to open a dialog with the word "world" in the localized language.

to test the application you should change the localization of the emulator to the correct language.

step 1: create a test project helloword:

create a simple windows ce pocket pc project with the controls that you can see in the figure 1. the application will show the strings localized in the selected language in the control panel.

step 2:localize the control’s form for spanish, english and german

language= select your desired language

localizable = true; 
 

when you select, in language a item different to" default", a new resource file is created and you can direct in the form, modify all controls strings. in the example i localized the form in english, german and spanish.

caution: does not use the localized form to move or modify the control properties. use only the "default" form unless you want a specific behaviour for a form’s controls. you can see in solution explorer below the form1.cs the created resources files.

we don’t need to create the english resources because we use then as “default” language.

the net framework, watchs the possible language resources files, and when it does not found any that match, use the default resource embedded in the assembly.

build and run the project. you can see the form localized in the language of your pocket pc (the value of regional setting in setting/ region.). you need to reset the emulator to take the new setting.

see figure 2 about the created resources in form and the compiled satellite assembly with the resources in figure 3.

step 3: localize internal string message as strong type resource.

now we incorporate the function of show a message box form with the "world" word, when the button is clicked. the dialog box contains a string that should be localized.

to localize the string we need to create a resource file for each language. visual studio set the default resource file below the properties directory.

open the property directory in your project and see the file resources.resx.

double click the file and you can see the resource editor. because we defined the english as default language we enter the english resource direct in this file. enter in the editor a string resource with the following value:

   
name = messagetext 
value= world!

to enter the localizated resources, click and copy the file resources.resx, and then create copy of this file in the same directory.

rename the create files to resources.de.resx and resources.es.resx

open those two files and enter the resource string as follow:

resources.de.resx
name = messagetext
value= welt!
 
resources.es.resx
name = messagetext
value= mundo!

in properties, for the added resources files, you should clear the property customtool. only maintain the value resxfilecodegenerator for the default resources.resx file.

rebuild the system; your solution explorer should look as showed in the following figure.

double click over the button to create a click_event and enter the following simple code.

 
private void button1_click(object sender, eventargs e)
{
      //get localized resource and show it in the message box.
      messagebox.show(properties.resources.messagetext);
}    

you can see in the example how to use programatically the resource. the utility resxfilecodegenerator automatic generated a properties.resources class to access the resource

the framework automatic detect the regional setting for the pocket pc and takes the correct localized resource, in the situation that the regional setting does not coincidence with the existents resources, the net framework take the resource language declared in the default resource file.

for more information you can see in the demo project the file resorce.designer.cs with the code of the generate class. now build the application and test for different regional setting the translated values.

step 4: life is not easy. cabwiz bug workaround

the deploy part of the application, normally should not has to do with the localization process, but because in the cabwiz.exe application, that comes with vs 2005 has a bug, we need to do extra steps to finish the process.

exist a well know bug in the cabwiz.exe program for visual studio 2005 and i am afraid (not sure) that it also exist in visual studio 2008 [1].

take a look to the helloworldcabsetup project in the example. if you deploy the resulted cab, you find that the localized resources do not work correct.

to test, set your pocket pc to spanish in control panel, and install the cab file. you can see that the form strings are still in english. that mining that the resources are not correctly loaded.

the bug is produced, because the name of the resource dll file are all the same. when the cabwiz read the inf file it use the same resource.dll file for all operation and ignore the fact that are in different directories ans are differents files. see the example code, project helloworldcabsetup.

in the reference [1] exists two workarounds to resolve this problem. here it is implemented a solution based in them

to correct the bug, we should do the following steps.

1. - in helloworld project define a post-build action to make a copy of the resources files with another name.

you can make the copy of the dll using line command in the post-built event from project. following the needed code:

copy "$(targetdir)de\helloworld.resources.dll"¬ 
"$(targetdir)de\de_helloworld.resources.dll"
copy "$(targetdir)es\helloworld.resources.dll"¬
"$(targetdir)es\es_helloworld.resources.dll"

if all it is ok, you can see the copied resources in the resources directories after a successful build. (see example)

2.- create a second deploy project

you can use the first deploy project, but to demonstration purpose i made the change in another deploy project. name it helloworldcabpatch. configure it by the first deploy, but assign the following renamed resource dll to the new created deploy project, instead the original names.

de_helloworld.resources.dll
es_helloworld.resources.dll 

build the project, and you can see in the inf file, the names of the rename dlls.

[files.common1] 
"de_helloworld.resources.dll","de_helloworld.resources.dll",,0 

[files.common2] 
"es_helloworld.resources.dll","es_helloworld.resources.dll",,0
 

obviously we can not use those names in our application, and then we should rename them and run again the cabwiz.exe file.

you can simple rename it in the inf file and re-run manually the cabwiz.exe utility, but that it not practical. we need to do automatically this process.

to do it we created a small program to patch the inf file and run the cabmwiz.exe

3.- create a console program to patch de inf file

see in code the program under cabwizpatch, that simple "patch" the inf file to generate the correct filenames. (yes, yes i know, the method that i use it is a bit brute force, but works perfect for the example), if you run the program yo can see that the [files.commonx] entries are modificate to instruct cabwiz.exe tocopy the resources files with the oroginal names. you can see the modification in the following code

[files.common1]
"helloworld.resources.dll","de_helloworld.resources.dll",,0 

[files.common2]
"helloworld.resources.dll","es_helloworld.resources.dll",,0 

4.- process automation
you can easily automate the process by created a dummy project and use the pre-build event to execute the console patch application and the post-build event to call to cabwiz.exe.

the code to do so is:

//pre-build event

"$(solutiondir)cabwizpatch\bin\debug\cabwizpatch.exe"¬
"$(solutiondir)helloworldcabpatch\debug\helloworldcabpatch.inf"

//post-build event

"c:\program files\microsoft visual studio 8\smartdevices\sdk¬
\sdktools\cabwiz.exe" "$(solutiondir)helloworldcabpatch¬
\debug\helloworldcabpatch.inf"

    

in the following image you can see the command in pre and post build event in the dummyclass project.

note: be sure that your dummy class project is build at end of the build process.

use the cab (under helloworldcabpath/bin/debug directory) and you see that your application use now the correct resources values.

if you want to use a msi installer, you can run the patch component in the pre and post build event of the msi installer project. now when you deploy the application you can see that your resources are correctly display in your pocket pc

code

download and compile with the debug option the code attached to article

the code and the explanation in the article is refered to debug compilation. you should adjust the code to release code build

project identification (in order)

1. cabwizpatch: console application to patch the resulted inf file.
2. dummyclass: class project, without output. it is use to run the console cabwizpatch in the pre-build event and to call the cabwiz.exe application in the post-built event.
3. helloworld: windowsce project, the application to deploy
4. helloworldcabpath: replica of the helloworldcabsetup to demostrate how to change the deploy project to get the correct resources dll.
5. helloworldcabsetup: original setup to demostrate the cabwiz bug. in the real worls, you only use 4)

see carefully the code, maybe you should modificate the path of the cabwiz application in your particular computer.

points of interest

the process of localize resources in visual studio 2005 is simple and should not gives head heaches to the developers. unfortunally a bug in cabwiz can give us a terrible confusion, because the result of our job when we make the deploy under vs2005 and when we install the application with the generated cab is complete different for the localization resource point of view.

this article wants to condensed the information about the resources in only one place. i hope that it can help.

bibliography

[1] microsoft connect. smart device cab project includes wrong localized resources.

history

30.07.2008 initial release