Re: i18n to CJK status (was: Nice changes to po-debconf translation status pages)
Hi,
Martin Quinson <mquinson@ens-lyon.fr> wrote:
(2003/09/12 00:12)
>But debconf works now ok for CJK, doesn't it? Mojibake should now be avoided
>in that system, or did I miss something?
Debconf works well, besides "gnome" frontend. However, for Japanese
characters to be displayed well, the whole system has to work. For
example, debconf runs on terminal and it has to have ability to
display
Japanese. The raw Linux console cannot display Japanese.
Japanese-enabled environment is, thus, like a carefully-built tower.
Any one defect will destroy the whole even if the other parts are
perfect.
>I am sorry, I was not trying to compare anything here. Really sorry if my
>wording was offensive to anyone. It was not intended at all. I only wanted
>to point out that if a japaneese translator were looking for something to
>translate without issues dues to bad i18n, he could have a look at the
>po-debconf messages.
It is ok. :-)
>But I may overestimate the quality of po-debconf for japaneese. What is the
>situation on that point? Your page about mojibake seems to say that the
>situation is solved since debconf 1.3, from 2 months ago.
As saying about debconf, it is significantly good. I am happy that
Debian's core people are generally friendly to Mojibake solution
efforts.
>That is why I do not share your pessimism about the future ability of the
>kernel and XFree86 to support your language. It will take time, but look at
>the debconf example. We managed to gain a well i18ned interface. It took
>much time, and the efforts of Denis to clean up the i18n concerning the
>translation maintainance issues, and yours to clean up the displaying issues
>of non latin languages, but we did manage it, didn't we?
The problem is that, it is partly technical problem but it is partly
political problem. For example, CJK support needs a certain amount of
disk space for fonts or conversion tables. Multibyte character
supports
force us to abondon very fast searching algorithm and so on. Some
people
think such disadvantage is so grave that we should not add CJK support
or we should not have CJK support that is as good quality as European
languages.
>When I look at your page, I see that most window manager can handle
>non-latin alphabet. Mainly, only enlightment fails that, and you have to
>apply a patch to FVWM and FVWM95. What is the current situation on those
>points? Did those patches get integrated? Did the enlightment situation
>improve? What is the situation for metacity and the kde window manager?
>Is there anything I can do to help those point improving? Mainly, who do I
>have to send mails to cry for support?
Several years ago, I wrote many patches for many window managers and
sent them to developers of these window managers. It was the main
difficulty that I have to explain what we need and what my patch does.
I stopped working with window managers because I felt that many of
popular window managers became supporting i18n.
>What is the version number of the first xterm you are speaking about on
>http://www.debian.or.jp/~kubota/mojibake/terminal-emulators.html ?
>I mean, you say that xterm does not work, and then you say that xterm 4.0
>works. That's a bit misleading, isn't it ?
xterm 4.0 supports UTF-8. However, it doesn't support EUC-JP and
other
multibyte encodings which are used in real in Asia. Xfree86-i18n
people
tend to insist that non-UTF-8 encodings will fade soon. However, I
managed to include non-UTF-8 encodings support for xterm 4.3 but it
has several problems. I would like to solve this problem in Debian
package level. (There are two problems, one is default font, another
is rular characters. xterm 4.3 will be in EUC-JP mode when invoked in
EUC-JP locale but the default font is ISO-8859-1, which causes
Mojibake.
The default must be ISO10646-1 font. Another problem is that usage of
rular characters in east Asian multibyte encodings will cause Mojibake
of multibyte characters.)
>I have a question for you, the best expert in CJK I know. What do you think
>of pango(www.pango.org)? It looks to me like a very well thought rendering
>library, not only suited to CJK, but also to bidi and a whole bunch of
>issues I am little aware of. From the package dependencies, it depends
>mainly on glib (which is not that big) and a whole bunch of font rendering
>tools. So, what prevents its use in a console emulator? In fact,
>gnome-terminal and libzvt depend on pango, so I guess it's already done.
Pango is very good. I hope more softwares will adopt it. However,
the problem is that not all softwares can adopt it. For example,
Linux
console would not adopt it. How about xterm? How about KDE? Also,
there are softwares which want to be lightweight. It is not very nice
if Asian people cannot use all of these lightweight softwares. Thus,
Pango is not a perfect solution.
One problem is that Pango is not intended to be used directly from
other
softwares but from other (higher-level) libraries like Gtk. This is
why
Pango doesn't have very comprehensive manuals. However, I know that
the
developer of Xplanet is now trying to use Pango. (I had sent
translated
-- or transliterated -- marker files. This is why I don't remove
xearth
package.)
---
Tomohiro KUBOTA <kubota@debian.org>
Reply to: