Re: Language Environment Chinese not support, w LANG=zh_CN.GB2312
- To: email@example.com
- Subject: Re: Language Environment Chinese not support, w LANG=zh_CN.GB2312
- From: firstname.lastname@example.org
- Date: Tue, 15 Aug 2000 17:27:42 +0800
- Message-id: <[🔎] 20000815172742.A23675@dumblink>
- In-reply-to: <email@example.com>; from firstname.lastname@example.org on Tue, Aug 15, 2000 at 02:20:23PM +0900
- References: <20000815010404.A1361@thunder> <email@example.com>
sorry for the long quote, but i have forwarded it to Debian ZH
On Tue, Aug 15, 2000 at 02:20:23PM +0900, Stephen J. Turnbull wrote:
> >>>>> "zw" == zw <firstname.lastname@example.org> 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).
i think this is quite reasonable.
zh_CN and zh_CN.GB2312 to Chinese-GB, indeed a de facto already
zh_TW.Big5 (not sure about the case) to Chinese-BIG5
what about zh_CN.GBK? then..
and there is a Big5p ???
| This message was re-posted from email@example.com
| and converted from gb2312 to big5 by an automatic gateway.