Chinese support is coming along very nicely.  I think we are almost there.  
There are a few things that still don't work right, however.  This message is 
a little long, and somewhat detailed but will hopefully explain exactly what 
the problems are, and what I did to test them.

When installing in Simplified Chinese, with no other languages, the locale was 
zh_CN, and everything seems to work as expected.  The problems happen when 
using more than one language.

My test install was from the 2003 Sept 19 cooker.  The installation laguage 
was Simplified Chinese.  Additional language support was chosen for:
 Traditional Chinese,
 Korean,
 Japanese,
 American English.
I did NOT choose "Use Unicode by default"
However,
/etc/sysconfig/i18n uses
zh_CN.UTF-8
for everything except LANGUAGE=zh_CN.GB2312:zh_CN:zh
(I mentioned this in bug #5581)

This is the default locale when no ~/.i18n is present in the user's directory.

All tests were using KDE with auto-login.  Restarts of KDE/X typically were 
done with ctrl-alt-backspace to kill X, and X/KDE was automatically 
restarted.

Konsole's default font for all these locales (except Japanese) looks terrible, 
by the way.  It's way too big.  It's the same size no matter what size you 
choose.  To change it you must choose a custom font.  It has always been this 
way with Chinese locales, by the way.

No .i18n:
Initially, chinput would not input characters into Konsole, kwrite, or kedit, 
(Qt apps), but worked with gvim, OpenOffice, gedit.  kedit gives the 
following error when typing with Chinput:
kdecore (KAccel): WARNING: g_bKillAccelOverride set, but received an event 
other than AccelOverride.

zh_CN.UTF-8:
If I ran localedrake, setting my locale to simplified Chinese, it creates the 
.i18n file with zh_CN.UTF-8.  Then, restarting kde, things seemed to work 
fine.  However, if I deleted both ~/.i18n AND ~/.qt/ then it gave the same 
problem again.  My uneducated guess is that whatever creates the ~/.qt/ files 
is looking at ~/.i18n and not at the environment variables (or 
/etc/sysconfig/i18n).  Openoffice used japanese language localization!!  (I 
mentioned this in bug #5583)

zh_TW.UTF-8:
After using localedrake to change my locale to zh_TW.UTF-8, the Mandrake Linux 
initial popup was missing characters.  It is probably using a simplified 
Chinese font.  kwrite would not display traditional characters (it displayed 
empty boxes), but will display simplified characters.  It is probably using a 
simplified font.  kedit, gedit, konsole all worked.  Openoffice still used 
japanese language localization.  Chinput was the IME.

ko_KR.UTF-8:
After using localdrake to change language to Korean (ko_KR.UTF-8), the initial 
Mandrake popup screen was still in chinese with missing characters.  I am 
assuming now that it is the same as when I started - simplified Chinese and 
doesn't change with the locale.  kwrite would not take korean input.  kedit 
worked, but gave this error when pressing the spacebar using the Ami input 
method:
kdecore (KAccel): WARNING: g_bKillAccelOverride set, but received an event 
other than AccelOverride.
Konsole and gedit seem to work fine.

Openoffice localized properly to Korean, but gave the following errors when 
running oowriter:
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or 
directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or 
directory

ja_JP.UTF-8:
After using localedrake to change the language to Japanese, the welcome popup 
still had the same problem.  kwrite would not display the proper fonts when 
entering japanese with kinput2.  It displays boxes for japanese characters.  
The menus localized fine.  kedit, gedit, konsole seemed to work fine.  
Openoffice localized fine.

By the way, strange things happen when you choose japanese language, but korea 
for a country.  I think that kind of problem can be left until later.

In all these cases localedrake language selection choices were in English.

zh_CN:
Now I checked things out again with simplified chinese, but this time removed 
the .UTF-8 encoding from each line in my ~/.i18n file, and deleted the 
ENC=utf8 line.  Now it is only zh_CN

Upon KDE restart, oowriter localized to Japanese!  So I deleted ~/.openoffice 
~/.kde and ~/.qt.  But upon another KDE restart, I again could not use 
Chinput with qt apps.  gedit worked fine.  Openoffice localized fine.  
Running localedrake again, choosing simplified chinese, added the line
ENC=gb
to ~/.i18n

Upon KDE restart everything worked fine. So I guess this ENC=?? line in 
~/.i18n is pretty important for qt

zh_TW:
Using localedrake to change the locale to traditional chinese/taiwan gives 
~/.i18n locale to be zh_TW.  I deleted ~/.openoffice to be safe.  Upon KDE 
restart kwrite still would not display traditional characters.  kedit, gedit, 
openoffice all worked fine.  xcin was the IME.

So I deleted ~/.kde, ~/.qt, and ~/.openoffice and restarted KDE.  This time 
all the KDE menus were missing characters (must be using a simplified font).  
kedit, kwrite would not display traditional characters.  gedit, as always, 
worked fine - menus, IME's, etc.  In changing to Simplified, restarting KDE, 
and then back to Traditional, I get the same behavior as the previous 
paragraph.

Incidentally, using gbrxvt with zh_CN.UTF-8 does not work well.

I hope this report can be useful.  I do not know enough about it all yet to 
know exactly which information is relevant, and which is superfluous.

I am not sure how to report all this into bugzilla, since it's rather broad, 
so I am posting it here.  I hope these issues can be resolved before the 
release.

Chinese (and other language) support has come a long ways, and it is beginning 
to look really good.  It's very nice to be able to switch between languages 
on the same machine.  (Perhaps in six months or a year Mandrake can move 
completely to Unicode and change IME's on the fly.)

vic


Reply via email to