Thank you for responding. Please forgive my ignorance on these topics. I am still learning. . .
> How do you want to be able to support Chinese and some other language > without using unicode? Well, I guess I don't know, and perhaps using UTF-8 is reasonable. Things seem to work, for the most part. I don't know how things like samba, nfs, FAT partitions, and FAT usb drives work, though, if they are using Chinese Windows 98, or a zh_CN locale (GB encoded) nfs server. If conversion happens automatically, then there should not be any problems. > "It's not a bug it's a featuer" :) > It is the wanted and expected behaviour, when choosing two (or more) > languages using incompatible character sets, the only choices are to use > unicode, or to be unable to use those languages together. Ok, perhaps we should mark bug #5581 as invalid, then. > > 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. > > The font used isn't the same as per KDE menus and buttons ? No. I can send a screenshot if you want. If you change your locale to zh_CN, or zh_CN.UTF-8 does it look ok to you? > > 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. > > In ~/.qt/qtrc do you have a section [General] with > XIMInputStyle = "Over The Spot" > ? I created a new default user - no .i18n file, and in ~/.qt/qtrc there is NO XIMInputStyle line. > (maybe DrakX doesn't create that file when creating a user?) > > > My uneducated guess is that whatever creates the ~/.qt/ files > > localedrake does. I do not know where the problem lies, but the XIMInputStyle line does not exist if there is no .i18n file. The ~/.qt/qtrc file does exist. This problem definitely needs to be fixed. It is like this for all new users I create. > > Openoffice used japanese language localization!! (I > > what is the output of "locale" command ? > OOo follows the value of LC_CTYPE > unless a specific OpenOffice language setting is defined everything is zh_CN.UTF-8, including LC_CTYPE. I think OOo doesn't understand the .UTF-8 part. IF my locale is zh_CN, then OOo localizes properly. If I use .UTF-8, then OOo uses Japanese localization for both zh_CN.UTF-8 and zh_TW.UTF-8 OOo version was 1.1.0-rc4.2mdk for OOo, l10n, and help files for each language. > > 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 > > Was fonts-ttf-big5 installed ? Yes, but I was referring to mandrakegalaxy. I am convinced now that it was using simplified Chinese. > What do you call the "initial popup screen" ? > The display manager where you log in? > kdm (and mdkkdm) use the language defined in the global config > file /usr/share/config/kdm/kdmrc > So, you need to change the global language setting (launch localedrake > as root), not simply the user setting. What I meant was the mandrakegalaxy. It's always the same each time, and doesn't display properly in locales other than zh_CN > > 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: > > > 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 > > That happens when the locale is not installed. > What is the output of "locale" ? (it should be ko_KR or ko_KR.UTF-8 for > Korean locale). > Is locales-ko installed ? it is ko_KR.UTF-8, and locales-ko-2.3.2-5 is installed. /usr/share/locale/ko_KR.UTF-8/ exists with files in it. > > ja_JP.UTF-8: > > still had the same problem. kwrite would not display the proper fonts > > when entering japanese with kinput2. It displays boxes for japanese > > characters. > > I don't have that problem; what version of kwrite ? kwrite: 4.1 kde: 3.1.3 qt: 3.1.2 > Kwrite seems to use its own display code, different of the rest of KDE, > and buged :( I think you are right that something is wrong with kwrite. Kwrite would not display the correct font for traditional and for chinese characters. It seems to be stuck in simplified chinese mode for me. Unfortunately, it seems to be the default text editor. > fontconfig gives information on charset coverage and language coverage for > each font; so maybe a future version of Qt could use that info to better > choose the fonts (or even better: try to find missing glyphs from other > fonts, as gtk does; which would take away the need to provide a default > font) I thought Qt was already able to do that. > Indeed, the only real CJK-specific problem in all you reported is > the bug of kwrite with ami; and the fact that Qt should better default > to Over the Spot, to be safer when conection to an XIM without good > On the Spot support is done. > All the rest is not CJK specific (they are font problems in Qt and kwrite, > and lack of proper UTF-8 support on some few old programs) Ok, I appreciate that. I am feeling better about the state of things, then. It was hard to know this, though, because with my first tests, everything was broken. One thing, though, that should be thought about is the fact that when a Chinese speaker chooses a console window, they will most likely choose the rxvt because the name is something like "Simplified Chinese terminal" or "Traditional Chinese terminal", and they know they want that, but it will not work with UTF-8. Most users would have no idea why. I don't know what could be done help this except to maybe change the names (in Chinese) to be GB terminal and Big-5 terminal or something like that. It may be more confusing to non-technical people, but it would be unambiguous. > The IME switching problem will take more time I'm affraid... > (with gtk it would maybe be possible to implement the same behaviour as > yudit, as gtk provides a way to develop gtk-specific input methods; for Qt > I don't know). Maybe something like IIIMF could be used in the future. I heard it is steadily progressing. Thank you for the hard work you are putting into this. I am very happy with the way things are looking. vic
