I have some questions, problems with SCIM, i.e. the SuSE packages from M. Fabian: Intoduction: Since I found no way to install arbitrary RPMs from YaST, I installed the scim with "rpm -ivh scim*" (and I already tried to recover the problems with "rpm --rebuilddb" twice). I upgrade my system with YOU daily, I also downloaded and installed all new SuSE KDE packages. SCIM corrupts YaST software update: 1) The dependencies seem to be corrupt. I installed scim-0.5.1-0. When I start YaST, it complains that all other scim packages (scim-config-gconf, scim-devel, ...) have an unresolved dependency to "scim = 0.5.1-". That should be "scim = 0.5.1-0", I suppose or better "scim >= 0.5.1". 2) What's worse: If I then click "Ignore All" and "Yes, Really" (or how it is translated english, I use german), then I get a dialog "Ignore all changes? Yes/No". This dialog reappears in an endless loop, regardles whether I click "Yes" or "no". I can no more access YaST software update. The only way is to kill YaST (with xkill, respectively Ctrl-Alt-Esc). Now, I cannot use the Grafical/X11 YaST anymore, only the command line YaST! When I deinstall the SCIM packages, YaST works again... Next problem: PinYin: 1) What's "Smart" Chinese Pin Yin? - Is there a "normal" Chinese Pin Yin (preferabely open source)? - Does "Smart" mean "automatic reordering" or "automatic completion"? If so, then I'd prefer a "non smart" Pin Yin... 2) Isn't it allowed to mirror the Pin Yin method in mfabian's home? Get all from the same source would make installation easier. 3) Will a Pin Yin method for SCIM be included in next SuSE? 4) RPM Installation of Smart Pin Yin fails with message: "error: scim-chinese-0.2.3-1ul1.i386.rpm cannot be installed", unfortunately with no reason why it cannot be installed. Any ideas, other experiences? Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
That is a YaST2 bug. The YaST2 developers are already investigating this. Just ignore it for the moment, it doesn't cause any trouble.
This is caused by a bug in Qt 3. To fix it use the qt3-3.1.2-* packages from ftp://ftp.suse.com/pub/people/mfabian/8.2-i586/
It means that you can enter complete words like "nihao" even without indication for tones and they will be converted correctly. The "non smart" Pin Yin methods usually require you to select each character separately and/or indicate the tones with number or something like that.
2) Isn't it allowed to mirror the Pin Yin method in mfabian's home? Get all from the same source would make installation easier.
I don't know, I must ask the author of SCIM.
3) Will a Pin Yin method for SCIM be included in next SuSE?
A non-smart Pin Yin method is inluded in the open source parts of SCIM and in xcin. xcin also has a "smart" Pin Yin method but only for traditional Chinese (I don't know how "smart" and how it compares with the "smart" Pin Yin for SCIM). I don't know whether the "smart" Pin Yin for SCIM can be included, I have to ask the author. Probably not.
I cannot reproduce that, I can install it without problems on SuSE Linux 8.2. -- Mike Fabian <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
(To Mike Fabian: Sorry, I forgot m17n@suse.com in the Cc) Thank you for the quick answer. At first sight, SCIM looks not bad, but also a bit unfinished, compared to xcim, how do you see this? A main advantage is, that the same tool can enter Chinese and Japanese. So even with LANG=zh_CN, I can enter Japanese. Unfortunately, the tool does not start with Ctrl-Space, if I start an application (kwrite) and the locale is de_CH.UTF-8. Why? 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). 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? I can enter Japanese Hira-/ Katakana, but didn't find the Kanji key (any idea where it is?). Other question, more related to SuSE and International Linux in general (but since Mike Fabian works for SuSE, this could be the right place for it): Wouldn't it be the best solution, to migrate the whole Linux and all applications to UTF-8? I think UTF-8 is the most intelligent coding system, since it is efficient for english, only requires two bytes for umlauts in european languages and still allows any language to coexist. So, I'd suggest that SuSE delivers all locales with *.UTF-8 per default. Thank you Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
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
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.
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 <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
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've tried to collect some reasons for switching to UTF-8 here: http://www.suse.de/~mfabian/suse-cjk/unicode.html
So, I'd suggest that SuSE delivers all locales with *.UTF-8 per default.
All locales are available with *.UTF-8 in SuSE Linux. I.e. you set a UTF-8 locale for any language which is supported at all on SuSE Linux. But UTF-8 is not yet the default when you install a SuSE Linux 8.2 from scratch. If you install in Japanese, you will get ja_JP.eucJP by default, if you install in German you will get de_DE@euro by default. If you prefer UTF-8 you have to select this yourself by editing /etc/sysconfig/language after installation. See also http://www.suse.de/~mfabian/suse-cjk/unicode-switch.html I hope UTF-8 locales will soon be made the default after a fresh installation of SuSE Linux. But it's not easy to convince people that this is useful and will help users of all languages to get better support for their native language in the long run. -- Mike Fabian <mfabian@suse.de> 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
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
Apparently most users don't really care. It looks like most users are interested *only* in their native language, few are doing multi-lingual stuff. And it is difficult to convince users who need only one language that even for them UTF-8 is an advantage in the long run. 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. In order to make even users who need only one language accept a switch to UTF-8 without complaining loudly, we need to make the switch as smooth as possible, there should be almost no significant bugs left when using UTF-8 when making UTF-8 the default. Therefore I am very interested in reports of bugs which occur when using UTF-8 locales. By reporting such bugs you can help to get the system working well enough in UTF-8 locales to make a smooth transition possible.
You mean that some config files in /etc/ contain German Umlauts in names of authors and things like that? You are right that this is not nice and should be fixed. Such files should be converted to UTF-8 in the long run. -- Mike Fabian <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 水曜日 30 7月 2003 18:59、Mike FABIAN さんは書きました: ...
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-----
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. Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
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 <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Am Dienstag, 5. August 2003 12.47 schrieben Sie unter "Re: [m17n] Argument for... Re: migrating to UTF-8":
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. Of course it needs some user interaction, i.e. selecting the files / directories and source language. The more smooth conversion of existing files, the more accepted the switch to UTF-8 will be. It could be something similar to the OpenOffice document convertion tool. Regards Marc
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> さんは書きました:
A GUI frontend for convmv might be useful. -- Mike Fabian <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Marc Waeckerlin <Marc.Waeckerlin@siemens.com> 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). -- Linux frechet 2.4.20-4GB #1 Tue Apr 8 13:00:26 UTC 2003 i686 GNU/Linux 2:27pm up 95 days 6:07, 20 users, load average: 0.06, 0.06, 0.07 work : ke@suse.de Karl Eichwalder home : keichwa@gmx.net
Karl Eichwalder <ke@suse.de> さんは書きました:
(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 <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Mike FABIAN <mfabian@suse.de> 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).
Yes. This is what I do. But as long as those issues are not solved, we must not switch to UTF-8 by default. -- Linux frechet 2.4.20-4GB #1 Tue Apr 8 13:00:26 UTC 2003 i686 GNU/Linux 3:21pm up 95 days 7:01, 20 users, load average: 0.20, 0.59, 0.36 work : ke@suse.de Karl Eichwalder home : keichwa@gmx.net
Karl Eichwalder <ke@suse.de> さんは書きました:
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 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 <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。
Mike FABIAN <mfabian@suse.de> writes:
Yes, I agree.
Not using UTF-8 when trying to use several non-English languages is a terrible mess.
Yes. All YaST .po files are UTF-8 encoded and not a single translator complains about this matter of fact any more. -- Linux frechet 2.4.20-4GB #1 Tue Apr 8 13:00:26 UTC 2003 i686 GNU/Linux 6:27pm up 95 days 10:08, 20 users, load average: 0.14, 0.18, 0.28 work : ke@suse.de Karl Eichwalder home : keichwa@gmx.net
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:
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%.
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 <anders@trudheim.com> Trudheim Technology Limited
participants (5)
-
Anders Karlsson
-
Franz Maria Tabei
-
Karl Eichwalder
-
Marc Waeckerlin
-
Mike FABIAN