Visual Basic - Foreign language issues

Author

Foreign language issues

Henk Borsje

2004-09-28, 3:55 pm

Dear reader,

My VB6 application requires that all strings in the user interface be
translated into a foreign language. I have set up a large table with
translated strings that I read at program initialization. Creating the
translations was the largest part of the effort. I am still hoping that
there is a way to programmatically get hold of some of the most commonly
used interface words that are part of the OS software. 'File',
'Cancel','Tools', etc. are some examples.

When a PC has a non-English default language, is there a way for a VB
application to obtain the translated text for these standard terms in the
language specific for this PC?

Thanks for your help.

Henk Borsje

Ralph

2004-09-28, 3:55 pm

"Henk Borsje" <hjborsje@verizon.net> wrote in message
news:pdi6d.1792$Xd2.1347@trndny01...
> Dear reader,
>
> My VB6 application requires that all strings in the user interface be
> translated into a foreign language. I have set up a large table with
> translated strings that I read at program initialization. Creating the
> translations was the largest part of the effort. I am still hoping that
> there is a way to programmatically get hold of some of the most commonly
> used interface words that are part of the OS software. 'File',
> 'Cancel','Tools', etc. are some examples.
>
> When a PC has a non-English default language, is there a way for a VB
> application to obtain the translated text for these standard terms in the
> language specific for this PC?
>
> Thanks for your help.
>
> Henk Borsje
>

Yes you can use "StringTables" in resource files to do what you are
attempting.

http://support.microsoft.com/defaul...kb;en-us;232625

You might also want to check out M$ Internationalization or Globalizing
sites. Most of the current articles are based on .NET but still contain some
good information. With a little extra searching you can uncover the older VB
Classic articles in the archives.

However, if I might make a suggestion. You might not want to confine your
localization to just strings, especially when working with Dialogs and
Forms. I once tried that several years ago when one of my clients was first
venturing forth on the International scene. We attempted to create
'universal' dialogs/forms and just swap out 'strings' as needed. It was a
disaster.

First problem was the relative length of 'commands' in different languages -
English is almost always shorter. Comparable phrases in one language was
never the same size in others. So dialogs/forms came out with tons of wasted
space around some controls and appeared cramped in others. This lead to a
painful exercise in redrawing everything. Also, seemingly harmless
'translations' of simple commands like you noted before - came out silly,
rude, and even insulting in other languages if one was not careful. (Icons
with the wrong hand gesture and even the wrong color of hat suffered the
same results - but that is another story).

Using VB we found it was simpler to actually teach translators how to
'design' forms using Visual Studio and then swapped out entire forms based
on locale. This worked by a serious effort to separate presentation from
code by using a "class-behind" every dialog/form.

hth
-ralph

Henk Borsje

2004-09-28, 8:55 pm

Thanks for your answer. I am aware of resource files, etc., but I thought I
might save myself the effort of translating a lot of strings that already
have been translated as part of the UI. Why would I try to find out what
the Polish translation of 'Close' is, if it is already somewhere in some
dll.

I was hoping there exists some API call that returns me the string,
something like

PolishClose = TranslateString ( LANG_POLISH , STRING_CLOSE)

or, if the UI language is defined as Polish:

MyClose = GetUIText (STRING_CLOSE)

** Obviously, names of functions and enumerations above are completely
fictitious **

I have not been able to find this simple form of translation in the
Microsoft documentation. Did I miss something?

Henk Borsje

"Ralph" <msnews.20.nt_consulting32@spamgourmet.com> wrote in message
news:%23shxcMZpEHA.3364@TK2MSFTNGP10.phx.gbl...
>
> "Henk Borsje" <hjborsje@verizon.net> wrote in message
> news:pdi6d.1792$Xd2.1347@trndny01...
that[color=darkred]
the[color=darkred]
>
> Yes you can use "StringTables" in resource files to do what you are
> attempting.
>
> http://support.microsoft.com/defaul...kb;en-us;232625
>
> You might also want to check out M$ Internationalization or Globalizing
> sites. Most of the current articles are based on .NET but still contain
some
> good information. With a little extra searching you can uncover the older
VB
> Classic articles in the archives.
>
> However, if I might make a suggestion. You might not want to confine your
> localization to just strings, especially when working with Dialogs and
> Forms. I once tried that several years ago when one of my clients was
first
> venturing forth on the International scene. We attempted to create
> 'universal' dialogs/forms and just swap out 'strings' as needed. It was a
> disaster.
>
> First problem was the relative length of 'commands' in different
languages -
> English is almost always shorter. Comparable phrases in one language was
> never the same size in others. So dialogs/forms came out with tons of
wasted
> space around some controls and appeared cramped in others. This lead to a
> painful exercise in redrawing everything. Also, seemingly harmless
> 'translations' of simple commands like you noted before - came out silly,
> rude, and even insulting in other languages if one was not careful. (Icons
> with the wrong hand gesture and even the wrong color of hat suffered the
> same results - but that is another story).
>
> Using VB we found it was simpler to actually teach translators how to
> 'design' forms using Visual Studio and then swapped out entire forms based
> on locale. This worked by a serious effort to separate presentation from
> code by using a "class-behind" every dialog/form.
>
> hth
> -ralph
>
>

Ralph

2004-09-29, 3:55 pm

"Henk Borsje" <hjborsje@verizon.net> wrote in message
news:F8m6d.5287$r%4.2177@trndny05...
> Thanks for your answer. I am aware of resource files, etc., but I thought
I
> might save myself the effort of translating a lot of strings that already
> have been translated as part of the UI. Why would I try to find out
what
> the Polish translation of 'Close' is, if it is already somewhere in some
> dll.
>
> I was hoping there exists some API call that returns me the string,
> something like
>
> PolishClose = TranslateString ( LANG_POLISH , STRING_CLOSE)
>
> or, if the UI language is defined as Polish:
>
> MyClose = GetUIText (STRING_CLOSE)
>
> ** Obviously, names of functions and enumerations above are completely
> fictitious **
>
> I have not been able to find this simple form of translation in the
> Microsoft documentation. Did I miss something?
>
> Henk Borsje
>

Sorry I misunderstood what you were really looking for.

If you fish around the web we will find the occasional list. Open source
code is often a real treasure trove of multiple languages whether in Windows
code or Unix.

The problem is up until a few years ago there was no "standard" translation
even for, what you noted appear to be common elements. For all the reasons I
mentioned before, each locale has come up with it own 'idioms'. A spanish
word for 'click' in one locale is often a very rude command in another. M$
International editions are a good place to start - but even there you will
discover that subtle 'exceptions' abound.

It is unfortunately very difficult for the monolingual to create localized
software - you often need the assistence of someone who is bilingual or
multilingual to help out, or obtain examples of programs in the other
language, if you are to create anything that doesn't resembles a ransom
note. <g>

hth
-ralph

Sponsored Links