Question: Can VBLM handle Asian and other languages that have more than 255 characters and hence need multi-byte character sets?

Answer: Yes, with a caveat. VBLM can handle ANY character set -- single, double, or mixed byte -- supported by VB and by the version of Windows you are running. VBLM even offers limited Unicode support, though Win9x and most VB controls don't -- see VB, VBLM & Unicode for more information.

That said, there are some things you should know and/or do when using VBLM to translate across character sets.

Learn the VB Basics

The VB6 docs have a reasonably good review of the issues involved. See International Issues in the Programmer's Guide, and pay special attention to the topic Issues Specific to the Double Byte Character Set.

Remove FontName from the Excluded Properties List

VBLM's basic mechanism for crossing character sets is conversion of the app's original fonts into fonts that use the new character set. If you're translating an English app to Japanese, for example, you want VBLM to convert all those MS Sans Serif fonts to MS Mincho (or something comparable). Since the fonts in VB projects are stored as FontName properties, VBLM's method for converting them is to simply treat them like any other property string in the project: it extracts them and includes them in the language table for you to translate.

Since most VBLM users are not crossing character sets, however, the FontName property is on VBLM's default list of excluded properties (see String Extraction Options). Until you remove FontName from this list, VBLM does not extract FontNames, they won't appear in the language table editor (LTE), and you can't translate them.

If you're translating across character sets, then, the first thing you need to do is select String Extraction on the main options menu and remove FontName from the Don't Extract...Properties list.

Translate the FontNames First

Once you have removed FontName from the excluded properties list, extracted strings and fired up the LTE, the next thing you should do is translate the fontnames (the reason why will be clear in a minute). Continuing our English => Japanese example, search through the table for MS Sans Serif and type in "MS Mincho" as the translation. Now when VBLM does a build, it will replace all instances of MS Sans Serif with MS Mincho.

Set the LTE's Translation Font

Having translated the fontnames, you're now ready to enter translations in the new language and character set. In order to do so, you obviously need to have the new font -- MS Mincho or whatever -- installed and usable on your system. If you don't, you can still test the concepts by using WingDings or some other appropriately cryptic font.

To enable translation across character sets, the LTE maintains a separate font for translation input and display (the "translation font") for EACH language table; this font is independent of the fonts used both to display original strings and other info (the "main font"), and the fonts used to display translations in other language tables. You need to set the translation font to MS Mincho or whatever, which you do in the language table properties window either when the table is first created, or by right clicking the table name on the main window and selecting Properties on the popup menu. Now you're ready to translate.

And now you might notice why you translated fontnames BEFORE changing character sets: the translations are now displayed as gibberish. This is not a problem (the codes are still correct), it's just what MS Mincho (Chr$ 77 83 32 ...) looks like in MS Mincho

Understand & Deal with Default (Missing) Fonts

OK, you've done everything necessary to translate your app into Japanese: you removed FontName from the excluded properties list, translated MS Sans Serif as MS Mincho, set the translation font, and entered the translations. You do a build, fire up your Japanese version and ... WHAT A MESS! You realize that menus and dialogs use the system font, which will correct itself automatically on the proper system; but why are so many controls, maybe even all controls, displaying MS San Serif gibberish? Before you get agitated and demand your money back, let me explain a) the problem, b) how to fix it yourself, tediously, and c) how VBLM can fix it for you instantly.

When you create a control container or control in VB, the initial FontName is MS Sans Serif, FontSize 8.25, and all other font properties False (except VB3, where FontBold=True). If you save the control container as text and view it with a text editor, though, you won't find these properties recorded in the file because they are VB's default font properties. If you don't change them, or if you change them and change them back, VB does not include any font info in the control container file. When VB loads a control container, it assigns these properties to any control that a) has font properties, but b) has no values for them recorded in the file. 10 points if you see the problem.

The problem is that VBLM works by translating the FontName properties that it finds in the form files. It can't translate them if they don't exist, and thus any form or control in the original project that has no font information isn't going to have any in the localized version either. When loaded, VB assigns MS Sans Serif, and you see gibberish because you're viewing MS Mincho character codes (the reverse of the earlier problem in the LTE)

There are 2 ways to fix this yourself. You can load the localized version and set all the fonts to MS Mincho, but a) what a pain, and b) you'll have to do this after every build. Alternately, you can load the original project, change the FontName to Arial for every form and control that uses the defaults, then update your VBLM project, and translate Arial. This solution won't affect appearance much and you only need to do it once, but a) it's still a pain, and b) it will increase the compiled size of the original project because it now contains font info previously supplied by VBRUNXXX.DLL.

A much better solution, available to VBLM users, is to let its Supply Missing Font options fix the problem for you. To do so, you'd enter MS Mincho (or whatever) as the FontName to Supply on the Supplied Font Options window, and check Supply Missing FontNames on the Build Options window. When you build, VBLM provides controls that use default font properties in the original project with the specified FontName in the localized version. This feature will save you many hours of tedium and eliminates the need to change fonts in your original project. For details, see Supply Missing Font Options.

Change the Style Property to Graphical

Command button, option button, and checkbox controls have a Style property that is set to Standard by default. However, you will often find that these controls do a much better job displaying double byte characters when the Style property is changed to Graphical.