Edmund,

> While I was in Japan, I tried using Abe-san's Nihongo port, but ran into
> serious issues: I didn't know what I was doing and on the other hand my
> image kept being killed by some bug. As a newbie, with the inevitable
> communication difficulties (it's really hard reading Japanese lists), and
> no ability to make people believe that I really had a bug (although I was
> very happily programming Squeak 6 hours a day with a standard image) I
> just gave up on Nihongo Squeak. Based on my past experiences, with Squeak
> and other computer languages, I would say that if you need to get a
> linguistic add-on to work in a language you are not an expert in, you will
> probably have a lot of problems. If the support is in the core you will
> succeed quickly.

  I agree with you that it should be in the main image.

  Emacs 18 and Mule 1, Emacs 19 and Mule 2 were separated software,
but Emacs 20 and after, most of the Mule work were integrated into the
main stream Emacs.  I'm hoping similar thing happens to Squeak.

> The reason I bring up Swiki is that by definition a Web server is exposed
> to posting from people all over the world. People tend to write their
> names and addresses in their own language, in particular.I have had
> problems in the past with Swiki and various languages. The core seemed to
> work, but as Abe-san and Oshima-san showed me, the client needs to know
> what language the page is in etc, which shoukd be handled by sending some
> more info, I guess. This has probably been fixed in the current versions,
> but I still think that any new work on Swiki should take multi-lingual
> issues into account, from the start.

  If I remember correctly, this was not exactly a Nihongo image
problem, right?  (Hmm, I can't remember well...)  The data sent from
the web browsers via POST simply assume the content type to be the one
declared in the page itself and the (modified) MimeDocument class
didn't (and doesn't) handle it properly or such?

-- Yoshiki