[14:20:11] Morning nkomura [14:20:24] Did you see the improvements I made to search&replace over the weekend? [14:20:27] hey good morning RoanKattouw [14:20:46] i noticed link dialogue was updated ;) [14:20:57] but i didn't look at search and replace [14:21:07] *nkomura will go look [14:23:29] It's mostly in how it doest the actual replacing [14:23:44] It selects the replaced text, and pops up an alert box with "5 replacements made" [14:24:19] hmm, the function does not seem to work [14:24:27] Unfortunately, that message sucks l10n-wise because we don't support pluralization in JS messages [14:24:31] How? [14:24:58] i entered a word for search and replace field, and hit replace [14:25:03] but nothing happens [14:25:11] Hm [14:25:20] Try hitting Replace again? [14:25:57] Also, which wiki is this on? [14:27:12] prototype/en [14:28:00] Hm it works for me there [14:28:09] Could you try clearing your cache? [14:28:26] (Shift+Refresh or Ctrl+R or whatever) [14:28:26] i tried with another article, but didn't work [14:28:31] k [14:28:34] will refresh [14:28:54] also tab didn't work to jump to the next field [14:29:42] Aye, known bug [14:31:03] https://bugzilla.wikimedia.org/show_bug.cgi?id=20567 [14:31:08] yay, it is working [14:31:17] Nice [14:31:33] I probably forgot a styleversion somewhere then [14:31:33] i just did replace all and 11 items replaced [14:31:33] nice [14:31:33] Shouldn't cause any issues on deployment [14:31:54] Another upside of using the select replaced text thingy is it improves compatibility with wikEd [14:32:08] Because it uses the method for replacing the selection, which regular toolbar icons also use [14:32:31] i see [14:38:54] hey RoanKattouw, i meant to send you email, but since i see you here [14:39:11] Yah? [14:39:11] may i ask you to add keywords to bugzilla? [14:39:18] I can't, I'm not a BZ admin [14:39:26] whom can i ask? [14:39:42] siebrand and ^demon, off the top of my head [14:39:45] Maybe werdna is a BZ admin? [14:39:58] i am indeed [14:40:01] Ah nice [14:40:06] yay [14:40:54] so i have a request to add usability keywords to bugzilla, such as "usability" and release names such as "acai", "babaco", and "citron" [14:41:14] so that we can track and target fixes better per release [14:43:02] so you want me to add usability, acai, babaco and citron keywords [14:43:15] yes [14:49:32] RoanKattouw: someone blocked me from editing the main page of usability.wikimedia.org :) [14:49:41] can you restore my write access? [14:50:27] Hm it's been protected so only sysops can edit ti [14:50:32] Lemme try to sysop you [14:50:53] ... and you are a sysop [14:51:15] nkomura: You should be able to edit it; verify that you're really logged in as Shurari and try again [14:51:38] i am logged in.. will check again [14:52:26] i can edit all pages except the main page [14:52:58] the information there is getting there stale, but i get grey box saying i don't have write access to the page [14:54:18] WTF [14:54:23] What exactly does it say? [14:56:16] i should have said that the page is locked.... [14:56:17] You do not have permission to edit this page, for the following reason: This page has been locked to prevent editing. You can view and copy the source of this page: [14:56:28] ... [14:56:31] Shuhari ???(Administrator) (Created on 5 February 2009 at 19:04) [14:57:01] So you should have access [14:57:20] hm [14:57:27] I get [14:57:31] Warning: This page has been locked so that only users with administrator privileges can edit it. [14:57:33] And an edit box [14:57:35] http://usability.wikimedia.org/w/index.php?title=Main_Page&action=edit [14:58:23] added acai keyword, usability already existed [14:58:55] thanks werdna! [14:59:06] babaco, citron added [14:59:33] RoanKattouw: i logged out and logged back in and it worked this time [14:59:46] i should have followed the mantra of the IT crowd [15:00:01] Heh [15:00:05] Very weird though [15:00:14] yeah [15:00:19] Probably just a wron User object getting stuck in memcached or something [15:00:21] wrong [15:00:27] *werdna wonders if anybody wants to play with LiquidThreads [15:00:35] maybe i was already timed out [15:00:39] me! [15:01:01] when can we stage LT on the usability sandbox/prototype? [15:01:37] once code updates are done [15:01:38] Right now, as far as I'm concerned [15:01:44] prototype, whenever you like [15:02:11] so prototypes are heavily tested right now [15:02:22] werdna: No outstanding issues or anything? No config weirdnesses apart from require_once? [15:02:24] so please coordinate when you guys update the version [15:02:34] You mean Calcey? [15:02:41] LQT shouldn't affect what they see [15:02:41] nkomura are you going to blog about it ? [15:02:56] I am happy to do that when you do not :) [15:03:08] RoanKattouw: it shouldn't but other changes may go in with the updates [15:03:33] werdna: we have a spare environment if you want to stage it here [15:03:34] http://usability.wikimedia.org/wiki/Sandbox [15:03:35] RoanKattouw: apart from what? [15:03:52] hi GerardM- [15:03:53] werdna: Do I have to do anything to install it apart from require_once'ing? [15:04:04] source the sql file [15:04:14] No update.php ? [15:04:16] i probably won't get to blog about LT, pls go ahead [15:04:20] Wasn't that fixed this weekend? [15:04:35] i'm supposed be on vacation, still wrapping up stuff [15:04:42] OK should be pretty straightforward [15:04:48] I'll install LQT on sandbox 3 in a minute [15:04:50] i'm sure werdna will blog about it ;) [15:05:09] RoanKattouw: well you can do update.php if you want [15:05:16] whatever works [15:05:48] werdna: Do you have any idea why we have seemingly redundant tabindexes on the edit form? [15:06:07] RoanKattouw: with LiquidThreads? [15:06:11] No, in EditPage.php [15:06:27] I failed to track it down, hit a dead end at r1284 (April 2003) [15:06:47] *werdna shrugs [15:07:16] It's messing up stuff, so I'm gonna experiment with either removing it or numbering them properly [15:07:45] We're numbering 3,4,5,... for checkboxes, but we're using 1 like three times (which is legal), and not using 2 AFAICT (also legal) [15:08:00] But they're not out of order anywhere so I'm pretty sure I can safely remove them [15:12:00] nkomura: where are you vacationing to? [15:12:12] nkomura, werdna: http://prototype.wikimedia.org/sandbox.3/Talk:Main_Page [15:12:12] to Japan [15:12:16] will leave tomorrow [15:12:33] I'll do a general post about LiquidThreads in the next few hours [15:12:37] nkomura: awesome, have fun! [15:12:38] RoanKattouw: woo i like it [15:13:47] Nice ... [15:13:59] Werdna .. so you are going to blog about it ? [15:14:07] GerardM-: indeed I shall [15:14:10] If so, I will another angle to the news [15:14:28] GREAT news ... congratulations by the way [15:14:36] :) [15:14:59] it'll be tested more widely once we get a code update [15:15:29] search doesn't work :( [15:16:49] created a discussion was so easy [15:17:02] i have trouble logging into the sandbox right now [15:17:21] so will try some more later to add replies and play with quotes [15:17:23] you guys don't have the fun lucene setup [15:17:26] You may not have an account yet [15:17:30] We don't have SUL there :P [15:17:47] i thought i had an account there [15:18:12] nkomura: At sandbox 1 maybe, but not at sandbox 3; they're different wikis, although they should arguably be using the same DB, lemme look into that [15:18:13] captcha makes it almost impossible to add anything without log-in ;) [15:18:20] ah [15:18:25] that's right [15:18:34] No, they /are/ using the same DB [15:18:56] so should work [15:19:08] i had trouble logging in before after we deployed ajax log in [15:19:08] https://bugzilla.wikimedia.org/show_bug.cgi?id=20642 [15:19:15] pesky vector skin ;) [15:19:19] so it is time for me to figure it wout [15:19:25] ooh, jax login? [15:19:28] heh [15:19:30] Aye [15:19:55] Extension from Wikia that works nicely, but needs a bit of attention to become WMF-worthy [15:20:46] looks pretty [15:20:47] werdna: you may want to add a screenshot to the bug case [15:21:12] yeah, good point [15:21:22] I'm used to filing bugs against my own stuff as a reminder/todo list [15:54:03] how are you mdale? [15:54:16] doing oky ... how about you ? [15:54:36] fiercely wrapping up work so that i can start my vacation [15:54:49] but still struggling [15:54:58] but i have a flight to catch tomorrow morning [15:55:10] yea ... seems there never a good time for vacation in this line work ;) [15:55:25] tell me about it ;) [15:55:37] i love the work you deployed on the sandbox [15:56:04] would you port it over to prototypes? [15:56:55] http://usability.wikimedia.org/wiki/Prototype [15:57:04] this is where we are doing active testing right now [15:57:27] oky... [15:58:06] and one more thing, if you can add high-level expected behavior here [15:58:07] http://usability.wikimedia.org/wiki/Releases/Babaco/Compatibility_Matrix [15:58:08] I need Trevor to add a 'toolbar-is-ready' hook of some sort.. cuz right now I am just putting in an arbitrary delay [15:58:21] oh [15:58:35] so the api is not ready yet? [15:58:58] (or I could add something in ... and Trevor could update it later... ) [16:00:01] as far as I can tell.. (no) .. cuz you can start trying to do api calls before the toolbar is "ready" since its built out asynchronously... or I think that was the problem I was running into anyway... its detailed in an email sent out last week. [16:00:43] ok [16:01:23] can you still add add-media-wizard without supported api? [16:01:59] i think it is worth getting some QA resource on it, if you are ok with proceeding without working api [16:02:32] yes ... we should go ahead with testing other things... (its oky that its slightly hackish in the background right now) [16:06:49] please update the prototypes then [16:06:59] i'm adding you to the test plan document [16:07:08] if you can log your update, that'll be great [16:07:31] QA folks are actively on it, so i want to communicate software updates explicitly [16:10:30] mdale: I can add that toolbarready hook, I suspect Melissa's had her baby by now (has she?) [16:11:10] sure if you want to plop it in there I will use it ;) [16:11:21] where you cc'ed on that email? [16:11:28] Which one? [16:11:39] that mentioned the lack of toolbarready hook [16:11:47] nkomura: Shouldn't Adam and Ryan be included in the usability and usabilityteam aliases [16:12:03] mdale: I vaguely recall one, lemme look it up [16:12:25] yes they are requested already [16:12:26] if so you could reply "Toolbar stuff / general js notes / Deployment issues" [16:12:51] hopefully they will be on the list by eod today [16:12:57] mdale: Yup found it [16:14:04] so yea.. lets add that in reply to that thread with-whatever you call the readyCallback item... there is some bigger refactoring efforts that need to take place.. but that will get is going [16:14:33] a onready callback will be "good enough for now" ... is what I mean to say [16:15:24] TrevorParscal: lots of exciting stuff happening this morning [16:15:41] LT staged on sandbox3 [16:15:57] yipee!~ [16:16:09] we are porting mdale's add-media-wizard to prototypes from sandbox [16:17:14] good morning brion [16:17:24] mornin all [16:17:40] did you have good weekend? [16:17:54] mdale: You wanted to selectively modify a toolbar button right? [16:18:00] hung around, did some reorg in the house. pleasant and relaxing :) [16:18:13] I can do the onready hook but I'll leave the selective modification to Trevor [16:18:27] Hey TrevorParscal can we congratulate you yet? [16:18:43] not yet [16:18:56] RoanKattouw: yeah, the onready thing is a bit of a hack still [16:19:34] Damn that baby is taking its sweet time [16:19:42] cause the api use upon intialization may or may not be what causes the image button that michael wants to replace to exist [16:19:46] RoanKattouw: seriously [16:19:54] Ah yes of course [16:20:17] There's an even hackier solution to that [16:20:25] Live events [16:20:28] RoanKattouw: but, i think a ready event for the toolbar would be ok [16:20:34] hmm [16:20:36] RoanKattouw: yea... right now... I am just running .unbind() [16:20:42] live events are not that fun I think... [16:20:56] looks like your new kid is going to be a hell of a procrastinator TrevorParscal ;) [16:21:01] $j('#someIDthatdoesntexistyet').click( ... ); but that might not get called in time [16:21:03] hehe ;) [16:21:16] Ah .live( 'click', ... ); of course [16:22:12] right but why not just organize things so that .live is never needed ... cuz what happens if you have your .live event and then another button want to extend you but does not have an api to know if "you" exist .. or well I just see lots of potential issues with using .live [16:22:43] Ah yes [16:22:54] In that case you would have to change the ID of the button xD [16:23:16] plus it seems like it would be slow .. to search all dom manipulations for a large set of "live" hooks. [16:24:54] TrevorParscal: What's the deal with the empty modifyTool() function in the toolbar API? [16:24:55] i'm in favor of wikiEditor( 'ready', function() { ... } ) [16:25:10] RoanKattouw: not yet implemented [16:25:13] sorry [16:25:23] OK but it'll fulfill Michael's needs, right? [16:26:09] TrevorParscal: is $.wikiEditor.ready(function() {} ); OK too? [16:26:30] Else I'd be overloading a parameter that's not overloaded yet [16:26:43] well, ideally the button would have a fallback (inserts text like it does now) and after michaels stuff loads (if it's turned on and loads OK and such) it gets modified so the action changes [16:27:18] $.wikiEditor.ready() would refer to all wikiEditor instances on a page [16:27:21] could be more than 1 [16:27:44] it will fufill the basic need of know the toolbar is ready for manipulation... (should be targeted to a specific instance) [16:28:01] Doh of course [16:28:20] ... right now I am doing that manipulation via $j('rel=file') type selector instead of via an api call but that can wait for later [16:28:21] we could do $( '#wpTextbox1' ).ready() and trigger it from the wikiEditor code [16:28:23] Why don't I just trigger the wikiEditorReady event on the textbox? [16:28:30] Yeah exactly [16:28:39] that would be sensible [16:28:58] mmm... but if toolbar is not "on" then the callback never gets fired. [16:29:09] would make more sense to have it be part of the wikiEditor api [16:29:45] mdale, what does that do to other things that are rel=file ? or are you more specific than that? [16:29:59] more specific [16:30:36] mdale: why would that callback need to be fired if the toolbar is not on? [16:31:07] Hmmm... [16:31:20] There's not an intuitive moment that you can say the toolbar is "ready" [16:31:21] (nope... if there is no wikiEditor available then I just addTheButton myself.... ) [16:31:33] Because EditToolbar and NTOC both do an addModule call [16:32:04] RoanKattouw: this is sort of why I say it's a bit of a hack [16:32:08] Aye [16:32:31] I *could* call the ready event on each toolbar widget after it's been added [16:32:38] Then you could catch that with a live event [16:32:42] Oh wait [16:32:46] but people need to be able to setup other parts, so we need something [16:32:54] Live events don't work for custom events IIRC dammit [16:33:16] why don't we make api calls queue [16:33:20] in order of being called [16:33:24] it should be re-factored :) you have to have a slightly more direct single point of entry [16:33:37] so even if they happen async, they are always executed in order of being called [16:33:49] mdale, what do you suggest? [16:33:50] Hm [16:33:53] I have a better idea [16:34:10] I'm gonna call an event on the textbox every time the toolbar is manipulated [16:34:25] so you call $j('#textbox').wikiEditor( { config: include module X, include module Y, etc } ) [16:34:26] And pass some kind of data along with the event indicating what's been manipulated [16:34:39] mdale: Yeah but that doesn't work ... modularly :P [16:34:45] right... but you can do something like [16:35:14] $j.extend( wgToolbarConfig, {include module X}) in moduleX.js [16:35:32] Yeah that's more or less exactly what we moved away from [16:35:43] A config global [16:35:49] mdale: and how is that more strightforward? [16:35:50] Because that depends on calling order [16:36:03] RoanKattouw: so you are saying, a change event [16:36:11] Aye, 'toolbarChange' or something [16:36:19] 'wikiEditorChange' I guess [16:36:19] no.. you have a clean seperation... any config happens priror to $j(document).ready() [16:36:38] mdale: Unless site config wants to modify the config, in which case they're screwed [16:36:48] $j( '#wpTextbox' ).wikiEditor( 'change', function() { ... } ); [16:36:51] Because site JS gets called *before* our JS [16:36:56] nope.. that is also included before document.ready [16:37:20] mdale: Yes, but at that time our config global doesn't even exist yet [16:37:30] We've been there [16:37:47] TrevorParscal: Why not just use jQuery events like $j('#wpTextbox1').bind( 'wikiEditorChange', ... ); [16:37:51] thats fine ...you do if( ! wgToolBarConfig) wgToolBarConfig = {}; [16:37:53] jQuery UI does that as well [16:38:02] and in your core defaults you don't override [16:38:34] RoanKattouw: i like that [16:38:49] very much [16:38:50] What, mdale 's suggestion or mine? [16:38:56] you [16:39:52] then you can just do in your bind, does this exist, if so remove it, add mine, never do do it again [16:40:22] not the clean way still [16:40:23] hmm [16:40:29] hld - dealing with craop [16:41:06] missed the recycling truck [16:41:07] grrr [16:41:08] anyways [16:41:23] the change event thing is a good way to hook into the timing [16:41:39] but the logic needed inside such a callback is still not clean [16:42:55] suggestions? [16:44:29] hmm... [16:44:31] sorry $j( '#wikipedia_usability' ).suggestions(); [16:44:34] :) [16:45:02] TrevorParscal: I'll pass the data passed to AddToToolbar to the event handler [16:45:04] I think without a global config / entry point things get complicated... [16:45:31] or maybe a way to look at the api... is injecting configuration... [16:45:49] the dom is the config [16:46:09] but still you need some point at which you say configuration and setup is done... now do hooks [16:46:26] which can be done, upon intialization [16:46:38] the toolbar and dialog configs are done on intialization [16:46:46] There's no need to enforce the core first, then hooks order in most cases [16:46:49] Except in yours :P [16:47:31] RoanKattouw: i agree, that dividing up the "core" config and hooks is lame [16:48:14] each module should have it's own ready event [16:48:35] wikiEditor-toolbar-ready wikiEditor-toc-ready [16:48:38] etc [16:49:01] ... I am sort of facing a similar problem with the add-media-wizard config...but solving it differently... extending a global config prior to $j(document).ready... then when document.ready happens ... i know I have whatever state any included script wanted the config to be in. [16:49:12] so no matter when the toolbar config was given, the event is triggered once it's setup and ready to accept further calls [16:49:20] just like the dom has a ready [16:49:38] TrevorParscal: that sounds like it would work too [16:50:38] can we just do $( '#wpTextbox' ).bind( 'wikiEditor-toolbar-ready', function() { ... } ); [16:51:28] TrevorParscal: Not quite that, but I'm working on something [16:52:00] Basically an event will be triggered at every API call, and you can examine the data passed to the call to see whether the widget you're interested in just got added [16:52:31] mdale: how does that sound? [16:52:36] RoanKattouw: I fear that's allot of logic to sift through the data... [16:52:47] for the callback writer [16:53:29] May not be too much trouble, I'd have to see how it works out [16:53:40] RoanKattouw: but I do like that it provides API data which should not change, rather than leaving them to hack our implementation [16:53:52] RoanKattouw: try that out, it seems flexible [16:53:57] hmm... say a given wiki wants to exclude a button or module... that will be handled in LocalSettings.php instead of the sitejs? [16:54:08] No, site JS [16:54:17] yeah, site js [16:54:27] we need to be moving towards that direction [16:54:40] imo [16:54:44] but how if editToolbar had the config hard-coded into the setup? [16:54:54] you would add it then remove it? [16:55:06] hmm [16:55:14] how else? [16:55:20] have a global config ;) [16:55:26] you think the js file should have PHP logic in it? [16:55:26] ok folks, i am going offline [16:55:28] that sounds scary [16:55:36] no no... [16:55:38] siteJS [16:55:39] nkomura: have a great day / trip tomorow too! [16:55:41] happy coding and testing [16:55:48] bye nkomura [16:55:50] nkomura: happy flying [16:55:51] thanks [16:55:59] mdale: There's a remove call in the API [16:55:59] bye [16:56:38] mdale: ok, so you are suggesting we have a global config, which gets modified on document ready, and then used sometime after that or something... ? [16:56:46] right .. but thats messy imho ... it will appear then disappear? ... you wait for the module onReady callback then remove the module? [16:57:03] you modify your config prior to document.ready [16:57:10] mdale: i can see your point of course [16:57:10] with $j.extend [16:57:27] how do you remove something with $j.extend ? [16:57:39] Damn this is serious JS voodoo http://dpaste.org/8b4F/ [16:58:02] $j.extend(globalConfig, { moduleName:{}}) ....? [16:58:09] or moduleName:null [16:58:30] mdale, i guess [16:58:30] for example .. in my add media wizard if a given wiki sitejs wants to include a seperate set of remote repositories they put in something like: [16:59:09] $j.extend( mwAMWconfg, { 'enabled_cps': ['wiki_commons','archive_org'] }); [16:59:17] then when the default configuration come around... [16:59:20] it does not override [17:00:39] and then when I build out the add-media-wizard (onClick) ... I know not to download all the code for and build out the fliker repository tab ... just to have it removed by an api call later on. [17:01:05] mdale: well that's a simple array of strings [17:01:31] yea configuration needs to be simple [17:01:31] we would end up requiring the user to recreate the majority of our config [17:01:34] not represent functionality [17:01:46] so, there's another issue there - which I can get behind [17:02:09] right config needs to be separate from driving the application. [17:02:24] if that makes sense ;) [17:02:40] but, the thing is we are already making it as simple as we can to configure [17:02:48] it's just a complex piece of software [17:02:52] there's no getting around that [17:03:25] it's a toolbar, so every tool does something different, has a different tooltip (which needs to be internationalized) different icon, etc [17:03:39] user-config looks like this: http://pastebin.com/m4f396085 and application config looks like: http://pastebin.com/m534071b3 [17:03:41] so in your example you would be including a javascript file for every toolbar icon [17:03:45] which is way too many [17:04:16] ok [17:04:21] you just have keys that identify your defaults [17:04:35] in that example, you are hiding the implementation of the tool a little more [17:04:39] right [17:05:17] but then you just end up with a config that's essentially the same exact thing just less info in it, now it's just lists of strings which are some sort of id of the tool to use there... [17:05:20] there are at least two types of config... stuff that admins will be doing and stuff that application developers will be doing [17:05:39] and the problem there is when you want to invent a tool, not just use a different arrangment of existing tools [17:05:46] you end up with a totally new intereface [17:05:54] so now you are doing 2 things instead of 1... [17:06:15] adding the "provider" and then adding an instance of the provider [17:06:33] ... there is no reason why you can't have a "custom_tool" item key in your config... that gets mapped out to more complexity... just the general case if you define these defaults .. we want to have these defined defaults accessible by a key [17:06:36] which is possible to do and all, but how does that actually solve our problem? [17:07:07] so people can flip the switches at whatever level they need to. [17:07:37] mdale: i actually did that btw with the dialogs for like half a day [17:07:44] big issue, internationalization! [17:08:07] what happens is the i18n comes from the extension we include to configure the toolbar [17:08:15]