06:01:45 <tagoh_> #startmeeting i18n
06:01:45 <zodbot> Meeting started Thu Jul  4 06:01:45 2013 UTC.  The chair is tagoh_. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:01:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
06:01:45 <tagoh_> #meetingname i18n
06:01:45 <zodbot> The meeting name has been set to 'i18n'
06:01:46 <tagoh_> #topic agenda and roll call
06:01:47 <tagoh_> #link https://fedoraproject.org/wiki/I18N/Meetings/2013-07-04
06:02:03 <tagoh_> hi, shall we have a meeting?
06:02:25 <mfabian> Hi!
06:02:34 <paragan> hi
06:02:45 <fujiwarat> hi
06:06:08 <juhp> hi
06:06:31 <dueno> hi
06:06:35 <pravins> हि
06:06:35 <tagoh_> okay, let's get started.
06:06:39 <pravins> hi
06:07:23 <tagoh_> #topic Upcoming schedule
06:07:24 <tagoh_> #info 2013-07-16        Change Proposals Submission Deadline
06:08:21 <tagoh_> any planning for changes has to be submitted within about 2 weeks
06:09:14 <tagoh_> other schedule is still in draft. guess it will be fixed soon
06:09:45 <tagoh_> #topic Outstanding topics
06:09:45 <tagoh_> #info #20: Fedora 20 Planning (tagoh)
06:09:45 <tagoh_> #link https://fedorahosted.org/i18n/ticket/20
06:10:28 <tagoh_> so we don't have so much time for that though, anyone has any plans of changes in f20?
06:10:55 <tagoh_> I don't think we need to do it for trivial changes though.
06:12:47 <pravins> nothing big plan yet, but may be would like to add couple of packages into Fedora
06:12:57 <pravins> one of that is  ibus-avro
06:13:01 <tagoh_> aha
06:13:03 <juhp> it would be good to have something - also to learn the new Change workflow though should be similar to Features
06:14:09 <tagoh_> pravins: if it affects a lot for users, we should do. otherwise relnotes may be a good place for that.
06:14:47 <pravins> tagoh_: yeah, this change is part of relnotes ;)
06:16:20 <tagoh_> changing default behavior may be a good example for this process I guess. we can get feedback about an idea before taking an action.
06:18:04 <juhp> also new features
06:18:10 <tagoh_> right
06:19:11 <juhp> not sure if there will be more Changes than Features or less - my impression is that part of the change was to widen the scope
06:22:35 <tagoh_> it's not limited to features only now so we have an opportunity to ask for feedback before messing up...
06:23:20 <pravins> yes and one is that getting more concern about only changes/feature affecting whole system
06:26:28 <tagoh_> anyway, we may want to keep something on track as usual if we have something. so if you have any idea, feel free to update the ticket. we can discuss it here in next meeting
06:27:08 <juhp> yes
06:27:43 <tagoh_> okay, move on then
06:27:53 <tagoh_> #info #21: Compare different Desktop Environments in Fedora 19 (pnemade)
06:27:53 <tagoh_> #link https://fedorahosted.org/i18n/ticket/21
06:28:25 <tagoh_> as per comment, I think we don't have anything we can discuss ATM?
06:29:02 <tagoh_> #topic New topic
06:29:02 <tagoh_> #info #22: Fedora 17 bugs cleanup (tagoh)
06:29:03 <tagoh_> #link https://fedorahosted.org/i18n/ticket/22
06:30:04 <tagoh_> so it's time to triage f17 bugs. we have 42 bugs open now
06:31:20 <tagoh_> I encourage you to check your bugs first this time and see some activities on f17 bugs by next meeting.
06:33:41 <tagoh_> I'm thinking triaging own bugs in 2 weeks and other i18n bugs in other 2 weeks.
06:33:50 <tagoh_> any comments?
06:34:42 <tagoh_> of course if you don't have less own bugs, you can help others :)
06:36:25 <juhp> +1
06:37:21 <pravins> moved one of my bug to F19 :)
06:37:43 <tagoh_> :)
06:39:19 <tagoh_> okay, let's do so then.
06:40:23 <tagoh_> #action all to triage own f17 bugs in 2 weeks and other f17 bugs in other 2 weeks
06:40:27 <tagoh_> #topic Open Floor
06:40:37 <tagoh_> anything else we want to discuss in this meeting?
06:41:21 <pravins> tagoh_: yeah
06:41:32 <pravins> regarding ibus-typing-booster
06:41:38 <tagoh_> sure. go ahead
06:41:39 <pravins> mfabian: hi
06:42:10 <pravins> presently we are not committing preedit buffer if someone press punctuation marks
06:42:38 <pravins> i think we should commit typed word to open application if someone press ".", ","  ":"  example
06:42:59 <mfabian> I am not sure because these characters could still combine with the next character.
06:43:02 <pravins> i have followed same thing in ibus-sayura and ibus-rawcode
06:43:29 <mfabian> A . followed by a c could become ċ in Latin-Prefix input method.
06:43:44 <pravins> aha
06:43:51 <mfabian> Therefore, I strip these punctuation characters from the token after committing.
06:44:34 <pravins> in that case i think this becomes language specific
06:44:36 <juhp> so maybe it should be language dependent?
06:44:39 <juhp> yea
06:44:52 <mfabian> It could be done when transliteration is not used.
06:45:16 <mfabian> But apparently in many transliteration input methods, punctuation characters combine with something.
06:45:52 <mfabian> mr-itrans.mim for example contains: ("~N" "ङ्")
06:46:08 <mfabian> I.e. ~ can probably not be comitted directly when mr-itrans is used.
06:46:21 <pravins> right
06:46:35 <anish_> i think it would be good not to commit the word
06:46:36 <mfabian> Leading punctuation characters are directly committed *if* no transliteration is used.
06:46:42 <pravins> yes there are some combinations even starts with "."
06:47:16 <pravins> hmm, this makes it complex :)
06:47:21 <mfabian> If transliteration is used, leading punctuation is not directly committed either because one has to wait whether it is used in transliteration.
06:47:27 <pravins> s/complex/complex issue
06:48:36 <pravins> but might be english language user will not like buffering "." He will more happy to see new preedit starts
06:48:48 <juhp> right
06:49:21 * juhp thinks again we need better Indic IME and transliteration
06:49:25 <mfabian> Yes, maybe I could do it the same way as with the leading punctuation, commit directly if no transliteration is used.
06:51:12 <pravins> yes
06:51:15 <pravins> we can give try
06:52:26 <pravins> but issue raised by you is very valid, if we cant process "."  one cant type  some  combinations forever;)
06:53:07 <mfabian> I've put it on my todo list do commit such punctuation directly if no transliteration is used.
06:53:36 <pravins> mfabian:  i will also report RFE for it, may be it will also help to discuss if any particular issue
06:53:52 <mfabian> pravins: Thank you!
06:53:58 <pravins> thanks, done with my query :)
06:54:11 <tagoh_> okay, anything else?
06:55:32 <mfabian> By the way, currently we add a " " when committing a word by typing TAB or by selecting a candidate in the lookup table. (Swiftkey on Android does this as well). But very often I don’t like that because I want to continue the current word. How do you like the space inserted when selecting a candidate from the lookup table?
06:58:07 <pravins> mfabian: yeah, its also debatable
06:58:10 <juhp> hmm yeah this is a common kind of problem - eg often plurals or other forms/endings of words might not be listed
06:58:37 <juhp> maybe there should be a way to commit without space?
06:58:40 <pravins> since sometime we get complete word in suggestion and getting auto space while committing save one extra keystroke
06:58:43 <mfabian> In German, nouns can often be combined without spaces, i.e. "car door" in German would be "Autotür"  without a space between "Auto" (= car) and "tür" (= door). Almost any nouns can be combined like that (even longer sequences of more than 2 nouns), so it is unlikely that such combinations are in some dictionary or database. So often I want to select a candidate which is a noun and then continue typing without a space.
06:58:43 <mfabian> to remove the automatically inserted space by backspacing.
06:59:03 <pravins> but sometime we need to type some extra characters so auto space is not expected
06:59:18 <juhp> true for German and Danish (etc?) might make more sense not to have space perhaps
07:00:11 <mfabian> Maybe it should be a checkbox option then.
07:00:16 <pravins> IMHO i think we should continue committing space considering that user will type complete word using typing booster so when next time he will time same word he will get better user experience ;)
07:00:23 <juhp> or language dependent again :)
07:00:44 <pravins> s/time/type
07:00:54 <juhp> mfabian, can space be used to commit?
07:01:07 <anish_> i don't know but giving too much options to users causes confusion
07:01:10 <pravins> we are using it for commit presently
07:01:12 <mfabian> Yes, space can be used to commit, it commits the current preëdit.
07:01:47 <mfabian> Committing the current preëdit by typing space should of course always insert the space as well.
07:01:51 <juhp> anish_, right
07:02:41 <juhp> okay
07:03:34 <pravins> this are interesting issues and we need some solution, lets think this week and discuss more on same in next meeting may be
07:04:50 <tagoh_> sounds goood
07:05:02 <mfabian> juhp: you wrote: “maybe there should be a way to commit without space?”
07:05:18 <mfabian> But it that would take an extra keystroke (e.g. Control) it would be useless.
07:05:25 <juhp> as in without committing a space :)
07:05:30 <juhp> hmm
07:06:12 <mfabian> So I thought of maybe making selecting a candidate via a number in the lookup table or TAB to commit without space. At least optionally.
07:06:58 <pravins> looks fare enough, but default behavior should commit "space"
07:07:31 <mfabian> In the long run, I think we want to use Pravin’s idea to not switch engines for each language. I.e. type German and English for example with the same engine. So making such behaviour language dependent would not work well then either.
07:09:25 <pravins> hmm
07:11:56 <tagoh_> anything else before closing this meeting?
07:15:09 <tagoh_> okay, if not, let's stop here then.
07:15:22 <tagoh_> thanks everyone for the meeting!
07:15:27 <tagoh_> #endmeeting