Marc Waeckerlin さんは書きました:

At first sight, SCIM looks not bad, but also a bit unfinished, compared to xcim, how do you see this?

I cannot really give a meaningful comparison of xcin and SCIM because I don't speak Chinese. I can test whether they appear to work but that's about it.

A main advantage is, that the same tool can enter Chinese and Japanese. So even with LANG=zh_CN, I can enter Japanese.

Only Hiragana and Katakana, i.e. the usefulness is rather limited.

Unfortunately, the tool does not start with Ctrl-Space, if I start an application (kwrite) and the locale is de_CH.UTF-8. Why?

It's always[1] like that with XIM. LC_CTYPE needs to be set to the language you want to input. I.e. you need something like LANG=de_CH.UTF-8 LC_CTYPE=zh_CN.UTF-8

I'd be glad if I could work entirely in my Swiss environment and just occasionally switch on the SCIM to enter some Chinese (or Japanese or Korean).

LC_CTYPE=zh_CN.UTF-8 doesn't hurt, you should note no differences at all compared to LC_CTYPE=de_CH.UTF-8 *except* that simplified Chinese input via XIM get's enabled.

Am Freitag, 25. Juli 2003 15.01 schrieben Sie unter "Re: [m17n] Poblems with scim":

...

A non-smart Pin Yin method is included in the open source parts of SCIM

I wasn't able to find it. Where is it, or how is it activated?

Sorry, you are right, apparently scim-tables-zh doesn't contain any Pin Yin input method: mfabian@gregory:~$ rpm -ql scim-tables-zh /usr/share/doc/packages/scim-tables-zh /usr/share/doc/packages/scim-tables-zh/README-Erbi.txt /usr/share/scim /usr/share/scim/tables /usr/share/scim/tables/CangJie.bin /usr/share/scim/tables/Cantonese.bin /usr/share/scim/tables/Erbi.bin /usr/share/scim/tables/Jyutping.bin /usr/share/scim/tables/Simplex.bin /usr/share/scim/tables/Wubi.bin /usr/share/scim/tables/Ziranma.bin mfabian@gregory:~$ I believe Jyutping is a phonetic input method for Cantonese, and Cangjie and Wubi are radikal based input methods. I have no idea at all about the others.

I can enter Japanese Hira-/ Katakana, but didn't find the Kanji key (any idea where it is?).

There is not conversion to Kanji for Japanese implemented in SCIM. Footnotes: [1] well, not always: mlterm supports runtime switching of input methods, i.e. you can still enable SCIM in mlterm after starting mlterm with LC_CTYPE=zh_CN.UTF-8. Yudit supports this as well. But this is a rare feature. IIIMF, the successor of XIM is supposed to improve this situation and allow runtime switching of input methods always. -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Am Freitag, 25. Juli 2003 21.26 schrieben Sie unter "migrating to UTF-8 (was: SCIM in general and "non smart" Pinyin)":

Yes, I believe as well that migrating to UTF-8 as fast as possible is a good idea. It makes multilingual use of Linux much easier.

I hope, you can convince SuSE ASAP. Especially since SuSE is internationally distributed.

If you prefer UTF-8 you have to select this yourself by editing /etc/sysconfig/language after installation. See also

That's what I did. But unfortunaltely, there are some Texts, that engulf the german Umlauts (because the texts are not UTF-8). As long as the system does not support UTF-8 per default, the system is not sound. BTW: Isn't RedHat entirely based on UTF-8? Initially, the good german support was my reason to choose SuSE... Regards Marc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 水曜日 30 7月 2003 18:59、Mike FABIAN さんは書きました: ...

I believe this is really the case, even for single language users it is useful. I tried to explain why it is a good idea to use Unicode in

http://www.suse.de/~mfabian/suse-cjk/unicode-about.html

if you have ideas how to make this more convincing, please tell me.

do You know about "open theory"? if You put Your text there, people can participate and add comments to every paragraph. http://www.opentheory.org/index.phtml?lang=en ciao, franz - -- http://www.widerspruch.at http://www.oekonux.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/KRJhr20A4SfeSRgRAnyNAKCpwZ49wyDQvWR63SvYA4VuaMOH+gCghi/4 cBIbZw/NusMzaXUzgeAHkO0= =YV1t -----END PGP SIGNATURE-----

Marc Waeckerlin さんは書きました:

Am Mittwoch, 30. Juli 2003 18.59 schrieben Sie unter "Re: migrating to UTF-8":

...

if you have ideas how to make this more convincing, please tell me.

In my opinion, the best argument is: There is no disadvantage in using UTF-8 (except that you have to migrate existing files and file names) for single language users, but there are great advantages for all multilingual users.

