On Sat, 29 Mar 2003, Pablo Saratxaga wrote: > On Sun, Mar 30, 2003 at 12:37:49AM +0900, Tomohiro KUBOTA wrote: > > > However, I am often annoyed by people who think supporting European > > languages is more important than supporting Asian languages
I don't think you meant that way, but I found it very annoying that some people and software use 'Asia' to mean only CJK. One prominent example is Sun's Staroffice and Openoffice. That's almost an insult to people of Indian subcontinent, Southeast Asia, Central Asia, and Southwest Asia. > Are there such people? There might be some, but as I wrote in my response to Kubota-san, I18N-mind is much more widely spread than 5 years ago and I agree to your assesment of I18N in Linux below. > 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. > > How should I call such people? I know they are never "racists" in its > > original meaning. > > "ethno-centrist" is the word you are looking for I suppose. If they're from Western Europe, 'Western-Eurocentric' :-) > Tell me about one single current major program/project that doesn't have > i18n support (maybe there are, and I'm just not aware of it (probably because > a modern software without i18n support is not worth it in my eyes). One example is mkisofs in cdrtools. It's 'single-byte-centric' and the project maintainer has yet to accept a patch for multibyte support (including UTF-8). Sonner or later, I'll send him a new patch in such a form that he find it hard to leave it aside. Other examples include fmt, and other textutils, mc (it sorta works, but needs a lot of work to be fully I18Nized and UTF-8 friendly), lynx (one MIME charset at a time is well supported, but it needs multilingual ability as found in w3m-m17n. I hope major linux distros include w3m-m17n instead of plain w3m) and Pine (it works fine for a single MIME charset, but not yet multilingual and screen handling is single-byte centric. My UTF-8 patch solves only a small subset of these problems). 'less' still needs more work (Owen's patch is better than my patch that went into less 37x.) Some terminal emulators and terminal-based/-like programs need to pay more attention to East Asian Width (UTR #1? ). xterm has an option '-cjk-width' and other programs need a similar option/feature. Vim needs this. Its current column width cacluation routine is not based on wcwidth(). (I'll plan to fix this soon. It's very easy and Markus's wcwidth and wcwidth_cjk come very handy. It's better to use them than wcwidth from glibc which is locale-dependent.) gtk2 font selection widget should optionally offer a way to designate a *separate* 'monospace' font for 'double width'. So does Qt's font selection widget. It's naive to believe that fontconfig and pango can do the magic for this case as evidenced by the fact that MS Word under MS Windows even with equivalents of fontconfig and pango lets users select East Asian font separately. Full-screen text based programs need to be linked against ncursesw rather than ncurses or slang (how good is slang's UTF-8 and multibyte support?) and delegate as many screen-manipulating tasks to ncursesw as possible . When used with mutt, ncursesw appears to work well under UTF-8 locale. Jungshik -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
