i18n
LOGS
06:05:05 <tagoh_> #startmeeting i18n
06:05:05 <zodbot> Meeting started Thu Sep 26 06:05:05 2013 UTC.  The chair is tagoh_. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:05:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
06:05:05 <tagoh_> #meetingname i18n
06:05:05 <zodbot> The meeting name has been set to 'i18n'
06:05:05 <tagoh_> #topic agenda and roll call
06:05:06 <tagoh_> #link https://fedoraproject.org/wiki/I18N/Meetings/2013-09-26
06:05:31 <tagoh_> sorry for a bit late start. shall we have i18n meeting now
06:05:32 <paragan> hi
06:05:33 <dramsey> ;)
06:05:37 <anish_> Hi!
06:05:50 <mfabian> Hi!
06:05:55 <pravins> hi
06:06:01 <fujiwarat> hi
06:07:26 <skore> hi
06:09:15 <tagoh_> okay, let's get started then.
06:10:03 <tagoh_> #topic Upcoming schedule
06:10:04 <tagoh_> #info 2013-10-08        Software Translation Deadline
06:10:04 <tagoh_> #info 2013-10-15        Beta Change Deadline
06:10:04 <tagoh_> #info 2013-10-15        Accepted Changes 100% Complete
06:10:05 <tagoh_> #info 2013-10-29        Beta Release
06:10:47 <tagoh_> no particular topics for schedule so far unless I'm missing anything else.
06:11:20 <epico> hi
06:11:34 <tagoh_> #topic Outstanding topics
06:11:34 <tagoh_> #info #24: Fedora 20 i18n docbeats (i18n@lists.fedoraproject.org)
06:11:35 <tagoh_> #link https://fedorahosted.org/i18n/ticket/24
06:13:02 <tagoh_> just a reminder; wiki freeze for beta is coming in 2 weeks if anyone is planning to add something related to i18n topics, please update.
06:13:40 <juhp> so soon
06:14:08 <tagoh_> right
06:15:02 <epico> ibus-rime is in f18, dunno whether too late to mention it?
06:15:27 <pravins> tagoh_: regarding Docs Beta
06:15:42 <pravins> i was just thinking on morning that what changes we suppose to add there
06:15:46 <pravins> any guideline for that?
06:16:03 <tagoh_> epico: guess so. no news for f20?
06:16:32 <pravins> hmm, no public etherpad for Fedora :(
06:16:37 <epico> tagoh_, not
06:17:42 <tagoh_> pravins: https://fedoraproject.org/wiki/Docs_Project_workflow_-_beat_writing#The_actual_writing maybe does it help?
06:18:09 <pravins> tagoh_:  how about having something like http://fpaste.org/42331/13801762/  ?
06:20:46 <tagoh_> pravins: well, thought it would be obvious thing for relnotes.
06:20:57 <pravins> yeah, agree
06:21:20 <pravins> still thought having it written somewhere will be good, so one cant miss points while writing for Docs Beat
06:22:18 <tagoh_> pravins: there are some links in the ticket for references. if it's worth documented somewhere after reading them, maybe good to suggest that to docs team I think.
06:22:53 <pravins> tagoh_: no problem, i will go through it
06:23:02 <tagoh_> it's not what we should have own guidelines IMHO.
06:23:16 <juhp> any new i18n packages?
06:24:37 <pravins> juhp: fonts, and some others
06:24:49 <pravins> imes, fonttools etc.
06:25:29 <pravins> tagoh_: yeah, i got your point.
06:25:31 <tagoh_> yeah, good to announce/advertise new packages there if any
06:28:27 <tagoh_> okay, guess better move on then?
06:28:59 <tagoh_> #info #25: Bugs Corner (i18n@lists.fedoraproject.org)
06:28:59 <tagoh_> #link https://fedorahosted.org/i18n/ticket/25
06:29:55 <tagoh_> no URLs added this week and last one is now on VERIFED. so any bugs we may want to highlight here?
06:33:30 <tagoh_> okay, move on then
06:33:43 <fujiwarat> ibus 1.5.4 can enable IME state per input focus for non-GNOME.
06:34:01 <epico> cool
06:34:08 <anish_> fujiwarat, IME state per input focus means?
06:34:59 <fujiwarat> IME per input context?
06:35:05 <juhp> do we have docbeat template now?
06:35:31 <juhp> nope ;)
06:35:45 <fujiwarat> Maybe good idea.
06:36:00 <juhp> might good to add some headers to encourage people to write under...
06:36:21 <tagoh_> juhp: reminds me we talked about same thing in last meeting... doh
06:36:25 <juhp> yes
06:36:41 <tagoh_> juhp: can you add it?
06:36:45 <juhp> alright
06:37:13 <juhp> I thought you were going to :)
06:37:47 <tagoh_> yeah.. missed that sorry
06:37:54 <juhp> okay I added a couple - np
06:38:06 <tagoh_> thanks
06:38:56 <tagoh_> fujiwarat: wasn't that supported before?
06:39:07 <fujiwarat> Also man page ibus.conf(5) is added as Fedora internal patch if you have feedback.
06:39:18 <juhp> aha
06:40:12 <juhp> in 1.2 perhaps or earlier?  I guess it is new feature for current ibus
06:40:29 <tagoh_> is it enabled by default?
06:40:32 <fujiwarat> tagoh_: It had not been since ibus 1.5.0 to follow GNOME but now GNOME has the ability and ibus is also updated in 1.5.4.
06:40:44 <juhp> aha
06:40:45 <tagoh_> aha
06:40:49 <fujiwarat> tagoh_: No, it's not by default.
06:40:54 <tagoh_> okay
06:40:55 <juhp> so 1.4 had it?
06:41:13 <fujiwarat> juhp: Yes, it did.
06:41:17 <juhp> ok
06:41:28 <fujiwarat> The default is still the global engine mode.
06:41:50 <epico> fujiwarat, guess gnome and ibus both have implemented this feature?
06:41:53 <juhp> I think that is ok
06:42:24 <fujiwarat> epico: Yes, it is.
06:42:39 <epico> fujiwarat, thanks, I see.
06:43:20 <tagoh_> okay, anything else?
06:45:05 <tagoh_> let's move on
06:45:17 <tagoh_> #topic Outstanding task
06:45:17 <tagoh_> #info #23: Fedora 20 i18n test day (i18n@lists.fedoraproject.org)
06:45:18 <tagoh_> #link https://fedorahosted.org/i18n/ticket/23
06:46:30 <tagoh_> well, our plan on i18n test day seems conflict with graphics test and being proposed to move to October 29th and ack'd on it. not yet updated on test day page though.
06:47:55 <juhp> ok
06:48:45 <tagoh_> anyway, due date for review on the plan is coming soon. please start to work on it if not yet
06:49:14 <tagoh_> for your responsible test cases
06:49:45 <juhp> are people clear about which cases they need to review?
06:49:53 <tagoh_> volunteers and double-check are always welcome.
06:50:19 <juhp> yeah probably good for QA also to look over them
06:50:42 <tagoh_> juhp: expecting to do that for own packages at least and/or any interests
06:50:59 <juhp> yes
06:52:34 <tagoh_> those test cases are referred for regression testing on bodhi by testers so it has to keep up-to-date.
06:54:31 <tagoh_> I suppose you all more or less has test cases needs to review anyway
06:55:34 <tagoh_> any questions or comments?
06:57:41 <tagoh_> okay
06:57:46 <tagoh_> #topic New topic
06:57:46 <tagoh_> #info #26: proposal: move to using IMEs for ASCII/Latin input (petersen)
06:57:47 <tagoh_> #link https://fedorahosted.org/i18n/ticket/26
06:59:15 <tagoh_> juhp: details are mentioned at the ticket though, do you want to summarize that?
06:59:22 <mfabian> Isn’t that something the Gnome designers did not like at all?
06:59:27 <juhp> sure
06:59:34 <mfabian> The Latin input mode in kkc for example?
06:59:47 <mfabian> I agree with Jens that it is useful.
06:59:51 <juhp> okay
07:00:02 <juhp> maybe I can summarize first :)
07:00:13 <mfabian> Sorry ...
07:00:17 <juhp> np
07:00:50 <juhp> actually I have been using kkc like this for quite a while so it seems kind of "obvious" to me...
07:01:17 <juhp> ueno told me that the latest kkc supports setting keyboard layout too
07:01:25 <juhp> anyway to explain...
07:02:08 <juhp> currently we use xkb layouts (or input sources) for inputting ascii/latin/"english" etc
07:02:27 <juhp> and for asian langs switch to an IME to input them
07:02:58 <juhp> at least the kkc and libpinyin engines support Latin (direct) input
07:03:47 <juhp> so my suggestion is that for languages where the primary engine supports Latin we don't use switching to xkb layout by default but just toggle the IME between latin and native text input
07:04:13 <juhp> further it would be good to extend some other IMEs to also support Latin input I feel
07:04:23 <juhp> but that might be less urgent
07:04:53 <tagoh_> just remember we had similar discussion before when scim was default IM and happy to see that again :) wb
07:04:58 <juhp> I think I started doing this from f18 perhaps and it works well for me at least
07:05:09 <juhp> tagoh_, right :)
07:05:24 <juhp> that time we were trying to push for all IMEs to support this for consistenct
07:05:25 <juhp> y
07:05:35 <juhp> I think that would still be a good longer term goal
07:06:05 <tagoh_> so then what was the reason it wasn't going to launch for all engines
07:06:11 <juhp> anyway this proposal is targetting F21 I suppose - I think it is already late for F20 to make this change
07:06:28 <tagoh_> need to remember that and think about that perhaps
07:06:37 <juhp> hmm yeah
07:07:05 <juhp> I think maybe we were trying all or nothing approach and another issue might have been hotkey
07:07:08 <tagoh_> I agree with this idea though
07:07:14 <juhp> okay
07:08:06 <juhp> it might also need ibus applet to support input status
07:08:25 <juhp> I haven't thought deeply about the actual integration process
07:09:48 <juhp> I think during the f19 devel cycle (perhaps?) I was only getting Japanese IME input source and that helped me to realise that this is quite possible and works fine
07:10:05 <juhp> so any thoughts on next steps?
07:10:20 <tagoh_> it could be kind of the feature in engine and not sort of all or nothing IMHO. but nice-to-have in all engines maybe.
07:10:34 <juhp> I know we are in the middle of the f20 cycle so maybe not best timing to move forward though we could already start it for rawhide I suppose
07:10:38 <mfabian> Does that really need to be integrated? Because the  extra  keyboard doesn’t really hurt and a user who wants to switch to Latin input by only using kkc can easily do it right now already.
07:10:56 <juhp> hmm
07:11:07 <juhp> so nothing to do? :)
07:11:19 <juhp> well the proposal was actually to make this the default...
07:11:22 <tagoh_> just to propose the feature for engines not having that yet?
07:11:28 <juhp> hmm
07:11:42 <juhp> that needs to be done upstream I suppose
07:11:45 <mfabian> Certainly keep that feature in ibus-kkc! I could not understand why the designers did not like that.
07:12:16 <tagoh_> juhp: to remove non-ibus keyboard layout by default you mean?
07:13:19 <juhp> so if one does a ja or zh_CN install/desktop one could end up with just IME by default yes
07:13:40 <juhp> epico, any comments from pinyin perspective?
07:13:59 <mfabian> Are the keybindings to switch in ibus-kkc between the different modes known by everybody?
07:14:19 <juhp> shrug maybe
07:14:28 <juhp> they are in ibus-setup-kkc at least
07:14:51 <mfabian> Most users probably know the Super+Space to go to the next input method, but the keybindings in ibus-setup-kkc are probably less well known.
07:14:54 <epico> juhp, this feature is used frequently in ibus-libpinyin.
07:14:54 <tagoh_> mfabian: same for Windows and something we had before. so yes
07:15:01 <juhp> this might also help to tighten coupling of engines are kbd layouts perhaps
07:15:13 <juhp> mfabian, right
07:15:18 <mfabian> And probably these keybindings are different in pinyin?
07:15:25 <juhp> I suppose so
07:15:45 <epico> mfabian, the keybindings is configurable in ibus-libpinyin.
07:15:53 <juhp> also in kkc
07:16:18 <juhp> so does it come to keybindings perhaps
07:16:38 <mfabian> By the way, in ibus-kkc “Direct input” and “Latin” seems to show the same symbol “_A” in the panel.
07:16:45 <epico> in gnome-control-center ?
07:16:46 <juhp> right
07:16:56 <mfabian> Although it is not exactly the same thing.
07:17:22 <juhp> Latin converts to katakana?
07:17:47 <mfabian> No, both input Latin.
07:18:00 <juhp> so what is the difference actually?
07:18:55 <mfabian> With “Direct input”, there is no preëdit, an “a” gets inserted immediately.
07:19:05 <juhp> yes Latin can do katakana conversion
07:19:08 <juhp> and completion
07:19:16 <juhp> with Tab
07:19:23 <juhp> and space
07:19:47 <juhp> I like that feature a lot - comes from skk I guess
07:19:48 <mfabian> In "Latin" mode you can do the katakana conversion or conversion to something like α
07:20:23 <anish_> juhp, does it show more than one candidate using tab?
07:20:59 <juhp> mfabian, try typing "computer" and space
07:21:03 <mfabian> anish_: It toggles through the candidates in preëdit when typing TAB
07:21:09 <juhp> right
07:21:17 <juhp> mfabian, ah yes
07:21:35 <mfabian> I played with this way of showing the candidates in LibreOffice as well.
07:21:46 <tagoh_> well, looks like better postponing the discussion to the next meeting
07:21:57 <mfabian> *Maybe* we could offer this as an additional option in the UI of ibus-typing-booster.
07:22:05 <juhp> anyway I guess my point is if one one input source then no need for Super-Space
07:22:27 <mfabian> Libreoffice has an option to show the candidates as a popup (like the lookup table in ibus) or in the preëdit.
07:22:47 <juhp> tagoh_, sure we can continue to discussing this topic - probably need more time to weigh it
07:22:54 <mfabian> Yes, if the user knows that input method well, there would be no need for Super-Space.
07:22:59 <tagoh_> juhp: yes
07:23:15 <mfabian> I could type German, English, and Japanese just fine using ibus-kkc.
07:23:24 <juhp> mfabian, if they don't they can use the mouse to change mode
07:23:55 <tagoh_> so let's close this topic here and continue to discuss in next meeting
07:23:55 <mfabian> But of course I will always have other input methods enabled and switch from time to time.
07:24:02 <juhp> I think it support standard bindings like Hankaku_Zenkaku and Alt-`
07:24:02 <tagoh_> #topic Open Floor
07:24:19 <mfabian> Alt-` doesn’t work for me!
07:24:39 <juhp> mfabian, right multiple IME might need xkb too
07:24:43 <tagoh_> so anything else we are missing or we may want to discuss other than the above?
07:24:51 <anish_> if we have time then we can discuss  "http://anish-patil.blogspot.in/2013/09/need-design-help.html"
07:25:02 <anish_> otherwise we can take it on #fedora-i18n
07:25:20 <anish_> any thoughts?
07:25:25 <juhp> mfabian, doesn't work in some apps for sure
07:26:07 <tagoh_> anish_: can you summarize the point or maybe good to move to next meeting?
07:26:44 <mfabian> Alt+` switches to a different application, apparently this is some default in gnome-shell?
07:26:59 <anish_> not sure about how to show candidate in i-t-b for zero length input from user
07:27:09 <anish_> we need design for that
07:27:17 <mfabian> As there are so many keybindings in ibus-kkc, there is a lot of potential for collision.
07:27:40 <mfabian> anish_: I thought about this again and *maybe* the preëdit solution is not so bad as one option.
07:28:04 <mfabian> I still have  no idea how to select candidates though when a lookup table is used.
07:28:10 <juhp> mfabian, right
07:28:17 <anish_> mfabian, umm personally i don't like it much
07:28:27 <tagoh_> anish_: sounds like not a quick topic to think about. maybe good to discuss it later.
07:28:30 <mfabian> If the candidates are selected using numbers, it becomes impossible to type numbers if the lookup table is shown always:
07:28:39 <fujiwarat> I have some information.
07:28:53 <fujiwarat> https://docs.google.com/document/d/1X4SBZM44ZIWM7s8_dgKw51aZfw0amp3fsqLVUPty5Gs/edit#heading=h.fl2vj834e2hp
07:29:06 <tagoh_> anish_: can you open a ticket so that I can pick up in next meeting please?
07:29:18 <mfabian> anish_: I would not offer the preëdit thing as the only option, but having that as an option to choose in the setup would be nice, I think.
07:29:26 <anish_> tagoh_, thanks! i will open a ticket
07:29:32 <tagoh_> anish_: thanks
07:30:17 <mfabian> fujiwarat: Do we need to do something there?
07:30:28 <fujiwarat> GNOME AppData will be integrated. If you wish to update data for ibus ime, it's good to have pull request in github.
07:30:43 <anish_> mfabian, for GNOME software AppData i have added few input methods from ibus-tables-others
07:31:11 <fujiwarat> Probably name, description would be good to be reviewed.
07:31:20 <tagoh_> aha
07:32:09 <fujiwarat> Probably each IME need to ship appdata.xml in f21.
07:32:47 <tagoh_> guess all package owner for engines needs to review that then?
07:32:57 <fujiwarat> Right.
07:33:50 <fujiwarat> Now ibus supports the system cache. If your IME is installed by default, it's good to have ibus command in %post and %postun.
07:33:58 <fujiwarat> http://pkgs.fedoraproject.org/cgit/ibus-anthy.git/tree/ibus-anthy.spec#n105
07:34:08 <tagoh_> #action all ibus engine package owners to review https://docs.google.com/document/d/1X4SBZM44ZIWM7s8_dgKw51aZfw0amp3fsqLVUPty5Gs/edit#heading=h.fl2vj834e2hp
07:34:40 <tagoh_> fujiwarat: what happens if one doesn't do that?
07:35:04 <fujiwarat> Then, local cache will be created when ibus-daemon is running.
07:35:42 <anish_> fujiwarat, when local cache will be cleared?
07:36:11 <fujiwarat> When ibus-daemon is running and an IME is added or removed.
07:36:59 <fujiwarat> The local cache is same in f19. The system cache can enhance the performance.
07:37:07 <anish_> fujiwarat, thanks
07:37:37 <fujiwarat> ibus 1.5.4 supports input purpose for gnome-shell password. It's good to implement it in each IME:
07:37:42 <fujiwarat> https://github.com/ibus/ibus-anthy/commit/6aae0a9f145f536515e268dd6b25aa740a5edfe7
07:38:24 <tagoh_> is this system cache thing supported from 1.5.4?
07:38:35 <fujiwarat> tagoh_: It's from 1.5.3.
07:39:03 <mfabian> fujiwarat: thank you, that’s nice!
07:39:17 <anish_> yeah, thanks!
07:39:22 <tagoh_> hmm, so similar fix is necesasry for f18 and f19 to improve the performance?
07:39:54 <fujiwarat> Yes, if you like. ibus 1.5.4 is ready in f18 and f19.
07:41:41 <tagoh_> sure. maybe good to file a bug for engines not doing that yet
07:42:32 <tagoh_> fujiwarat: can you pick up and file a bug for them?
07:42:56 <mfabian> fujiwarat: What happens when this code is used with ibus < 1.5.4? It doesn’t hurt right? Only do_set_content_type() is probably never called then, so it probably just does nothing for ibus < 1.5.4. I.e. that code can be used unconditionally.
07:43:58 <fujiwarat> ibus 1.5.3 returns FALSE anyway instead of send the key events to engines if the input purpose is password.
07:45:36 <tagoh_> anything else before stop?
07:45:59 <dramsey> 8-)  tagoh_ , thank you for chairing.  FYI, I would like to assist as a tester with Fedora 20 i18n test day.  Sending positive Fedora energy from all my computers to all yours.  eof  8-)
07:46:22 <tagoh_> dramsey: thanks :)
07:48:01 <fujiwarat> mfabian: The patch of ibus-anthy checks if IBus.InputPurpose exists.
07:49:14 <mfabian> fujiwarat: Ah, I see it now!
07:49:18 <tagoh_> okay, let's stop here then
07:49:25 <tagoh_> thanks everyone for your participation!
07:49:29 <tagoh_> #endmeeting