From xemacs-m  Fri Dec  6 02:22:54 1996
Received: from etlpost.etl.go.jp (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id CAA09306 for <xemacs-beta@xemacs.org>; Fri, 6 Dec 1996 02:22:52 -0600 (CST)
Received: from etlpom.etl.go.jp by etlpost.etl.go.jp (8.6.9+2.4W/2.7W)
	id RAA01354; Fri, 6 Dec 1996 17:22:38 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA14721; Fri, 6 Dec 96 17:22:37 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id RAA06798; Fri, 6 Dec 1996 17:23:43 +0900
Date: Fri, 6 Dec 1996 17:23:43 +0900
Message-Id: <199612060823.RAA06798@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: mule@etl.go.jp, mrt@mickey.ai.kyutech.ac.jp, xemacs-beta@xemacs.org,
        brewin@Eng.Sun.COM, Teruhiko.Kurosaka@Japan.Sun.COM
In-Reply-To: <199612060615.WAA03500@xemacs.eng.sun.com> (message from Martin
	Buchholz on Thu, 5 Dec 1996 22:15:35 -0800)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   Date: Thu, 5 Dec 1996 22:15:35 -0800
   From: Martin Buchholz <mrb@Eng.Sun.COM>

   Most Japanese WILL want to see the output of `date' in Japanese.

Really?  I'm not sure.  Making date command localize is, I think, just
a waste of time.  I think most users don't ever want to invoke `date'
command, but just want to see it on window (like xclock).  Programmers
or system managers may want to invoke `date' command.   Please ask
them if they surely want to see Japanese output.

   The dominant model for internationalization is the locale model.  We
   cannot just ignore it.  Vendor-provided message translations are
   desired by users, and are usually only provided using the locale model.

   KH> to see Japanese/Chinese/Thai/... text if it is there when, for
   KH> instance, I invoke `head FILENAME'.

   Suppose different files are encoded using different coding systems.
   In a shell buffer one types

   $ date
   Japanese date
   $ xemacs
   Segmentation fault - core dumped (in what language??)

For a programmer, this English message is enough.  For a user, before
translating it, vendors should try to make it easier to understand as below:
	The program (/usr/local/bin/xemacs) tried to access a memory
	(#xxxxx) which is out of accessible area by the program.
        The core image file `/.../core' is created.  Don't delete it.
	Consult with your system manager.
Then a user can mail this message to a system manager.  Again, it
seems just a waste of time to translate it.

   $ head Thai-file
   thai...
   $ head Russian-file
   ruskij...

   how can Emacs interpret the output of the head commands so that it
   knows to switch coding-systems?  No way - Emacs must be told when to
   switch by the user.  But even then, how could
   $ head Thai-file Japanese-file

   ever work (unless using a multi-lingual coding-system such as iso2022)?

Of course, we should use multilingual-safe coding systems (e.g
coding-system-iso-2022-int).  Then, there's no problem.  Mixture of
ISO-2022-JP, ISO-2022-CN, ISO-2022-KR is also ok.  All of them are
multilingual-safe.  But, Mixture of Japanese-EUC, Chinese-EUC,
ISO8859/1 is a disaster in a multilingual environment.  No local
model help it.


---
Ken'ichi HANDA
handa@etl.go.jp

