The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Resource string ordering

Got a problem... I need my app to be fully self-contained (ie. single executable) and multi-lingual. I put in a bunch of resources in other languages and tried to follow the logic in Microsofts scheme for loading string resources:

Windows NT
1.    Neutral
2.    Prim Lang/ Sub Lang
3.    English (US)
4.    Neutral (default)
5.    Whatever else it can find

I put Enlish (US) 2048 resources, as well as a bunch of Spanish and German strings. But on my PC, which is fully English based, the German resources are always used. Any ideas? My understanding is that English (US) would have been picked up after tests 1 & 2 have failed.
String man
Sunday, March 27, 2005
I found the problem. The issue was that VS for some reason put English (US) strings as 2048, which is wrong. I manually changed it to the proper string resource number and everything seems better. So now another question: I have a customer who wants Chinese resources added. Unfortunately our app was not written in Unicode. Does an app require to be written in Unicode to display the Chinese strings? I do know that the stuff is correctly formatted in the resource editor, but when I try to display this Chinese text in my non-Unicode app, it appears with a bunch of ?#$ symbols. So am I doing something wrong altogether, or can I expect this to work correctly on a Chinese computer with the appropriate texts?
String man
Sunday, March 27, 2005
Try installing support for Far Eastern languages (there's a tickbox for it in XP on the languages section of the control panel I think it was) then selecting chinese as the language for your non-Unicode apps.

That's a guess, but it works like that for the Japanese non-Unicode multibyte encoding, which just produces gibberish high-byte characters if you don't have the right bits installed. No need for Unicode that I could tell, we had some console programs written by Japanese programmers and they printed everything out (in Japanese) using normal printf.

I suspect the VS dialog editor works internally with Unicode and so displays everything correctly all the time.
Monday, March 28, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz