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