06:03:20 <tagoh_> #startmeeting i18n
06:03:20 <zodbot> Meeting started Wed Feb 12 06:03:20 2014 UTC.  The chair is tagoh_. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:03:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
06:03:21 <tagoh_> #meetingname i18n
06:03:21 <zodbot> The meeting name has been set to 'i18n'
06:03:21 <tagoh_> #topic agenda and roll call
06:03:21 <tagoh_> #link https://fedoraproject.org/wiki/I18N/Meetings/2014-02-12
06:03:32 <tagoh_> shall we have i18n meeting now?
06:03:53 <fujiwarat> hi
06:03:56 <juhp> hi
06:04:17 <pravins> hi
06:04:17 <__anish__> Hi!
06:04:20 <epico> hi
06:04:28 <paragan> hi
06:04:29 <mfabian> Hi!
06:04:33 <dueno> hi
06:05:34 <lijli> hi
06:06:56 <tagoh_> okay, let's get started.
06:07:05 <tagoh_> #topic Upcoming schedule
06:07:35 <tagoh_> nothing I can share AFAIK
06:07:59 <tagoh_> anyone has anything?
06:10:08 <tagoh_> if not, move on then
06:10:11 <tagoh_> #topic Outstanding topics
06:10:11 <tagoh_> #info #25: Bugs Corner (i18n@lists.fedoraproject.org)
06:10:12 <tagoh_> #link https://fedorahosted.org/i18n/ticket/25
06:10:22 <tagoh_> any bugs you want to share in this meeting?
06:10:27 <juhp> PRDs have been approved, next step seems to be working on technical plans for the 3 products (notting's mail to devel-announce)
06:10:34 <juhp> sorry slow typing :)
06:12:00 <tagoh_> aha. thanks
06:12:40 <epico> . bug 969415
06:12:44 <zodbot> epico: Bug 969415 tomoe includes non-free contents - https://bugzilla.redhat.com/show_bug.cgi?id=969415
06:13:35 <epico> guess need to provide the shell script and stripped tar ball in src rpm?
06:14:13 * epico not familiar with kanjidic and skip code.
06:14:34 <juhp> epico, hmm probably - even removing SKIP data from binaries would be step forward I think, but yes I believe that is correct
06:14:55 <juhp> epico, or you could ship debian's tarball if you prefer
06:15:01 <juhp> perhaps
06:15:06 <epico> I checked tomoe, it seems it only contains kanjidic2, not kanjidic.
06:15:13 <juhp> ah
06:15:33 <epico> after check, I think only kanjidic2-original.xml contains skip code, kanjidic2.xml seems not.
06:15:35 <juhp> is the report incorrect then?
06:15:41 <juhp> aha
06:17:16 <epico> guess I need to remove "<q_code qc_type="skip">4-7-1</q_code>" from kanjidic2-original.xml?
06:17:28 <juhp> epico, what does debian do to tomoe if anything?
06:17:28 <mfabian> James Halper once allowed me to distribute the SKIP code stuff in SuSE. I always had his e-mail allowing this in the package. But the legal department later wanted to have it removed anyway.
06:17:48 <mfabian> Jack Halpern is very nice, I think he would allow distribution if one asks.
06:18:03 <juhp> mfabian, I think epico contacted him...
06:18:22 <epico> mfabian, I sent email, no reply yet.
06:18:31 <mfabian> Oh, that is a pity.
06:19:18 <juhp> epico, that might work - I think for kanji1 debian overwrites with dummy data - for xml not sure on the Right Thing
06:19:24 <epico> juhp, the binary tomoe package seems okay...
06:19:35 <juhp> epico, could also replace with 1-1-1 or whatever they ddi
06:19:36 <juhp> did
06:19:42 <juhp> epico, I see
06:19:57 <juhp> maybe we can discuss more offline
06:19:58 <epico> I will ask it on bug first. :)
06:20:01 <juhp> okay
06:20:29 <tagoh_> maybe including it in the source looks not good. better respin the tarball or ship debian's as juhp suggested.
06:20:42 <juhp> I guess tomoe doesn't need the skip codes anyway...
06:20:52 <juhp> tagoh_, right
06:21:18 * epico finding the debian bug.
06:21:29 <epico> the mentioned bug is about kanjidic...
06:21:30 <juhp> debian might have stripped out kanjidic data completely and use kanjidic package instead I guess
06:21:49 <epico> s/the debian bug/the debian tomoe bug/
06:22:08 <juhp> need to check I guess
06:22:17 <epico> yes
06:22:46 <juhp> what uses tomoe these days anyway?
06:23:19 <epico> juhp, only zinnia use its handwriting data.
06:23:28 <juhp> I see
06:23:36 <epico> for zinnia model generation.
06:23:40 <juhp> scim-tomoe is gone?
06:23:50 <juhp> I see
06:24:02 <juhp> guess it doesn't need skip codes
06:24:20 * epico hope so.
06:24:27 <epico> I checked the spec, seems not.
06:24:47 <mfabian> I cannot imagine it needs skip codes for handwriting recognition.
06:24:50 <epico> not use skip code.
06:25:01 <juhp> if we don't want to package kanjidic (I am kind of neutral) then maybe respin tarball is better but there is also another package that needs it so probably better to package it ideally
06:25:24 <juhp> maybe Fedora is less strict about copydata than copylibs ;o)
06:25:46 <juhp> kiten, yes
06:26:09 <epico> scim-tomoe is retired.
06:26:16 <juhp> of course it would be easier if upstream could make a free release without skip...
06:26:20 <juhp> epico, okay
06:27:20 <juhp> anyone want to package it? :)
06:27:22 <tagoh_> does upstream still maintain tomoe?
06:27:31 <juhp> good question
06:27:50 <epico> juhp, tomoe debian bug not found by google search...
06:28:20 <juhp> epico, I think debian is more carefully about copydata
06:28:21 <epico> tagoh_: I also worry about it...
06:28:37 <juhp> how about zinnia?
06:29:04 <juhp> it still works? :)
06:29:19 <epico> it seems to use handwriting-*.xml.
06:29:59 <juhp> ah ibus-handwrite uses it
06:30:12 <epico> in the worst case, we can package zinnia-model. we generate the zinnia-model when building.
06:30:20 <juhp> aha
06:30:27 <epico> last time zinnia-model failed to pass package review...
06:30:33 <juhp> oh
06:30:47 <epico> a long argument on the package review...
06:30:59 <juhp> hmm
06:31:11 <epico> any way I will ask it on the bug.
06:31:36 * epico think no big problem with zinnia iiuc.
06:31:52 <juhp> bug#?
06:31:58 <juhp> we could try again
06:32:25 <epico> . bug 575005.
06:32:27 <juhp> so there is newer version of zinnia or it is a build option?
06:32:30 <zodbot> epico: Bug 575005 Review Request: zinnia-tomoe - Online hand recognition system with machine learning - https://bugzilla.redhat.com/show_bug.cgi?id=575005
06:32:36 <juhp> ah ok
06:33:22 <epico> juhp, zinnia is also low activity. and I think it is okay to remove skip code from tomoe.
06:33:31 <epico> just not tried it yet...
06:33:31 <juhp> okay
06:33:54 <juhp> epico, but we already don't ship skip in binary rpms?
06:34:21 <epico> [epico@localhost debian]$ rpm -ql tomoe|grep kanji
06:34:22 <epico> /usr/share/doc/tomoe/kanjidic-licence.html
06:34:22 <epico> /usr/share/doc/tomoe/kanjidic.html
06:34:22 <epico> /usr/share/doc/tomoe/kanjidic2.html
06:34:26 <epico> not
06:35:01 <epico> juhp, sorry, I forget one thing, let me check.
06:36:01 <tagoh_> okay, anything else?
06:38:01 <tagoh_> BTW f18 i18n bugs has been triaged. thanks everyone for spending a time for that.
06:39:57 <juhp> yay
06:41:08 <tagoh_> if not, let's move on.
06:41:27 <tagoh_> #info #26: proposal: IM and xkb UI design improvements (i18n@lists.fedoraproject.org)
06:41:28 <tagoh_> #link https://fedorahosted.org/i18n/ticket/26
06:41:31 <tagoh_> any updates?
06:44:19 <juhp> (yes I renamed the ticket)
06:45:20 <tagoh_> yep
06:46:49 <juhp> otherwise not really - I had some more discussion on it with fujiwarat though
06:47:07 <juhp> which helped to clarify some things for me on the ibus side
06:47:28 <juhp> I forgot to summarize them though in the ticket
06:48:33 <juhp> anyone have any comments or questions currently?
06:49:43 <juhp> I feel like some parts depend on or could be improved by hw or lower level support - last we talked at the end of hw detection for example
06:49:59 <juhp> I should try to ask whot about that
06:50:09 <tagoh_> sure
06:50:12 <juhp> or does anyone have any pointers?
06:50:22 <juhp> tagoh_, you mentioned X db ?
06:51:27 <juhp> but maybe hard to say when Linux/Fedora would support that though
06:52:49 <juhp> mfabian, have you thought more about xkb metadata for langtable say?
06:53:00 <anish__> for Indian languages we can't have one to one mapping in xkb because of certain characters such as "Dnya" can't be imputed without input methods
06:53:28 <juhp> anish__, right it is an X Input limitation I think
06:53:41 <juhp> hopefully Wayland might do better?
06:53:54 <epico> use libinput?
06:54:05 <epico> by wayland.
06:54:06 <juhp> aha
06:54:24 <anish__> juhp, if such words are less 10 or 20 can we have hack or something so that we don't have use input methods at all
06:54:28 <epico> libinput forked input code from wayland.
06:54:56 <mfabian> juhp: not yet. It is an interesting idea but I have not yet thought in more detail about it.
06:55:04 <juhp> mfabian, ok
06:55:24 <juhp> epico, right
06:55:51 <juhp> anish__, I dunno how frequent are they?
06:55:56 <juhp> ,
06:56:13 <juhp> anish__, maybe one could just use IME for writing them etc
06:56:58 <mfabian> anish__: dnya was from itrans, right?
06:57:05 <juhp> anish__, but I think some other input maps also need multi-glyph input?
06:57:21 <mfabian> anish__: does inscript have the same problem?
06:57:30 <juhp> I thought phonetic did too
06:57:34 <mfabian> anish__: or does inscript work OK with an xkb layout?
06:57:39 <anish__> juhp, i am not sure either, i am thinking about it, xkb and lib17n it creates lot of confusion
06:58:05 <juhp> I would be happy if we could use kbd layouts for Indic
06:58:27 <juhp> mfabian, I think xkb supports some inscript
06:58:53 <anish__> juhp, yeah let me check out with l10n guys, as i am not *good* user of these layouts
06:59:05 <mfabian> Yes, there are inscript layouts for xkb.
06:59:09 <juhp> in sense now that we have input sources - it might even be possible to make some use of xkb for indic, dunno
06:59:12 <juhp> paragan, ?
06:59:18 <mfabian> I just wondered whether they work perfectly or have some problems.
06:59:29 <juhp> right
06:59:53 <juhp> epico, does libinput support X too?
07:00:05 <mfabian> If they work perfectly, they might be a very good option to use in ibus-typing-booster for indic.
07:00:18 <juhp> mfabian, ah right yes
07:00:26 <anish__> mfabian, juhp i could see only one problem you can't use itrans using xkb layouts
07:00:38 <juhp> and phonetic?
07:00:45 * epico thinks it targets any wayland forked display server...
07:00:51 <juhp> epico, okay
07:00:54 <tagoh_> juhp: interesting one - /etc/X11/xorg.conf.d/00-keyboard.conf which was generated by systemd-localed. that looks like they know what it is.
07:01:01 <juhp> oh
07:01:06 <anish__> juhp, phonetic i think so
07:01:30 <mfabian> Currently, for Marathi, the combobox in ibus-typing-booster setup offers: “imes = Enhanced Inscript:mr-inscript2,Inscript:mr-inscript,Phonetic:mr-phonetic,
07:01:30 <mfabian> Itrans:mr-itrans”
07:01:40 <juhp> tagoh_, that might be from anaconda though?
07:02:25 <mfabian> If the inscript xkb layouts work well, then “Native Keyboard:NoIme” should be added to make it possible to use the xkb inscript layouts as well.
07:02:45 <juhp> anish__, xkb supports phonetic?
07:02:48 <paragan> xkb layouts don't support conjuncts
07:03:01 <juhp> paragan, ah right
07:03:20 <mfabian> paragan: are the conjuncts only a problem with phonetic and itrans or also with inscript?
07:03:33 <tagoh_> juhp: no idea if it will be upcated on demand so that I don't have extra keyboard here
07:03:39 <paragan> mfabian, no
07:04:48 <juhp> at least anaconda doesn't detect keyboard hw afaik
07:04:57 <tagoh_> juhp: systemd has udev code and they know what keys it has. they could guess layout too perhaps dunno
07:05:04 <juhp> okay
07:05:09 <juhp> that is interesting
07:05:41 <mfabian> paragan: "no" means  the inscript xkb layouts do *not* work well?
07:06:18 <paragan> any kind of xkb layout does not support conjuncts
07:06:39 <juhp> this is about glyph reordering, right?
07:06:49 <paragan> right
07:06:53 <juhp> ok
07:09:47 <anish__> juhp, do you think wayland can work/handle this conjuct limitation?
07:10:17 <juhp> maybe not - I am not sure
07:10:26 <mfabian> paragan: can you give a simple example?
07:12:34 <anish__> mfabian, not sure whether it is a correct example type "ksha" using mr-inscript
07:13:21 <anish__> letter क्श is a combination of क and श
07:13:41 * epico thinks pango handles this...
07:14:40 * fujiwarat agree with epico :).
07:14:42 <anish__> epico, yes pango does the reordering
07:15:25 <epico> fujiwarat :)
07:16:44 <mfabian> If I paste क followed by श into gedit, I get कश instead of क्श
07:17:17 <epico> ah
07:18:58 <fujiwarat> But indic needs input method? I'm not familiar with conjunct. AFAIK, ara does not need input method.
07:19:51 <anish__> fujiwarat, that is my point and i am not sure about it
07:20:17 <fujiwarat> anish__: ok, I'm just interested in it.
07:20:26 <anish__> fujiwarat, i only know one limitation that i already told
07:20:37 <mfabian> typing ksha gives केपो when using mr-inscript or mr-inscript2 (both with typing booster and directly via ibus-m17n)
07:20:59 <anish__> wondering what could be other limitations and how we can overcome it
07:21:00 <juhp> anyway - I think we need to strip down the list in the ticket to the bare possible essentials
07:21:06 <juhp> and scope what is possible
07:22:17 <tagoh_> sounds good for next step
07:23:19 <juhp> still wish we could do more on Latin mode and input mode status but it seems too many IMEs don't do it
07:23:46 <fujiwarat> https://wiki.gnome.org/GnomeGoals/KeyboardData
07:23:53 <fujiwarat> Hmm.., server down.
07:24:12 <fujiwarat> https://wiki.gnome.org/Initiatives/GnomeGoals/KeyboardData
07:25:07 <fujiwarat> Maybe you like the more enhanced keymap list.
07:25:28 <mfabian> After “setxkbmap 'in(deva)'”, typing ksha in gedit also gives केपो I.e. that looks the same.
07:25:52 <juhp> fujiwarat, thanks - I had forgotten about that - yes it is a good useful start
07:26:49 <tagoh_> running out of the time - let's continue the discussion in the next meeting.
07:27:02 <mfabian> So "ksha" does not show that the inscript xkb layout does not work because it gives the same result as inscript or inscript2 via the m17n library.
07:27:30 <anish__> mfabian, okay
07:30:27 <tagoh_> #topic Open Floor
07:30:39 <tagoh_> any other topics we want to discuss before stop the meeting?
07:34:13 <tagoh_> alright, stop here then. thanksk everyone for the meeting!
07:34:23 <tagoh_> #endmeeting