[turnbull@sk.tsukuba.ac.jp: Language Environment Chinese not support, w LANG=zh_CN.GB2312]
Please help to resolve. Thanks!
----- Forwarded message from "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> -----
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Tue, 15 Aug 2000 14:20:23 +0900 (JST)
To: zw@zhaoway.com
Cc: xemacs-mule@xemacs.org
Subject: Language Environment Chinese not support, w LANG=zh_CN.GB2312
>>>>> "zw" == zw <zw@zhaoway.com> writes:
zw> when i run xemacs-mule (debian woody newest) with env
zw> LANG=zh_CN.GB2312, xemacs says before parsing .emacs that
zw> "Language environment Chinese not supported",
I believe that the problem is that due to the differences between
Chinese and Taiwanese usages, we should distinguish between zh_CN, and
zh_TW. There is no single Chinese environment defined; instead
Chinese-GB and Chinese-Big5 are defined. The auto-initialization
should select the Chinese-GB environment in the former case, and the
Chinese-BIG5 environment in the latter.
Do you agree with this analysis? (The patch selected below does work,
in the sense that there is no error and the EUC/GB environment is
selected. I don't know Chinese, so I can't confirm more than that.)
Do you have a suggestion about what to do about the situation where
"LANG=zh" with no regional modifier? We could force zh_CN, force
zh_TW, or ignore it. I'm inclined to ignore it.
I also have to think about what to do in the case LANG=zh_TW, since
this could be either Big5 or CNS 11643. I realize you're probably not
the right person to ask, but do you agree that for zh_TW defaulting
the encoding to Big5 is correct unless LANG=zh_TW.CNS11643? (Since I
don't know of any Taiwanese beta testers. :-( )
Unfortunately this bug occurs in the Mule initialization process which
is dumped into the binary xemacs. The only way at present that we can
allow choice is to ignore ambiguous values of LANG and force the user
to make the choice in .emacs. Forcing is not irrevocable, since the
user could override in .emacs in any case. But it could be annoying.
To (temporarily) fix it you could apply the following patch to
lisp/mule/mule-init.el, remove lisp/mule/mule-init.elc and src/xemacs,
and `make xemacs'. If you agree that this is the correct approach to
detecting the two kinds of Chinese, I will submit the patch to
XEmacs.org and eventually it will find its way into the Debian
distribution. However, it is not possible to fix your local
installation without rebuilding XEmacs as far as I know.
Index: lisp/mule/mule-init.el
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/mule/mule-init.el,v
retrieving revision 1.12
diff -u -r1.12 mule-init.el
--- mule-init.el 1999/02/17 13:59:34 1.12
+++ mule-init.el 2000/08/15 04:57:45
@@ -76,7 +76,8 @@
(defvar auto-language-alist
'(("^ja" . "Japanese")
- ("^zh" . "Chinese")
+ ("^zh_CN" . "Chinese-GB")
+ ("^zh_TW" . "Chinese-BIG5")
("^ko" . "Korean"))
"Alist of LANG patterns vs. corresponding language environment.
Each element looks like (REGEXP . LANGUAGE-ENVIRONMENT).
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
----- End forwarded message -----
--
| This message was re-posted from debian-chinese-gb@lists.debian.org
| and converted from gb2312 to big5 by an automatic gateway.
Reply to: