[ruby-talk:12124] Is Ruby japanese-centered?

[matz writes]
[ruby-talk:11539]
  (c) you can handle multibyte characters by specifying -K option,
      which K is for Kanji (Japanese/Chinese characters).  And its
      multibyte features are totally centric to Japanese (yet, I'm
      working on it).

							matz.
--------------------------------------------------------------------
I think matz is very modest:

I couldn't help notice the "-u" option that makes Ruby accept any utf-8
encoded unicode carachter, in regexes, strings and even varible names...

That is not so bad.
(For those who havn't tried to name a variable by Kanji, go to
http://home.no.net/hvrosen/rubeno/ to look at some playing around)
***se note at bottom of message

Interesting... nowhere in the docs could I find anything on this matter, but
for the mentioning of /XXX/u and "-Ku". I think that I did find some
japanese language docs, but... the Exite would not work...

Anyway, can anyone be so kind to enlighten me on what m17n stands for, and
how it come to be that i18n means internationalization (more than the
strongly felt need to save typing:-))?

I find these docs useful on the i18n topic.
[about _where_ to depend on encoding, and _where_ not to]
http://ppewww.ph.gla.ac.uk/~flavell/charset/quick.html
[I18n-sig] Pre-PEP: Proposed Python Character Model, proposing to deprecate
the unicodestrings.
http://mail.python.org/pipermail/i18n-sig/2001-February/000646.html

Where does Ruby stand in this?



amike via Henning

---
***(Of course, variable names should strictly conform with the environment,
not leaving the ASCII subset if not needed, since there is no guarantee for
what other environments can present and other programmers understand. This
is why Guido never allowed unicode variable naming to Python - they can live
in the hashtable implementation, but not be swallowed by the interpreter...
Anyway - the linguistic rights are happy for the freedom of kanji, swedish
dupoints and esperantic "roofs" and so on)