> Le Jeudi 23 F=E9vrier 2006 17:37, Chris Laurel a =E9crit :
>> > To avoid character map issues, the generated resource files use UTF-=
>> > (code_page 65001), this appears to not be supported by VS 6, is that=
>> > problem?
>> > Chris, can I commit the win32 i18n patch?
>> Yes, you should commit the patch.
> Ok, I'll commit everything tonight, including the perl scripts.
>> > Here is the TO DO list to have i18n working on Windows:
>> > - automatic loading of the appropriate resource file
>> > - conversion of utf8 strings to the current local in dialogs
>> > - unicode input (supported by celestiacore, but not used by winmain).
>> I *think* that we'll need to start building the Windows version with
>> UNICODE defined. Or is this not necessary if we use UTF-8 encoded
>> instead of wide characters?
> I've seen that there are two modes for windows apps: ANSI or UNICODE, b=
> not sure what the effect of UNICODE is. My understanding is that the wi=
> API then expects all GUI strings to be wide character strings? does tha=
> affect IO operations?
> Otherwise, I think we can get away with the current ANSI mode, converti=
> UTF8 string to wide caracters and then to the current CP. That will wor=
> the LANGUAGE you're running Celestia with is supported by your current =
I got everything to build last night after making a couple adjustments
which I'll check in tonight. I'll also upload a new version of winlibs.zi=
that includes intl.lib, iconv.lib, and relevant headers.
I experimented with the using the French resource file, hoping that
everything would just work. The French language UI strings were shown, bu=
the non-ASCII characters were not drawn correctly. I think you're correct=
we need to convert UTF-8 to wide characters and then to the codepage.
Switching to UNICODE and wide characters throughout would mean that
Celestia could no longer run on Win9x.