>   Ah yes, the problem is not only for menus, but also
> inputing, justification, file-io, comparion and more.

I found that UI's were more amenable to localization when field
labes are above fields, rather that to the (left) side.  This way
when the length of the label changes, the layout doesn't get as messed up.

>   The biggest problem of Unicode is the existence of 'many-
> to-one mapping.' The interpretation of the 16bit code
> depends on the unencoded external environment.

Are you talking about the CJK unification?  I worked on an application
that went chinese, japanese, korean (and english for debugging :-).
I was told never to mention Unicode around a client because unification
gives it a bad rap. We did use Unicode internally, and I found that
it helped dealing with these languages.

>   The better alternative is something like an aggregation of
> local encodings which Mule employs. (Yes, Unicode can be one
> of the local encoding.)

I agree.


So, I go browsing the Charcter class in Squeak to see what would be 
involved in multi-byte characters, and run accross the class-side method:

initialize
	"Create the table of unique Characters. This code is not shown so 
that the
	user can not destroy the system by trying to recreate the table."

Open source :-?

Undetered, I try:

	String with: (Character basicNew instVarAt: 1 put: 16r2190; yourself)

And it evaluates even though if you look at the code (or even step into
the String >># at:put: primitive) it should be an error.  Some kind of
wierdness in the primitive.  Hmm, maybe I can build a VM in my PC, someday.

-- Mike Klein

P.S.  maybe we should put the underscore glyph at some unused code point 
in Squeak's character map  (kidding :-)