Bret,

sorry for this late answer due to my absence.

I have been dealing in i18n since I started working here in '94, and I can 
tell you the bad news: it is painful. In our pc-based products we support 
10 languages right now, including Japanese, and it was not easy to set it 
up correctly. You can find a lot of documentation on the internet and on 
paper, and almost all of it is bad. You can start from the M$ web site, 
just to have an idea how complex the task is.

There are many way to achive i18n.
The standard is using the resource file, that means you have to enter the 
strings for all the supported languages in the rc file, unless you make an 
exe for each language. Managing rc files is not an easy task, unless you 
use third party components to do the job the standard rc editor does not 
do. We started that way and abandoned it soon.
If you connect to a database, you can store the strings there. Can be slow 
if you go through the network.
We create one dll for each language, and we load the selected one at run 
time. It has the beauty that we have only one exe per application, we can 
add langauges on the fly and the application changes automatically when 
another langauge is selected from the control panel (very useful for field 
engineers who do not know Hungarian...) The gotcha is to maintein all 
these dll, and we wrote some applications to deal with it. Basically we 
send a txt file to a translator, get it back and create a new dll, merging 
the old data.

But this is only one part of the problem.

Selecting the right font is another tough point. All is well with English 
and Italian. You select Hungarian and Japanese and everything goes to 
hell. You must be careful that the fonts you selected are present in every 
language you support. Unfortunatelly, the default VB font does not do a 
good job. Windows2000 multi langauge is the correct environment to work 
with, in order to check the fonts for all langages.

Another problem is formatting numbers. Every country uses a different 
notation, so you must be very careful when you display/store/read numbers. 
Sometimes you can get very strange results. Be very careful: NEVER save a 
VB project after you change language: all the numbers stored in the VB 
files (like control position and size) will be stored using the locale 
notation, and when you load the project again in English everything get 
corrupted. The only way to fix it is to roll back or to edit the files in 
notepad. 

Last but not least: give *a lot* of room in the user interface to the 
labels (every label) to grow. German translations tend to take as much as 
twice more real estate than the corrensponding English. After you get a 
new translation, always load all your applications and check if some 
labels get truncated. Painful, I swear.

As a last advice, do not rush. It is a messy job, and if you do not do it 
right from the beginning, you pay a lot in the future (sort of like 
screwing a data base design). I18n needs a lot of time to deal with.

Whatever solution you chose, call me if you need help.

m.

> I need to covert an existing system to Support Multiple Languages, at 
least
> 4 for now. Any one have some words of advice or suggestion on design.
> 
> Thanks Bret
> 
>