4

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.

Peter O.
  • 32,158
  • 14
  • 82
  • 96
lemoncodes
  • 2,371
  • 11
  • 40
  • 66
  • 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? – bonCodigo Jan 14 '13 at 10:51
  • 1
    Do you mean vb6, or VBA? They're not the same environment... – Tim Williams Jan 14 '13 at 16:07
  • ops sorry its supposed to be vb6 not vba my bad. – lemoncodes Jan 22 '13 at 03:07
  • Have uou tried using unicode strings. The VB6 runtime has support for unicode characters. Note: the VB6 IDE does not support unicode. – user1947746 Jan 23 '13 at 11:18
  • Why not use the Resources file ie. the resx mechanism? – allen Jan 27 '13 at 05:41
  • 1
    Have you looked at this [SO question](http://stackoverflow.com/questions/830367/internationalization-of-a-vb-6-application) The answer references Michael Kaplan's book which is one of the better references in a convulated subject – Mark Hall Jan 27 '13 at 06:23

2 Answers2

2

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.

Don't forget that different fonts and languages take differing amounts of vertical space for the same text. The form layout also needs to be adjusted to take this into account, or reflow dynamically (align controls to longest label, shift down to allow for longer full width text, etc.)

Deanna
  • 23,876
  • 7
  • 71
  • 156
  • @Deanna - Did you automate the process of replacing the strings in the codebase? if so, how? – pingu Mar 30 '16 at 13:08
  • 1
    @pingu No, sorry. It was a very manual process, and included adding code to adjust the layout of each dialog to take into account other language rules. Don't forget that the same text in different languages could be very different physical length. – Deanna Mar 30 '16 at 14:05
1

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...

Community
  • 1
  • 1
Mathieu Guindon
  • 69,817
  • 8
  • 107
  • 235