Localization in Visual Basic 6

Tag: unicode , localization , vb6 Author: yuchao0729 Date: 2012-12-29

Is there a best way to localize the language settings? Say the situation is that you have already a working application in, say, French, and wanted to completely localize it in English.

So is there any way to easily localize the application while minimizing the impact on the application's code, I mean there mustn't be any major changes to the code itself but adding some would suffice. I've heard of using resource files in VB6 but it seems to have an issue with its fonts specially in Japanese characters, it throws out a garbage chars specially on labels. Now, what's the best way to change the charset of a application without applying too much changes in the applications code.

This application has a legacy code to I have to deal with it.

It's possible. When you are working with third party applications that supports multiple languages then you want to make sure the Excel works based on each person's language setting and not blowing it up. Can you please clarify a bit more. Do you want to change Excel sheets and forms or Do you want to change VB6 forms?
Do you mean vb6, or VBA? They're not the same environment...
ops sorry its supposed to be vb6 not vba my bad.
Have uou tried using unicode strings. The VB6 runtime has support for unicode characters. Note: the VB6 IDE does not support unicode.
Have you looked at this SO question The answer references Michael Kaplan's book which is one of the better references in a convulated subject

Other Answer1

Regarding the "while minimizing the impact on the application's code" part of the question, I would suggest encapsulating the resource-lookup-related features into a class of its own, exposing methods to fetch a string (by passing a culture specifier argument).

Then the bulk of the work is to convert your code from perhaps hard-coded strings to method calls to retrieve the appropriate strings. Implementing a variant of this answer: Implementing String.Format() in VB6, could greatly simplify your life if you also encapsulate the notion of 'culture' and introduce some cultureInfo argument to this StringFormat method's signature (perhaps call it StringFormatLocal).

The point being, if the current app isn't localized, it's probably not concerned about localization; localizing it means introducing a new concern so in order to affect legacy code as little as possible, you'll need to seek & destroy "magic strings" and "magic formats" all over the code base (and if your UI has hard-coded design-time captions and images, remove those as well), replacing them with calls to your localization API - keeping the localization concern separated.

I'd like to see another answer here with more details about storing, loading and especially using non-ANSI string resources...

Other Answer2

I use resource files, and replaced (almost) every string in the codebase and UI with an ID. Whenever I display a string, I then call a single function that takes a string like {#1234} and loads string ID 1234 (using LoadString() and returns it. For the UI, I enumerate every control on the form and pass the visible strings to the same function.

This meant a single call to Localise Me in the Load event of each form and a TranslateString("{#1234}", "name", Name) whenever I set/display something dynamically.

For the fonts, see this example from the Visual Basic Programmer's Guide. I call this on every control as part of the Localise method.


+50 That's how it's done!