Re: Language Environment Chinese not support, w LANG=zh_CN.GB2312

[zw@zhaoway.com]

sorry for the long quote, but i have forwarded it to Debian ZH
and i18n-chinese@egroups.com, 

On Tue, Aug 15, 2000 at 02:20:23PM +0900, Stephen J. Turnbull wrote:
> >>>>> "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).

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 debian-chinese-gb@lists.debian.org
| and converted from gb2312 to big5 by an automatic gateway.