No, not yet. This is planned for the future, but probably not in the first public release. It was impossible to implement Unicode in zMUD because of the old compiler (Delphi 5) that I was using. CMUD uses a newer compiler (Delphi 7) which does have Unicode support, so at least it should be possible, even if it requires a lot of work.

Is cMud 8bit safe?
In zMud, #D0 will be treated as a special char, and will be altered during variable assignment.

btw, Delphi 7 doesn't have native unicode VCL, only very small number of 3rd-party components support unicode display. eg. JVCL, TNTWare and Virtualtree. I won't expect a unicode cmud anytime soon, but I'd like to have a cmud can deal with 8-bit string.

Well, 8-bit is actually what I was talking about. I should have been clearer. I'm talking about UTF-8 support, which is one possible Unicode encoding. UTF-8 is the only thing that CMUD probably has a chance to support.

The Delphi 7 VCL *does* support UTF-8. There is a datatype called a "WideString" which is the OLE compatible string type. Lots of 3rd parties support WideString types. But yes, that's where all of the work is...going through all of the 3rd party components and making sure WideStrings work.

In Delphi 5, Delphi itself had all sorts of problems with WideStrings, which is why UTF-8 wasn't really possible at all. As I said, with CMUD it should be possible to support UTF-8, but the current version does not and it will be a while before it does.

One of the issues is testing. Since I don't have any system that uses UTF-8, I have no way to test this myself, so I'll be relying on external beta testers.

Widestring in Delphi 7 is implemented as UCS-2 (UTF-16) not UTF-8, so PWidechar can be used in Windows API directly without conversion.
As far as I know, Delphi 7 VCL only support MBCS conversion. Even the newest Delphi 2006 doesn't have Win32 Unicode VCL. Widestring is a native type for compiler, and delphi has some unicode support in RTL, but not in VCL.

Most existing/older MUDs that use multibyte languages use language-specific (Korean, Chinese) encodings. Some newer servers (including MUSH/MUX variants) are using straight out UTF-8 to make it easier to support multiple languages, but those are still in the minority. None that I have yet encountered use UTF-16 across the wire. (Probably largely because UTF-16 is endian-sensitive and thus makes for headaches.)

