Running PennMUSH under win32 with support for Scandinavian characters

I'm currently looking into setting up my own pet MUSH. As it is going to be a game for Norwegians, I'd hoped it would be possible to have the engine parse the three additional Norwegian lettes: æ, ø and å.

I was thrilled when I noticed the latest patch level includes support for this in some form or other, but I am not at all sure what is required to enable it. I assume it takes a recompilation of the source, but perhaps not.

The "restart" configuration file has a variable for setting the language of the MUSH, but there seems to be little or no change when using it.

I'd be overjoyed if someone on this board could help me with this. I need the game to process æ, ø and å. That's all. :-)

Thanks a bunch,
Thor

How do you mean process exactly? In a "say"?

How can I type those characters on my keyboard to test it?

Well, in any command. As it stands, it appears the game simply omits those characters when encountered. "SAY Ære være med deg!" is rendered comes out "re vre med deg!". And if you simply feed them to the game as you would any other command, it doesn't even give you a "Huh?". It's as though they weren't even there.

No, you can't type them on your keyboard unless your mud client takes ALT+??? combinations, or you set the keyboard layout to Norwegian of course. You can always copy them. Here's a small cache so you don't run out: øæøæøæøåøåøæøøøåøåøåæø! ;-)

Thor (btw, your password retriever is down - hence the triple r :-P)

How do I apply those .PO files anyway?
se_SV.po, for instance... I find no directions.

Thor

I have forwarded your query to the PennMUSH supporters.

I don't understand the question about .PO files? Where did you find them?

The .PO files are sets of translated in-game message. It appears they are supposed to be patched over the original source files before compiling them.
You can find them here, for instance:
http://ftp.pennmush.org/Source/translations/1.7.4p5

I know very little of Unix, but the PERL script "restart", residing in the game folder, seems to be tailored to handle the setting of your locale, by altering the LANG environment variable. Also, it appears the whole deal requires a program called "setlocale", which looks to be a *nix thing too.

It's dawning on me that win32 support for this hasn't been meddled with yet. Oh well...

Thor

I got this response from the PennMUSH developers:


Yes, the server needs to be compiled with locale support and run on a system with proper Norwegian locales. Unfortunately I don't know much about how to do setlocale NLS on Windows...

Well, what can a man do? *grin*

I suppose that means I'll have to get myself a Linux box - and that is fine. :-)

Thor

Oh! And I wanted to tell you how lovely it is to get swift and helpful replies directly from the developer(s). You seem to be doing what you can to get back to the people posting here, and that's great.

Kudos to Nick. :-)

I don't use PennMUSH or anything like it, but from what i know about merc/envy/etc derivitives, I/O operations use signed characters, not unsigned, meaning they support no "extended ascii", such as norwegian characters.

it shouldn't be too hard to change this. does this help, at all?..

- dave

As far as IO goes, a byte is a byte, really.

I understand the point you are making, but I think if you do this:

unsigned char a = 255;
char b;

b = a;

You will still get all bits copied from b to a. If you try to display "b" it will "appear to be" -1, not 255, but the same bits are still there in the same order.

I think the reason some characters are disappearing is that the server is making a conscious decision to strip them, eg.

b &= 0x7F;

However there may be a more subtle reason. I have emailed the developer again to get clarification on this point.

This is the response I got:




Now, looking in ctype.h I see this:



#define _U 01
#define _L 02
#define _N 04
#define _S 010
#define _P 020
#define _C 040
#define _X 0100
#define _B 0200

extern __IMPORT _CONST char _ctype_[];

#define isalpha(c) ((_ctype_+1)[(unsigned)(c)]&(_U|_L))
#define isupper(c) ((_ctype_+1)[(unsigned)(c)]&_U)
#define islower(c) ((_ctype_+1)[(unsigned)(c)]&_L)
#define isdigit(c) ((_ctype_+1)[(unsigned)(c)]&_N)
#define isxdigit(c) ((_ctype_+1)[(unsigned)(c)]&(_X|_N))
#define isspace(c) ((_ctype_+1)[(unsigned)(c)]&_S)
#define ispunct(c) ((_ctype_+1)[(unsigned)(c)]&_P)
#define isalnum(c) ((_ctype_+1)[(unsigned)(c)]&(_U|_L|_N))
#define isprint(c) ((_ctype_+1)[(unsigned)(c)]&(_P|_U|_L|_N|_B))
#define isgraph(c) ((_ctype_+1)[(unsigned)(c)]&(_P|_U|_L|_N))
#define iscntrl(c) ((_ctype_+1)[(unsigned)(c)]&_C)


How this works basically is that there is an array of 256 bytes (_ctype_) and to test if a given character is (say) alpha, the isalpha macro indexes into that array and sees if the bits _U or _L are set (Upper or Lower I presume).

I can't see where this array itself is defined, so it is probably inside a library somewhere. So it appears that by correctly localising (something I don't know how to do), the correct library will be installed, the correct _ctype_ array will be used, and your characters will automatically work. :)

However, see: http://www.gammon.com.au/forum/?id=3902