i18n April 2009

i18n@lists.stg.fedoraproject.org

8 participants
11 discussions

IBus UI review
by Matthias Clasen 20 May '09

20 May '09

Not sure if this is the correct place to send this, but I'll send it here anyway (please tell me if there's a better place). I've recently installed ibus in order to get some impression of how our new im framework will integrate in the desktop. While playing with it, I took some notes, that I'd like to share. Matthias --- Status icon - The tooltip "IBus - Running" is pretty pointless less and should be removed until there is something useful to say - There is no way to switch back to "no input method" from the status icon. I have to press Ctrl-space to go back. Maybe add an "None" entry at the bottom of the menu ? Toolbar - Why do input methods seem to fancy these weird undecorated floating toolbars ? Does it add anything that is not already present in the status icon ? - If we can't drop it, can there at least be a way to turn it off ? - The toolbar seems useless if "focus-follows-mouse" is turned on, since it becomes inactive on focus out. This also affects the status icon. Menus - What is the plan, going forward, wrt to im-chooser ? I'd hate to have 2 input method related menuitems in the default install. My preference would be to not install the im-chooser by default, since it is only needed to switch back to 'legacy' frameworks. - It would be great if we could use the generic "Input Method" menuitem for the ibus preferences, and maybe rename im-chooser to "Input Method Framework" or something like that. - Alternatively, if we can't get rid of im-chooser by default, maybe ibus-setup should not have its own menu item (I notice that scim-setup doesn't have one either), since it is available via im-chooser. - There is a mismatch between the menuitem and the ibus-setup window, both the window title and icon don't match the menu, as they should. Preferences, General tab - "Aauto start IBus on session login" is very techno babble. Can we make that something like "Enable Input Methods" ? I don't think there is any need to talk about sessions and autostart here. - Keyboard shortcuts: I would love to see these moved to the keyboard shortcuts capplet, which has support for handling application-defined shortcuts. As a bonus, you get automatic conflict handling. The one restriction is that currently, only one key-combination per action is possible. If having multiple is essential, you could either split it into "Trigger", "Alternative Trigger", "Second Alternative Trigger", or file a bug and I'll look into enabling multiple shortcuts per action in the keybinding capplet - "UI" is a bad section label. How about "Fonts & Style" instead ? Even better would be to split it into two sections, a la Input Window Lookup table orientation: [Vertical] [ ] Use the system font Input Window Font: [Sans 10] Language Bar [ ] Show language bar [ ] Hide language bar when it is not needed Preferences, Engine tab - "Engine" is a technical term that is not really helpful here. How about "Languages" instead ? - There are some icons missing in the combo box, e.g Telugu-apple, Telugu-rts, Marathi-phonetic, Marathi-itrans... - The main list needs to repeat the language name (like the status icon menu already does) otherwise it is not clear if "phonetic" is Oriya or Marathi. Preferences, About tab This should not be done as a tab, it is very much against the style of our preference tools. There is already an About menu item on the status icon. If you absolutely want to have an "About" in the preferences, it should be a left-aligned "About" button in the action area that brings up an about dialog. But I'd really just get rid of it.

4 9

Respuesta automática
by sergio.puas＠hotmail.com 21 Apr '09

21 Apr '09

1 0

Re: Fedora-i18n-list Digest, Vol 59, Issue 9
by Peter Pang 21 Apr '09

21 Apr '09

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 <dchen(a)redhat.com> > Subject: Re: request for ibus input method? > To: Fedora internationalization discussions > <fedora-i18n-list(a)redhat.com> > Message-ID: <1239848946.3904.9.camel(a)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(a)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(a)redhat.com > https://www.redhat.com/mailman/listinfo/fedora-i18n-list > > End of Fedora-i18n-list Digest, Vol 59, Issue 9 > ***********************************************

2 1

request for ibus input method?
by Peter Pang 15 Apr '09

15 Apr '09

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

2 1

Respuesta automática
by sergio.puas＠hotmail.com 15 Apr '09

15 Apr '09

1 0

Re: ibus-hangul bugs
by Warren Togami 09 Apr '09

09 Apr '09

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(a)redhat.com

1 0

Re: ibus-hangul bugs
by Warren Togami 08 Apr '09

08 Apr '09

On 04/08/2009 12:44 AM, Choe Hwanjin wrote: > On Tue, Apr 7, 2009 at 1:16 PM, Warren Togami<wtogami(a)redhat.com> 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(a)redhat.com

1 0

Draft IBus Hotkey Behavior Plan v0.1
by Warren Togami 06 Apr '09

06 Apr '09

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(a)redhat.com

2 4

ibus-hangul bugs
by Warren Togami 06 Apr '09

06 Apr '09

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(a)redhat.com

1 0

Re: iBus translations submission!
by Piotr Drąg 03 Apr '09

03 Apr '09

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

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

i18n April 2009