On Mon, May 14, 2012 at 8:34 PM, Christophe Fergeau <[email protected]> wrote: > Hey, > > I just read the whole thread, and had a few questions, I'm more or > less arbitrarily answering to this email in the thread. > > 2012/5/13 Marguerite Su <[email protected]>: >> and another background knowledge: >> >> fcitx is capable of inputing in Traditional Chinese( IBus don't make >> it even work), Simplified Chinese(as I said, top choice if user has >> choices), Korean( korean Ubuntu users is discussing it in their forums >> just right now.), Vietnamese. >> >> and Japanese is starting in two months after Weng finished his >> graduation paper. it's for GNOME 3.6 right? he invent fcitx-keyboard >> in just two days but solid. can't you wait two month and work on >> other parts of fcitx? > > Did I understand correctly that fcitx does *not* have japanese support > today but that it should be implemented in the coming months? This > would mean that fcitx is not a suitable CJK method now as has been > said throughout the thread, but just a CK input method until Weng does > his magic ;) >
Hi, Christophe, I was a little mix up this thread with the thread on our distribution channel. here are some background in our thread ( not this one ): at first, answer your question: FCITX has J support, mozc. and fcitx has a experimental anthy. so you may ask: why doesn't finish anthy then start mozc? mozc is actually like Linux version of Google Japanese IM. and anthy/canna/skk/wnn are all IM engines in SICM era. so Japanese is like us Chinese, prefer to use mozc as a better choice.(so Chinese nowadays even know mozc.) since FCITX takes users choice as the first priority. they do mozc first. that's something development schedule. then I proposed to select MOZC as Japanese default IM in openSUSE DVD since it's the users' choice. but then maintainers of MOZC told me although mozc is FOSS, it's close development. so it's hard for us(I'm one of mozc maintainer too) to maintain it as a distribution's default IM. that's why we temporarily kept ibus-anthy as default IM in DVD, until Weng finished fcitx-anthy (as you know, J community is tired of IBus-anthy too, too old, too buggy. and they're actively involved in testing now). so it's not FCITX doesn't has J support. but is J community decides not to choose mozc as default IM although they use it on a daily basis and prefer it as better choice. they calls for fcitx-anthy/canna/skk/wnn as default IM, although they'll use mozc as their "actually default IM". :) > This leads to my next question, this thread so far has been focused on > CJK (and Vietnamese in this email). Are they the only languages that > needs input methods? Or are they needed too for arabic, hebrew, > thailandese, ... ? If yes, is fcitx the IM framework to use for these > too? > to be honest, CJK developers build IM framework, others build local engines.(but there are still many much more engines in CJK than others) that's why we focus on CJK here. because as IM, if you can't support CJK to input with hobby and pleasure, even if you success in all other areas, it's hard for you to call yourself as a "framework". and if framework is good, engines catch up more quickly than you think. CNS11643, Compose, Emoji, Ipx-x-sampa, Latex, Rustrad, Thai, Translit-ua, Translit, Viqr, Yawerty. these're all other non-CJK engines IBUS and FCITX both support. is there any engine IBUS supports but FCITX not? no. at least for openSUSE. because I almost package and maintain every IM in openSUSE, SCIM/IBUS/FCITX. and I think openSUSE community is large enough to be considered as a sample. actually SCIM's multi-national support is the best. but you've already had a conclusion why no SCIM. because it does not even ever support GTK3. > Having an IM abstraction framework has been one recommended by some > people in this thread. One concern I have with that is that the > fragmentation we have now will stay, and we'll have the foo IM > framework which will be favoured by people who want to input language > A, the bar IM framework will be the best for language B. In such a > situation, people who want to input both A and B (think A speaker > learning the B language) will not get a satisfying user experience. > but the fragmentation now partially comes to an end. the demand to input both A lang and B lang is now provided by Weng. you can even use fcitx-hangul(K) in one chat conversation, fcitx-pinyin(C) in another. and to talk about IM users' mixed input experience, you must know the languages IM users often use mixed. that's, English and mother language. or vice versa. that can even done by an IM without English support, right? another IM mixed situation is between C and J/K. since every IM has CJK support. that's not a problem. and mixed input between French and German? that's what keyboard do. we just provide fcitx-keyboard(IBUS doesn't have it yet) and fcitx/ibus-m17n. and between south-eastern Asia and CJK? well, thai, vietnamese can be both mixed. and many people in that area even write in C and speak C. between Arabic/Hebrew and CJK? that's a too small user database. that's why we CJK interact with them using English, like to you. that hypothesis is almost based on thin air. there are too few CJK know that language, and that will make a lot of money, they can't be even satisfied by LINUX but MAC. so mixed-up input experience is the same under FCITX and IBUS. if that's what you and GNOME developers are worrying about. :) > Finally, please correct me if I misunderstood, but after reading the > thread, I'm under the impression that ibus and fcitx work equally well > to input CJK "characters" (except for a few ibus bugs that I guess > could be fixed?). What makes fcitx better is that it provides advanced > functionalities such as word autocompletion (+ highly customizable > autocompletion window and online autocompletion lists), "macros" > (short key sequences that will get replaced by a full word), ... My > feeling about these advanced functionalities is that they are not > really CJK-specific, and that this could be useful too when typing > English or French texts, in which case this may be worth integrating > at a higher level instead of having this in the input method? I guess > the answer is that they are different things, but asking does not hurt > ;) > yes, that's useful for western users too. but not the thing DE should do. all they have to do it together at least. reasons: 1. then if KDE doesn't do it, there'll be no IBUS but GBUS...because if a feature has been done by GNOME, then no need to implement it again on IBUS. the what about IBUS user experience on KDE? you know, IBUS is at first a cross-over IM then a DE integration to be. that means IBUS has to implement it again on its own. then GNOME don't need to do it from the beginning, right? 2. even if KDE/GNOME both done this, what about a mobile phone? an openbox? a xfce? > Christophe Hope it helps Marguerite _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
