Bug#215647: xterm 4.3.0-0pre1v3 i18n
Hi,
> I've been in touch with the upstream XTerm maintainer and I am not going
> to apply this patch.
Then, why do you (you and the upstream) decided so?
I would like to know the reason, so that my patch or idea
can be improved for acceptance or I will be able to think
out some compromise.
> I am unwilling to fork from upstream in this way given the concerns he
> has cited.
If the upstream is changed, you will accept it, OK?
Or, do you have your own idea?
> What is unacceptable about using UXTerm?
I am surprised you don't understand the problem at all.
UXTerm is only for UTF-8. It doesn't support other encodings
such as ISO-8859-1, ISO-8859-15, ISO-8859-2, ISO-8859-3, KOI8-R,
EUC-KR, EUC-JP, GB2312, Big5, and so on so on. Therefore, if
you are really want people to use UXTerm in UTF-8 locales, you
will also prepare "xterm-euc-jp", "xterm-iso-8859-15", "xterm-koi8-r",
and so on so on.
You will think such an idea (preparing "xterm-euc-jp", "xterm-koi8-r",
and so on so on) is silly. I also think. However, UXTerm's concept
is exactly same as this idea, "One software for one encoding".
Several years ago, Debian JP Project was taking this approach to
achieve Japanese support. However, we decided to stop such evil
"fork" and try to develop one unversal software. This idea is
achieved by using a mechanism of "locale".
Do you understand? I have no idea how to explain more easily....
If you really don't undestand what I am saying, Please ask
Mutsumi-san "what is locale?". I imagine you trust him because
you and he are working on Debian X packages for a long time.
---
Tomohiro KUBOTA <kubota@debian.org>
http://www.debian.or.jp/~kubota/
Reply to: