Fog Creek Software
Discussion Board

Need EASY way to make VB6 Project multilingual

I have a large VB6 Project that builds a commercial application that is being deployed in many foreign countries (USA, Germany, France, Spain, Israel, etc, etc)

The code base is heavily sprinkled with hard-coded "English ANSI strings everywhere".  It also gets about 20% of its strings from one or more API sub-system DLLs that is written in MS-Visual C/C++.

I will need to re-factor the entire VB6 code-base and existing DLL’s to support many other languages, locales, and character sets.

Any expert advice out there on how to approach this “simple” yet large-scale problem?
Any recommended 3rd party COTS component solutions for internationalizing VB6 Projects.
Any recommended books on the subject?

Heston Holtmann
Thursday, July 10, 2003

I have only general advice: first, this is an excellent opportunity to centralise your strings (20% from here, others from there etc is an update nightmare as you are feeling now).  Second, the number of installers etc who list the languages for install as "English, Swedish, Spanish ..." instead of "English, Svenska, ..." is astonishing!  Don't do it!

constructive comment
Thursday, July 10, 2003

I'm not clear on what you advise me NOT to do?

A. Don't use a particular installer product that forces you to use "English, Swedish, French, etc, ..." at user-install time


B. Don't design my installation using the english names for other languages?

We already licence and use InstallShield Developer v8.0 (sp2).. so what ever I end up doing with the setup, it MUST be done with ISDev8.0 or later, too late to change installers!

Heston Holtmann
Thursday, July 10, 2003

I think the point he was making is that, if you speak Swedish and not English, you'll be looking for the word "Svenska" instead of "Swedish," while a French speaking person is looking for "Francais" rather than "French," and so on.

Thursday, July 10, 2003

i was testing some (one or two) commercial products for this (multilingual VB6 programs), but, don't remember why, these programs was not selected.
instead, we start our proper program for help us in the translation, with a lot of work.

all the strings into vb (strings in controls, not code) is auto searched in an "repository" for not having duplicates strings and so on.

unfortunatelly this was parked due other most urgent things.

maybe tomorrow i will loogk in the documentatio to relate you the name of the commercial programs.

Thursday, July 10, 2003

There's one utility floating around the net that will look at any hardcoded string and move it to a res file. It will replace the string with loadres code. I'll post the url if I find it.

In the meantime, I found:

Some utilities that I've found are:

Localization Guru

VB Language Manager Pro

Never used them, since I haven't had to do localization myself. There has always been somebody else handling this in the teams I've worked with.

Thursday, July 10, 2003

Don't forget about converting strings to dates and numbers and vice versa. In VB the locale of your code base is US, however the locale of your user may be different.
So , may be used instead of . in a number and the order of dates is different. If you're using SQL then you may very well have this problem with dates.

So debug.print #1/31/2003# produces 31/01/2003 on my UK machine using the immediate window. Use the day, month and year functions on dates along with dateadd and dateserial to put them back together.

debug.Print Month("1/4/2003") prints 4
debug.Print Month(#1/4/2003#) prints 1
debug.Print CDate("1/31/2003") prints 31/1/2003

This result may surprise some US programmers (And I've caught the folks here doing it too) particularly the last one since VB is trying to get it right and reckons I must have entered a us date by mistake.

You shouldn't need to reboot to swap user locales, the machine may prompt you to do so, but it's only because most software caches the settings. (I haven't checked this in a while so I may be wrong)

Peter Ibbotson
Thursday, July 10, 2003

I bought a Wrox(?) book on the subject which was quite good. Can't remember the title though. That's not very helpful is it?

2nd the comments about strings. I have written VB plugins that do these things - I might polish these an make them available as shareware or something if you're interested.

To handle hardcoded strings, create a library routine, e.g.
    strTranslate(byref strSource as string) as string
and pass it the string you want to translate. For the time being, have the routine just return what is passed in. Enforce religiously its usage for EVERY string in the App. e.g.
strMessage = strTranslate("Some " & lngCount & " Message")

You are doing this to make subsequent conversion an easier task. This conversion will also need to handle form
captions etc.

Make sure all icons etc are loaded dynamically. Ditto menus.
The MSDN site has loads of advice about UI design.
Make sure all translation is done professionally.

Thursday, July 10, 2003

When we had to undertake a similar project for our VB app we used VBLM for it:

It was very highly thought of by the developers who used it and the support process was very efficient.  Definitely worth a look.

David Groombridge
Thursday, July 10, 2003

Michael Kaplan wrote a book titled, "Internationalization with Visual Basic" that you might be be interested in:

Below, is a link to his web site where you can read sample chapters and the table of contents:

One Programmer's Opinion
Thursday, July 10, 2003

Here's a technique I once used.

First of all, like others have already suggested, make sure your text is centralised, and don't forget to localise dates and times.

- Assign a unique Id to every piece of text.
- Now create a module, or an object, or a procedure, whatever you like best, that can manage all text. I will use an object from here on.
- Give your TextManager object a method to set the current language.
- Give your TextManager object a method to retrieve a text using an id to identify it. Your Textmanager object should use the current language setting plus the id to determine the correct piece of text.

Basically, this is all. You can code the text ids as constants in your code, but you can also take advantage of the tag attribute of controls. You can draw a label (or something else) on a form, set the tag to the value of the id that identifies the right text. Whenever you load the form (or when the language is changed), you query the controls on your form, get their tag value, query the TextManager, and you're done.

If you're interested, I have some code lying around somewhere that uses this technique. You can contact me via mail.
The TextManager object in this particular piece of code works by retrieving the text from dll's that each hold a single language.
The text's are encapsulated as resources in the dll. The TextManager object simply uses the dll that goes with the currently selected language. Every dll has the same structure and interface, only different text contents.

Practical Geezer
Friday, July 11, 2003

Thanks for everyone's contributions so far...

I ordered Kaplan's "i18N with VB" book and the latest offering from MS-PRESS:

Title: Internationalization with Visual Basic

Title: Developing Internation Software with CDROM

I started reading Kaplan last night... WOW... very well written, so far it looks like it will answer all of my questions.

Only problem is that it looks like I will have an IMMENSE amount of work ahead of me for i18N and Localization.

My boss has this idea in his head that i18N will be "VERY EASY" since its just a bunch of string replacements.. NOT!

Heston Holtmann
Tuesday, July 15, 2003

*  Recent Topics

*  Fog Creek Home