Of course, if SuSE switches to UTF-8 as default, all applications should be carefully tested. Also carfully tested migration tools should be supplied and an automatic migration should be suggested in YaST.

I believe an automatic migration of all your old file contents is not really feasible. It's not really possible to find out reliably which files should be converted and which should not be converted. Attempting to do that automatically risks data corruption. For file names see convmv: http://www.suse.de/~mfabian/suse-cjk/encodings-file-names.html -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Marc Waeckerlin さんは書きました:

Am Dienstag, 5. August 2003 12.47 schrieben Sie unter "Re: [m17n] Argument for... Re: migrating to UTF-8":

...

I believe an automatic migration of all your old file contents is not really feasible. It's not really possible to find out reliably which files should be converted and which should not be converted. Attempting to do that automatically risks data corruption.

The users that come from Windows are used to use umlauts even in filenames and they don't read documentations nor can they handle with command line. That's why I think a GUI convertion assistant is absolutely required.

A GUI frontend for convmv might be useful. -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Karl Eichwalder さんは書きました:

Marc Waeckerlin writes:

...

As long as the system does not support UTF-8 per default, the system is not sound.

Some programs are still not ready for UTF-8 (e.g., Emacs, xfig, and man).

(X)Emacs work OK for some subsets of UTF-8, i.e. they work good enough for the stuff I normally need (German and Japanese in UTF-8). 'man' also works reasonably well. man-pages for languages where the legacy encoding was ISO-8859-1 (German, French, ...) are already handled correctly by default in the respective UTF-8 locales (de_DE.UTF-8, fr_FR.UTF-8, ...). For other languages like Czech (legacy encoding ISO-8859-2) and Japanese (legacy encoding EUC-JP), I have workarounds in the SuSE groff package since SuSE 8.1 already. These are only (ugly) workarounds, but they are effective and I didn't notice any problems when displaying Japanese man pages for a long time already. If you find any problems, please report them. xfig has problems in UTF-8 locales, but that is no valid reason not to use UTF-8 by default, in my opinion it is much better to start such legacy applications which do not yet have proper UTF-8 support explicitely in a legacy locale like LC_ALL=ja_JP.eucJP xfig until they are fixed. -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Karl Eichwalder さんは書きました:

Mike FABIAN writes:

...

(X)Emacs work OK for some subsets of UTF-8, i.e. they work good enough for the stuff I normally need (German and Japanese in UTF-8).

Yes, but with Emacs it is easily possible to break UTF-8 files using cut-and-paste under X. Emacs 21.3 and Emacs from CVS are quite good concerning UTF-8 (but I don't use CJK langauges, though).

We have bug reports concerning cut and paste problems for (X)Emacs in de_DE@euro as well. Overall I think that (X)Emacs work at least as good in de_DE.UTF-8 as they work in de_DE@euro already.

...

xfig has problems in UTF-8 locales, but that is no valid reason not to use UTF-8 by default, in my opinion it is much better to start such legacy applications which do not yet have proper UTF-8 support explicitely in a legacy locale like

LC_ALL=ja_JP.eucJP xfig

until they are fixed.

Yes. This is what I do. But as long as those issues are not solved, we must not switch to UTF-8 by default.

If we wait until all old applications are fixed for UTF-8 we will never be able to switch. And the benefits of switching are far greater than the disadvantages. Starting such an old application like xfig with a wrapper script is a minor inconvenience. And there are not many of such applications left which are still commonly used anyway. Not using UTF-8 when trying to use several non-English languages is a terrible mess. -- Mike Fabian http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Apologies for chipping in. I've followed the discussion and find it quite interesting. On Fri, 2003-08-01 at 14:58, Mike FABIAN wrote:

We have bug reports concerning cut and paste problems for (X)Emacs in de_DE@euro as well. Overall I think that (X)Emacs work at least as good in de_DE.UTF-8 as they work in de_DE@euro already.

If the major applications people use work as well in UTF8 as they do in 'normal' locales, there is nothing really stopping a change-over, is there?

If we wait until all old applications are fixed for UTF-8 we will never be able to switch.

If the official line would be that the switch happens when all applications are ready, you can give up ever changing over right now. If the official line is to change at soonest convenient and technically feasible point, then the time is probably here to change over right now.

And the benefits of switching are far greater than the disadvantages.

Ack 100%.

Starting such an old application like xfig with a wrapper script is a minor inconvenience. And there are not many of such applications left which are still commonly used anyway.

The few that exists should not be a show-stopper.

Not using UTF-8 when trying to use several non-English languages is a terrible mess.

Is there a time-line for enabling UTF8 in SuSE as the default locale, like is it scheduled for the next version or the one after that? (8.3 or 9.0?) Regards, -- Anders Karlsson Trudheim Technology Limited