This topic contains a mix of tips and tricks for using VBLM most effectively, and finishes up with a short list of additional sources of information about localization.

String Extraction Tips

There are probably many strings in your program -- filenames, SQL queries, etc -- that should not be translated. If VBLM extracts these strings, you can just leave them untranslated and you won't have a problem. As discussed in the string extraction overview, though, you'll make life much easier by configuring SX options to exclude as many of these strings as possible. You'll have to invest some time up front, but VBLM has features to help out.

Use the Special Tables to Get Started

When you create a language table named Test, Design, Enumerate or PigLatin, VBLM automatically "translates" every item in the table (ie every string that VBLM extracted). The Test table translates each item with the name of the item (thus the caption for Command1 will be translated as "Command1.Caption," etc). The Design table duplicates the originals (handy for translating between language variants, say English English and American English). Enumerate is filled with numbered strings, and PigLatin, well, take a guess The purpose of these tables is to give you immediate feedback about what got extracted that shouldn't be translated. The first thing you should do when you run VBLM on your project is create a special table, perform a build, and see what you've got.

Understand how the SX Options Work

SX option settings only have an effect during string extraction, which occurs when you select New Project or Update Project on the main file menu. SX option changes will not affect language table content until you re-extract strings.

Tune the SX Options from the LTE

If you select SX Options on the LTE options menu, you can configure them while viewing their results. You can scroll through the table, see unwanted strings, view their code context, and add the subs, functions, patterns, etc. that will get rid of them.

Update, Update, Update

VBLM's update capability was originally designed for version synchronization, but you'll probably use it as least as much to get the SX options right. Run through repeated cycles of updating, LTE viewing, and SX option tweaking until you've got the unwanted strings to a minimum.

Consult the Extraction Log

The interplay between your code, VBLM, and SX options can get complicated. If you get puzzled, turn on extraction logging and consult the log file to see what's happening.

Judgment Call: SX Options vs Marking as Excluded vs SXL Files vs Directive Comments

You always have a choice whether to exclude strings with systematic rules (the SX options) or by using one of the 3 arbitrary exclusion methods. It's obviously desirable to exclude as many as possible with as little effort as possible, and often putting a single token on one of the SX lists will get rid of many strings. Sometimes, though, it's going to be a toss-up.

Translation Tips

If you're translating across character sets...

Be sure to familiarize yourself with the issues, and with VBLM's features for making it easier. See translating across character sets and supplying missing fonts for details.

Configure export options appropriately

When creating an export file from the LTE, think through its purpose and configure the export options accordingly. For instance, if you're going to send it to a person you should use paired format so they can enter translations right below the originals, remove ampersands because hotkeys are nonsensical, and use quotes so they can match leading and trailing spaces. If, on the other hand, you're going to translate it with document-oriented software, you should definitely use sectioned format, and you should probably skip the quotes (though it depends on the software).

Don't try to use Unicode!

VB6 and earlier, and hence VBLM, do not support Unicode. To localize an app into an Asian language (or any language that relies on more than 255 characters) you have to use Microsoft's double byte character set (DBCS) fonts, not Unicode fonts. This didn't used to create many problems, but these days it does because W2K has extensive Unicode support that makes it easy to display Asian languages on Latin alphabet systems. I get lots of e-mail from customers trying to paste these into VBLM. This is guaranteed to not work; all you'll see is garbage, usually "???". The problem is compounded by the fact that W2K doesn't tell you which fonts are Unicode and which ones are not. The tip off is when you set the translation font in VBLM, paste in some Asian characters, and see "???" instead -- this means it's a Unicode font. So job #1 in localizing VB to Asian languages is to get yourself a DBCS font.

Make sure your translator uses a Windows text editor

DOS and Windows use different character sets, which is why text files with characters > 127 don't look the same. If you're sending someone a text file to translate, make sure that they enter the translations using a Windows text editor. If they don't, you're going to end up with the wrong characters

Use LMX files as dictionaries

If you're translating multiple apps that share strings, you can translate them once and use them in all projects by using LMX files as dictionaries. Enter the translations in one project, create an LMX file by exporting, then import that file into the projects and all matching strings will pop right in.

Build Tips

Use the Dimensioning Options to save your work

It's a near-certainty that you're going to have to fiddle around with form and control dimensions to get a translated version of your application to look as good as it does in the design language. VBLM won't do this for you, but it will preserve your work between builds. See dimensioning overview and dimensioning options for more info.

Use Text format for runtime language databases

VBLM's ANSI Text language database format has two advantages over binary. The first is performance, in that it loads nearly twice as quickly. The second, though not always an advantage, is that your end-users can edit it. Unless you don't want users to be able to edit it, stick with ANSI Text.

Let your users do the translation

Though not appropriate for many apps, a number of our customers have wanted to ship their users (often branch offices) a version of an app that the users could translate themselves. If you create an RSV including only the design language and specify ANSI Text database format, that's exactly what you'll have.

Rename the LDBs to have multiple RSV's in a directory

If you need to keep multiple runtime-switched executables (and hence multiple language database files) in the same directory, you can use the RSV build option to give them different names.

Other Sources of Information

As long as I've been selling VBLM, customers have been asking me general questions about localization. Frankly, I know a lot more about VB than I do about localization (though I know a lot more than I used to). Sometimes I have answers and sometimes I don't. If you have questions about localization issues, or products, or whatever, you might try any of the following.

When in Doubt... RTFM

The International Issues section of the VB6 Programmer's Guide contains a lot of useful information.

"Internalization with Visual Basic: The Authoritative Solution", Michael S. Kaplan, Sams (9/2000)

I haven't actually read this book (I just ordered it), but a customer passed this along: "I haven't finished this recent library acquisition and 'Authoritative' might be a bit overstating, but it is another resource. There is some mention of VBLM in the book although not enough IMHO. I'm still evaluating it."

microsoft.public.win32.programmer.international

This news group is dedicated to Windows internationalization. VC++ gets more attention to VB, but some very knowledgeable folks contribute (including the aforementioned Mr. Kaplan)

MSDN Library

An indispensable resource.

Multilingual Computing Magazine

A customer recently told us about this magazine (I'd give him credit if I could remember who he was), and it's a veritable gold mine of information about localization issues, products, and services. They're located in Sandpoint, Idaho (USA) and can be reached at Tel (208) 263-8178, Fax (208) 263-6310, CIS 71224,1003, or info@multilingual.com. As John Dvorak says, "highly recommended."