06:02:52 <tagoh_> #startmeeting i18n
06:02:52 <zodbot> Meeting started Wed Oct 23 06:02:52 2013 UTC.  The chair is tagoh_. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:02:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
06:02:53 <tagoh_> #meetingname i18n
06:02:53 <zodbot> The meeting name has been set to 'i18n'
06:02:53 <tagoh_> #topic agenda and roll call
06:02:54 <tagoh_> #link https://fedoraproject.org/wiki/I18N/Meetings/2013-10-23
06:03:11 <dueno> hi
06:03:15 <tagoh_> okay, time to have i18n meeting now
06:03:20 <juhp> hi
06:03:25 <pravins> hi
06:03:38 <fujiwarat> hi
06:03:39 <mfabian> Hi!
06:04:21 <anish_> hi
06:05:00 <epico> hi
06:06:51 <paragan_> hi
06:07:00 <tagoh_> let's get started.
06:07:37 <tagoh_> #topic Upcoming schedule
06:07:37 <tagoh_> #info 2013-10-29        Beta Release
06:07:38 <tagoh_> #info 2013-11-19        Final Change Deadline
06:07:38 <tagoh_> #info 2013-12-03        Fedora 20 Final Release
06:07:47 <tagoh_> and i18n test day next Tuesday
06:08:48 <tagoh_> #topic Outstanding topics
06:08:50 <tagoh_> #info #26: proposal: move to using IMEs for ASCII/Latin input (i18n@lists.fedoraproject.org)
06:08:50 <tagoh_> #link https://fedorahosted.org/i18n/ticket/26
06:09:36 <tagoh_> just shuffled the order to focus on it more so that we didn't have a time to discuss about it last time
06:10:44 <juhp> I don't think I have any further updates on it today - anyone?
06:11:35 <juhp> do we need some rule/protocol about who should update tickets after meeting?
06:12:32 <juhp> perhaps should be proposer's job dunno?
06:13:28 <tagoh_> can anyone sort out requirements, pros and cons on implementations etc?
06:13:51 <juhp> I can try to update the ticket based on discussion so far before next meeting I suppose
06:14:15 <tagoh_> that would be great
06:14:19 <juhp> anyway opinions still seem somewhat divided on scope too
06:14:43 <juhp> or was it only me who thinks single source makes sense - I forget ;)
06:15:04 <juhp> as default...
06:16:10 <tagoh_> there should be no conclusions yet.. just made mention each other with what they think of
06:16:18 <juhp> ok
06:17:00 <tagoh_> so need to make it clear and what's better to go
06:17:25 <mfabian> I don’t see the point removing the extra keyboard, if you just don’t switch engines and switch to Latin using kkc only, other engines/keyboards selectable in the panel don’t cause any harm.
06:17:38 <juhp> and do we need some rule about who should update tickets after meeting discussion?
06:18:28 <juhp> mfabian, well true - so should we configure all default IMEs by default too :)
06:18:48 <juhp> but okay point taken
06:19:26 <juhp> layout doesn't use much resources or space anyway
06:19:59 <tagoh_> juhp: I can do. that said it is hard to pick up - need a help from bot. though if we have any consensus on it
06:20:01 <juhp> still seems cleaner to me to remove it if it is unused
06:20:06 <tagoh_> s/it/discussion/
06:20:12 <skore> hi
06:20:25 <juhp> tagoh_, right
06:22:11 <juhp> also wish gnome indicator would expand mode submenu by default perhaps
06:22:36 <juhp> anyway I guess it is something for f20 perhaps
06:23:10 <juhp> mfabian, if kkc defaults to Latin then switching be xkb is kind of redundant
06:23:21 <juhp> for example
06:24:10 <mfabian> Yes, it is redundant, but it thought it is an “obvious” way to switch to Latin whereas the switch within kkc is not so obvious.
06:24:25 <juhp> yes that is true, hmm
06:24:45 <juhp> so maybe we need to make the IME mode switching more natural
06:25:10 <tagoh_> so may be better implementing it as ibus feature perhaps?
06:25:24 <mfabian> expand sub menu automatically: I think I would like that.
06:25:40 <pravins> yes, having it in ibus will be good
06:25:41 <mfabian> I also would like to have that sub-menu at the top, above the list of other engines, not at the bottom.
06:25:43 <epico> Chinese imes normally default to Chinese mode...
06:25:56 <epico> maybe need some help on ibus side?
06:25:56 <pravins> so ime-engine only need to call particular function say for starting latin.
06:26:26 <mfabian> Because if I have many engines enabled, it is a long way with the mouse to the sub-menu if it is at the bottom.
06:26:52 <epico> mfabian, +1
06:26:59 <juhp> yes
06:27:06 <juhp> tagoh_, perhaps
06:27:44 <juhp> maybe we only need hotkey for mode switching not IME switching
06:27:56 <juhp> hmm
06:28:01 <juhp> by default I mean
06:28:34 <tagoh_> mfabian: well, it could be a separate feature. better talk about it later or file an RFE probably
06:28:56 <juhp> sure it is another issue but related perhaps
06:29:48 <juhp> I think traditionally IM would show the list of input modes in the top level
06:29:53 <tagoh_> juhp: well, related stuff should be only to display the mode at the panel. its location should be irrelevant
06:30:20 <tagoh_> right
06:31:36 <juhp> epico, sure but Linux normally default to Latin input...
06:32:07 <epico> juhp, yes, just some thought on code side...
06:32:12 <juhp> right
06:32:19 <tagoh_> guess default when turning on IM..
06:33:03 <epico> now, when switched default is Chinese mode for pinyin...
06:33:26 <juhp> epico, but if you only have libpinyin you probably want default to Latin
06:33:37 <epico> juhp, right
06:33:59 <tagoh_> epico: once this feature is implemented, IM should be always turned on and engines may has to start Latin input mode by default. otherwise users may get confused on login perhaps
06:34:03 <juhp> migrating people to new way is somewhat tricky though
06:34:17 <epico> I see
06:34:25 <juhp> maybe only for new accounts perhaps?
06:35:10 <juhp> fujiwarat, do you have any thoughts?
06:36:41 <tagoh_> btw given the performance on switching is improved, do we still need this feature?
06:38:27 <fujiwarat> I think the default latin or language is implemented in each ime at present.
06:38:48 <mfabian> Not in ibus-typing-booster.
06:38:54 <mfabian> But maybe it should be.
06:39:53 <fujiwarat> I guess i-t-b does not have the mode.
06:40:02 <anish_> yeah
06:40:23 <tagoh_> or how about a kind of ibus-latin to deal with keyboard layout stuff? does it still make slowness like we are facing?
06:41:23 <mfabian> Yes, ibus-typing-booster has no direct input mode, but maybe it would be useful to add that. Because sometimes one does want completion and sometimes not. Maybe one wants to use the TAB completion in the shell and then use the i-t-b completion again. So fast switching might be useful for i-t-b.
06:42:24 <epico> tagoh_, like ibus-xkb?
06:42:41 <juhp> has switching performance improved btw?
06:42:43 <tagoh_> epico: sort of, yes
06:43:11 <juhp> a separate module?  I guess it should be built into ibus core?
06:44:10 <epico> juhp: ibus-xkb is in ibus, ibus-xkbc is not...
06:44:20 <juhp> ah yes
06:44:34 <tagoh_> juhp: if that would helps - may need to integrate ibus into gnome more deeply not to make a regression on the feature
06:45:15 <tagoh_> I mean replacing keyboard layout stuff in control-center with ibus completely say
06:45:22 <juhp> I feel like ibus could provide Latin mode for IMEs but integration might need some thought
06:45:30 <juhp> tagoh_, oh
06:45:43 <juhp> not sure that is the way we want to go
06:46:10 <juhp> I feel currently xkb is too much on the same level as IMEs and this is kind of a mistake
06:46:29 <tagoh_> that might helps to improve the performance issue on switching I guess.
06:47:01 <juhp> right no need to switch off/deselect IMEs so often
06:47:04 <mfabian> juhp: yes, I also don’t like keyboard layouts treated the same as input methods.
06:47:36 <juhp> it is like we haven't gotten the design quite right yet
06:47:36 <fujiwarat> Not sure why you don't like to handle latin mode in each IME.
06:47:50 <tagoh_> anyway, I'm wondering if we can settle this down to GNOME upstream without resonable scope
06:48:03 <juhp> fujiwarat, well it might be okay - but seems like duplication potentially
06:48:28 <juhp> tagoh_, I don't see it is gnome specific
06:48:43 <juhp> though we could attempt to solve it first for gnome
06:48:59 <fujiwarat> Each ibus engine can inherit IBusEngineSimple.
06:49:06 <juhp> fujiwarat, okay
06:49:21 <tagoh_> juhp: right. but it has been integrated at this moment. so part of it too
06:49:26 <juhp> fujiwarat, that is probably good enough
06:49:31 <epico> send ctrl-space when only one engine?
06:49:44 <juhp> epico, that might work
06:49:55 <juhp> or something like that
06:50:13 <epico> okay
06:50:15 <fujiwarat> Currently ibus-anthy switches latin and ja with ctrl-space.
06:51:13 <juhp> (one counter argument in the best was the lack of common mode hotkey between different IMEs)
06:51:17 <epico> fujiwarat, I mean Super+space.
06:51:18 <juhp> in the past!
06:52:06 <tagoh_> fujiwarat: but g-s-d on GNOME grabs a key first?
06:52:13 <fujiwarat> Another point is ibus switching uses XI2 and anthy mode switching uses gdk keybinding which also works in nested VM box.
06:52:27 <juhp> aha
06:52:45 <fujiwarat> tagoh_: right.
06:52:59 <juhp> currently Super+Space is a noop when only one input source?
06:53:21 <juhp> dueno, any thoughts?
06:54:11 <tagoh_> juhp: but not forwarding a key event to others
06:54:25 <juhp> but we are kind of lucky to finally have a global hotkey for switching....
06:55:03 <juhp> tagoh_, I see what wondering if it is disable in that case but maybe not
06:55:08 <juhp> what = was
06:55:16 <juhp> disabled
06:55:56 <tagoh_> juhp: even if disabling keyboard plugin with gsettings which is used to use non-ibus IM anyway, one can't turn on it with same key unless they get rid of it from shortcut key settings
06:56:34 <juhp> okay - anyway just wondered
06:57:11 <juhp> other problem is that ibus maintainer doesn't like this approach iiuc
06:57:43 <tagoh_> for reference, https://bugzilla.gnome.org/show_bug.cgi?id=703779
06:57:47 <juhp> so various obstacles we still need to consider
06:58:08 <juhp> tagoh_, I see thanks
06:59:43 <juhp> okay anyway let's try to summarize the main discussion points so far in the ticket before next meeting/discussion hope that might help give further clarity to the issues
07:00:24 <juhp> quite a few points have some up in the discussion so few - perhaps even a wikipage might make sense
07:00:31 <juhp> few =far
07:01:05 <tagoh_> would be nice to clarify the scope again. that sounds like vague ATM.
07:01:31 <juhp> quite a few points have come up in the discussion so far - perhaps even a wikipage might make sense
07:01:36 <juhp> okay
07:02:03 <tagoh_> juhp: yep, sounds good to me
07:02:16 <juhp> well it is somewhat intentionally vague to try to see on best direction for consensus but yeah
07:03:16 <juhp> tagoh_, okay I will try to do that - if there is too much material pros/cons etc i might move the summary to the wiki so more people can input
07:03:38 <tagoh_> juhp: cool. thanks
07:04:01 <juhp> otherwise perhaps we can also try to break it down into smaller pieces and take it from there yeah
07:04:12 <tagoh_> yep
07:04:38 <juhp> we might also have a few bugs/rfe's spin out
07:05:18 <tagoh_> looks olay with "juhp to summarize the discussion and clarify the scope for latin input mode" for action item then?
07:05:24 <tagoh_> okay even
07:05:34 <juhp> sure
07:05:48 <tagoh_> #action juhp to summarize the discussion and clarify the scope for latin input mode
07:05:53 <tagoh_> okay, better move on then
07:06:04 <tagoh_> #info #25: Bugs Corner (i18n@lists.fedoraproject.org)
07:06:04 <tagoh_> #link https://fedorahosted.org/i18n/ticket/25
07:06:15 <tagoh_> any bugs we may want to discuss today?
07:06:34 <tagoh_> not too much time today like we spent last time though
07:09:38 <tagoh_> anyone?
07:09:59 <tagoh_> if not, will move on
07:11:06 <tagoh_> #topic Outstanding task
07:11:06 <tagoh_> #info #23: Fedora 20 i18n test day (i18n@lists.fedoraproject.org)
07:11:06 <tagoh_> #link https://fedorahosted.org/i18n/ticket/23
07:11:43 <tagoh_> okay, as I said earlier, we will have i18n test day next Tuesday. I suppose we can use beta iso for testing
07:12:57 <juhp> hope there might be RC by then
07:13:12 <tagoh_> please join the event as far as possible. all your testings are necessary to improve i18n support in f20.
07:13:13 <juhp> otherwise latest TC?
07:13:19 <juhp> tagoh_, +1
07:14:12 <tagoh_> hopefully we will see more testers than last time.
07:15:41 <tagoh_> any questions or concerns ?
07:16:39 <juhp> are we happy with the current state of testcases?
07:17:27 <tagoh_> guess so since we've reviewed them...
07:18:20 <tagoh_> may need to think about how to update nice-to-test stuff later perhaps
07:19:11 <juhp> okay
07:19:26 <tagoh_> #topic Open Floor
07:19:39 <tagoh_> okay, anything else we want to discuss before stop the meeting?
07:22:13 <tagoh_> then stop the meeting here.
07:22:21 <tagoh_> thanks everyone for the meeting!
07:22:23 <tagoh_> #endmeeting