Re: add support for other languages
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Sun, 26 Jun 2005 22:43:05 -0400
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
.
- Follow-Ups:
- Re: add support for other languages
- From: Chris Ward
- Re: add support for other languages
- References:
- add support for other languages
- From: Sam
- Re: add support for other languages
- From: David Lowndes
- Re: add support for other languages
- From: Sam
- Re: add support for other languages
- From: David Lowndes
- Re: add support for other languages
- From: Sam
- add support for other languages
- Prev by Date: Re: Bridge applicaiton: best connectivity solution?
- Next by Date: Re: First-chance exception . . . (NTDLL.DLL) . . . Access Violation.
- Previous by thread: Re: add support for other languages
- Next by thread: Re: add support for other languages
- Index(es):