06:01:58 <tagoh_> #startmeeting i18n
06:01:58 <zodbot> Meeting started Wed Feb  5 06:01:58 2014 UTC.  The chair is tagoh_. Information about MeetBot at http://wiki.debian.org/MeetBot.
06:01:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
06:01:59 <tagoh_> #meetingname i18n
06:01:59 <zodbot> The meeting name has been set to 'i18n'
06:01:59 <tagoh_> #topic agenda and roll call
06:02:00 <tagoh_> #link https://fedoraproject.org/wiki/I18N/Meetings/2014-02-05
06:02:14 <tagoh_> okay, shall we have i18n meeting?
06:02:14 <mfabian> Hi! ☺
06:02:44 <pravins> hi
06:02:52 <skore> hi
06:02:55 <paragan> hi
06:03:02 <juhp> hi
06:03:08 <dueno> hi
06:03:21 <anish_> Hi!
06:04:51 <tagoh_> okay, let's get started.
06:05:04 <tagoh_> #topic Upcoming schedule
06:05:19 <tagoh_> well, no updates AFAIK
06:05:51 <tagoh_> anything I'm missing?
06:06:45 <juhp> I guess not - looks like f21 will be a long cycle
06:07:02 <tagoh_> yeah, seems so.
06:07:52 <tagoh_> good to keep eyes on updates/discussion at the list
06:08:03 <juhp> (bit OT:  I saw interested Fedora Server proposal for longer support releases - < 3 years perhaps)
06:08:09 <juhp> interesting
06:08:15 <juhp> supported
06:08:36 <tagoh_> aha
06:08:37 <juhp> well still under discussion in the WG I guess
06:08:58 <juhp> anyway still many questions around Fedora.next...
06:09:08 <tagoh_> right
06:09:31 <juhp> some even still asking if it will really happen ;)
06:09:53 <tagoh_> hehe. sure.
06:10:10 <tagoh_> alright, let's move on then.
06:10:19 <tagoh_> #topic Outstanding topics
06:10:19 <tagoh_> #info #29: Fedora 18 bugs cleanup (tagoh)
06:10:19 <tagoh_> #link https://fedorahosted.org/i18n/ticket/29
06:11:50 <tagoh_> want to triage f18 bugs as far as possible. 3 open bugs there.
06:13:21 <tagoh_> .bug 847565
06:13:28 <zodbot> tagoh_: Bug 847565 Very slow response or frozen input when input is switched to use other input methods (e.g. Chinese, pinyin) - https://bugzilla.redhat.com/show_bug.cgi?id=847565
06:13:31 <tagoh_> .bug 873849
06:13:35 <zodbot> tagoh_: Bug 873849 no keyboard shortcut for toggling keyboard layouts - https://bugzilla.redhat.com/show_bug.cgi?id=873849
06:13:38 <tagoh_> .bug 874753
06:13:41 <zodbot> tagoh_: Bug 874753 Can't change keyboard layout in GDM by default - https://bugzilla.redhat.com/show_bug.cgi?id=874753
06:14:20 <juhp> was there no conclusion about 847565 ?
06:14:26 <juhp> fujiwarat, ?
06:15:01 <fujiwarat> I think so. I'm waiting for auto-closing for f18.
06:16:16 <tagoh_> apparently not. if it's improved/fixed in the latest. you could simply close it.
06:18:19 <juhp> fujiwarat, if you think it is fixed then please comment in the bug and close it
06:18:40 <juhp> ah sorry what tagoh_ said
06:19:53 <juhp> is there some way to boot Live into another locale?  I forget
06:20:54 <tagoh_> dunno. is it possible?
06:22:59 <tagoh_> any other comments on f18 bugs?
06:23:09 <juhp> I closed 873849
06:23:31 <juhp> vconsole.locale= ?
06:23:40 <juhp> not sure if it works though :-\
06:24:36 <tagoh_> thanks
06:24:37 <tagoh_> aha
06:25:23 <juhp> luckily that doesn't work ;)
06:25:38 <juhp> mfabian, ?
06:25:52 <juhp> let me try to test gdm later anyway
06:26:57 <tagoh_> locale.LANG= ? from systemd(1)
06:27:40 <mfabian> juhp: 874753, Can’t change keyboard layout in GDM by default?
06:28:10 <juhp> mfabian, yeah - well just wondered if you knew how to change system locale for Live
06:28:32 <juhp> mfabian, or do you know current status?
06:28:37 <mfabian> No, I didn‘t really try live often, mostly I install -netinstall.
06:29:23 <juhp> can't one change input source now on login (or lockscreen)?
06:29:42 <mfabian> I’ll check whether that  problem is still there ...
06:30:18 <tagoh_> no Live iso on my machine ATM. so can't try it quickly..
06:32:12 <juhp> I don't see any indicator on the login screen anyway
06:32:15 <juhp> so maybe not
06:32:19 <juhp> mfabian, thanks
06:32:48 <tagoh_> okay, move on then
06:32:58 <tagoh_> #info #25: Bugs Corner (i18n@lists.fedoraproject.org)
06:32:59 <tagoh_> #link https://fedorahosted.org/i18n/ticket/25
06:33:09 <tagoh_> any other bugs we want to focus on here?
06:35:19 * juhp might file a bug about not being able to set boot locale for Live...
06:36:49 <tagoh_> juhp: so locale.LANG= didn't work on live?
06:38:15 <juhp> no
06:38:27 <juhp> I see a locale.conf file on Live...
06:38:27 <tagoh_> aha
06:41:21 <tagoh_> okay, anything else?
06:42:54 <tagoh_> if not, let's move on
06:42:57 <tagoh_> #info #26: proposal: move to using IMEs for ASCII/Latin input (i18n@lists.fedoraproject.org)
06:42:58 <tagoh_> #link https://fedorahosted.org/i18n/ticket/26
06:43:03 <tagoh_> any updates?
06:44:00 <juhp> indeed
06:44:50 <juhp> I revised the earlier list of ideas after some private discussions on Latin mode
06:45:06 <juhp> actually there is still quite a lot left - more than I thought
06:45:24 <tagoh_> aha
06:46:01 <mfabian> “currently xkb too much on the same level as IMEs ” <- I think so as well.
06:46:03 <juhp> https://fedorahosted.org/i18n/ticket/26#comment:10
06:47:22 <juhp> yea, I added a question since I am not completely sure yet on the story for differentiating IME and xkb maps - obviously we don't want to undo _all_ the work on input sources
06:48:14 <juhp> as I see more metadata is needed on xkb maps - langtable's data on ascii maps is good start at least :)
06:48:19 <juhp> see it *
06:49:21 <juhp> it is delicate balance between too free (IMHO what we have now) and too constrained (maybe more like win or cros, not sure)
06:50:02 <juhp> eg I want French users to be able to input Japanese from azerty kbd for example
06:50:18 <mfabian> Yes. Currently possible but a bit confusing.
06:51:26 <mfabian> One also might want to use ibus-typing-booster for Russian and English by keeping the same engine and not using Russian transliteration but switching between Russian and English keyboard layout.
06:51:35 <juhp> but I don't want to be offered layouts my keyboard doesn't support say, or non-ascii keymaps anyway
06:52:00 <juhp> mfabian, aha
06:52:07 <juhp> right interesting
06:52:21 <juhp> mfabian, that's not currently possible, right?
06:52:45 <mfabian> inconvenient, because to switch the keyboard layout one has to leave typing booster.
06:52:59 <juhp> maybe IME should specify what keymaps they can use?
06:53:04 <juhp> nod
06:53:11 <mfabian> I.e. switch to Russian layout, then back to typing booster, then switch to English layout, then back to typing booster.
06:53:21 <juhp> mfabian, I think your case is a bit hard though interesting
06:53:41 <mfabian> Would be nicer if the layout could be switched independently.
06:53:57 <juhp> but ideally our input framework should be flexible enough to do this without need libtranslit etc
06:54:27 <juhp> mfabian, so back to gnome2 ? :-P :)
06:54:59 <mfabian> I always thought having one switch for keyboard layouts *and* IMEs was a mistake.
06:55:19 <mfabian> But some people disagree passionately.
06:55:27 <juhp> yeah also it seems it would be nice if IM framework was aware of input mode ("privileged" property)
06:55:31 <fujiwarat> If each IME has different keymap, I think it's an IME issue.
06:55:55 <juhp> mfabian, I think it could be done properly
06:56:05 <juhp> again using more metadata etc
06:56:41 <juhp> fujiwarat, well mfabian wants to allow layout (keymap) switching within an IME
06:56:56 <juhp> but yeah in some sense perhaps it could be handled by IME perhaps
06:57:02 <mfabian> bochecha absolutely wanted only one switch. But I think this is because his Cangjie input method basically requires the US layout and he doesn’t understand that some IMEs could be used with almost any keyboard layout.
06:57:11 <fujiwarat> Yes, I mean it.
06:57:17 <juhp> mfabian, right
06:57:42 <juhp> mfabian, South Chinese IMEs seem to assume US
06:57:46 <pravins> do we have  any shortcut  define for layout switch within IME?
06:58:06 <juhp> fujiwarat, okay - but it seems something that maybe the IM framework could provide perhaps?
06:58:32 <mfabian> The Japanese input methods for example can be used with any keyboard layout which can input ASCII. The Cangjie input method has radicals on certain keys, using  any other keyboard layout than US would be a mess.
06:58:43 <juhp> (as in not Latin phonetic)
06:58:53 <juhp> right
06:59:40 <juhp> I think there are some similar obscure IMs for Japanese and less obscure for SC that also assume kbd layout
06:59:55 <juhp> probably
06:59:57 <juhp> anyway
07:00:02 <mfabian> Like wubi.
07:00:18 <juhp> anyway this is well-known issue - two types of IME :)
07:00:22 <fujiwarat> juhp: We are ok to provide a common keymap for IMEs but probably I think having it in DE configuration make sense.
07:01:01 <mfabian> I always read “DE” as “Germany” first ☺.
07:01:14 <juhp> one problem is it seems too much work (risk?) to clean up the list of xkb maps
07:01:16 <pravins> :)
07:01:22 <fujiwarat> mfabian: sorry :). desktop.
07:01:38 <mfabian> Yes, I usually notice on second reading ☺
07:02:37 <fujiwarat> phuang suggest if latin and hiragana modes have different keymaps, it would be better to use XKB engines and IME than switching input modes.
07:03:07 <juhp> fujiwarat, well they don't?
07:03:32 <juhp> unless you mean kana input?
07:04:14 <mfabian> I.e. switch to kana input by changing the xkb layout? Interesting, maybe that’s a better way to do it.
07:04:20 <juhp> fujiwarat, ah you mean input sources?
07:04:36 <fujiwarat> juhp;: we assume normally we use the same keymap between enable IME and disable IME. If not, suggest to use XKB engines.
07:04:51 <juhp> fujiwarat, I see
07:06:03 <juhp> fujiwarat, I think normally people prefer to input Ja with their default layout no US or JP say
07:06:08 <juhp> not
07:06:26 <juhp> anyway it is kind of an edge case but true
07:06:30 <fujiwarat> So currently we assume one common keymap confugration is needed. But probably it's better to configure in DE than IMF.
07:06:34 <mfabian> If one wants to use Kana input, one probably *must* use a real Japanese keyboard.
07:06:54 <juhp> fujiwarat, I see
07:07:40 <mfabian> On most other keyboards, the key with the ろ to the left of the right Shift key would be missing.
07:07:41 <juhp> fujiwarat, but then it is needed on each DE
07:08:55 <juhp> mfabian, that's why I think user should really configure their type of keyboard geometry ("layout") and that should restrict the available keymaps etc
07:09:11 <juhp> would that be too rigid?
07:09:41 <juhp> so maybe that is really what I want separated: the geometry and the maps
07:09:43 <mfabian> Isn’t it a bit hard to figure out which layout could be used on which physical keyboard.
07:09:44 <mfabian> ?
07:10:42 <juhp> hm, it ought to be possible I feel
07:10:46 <fujiwarat> juhp: RIght. I think it's an user friendly configuration. If not, $HOME/.Xkeymap might resolve it.
07:10:59 <juhp> just count the keys ... maybe maybe not that easy
07:11:07 <juhp> well that's why I want more metadata :-)
07:11:16 <juhp> s/maybe//
07:11:45 <mfabian> https://en.wikipedia.org/wiki/AZERTY https://en.wikipedia.org/wiki/QWERTZ  seem to have the same physical keys, so using a French layout on a German keyboard and vice versa should be possible.
07:11:56 <juhp> mfabian, okay
07:12:18 <mfabian> But one could not use the French or the German layout on a Japanese or a US keyboard because the key to the right of the left Shift key would be missing.
07:12:19 <juhp> admittedly I haven't done all the work and analysed the best way to do this
07:12:53 <juhp> mfabian, I see and maybe vice versa too for jp -> fr or de
07:13:28 <juhp> I think xkb has the layout to separate geometry but it is hidden in the UI
07:13:35 <juhp> erm
07:13:49 <mfabian> Maybe that information can be found by scripting from the data in /usr/share/X11/xkb/
07:13:51 <juhp> s/layout/"language"/
07:13:59 <juhp> yes perhaps
07:15:28 <mfabian> Maybe something I should think about for langtable ... "Can layout x be used on a physical keyboard y?" an easy function for that may be useful.
07:15:41 <juhp> mfabian, that would be cool
07:16:58 <fujiwarat> If kbd is usb but not ps/2, the keymap can be detected AFAIK.
07:18:21 <juhp> fujiwarat, in practice I am not sure
07:18:59 <tagoh_> like evdev does?
07:19:35 <juhp> we have keyboard type detection?
07:20:05 <juhp> I wish though
07:21:02 <fujiwarat> I mean usb 2.0 is required.
07:21:33 <juhp> I mean in practice keyboard generally don't provide the info even if they can afaik
07:21:47 <juhp> mine don't anyway
07:22:13 <fujiwarat> right. it's not done in linux.
07:22:19 <juhp> hm
07:22:29 <juhp> so it works for Windows?
07:22:56 <juhp> I could imagine Apple probably does
07:23:22 <tagoh_> X has DB. evdev does it. so they might try to match on it? dunno.
07:24:03 <juhp> maybe we should look more into it then
07:24:22 <tagoh_> anyway, we are running out of the time. let's clarify some conclusions and tasks
07:27:03 <juhp> yes
07:27:16 <juhp> well a few new points also came up today
07:27:33 <juhp> and other parts we have not discussed yet
07:27:57 <juhp> it would be good to break it down into smaller pieces though
07:28:01 <tagoh_> so shall we continue to discuss it in next meeting then?
07:28:14 <juhp> probably good yes
07:28:20 <tagoh_> okay
07:28:29 <juhp> I know it is an ongoing topic but I feel more to cover
07:28:38 <tagoh_> sure
07:29:10 <tagoh_> move on then
07:29:11 <tagoh_> #topic Open Floor
07:29:23 <tagoh_> any other topics we are missing in the agenda?
07:32:36 <tagoh_> okay, then let's stop here. thanks everyone for the meeting!
07:32:51 <tagoh_> #endmeeting