What are the best practices for building multi-lingual applications on win32?

Question

I have to build a GUI application on Windows Mobile, and would like it to be able user to choose the language she wants, or application to choose the language automatically. I consider using multiple dlls containing just required resources.

1) What is the preferred (default?) way to get the application choose the proper resource language automatically, without user intervention? Any samples?

2) What are my options to allow user / application control what language should it display?

3) If possible, how do I create a dll that would contain multiple language resources and then dynamically choose the language?

Answer 1

For #1, you can use the GetSystemDefaultLangID function to get the language identifier for the machine.

For #2, you could list languages you support and when the user selects one, write the selection into a text file or registry (is there a registry on Windows Mobile?). On startup, use the function in #1 only if there is no selection in the file or registry.

For #3, the way we do it is to have one resource DLL per language, each of which contains the same resource IDs. Once you figure out the language, load the DLL for that language and the rest just works.

Answer 2

Re 1: The previous GetSystemDefuaultLangID suggestion is a good one.

Re 2: You can ask as a first step in your installation. Or you can package different installers for each language.

Re 3: In theory the DLL method mentioned above sounds great, however in practice it didn't work very well at all for me personally.

A better method is to surround all of the strings in your program with either: Localize or NoLocalize.

MessageBox(Localize("Hello"), Localize("Title"), MB_OK);
RegOpenKey(NoLocalize("\\SOFTWARE\\RegKey"), ...);

Localize is just a function that converts your english text to a the selected language. NoLocalize does nothing.

You want to surround your strings with these values though because you can build a couple of useful scripts in your scripting language of choice.

1) A script that searches for all the Localize(" prefixes and outputs a .ini file with english=otherlangauge name value pairs. If the output .ini file already contains a mapping you don't add it again. You never re-create the ini file completely, your script just adds the missing ones each time you run your script.

2) A script that searches all the strings and makes sure they are surrounded by either Localize(" or NoLocalize(". If not it tells you which strings you still need to localize.

The reason #2 is important is because you need to make sure all of your strings are actually consciously marked as needing localization or not. Otherwise it is absolutely impossible to make sure you have proper localization.

The reason for #1 instead of loading from a DLL is because it takes no work to maintain this solution and you can add new strings that need to be translated on the fly.

You ship the ini files that are output with your program. You also give these ini files to your translators so they can convert the english=otherlanguage pairs. When they send it back to you, you simply replace your checked in .ini file with the one given by your translator. Running your script as mentioned in #1 will re-add any missing translations if any were done while the translator was translating.