When you first start writing DotNet applications, you quite impressed to learn that MS has provided features / tools to make it possible to internationalize your application.
Which is true, but once you have finished your application you´re still left with some problems.
Before I go into those, I´ll run through the things you need to do to before you Internationalise your application.
There are different ways of achieving this goal, but by far the easiest approach is as follows.
Firstly, finish your application.
Next go round all your forms and set Localized to true.
This will add a lot more detail to your RESX files, one for each form.
You can now send these files off to the person you have lined up to translate your language.
They will need to install the DotNet Framework and the Framework SDK.
Even if you´re using VS.Net 2002 you´ll need the FX 1.1 and SDK 1.1.
In the bin folder of the SDK is a program called WinRes.exe.
Your translator friend will use this application to open the RESX files and save as the desired language.
Winres allows you to change the size of controls on forms as well.
So if your friend has saved as German you would have another RESX file like Form1.de.resx.
Next you need to use Resgen and on each of the new RESX files to create files like Form1.de.resources
Then use the AL.exe on the resource files to create resource DLLs.
Simple 
Oh, if your using VS 2002 you may have to do a global search and replace on the version number e.g. 1.500 to 1.3300 or what ever it is.
OK, now your problems are over?
Well unfortunately MSI files only come in one language.
So you can´t create ONE international distribution file with the Setup project, which may not be a problem for you to create one MSI for each language??
This approach doesn’t exactly go with what we all thin Internationalisation is all about, also download sites and PAD files are aimed at ONE file!
I thought it seemed like too much work anyway to have different files, after all the resource DLLs and CHMs will probably only come to another 200kb or so.
Well after much though I came up with a workable solution.
I have found a free installation package called QSetup.
Which caters for more than one language and some other neat features.
You will need to :-
- create generic names for your shortcuts
- have more than more language in your license agreement
- create one CHM file for each language
- have a selection screen when your program first starts to chose the language.
- then a means to route to access the chosen language files .e.g product.de.chm.
OK, you´ve done all that and you start having a look at the files you have!
“WOW, my files are massive.”
Well yes once you set Localized to True your assemblies increase in size.
Not sure why, I think it may be a bug.
Keep reading though….
So you compare the size of your MSI file with your new bundled QSetup file!
Wow, that´s big too.
Well remember, you should ship the InstMsi A & W files with your MSI.
You don´t need to with QSetup, so that kind of levels things out.
So you can have one international distribution file!
After spending time trying to come up with generic shortcut names I decided to use “Product Help / Produkt Hilfe”.
Which on reflect doesn´t exactly look good, also if I were to add more languages it would get a bit silly.
However at the time I couldn´t think of a better approach.
My new idea (which can be used with almost any type of setup and will cater for the removal of shortcuts on uninstall) is to have something like this.
Product (English)
Product (German)
Then when the program is run for the first time and the user chooses which language they want to use, I´m going to delete the shortcuts groups I don´t need!!
Ideaspad – An Award winning information manager for home and professional use
by JM
Post a Comment