From ankit at redhat.com Wed Apr 1 11:46:51 2009 From: ankit at redhat.com (Ankitkumar Rameshchandra Patel) Date: Wed, 01 Apr 2009 17:16:51 +0530 Subject: iBus translations submission! Message-ID: <49D3542B.3010505@redhat.com> Hi all, Because of some technical issue, discussed here: https://fedorahosted.org/fedora-infrastructure/ticket/1294, submission of iBus (the new input method for Fedora 11) translation can't be done through Transifex. Since the freeze date for translations is approaching, you can send your translations for iBus, to shawn.p.huang at gmail com , as mentioned here: https://translate.fedoraproject.org/tx/projects/ibus/master/ (Thanks Sandeep for informing me about this). I am not sure about, whether status updated status will be reflected or not, after shawn submits your translation file to the github repository! Thanks! -- Regards, Ankit Patel http://www.indianoss.org/ From piotrdrag at gmail.com Wed Apr 1 17:27:44 2009 From: piotrdrag at gmail.com (=?UTF-8?B?UGlvdHIgRHLEhWc=?=) Date: Wed, 01 Apr 2009 19:27:44 +0200 Subject: iBus translations submission! In-Reply-To: <5eb2c9220904010455s71f574bapd45daf0a710c636@mail.gmail.com> References: <49D3542B.3010505@redhat.com> <5eb2c9220904010455s71f574bapd45daf0a710c636@mail.gmail.com> Message-ID: <49D3A410.3020503@gmail.com> Xavier Conde Rueda pisze: > thanks for the info, we'll have time to submit a translation. However, > I would like to know why a core module like this is not in fedora-11 > but in various. In order to priorize translations, I would like to > know which translations are "core" and which isn't. Why packagekit, > rpm, yum, iBus and pulseaudio - among others - are not under the > fedora-11 category? I think that this category should group all > packages that are installed by default and are part of the system. > All of these are external modules, independent from Fedora. In fedora-11-like categories we have only projects that we are upstream of. -- Piotr Dr?g http://raven.pmail.pl From dimitris at glezos.com Wed Apr 1 17:31:12 2009 From: dimitris at glezos.com (Dimitris Glezos) Date: Wed, 1 Apr 2009 19:31:12 +0200 Subject: iBus translations submission! In-Reply-To: <49D3A410.3020503@gmail.com> References: <49D3542B.3010505@redhat.com> <5eb2c9220904010455s71f574bapd45daf0a710c636@mail.gmail.com> <49D3A410.3020503@gmail.com> Message-ID: <6d4237680904011031t4d56bc12s459490344f398a1b@mail.gmail.com> On Wed, Apr 1, 2009 at 7:27 PM, Piotr Dr?g wrote: > All of these are external modules, independent from Fedora. In > fedora-11-like categories we have only projects that we are upstream of. It's worth noting that with Transifex 0.5, creating and maintaining Collections and Releases is easier, so we could have more releases and components included in >1 of them. -? -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From noriko at redhat.com Wed Apr 1 23:34:07 2009 From: noriko at redhat.com (Noriko Mizumoto) Date: Thu, 02 Apr 2009 09:34:07 +1000 Subject: iBus translations submission! In-Reply-To: <49D3A410.3020503@gmail.com> References: <49D3542B.3010505@redhat.com> <5eb2c9220904010455s71f574bapd45daf0a710c636@mail.gmail.com> <49D3A410.3020503@gmail.com> Message-ID: <49D3F9EF.6010301@redhat.com> Piotr Dr?g ????????: > Xavier Conde Rueda pisze: >> thanks for the info, we'll have time to submit a translation. However, >> I would like to know why a core module like this is not in fedora-11 >> but in various. In order to priorize translations, I would like to >> know which translations are "core" and which isn't. Why packagekit, >> rpm, yum, iBus and pulseaudio - among others - are not under the >> fedora-11 category? I think that this category should group all >> packages that are installed by default and are part of the system. >> > > All of these are external modules, independent from Fedora. In > fedora-11-like categories we have only projects that we are upstream of. Is anyway to identify/categorize/group/whatever those packages among others installed by default for easy prioritization? noriko From wtogami at redhat.com Thu Apr 2 05:01:36 2009 From: wtogami at redhat.com (Warren Togami) Date: Thu, 02 Apr 2009 01:01:36 -0400 Subject: Draft IBus Hotkey Behavior Plan v0.1 Message-ID: <49D446B0.5050002@redhat.com> Please comment on the below draft. Cycle Hotkey Behavior ===================== We have agreed to match the Windows IME hotkey cycling behavior in order to match user expectations. Alt-Shift This hotkey cycles to the next language. Ctrl-Shift This hotkey cycles to the next engine within the current language, if there is more than one engine for that language. In practice this only does something in Chinese, while it does nothing in single engine languages like Japanese or Korean. There is no time to implement this for Fedora 11, so we will compromise by having Alt-Shift cycle through all engines for all languages until we later implement this secondary cycling hotkey. Ideal Trigger Hotkey Behavior ============================= After F11, we intend on changing the default behavior of hotkeys to be similar to Windows behavior, where hotkeys associated with a language are active only when that language engine is the current engine. Chinese CTRL-Space India CTRL-Space Japanese Hankaku, Alt-Hankaku, Alt-` Korean right-Alt This means if Japanese is the current language engine, CTRL-Space does nothing. If Korean is the current language engine, Alt-` does nothing. The goal is to bring our IM behavior into line with non-technical normal user (hint: not Linux user) expectations, while making it easy to restore the old Linux behavior with an option. I believe after we implement the above behavior, we could possibly improve upon it: * In this ideal plan, the global trigger hotkey would default to blank. A user may set their desired global trigger hotkey if they want to restore the previous behavior. * We may want to consider always enabling non-native hotkeys deemed to be non-conflicting, or making this an option. For example, Hankaku and Alt-` wont upset any other user. right-Alt would upset non-Korean users, however Han/En is unique and might be deemed as non-conflicting. * Other possible improvements over Windows behavior. This ideal plan would need to implement some type of per-language hotkeys that inherit from the current engine. We don't have time to do this before Fedora 11. Thus we will do a simpler plan for Fedora 11, and return to do it properly later. Fedora 11 Compromise Trigger Behavior Plan ========================================== Default Global Triggers CTRL-Space, Hankaku, Alt-Hankaku, Alt-` These as default global triggers satisfy nearly all normal end-user expectations without upsetting anyone. Korean Hotkey Behavior ====================== https://bugzilla.redhat.com/show_bug.cgi?id=493509 US Layout Hotkeys right-Alt Han/En switch in language bar, does not dismiss bar right-Ctrl Hanja conversion button KO Layout Hotkeys (might already be done, needs testing) Han/En button switch in language bar, does not dismiss bar Hanja conversion button * phuang says Korean users expect Alt-Space as trigger, but it seems to do nothing by default on Windows. * krisna mentioned left-Alt as being expected to be Hanja, but it seems to do nothing on Windows. US Korean users seem to universally expect right-Ctrl to be Hanja. * Variants of these preferences seem to exist. We should study SCIM Hangul, Windows and Mac to see what preferences exist. Japanese Hotkey Behavior ======================== (TODO) Chinese Hotkey Behavior ======================= (TODO) Warren Togami wtogami at redhat.com From piotrdrag at gmail.com Thu Apr 2 16:20:23 2009 From: piotrdrag at gmail.com (=?UTF-8?B?UGlvdHIgRHLEhWc=?=) Date: Thu, 02 Apr 2009 18:20:23 +0200 Subject: iBus translations submission! In-Reply-To: <49D3F9EF.6010301@redhat.com> References: <49D3542B.3010505@redhat.com> <5eb2c9220904010455s71f574bapd45daf0a710c636@mail.gmail.com> <49D3A410.3020503@gmail.com> <49D3F9EF.6010301@redhat.com> Message-ID: <49D4E5C7.7010906@gmail.com> Noriko Mizumoto pisze: > Is anyway to identify/categorize/group/whatever those packages among > others installed by default for easy prioritization? > Currently I'm working on creating new categories and re-organizing some of them. For now this list can be helpful for new translators: http://fedoraproject.org/wiki/L10N/GUI -- Piotr Dr?g http://raven.pmail.pl From ankit at redhat.com Fri Apr 3 05:17:51 2009 From: ankit at redhat.com (Ankitkumar Rameshchandra Patel) Date: Fri, 03 Apr 2009 10:47:51 +0530 Subject: iBus translations submission! In-Reply-To: <49D4E5C7.7010906@gmail.com> References: <49D3542B.3010505@redhat.com> <5eb2c9220904010455s71f574bapd45daf0a710c636@mail.gmail.com> <49D3A410.3020503@gmail.com> <49D3F9EF.6010301@redhat.com> <49D4E5C7.7010906@gmail.com> Message-ID: <49D59BFF.90603@redhat.com> Piotr Dr?g wrote: > Noriko Mizumoto pisze: >> Is anyway to identify/categorize/group/whatever those packages among >> others installed by default for easy prioritization? >> > > Currently I'm working on creating new categories and re-organizing > some of them. For now this list can be helpful for new translators: > > http://fedoraproject.org/wiki/L10N/GUI > Piotr, Looks good list for the start. Let's know if you need any help for preparing this list. Fedora I18n team could be the best to help us on preparing this list, I think. As Noriko mentioned, having another category of "Packages installed by default" for the minimal install would be really good too. Btw, Can we have some definition or explanation for these categories on the wiki page? That makes it clear for translators to understand the category. Thanks! -- Regards, Ankit Patel http://www.indianoss.org/ From dchen at redhat.com Fri Apr 3 07:32:15 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Fri, 03 Apr 2009 17:32:15 +1000 Subject: Draft IBus Hotkey Behavior Plan v0.1 In-Reply-To: <49D446B0.5050002@redhat.com> References: <49D446B0.5050002@redhat.com> Message-ID: <1238743935.3708.5.camel@localhost.localdomain> ? ??2009-04-02 ? 01:01 -0400?Warren Togami ??? > Please comment on the below draft. > > Cycle Hotkey Behavior > ===================== > We have agreed to match the Windows IME hotkey cycling behavior in order > to match user expectations. > > Alt-Shift > This hotkey cycles to the next language. > > Ctrl-Shift > This hotkey cycles to the next engine within the current language, if > there is more than one engine for that language. In practice this only > does something in Chinese, while it does nothing in single engine > languages like Japanese or Korean. There is no time to implement this > for Fedora 11, so we will compromise by having Alt-Shift cycle through > all engines for all languages until we later implement this secondary > cycling hotkey. We need to consider not only the Windows user, but also existing Linux user who used to other IM framework SCIM. As I suggested in https://bugzilla.redhat.com/show_bug.cgi?id=490013 There should be an option that allow the Ctrl-Shift to cycle all, though it needs not to be default. -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From wtogami at redhat.com Mon Apr 6 01:48:08 2009 From: wtogami at redhat.com (Warren Togami) Date: Sun, 05 Apr 2009 21:48:08 -0400 Subject: Draft IBus Hotkey Behavior Plan v0.1 In-Reply-To: <1238743935.3708.5.camel@localhost.localdomain> References: <49D446B0.5050002@redhat.com> <1238743935.3708.5.camel@localhost.localdomain> Message-ID: <49D95F58.9020003@redhat.com> On 04/03/2009 03:32 AM, Ding-Yi Chen wrote: > We need to consider not only the Windows user, but also existing Linux > user who used to other IM framework SCIM. As I suggested in > https://bugzilla.redhat.com/show_bug.cgi?id=490013 > > There should be an option that allow the Ctrl-Shift to cycle all, > though it needs not to be default. > Sure, simply reassign the Alt-Shift to Ctrl-Shift. Warren From dchen at redhat.com Mon Apr 6 04:54:37 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Mon, 06 Apr 2009 14:54:37 +1000 Subject: Draft IBus Hotkey Behavior Plan v0.1 In-Reply-To: <49D95F58.9020003@redhat.com> References: <49D446B0.5050002@redhat.com> <1238743935.3708.5.camel@localhost.localdomain> <49D95F58.9020003@redhat.com> Message-ID: <1238993677.3838.6.camel@localhost.localdomain> ? ??2009-04-05 ? 21:48 -0400?Warren Togami ??? > On 04/03/2009 03:32 AM, Ding-Yi Chen wrote: > > We need to consider not only the Windows user, but also existing Linux > > user who used to other IM framework SCIM. As I suggested in > > https://bugzilla.redhat.com/show_bug.cgi?id=490013 > > > > There should be an option that allow the Ctrl-Shift to cycle all, > > though it needs not to be default. > > > > Sure, simply reassign the Alt-Shift to Ctrl-Shift. > > Warren > I thought Alt-Shift is for En -> Zh -> Jp -> Kr .... But what I am talking about (and ppls from SCIM/OXIM/Gcin perceived) is En -> Zh0 -> Zh1 -> Zh2 -> Jp0 -> Jp1 -> Kr ... -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From wtogami at redhat.com Tue Apr 7 04:16:01 2009 From: wtogami at redhat.com (Warren Togami) Date: Tue, 07 Apr 2009 00:16:01 -0400 Subject: ibus-hangul bugs Message-ID: <49DAD381.5050009@redhat.com> Hello Krisna, We have decided to make the Fedora ibus defaults behave exactly like Windows IME in order to match the majority end-user expectations. This means we will not ship with legacy default hotkeys in cases where they conflict like Shift-Space. Users may configure it that way in options if they desire non-default hotkeys and behaviors. I have bought a Korean USB keyboard so I can test Korean input with both US and KO layouts. I hope for your comment on the following. 1) BTW, where did F9 as Hanja conversion button come from? This seems like another legacy that conflicts with unrelated software. Windows and Mac do not have F9 as Hanja by default. Perhaps this is because all modern Korean keyboards have a Hanja button, making the legacy F9 obsolete? 2) https://www.redhat.com/archives/fedora-i18n-list/2009-April/msg00004.html Here is the current proposal for ~6-month ideal IM behavior, and the compromise behavior for Fedora 11. Fedora 11 development freeze is one week from now. I really need people to respond to this proposal. 3) https://bugzilla.redhat.com/show_bug.cgi?id=494445 ibus-hangul missing right-Alt or Hangul Han/En mode How difficult might it be to implement this for ibus-hangul, so it behaves equivalently to Windows Hangul? Currently it is especially unfriendly to use ibus-hangul with a US keyboard layout because we lack Han/En mode switching. https://bugzilla.redhat.com/show_bug.cgi?id=491042 We especially need ibus-hangul to handle Han/En mode switching because we cannot define right-Alt as a default global trigger, as it would be too disruptive to non-Korean users. Do you agree? I really hope for your help to add this to ibus-hangul, because without this ibus-hangul is not usable with US keyboard. 4) https://bugzilla.redhat.com/show_bug.cgi?id=493687 ibus-hangul should default to vertical candidate selection phuang says the next build will do vertical candidate selection automatically for both ko and ja. https://bugzilla.redhat.com/show_bug.cgi?id=493706 [PATCH] ibus-hangul Hanja arrow keys are wrong I think this patch is reasonably correct, especially with ko vertical candidate selection. 5) https://bugzilla.redhat.com/show_bug.cgi?id=493509 [PATCH] ibus-hangul missing right Ctrl for Hanja button I know you mentioned that some Korean users don't want this. My testing however has found this to be default in Windows/Mac even with Korean layout keyboard. I think this should be default because US keyboard users expect it. You should add an option to ibus-hangul to turn it off if you think it is important that some users really don't want it. Do you agree? 6) https://bugzilla.redhat.com/show_bug.cgi?id=492929 ibus-hangul can cause gtk app to lockup Very nasty bug hangul specific. phuang said he fixed this upstream but I am waiting for new builds to test it. Warren Togami wtogami at redhat.com From wtogami at redhat.com Tue Apr 7 04:18:51 2009 From: wtogami at redhat.com (Warren Togami) Date: Tue, 07 Apr 2009 00:18:51 -0400 Subject: Draft IBus Hotkey Behavior Plan v0.1 In-Reply-To: <1238993677.3838.6.camel@localhost.localdomain> References: <49D446B0.5050002@redhat.com> <1238743935.3708.5.camel@localhost.localdomain> <49D95F58.9020003@redhat.com> <1238993677.3838.6.camel@localhost.localdomain> Message-ID: <49DAD42B.9000406@redhat.com> On 04/06/2009 12:54 AM, Ding-Yi Chen wrote: > > I thought Alt-Shift is for En -> Zh -> Jp -> Kr .... > But what I am talking about (and ppls from SCIM/OXIM/Gcin perceived) > is En -> Zh0 -> Zh1 -> Zh2 -> Jp0 -> Jp1 -> Kr ... I am not disagreeing with this. https://www.redhat.com/archives/fedora-i18n-list/2009-April/msg00004.html However this is the difference between the compromise F-11 plan and Ideal plan. There isn't time to make it perfect for F-11, but this is an improvement over the current behavior. Warren From wtogami at redhat.com Wed Apr 8 05:15:21 2009 From: wtogami at redhat.com (Warren Togami) Date: Wed, 08 Apr 2009 01:15:21 -0400 Subject: ibus-hangul bugs In-Reply-To: <604f48110904072144v3b6ae09dn553de13ae946cd02@mail.gmail.com> References: <49DAD381.5050009@redhat.com> <604f48110904072144v3b6ae09dn553de13ae946cd02@mail.gmail.com> Message-ID: <49DC32E9.8080607@redhat.com> On 04/08/2009 12:44 AM, Choe Hwanjin wrote: > On Tue, Apr 7, 2009 at 1:16 PM, Warren Togami wrote: >> Hello Krisna, >> >> We have decided to make the Fedora ibus defaults behave exactly like Windows >> IME in order to match the majority end-user expectations. This means we >> will not ship with legacy default hotkeys in cases where they conflict like >> Shift-Space. Users may configure it that way in options if they desire >> non-default hotkeys and behaviors. I have bought a Korean USB keyboard so I >> can test Korean input with both US and KO layouts. >> >> I hope for your comment on the following. >> >> 1) BTW, where did F9 as Hanja conversion button come from? This seems like >> another legacy that conflicts with unrelated software. Windows and Mac do >> not have F9 as Hanja by default. Perhaps this is because all modern Korean >> keyboards have a Hanja button, making the legacy F9 obsolete? > > Yes, it is legacy. It came from hangul word processor and it still > uses same key to > convert hanja. It also used in Ami (old korean xim). scim-hangul, > nabi, imhangul > also use F9 as hanja conversion key. I prefer F9 and Hanja key as hanja > conversion key. > But if you insist, It's ok for me to remove F9 from hanja conversion keys. Please keep F9 for now, until it can be configurable within ibus-hangul. > >> 2) >> https://www.redhat.com/archives/fedora-i18n-list/2009-April/msg00004.html >> Here is the current proposal for ~6-month ideal IM behavior, and the >> compromise behavior for Fedora 11. Fedora 11 development freeze is one week >> from now. I really need people to respond to this proposal. > > For koreans, they may be annoyed with right-alt and right-ctrl as trigger > key and hanja conversion key. > There are korean keyboard driver type 1, 2, 3 on windows, and with type 3, > shift-space works as trigger key. What is type 1 and 2? > >> 3) >> https://bugzilla.redhat.com/show_bug.cgi?id=494445 >> ibus-hangul missing right-Alt or Hangul Han/En mode >> How difficult might it be to implement this for ibus-hangul, so it behaves >> equivalently to Windows Hangul? Currently it is especially unfriendly to >> use ibus-hangul with a US keyboard layout because we lack Han/En mode >> switching. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=491042 >> We especially need ibus-hangul to handle Han/En mode switching because we >> cannot define right-Alt as a default global trigger, as it would be too >> disruptive to non-Korean users. >> >> Do you agree? I really hope for your help to add this to ibus-hangul, >> because without this ibus-hangul is not usable with US keyboard. > > It requires that the input framework is enabled on start, or a user should > press trigger key twice. > > Let's think about the behavior: > 1. Run gedit. > 2. Input method is not enabled yet. So a user should enable input method by > pressing 'ctrl-space'. > 3. Now korean input method is enabled but it is in english mode. So the user > should press 'right-Alt' or anything else. > I think it isn't acceptable for most users. Would it be wrong for ibus-hangul to begin in Hangul mode? That seems very reasonable? > >> 4) >> https://bugzilla.redhat.com/show_bug.cgi?id=493687 >> ibus-hangul should default to vertical candidate selection >> phuang says the next build will do vertical candidate selection >> automatically for both ko and ja. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=493706 >> [PATCH] ibus-hangul Hanja arrow keys are wrong >> I think this patch is reasonably correct, especially with ko vertical >> candidate selection. > > I think ibus-hangul should detect lookup table orientation and change > the arrow key behavior according to the lookup table orientation. > And I think it should not fixed, it should be changeble by a user or a > programmer. I agree it should be configurable, but we need a compromise with expected defaults for the Fedora 11 development deadline in less than a week. > >> 5) >> https://bugzilla.redhat.com/show_bug.cgi?id=493509 >> [PATCH] ibus-hangul missing right Ctrl for Hanja button >> >> I know you mentioned that some Korean users don't want this. My testing >> however has found this to be default in Windows/Mac even with Korean layout >> keyboard. I think this should be default because US keyboard users expect >> it. You should add an option to ibus-hangul to turn it off if you think it >> is important that some users really don't want it. Do you agree? > > It's not difficult to add another hanja conversion key. > And it is better to make it configurable. > But making hot key configure widget takes some time. I agree it should be configurable, but again we need to have something usable in a week. The Han/En issue above and to a small degree the lack of this hotkey makes ibus-hangul currently unusable without a Korean keyboard. We should add configurability after Fedora 11 when we have more time to implement the ideal interface. #4 above is the most important issue we have remaining for ibus in Fedora 11. > >> 6) >> https://bugzilla.redhat.com/show_bug.cgi?id=492929 >> ibus-hangul can cause gtk app to lockup >> Very nasty bug hangul specific. phuang said he fixed this upstream but I am >> waiting for new builds to test it. > > I didn't know that. > I will test it later, because I have no time recently. Good news, phuang fixed this, it was a bug in ibus core. Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Apr 10 02:09:45 2009 From: wtogami at redhat.com (Warren Togami) Date: Thu, 09 Apr 2009 22:09:45 -0400 Subject: ibus-hangul bugs In-Reply-To: <604f48110904091853x1005b54av4ef1aa2f7fa47779@mail.gmail.com> References: <49DAD381.5050009@redhat.com> <604f48110904072144v3b6ae09dn553de13ae946cd02@mail.gmail.com> <49DC32E9.8080607@redhat.com> <604f48110904091853x1005b54av4ef1aa2f7fa47779@mail.gmail.com> Message-ID: <49DEAA69.9040307@redhat.com> On 04/09/2009 09:53 PM, Choe Hwanjin wrote: >>> I think it isn't acceptable for most users. >> Would it be wrong for ibus-hangul to begin in Hangul mode? That seems very >> reasonable? > > It's possible, but I think it is not a solution. > Even if ibus-hangul begin in hangul mode, users should still press > ctrl-space to > input hangul and then user should press right-alt to change input mode, which > don't have consistency. Note: The medium-term plan is to get rid of global hotkey defaults. This means Ctrl-space is only a global trigger for languages like Chinese and Indic. Hankaku, Alt-Hankaku or Alt-` are triggers for Japanese. Hangul or right-Alt are triggers for Korean. For now we decided we are out of time for Fedora 11, so we will ship with all the above triggers enabled as globals. This is not ideal. We will improve this further after Fedora 11 after some design discussions. >> I agree it should be configurable, but we need a compromise with expected >> defaults for the Fedora 11 development deadline in less than a week. > > But current ibus' default lookup table orientation is horizontal not vertical. > And ibus-hangul can't change its value. > If we change the key mapping, it doesn't match the horizontal lookup table. > Is it acceptable? > > I think that current ibus lookup table orientation is horizontal, > therefore key mapping for > lookup table should follow the orientation. I'm surprised, but phuang made the new ibus default vertical. It seems after Fedora 11 we will have vertical/horizontal decided by the language engine. > it is easy to make right-ctrl as Hanja conversion key. > But it needs some time to add english mode in ibus-hangul. > I don't have time to do it now. > And basically I don't agree to add english mode in every language engine. > > And Shift-Space is mostly used trigger key in korean linux desktop. > So I think shift-space is enough for now. As noted above, we delayed implementing these proposed changes. In the short-term the only remaining changes we need are the two patches for right-Ctrl and proper arrow key behavior with vertical Hanja candidate selection. In the long-term we need further discussion about the Big Picture plan forward. I will CC you with future summaries as we discuss this plan. Thank you, Warren Togami wtogami at redhat.com From pangp at ematters.com.tw Wed Apr 15 03:03:58 2009 From: pangp at ematters.com.tw (Peter Pang) Date: Wed, 15 Apr 2009 11:03:58 +0800 Subject: request for ibus input method? Message-ID: <20090415025902.M10627@ematters.com.tw> Hi I am using Fedora 10 now and realize Fedora 11 is going to use ibus as default input method. Since we are using Zhuyin (Mandarin Phonetic Symbols ?????) a lot and do not find this function in ibus now. Could you advise if there is any plan to add Zhuyin to ibus future? If this Zhuyin question is a FAQ, please give me a link to this FAQ subject. Thanks. Kind regards, Peter From sergio.puas at hotmail.com Wed Apr 15 16:00:46 2009 From: sergio.puas at hotmail.com (sergio.puas at hotmail.com) Date: Wed, 15 Apr 2009 09:00:46 -0700 Subject: =?iso-8859-1?q?Respuesta_autom=E1tica?= In-Reply-To: <20090415160042.CDC9961A587@hormel.redhat.com> Message-ID: An HTML attachment was scrubbed... URL: From dchen at redhat.com Thu Apr 16 02:29:06 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Thu, 16 Apr 2009 12:29:06 +1000 Subject: request for ibus input method? In-Reply-To: <20090415025902.M10627@ematters.com.tw> References: <20090415025902.M10627@ematters.com.tw> Message-ID: <1239848946.3904.9.camel@localhost.localdomain> There is ibus-chewing for AI Zhuyin input method, However, if you are after "pure" zhuyin, you may provide a table for ibus-table. See http://code.google.com/p/ibus/issues/detail?id=94&q=table&colspec=ID% 20Component%20Type%20Status%20Priority%20Milestone%20Owner%20Summary For example. ? ??2009-04-15 ? 11:03 +0800?Peter Pang ??? > Hi > > I am using Fedora 10 now and realize Fedora 11 is going to use ibus as default input method. > Since we are using Zhuyin (Mandarin Phonetic Symbols ?????) a lot and do not find > this function in ibus now. > > Could you advise if there is any plan to add Zhuyin to ibus future? > > If this Zhuyin question is a FAQ, please give me a link to this FAQ subject. > Thanks. > > Kind regards, > Peter > > -- > Fedora-i18n-list mailing list > Fedora-i18n-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-i18n-list -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From pangp at ematters.com.tw Fri Apr 17 04:06:15 2009 From: pangp at ematters.com.tw (Peter Pang) Date: Fri, 17 Apr 2009 12:06:15 +0800 Subject: Fedora-i18n-list Digest, Vol 59, Issue 9 In-Reply-To: <20090416160039.A66F28E0161@hormel.redhat.com> References: <20090416160039.A66F28E0161@hormel.redhat.com> Message-ID: <20090417035538.M22121@ematters.com.tw> Hi, I understand there is ibus-chewing for AI Zhuyin input method. The request I submitted is mainly focused on "pure" Zhuyin input method. There are users using chewing, but still many users are using traditional "pure" Zhuyin input method. I would highlight this need so that ibus could also add this Zhuyin input method. Thanks for the web info, and how can I get the Zhuyin table for ibus-table? I am simply a user and not good at ibus technical components. Of course, the more I know, the more I can research. Could we know any easier way to have "pure" Zhuyin in ibus system or how to handle tables? Kind regards, Peter > Date: Thu, 16 Apr 2009 12:29:06 +1000 > From: Ding-Yi Chen > Subject: Re: request for ibus input method? > To: Fedora internationalization discussions > > Message-ID: <1239848946.3904.9.camel at localhost.localdomain> > Content-Type: text/plain; charset=utf-8 > > There is ibus-chewing for AI Zhuyin input method, > However, if you are after "pure" zhuyin, you may provide a table for > ibus-table. > > See > http://code.google.com/p/ibus/issues/detail?id=94&q=table&colspec=ID% > 20Component%20Type%20Status%20Priority%20Milestone%20Owner%20Summary > > For example. > > ??? ??????2009-04-15 ??? 11:03 +0800???Peter Pang ????????? > > Hi > > > > I am using Fedora 10 now and realize Fedora 11 is going to use ibus as default input method. > > Since we are using Zhuyin (Mandarin Phonetic Symbols ?????????? ????) a lot and do not find > > this function in ibus now. > > > > Could you advise if there is any plan to add Zhuyin to ibus future? > > > > If this Zhuyin question is a FAQ, please give me a link to this FAQ subject. > > Thanks. > > > > Kind regards, > > Peter > > > > -- > > Fedora-i18n-list mailing list > > Fedora-i18n-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > -- > Ding-Yi Chen > Software Engineer > Internationalization Group > Red Hat, Inc. > > Looking to carve out IT costs? > www.apac.redhat.com/promo/carveoutcosts/ > > ------------------------------ > > -- > Fedora-i18n-list mailing list > Fedora-i18n-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > > End of Fedora-i18n-list Digest, Vol 59, Issue 9 > *********************************************** From dchen at redhat.com Tue Apr 21 07:56:56 2009 From: dchen at redhat.com (Ding-Yi Chen) Date: Tue, 21 Apr 2009 17:56:56 +1000 Subject: Fedora-i18n-list Digest, Vol 59, Issue 9 In-Reply-To: <20090417035538.M22121@ematters.com.tw> References: <20090416160039.A66F28E0161@hormel.redhat.com> <20090417035538.M22121@ematters.com.tw> Message-ID: <1240300616.3642.7.camel@localhost.localdomain> Hi, I have made a plain Zhuyin input module, ibus-table-zhuyin. You can play it by: git clone git://github.com/definite/ibus-table-zhuyin.git However, unless ibus-table have not support endkeys, ibus-table-zhuyin cannot be used practically, because you can only input the first candidate. *sigh*. Detail of this can be see in http://code.google.com/p/ibus/issues/detail?id=361&colspec=ID% 20Component%20Type%20Status%20Priority%20Milestone%20Owner%20Summary In the meantime, I'll amend my ibus-chewing to support pure zhuyin input. Please post further questing in IBus Google Code: http://code.google.com/p/ibus/ for you got more audience there. Regards, Ding-Yi Chen ? ??2009-04-17 ? 12:06 +0800?Peter Pang ??? > Hi, > > I understand there is ibus-chewing for AI Zhuyin input method. > The request I submitted is mainly focused on "pure" Zhuyin input method. > > There are users using chewing, but still many users are using traditional "pure" Zhuyin > input method. I would highlight this need so that ibus could also add this Zhuyin input > method. > > Thanks for the web info, and how can I get the Zhuyin table for ibus-table? > I am simply a user and not good at ibus technical components. > Of course, the more I know, the more I can research. > Could we know any easier way to have "pure" Zhuyin in ibus system or how to handle tables? > > Kind regards, > Peter > > > Date: Thu, 16 Apr 2009 12:29:06 +1000 > > From: Ding-Yi Chen > > Subject: Re: request for ibus input method? > > To: Fedora internationalization discussions > > > > Message-ID: <1239848946.3904.9.camel at localhost.localdomain> > > Content-Type: text/plain; charset=utf-8 > > > > There is ibus-chewing for AI Zhuyin input method, > > However, if you are after "pure" zhuyin, you may provide a table for > > ibus-table. > > > > See > > http://code.google.com/p/ibus/issues/detail?id=94&q=table&colspec=ID% > > 20Component%20Type%20Status%20Priority%20Milestone%20Owner%20Summary > > > > For example. > > > > ??? ??????2009-04-15 ??? 11:03 +0800???Peter Pang ????????? > > > Hi > > > > > > I am using Fedora 10 now and realize Fedora 11 is going to use ibus as default input > method. > > > Since we are using Zhuyin (Mandarin Phonetic Symbols ???????????????) a lot and do > not find > > > this function in ibus now. > > > > > > Could you advise if there is any plan to add Zhuyin to ibus future? > > > > > > If this Zhuyin question is a FAQ, please give me a link to this FAQ subject. > > > Thanks. > > > > > > Kind regards, > > > Peter > > > > > > -- > > > Fedora-i18n-list mailing list > > > Fedora-i18n-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > > -- > > Ding-Yi Chen > > Software Engineer > > Internationalization Group > > Red Hat, Inc. > > > > Looking to carve out IT costs? > > www.apac.redhat.com/promo/carveoutcosts/ > > > > ------------------------------ > > > > -- > > Fedora-i18n-list mailing list > > Fedora-i18n-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > > > > End of Fedora-i18n-list Digest, Vol 59, Issue 9 > > *********************************************** > > -- > Fedora-i18n-list mailing list > Fedora-i18n-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-i18n-list -- Ding-Yi Chen Software Engineer Internationalization Group Red Hat, Inc. Looking to carve out IT costs? www.apac.redhat.com/promo/carveoutcosts/ From sergio.puas at hotmail.com Tue Apr 21 16:00:35 2009 From: sergio.puas at hotmail.com (sergio.puas at hotmail.com) Date: Tue, 21 Apr 2009 09:00:35 -0700 Subject: =?iso-8859-1?q?Respuesta_autom=E1tica?= In-Reply-To: <20090421160032.DC7B061A0BE@hormel.redhat.com> Message-ID: An HTML attachment was scrubbed... URL: