[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  International
. . -> [Subject]  Localization - is it needed?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Localization - is it needed?

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Pages: 1  2 

Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #15 on Mon 11 Jun 2007 06:11 AM (UTC)
Message
Quote:
I'm a bit puzzled it was that easy - this was in the full MUSHclient compile?


Well, it's not that easy. On closer inspection it turned out that I merely confirmed that Russian is displayed, not that Unicode is displayed, but Russian characters are on most English codepages so my tests provide no proof that Japanese, for example, will also be displayed without problems.

Later yesterday I tried changing the codeset for the entire solution to Unicode and sure enough - that spawned over 2000 compile errors, mostly having to do with conversion between LPCTSTR/LPCWSTR and char. Some of those errors (those that involve literal strings in assignments and function calls) are easy to solve, but implications of fixing the rest are not as obvious to me.

Quote:
The normal AfxMessageBox function (in a non-Unicode application) expects 8-bit data.


VS8 supposedly has a "Unicode version" of MFC. At least many of the errors I mentioned above seem to indicate that AfxMessageBox expects a wide char* instead of char*, which is what it is getting right now all over the place. Converting literal strings to wide (with the L macro) solves this chunk of errors.

Quote:
As for changing things like dialog boxes - do you think you could make a copy of the resources that use Russian characters, and I could merge them into the existing source? I don't have the .NET compiler (yet, anyway).


Sure.
[Go to top] top

Posted by Nick Gammon   Australia  (21,321 posts)  [Biography] bio   Forum Administrator
Date Reply #16 on Mon 11 Jun 2007 07:05 AM (UTC)
Message
Quote:

... sure enough - that spawned over 2000 compile errors, mostly having to do with conversion between LPCTSTR/LPCWSTR and char ...


Well I tried that once with similar results. You can put _T(...) around strings but then that introduces another heap of errors.

For example, functions that have a 'const char *' prototype will not now accept the new strings. So, you change those, and then they fail because they call something like fwrite, (or strlen) which still expects char *.

It was about at this point when my mind started to boggle. For example, Lua uses 8-bit strings, not 16-bit strings. Also, MUSHclient world files are 8-bit data, not 16-bit data. Also, incoming text from a MUD is 8-bit data.

I think the simpler solution is to stick to UTF-8 for Unicode data, provided we can solve the problem of getting dialog boxes to display in Unicode, which judging by the earlier post, someone has done.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,321 posts)  [Biography] bio   Forum Administrator
Date Reply #17 on Mon 11 Jun 2007 07:09 AM (UTC)
Message
Quote:

On closer inspection it turned out that I merely confirmed that Russian is displayed, not that Unicode is displayed,


What I think you need to do, is look up the Unicode code points by referring to the appropriate page here:

http://www.unicode.org/charts/

Then you can use the "Debug Simulated Input" dialog in MUSHclient to convert Unicode code points into UTF-8 sequences in hex. Having done that you can plant those into a dialog box and confirm they are displayed correctly.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Ked   Russia  (524 posts)  [Biography] bio
Date Reply #18 on Mon 11 Jun 2007 08:23 PM (UTC)
Message
Ok, I checked a UTF-8 sequence as you suggested. I used the following call, which might even be a wrong way to do it:

::AfxMessageBox("\d0" "\90")


And the dialog displayed two separate characters instead of a single capital "A".

This was with the multi-byte character setting, since Unicode doesn't compile.

From what I understand in "multi-byte mode" AfxMessageBox uses the current locale's codepage to convert an array of chars, so it will display Russian or Chinese text properly as long as the corresponding codepage is selected. But it'll treat UTF-8 also according to this codepage, not UTF-8 itself. At least MSDN docs on setlocale() explicitly say that you cannot set the locale to UTF-7 or UTF-8.

[Go to top] top

Posted by Nick Gammon   Australia  (21,321 posts)  [Biography] bio   Forum Administrator
Date Reply #19 on Mon 11 Jun 2007 09:50 PM (UTC)
Message
Yes, UTF-8 is an encoding system, not a locale.

This is roughly what I am using:


#include <vector>

// display message box - using UTF-8
int UMessageBox (const char * lpszText, UINT nType)
  {

  // find how big table has to be
  int iLength = MultiByteToWideChar (CP_UTF8, 0, lpszText, -1, NULL, NULL);

  // vector to hold Unicode
  vector<WCHAR> v;

  // adjust size
  v.resize (iLength);

  // do the conversion now
  MultiByteToWideChar (CP_UTF8, 0, lpszText, -1, &v [0], iLength);

  // determine icon based on type specified
  if ((nType & MB_ICONMASK) == 0)
  {
    switch (nType & MB_TYPEMASK)
    {
    case MB_OK:
    case MB_OKCANCEL:
      nType |= MB_ICONEXCLAMATION;
      break;

    case MB_YESNO:
    case MB_YESNOCANCEL:
      nType |= MB_ICONEXCLAMATION;
      break;

    case MB_ABORTRETRYIGNORE:
    case MB_RETRYCANCEL:
      // No default icon for these types, since they are rarely used.
      // The caller should specify the icon.
      break;
    }
  }

  int nResult = ::MessageBoxW (NULL, &v [0], L"MUSHclient", nType);

  return nResult;

  }   // end of UMessageBox



And test like this:


   UMessageBox ("\xC9\xB3\xC9\xA8\xC9\x95\xC9\xAE");


That UTF-8 sequence should show 4 characters that look vaguely like "Nick".

What this is doing is taking UTF-8 input, converting to wide characters (WCHAR) using MultiByteToWideChar, and then calling MessageBoxW to display the Unicode text.

I am basically going through the MUSHclient source changing all calls to AfxMessageBox to UMessageBox, thus facilitating the display of Unicode.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,321 posts)  [Biography] bio   Forum Administrator
Date Reply #20 on Mon 11 Jun 2007 09:52 PM (UTC)
Message
I'm not sure about the L"MUSHclient" - that is displayed in the dialog box title. It is a proper name, after all, so perhaps it doesn't need translating?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (21,321 posts)  [Biography] bio   Forum Administrator
Date Reply #21 on Tue 12 Jun 2007 06:14 AM (UTC)
Message
See follow-up thread with progress to-date:

http://www.gammon.com.au/forum/?id=7953

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


24,622 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]