[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Fwd:] Re: [alert] i18n may be removed from X11



Hello,

底下是一封来自日本的 I18N hacker 寄给 xcin mailing list 的信,
他长期在 XFree86 I18N 方面贡献心力,而这次 Xlib 中 BIG5 bug 的
部分,他也投住了不少心力帮忙修正 (我们台湾这边似乎还没有贡献
XFree86 I18N 部分的 hacker :-((((

然而,在 XFree86 I18N 的发展方面,他感到极大的压力,因为有很多
声音是希望只做 Unicode only, but not I18N。以下是信件内容,希望
有兴趣的朋友可以看看,有兴趣的朋友也不妨 feedback 给他,或更进
一步地加入 XFree86 I18N 计画 (也许我们还不能马上贡献程式码,但
至少从帮忙测试、吵架开始 :-)) 多多支持这个得来不易的 I18N 开发
平台,以及 BIG5 ready 的平台 :-))

相关详细资讯,请见:

http://www.linux.org.tw/pipermail/xcin/2001-August/002968.html
http://www.linux.org.tw/pipermail/xcin/2001-August/002969.html
http://www.linux.org.tw/pipermail/xcin/2001-September/002974.html
http://www.linux.org.tw/pipermail/xcin/2001-September/002975.html
http://www.linux.org.tw/pipermail/xcin/2001-September/002979.html

XFree86 I18N mailing list archive 请见:

http://www.xfree86.org/pipermail/i18n/


T.H.Hsieh

-- 
| This message was re-posted from debian-chinese-big5@lists.debian.org
| and converted from big5 to gb2312 by an automatic gateway.
>From xcin-admin@linux.org.tw  Wed Sep  5 10:31:06 2001
Return-Path: <xcin-admin@linux.org.tw>
Delivered-To: thhsieh@linux.org.tw
Received: from localhost.localdomain (localhost [127.0.0.1])
	by tlug.sinica.edu.tw (Postfix) with ESMTP
	id 2FBF51E46A; Wed,  5 Sep 2001 10:31:06 +0800 (CST)
Delivered-To: xcin@linux.org.tw
Received: from surfchem0.riken.go.jp (surfchem0.riken.go.jp [134.160.25.161])
	by tlug.sinica.edu.tw (Postfix) with ESMTP
	id 42BC31E40D; Wed,  5 Sep 2001 10:27:00 +0800 (CST)
Received: from surfchem0.riken.go.jp (localhost [127.0.0.1])
	by surfchem0.riken.go.jp (Postfix) with ESMTP
	id 5EF941C203; Wed,  5 Sep 2001 11:31:44 +0900 (JST)
Message-ID: <878zfutlkj.wl@surfchem0.riken.go.jp>
From: Tomohiro KUBOTA <tkubota@riken.go.jp>
To: thhsieh@linux.org.tw, xcin@linux.org.tw
Mail-Reply-To: tkubota@riken.go.jp
In-Reply-To: In your message of "Mon, 3 Sep 2001 22:34:06 +0800"
	<20010903223406.A14501@linux.org.tw>
References: <20010903223406.A14501@linux.org.tw>
User-Agent: Wanderlust/1.1.1 (Purple Rain) EMY/1.13.8 (Tastes differ) FLIM/1.13.2 (Kasanui) APEL/10.2 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: [XCIN] Re: [alert] i18n may be removed from X11
Sender: xcin-admin@linux.org.tw
Errors-To: xcin-admin@linux.org.tw
X-BeenThere: xcin@linux.org.tw
X-Mailman-Version: 2.0.6
Precedence: bulk
Reply-To: xcin@linux.org.tw
List-Help: <mailto:xcin-request@linux.org.tw?subject=help>
List-Post: <mailto:xcin@linux.org.tw>
List-Subscribe: <http://www.linux.org.tw/mailman/listinfo/xcin>,
	<mailto:xcin-request@linux.org.tw?subject=subscribe>
List-Id: <xcin.linux.org.tw>
List-Unsubscribe: <http://www.linux.org.tw/mailman/listinfo/xcin>,
	<mailto:xcin-request@linux.org.tw?subject=unsubscribe>
List-Archive: <http://www.linux.org.tw/pipermail/xcin/>
Date: Wed, 05 Sep 2001 11:31:39 +0900
Status: RO
Content-Length: 6272
Lines: 137

Hi,

At Mon, 3 Sep 2001 22:34:06 +0800,
thhsieh@linux.org.tw wrote:

> However, I cannot agree with his statements. He said that Xlib is the
> wrong place to put so much i18n related stuffs. He said the correct
> place should be the application layer, like gtk+ or qt+. But from my
> point of view, these two libraries are not as universal as Xlib itself.
> Although it might be more and more popular in the future, but in the
> current stage if I want to develop a truely protable X Window application
> accross many flavors of UNIX systems, I will consider Xlib first rare
> than the other toolkits. Xlib is powerful enough and not hard to use.
> So why not use it?

I fully agree with you.  I think their aim is to promote Unicode-based
i18n.  This is what Keith explicitly said.  However, I feel that they
are trying to make mb/wc (multibyte/wide character) approach more
inconvenient and difficult than ever.  Their aim is to achieve UTF-8-
only world where softwares will not need to support other encodings.
This is why they are not interested in encoding conversion while
their Unicode-based way need encoding conversion to support LC_CTYPE
(locale)-encodings.

Such a world might come.  However, their process is opposite.
The right process should be:
 (1) softwares supply choice.
 (2) wait for people to come to use UTF-8.
 (3) long time after nobody use non-UTF-8 encodings,
     softwares will be free from non-UTF-8 encodings support.
Their process is:
 (1) make it difficult to write non-UTF-8-encodings-supporting softwares.
 (2) more softwares will not support non-UTF-8 encodings.
 (3) people will be forced to use UTF-8.
I think this is a wrong way.

> In fact, I don't use gtk+ and qt. My working desktop is neither GNOME nor
> KDE. I don't need them. Many of my daily tools and utilities are based
> on Xlib directly, e.g., rxvt and xcin. Because Xlib have elegant i18n
> support, so they can work fine and totally fit my requirement. So I advocate
> that Xlib should support i18n, because it is a universal base of the UNIX
> GUI plateform.

Yes.  We can easily write LC_CTYPE-supporting software by using Xlib.


> I don't understand Xft very well. So I don't know if it is important
> to have it support i18n or not.

I also don't know well about Xft.  I just know it supplies better
rendering, true type support, 32bit encoding space, and so on.
So, I want to use this for mb/wc-based softwares.  XCIN will also
become look better by using Xft.  However, without mb/wc APIs,
you will have to convert your text into Unicode to use Xft, which
is not elegant.

> But for XTerm, I think it is valuable
> to have it support i18n/locale. My point of view is: Yes, Unicode is
> important to serve as the "base encoding" of the plateform, but it is
> not everything. Many people in their local areas have used their local
> encodings for a long long time. They are comfortable with their encodings.
> There are a lot of stuffs presented with their encodings. We cannot force
> them to switch to another one. And in fact, we don't have to do this.

I fully agree.  All what developers can do is to give a choice to
use UTF-8 or other encodings.  Forcing using UTF-8 is evil.
I imagine European people want to completely switch into UTF-8
because they need Euro sign.  It is true that ISO-8859-15 and so
on have Euro sign.  However, if they need migration into ISO-8859-15,
why not migrate into UTF-8?  I think it is reasonable.  However,
I think it is just a local situation for European (and maybe
American) people.


> Because there is an i18n standard, which let a single program to "speak"
> in many kinds of languages. So in fact I would like to say that a "good"
> application should be independent of the encoding. It will use the
> encoding according to the current environment.

Sure.  I think it is a mandatory of "i18n".  Unicode-hard-wired approach
can supply this true i18n using encoding conversion based on LC_CTYPE
locale.  But what they do is promoting Unicode-hard-wired approach
and (I guess intentionally) forgetting encoding conversion.  This
results in UTF-8-only softwares.  They call this is "i18n".


> The system could choose
> one perticular encoding as its "base encoding", for message transformation
> or unification or blablabla .... But, on the top of the user interface,
> it should present the encoding the users like. Because i18n can accomplish
> this and it is so important, I advocate that it should be implemented
> in the base of the system (libc, Xlib) to serve as a universal plateform,
> such that at least we could develop a *basic* i18n compliant program
> (just basic, fancy is not necessary) directly from the base of the system.

Fully agree.


> Yes. If XTerm works for BIG5, I even don't need rxvt at all (in fact,
> rxvt has minor bugs in BIG5 procession, but I don't have time to trace
> all the bugs).
> 
> Is your code ready now? If yes, I would like to test it in the following
> weekend :-)

