Hi, From: Pablo Saratxaga <[EMAIL PROTECTED]> Subject: Re: supporting XIM Date: Sat, 29 Mar 2003 17:13:02 +0100
> > However, I am often annoyed by people who think supporting European > > languages is more important than supporting Asian languages > > Are there such people? I think there are no people who explicitly think so. However, how do you think if a developer think, for example, italic character support for 8bit characters is very important while he/she don't won't understand importance of multibyte support? > Note also that, currently, I do'nt agree with you that i18n of programs > is low; to the contrary, the majority of programs have good to > very good i18n support. > Those that still doesn't have are of two kinds: > - small programs/projects, not very used, and not i18n mainly by > ignorance of the problem by the authors, but that is a thign that > can be solved. > - old programs/projects, in some cases stalled, abandonned or orphaned > for years; there is no much hope to achiueve i18n for them, but > there is no much hope about their survival either. At first, I think translation (gettextization) is relatively unimportant area of i18n. Of course I don't say that we should not do that, but imagine two word processors: - a word processor whose menus and messages are translated into your native language but cannot input/display text in your native language - a word processor whose menus and messages are in English but can input/display/print text in your native language Which is better? The first one is completely unusable and the second one is unconveinent but usable. Now brief list of examples. - Xmms cannot display non-8bit languages (music titles and so on). - Xft/Xft2-based softwares cannot display Japanese and Korean at the same time while Xft and Xft2 are UTF-8-based, because there are no fonts which contain both of Japanese and Korean. This should not be regarded as a font-side problem, because (1) font-style principle is different among scripts (there are no "courier" font for Japanese) and (2) such fonts need developers who can design letters all over the world. Pango's approach (changing font according to script) is needed. Thus, Xft/Xft2 should not be used directly from end- user application unless this problem is handled properly. There are even FreeType-based softwares (like xplanet beta version), which forces non-Latin-1 people to choose proper font (otherwise Mojibake occurs). - There are many window managers which support "themes". Even if the window manager itself is already i18n-ed, some themes cannot display non-Latin-1 languages. This occurs in two cases: (1) when the theme specifies a font name (it is very likely) or (2) when the theme supplies an origial font. - There are no lightweight web browser like dillo which is i18n-ed. - FreeType mode of XFree86 Xterm doesn't support doublewidth characters. - Tcl/Tk's XIM support is unstable even now. (Every time I try to input Japanese, it sticks). When I read Tcl/Tk's roadmap in version 8.0 age, I was really surprised that XIM support (essential for CJK, as you know) is very low priority. - Text editors which run on terminal rarely supports i18n. Emacs and Vim are precious exceptions. - Xterm. Its terminfo "enacs", "smacs", and "rmacs" (used for line- drawing characters) assumes that G1 is not used and GR is G2, which conflicts with EUC encodings. This causes usage of line-drawing causes all Hiragana/Katakana/Kanji to mojibake. I proposed to change definition of these terminfo items but it wasn't accepted because of vague uneasiness on compatibility. I have not read any concrete compatibility problem. - Xterm. It can automatically use UTF-8 mode and luit depending on locale. However, though it automatically use UTF-8 mode, it cannot use iso10646-1 font automatically. My patch to do this (and the idea itself) was rejected. Usage of iso10646-1 font as default was also rejected. - Linux console. I heard that kernel version 2.6's console will be able to display Kanji. However, there would be no input methods. - Ghostscript. It is known that it can handle Japanese by some trick (by localized version?) but it is too complex and difficult for me. - Text viewer. There is a good software "lv" and I don't understand why Linux distributors don't use this for default installation. - Even OpenOffice.org 1.0 cannot display Japanese even with Japanese add-on package. I have to configure some font substitution. Note that this can be done only after installation, thus I cannot read (translated) messages during installation at all. - Curses-basd softwares. They must not assume number of bytes is same as number of columns or number of characters. Doublewidth and combining character support is needed. - Perl doesn't have wcwidth(). - Text line wrapping. Chinese and Japanese (not Korean) don't use whitespace between "words". I feel that CJK people everytime have to keep a watch on softwares which are already i18n-ed, because i18n support of such softwares are sometimes broken when new versions are released. (Xedit often changes its status (can use XIM or cannot use XIM). What happens?) This is fatal if translation is already supplied (like OpenOffice.org case). I think a certain part of CJK developers' time are wasted into this. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
