Fog Creek Software
Discussion Board

Internationalization of our VB app

Now shame on me, I admit, for carrying Michael.S.Kaplan's Internationalization with Visual Basic for months and not taking the time to read it. I had other things I wanted to read more badly until today morning when I received an email from the one of the army in the adminisphere demanding an estimate for translation of one of our VB applications into three other languages.

I sat down with a keyboard, a notepad and my fingers. Thought for a file and came out with this:

(1) Seperation of string data from application commands
(2) Identification of text depicted pictorially in BMP/GIF/JPGs etc.
(3) Translation of string data and translation of text depicted pictorially
(4) Design of new pictures with inscribed translated text
(5) Creation of a resource file for storing the pictures as well as a string table
(6) Editing of code to adapt to the new string table, because the app was initially not written to refer to a string table. The coders at the begining of the project did not expect an internationalization and hence mixed everything up.
(7) Search for explicit formatdatetime calls and change them to suit the locale.

Is there anything else I need to consider?

Sathyaish Chakravarthy
Monday, November 17, 2003

Yes, number formats: check for use of CStr/Str/Val etc.
Numeric values that are not displayed to the end user, e.g. in the registry or files should be converted to/from strings using Str/Val.  Values that are displayed to the end user should be formatted using CStr.

Monday, November 17, 2003

Thanks for the input.
>Yes, number formats: check for use of CStr/Str/Val etc.
The reason I didn't mention these functions is that I thought that they were already locale-aware. So it goes for the Format function and all type conversion functions.

>Numeric values that are not displayed to the end user, e.g. in the registry or files should be converted to/from strings using Str/Val. Values that are displayed to the end user should be formatted using CStr.
That is already being done. I always use only REG_SZ for registry read/write so its not a problem with our app even if we're writing numeric values into the registry, we are always sending/receiving them as strings.
Any more ideas? I want to be sure I am not missing out anything.

Sathyaish Chakravarthy
Monday, November 17, 2003

Keyboard issues. Many languages have a Alt+Gr button for the right "Alt". And Ctrl is not always called Ctrl, so if you write "Ctrl+X" on your "Cut" menu item, better make sure it appears as Strg+X in German.

If you have buttons like B/I/U for bold/italic/underline on your toolbar, these need to be localized for many languages, and they don't use Ctrl+B/Ctrl+I/Ctrl+U in other languages, they use Ctrl+Shift+Letter.

Joel Spolsky
Monday, November 17, 2003

Thanks a zillion, Jewel :)!

If I tell you that I am scared, and I don't want to use accelerator keys for the very reason that I do not have a comprehensive list of keyboard keys for the locales I intend to design for. Would that leave me with something I might have missed out?

Sathyaish Chakravarthy
Monday, November 17, 2003

What should I do for compound messages that have already gone into the application?

For instance,

Dim SngNumMothers as Single
Dim SngNumMonths as Single

SngNumMothers = 9
SngNumMonths = 1

MsgBox CStr(SngNumMothers) & " mothers cannot make a baby in " & SngNumMonths & " month."

I can hear you say, "Dont do it then!", but I need advise.

Sathyaish Chakravarthy
Monday, November 17, 2003

Avoid sentence construction, instead...

Store all possible combinations of the sentence syntax with place holders for substitutions. e.g. Store a plural form of the sentence and a singular version of the sentence.

Clearly you need to limit the possible combinations or face the ^n consequences.

Sentence construction is all to pot in different languages and just sticking an 'S' on the end of the noun doesn't cut it.

Tim H
Monday, November 17, 2003

I think Val is unaware of locale but Cdbl etc are. However if the string being converted has garbage then:
Val("1234xyz") produces 1234
CInt("1234xyz") produces type mismatch error
Val ("9.5%Y23.0%") also produces a type mismatch error.

Peter Ibbotson
Monday, November 17, 2003

Watch out when you are converting number formats to string formats.

These examples are with the regional settings set to French, where a comma is used to denote decimals and period is used to mark out the thousands.

Ie. in france a half is 0,5 and a million and a half is 1.000.000,50.

? val("999.99")
? val("999,99")
? str("999,99")
? ccur("999,99")
? ccur("999.99")
(Causes Type Mismatch)

Ged Byrne
Monday, November 17, 2003

There's potentially a lot more things you need to worry about, though in part it will depend on the languages/locations you're localizing to (will the list get longer in the future?) and the type of application you've talking about.

Among other differences:

Sorting (collation) order may differ, perhaps dramatically, from that in English.

Dialog box and report-type layouts may need to change because of differening word lengths -- German text, for example, often averages about ~30% longer than the equivalent English text.

Your characters may not be single bytes. Text may not read left-to-right.

In addition to time, date, number, and currency format changes, things like phone numbers, postal codes, and state/province names will often have different formats than your code might be used to.

Traditional paper sizes and units of measure may differ.

Is somebody going to localize/translate your documentation? Your help files? Your Web site and order form?

Are there other cultural assumptions in your application that are not valid for the target market? For example, not everywhere in the world considers a weekend to be Saturday plus Sunday.

John C.
Monday, November 17, 2003


Make sure all date entry is using suitable controls (not textboxes or masked edit boxes).

You may find:



Monday, November 17, 2003

*  Recent Topics

*  Fog Creek Home