In terms of what you support going across the wire, UTF-8 is obviously the most important (as it's what server codebases are slowly adopting if they want to do multibyte), but

The other thing I would suggest is using Telnet CHARSET negotiation, if at all possible. Several servers are beginning to use it so that the client and server can agree on an encoding where possible, and it makes for a smoother experience overall. A few clients (well, okay, two that I know of) are using that already to make it easier, and if CMUD does alo I can only imagine it'll help push adoption among servers!

(As background, I write a MU* client for a non-Windows platform as well as helping on the MUX 2 codebase, and have already had to walk the Unicode route for both. Lately, I'm kind of an evangelist for getting more clients to support UTF-8 and multibyte encoding, and trying to get some sort of ad hoc Unicode MU* standard together.) :)

The news is not good for this. Turns out that even the brand new Delphi 2007 still doesn't support Unicode in the VCL, and from discussions on various Delphi developer's blogs, it doesn't look like it ever will. So, supporting any sort of Unicode or alternate character sets is going to be a huge project. If you have any pointers to sites listing resources for implementing the telnet CHARSET negotiation, please post as much as possible. My main problem is that I have no way to test this kind of stuff, and there is a lot of work involved, so right now it's become a very low priority.

I have looked at this sort of stuff in MUSHclient as Packet/Rachel may be aware. The charset negotiation is only half of the story, no doubt an important half. The client may support UTF-8 but the user have installed a non-Unicode font. I haven't been able to find any easy way (or any way at all) of finding whether or not the currently-selected font is Unicode-aware.

This raises another issue I have been looking at recently - Internationalization. I am curious to know whether there are plans for making CMUD localizable (eg. do menus in French, Italian etc.)? Also, if anyone would be interested if it were? I can start another thread is that seems more appropriate.

Internationalization is on my (long) to-do list, but is a pretty low priority right now. I spent a *lot* of effort adding it to zMUD, and only ended up getting a couple of translations (for various reasons). It made me feel like it wasn't worth all of the effort.

Coming up with something that is easy to translate, easy to implement and easy to maintain as features change, etc, is challenging (and also making it something that doesn't kill performance...the zMUD method made dialog creation much slower). On top of this, there is the whole help-file translation issues.

Internationalization is on my (long) to-do list, but is a pretty low priority right now. I spent a *lot* of effort adding it to zMUD, and only ended up getting a couple of translations (for various reasons). It made me feel like it wasn't worth all of the effort.

Coming up with something that is easy to translate, easy to implement and easy to maintain as features change, etc, is challenging (and also making it something that doesn't kill performance...the zMUD method made dialog creation much slower). On top of this, there is the whole help-file translation issues.

When I worked on translating zMUD there was a few issues:
1. It is a large task to write a translation. You often had to open zMUD to check how the translated labels looked so that they didn't mess up the UI or become too long. Some sentences might be tough to translate as they might not have an obvious translated counterpart.
2. If a new version of zMUD was released then new strings would be needed to be translated. Which ones? What about removed ones?

Due to the size of zMUD the translation work can be very boring. It requires a lot of focus and having faith that the final result will be worth the effort. The work can take many days before you've managed to translate a bigger part of the application. The main motivation is that perhaps someone will use the translation. Perhaps .

The target language I translated to (swedish) didn't really need to be done. In Sweden a lot of people know English quite well. The reason I made the translation was mostly for fun, and try get others to make translations as well. Also I noticed translation support in zMUD appeared to slowly be dropped (e.g lack of support in mapper) which motivated me a bit to get started.

I spent quite a bit of effort adding Internationalization to MUSHclient, so far I don't know of a single attempt at localizing it. Perhaps someone is quietly working away on it, I don't know.

I did make a facility to notify you if new strings appeared (a small script compared the 'before' and 'after' files in English) - so that part would have been easy enough.

It was also possibly to part-translate, so you could change only common messages. I wrote a second script to tell you, after running a session, which messages appeared most often. Both of those things would probably help the translator.

Having said that, as I commented before, the response was underwhelming.

Perhaps it's something to do with the availability and distribution of translations. The response for zMUD transations seems to have been similarly scarce (the only one I know about is on Rorso's site). WoW addons tend to be very well localised, though - the relative simplicity of WoW addons definitely plays a part, but localisations are normally distributed by the addon's author in the same package as the addon itself, and the right localisation is chosen automatically by the game. The convenience of not having to search for your localisation is probably a very important factor.

I think that few people make localisations, too - it's too much effort for too little payoff. It's much easier just to cope with some English words and wait for someone else to do it. And there's always some crazy person who wants to do it just to see if they can. Here's looking at you, Rorso ;P

The same probably applies to themes. While themes are nice, looking for them isn't.

Edit: Perhaps the real question is how many non English MUDs are there and how many active players does those MUDs have? Non English MUDs might be a small part of the already small MUD community. On the other hand asking such a question might be bad. Is it possible that if translations were avaible that more people would come play MUDs?

That's probably because 8 million people are using Wow, and there are less than 100,000 people using zMUD. Makes a big difference.

And honestly, not that I want to start a flame war or anything, but most of the requests that I get for unicode-support/translations are from Chinese/Korean/etc where the crack rate is so large that I don't expect I'd gain any additional sales anyway.

I tend to agree with Nick...it's a *lot* of effort, for very little return. And it certainly isn't high on the priority list given all of the other things I can spend my time on (like improving the mapper) which *would* improve sales. It took several years for me to get around to having a translation ability in zMUD...CMUD is only a year old. Maybe in a few years when I'm done with the more important stuff, then I'll get around to this.

The only recent response I got to the localization question was someone from China. Bear in mind that there are a *lot* of people living there.

I have been puzzled by the localization issue for some time. Are there non-English MUDs? If so, are there whole code bases we know nothing about written in, say, French? Or do non-English mudders simply learn English, to understand the error (and other) messages from standard non-localized MUDs?

I even asked the Lua developers (who are Portugese) about adding some sort of localization to Lua. I did not even get a reply of any sort. Evidently most developers use English, even if it isn't their native language.

Even if you can't go the whole way to implementing unicode, you can go a long way by simply assuring that the whole application is 8-bit clean, meaning that all chars will be displayed according to the font being used, and that the "upper-bit" isn't being used to mark a character as being special. This allows you to support either Windows-1252 or ISO 8859-1 charsets, which support just about all Western European languages. It can be left to the user to specify fonts that correspond to those.

The only recent response I got to the localization question was someone from China. Bear in mind that there are a *lot* of people living there.

I have been puzzled by the localization issue for some time. Are there non-English MUDs? If so, are there whole code bases we know nothing about written in, say, French? Or do non-English mudders simply learn English, to understand the error (and other) messages from standard non-localized MUDs?

I even asked the Lua developers (who are Portugese) about adding some sort of localization to Lua. I did not even get a reply of any sort. Evidently most developers use English, even if it isn't their native language.

Post is old, most recent post is not that old...

English/ASCII is dominant because the last thing a developer wants to spend time thinking about is "I understand the code, and my IDE supports unicode, but how the (*#(*(* do I type the name of that variable on my keyboard?"

English/ASCII is a lowest common denominator for many, many purposes in the international community.

The end users may like to produce native-language content but the developers and other technical people might not.