While Visual Basic for Applications has no implicit support for internationalization, the task can be accomplished through the use of a Visual Basic satellite DLL, from MSDN article Q188659. While this approach works, it requires the use of separate DLLs for each supported language. I also don’t like this approach because it requires the programmer to manually align the constants for their string tables. More importantly, since VB already supports multiple languages in a single resource, this seems like an unnecessary complication.

One variation is an approach that uses multiple string tables within a single resource file using an ActiveX DLL. The LoadResString function is then utilized to automatically load the locale identifier (LCID) from the operating system:

Public Enum StringIDs
    resCaption = 101
    resCmdYes = 102
End Enum

Caption = LoadResString(resCaption)

The disadvantage of this technique, of course, is that it does not allow the user to select the program language explicitly. This may or may not be the desired behavior, depending on the application.

Other techniques for adding internationalization support include using the registry, a flat text-file, a SQL database, or XML. I find all of these techniques to be kludgy with respect to the Microsoft provided resource files. For information on these techniques, see the VB Helper tutorial on Internationalization.