[17:38:02] There it is [17:41:23] Hmm https://bugzilla.wikimedia.org/show_bug.cgi?id=20128 came in over the weekend, shouldn't be hard to fix I think [17:44:46] I will build a UI element with HTML and javascript that will replace it [17:44:54] :) [17:44:54] OK great [17:45:04] I'm gonna dig up my laptop and get setup for the Skype call now [17:45:08] we should meet in 15min we can talk about it more :) [17:45:10] sweet [17:58:29] *RoanKattouw sets laptop clock back to CEST from SF time ^^ [17:58:52] OK I'm all set up for the Skype call, I do have a mic issue that causes some noise though, we'll see [17:59:03] If we hate it we can always use the phone I guess [18:08:59] ok [18:13:24] somebody boot TrevorParscal [18:13:27] he's got my name! [18:17:48] ghost him TrevorParscal_ [18:55:52] God I hate RTL xD [18:56:22] nkomura: Yesterday there was a volunteer dev here (vvv) who's gonna write about Acai on a Russian IT web site and will provide us with an English summary if he gets useful feedback on it [18:57:43] nkomura, TrevorParscal : Also, do we want per-hour stats? We wouldn't have one bar per hour, but it'd try to show approx. 10 bars with e.g. 0-8, 9-16, etc. [18:58:24] is there a way to select that in the UI - like we have for http://wiki.wikked.net/wiki/Wikimedia_statistics/Monthly [18:58:38] just have links for hourly, daily, weekly, monthly, yearly [18:59:07] Yes. Currently only works with the &inc= parameter but I could add links for that [18:59:19] (try &inc=2 on prefstats to see what I mean) [19:03:13] TrevorParscal: http://ar.wikipedia.org/w/index.php?title=%D9%85%D8%B3%D8%AA%D8%AE%D8%AF%D9%85:Catrope&action=edit shows the toolbar for me [19:04:55] ha [19:04:58] I wasn't opted in [19:05:05] but my skin was set to vector [19:13:05] Aaah [19:13:16] OK a few more things I thought of over the weekend [19:13:50] We've got quite a volume of filled-out surveys built up already (10k+ on enwiki I think), we should start reading their feedback now or the backlog will be too large to cope with (IMO) [19:14:29] The edit toolbar is not shown on User:Foo/foo.js or .css . This is deliberate and has been in the software since 2004 or earlier, but I'm wondering whether it's desirable [19:14:37] I also don't know what the reasoning behind it is [19:14:51] *brion-codereview stabs TrevorParscal with a lunchtime [19:15:05] RoanKattouw: those aren't wikitext pages [19:15:15] i don't recall the change being made but it makes sense to me :) [19:15:33] Neither is MediaWiki:Common.css for instance, but you may still want to use special characters or something [19:15:46] Anyway [19:16:01] And someone on usabilitywiki suggested adding a search&replace which frwiki(?) had added locally [19:16:05] do you want a distinct toolbar mode for JS/CSS pages? [19:16:25] We could do that as a content generation dialog, I've already written a one-liner JS to do the actual S&R [19:16:37] Nah that'd be overkill [19:25:27] TrevorParscal: poke poke lunch status over there? [19:26:55] nkomura: parutron nimish_g poke poke? [19:26:59] y'all dead over there? [19:27:08] hi hi hi [19:27:18] it's eugene's brown bag lunch! [19:27:20] it's NOM TIME [19:27:40] naoko and trevor have nom nomed their way over to south park.... [19:27:48] i'm hoping to join, but needing to get a few things done first. [19:27:56] nimish_g is apparently fasting today. [19:28:00] hm? [19:28:02] tee hee [19:28:03] just kidding [19:28:06] :) [20:38:29] brion-codereview: so, it looks like the $wgExtNewFields[] works for adding columns to a database, but not modifying existing columns...is there already a way to do that easily? [20:41:21] nimish_g: I don't think there is, currently [20:41:32] Ran into that problem myself [20:41:44] You may have to add a way to do it [20:42:17] ok, will do [20:42:25] nkomura_away, TrevorParscal: Stacked charts demo @ http://prototype.wikimedia.org/en.wikipedia.org/Special:PrefStats/skin [20:43:03] sweetness! [20:43:15] only accessible to admin.... [20:43:38] yeah, could I get admin on there as well? [20:43:53] nimish_g: Sure, what's your username? [20:44:34] TrevorParscal: List of what I'll ask Brion to scap if all of you are OK with it: http://dpaste.org/Qngd/ [20:44:44] "Nimish Gautam" [20:45:02] moment [20:45:20] brion-codereview: Need an OK from the team first, relax ;) [20:45:31] nimish_g: Gave you sysop and bureaucrat, enjoy [20:45:36] nimish_g: for that you basically need to run a func which'll check the db structure to see if it's what you want. there's not a generalizable thing for it [20:45:51] RoanKattouw: last item, let me look at the revs... [20:45:53] hld [20:46:00] RoanKattouw: can i admin access to prototype too? [20:46:07] nkomura_away: Shuhari? [20:46:13] yup [20:46:33] Done [20:46:43] Only on en prototype for you two though, will do the others in a minute [20:47:16] I don't see the thing I wanted to not deploy. the jquery event for toolbarConfi [20:47:27] which is good [20:47:32] just making sure [20:47:34] brion-codereview: cool, I'll just do it the way we're doing it for Postgresql [20:47:40] Yeah I figured that wasn't important to deploy fast [20:48:27] RoanKattouw: ok, yeah - we may even revert it - it's not a problem having it in trunk, but if we give users that they will depend on it.. I want them to use the API :) [20:48:29] well if everyone is doing it..... [20:48:31] tee hee [20:48:33] it will be less error prone [20:48:35] nimish_g: what we should do in general is fix up the extension updater hooks to work like the built-in ones after i restructured them last year [20:48:35] welcome back roan! [20:48:37] Yeah [20:48:44] Thanks parutron :P [20:48:45] so we have a single temporal stream of all update types [20:49:01] then we should probably also add in a type that'll help with the change-a-field-type case [20:49:20] brion-codereview: You mean that extensions still use the deprecated way of executing the query on their on instead of adding to $wgExtNewWhatever? [20:49:34] RoanKattouw: no, i mean $wgExtNewWhatever sucks ass [20:49:39] TrevorParscal: Yeah, figured it wouldn't hurt while still in trunk [20:49:48] brion-codereview: Heh, what do you suggest then [20:49:50] there's no way to express the order of dependencies [20:49:58] RoanKattouw: what i said above :) [20:50:01] see updaters.inc [20:50:08] Ah yes [20:50:24] core updaters have a single array for all types of updates, regardless of which method they're doing [20:50:30] that way they get done in proper order [20:50:36] So you want extensions to like insert in the middle of that array, or break it up per-version or something [20:50:46] not necessarily that array [20:50:52] Oh yeah I get it [20:50:53] but to be able to express all of their own updates in order [20:51:08] There's no way to do table-index-table for instance [20:51:22] Because it does all tables first then all indices [20:51:35] RoanKattouw: I notice you switched away from js2AddOnloadHook to using jQuery directly [20:51:42] what happened there? [20:51:57] TrevorParscal: JS2 might be disabled, not sure if I could rely on js2AddOnloadHook() being present [20:52:11] Feel free to change back if you're sure it's safe on e.g. enwp [20:52:21] Did that because I initially misunderstood why it broke [20:52:22] oh - umm... look at js/js2.js [20:52:42] (the real reason was that you'd removed optInGetPOSTData(), not JS2 or $ vs. $j vs. jQuery) [20:52:46] if js2 is not enabled, we fake it in a few ways, so that when it is, all is well [20:52:55] understood [20:53:09] So it was a misunderstanding, feel free to change back [20:53:51] But as both are equivalent if JS2 is disabled (js2AddOnloadHook() is just a wrapper around jQuery's document ready in that case), it shouldn't matter on enwp so that rev changing it back wouldn't have to be deployed, right? [20:53:58] *RoanKattouw tries to ease review load on brion-codereview a bit [20:54:16] \o/ [20:54:22] TrevorParscal: Anything I need to change about the PrefStats page in your opinion? [20:54:34] looking in a sec [20:54:50] *RoanKattouw points parutron and nkomura_away to http://prototype.wikimedia.org/en.wikipedia.org/Special:PrefStats/skin once more [20:55:03] Meh I'll just allow Special:PrefStats for everyone on prototype [20:55:23] am I an admin? [20:55:28] it seems not. [20:55:31] No, but you don't need to be anymore [20:55:33] Reload the page [20:55:46] reloaded and works! [20:56:44] It should be noted that if you try to click hourly on large data sets, the data can become too much for Google Charts too handle (or rather, the URL becomes longer than 2047 chars), and the graph disappears [20:57:07] woo hoo! [20:57:10] this is fabulous. [20:57:20] eeeps, can't wait to see the feedback everyone has left... [20:57:55] ok dudes, coming over to yer office :D [20:57:55] RoanKattouw: hourly should have a limit of 24 hours? [20:58:01] yay time scale views [20:58:01] beautiful [20:58:07] just merged the vector updates... [20:58:07] RoanKattouw - YAY! [20:58:26] and yay - brion is coming over! [21:00:35] What do you mean, cut off after 24 hrs? [21:00:41] That's an idea [21:01:59] OK I changed the code a little bit, if you haven't selected per hour or per day or whatever, it'll now try to get 15 bars instead of 10 [21:02:21] good work on the tabs being shown immediately [21:02:23] that's cool [21:02:30] we will add the spinner back in soon [21:03:39] parutron: I was saying earlier, we should probably start processing that ASAP if we don't wanna get swamped in it [21:04:39] yes lets! [21:04:50] how can i help? [21:05:05] You can't do much yet until we actually give you the data :) [21:05:14] I'll be poking some people to get you dumps from enwp [21:05:21] yippee! [21:05:31] Which probably has between 10k and 20k surveys already [21:05:36] um, what???? [21:05:42] really? [21:05:44] egads! [21:05:50] it's brion! [21:06:00] or is it brion-clone? [21:06:04] Hey brion [21:06:15] RoanKattouw: you've got my OK on your patches tagged as acaifix [21:06:19] OK [21:06:31] List of revs we'd like to put live (if the rest of the team approves) @ http://dpaste.org/QfYO/ [21:07:06] Oh wait, something's wrong with r54720, double-escaping of quotes in the JS message [21:07:09] Lemme quickie fix that [21:07:09] hey dudes [21:07:11] RoanKattouw: are those core or ext? [21:07:13] i was gonna just merge the whole ext set :) [21:07:15] Ex [21:07:17] t [21:07:19] No, please don't [21:07:26] There's some stuff in there we don't wanna put live [21:07:35] :( [21:07:41] ok [21:07:48] I know this increases the time you'll have to wait on slow SVN merges, I apologize [21:08:07] why don't you go ahead and merge the extension bits that you want yourself and we'll see hwo that goes :D [21:11:26] OK I'll merge them into wmf-deployment then [21:12:37] excellent :D [21:13:39] now my plan is to be doing general merges from trunk to wmf-deployment on a 2- or 3-week schedule. anything we need to keep in mind with your dev work on the ext and vector ends? [21:15:47] Not really, we will be doing bug fixes quite often, but critical ones seem to be settled so, 2-3 weeks should be good for us [21:18:37] *RoanKattouw does initial checkout of wmf-deployment branch, pretty huge [21:22:54] yeah it's got a bunch of extensions we don't actually use ;) i'll trim it later today [21:28:50] Damn every rev so far is causing merge conflicts :( [21:32:23] :( [21:35:14] brion-meeting: Do you care about svn:mergeinfo? [21:35:25] *shrug* [21:35:31] not really sure how it works ;) [21:35:34] Because EditToolbar.i18n.php is giving me some trouble [21:38:35] brion-meeting: after your meeting, you think you could point me to the extensions updating framework you were talking about? the only updating stuff I found in the code was the stuff marked 'fixme' =) [21:41:04] brion-meeting: I'm merging all i18n updates to the UI extension so those merge conflicts will leave me alone [21:49:50] RoanKattouw: have we committed a fix for the textarea back-button thing yet? [21:50:02] nimish_g: sure :D [21:50:13] i18n is hell, yeah ;) [21:58:29] brion-meeting: No. Trevor said he'd work on it [21:58:41] As a temp fix we can remove the header [22:00:53] brion-meeting: OK, I'm done merging, now I just have to figure out what I merged from bash history :P I merged some stuff in the wrong order so I'm afraid I might've borked the svn:merge-info stuff which may cause problems for the next merge, but we'll see about that later. [22:14:56] brion-meeting: OK, merge committed, recommend letting us test for breakages on testwiki first, it has a huge mess :( [22:15:04] Seems to have taken me no less than an hour [22:16:54] brion-meeting: Oh and when it's deployed it also needs $wgPrefStatsTrackPrefs['useeditwarning'] = 0; (not critical, but would be appreciated) [22:24:21] i18n is good compared to configuration [22:30:29] ? [22:33:54] ? [22:34:38] TrevorParscal: Is Brion still at our office? [22:35:23] just left [22:35:49] Ah OK [22:36:02] I'll stalk him when he arrives at Stillman then [22:36:22] I spent an hour untangling this merge mess, now I wanna see it deployed :P [22:38:52] !log andrew synchronized php-1.5/wmf-config/InitialiseSettings.php 'Bug 20001 -- activate fancy edit toolbar by default on strategy wiki' [22:48:46] brion: I've done the merge, could you put it live on testwiki so we can verify I didn't screw anything up? [22:49:38] woot [22:49:39] sec [22:53:11] Parse error: syntax error, unexpected T_SR, expecting ')' in /Library/WebServer/Documents/wmf-deployment/extensions/UsabilityInitiative/PrefStats/PrefStats.i18n.php on line 38 [22:56:27] Sorry about that, fixed it [22:56:31] Left a conflict marker [23:04:06] why would usability people use a channel that has an underscore in it [23:04:21] isn't that the exact opposite of usable? [23:04:36] It's just an extra press of Shift really [23:04:53] well actually there is a policy problem with it, this channel is technically not allowed [23:04:58] I'm not fond of it either but moving is too much of a hassle [23:05:14] lol there's another channel used by WMF staff that has a _ in it [23:05:28] primary channels (#) are reserved for registered groups, and #wikipedia_usability isn't one :) [23:05:38] but no one is going to be so technical [23:06:05] *TrevorParscal sees Prodego make a mountain from a mole hill [23:06:19] anyway, regarding the vector skin, I was wondering specifically about the choice to position 'delete' in a drop down menu [23:06:21] Mah let the freenode folks bite me; I registered this channel with ChanServ and it let me ^^ [23:06:50] TrevorParscal: There's been lots of criticism on New section being in the dropdown menu the last few days [23:07:11] RoanKattouw: We actually have plans for that [23:07:15] that too (although I usually just edit the last section) [23:07:35] Eventually it won't matter because of liquid threads [23:07:43] ok guys ready to scap? [23:08:16] but in the mean time, we are moving it up, and in babaco the tabs will by dynamic (showing as many as possible within the given screen size, using the dropdown as an overflow only [23:08:54] brion: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/54752 ? [23:08:55] scapping [23:08:58] that's a neat idea [23:09:20] TrevorParscal: yes yes, but delete is a problem for a lot of people [23:09:28] because if you want to delete a bunch of pages [23:09:34] use Special:Nuke [23:09:41] that would require they be by the same author [23:09:43] (or maybe that's got too speciifc limitations) [23:09:52] brion: WAIT [23:09:54] lets say you are going through csd [23:10:09] brion: Make sure you catch r54757 [23:10:19] Damn he already started [23:10:24] *TrevorParscal is looking through merges [23:10:35] they all look fine to me [23:10:43] brion: I committed during scap, that's probably gonna cause nasty issues anyway, so I suggest you immediately scap again when it finishes [23:11:00] sigh [23:11:11] ha... r54757 you mean? [23:11:39] brion: And I'd like $wgPrefStatsTrackPrefs['useedittoolbar'] =0; to be set on all wikis [23:11:46] Oops make that useeditwarnig [23:11:51] *useeditwarning [23:11:52] *RoanKattouw can't type [23:12:09] Oh wait Fred might be doing that already [23:12:14] *TrevorParscal thinks roan has had too much coffee [23:12:19] :) [23:12:25] Dude [23:12:26] TrevorParscal: also, the AJAX 'watching...' / 'unwatching...' is ugly [23:12:28] ok redeploying @ 54757 [23:12:33] You know I don't drink coffee [23:12:38] of course, that is bad in monobook too [23:12:50] In fact, I could use some, I'm obviously not fully awake any more [23:12:51] hmmm [23:13:00] Prodego: also something we have plans for [23:13:05] brion: Fred seems to have done the config change already [23:13:11]

 sections seem to have gotten smaller: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/54754 etc
