Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
sukky
Newbie


Joined: 20 Jul 2006
Posts: 2

PostPosted: Thu Jul 20, 2006 1:22 pm   

Does CMUD support Korean? or other unicode languages?
 
Hello, Zugg.

I know zMud is not supporting unicode language like Korean or Chinese.
I feel glad that you released CMUD and I really want to know whether CMUD fully supports Korean.

Thank you.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Thu Jul 20, 2006 5:15 pm   
 
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.
Reply with quote
yejun
Wanderer


Joined: 13 Jun 2005
Posts: 51

PostPosted: Thu Jul 20, 2006 7:15 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Thu Jul 20, 2006 10:43 pm   
 
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.
Reply with quote
yejun
Wanderer


Joined: 13 Jun 2005
Posts: 51

PostPosted: Thu Jul 20, 2006 11:08 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Fri Jul 21, 2006 4:55 am   
 
Ack, sorry, I meant to say UTF-16 whenever I said UTF-8. My bad.
Reply with quote
Packet
Newbie


Joined: 23 May 2007
Posts: 1
Location: Seattle, WA

PostPosted: Thu May 24, 2007 12:08 am   
 
Apologies for resurrecting a dead thread here, but... :)

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.) :)

--Rachel
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Thu May 24, 2007 7:51 pm   
 
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.
Reply with quote
Nick Gammon
Adept


Joined: 08 Jan 2001
Posts: 255
Location: Australia

PostPosted: Mon Jun 18, 2007 9:49 pm   
 
Ah, Unicode. :)

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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Mon Jun 18, 2007 10:32 pm   
 
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.
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Fri Jun 22, 2007 9:01 pm   
 
Zugg wrote:
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 Rolling Eyes.

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.
Reply with quote
Nick Gammon
Adept


Joined: 08 Jan 2001
Posts: 255
Location: Australia

PostPosted: Sun Jul 08, 2007 9:46 pm   
 
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.
Reply with quote
Fang Xianfu
GURU


Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom

PostPosted: Sun Jul 08, 2007 10:06 pm   
 
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.
_________________
Rorso's syntax colouriser.

- Happy bunny is happy! (1/25)
Reply with quote
Rorso
Wizard


Joined: 14 Oct 2000
Posts: 1368

PostPosted: Mon Jul 09, 2007 8:53 am   
 
There's Italian, Spanish, and Swedish translations avaible to zMUD.

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?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Mon Jul 09, 2007 6:31 pm   
 
Quote:
WoW addons tend to be very well localised, though

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.
Reply with quote
Nick Gammon
Adept


Joined: 08 Jan 2001
Posts: 255
Location: Australia

PostPosted: Tue Jul 10, 2007 6:49 am   
 
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.
Reply with quote
Zhiroc
Adept


Joined: 04 Feb 2005
Posts: 246

PostPosted: Fri Jul 20, 2007 5:18 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Fri Jul 20, 2007 6:06 pm   
 
Yes, CMUD is already "8-bit clean". It never uses the upper bit for anything special. And it's already being used in many European countries without problems I think.
Reply with quote
sukky
Newbie


Joined: 20 Jul 2006
Posts: 2

PostPosted: Thu May 05, 2011 11:31 am   It have been passed five years.
 
Does CMUD still not support Korean?

:)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23377
Location: Colorado, USA

PostPosted: Thu May 05, 2011 4:04 pm   
 
It still does not and recent work trying to make CMUD Unicode compliant was not successful. So at this time I have no plans to support Korean or other multi-byte languages, sorry.
Reply with quote
Tarn
GURU


Joined: 10 Oct 2000
Posts: 853
Location: USA

PostPosted: Fri Jun 10, 2011 7:35 am   
 
Nick Gammon wrote:
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.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net