Re: add support for other languages

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I have a tiny program that installs add-on modules for use by our main
application. The installer basically goes about it's business silently, but
I have a Windows MessageBox pop-up to report errors (only if encountered). I
would like to have those error messages in several different languages.
Currently, the installer reads the messages from a simple ASCII text file,
and so the language scope is very limited, however the advantage is that the
translator can simply swap my file for his and the installer uses his
messages without me even having to see anything.

MessageBox uses single-byte LPCSTR, so that is the first interesting problem
to overcome. However, what is more interesting is the file that contains the
strings in the first place. I can send an English-language plain text file
to the translators - but what kind of file can they store their language
versions of the strings in, and how does one parse this file - for example,
it is "easy" to use MS Word to create sentences in Chinese Simplified, but
that file would of course contain more data than just the text. Has anybody
tackled these issues?

regards

IdeasVacuum


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:gsoub15hd819mjru1tja3bds1bate38dks@xxxxxxxxxx
> There are a lot of issues dealing with internationalization. They include
> simple text
> (menus, captions, etc.), presentation to the user of text (e.g., a
> dynamically-loaded
> ComboBox needs to use language-specific strings, and you cannot make
> assumptions about the
> ordering if it is sorted by string name. The number of people who use the
> design time
> "combo box data" option, one of the most completely useless options ever
> added to a
> development environment, is frightening. It rarely, if ever, is useful.
> Then you've got
> details about how to represent dates, numbers, times, etc. Some of these
> decisions are
> context-sensitive, e.g., some countries use 12-hour time for "civilian"
> uses but
> applications designed to run in contexts such as transport scheduling are
> required to use
> 24-hour times. Right-to-left and left-to-right displays make life more
> interesting (Hebrew
> and Arabic are currently giving me grief, particularly because I cannot
> read either
> alphabet).
>
> You have to deal with the fact that the controls may need to be resized to
> handle the
> alternate language strings (apparently Finnish is the worst language,
> because the strings
> can have up to 3x the number of characters of English strings).
>
> You have to deal with locale-specific sort order (German has two, for
> example, default and
> telephone book, and no, I don't know the difference).
>
> If you don't mind playing with pre-alpha code, send me some email and I'll
> send you a
> snapshot of the program I'm working on to help people who deal with these
> issues, my
> "Locale Explorer". I'm still adding features to it, so not all features
> are fully
> implemented, and may not give any output.
>
> First step is to remove every single native-language string (except
> possibly your own
> personal debug output messages that will not appear in the delivered
> product) from the
> source code. Second step, which is easy to do at the same time, is to make
> everything
> Unicode-aware. For example, 99.999% of the uses of 'char' are erroneous
> for a program that
> is Unicode-aware. So you must be incredibly suspicious of every appearance
> of 'char',
> LPSTR, LPCSTR, and other 8-bit assumptions. You cannot assume characters
> are single bytes.
> Every literal must be surrounded by _T() and the exceptions to this are so
> vanishlingly
> small that you can, as a first approximation, assume that any such usage
> is erroneous.
>
> Now, if you have external data, such as a file, a communication line,
> etc., then you have
> to worry about converting locale-specific characters to and from the
> communication
> representation. Some communication links talk to programs that can only
> support 7-bit
> characters, so worrying about how you deal with this when there are
> accented characters
> can pose interesting problems (sure, UTF7 solves the representation
> problem, but only if
> the OTHER side understands UTF7 also!)
>
> I don't even want to get into UniScribe. I'm working out ways of avoiding
> its use entirely
> (this is not easy, but relevant for several classes of languages,
> including mixed RTL and
> LTR text).
>
> So it depends on what you are trying to deal with as to how hard your
> problem will be.
> Right now, I can handle a variety of scripts, although I am not certain I
> have a clue as
> to whether or not the output is actually completely valid (Chinese numbers
> are a problem
> I've shelved for a while, because there is a symbol very similar in
> appearance to a + that
> represents "10", and I just haven't had time to figure out what to do here
> (once I put
> this out with complete source, I will be happy to accept corrections, but
> it is Not Yet
> Ready For Primte Time until I go as far as I can on my own).
>
> Overall, internationalization raises some fascinating issues, and there is
> a series of
> MSDN articles on how to deal with it.
>
> Start with the articles at
>
> http://www.microsoft.com/globaldev/default.mspx
>
> and follow the links around. I'm still absorbing all the material here.
> joe
> On Sat, 25 Jun 2005 21:26:50 +0200, "Sam" <sam@xxxxxxxxxx> wrote:
>
>>Dear Dave,
>>
>>I'm sorry but I was misleading a little. My problem is with the different
>>languages. I don't know where is the language support comes into
>>expression - in the compiler(I have only VC in English), in O/S or
>>elsewhere. For instance I live in Israel, I create applications in my PC
>>which its default language is Hebrew and I never get Hebrew whatsoever.
>>
>>I hope I clarified a little.
>>
>>Regards
>>
>>Sam
>>
>>"David Lowndes" <davidl@xxxxxxxxxxxxxxx> wrote in message
>>news:9uoqb15dbbke1i9rot083aftg6ddke67nh@xxxxxxxxxx
>>> >I think I'll cope with that, but how to create these dll's.
>>> >Can you refer to a link or documentation also?
>>>
>>> Sam,
>>>
>>> Try this:
>>>
>>>
>>http://msdn.microsoft.com/library/en-us/vccore/html/_core_Create_a_Resource.
>>2d.Only_DLL.asp
>>>
>>> Dave
>>> --
>>> MVP VC++ FAQ: http://www.mvps.org/vcfaq
>>
>
> Joseph M. Newcomer [MVP]
> email: newcomer@xxxxxxxxxxxx
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • Re: Why R6RS is controversial
    ... the semantics of the language, ... behavior of grapheme-cluster characters under most linguistic ... as the strings grow longer. ... Normalization is hideously complicated, and may require many ...
    (comp.lang.scheme)
  • Re: add support for other languages
    ... There are a lot of issues dealing with internationalization. ... ComboBox needs to use language-specific strings, and you cannot make assumptions about the ... alternate language strings (apparently Finnish is the worst language, ... You cannot assume characters are single bytes. ...
    (microsoft.public.vc.mfc)
  • Re: Null-terminated strings: the final analysis.
    ... irrelevant to a discussion of C strings. ... contain any characters other than '\0', ... Yes, but you can't store a null character in the middle of a string, ... If, because of some requirement outside the C language, I want to ...
    (comp.lang.c)
  • RE: Prothon should not borrow Python strings!
    ... > "Strings are a powerful data type in Prothon. ... > should be a list of characters. ... Is there any dynamic language that already does this right for us to ...
    (comp.lang.python)
  • Re: Fast UTF-8 strlen function
    ... >> syllables using Latin characters. ... >> their native language using the Latin-characters. ... was a "standard" way to write Vietnamese stuff using ASCII ... And when it comes to vowels, this is NOT easy at all...English, in fact, is ...
    (alt.lang.asm)