Please test Robert's and my patches.  It already works.  However,
also fot XTerm, they insist to be "free from encoding conversion."
I am not sure whether I can persuade them to support LC_CTYPE.

  -- * -- * --

BTW, I'd like to know how Chinese people think about CJK Han Unification
of Unicode.  You know, some of unified Hanji are strictly identical
and others are not.  Some of these "different but unified" characters
are not acceptable (or even unreadable) for Japanese people.  Please
refer the following page:

    http://www.debian.or.jp/~kubota/unicode-unihan.html

Thus, I think some mechanism is needed to distinguish unified
characters from C, J, K, and T.  I discussed on this problem in
i18n@xfree86 but they said:
 (1) the mechanism should be too complex for plain text.
 (2) Only Japanese people stick to this problem.  Thus, simply
     using Japanese font as a default can solve this problem.
Though I, a native Japanese speaker, can accept (2), but I imagine
Chinese and Korean people may not.  How do you think?

---
Tomohiro KUBOTA <kubota@debian.org>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/

_______________________________________________
XCIN mailing list
XCIN@linux.org.tw
http://www.linux.org.tw/mailman/listinfo/xcin

-- 
| This message was re-posted from debian-chinese-big5@lists.debian.org
| and converted from big5 to gb2312 by an automatic gateway.

Reply to: