When you create or update a VBLM project, VBLM reads the files in your VB project and extracts strings for translation. As it does so, VBLM examines each line of code in which strings appear and uses its string extraction (SX) rules and options to determine which strings should be extracted and which strings should not. The SX options control the process, and their purpose is to prevent the extraction of strings used internally by the project that shouldn't be translated. A typical VB project has many of these, such as file names, Tag properties, SQL queries, and the like.

Technically, the SX options are a convenience rather than a necessity, because when VBLM does a build it ignores extracted strings that haven't been translated. Thus when VBLM extracts strings that shouldn't be translated, you can just leave them untranslated and you won't have any problem other than a cluttered language table.

As early VBLM users told me emphatically, however, the SX options are a practical necessity because most developers sub out translation to people with no way of knowing which strings on the table shouldn't be translated. Developers could go through the language table and mark it up, but this was tedious. If they didn't, though, they might end up both paying for and deleting unwanted translations. The bottom line is that you really want VBLM configured to extract only strings that should be translated. When this is the case, there is a whole class of things that you don't have to worry about, and vice-versa

It would be nice to have a single SX option called Only Extract Strings That SHOULD Be Translated, but the rules are so complex and ambiguous, and VB projects so varied, that this eluded me (any suggestions?). Instead, VBLM offers the following features to help you achieve the same goal:

image\ebd_19.gif An large set of SX options you can configure to exclude strings systematically. The SX options, for example, include a list of properties for which any assigned string will not be extracted; lists of sub and functions for which any string arguments will not be extracted; a list of variables for which any assigned string will not be extracted; etc. These lists are preset with default values but can all be modified for your specific projects. For details, see String Extraction Options.

image\ebd_20.gif Non-list based options that control extraction of numeric and punctuation-only strings, menu hotkeys, and the like. See Miscellaneous SX Options.

image\ebd_21.gif Three ways to help you "tune" the SX options to maximize the systematic exclusion of unwanted strings:

 > Access to the SX options window from within the language table editor, so you can reconfigure the options while viewing their results (select String Extraction on the LTE options menu). And new as of V6, after tweaking the rules you can now re-extract strings from within the LTE and see resulting changes immediately in the displayed language table.

 > A display of detailed results from the last string extraction. See String Extraction Results

 > An extraction log and an update log that show you precisely how the options are being applied and to what effect.

image\ebd_22.gif For strings that defy systematic exclusion, four easy ways to exclude them arbitrarily (ie, I don't want this one or that one);

 > You can insert comments in your source code that instruct VBLM to ignore parts of it, from single strings within a line to single lines to complete sections and procedures: see VBLM Comment Directives. What's more, VBLM can add the comments for you: see Excluding highlighted code in the code window.

 > You can permanently exclude strings by selecting them once for addition to a file-based list. See string exclusion list files for more information about this excellent new method for permanently excluding strings.

 > You can instruct VBLM to exclude all strings in one or more project files. See Excluding Files for details.

 > Finally, you can always mark strings as excluded. even though they have been extracted (although strings so marked have in fact been extracted, VBLM essentially ignores them.

I encourage you strongly to use some or all of these features to help whittle down the extracted strings to only those that should be translated. Did I already say that?