Localization in Visual Basic 6

Question

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

So, is there a way to easily localize the application, minimizing the impact on the application code, I mean that there should not be any major changes in the code itself, but adding some would be enough. I heard about the use of resource files in VB6, but it seems to have a problem with fonts specifically for Japanese characters, it throws out garbage characters specifically for shortcuts. Now, what is the best way to change the encoding of an application without applying too many changes to the application code.

This application has outdated code that I have to deal with.

Answer 1

I use resource files and replace (almost) every line in the code base and UI with an identifier. Whenever I show a line, I call one function that takes a line like {#1234} and loads the line ID 1234 (using LoadString() and returns it. For the user interface, I list each control on the form and pass the visible lines to one and the same function.

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

For fonts, see this example from the Visual Basic Programming Guide. I call this on each control as part of the Localise method.

Do not forget that different fonts and languages ​​occupy a different amount of vertical space for the same text. The layout of the form also needs to be adjusted to take this into account, or rescheduled dynamically (align the controls to the longest label, move down to get a longer full width text, etc.).

Answer 2

As for the part of the question “with minimal impact on the application code”, I would suggest encapsulating the functions associated with the resource in your own class, exposing the methods to string selection (by passing the culture specifier argument).

Then, the main part of the job is to convert your code from possibly hard-coded strings into method calls to extract the corresponding strings. Implementing a variant of this answer: Implementing String.Format () in VB6 can greatly simplify your life if you also encapsulate the concept of 'culture' and enter some cultureInfo argument for this signature StringFormat (maybe call it StringFormatLocal ).

The fact is that if the current application is not localized, it probably does not concern localization; localization of it means introducing a new problem, therefore, in order to influence the obsolete code as little as possible, you need to search and destroy “magic lines” and “magic formats” throughout the code base (and if your user interface has hardcoded capital letters, etc. etc.), replacing them with calls to your localization API, while preserving the localization problem.

I would like to get another answer here with more details on storing, loading and especially using string resources other than ANSI ...