Re: supporting XIM

[Jungshik Shin]

Tomohiro KUBOTA wrote:

- 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.
 

I agree with you on this point. That's why I compared the status of KDE 
in 1999-2000
with that in 2003. Back in 1999-2000, KDE/Qt people thought that 
translating messsages
is I18N, but they don't do any more and KDE/Qt supports 'genuine I18N' 
much better now.

Now brief list of examples.

- Xmms cannot display non-8bit languages (music titles and so on).

      Are you sure? It CAN display Chinese/Japanese/ Korean id3 v1  tag 
as long as
the codeset of  the current locale is the codeset used in ID3 v1 tag.  
The problem with mp3
and id3 v1 tag is that id3 v1 tag doesn't have any means of  labelling 
the codeset used
in the tag. Therefore, you can't  view Russian id3 v1 tags (in KOI8-R ) 
and Korean
id3 v1 tags in EUC-KR in a *single* xmms session.  To work around this,
there are three ways ( we discussed this issue a couple of months agon
on this list):

    1. convert all id3 v1 tags in your mp3 collection to UTF-8
     2. Give up the idea and launch two separate xmms under two 
different locales
         % LC_ALL=ru_RU  xmms &
         % LC_ALL=ko_KR xmms &

- 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)
    You can use 'alias' in fontconfig  if some programs use 'Courier' 
or 'Arial' instead
of generic fonts names like 'monospace', 'serif', 'sansserif', and so 
forth.

  and (2) such fonts need developers who can design letters all over
  the world.  Pango's approach (changing font according to script)
  is needed.  

 Well,  if Xft2 is used along with fontconfig, there's no such problem. 




- 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.
 In the first case, you can work around the problem rather easily with 
'alias' mechanism
in fontconfig.

 

- There are no lightweight web browser like dillo which is i18n-ed.

    I think that w3m-m17n is an excellent lightweight browser that 
supports I18N well.

- FreeType mode of XFree86 Xterm doesn't support doublewidth characters.

  Well, it sort of does. Anyway, I submitted a patch to Thomas and I expect
he'll apply it sooner or later. After that, I'll add '-faw' option 
(similar to '-fw' option).
  

- 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's not that hard. Most changes made by gs-cjk project have been 
folded back to
the upstream gs.  Moreover, modern Linux distros now come with ghostscript
with all the 'hard' jobs(configurations) already done for you and you 
don't have much to do.

- 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.
 OpenOffice seems to have a serious problem when run under UTF-8 
locale. Under locales
with legacy codesets, it more or less works, but Unix/X11 version 
appears to have to be
overhauled with a new client-based font framework (fontconfig, Xft, 
pango). Its use
of the old server-side font technology makes it slow and ugly.



- 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.
  As I mentioned already,   this is where we need a lot of  works. 
There are a few programs
that work well, though when linked against ncursesw.  One prominent 
example is
mutt.

 

- Perl doesn't have wcwidth().

  Well, there are a couple of Perl packages that let you  query various 
Unicode character
properties so that it should be trivial to write your own wcwidth() if 
somebody
hasn't done it already.

- Text line wrapping.  Chinese and Japanese (not Korean) don't use
  whitespace between "words".
 

 I already mentioned this issue. Programs like 'fmt' has to be 
modified, but there's already
an alternative to 'fmt' that supports Unicod linebreaking algorithm.

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. 

  This is probably true, but I wouldn't complain as much as you do 
because CJ(K) people
have a much better luck than a lot of people in 
South/SouthEast/SouthWest Asia.

Jungshik





--
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/