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