From Fedora Project Wiki

previous meeting | next meeting

Agenda

Time:2009-08-19 0500 UTC

Place: #fedora-i18n at Freenode

Summary

Log

juhp g'day Aug 19 15:00
juhp guess it is time for our weekly IM meeting Aug 19 15:00
juhp I18N/InputMethods/Meetings/2009-08-19 Aug 19 15:00
juhp who is here? :) Aug 19 15:01
juhp hmm Aug 19 15:02
juhp phuang, tagoh3, paragan, pravin_s, kaio, dychen, fujiwarat: ping Aug 19 15:03
phuang hi Aug 19 15:03
fujiwarat hi Aug 19 15:03
pravin_s juhp: hi Aug 19 15:03
dychen juhp: pong Aug 19 15:03
tagoh3 hi Aug 19 15:03
Kaio pong Aug 19 15:03
paragan hi Aug 19 15:06
juhp sorry just tweaked the page some more Aug 19 15:06
juhp phuang: I had some more discussion with whot today about xkb Aug 19 15:06
phuang ah Aug 19 15:07
juhp well just developing our earlier discussions Aug 19 15:07
juhp he's writing a draft blog about it: http://people.freedesktop.org/~whot/ibus Aug 19 15:10
juhp which summaries it all quite well I think Aug 19 15:10
phuang cool Aug 19 15:11
whot I'm here btw. if you have any questions. Aug 19 15:11
juhp but he would appreciate any comments or corrections I am sure Aug 19 15:11
juhp :) Aug 19 15:11
juhp yes Aug 19 15:11
juhp so I was playing a bit more with xkb on rawhide earlier Aug 19 15:12
phuang whot, thanks. Aug 19 15:12
juhp but the underlying idea is to try to drop xkb hacks in ibus afap Aug 19 15:12
juhp and just rely on xkb layouts rather than assumptions Aug 19 15:13
juhp # Xkb interaction Aug 19 15:13
juhp * ibus orth? Aug 19 15:13
juhp * inscript maps to xkb? Aug 19 15:13
juhp even if we don't use all the changes by default in f12 say I think it would be good to start such changes where possible now Aug 19 15:16
juhp also XI2 is in f12 xorg-server already whot told but probably doesn't have so much affect on IM yet Aug 19 15:17
juhp but there are plenty of UI and config issues to consider once we make this transition Aug 19 15:18
juhp one thing that we talked about earlier too I think is switching IME for certain input - but thinking now it is more of an advanced perhaps Aug 19 15:19
---Users on #fedora-i18n: krishnababu pravin_s paragan juhp whot jni dychen Kaio_Strassus yshao hanthana fujiwarat phuang noriko_ candyz0416 zodbot Kaio mishti jassy ivazquez|laptop asgeirf ricky dyek2 tagoh3 sflanigan paragn Aug 19 15:19
juhp paragan: we were wondering though how many Indic users use non-linear maps by default - any idea? Aug 19 15:20
juhp if we take this work to its limit then we might just use xkb for inscript and perhaps not need m17n by default Aug 19 15:20
paragan most of govt organizations uses inscript here Aug 19 15:21
juhp ok Aug 19 15:21
juhp I guess one can say for most langs we can hopefully default to just one IME others being optional so if that made sense for Indic it would ease the UI pain Aug 19 15:22
juhp in a way looking back we should probably have really used xkb for inscript all along... though it would have made our UI considerations different Aug 19 15:22
juhp paragan: how about the new inscript standard? it seems like a good time to port to xkb if possible Aug 19 15:23
juhp pravin_s: too Aug 19 15:23
paragan juhp, its not yet released. Once we have it released we start working on it Aug 19 15:23
juhp paragan: one current limitation is the max of 4 xkb layouts Aug 19 15:24
juhp paragan: hmm so when will that be? Aug 19 15:25
paragan soon Aug 19 15:25
juhp paragan: we really need that in f12 Aug 19 15:25
juhp ok Aug 19 15:25
juhp will it make f12beta? Aug 19 15:25
paragan not sure depends on release date Aug 19 15:26
juhp (end of next month I see) Aug 19 15:26
juhp paragan: if we know the basic details seems it would not hurt to start earlier - if major alterations are unlikely Aug 19 15:26
paragan juhp, yes I have few questions already in mind regarding that Aug 19 15:27
paragan for that I need to send you draft copy of that Aug 19 15:27
juhp or we could start by porting current missing inscript maps to xkb perhaps? Aug 19 15:27
paragan and decide how to switch layers Aug 19 15:27
juhp aha Aug 19 15:27
paragan which shortcut keys to use Aug 19 15:27
juhp paragan: I see guess xkb may be good for that Aug 19 15:27
juhp ok Aug 19 15:28
paragan got 4 types of switching Aug 19 15:28
juhp gosh Aug 19 15:28
juhp ok Aug 19 15:28
paragan 1) normal 2) with caps 3) normal+someswitch 4) caps+someswitch Aug 19 15:29
juhp aha right Aug 19 15:29
juhp maybe right Alt or a better symbol? Aug 19 15:30
juhp whot might have a better suggestion Aug 19 15:30
whot fwiw, xkb has some standard ways of switching layout already. it might be worth considering those too Aug 19 15:30
juhp ok Aug 19 15:30
paragan whot, yes I have seen xkb have its own switching layout Aug 19 15:31
paragan will see more on that Aug 19 15:31
juhp paragan: caps = shift? Aug 19 15:31
juhp I guess Aug 19 15:31
paragan yes Aug 19 15:31
juhp does someswitch need to be stateful? Aug 19 15:32
whot system->preferences->keyboard, advanced options, "Key(s) to change layout" are the options available right now Aug 19 15:32
whot i think the IM shouldn't really add on top of that but just hook in with this. Aug 19 15:33
juhp or Keys to choose 3rd level perhaps in this case Aug 19 15:33
whot which allows for those that have e.g. us,de,ja to use the same key to cycle through all, rather than having one for us,de and one for IM Aug 19 15:33
juhp whot: I think this is within one layout Aug 19 15:33
whot 3rd level == AltGr (basically) Aug 19 15:33
juhp right Aug 19 15:33
juhp whot: seems (some? of) the revised inscript layouts will need 4 levels Aug 19 15:35
juhp paragan: currently it is just 2? Aug 19 15:35
juhp is it for all of them? Aug 19 15:35
whot juhp: you have up to 8, so that's fine Aug 19 15:36
juhp :) Aug 19 15:36
juhp yup Aug 19 15:36
paragan juhp, yes 2 Aug 19 15:36
juhp phuang: do you have any more thoughts or comments Aug 19 15:36
juhp ok Aug 19 15:36
phuang juhp, I am thinking Aug 19 15:36
juhp paragan: I think various euro layouts have more than 2 levels so could use those too for reference Aug 19 15:37
pravin_s juhp: aha, thats nice Aug 19 15:38
juhp paragan: I guess we need some script for converting .mim files to xkb format perhaps Aug 19 15:39
juhp phuang: I think there are still various UI issues to overcome but I agree with whot that using xkb should be Right Thing Aug 19 15:40
pravin_s juhp: hmm, but scope will be limited as far as its 1-to-1 mapping Aug 19 15:40
juhp pravin_s: yep that's right Aug 19 15:41
phuang pravin_s, right Aug 19 15:41
juhp pravin_s: that is why I was asking how many use non-linear maps :) Aug 19 15:41
juhp any feeling on that? Aug 19 15:41
dychen juhp: phuang: I think some Chinese IM can still hook on English keysyms. Aug 19 15:41
dychen but some can't. Aug 19 15:41
pravin_s i think except inscript all uses non-linear Aug 19 15:41
juhp anyway as such nothing to stop ibus from also doing layout switching per se Aug 19 15:42
juhp pravin_s: indeed Aug 19 15:42
juhp pravin_s: how many users :) Aug 19 15:42
dychen whot: So what should we provide to xkb, a symbol <-> keycode table? Aug 19 15:42
pravin_s juhp: inscript is national standard in India, and govt. recommend to use that Aug 19 15:42
juhp dychen: actually even unicode symbols are considered symbols Aug 19 15:43
juhp that is what current inscript xkb maps use Aug 19 15:43
pravin_s yeah Aug 19 15:43
juhp pravin_s: ok but how minor is use of others? Aug 19 15:43
juhp so roughly sounds like just shipping inscript by default is enough? Aug 19 15:44
juhp dychen: Uxxxx Aug 19 15:44
pravin_s juhp: cant say that actually, but people familiar with Latin,English uses other keymap Aug 19 15:44
juhp so don't need to define them per se Aug 19 15:44
juhp ok phonetic Aug 19 15:44
dychen whot: in other words, what can we use to describe the location of the symbol? Aug 19 15:44
juhp well maybe we just try and see what happens ;o) Aug 19 15:45
pravin_s i saw people newbies in language technology graps other keyboar layout say itranse quickly Aug 19 15:45
juhp dychen: an xkb layout? Aug 19 15:45
juhp pravin_s: aha Aug 19 15:45
dychen juhp: Something like that. Aug 19 15:45
juhp I don't see any other way :) Aug 19 15:45
juhp phuang: so in that sense the "ibus orth" would be nice Aug 19 15:46
juhp even though I didn't explain what I mean by that :) Aug 19 15:46
dychen juhp: orth? Aug 19 15:47
juhp dychen: so one would switch to chewing say by switching to chewing layout in xkb Aug 19 15:47
juhp and input would turn on xkb automatically Aug 19 15:47
juhp dychen: so I mean auto-enabling ibus IME dependent on the symbols being input Aug 19 15:47
juhp :) Aug 19 15:47
juhp eg kana input might enable anthy Aug 19 15:49
whot dychen: sort-of, yes. if you look at /usr/share/X11/xkb/, you'll see all the files required Aug 19 15:50
juhp anyway many IMEs has using phonetic based (letter) input Aug 19 15:50
juhp have Aug 19 15:50
whot http://who-t.blogspot.com/2008/09/rmlvo-keyboard-configuration.html Aug 19 15:50
whot has a bit of information there Aug 19 15:50
dychen juhp: One question is , when people switch to Zhuyin layout, they may either expect chewing or plain Zhuyin. :-) Aug 19 15:51
juhp dychen: right that is also true Aug 19 15:51
juhp so need some config for that... Aug 19 15:51
whot essentially there's a mapping from keycode -> intermediate key name (e.g. AD01 for first key in second row), then there's an assignment of AD01 to the symbols. Aug 19 15:51
whot when the whole thing is assembled, those two are hooked up together Aug 19 15:51
dychen So we need at least 2 layers, the "symbol layout" and input method. Aug 19 15:52
juhp yeah that is the idea Aug 19 15:52
whot dychen: yes, the symbol layout is supposed to represent what's printed on the keyboard (more or less) Aug 19 15:52
dychen whot: That's what I am talking about. :-) Aug 19 15:52
juhp phuang: does ibus currently support non-ascii input or is it up to the IMEs? Aug 19 15:53
phuang juhp, it just pass the keycode and keysym to IME Aug 19 15:54
juhp from the UI pov of course using both gnome-keyboard-applet and ibus applet is awkward at best Aug 19 15:54
juhp phuang: ok cool Aug 19 15:54
phuang juhp, But all Engines can only process ascii chars. Aug 19 15:54
juhp ah Aug 19 15:54
juhp phuang: currently? Aug 19 15:55
dychen juhp: especially IMs from ibus-table. Aug 19 15:55
juhp or what is the limitation? Aug 19 15:55
phuang yeah Aug 19 15:55
juhp dychen: sure Aug 19 15:55
juhp that is one case Aug 19 15:56
phuang It is an history problem. All engines (includes 3rd part engines) are developed for ascii chars Aug 19 15:56
juhp yup Aug 19 15:56
dychen juhp: same limitation with keysyms or keycode. Aug 19 15:56
phuang for en compatible keyboard Aug 19 15:56
juhp phuang: but in principle nothing to stop say ibus-anthy from accepting kana input, right? Aug 19 15:56
dychen can kana pass though either keysyms or keycode? Aug 19 15:57
phuang juhp, yeah. Maybe except some feature Aug 19 15:57
*whot has to run for the bus Aug 19 15:57
juhp thanks whot Aug 19 15:58
juhp phuang: ok Aug 19 15:58
<--krishnababu has quit (Success) Aug 19 15:59
juhp guess in the end the goal would be drop use of keycodes inside ibus Aug 19 15:59
juhp but yeah it is valid point of tables and maps still assuming qwerty, hmm Aug 19 16:00
juhp but that is legacy stuff really - not much we can do there I feel Aug 19 16:01
juhp they should specify a layout I guess Aug 19 16:01
juhp anything else that needs keycodes? Aug 19 16:02
dychen juhp: contingency plan: all IM can still embrace en-Qwerty layout. Aug 19 16:02
-->krishnababu (n=kkrothap@115.184.60.212) has joined #fedora-i18n Aug 19 16:03
juhp dychen: want to expand on that? :) Aug 19 16:03
juhp all? Aug 19 16:04
dychen juhp: Sorry, no. Aug 19 16:04
juhp the main limitation I see is xkb limiting currently to 4 groups (layouts) Aug 19 16:05
juhp but the plus side is no weird assumptions/hacks for layouts + some new UI complexity to solve Aug 19 16:06
juhp I don't think this will all land in f12 but it is a goal for us to be working towards IMHO Aug 19 16:06
juhp and will finally bring xkb and im together or on speaking-terms at least ;) Aug 19 16:07
phuang juhp, actually, the assumption is the the keycodes from X are same with keycodes from Linux kernel evdev Aug 19 16:07
dychen when will xkb2 in charge? Aug 19 16:07
juhp dychen: not sure... maybe next year? Aug 19 16:07
juhp phuang: for ? Aug 19 16:08
phuang juhp, Linux kernal defines the keycode in head file Aug 19 16:08
juhp ok Aug 19 16:08
phuang juhp, So it should not be changed Aug 19 16:08
juhp phuang: but how does it relate to im? :) Aug 19 16:08
juhp phuang: you lost me slightly :) Aug 19 16:09
phuang juhp, the im needs constant keycode values Aug 19 16:09
juhp phuang: for tables and maps? Aug 19 16:09
juhp or why? :) Aug 19 16:10
juhp phuang: I guess that works but it is still a hack really Aug 19 16:11
phuang In my point of view, the problem of current solution is we assume the keycodes are constant. right? Aug 19 16:12
juhp phuang: right Aug 19 16:12
phuang juhp, any other problem? Aug 19 16:12
juhp ah sorry see your point now Aug 19 16:12
juhp thought you were trying to say something else :) Aug 19 16:12
juhp exactly Aug 19 16:13
juhp so with xkb we no longer need that assumption really Aug 19 16:13
juhp modulo some maps that assume qwerty Aug 19 16:13
phuang with xkb, we only need define only one layout Aug 19 16:14
juhp phuang: so guess we still need keycodes hack for those for now anyway Aug 19 16:14
juhp phuang: right Aug 19 16:14
juhp though we can have more Aug 19 16:15
phuang more layouts is difficult Aug 19 16:16
juhp I think xkb switching is kind of open game anyway - you can do it with setxkbmap, or gnome-keyboard-applet, gdm, or ibus... Aug 19 16:17
juhp phuang: in what way? Aug 19 16:17
juhp well it certainly adds to complexity I don't deny Aug 19 16:17
phuang but how about console clients Aug 19 16:17
juhp hmm Aug 19 16:17
juhp good question! Aug 19 16:17
dychen consider there is something like ibus-fbterm available.... Aug 19 16:18
juhp hmmm Aug 19 16:18
phuang we can not like console to change layout for our IMEs Aug 19 16:19
phuang s/like/let Aug 19 16:19
juhp until now we/I didn't consider console... Aug 19 16:20
phuang Or we can not define may layouts for different kinds of clients (X, console, and etc) Aug 19 16:20
juhp ideally we should have something like xkb on console too but... Aug 19 16:20
dychen or unify them. Aug 19 16:20
juhp phuang: perhaps we need to change console layouts too? Aug 19 16:20
juhp dychen: yeah Aug 19 16:20
phuang So, if let ibus handle the conversion from keycode to keysyms, it will be easy Aug 19 16:21
juhp perhaps we need to go back to whot... Aug 19 16:21
phuang We just need define one layout in xkb, it could convert different keycode to one unified keycode for ibus Aug 19 16:22
juhp phuang: what about all the above discussion... Aug 19 16:22
juhp and different kbd models? Aug 19 16:23
juhp phuang: and xkb users? Aug 19 16:23
dychen where should we put this universal keycode <-> keysym conversion tables? Aug 19 16:23
juhp phuang: so we just use xkb keycodes and forget about xkb symbols completely? Aug 19 16:24
juhp hmm Aug 19 16:24
phuang dychen, I think it should be split into two steps Aug 19 16:25
juhp maybe we need to think more if we really want to support console Aug 19 16:25
juhp to me console is not that important a case Aug 19 16:25
phuang universal keycode -> unified keycode -> keysym Aug 19 16:25
phuang the first step could be done in xkb Aug 19 16:25
phuang the second step is in ibus Aug 19 16:25
juhp what does unified mean here? Aug 19 16:26
juhp I still fixing the xkb/im issue is more important than console Aug 19 16:26
phuang It is same with linux kernel evdev Aug 19 16:26
juhp so universal and unified keycodes are all different? Aug 19 16:27
phuang all different? Aug 19 16:27
dychen How about keycode->keysym handle by xkb/xkb2, then ibus (in x11) convert keysym string to characters? Aug 19 16:28
juhp hmm Aug 19 16:28
juhp maybe we need to think more Aug 19 16:28
juhp dychen: is that where we are? Aug 19 16:28
phuang I think it is same in Linux, but maybe different in other platforms Aug 19 16:28
juhp s/is/isn't/ Aug 19 16:29
juhp phuang: ok Aug 19 16:29
dychen juhp: Currently ibus do keysym-> character and keycode-> character. Aug 19 16:29
juhp yup Aug 19 16:29
juhp ok Aug 19 16:29
phuang dychen, You suggestion is same with ibus-1.1.x Aug 19 16:30
juhp right Aug 19 16:30
juhp ok let's talk more to whot about console side tomorrow Aug 19 16:30
juhp * bugs Aug 19 16:31
juhp anyone have any bugs to discuss? Aug 19 16:31
dychen phuang: Well, I think whot prefer this way.. Aug 19 16:31
phuang dychen, It needs xkb do right conversion for each imes Aug 19 16:31
dychen hmm Aug 19 16:32
juhp or some may to emulate xkb inside ibus? Aug 19 16:32
juhp but hmm maybe not Aug 19 16:32
juhp https://bugzilla.redhat.com/buglist.cgi?product=Fedora&field0-0-0=component&type0-0-0=regexp&value0-0-0=^ibus.*&bug_status=NEW,ASSIGNED Aug 19 16:33
juhp dychen: I'll try bug 513895 again Aug 19 16:37
juhp .bug 513895 Aug 19 16:37
zodbot juhp: Bug 513895 new IME does not show up in ibus-setup - https://bugzilla.redhat.com/show_bug.cgi?id=513895 Aug 19 16:37
dychen juhp thanks Aug 19 16:37
juhp phuang: how about the icons: Aug 19 16:39
juhp .bug 501214 Aug 19 16:39
zodbot juhp: Bug 501214 need better icon: light blue ibus icon is not obvious - https://bugzilla.redhat.com/show_bug.cgi?id=501214 Aug 19 16:39
Kaio most bugs in engines will make it doesnt show up in ibus-setup Aug 19 16:40
Kaio afaik Aug 19 16:40
juhp .bug 514192 Aug 19 16:40
zodbot juhp: Bug 514192 ibus toolbar should use config icon for setup - https://bugzilla.redhat.com/show_bug.cgi?id=514192 Aug 19 16:40
dychen phuang: ibus-1.1 is still based on ascii keysym. but under the "new architecture", we should rely on keysym like Zhuyin symbols, Cangjie/Wubi wordroots, something like those. Aug 19 16:40
juhp kaio: oh Aug 19 16:40
Kaio juhp☺ everytime tracebacks in ibus-table makes it disappeared from ibus-setup Aug 19 16:42
dychen phuang: IM methods only convert Zhuyin symbols, Wubi wordroots to characters, while xkb2 convert key press to these symbols. Aug 19 16:42
phuang dychen, aha Aug 19 16:44
juhp dychen: I don't think xkb2 is required for that - just some layouts :) Aug 19 16:44
phuang Kaio, I think juhp mean when you install new IME, ibus should detective the new IME without restart Aug 19 16:45
juhp phuang: right Aug 19 16:45
phuang juhp, right Aug 19 16:45
Kaio phuang☺ really it does do? Aug 19 16:45
dychen phuang: Of course, we assume that IM developers are willing to submit their wordroots. :-P Aug 19 16:45
phuang Kaio, currently, we need restart ibus-daemon Aug 19 16:45
Kaio phuang☺ mostly I just ibus-daemon -rt forcibly Aug 19 16:45
dychen wordroots as layout. Aug 19 16:46
phuang dychen, But i think they do not like do it Aug 19 16:47
phuang xkb layout is complex Aug 19 16:47
dychen phuang: So we are at where we are. :-) Aug 19 16:47
juhp dychen: some of that might still be a bit down the road Aug 19 16:47
juhp right Aug 19 16:47
juhp phuang: what do you think of the newer ibus icon? Aug 19 16:48
juhp phuang: do you need a patch for the toolbar setup icon? Aug 19 16:48
dychen juhp, I do suggest ibus icon theme. :-) Aug 19 16:48
*juhp would rather not go there Aug 19 16:49
juhp but I can't stop it :) Aug 19 16:49
juhp I prefer good defaults Aug 19 16:49
juhp dychen: themes tend to break Aug 19 16:49
phuang we can change ibus icon, but how to deal icons for engines Aug 19 16:49
juhp ah you mean my further rfe? :) Aug 19 16:50
juhp or the toolbar? Aug 19 16:50
phuang I think we just need a better icon to replace the blue [I] Aug 19 16:51
dychen Ask community to make some and vote? Aug 19 16:52
juhp phuang: right Aug 19 16:53
phuang icons of engines, we should not control them Aug 19 16:53
dychen and we cannot control them. Aug 19 16:54
juhp phuang: ok let's ask mlanglie for svg? Aug 19 16:54
juhp phuang: sure - but ibus defines ibus-setup.svg, no? Aug 19 16:54
phuang yeah Aug 19 16:55
juhp I am suggesting to change that icon too... Aug 19 16:55
phuang ok Aug 19 16:55
juhp :) Aug 19 16:55
phuang http://productdesign.usersys.redhat.com/wiki/IBus Aug 19 16:55
juhp yeah internal to redhat only unfortunately Aug 19 16:55
phuang juhp, which icon is better for replace [i] Aug 19 16:55
Kaio nice hostname Aug 19 16:55
juhp so suggested the latest one Aug 19 16:55
phuang juhp, The background is the earth Aug 19 16:57
dychen I like take 4 best. Aug 19 16:57
*juhp looks again Aug 19 16:58
juhp dychen: that is the newest one Aug 19 16:58
juhp phuang: no the first one on the page Aug 19 16:58
phuang juhp, ic Aug 19 16:58
paragan take3 Aug 19 16:58
phuang I think the color is little dark Aug 19 16:59
juhp phuang: take4? Aug 19 16:59
phuang yeah. Aug 19 16:59
juhp hm Aug 19 16:59
phuang how about make it more colourful Aug 19 16:59
juhp the others look darker to me... Aug 19 17:00
juhp phuang: well you can suggest it but I don't see how Aug 19 17:00
paragan is take4 looks similar to scim icon in systray? Aug 19 17:00
juhp paragan: it does Aug 19 17:00
paragan ok Aug 19 17:00
juhp just better ;P Aug 19 17:00
phuang Maybe it is good for displaying on systray Aug 19 17:01
phuang but is it good for project logo? Aug 19 17:01
dychen What's amarok's icon, BTW? Aug 19 17:02
dychen stardict is just books.. audacious is just a black 'a' in surrounding by gray circle in black square. Aug 19 17:04
juhp phuang: project logo is up to you :) Aug 19 17:04
juhp I am just worrying about what is on desktop :) Aug 19 17:04
juhp I don't think they have to be same Aug 19 17:04
dychen beryl is just.. beryl. :-) Aug 19 17:05
phuang So we will use different icon for fedora Aug 19 17:05
juhp hm Aug 19 17:05
phuang I think it is better to use same icon Aug 19 17:06
juhp ok Aug 19 17:06
juhp to me it is about input status not the project Aug 19 17:06
juhp I talked about my ideas before so I won't repeat them again now... Aug 19 17:07
juhp on the systray applet Aug 19 17:07
juhp ok 2 hours passed I suggest we here or soon Aug 19 17:08
juhp anyone have anything else? Aug 19 17:08
juhp phuang: you prefer current icon to take4? Aug 19 17:10
juhp anyway thanks everyone for the long meeting Aug 19 17:11
juhp though it seemed to create more questions than answers? ;) Aug 19 17:11
juhp # meeting closed Aug 19 17:12

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!

Retrieved from "https://fedoraproject.org/w/index.php?title=I18N/InputMethods/Meetings/2009-08-19&oldid=471542"