Kaixo! On Mon, Mar 31, 2003 at 08:19:28AM +0900, Tomohiro KUBOTA wrote:
> Now brief list of examples. > > - Xmms cannot display non-8bit languages (music titles and so on). Only in the "skin" interface; and that is because it isn't displayed with a real normal font, but with a special one specifically created for the skin. Note that you can see them perfectly on the titles list window (if the titles are written in the same charset as your locale) Note also the the real reason of the problem is that the MP3 format never thought about it; if the MP3 format had allowed for i18n in its text strings we would probably have a better situation than currently (yes, people write localized titles in their MP3, but without any standardization on which charsets to use it is quit problematic) > - Xft/Xft2-based softwares cannot display Japanese and Korean at the > same time Yes they can. > because there are no fonts which contain both of Japanese and Korean. Yes, they are. Not a lot of them, that's true, but they exist. Also, Xft allows to define "virtual fonts" created from a list of other fonts; "Sans", "Serif" and "Monospace" come in standard. If you need such feature to use it with Xft programs that don't use pango, then you can create a ~/.fonts file (I think, not sure right now of the filename) and define some pseudo-fonts you want. Yes, it is a bit complex as you have to hand-edit a config file; but it is a better situation than on other systems where it is simply impossible to do. And note that it isn't possible to do it other way; adding a special case for Japanese is just the same ethno-centrism you are criticizing, as it would only adress one issue, and disregard the needs of other people. What about people neededin Georgian and Russian? or Cyrillic and traditional mongolian? etc. Any solution that targets some specific languages is bad, as it is not global enough. > Pango's approach (changing font according to script) > is needed. Yes, pango (and similar rendering systems) are the best solution; not only for font selection, but also for rendering. And also because it removes completly the problem from the programmers minds; if they use pango they don't need to care at all about i18n issues on displayable text, it will just work. > - 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. Modern WM allow to redefine the fonts they use; even more modern ones use pango or similar techniques. Those that don't will just need to adapt or disappear. Yes, there still are some programs not properly i18n'ed; but they are not the unique choice anymore. > - There are no lightweight web browser like dillo which is i18n-ed. > - FreeType mode of XFree86 Xterm doesn't support doublewidth characters. Even if the font provides them on the 0xff.. range? (if that is the case, then it should be seen as a bug) > - Tcl/Tk's XIM support is unstable even now. (Every time I try to Imho that's not the main problem. Does Tk support devanagari or arabic? > - Text editors which run on terminal rarely supports i18n. Yes, text mode programs are currently the main pool of badly i18n'ed programs. In X11 mode the imporvements on i18n support of the toolkits, have improved the situation a lot. Tk and Motif seems the two main remaining toolkits lacking good i18n, there are also less and less used (I haven't used or even seen a Tk or Motif program for ages). > - Linux console. I heard that kernel version 2.6's console will be > able to display Kanji. However, there would be no input methods. That is mainly because there aren't input methods available > - Ghostscript. It is known that it can handle Japanese by some > trick (by localized version?) but it is too complex and difficult > for me. It involves availability of CID fonts. The problem is the resolution of font names; and Japanese is not the only one with the problem. That is why more and more programs embedd fonts in the postscript documents they produce. > - Text viewer. There is a good software "lv" and I don't understand > why Linux distributors don't use this for default installation. Maybe they don't know it. > - 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. That will improve when it switch to Gtk2 (and pango). Yes, some programs are still having problems, due to technical limitations; but they are aware of the problem and willing to solve it; a quite different situation of programs unaware of the problem or not caring about it. We are still in a transitional process, with still some road to do; but the right road is being taken, I'm very confident in the future. I'm also a bit reluctant to provide much efforts on language-specific solutions (eg: Japanese-only patches for OOo), i think the efforts will be better spent into changing the framework of the application so it gets truly i18n'ed and is able to support *all* languages. Japanese (or any other language) shouldn't be seen as special nor needing special features, but just a particular case of the general i18n case. > - 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. And also zero-width ones. > - Perl doesn't have wcwidth(). I didn't knew. Thanks. > - Text line wrapping. Chinese and Japanese (not Korean) don't use > whitespace between "words". That is also the case of Thai (but Thai does need line wrapping to occur at word boundaries, contrary to Japanese or Chinese. I wonder even if it wouldn't be a good idea to introduce the idea of using zero width space between words when typing in Thai...) > 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. So they are not properly i18n'ed. > I think a certain part of CJK developers' time are wasted > into this. I think it is wasted because the goal is to support CJK, instead of supporting global i18n. font selction, character width, etc. all that should never be implemented at the application level. A good library, like pango, should be used instead; that would solve not only the CJK issues, but also the issues for any other program. And if there are some remaining problems, the use of a specific library allows to solve the problem in the library and have all programs using it corrected automatically; instead of having to change all programs one by one. I understand that Japanese people don't care much about it, and that just Japanese support is good enough; but that also mean that people having their i18n needs too, but not speaking Japanese, are not interested on the efforts being done by Japanese people, and so you end up with a real waste of ressources. I remember there was one a Japanese-specific "less", a Japanese-specific "vim", a Japanese-specific xterm (kterm), etc etc. It would have been much better to make those have a global i18n support. Well, those were other times too, there weren't much other solutions than to do language-specific hacks; unicode use wasn't yet a real possibility. But nowadays things have changed, and it is clearly possible to have a real i18n solution. We are still on the road, but I'm not as pessimistic as you are. -- Ki �a vos v�ye b�n, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese]
pgp00000.pgp
Description: PGP signature
