06:04:16 <tagoh_> #startmeeting i18n 06:04:17 <zodbot> Meeting started Wed Nov 20 06:04:16 2013 UTC. The chair is tagoh_. Information about MeetBot at http://wiki.debian.org/MeetBot. 06:04:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 06:04:17 <tagoh_> #meetingname i18n 06:04:17 <zodbot> The meeting name has been set to 'i18n' 06:04:17 <tagoh_> #topic agenda and roll call 06:04:17 <tagoh_> #link https://fedoraproject.org/wiki/I18N/Meetings/2013-11-20 06:04:23 <tagoh_> okay, shall we have i18n meeting? 06:04:29 <mfabian> Hi! 06:04:31 <skore> hi 06:04:46 <anish_> hi 06:05:02 <dueno> hi 06:08:28 <tagoh_> let's get started then 06:08:50 <tagoh_> #topic Upcoming schedule 06:08:50 <tagoh_> #info 2013-11-26 Final Change Deadline 06:08:51 <tagoh_> #info 2013-12-10 Fedora 20 Final Release 06:09:03 <tagoh_> final deadline is coming next Tuesday 06:10:55 <juhp> hi 06:11:34 <lijli> hi 06:13:22 <tagoh_> sorry got a crash on browser. 06:13:33 <paragan> hi 06:14:30 <tagoh_> anyway, we have three i18n-related final blocker. good to help them to get fixed by GA 06:14:31 <pravins> hi 06:15:29 <tagoh_> #topic Outstanding task 06:15:30 <tagoh_> #info #23: Fedora 20 i18n test day (i18n@lists.fedoraproject.org) 06:15:30 <tagoh_> #link https://fedorahosted.org/i18n/ticket/23 06:16:03 <tagoh_> thanks for updating with bz url. I've updated with final report and result pages with bz url 06:17:36 <tagoh_> we may need to polish test cases including nice-to-test things later but better having a chance earlier. 06:18:38 <tagoh_> will close this at this moment. 06:19:05 <juhp> thanks 06:19:20 <tagoh_> #topic Outstanding topics 06:19:21 <tagoh_> #info #25: Bugs Corner (i18n@lists.fedoraproject.org) 06:19:21 <tagoh_> #link https://fedorahosted.org/i18n/ticket/25 06:19:32 <tagoh_> any bugs we want to share today? 06:19:44 <juhp> I just posted one :) 06:19:55 <juhp> .bug 1031848 06:20:01 <zodbot> juhp: Bug 1031848 xkb-converted layouts do not include multiple mappings where they are commonly expected - https://bugzilla.redhat.com/show_bug.cgi?id=1031848 06:20:01 <tagoh_> ah, thanks 06:20:10 <juhp> well basically trying to understand the kbd status in f20 06:20:11 <juhp> mfabian, ? 06:20:49 <juhp> I think you had some related discussion with Adam on this iiuc 06:21:07 <mfabian> Added a patch by Adam to langtable yesterday night. 06:21:12 <juhp> aha 06:21:16 <juhp> cool 06:21:36 <juhp> kbd now uses keymaps ported from xkb? 06:21:39 <mfabian> (Adding some more keyboard layouts to have more informations which layouts can be used to input ASCII or not) 06:21:48 <juhp> aha good 06:21:55 <juhp> does it help? 06:21:59 <mfabian> Yes, kbd mostly uses keymaps converted from X11. 06:22:14 <juhp> since f20? 06:22:15 <mfabian> /usr/lib/kbd/keymaps/xkb/ 06:22:24 <mfabian> Since f20. 06:22:27 <juhp> okay 06:22:49 <mfabian> Old keymaps are still there for compatibility /usr/lib/kbd/keymaps/i386/ 06:22:58 <mfabian> Some are just symlinks to the converted X11 layouts. 06:22:59 <juhp> do you think it is all fixed now or are there residual problems? 06:23:05 <juhp> aha 06:23:09 <mfabian> There are residual problems. 06:23:13 <juhp> ok 06:23:28 <mfabian> .bug 1028207 06:23:34 <zodbot> mfabian: Bug 1028207 non US keyboard layouts not working at console - https://bugzilla.redhat.com/show_bug.cgi?id=1028207 06:23:57 <mfabian> Not sure whether that one works now, there was no progress until yesterday. 06:24:06 <mfabian> non-US layouts were not loaded at all. 06:24:06 <juhp> thanks - was looking for that one too 06:24:24 <juhp> I see 06:24:25 <mfabian> There was some activity yesterday, will check whether anything changed. 06:24:43 <mfabian> The langtable patch is for the problem that some layouts like "ru" cannot input ASCII. 06:25:00 <mfabian> On X11, we solve that by adding the "us" layout as well for such cases. 06:25:07 <juhp> seems there is a kbd test build 06:25:21 <juhp> right 06:25:24 <tagoh_> aha 06:25:32 <mfabian> The old vconsole keyboard layouts for "ru" had a switch to ascii, maybe similar to the group toggle in X11. 06:25:40 <juhp> ok 06:25:44 <juhp> and now? :) 06:25:49 <mfabian> But now, when "ru" is converted from X11, that is gone, so one can only input cyrillic. 06:25:58 <mfabian> Adam is trying to find a solution for that. 06:26:02 <juhp> okay 06:26:25 <juhp> seems like somehow the xkb layouts need to be combined in some way? 06:26:34 <mfabian> One part of this is making the list of keyboards langtable knows about (whether they support ASCII or not) more complete. 06:26:44 <juhp> ok yep 06:27:21 * juhp wonders though how much do people need native console input... 06:28:05 <juhp> wonder if there is a simple fix that could work for f20-final? 06:28:23 <juhp> but yes definitely a regression 06:29:02 <mfabian> I practically never use the vconsole. 06:29:46 <juhp> I use it occasionally but I never really do Japanese on the vconsoles ;o) 06:31:00 <juhp> mfabian, just wonder if not using ru keymap etc by default on console would be better for now 06:31:21 <mfabian> Maybe, I don’t really have an opinion there. 06:31:30 * tagoh_ reads comments 06:32:51 <mfabian> Biggest problem is probably maps like "de", "fr", "gb", ... which might cause the problem that people cannot even enter their disk encryption password when their national layout which they expect is not loaded. 06:33:50 <juhp> but they are all ascii with switching so no problem 06:33:56 <juhp> *without* 06:34:06 <mfabian> Yes, but currently they are not loaded. 06:34:18 <juhp> ah right 06:34:28 <juhp> that should be easier to solve one would think 06:34:54 <juhp> so that is the systemd issue right? 06:34:59 <juhp> .bug 981805 06:35:04 <zodbot> juhp: Bug 981805 localectl / localed should use matching kbd layout for xkb layout when available - https://bugzilla.redhat.com/show_bug.cgi?id=981805 06:35:07 <mfabian> So if a user expects a British keyboard there and has Shift+3 in his password, this needs to be a £ sign, not a #. 06:35:13 <juhp> maybe this? 06:35:17 <mfabian> (Adam stumbled over this). 06:35:24 <juhp> sure 06:35:51 <mfabian> We are not sure whether it is a systemd issue. 06:36:00 <mfabian> It looks more like a problem in initramfs. 06:36:11 * juhp wonders why all this was not noticeable earlier... 06:36:17 <juhp> hmm 06:36:31 <mfabian> loadkeys calls popen() using the gzip binary, the gzip binary is not in initramfs, the opening of the keymaps fails. 06:36:55 <juhp> nice 06:36:55 <mfabian> Not sure whether that is the only problem, but that is one of the problems I found when debugging. 06:37:13 <juhp> that's reported right? 06:37:24 <mfabian> Yes, that is in the bug above. 06:37:30 <juhp> cool 06:37:47 <juhp> sounds like this will help to slip final release anyway 06:38:04 <juhp> I mean all the kbd issues 06:38:44 <mfabian> “help”? That sounds as if slipping is a good thing ☺ 06:39:13 <tagoh_> so still needs more work even if installing new kbd and systemd? 06:39:19 <mfabian> “I love deadlines. I like the whooshing sound they make as they fly by.” — Douglas Adams 06:40:46 <mfabian> tagoh_: At the moment I think that the biggest problem (not loading any non-US keymaps at all) will be fixed soon by fixing that gzip problem and maybe some directory layout problem in initramfs. 06:41:24 <tagoh_> aha 06:41:34 <juhp> mfabian, :) 06:42:26 <juhp> mfabian, okay - the systemd people have ack'ed on that? 06:44:05 <mfabian> The systemd people didn’t say anything. 06:44:20 <mfabian> The only thing new seems to be https://bugzilla.redhat.com/show_bug.cgi?id=1028207#c61 06:46:07 <juhp> mfabian, where should the gzip go - in dracut? 06:46:12 <juhp> gzip fix 06:46:28 <juhp> I think that needs to be proposed as a blocker too probably 06:47:01 <mfabian> It would surprise me if that solves the problem. I cannot see how that does anthing about the gzip problem, *maybe* it does because of https://bugzilla.redhat.com/show_bug.cgi?id=1028207#c51 06:47:53 <juhp> I mean the a bug against the package where gzip initramfs fix is needed 06:47:59 <juhp> s/the// 06:48:26 <mfabian> I am not 100% sure whether it is needed because: 06:48:36 <mfabian> https://bugzilla.redhat.com/show_bug.cgi?id=1028207#c51 06:48:43 <mfabian> [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ sudo lsinitrd /boot/initramfs-3.11.8-300.fc20.x86_64.img | grep de\\.map 06:48:43 <mfabian> [sudo] password for mfabian: 06:48:43 <mfabian> -rw-r--r-- 1 root root 124811 Nov 6 13:45 usr/lib/kbd/keymaps/i386/qwertz/de.map 06:48:46 <mfabian> -rw-r--r-- 1 root root 3902 Nov 6 13:45 usr/lib/kbd/keymaps/xkb/de.map.gz 06:48:46 <mfabian> [mfabian@Fedora-20-TC1-x86_64-netinst tmp]$ 06:49:14 <mfabian> That looks weird, why xkb/de.map.gz but the other de.map in the other directory has no .gz ? 06:52:20 <juhp> hmm 06:52:37 <juhp> mfabian, you can tested comment#61 ? 06:52:41 <juhp> erm 06:52:45 <juhp> have you *, I mean 06:52:57 <juhp> yeah it seems quite a mess 06:53:09 <mfabian> No, I did not yet test comment#61. 06:53:15 <tagoh_> looks like just a packaging bug? 06:53:25 <mfabian> Will do that after our phone call. 06:53:33 <juhp> personally at this stage it might be easier to revert everything but dunno if that is possible 06:53:34 <mfabian> Could be just some packaging bug, yes. 06:53:39 <juhp> ah 06:54:22 <juhp> tagoh_, well it is changing keymap path etc 06:55:14 <juhp> anyway perhaps we should move on? 06:55:50 <tagoh_> juhp: given that dracut isn't expecting to see any gzip'd keymaps, just thought it was intentionally containing ungziped one but didn't do that by mistake for new xkb keymaps? dunno 06:56:04 <juhp> I see 06:56:25 <juhp> anyway sounds like more testing and continued debugging needed 06:56:33 <tagoh_> agree 06:56:59 <juhp> mfabian, thanks for spending time on this 06:57:19 <tagoh_> juhp: thanks for bringing this up too. 06:57:24 <juhp> :) 06:57:25 <tagoh_> okay, shall we move on then 06:57:45 <tagoh_> #info #26: proposal: move to using IMEs for ASCII/Latin input 06:57:45 <tagoh_> #link https://fedorahosted.org/i18n/ticket/26 06:58:26 <juhp> I don't really have any further update - wanted to get some feedback from others (fujiwara etc) before starting any next steps 06:58:46 <tagoh_> right 06:59:10 <tagoh_> so better postponing a discussion today? 06:59:40 <juhp> yes I guess 06:59:58 <juhp> also haven't talked to any gnome folks yet 07:00:07 <tagoh_> or anyone else here has any comments 07:01:22 <tagoh_> okay, let's move on then 07:01:24 <tagoh_> #topic Open Floor 07:01:43 <tagoh_> anything else we want to discuss in this meeting before stop? 07:02:08 <anish_> i would like a propose feature for ibus that we should have text prediction as service 07:03:07 <anish_> in fctix they are having text prediction as a service 07:03:33 <tagoh_> aha 07:03:55 <anish_> one primary advantage of this approach is we would not have several engines only for text prediction 07:04:37 <anish_> users can enable text prediction whenever they want 07:05:41 <anish_> for text prediction for instead of candidate window lists, we can have candidate lists at fixed location 07:06:01 <anish_> and this location can be customizable 07:06:35 <juhp> aha 07:08:19 <tagoh_> so are you proposing a common API in ibus for text prediction? 07:08:52 <anish_> instead of API how about service? that will give suggestions 07:09:18 <anish_> it would be independent of engines 07:10:25 <anish_> advantage of service would be if someone wants to get suggestions from web or say meaning of words it can be done 07:11:00 <tagoh_> well, you need to call an API to connect to the service and interface that provided at the end though :) anyway got what you mean. 07:11:45 <anish_> tagoh_, thanks! :) 07:12:03 <tagoh_> have you proposed that in ibus upstream or so? 07:12:30 <anish_> i will file a bug if you guys think its a nice idea 07:13:53 <tagoh_> any comments from anyone else? 07:16:39 <tagoh_> hm, okay. anything else? 07:19:50 <tagoh_> okay, then let's stop the meeting here. 07:19:57 <tagoh_> thanks everyone for the meeting! 07:20:03 <anish_> thanks! 07:20:06 <tagoh_> #endmeeting