[23:13:20] 	font size used to be a bit bigger
[23:13:21] 	Prodego: are you interested in voicing complaints or asking questions?
[23:13:41] 	Both, I was wondering why some of the design decisions were made
[23:13:55] 	I'll no doubt have lots of comments after I have used it more, and more things come up
[23:14:12] 	the biggest thing is that I miss my monobook specific javascript :)
[23:14:12] 	brion: in relation to r54601 ?
[23:14:16] 	perhaps?
[23:14:32] 	nkomura, parutron: Stacked charts live @ http://en.wikipedia.org/wiki/Special:PrefStats/skin
[23:14:41] 	Prodego: now is a good time to dust off your javascript book then :)
[23:14:42] 	mebbe. anyway just adding that to yer list to look at :D
[23:14:53] 	wow
[23:15:06] 	TrevorParscal: heh, I would, but I didn't write the javascript to start with, so it would be difficult
[23:15:15] 	stole it from essjay
[23:15:23] 	I think this would be the perfect time to get the user/common.js finished
[23:15:28] 	Prodego: soon lots of new scripts for vector will pop up
[23:15:37] 	great presentation
[23:15:46] 	RoanKattouw: so what's the vertical scale?
[23:15:52] 	and the difference between the two bars?
[23:15:56] 	TrevorParscal: true, mine has been pretty custom though, I'm the only one using the interface I am, so far as I know
[23:16:02] 	RoanKattouw: the number on the first day does not look right
[23:16:02] 	on/off? this week / last week?
[23:16:14] 	different prefs we're tracking?
[23:16:16] 	I get "=Unauthorized= You are not allowed to execute the action you have requested."
[23:16:22] 	Prodego: so, basically, the changes we are making are not intended to ane
[23:16:25] 	after a couple shft+reload
[23:16:33] 	brion: vertical -> number of people
[23:16:35] 	parutron: Sorry, you're not a sysop on enwiki
[23:16:35] 	*anger you, but they are also not aimed at you
[23:16:38] 	light blue - opt-in
[23:16:39] 	but I am
[23:16:43] 	dark blue - opt-out
[23:16:45] 	RoanKattouw: any reason not to make the stats chart pubicly viewable?
[23:16:54] 	and I get
[23:16:54] 	that message too
[23:16:55] 	i might recommend adding a label for that :)
[23:16:55] 	brion: DB load
[23:17:12] 	"You are not allowed to execute the action you have requested."
[23:17:15] 	we could cache the queries hourly and make them public
[23:17:15] 	Yeah the light/dark thing should be labeled
[23:17:20] 	could we maybe store the numbers and make em non-loady? :)
[23:17:24] 	It lets you add a legenda, will do tomorrow
[23:17:34] 	ok
[23:17:36] 	awesomes
[23:17:45] 	I'd love for this to be public.. so.. caching it is!
[23:17:47] 	brb
[23:18:02] 	Yeah we could cache them hourly, I'll implement that tomorrow if brion (poke) is down with it
[23:18:49] 	Prodego: so, you are not the kind of user these changes help, in fact you may never want to use Vector and the new toolbar - its users who don't even know they can edit yet that we are targeting...
[23:19:00] 	RoanKattouw:  thanks a lot for opt-out number overlaid
[23:19:00] 	nkomura: Yes, dark blue is opted out, light blue is still opted in, correct
[23:19:05] 	Seeing through their eyes will help you to see why we've done what we have
[23:19:18] 	the opt-out rate on the first date is remarkable...
[23:19:26] 	TrevorParscal: the users you want to attract will at some point be doing what I am though :)
[23:19:33] 	nkomura: That's not the first day
[23:19:42] 	nkomura: It means most people who opted out did so within 24 hrs
[23:19:56] 	nkomura: Only 9 users stayed opted in for 90+ hrs and then opted out
[23:20:09] 	Prodego: and they will learn a different way of doing things because of the new UI being... not monobook
[23:20:54] 	has anyone (except me :p) looked at ways in which wiktionary editing could be improved?
[23:21:48] 	brion: Y axis is # of users, X axis is in hours
[23:22:28] 	brion: What it says now is that 3342 users opted into Vector and back out within 24 hrs, while 1495 users enabled Vector less than 24 hrs ago
[23:22:39] 	RoanKattouw: hour chart started looking too crowded
[23:22:43] 	I see how non-intuitive this is now :)
[23:22:47] 	nkomura: Yes, I know
[23:23:00] 	When the dataset gets too large it won't even display any more, too much data
[23:23:12] 	RoanKattouw: i think we need to send you bed :)
[23:23:17] 	it is so late for you!
[23:23:30] 	Interesting though is that 2849 users opted back out within an hour
[23:24:04] 	if they're like me they just did it to see what was going on without any intention of actually using it
[23:24:23] 	nkomura: Would you like me to do a more intuitive graph in addition to this one grouping users by date+time of opting in instead of duration of being opted in?
[23:25:26] 	(for what it's worth, it shouldn't ask for me to leave feedback when I click Leave after I already gave feedback using the give feedback link)
[23:25:37] 	as discussed, we should keep the total numbers of opt-in and opt-out and the ration
[23:25:42] 	but it can be in the touble
[23:25:47] 	no need to be in the graph
[23:28:46] 	i meant to say "table" not "touble"
[23:28:51] 	Yeah got that
[23:29:04] 	let's discuss tomorrow
[23:29:08] 	Yeah
[23:29:18] 	You're right, I should be in bed
[23:30:44] 	great work RoanKattouw!
[23:31:04] 	hello cirwin!
[23:31:13] 	hi nkomura
[23:31:32] 	if you have specific improvement recommendations for wikitionary
[23:31:42] 	we would like to hear it
[23:31:48] 	the difficulty is mainly that each wiktionary project uses a different format
[23:31:49] 	our focus has been on wikipedia
[23:31:56] 	i see
[23:32:02] 	I'd like to see more things like the assisted translations editor on en.wikt
[23:32:06] 	for other parts of entries
[23:32:14] 	so no wikitext is needed to add data
[23:32:16] 	usability is something for everyone, if the goal is usability, then targeting only the people who do not use the site, is unlikely to make things more usable
[23:33:13] 	I don't know how technical you want to get with usability, but it would certainly make wiktionaries more usable if we had some sense into our formatting - probably too much of a political kettle of fish to get anywhere though
[23:34:06] 	http://www.mediawiki.org/wiki/Click_stats_tracker_requirements <- quickie notes to start. anything you guys wanna add?
[23:34:16] 	Prodego: was that aimed at something I said, or just a statement?
[23:34:25] 	cirwin: The main focus of this project is Wikipedia, not Wikitionary, and we're primarily doing things that benefit all wikis rather than a subset
[23:34:32] 	understandable
[23:34:40] 	cirwin: that was a very late reply to TrevorParscal
[23:34:46] 	though much of the enhancement that you give to wikipedia isn't that useful to wiktionary
[23:35:54] 	i've meaning to create idea box for ideas which can benefit project specific improvements
[23:36:13] 	brion: That seems overly stalkerish to me, would probably generate way too much data, be slow, etc. I think real usability studies are better; of course it's 1:35 now so I'll comment tomorrow
[23:36:14] 	with the new editor, will we still have a way to customize the special characters per-site?
[23:36:18] 	cirwin: Yes
[23:36:27] 	that's fine then
[23:36:33] 	RoanKattouw: what's stalkerish?
[23:36:43] 	listing which toolbar buttons get pressed?
[23:36:46] 	cirwin: yes, I'm working on an API right now
[23:36:47] 	that's very... non-stalkerish
[23:36:53] 	Not so much stalkerish as gathering too much info
[23:36:57] 	And probably too inefficient
[23:36:57] 	as it includes no personal information whatosoever in the universe
[23:36:59] 	it will be very easy to customize the entire editor per wiki or per user
[23:37:00] 	I know
[23:37:12] 	what's "too much info" mean here?
[23:37:13] 	Still, it seems overkill to capture all this information
[23:37:13] 	TrevorParscal: ok, if you added support for having different link-text to the character inserted, we would love you a lot
[23:37:25] 	otherwise adding combining diacritics is a nightmare
[23:37:44] 	if the info you're trying to collect is "how often are the toolbar buttons used" i'm not sure you we could possibly collect lessinformation to get it
[23:37:52] 	brion: It means that storing every toolbar click on enwiki generates a huge set of info that's probably too large for us to handle and causes performance problems
[23:38:04] 	RoanKattouw: sampling is a distinct issue
[23:38:12] 	which can be treated in as much/little detail as you care
[23:38:17] 	Yeah that's true, if you're only storing aggregates you should be fine
[23:38:20] 	but it would help to define what you want to count to begin with
[23:38:38] 	brion: i will add bucket testing - possibly track clicks for two or multiple solutions
[23:38:39] 	Still, an AJAX request for every toolbar click, are we sure we wanna do that?
[23:38:42] 	for an example right now we have NO IDEA AT ALL what the frequency of button presses is
[23:38:45] 	for all we know there's only 100 a day
[23:38:55] 	of course i'm sure there's more than that ;)
[23:39:07] 	Yeah it seems sane to gather some data
[23:39:15] 	RoanKattouw: push that tought back, you're way ahead of yourself
[23:39:23] 	start with asking WHAT you need to collect
[23:39:28] 	i don't know about the performance downsides, but i am VERY PRO gathering this data.
[23:39:29] 	THEN we can worry about the most efficient way to capture it
[23:39:37] 	Yes, you're rigtht
[23:39:51] 	Storing only aggregates like total # of clicks on a certain button should be fine
[23:40:10] 	Then you could submit those numbers on unload or save time
[23:40:37] 	TrevorParscal: (if you look at the hebrew edit tools on en.wikt, you will see the problem that they have)
[23:41:06] 	cirwin: That's done already. In fact, the Hebrew tools have been expanded just now
[23:41:11] 	great
[23:41:15] *cirwin 	is happy
[23:42:05] 	Oh wait I didn't merge those
[23:42:13] 	phew
[23:42:19] 	Recification: the Hebrew expansions aren't live yet. They're on the prototype wiki though
[23:43:07] 	just got confirmation that the enhanced toolbar is not visible for ar.wp with IE7
[23:43:31] 	ok is that an 'it's disabled on arabic entirely' or 'it's broken in ie7 but works in other brwosers'
[23:43:52] 	RoanKattouw: yes, that's a lot better than what we have now
[23:44:08] 	ok they're enabled at least in site config
[23:44:10] 	though I quite like the division into sub-sections, if you're still wanting features
[23:46:14] 	cirw
[23:46:18] 	*sigh*
[23:48:23] 	brion: i'm afraid it is broken...
[23:48:34] 	trevor is looking into it
[23:48:35] 	TrevorParscal: Tomorrow I'll write up a basic framework for content generation dialogs in the toolbar and add one for search&replace as a proof of concept of sorts; you OK with that?
[23:48:55] 	sure - ... um
[23:49:02] 	we are going to use jquery ui
[23:49:14] 	whee
[23:49:16] 	so we need to bundle a copy of that into the js2 stuff
[23:49:21] 	Right
[23:49:27] 	aka, when js2 is enabled, jquery ui is provided
[23:49:39] 	I'll let you handle that I guess
[23:49:49] 	brion: the toolbar for ar works on FF/Chrome/Safari
[23:49:57] 	so far IE7 is confirmed not working
[23:50:00] 	I'll just use ugly prompt() and let you sort out the jQuery UI stuff ;)
[23:50:02] 	I've talked with Michael about making the jquery and jquery ui scripts not be burried in mwEmbed, but either way they should be around...
[23:50:04] 	it is possible IE8 too
[23:50:15] 	Or I might take a stab at it myself if I feel like it
[23:50:16] 	sure
[23:50:34] *TrevorParscal 	is working on ie7 rtl toolbar bug
[23:50:39] 	Yeah
[23:50:42] 	Good luck with that one
[23:50:46] 	I'm off to bed
[23:50:50] 	Night guys
[23:50:59] 	good night
[23:52:19] 	*night