I tried the demo on NT 4 sp 5 + IE4's new shell (Active Desktop).
First, system complained about a missing file. It was oleacc.dll, I located it on the Net and with it, it ran fine. I think it is a common plague for applications compiled with VC++7.
Second, as I failed to put the ini files in a Lang sub-directory, the program correctly complained about missing them, but made the switch anyway. It resulted in blank texts... A bit disturbing, you should have more robust error handling. Also you probably should load dynamically the list of languages from the content of this directory, instead of hard-coding it.
Third, when I switched to Japanese, I got strange characters (ƒtƒ@ƒCƒ‹(&F) •ҏW(&E) •\Ž�(&V) Œ�Œ� ƒwƒ‹ƒv(&H)) instead of Japanese chars. That's because I use Comic Sans as menu font. I have Japanese fonts installed, they were not used. I don't know if it is simple to handle.
Oh well, I suppose that this setting is mostly used on Japanese system, and so there is no problem here. Just wanted to mention the issue.
I enjoyed the article and assumed that when you said you would be working on a DLL tutorial that it would be for switching lang resources. It takes a long time to write an article well and I enjoyed this one. I guess some people can only take the time to be critics and not contributers.
Well, there're three main methods for supporting multilingual in Windows platforms:
Method 1, Independent release for each language (e.g. Microsoft Windows)
Method 2, Single executable file includes more than one language resources, or independent resource .dll file for each language (e.g. IsoBuster)
Method 3, Single executable file with external language packs (e.g. Tweak-XP, PatchWise Free)
Just like Netants, FlashGet, Tweak-XP, PatchWise Free, etc. More and more applications use external language packs (*.ini or *.lng) instead of DLLs for supporting multilingual. It's not necessary to recompile the whole project because the language packs can be added or modified dynamically. Absolutely, it's easy to translate and maintain the external language packs which are just like an INI-like text file. And, language can be shifted on the fly.
Have a quick look on my MSDN, Noticed that there is a good artical in April 1999 issue of MSJ. It also comes with sample source code. The artical is celled "Design a Single Unicode App that Runs on Both Windows 98 and Windows 2000"
The code is OK, if not fairly simple - but why do people
keep on writing such functions?
I mean there are 3 trillion packages on the market that
do the same job and most of all better!
1) What happens with right to left languages?
2) What happens (as someone said) when the text becomes too long?
And increasing the width of the caption will cause it
to go over the screen's edge?
3) Is an ini-file really a nice way of translating words?
i.e. how do I find all words which have not been translated.
How can I make sure that I have a kind of base lexicon
(so that i don't translate "Ja" with "Yes" in one part of
the code and with "Yeah" in another part.
4) I have to put in extra source code in all my programs
I would recommend using something like Multilizer (www.Multilizer.com)
Great idea, and really fast to get off the ground. However you will hit massive problems with some languages when they use 15 words when 3 will do. You dlg will look so horrible and nothing will fit properly. The way I have done it is to produce a separate resource DLL. Then your dlg layouts etc will always fit.