my life at the moment
-
Gary R. Wheeler wrote: .RC files must be encoded as MBCS (multibyte character set, not UNICODE) :wtf: That's news to me. (Un)fortunately, this app is in VB, and as my luck would have it - most VB programs don't take advantage of resource scripts. We're pulling the translations from a SQL database (the app is used over a citrix server). Gary R. Wheeler wrote: By the way, did I mention that if you set the code page for the .RC file to 1200 (UNICODE), the farking IDE (.NET 2003) will no longer load the file? LOL! That's about all I can say. So far, we've been doing all the Japanese development on a Japanese version of Windows XP with minimal problems. Of course, we're also using VB6 too. (insert sigh here) Jeremy Falcon
Jeremy Falcon wrote: That's news to me. As you know, resource scripts are essentially source files. The bulk of the file is syntactic elements that describe bits and pieces of the user interface. The language-specific text actually occupies a relatively small portion of the file. I think you could justify converting the whole mess to UNICODE, however. The syntactic elements (
DIALOG,BEGIN/END,STRINGTABLE, etc.) aren't any more difficult to parse and identify as UNICODE than they are in an ANSI character set. The screen text, however, is required to be unambiguous. The current methodology involves multiple translations between an MBCS code page and UNICODE. Each translation has the potential for data loss. For example, if a UNICODE character doesn't have a corresponding MBCS representation, you're stuck. Unless you are supporting Windows 95, UNICODE is a better way to go. It's supported natively in Windows NT/2000/XP, and with an add-on for Windows 98. Jeremy Falcon wrote: we've been doing all the Japanese development on a Japanese version of Windows XP with minimal problems Thus far I've been able to get away with using the Japanese add-on from the XP multilingual pack. It adds Japanese fonts and resources to English Windows. For a while I was switching back and forth from the Japanese UI to the English one. Recent changes in my translation app have made it easier, however. I can test most of the application (Japanese text display, file parsing and I/O) under the English UI (it displays Japanese just fine). I have to switch to the Japanese UI to test the text entry, however. Sorry to have gone on and on about this :-O. I've spent the last 8 working days on this issue, and it's rather nice to finally have it ironed out :sigh:.
Software Zen:
delete this; -
Jeremy Falcon wrote: That's news to me. As you know, resource scripts are essentially source files. The bulk of the file is syntactic elements that describe bits and pieces of the user interface. The language-specific text actually occupies a relatively small portion of the file. I think you could justify converting the whole mess to UNICODE, however. The syntactic elements (
DIALOG,BEGIN/END,STRINGTABLE, etc.) aren't any more difficult to parse and identify as UNICODE than they are in an ANSI character set. The screen text, however, is required to be unambiguous. The current methodology involves multiple translations between an MBCS code page and UNICODE. Each translation has the potential for data loss. For example, if a UNICODE character doesn't have a corresponding MBCS representation, you're stuck. Unless you are supporting Windows 95, UNICODE is a better way to go. It's supported natively in Windows NT/2000/XP, and with an add-on for Windows 98. Jeremy Falcon wrote: we've been doing all the Japanese development on a Japanese version of Windows XP with minimal problems Thus far I've been able to get away with using the Japanese add-on from the XP multilingual pack. It adds Japanese fonts and resources to English Windows. For a while I was switching back and forth from the Japanese UI to the English one. Recent changes in my translation app have made it easier, however. I can test most of the application (Japanese text display, file parsing and I/O) under the English UI (it displays Japanese just fine). I have to switch to the Japanese UI to test the text entry, however. Sorry to have gone on and on about this :-O. I've spent the last 8 working days on this issue, and it's rather nice to finally have it ironed out :sigh:.
Software Zen:
delete this;Gary R. Wheeler wrote: The screen text, however, is required to be unambiguous. You'd think everything would be Unicode for resource scripts then since MS dumped Win95. Gary R. Wheeler wrote: Sorry to have gone on and on about this . I've spent the last 8 working days on this issue, and it's rather nice to finally have it ironed out No problem, if I come across this issue in the future, I'm sure it'll help me out. :) Jeremy Falcon