06:03:00 <tagoh_> #startmeeting i18n
06:03:00 <zodbot> Meeting started Thu Sep  5 06:03:00 2013 UTC.  The chair is tagoh_. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:03:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
06:03:00 <tagoh_> #meetingname i18n
06:03:00 <zodbot> The meeting name has been set to 'i18n'
06:03:01 <tagoh_> #topic agenda and roll call
06:03:01 <tagoh_> #link https://fedoraproject.org/wiki/I18N/Meetings/2013-09-05
06:03:18 <epico> hi
06:03:21 <dueno> hi
06:03:21 <tagoh_> okay, time to have i18n meeting
06:03:23 <mfabian> Hi!
06:03:54 <fujiwarat> hi
06:04:21 <tagoh_> not too much topics and updates. that may be a quick meeting today perhaps, to notice a bit.
06:04:48 <anish__> Hi!
06:05:52 <paragan> hi
06:07:06 <tagoh_> okay, let's get started.
06:07:14 <tagoh_> #topic Upcoming schedule
06:07:14 <tagoh_> #info 2013-09-17        Alpha Release
06:07:15 <tagoh_> #info 2013-10-08        Software Translation Deadline
06:07:15 <tagoh_> #info 2013-10-08        Beta Change Deadline
06:07:16 <tagoh_> #info 2013-10-08        Accepted Changes 100% Complete
06:08:20 <tagoh_> as you may read an announcement at devel-announce, we are facing alpha change freeze now. you need to file a request on bodhi to push your updates to f20 now.
06:08:26 <pravins> hi
06:08:57 <smaitra> hello everybody!
06:09:38 <tagoh_> #topic Outstanding topics
06:09:39 <tagoh_> #info #23: Fedora 20 i18n test day (tagoh)
06:09:39 <tagoh_> #link https://fedorahosted.org/i18n/ticket/23
06:10:00 <tagoh_> well, no updates for schedule yet. waiting for some response at QA ticket now.
06:10:22 <tagoh_> other than that, we may need to revisit our test cases to see if we may need to update
06:11:37 <tagoh_> https://fedoraproject.org/wiki/Test_Day:2013-05-02_Internationalization?rd=Test_Day:2013-05-02_Localization_(i18n)#Test_Cases_and_Results
06:12:18 <tagoh_> please check test cases you are responsible and good to try once if it's testable on f20.
06:12:40 <pravins> tagoh_: yes sure
06:13:11 * smaitra will have a look on it and review!
06:14:22 <tagoh_> that would be nice if you can add a comment on the ticket once you finished a review. so we can keep it on track even if it doesn't need to be updated.
06:15:43 <tagoh_> any comments on that?
06:18:49 <tagoh_> no deadline for reviews so far because we can't exactly fix the schedule yet. but may be good to finish by early October according to our proposal.
06:19:20 <juhp> yes
06:19:43 <tagoh_> if no objections on this plan, let's move on.
06:21:51 <tagoh_> #info #24: Fedora 20 i18n docbeats (tagoh)
06:21:51 <tagoh_> #link https://fedorahosted.org/i18n/ticket/24
06:22:47 <tagoh_> no updates on relnotes yet. we don't have any notes in this release perhaps?
06:23:07 <juhp> wonder if we need something for wayland preview
06:23:26 <tagoh_> aha
06:25:19 <tagoh_> any visible changes in ibus regarding wayland?
06:27:17 <tagoh_> fujiwarat, dueno: ^
06:28:18 <dueno> guess no
06:28:47 <tagoh_> okay
06:28:54 <dueno> https://bugzilla.gnome.org/show_bug.cgi?id=698307#c13
06:29:31 <tagoh_> sure
06:29:49 <tagoh_> anything else we may want to add?
06:33:08 <tagoh_> if not so far, will move on then
06:33:21 <tagoh_> #topic Open Floor
06:33:34 <tagoh_> any other topics we want to discuss/share in this meeting?
06:34:37 <mfabian> Is it possible to display a candidate list in ibus at a fixed position?
06:35:08 <mfabian> I.e. not at the current cursor position but for example "always in the lower left corner of the screen", "always in the panel", ... or something like this?
06:35:39 <anish__> Or can we get rid of candidate list completely>
06:36:10 <tagoh_> anish__: what's an alternative for that?
06:36:19 <fujiwarat> No, ibus cannot.
06:36:44 <anish__> tagoh_: Not sure,But it annoys a lot
06:37:10 <anish__> specially for prediction,when you type space and still you want to show some suggestions
06:37:14 <juhp> you mean in browser with suggestions?
06:37:15 <mfabian> Some people I discussed ibus-typing-booster with were annoyed about the candidate list constantly popping up.
06:38:03 <mfabian> Yes, in the browser it hides the Google suggestions, the i-t-b candidate list can be easily toggled with TAB to see the browser suggestions though.
06:38:11 <mfabian> sassmann: are you reading this?
06:38:13 <anish__> juhp: No! e.g after typing word and you press space you want to show suggestions so that you don't have type next word
06:38:41 <mfabian> sassmann: we discussed this recently, you were very much annoyed by the candidate list popping up always at the  cursor position.
06:38:50 <sassmann> morning mfabian, let me catch up
06:39:11 <mfabian> Swiftkey on Android shows suggestions even if no character has been typed so far, based on the previous input.
06:39:43 <mfabian> We could do that in ibus-typing-booster as well, it is a nice feature, but then the candidate list would pop up even more often and annoy some users even more.
06:40:06 <sassmann> mfabian: I jjust joined and might be missing the beginning of the discussion
06:40:22 <mfabian> Swiftkey on Android does not have that problem because the candidate list is fixed size just above the virtual keyboard and does not flicker.
06:40:32 <epico> mfabian, the candidate positions is sent by applications.
06:40:40 <mfabian> So it does not hurt much, it is not so visually disturbing.
06:40:42 <pravins> still not very clear, so when we are planning to show candidate window?
06:41:02 <mfabian> So sassmann also suggested to have the candidate list in a fixed place.
06:41:09 <epico> mfabian, I think android is like caribou.
06:41:12 <pravins> we have option for toggle candidate windows on/off
06:41:17 <mfabian> I am also afraid this is currently not possible with ibus.
06:41:33 <fujiwarat> Then candidate list would not be needed?
06:42:01 <pravins> mfabian: considering Desktop uses, normally while typing i look towards cursor, so its natural to have candidate window there only
06:42:01 <mfabian> pravins: with TAB we can toogle the candidate list on/off, yes.
06:42:11 <epico> fujiwarat, maybe he mean the candidate list doesn't hide the chrome url suggestions...
06:42:39 <pravins> having cursor at one location and candidate window at bottom does not sound good from eye movement perspective
06:42:54 <mfabian> And ibus-typing-booster also has a feature to choose the minimun number of characters to type before the candidate list pops up to make it less disturbing for people like sassmann who want to complete only long words.
06:43:04 <anish__> epico: or can we show candidate suggestions somewhere else? any thoughts?
06:43:32 <pravins> mfabian: that is worth feature
06:44:01 <mfabian> pravins: yes, the obvious disadvantage of showing the candidate list not at the cursor position, but for example at the lower left corner of the screen is that your eyes have to move all the time between the cursor position and the far away candidate list.
06:44:06 <sassmann> on a desktop with a keyboard for me it only makes sense to use completetion for longer words as I'm typing 3-4 letter words faster than choosing a word from completion
06:44:13 <anish__> any wierd ideas?
06:44:14 <epico> anish__, I think wayland and caribou is an example.
06:44:29 <mfabian> Not so much a problem on the Android where the candidate list is in the middle of the screen right above the virtual keyboard.
06:44:43 <anish__> epico: for caribou we can show it just like Android does
06:45:12 <anish__> But for desktop,where to show?
06:45:15 <mfabian> For Japanese or Chinese, I think having the candidate list far away from the cursor would be inconvenient.
06:45:34 <tagoh_> how about adding an option to change the position for the candidate window?
06:45:38 <epico> anish__, I think so.
06:45:57 <mfabian> But if ibus-typing-booster, this maybe OK.
06:46:20 <tagoh_> or add an API to allow changing the behavior by the engine?
06:46:24 <pravins> i think having bug for this will be very useful. :)
06:46:25 <mfabian> Because users like sassmann apparently don’t want to look at the candidate list always anyway.
06:46:48 <mfabian> Yes, I think an option to choose a fixed position for the candidate window would be very nice.
06:47:33 <mfabian> If one could choose a fixed position, ibus-typing-booster could show predictions even of 0 characters typed and it would not be so annoying.
06:47:35 <pravins> i prefer it at cursor location only, since that is active area for me while typing
06:47:47 <sassmann> at least the candidate window shouldn't change position while typing a word otherwise you have to refocus the words all the time
06:48:23 <mfabian> a candidate list popping up already for 0 characters typed at the cursor position is *very* annoying. Constant visual flickering at the spot you are looking at.
06:48:42 <fujiwarat> Maybe a screenshot is needed.
06:48:51 <mfabian> sassmann: I was surprised when you mentioned that you don’t want the candidate list to move along with the cursor.
06:49:27 <epico> mfabian, iirc, some old ime supports a fixed position...
06:49:36 <sassmann> mfabian: I'm not against moving it, but keeping it in the same spot for the same word
06:49:58 <mfabian> sassmann: because for me that feels natural. It doesn’t move with the cursor in programs like xterm which do not support on-the-spot editing, so it does not move until a commit happens, but I always felt that to be a bad thing. And now sassmann wants exactly that ☺.
06:50:42 <sassmann> different people like different things :)
06:50:52 <pravins> sassmann: agree :)
06:51:23 <pravins> having this option will be good, but i will recommend not to change default setting
06:51:43 <mfabian> For Japanese, the candidate list is not very disturbing because until the user hits SPACE to convert, there is no candidate list at all. So in Japanese, there candidate list is not so much changing, changing contents, jumping around when one types more characters.
06:52:17 <mfabian> pravins: No, the default should not be changed but having an option to have the candidate list in a fixed position would be nice.
06:52:33 <epico> how about to ask chrome to give a different position, not at cursor?
06:52:40 <epico> just a random thought.
06:52:46 <mfabian> epico: chrome?
06:52:56 <mfabian> The google browser?
06:52:58 <epico> yes
06:53:00 <tagoh_> mfabian: depends on enabling/disabling prediction though
06:53:47 <anish__> yeah and most important thing for predictive input methods, users want to see suggestions for zero word
06:54:28 <sassmann> anish__: what suggestion do you want for 0-1 letters? there's simply too many options to make a good decision
06:54:40 <mfabian> I think when one wants something like next word prediction even when 0 characters have been typed so far, then one most likely will not want these predictions to show up at the cursor position. The candidates will be visible almost always in that case, so they should be somewhere where they are not so much  disturbing.
06:55:08 <pravins> i was wondering what it will be for zero word, but while discussing with anish understood, he is talking about word level predictionss
06:55:32 <pravins> so if one type "that" next prediction for 0 level will be "is"
06:55:57 <sassmann> pravins: so you mean a "full word prediction" ?
06:55:58 <anish__> sassmann: zero word means,when user types "We", he expects suggestions like "are,have"..
06:56:08 <mfabian> Yes, like if you type "We are playing " then the candidates "cricket, soccer" may already show up although no letter of the next word has been typed yet.
06:56:21 <sassmann> pravins: context sensitive
06:56:57 <mfabian> sassmann: that is what swiftkey does on Android, it suggests 3 possibilities for the next word already based on the last typed 2 words even when you have not typed a single character of the next word yet.
06:57:09 <pravins> yep, full word level prediction
06:57:54 <mfabian> Prediction of course becomes more precise the more letters have been typed already, but next word prediction based on the previous 2 words can already work reasonably well in many cases.
06:58:06 <sassmann> well that also sounds like something you want to be able to enable/disable
06:58:31 <mfabian> So it can be useful to set the option of the minimum number of characters to type before prediction is attempted to 0.
06:58:47 <mfabian> I introduced that option for sassmann, currently  it must be >= 1.
06:59:05 <pravins> mfabian: even for Indic typing booster it was >=2
06:59:24 <sassmann> I think it makes a big difference on what kind of device you are, with a real keyboard you probably won't need this, but with an on-screen keyboard it might be useful
06:59:26 <pravins> since, we cant give perfect prediction based on single character, as it was just from dictionary
06:59:37 <mfabian> I thought immediately about allowing 0 there, but postponed this because of the problem with the candidate list we are discussing here.
07:00:25 <mfabian> For 0, the candidate list pops up so often, *all* *the* *time*, then it must really be somewhere else, not at the cursor position, where the constant visibility of the candidate list does not hurt that much.
07:01:28 <sassmann> mfabian: the context sensitive word prediction with 0 letters sounds like a separate feature to me
07:02:19 <pravins> mfabian: agree with you for 0 level suggestion ..
07:02:22 <mfabian> If we could set an option in ibus to have the candidate list always in some corner or at some edge of the screen, or always somewhere (horizontally) in the panel maybe, that it would be possible to allow showing predictions for 0 characters typed.
07:03:36 <mfabian> sassmann: this context level prediction works already, it also works for 0 letters typed, I only forced the number of characters to be >=1 because I did not have a good idea how to make that candidate list not so disturbing if it constantly pops up.
07:04:27 <sassmann> mfabian: that is a big issue indeed
07:05:06 <fujiwarat> Maybe a screenshot is needed. Normally I disable input method when I use brower's suggestion.
07:05:25 <mfabian> sassmann already found it disturbing to pop up for 1 character typed, he said he wants it to show up only for a larger number of characters type, say >= 4 characters typed. So if showing it for 1 character typed already annoys sassmann, then showing it for 0 characters typed will be completely unacceptable for sassmann.
07:06:09 <mfabian> fujiwarat: this is not so much about hiding the browser suggestions, more about the list showing  up all the time.
07:06:17 <sassmann> as I said, on a real keyboard my use-case is only to complete long words and possibly help out with the spelling
07:06:52 <mfabian> fujiwarat: In Japanese, you type にほんご and see no candidate list.
07:07:10 <mfabian> Even after typing space once, I  see 日本語 and still no candidate list.
07:07:23 <mfabian> After typing space for the second time, I see a candidate list.
07:07:57 <mfabian> So for Japanese, the candidate list doesn’t disturb much.
07:08:53 <mfabian> But for a word predicting input method, the candidate list pops up immediately and then changes contents for every additional letter typed. I.e. it constantly flickers and moves.
07:10:33 <epico> mfabian, how about to add a delay time option?
07:11:10 <mfabian> epico: I don’t think a delay helps, ibus-typing-booster should improve typing speed, not make it slower.
07:11:46 <mfabian> With a delay, one would need to wait each time to select.
07:11:47 <epico> mfabian, I mean delay the candidates pops up time.
07:12:17 <mfabian> I.e. when trying to type "I love cricket", type "I", wait the delay, select "love", wait, select "cricket".
07:12:37 <pravins> epico: i think delay here means wait for users to type some characters.. which is presently 1/2.
07:13:08 <epico> pravins, yes, about 0.3s.
07:13:24 <epico> or 0.5s...
07:13:25 <mfabian> With a delay of maybe one second to show the candidate list, typing "I love cricket" would take more than 3 seconds just because of this.
07:13:53 <mfabian> Maybe a very small delay like 0.1 s would be OK, not sure. Maybe I should experiment with adding a delay option.
07:13:58 <fujiwarat> Showing two candidate windows of flicker and input method is not useful?
07:14:17 <mfabian> epico: thinking about this, a small delay might reduce flicker considerably for fast typists.
07:14:42 <epico> mfabian, yes, and some IDE uses this technique.
07:14:52 <mfabian> fujiwarat: I do not understand that question.
07:16:46 <tagoh_> epico: true. but I suppose that makes a slow for users who wants to use the candidate list. I guess it isn't what one expects here?
07:17:23 <mfabian> tagoh_: yes, I am also afraid a delay might make it feel slow.
07:17:42 <tagoh_> and saying that the fixed position would a workaround for that issue IIRC
07:17:45 <epico> how about to allow the user adjust the delay time?
07:17:48 <mfabian> But maybe a 0.1s delay is acceptable and may reduce flicker a lot for people who type fast.
07:18:07 <mfabian> Yes, if a delay is added, it *must* be an adjustable option.
07:18:22 <epico> mfabian, right.
07:19:14 <tagoh_> mfabian: I think you should file an RFE for that if you didn't do that yet.
07:19:35 <mfabian> If I am typing along with high speed, then I may not want to see suggestions at all, but if I hesitate a bit, it would be nice for the candidates list show up. So such a delay option might be a very useful thing.
07:19:44 <mfabian> epico: thank you for the idea!
07:20:02 <epico> mfabian, welcome :)
07:20:33 <tagoh_> maybe good to move the discussion outside the meeting if we may need more time.
07:20:42 <mfabian> For the show candidate  list already when 0 characters are typed it would not help much though, for that case, a fixed position option of the candidate list seems almost necessary.
07:21:17 <mfabian> Ah, sorry for disturbing the meeting, it was so convenient because everybody happened to be in the channel already, even sassmann.
07:21:51 <mfabian> tagoh_: I think I file an RFE for a fixed position candidate list, yes.
07:22:08 <sassmann> mfabian: +1
07:22:18 <tagoh_> thanks for bringing this up and sharing. it is quite interesting topic to discuss. suppose we have some idea to address this with it.
07:23:13 <tagoh_> let's finish the meeting here then.
07:23:24 <mfabian> OK, thank you all!
07:23:30 <tagoh_> thanks everyone for the meeting and very useful discussion!
07:23:37 <tagoh_> #endmeeting