News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

unicode for multi-lingual support

Started by dedndave, February 02, 2009, 02:00:47 PM

Previous topic - Next topic

dedndave

I would like to provide support for multiple languages.
I understand the unicode file formats, and how text is diplayed, etc.
I have no intention of learning all the languages of the world - lol.
I have installed one of the Chinese language packs, just so I could see how things work.
(Which, I don't readily see a way to un-install - lol).
Is there a simple way to create the required unicode files without actually being able to display them?
An example that comes to mind is, as mentioned, I have a Chinese language pack installed.
But, if i view a different language file (Hebrew, for example), the characters are Chinese, of course, and make no sense.
I am sure I am not the first one to want to write programs for multiple languages without getting to involved.
Does anyone know of a simple game-plan ?
- Dave

Mark Jones

Hi Dave, I believe .RC resource files will allow strings containing unicode text. So one solution may be to write the base code (keep in mind that the -W suffix must be used on most Windows API's i.e. MessageBoxW), then create .RC files for each language you wish to display, and switch between these strings at run-time.

Jeremy's GoASM includes native unicode string support, as well as an optional "loader" which allows unicode executables to work on Win9x machines without any fuss.
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

Tedd

You make a "string table" resource, containing all of the strings which are displayed to the user.
At the start of your program, you get the current locale, and then try to load 'that' string table (which will contain the strings in the correct language for that locale.) These are the strings you then use.
As for knowing whether they will display correctly, as long as they're in unicode, you should assume they will -- most likely, the person who provided them to you (since it's not your native language) will have input them correctly to display on their system.
No snowflake in an avalanche feels responsible.