[13:11:42] Hi folks [13:12:10] I have a doubt about a block issue [13:12:25] Could someone help me? [13:12:55] ... [13:13:44] Were you blocked on any wiki? [13:14:29] No, of course not [13:14:43] :) [13:14:50] State your question [13:15:32] We can't say whether we can answer it without knowing the question [13:16:06] I wonder if it is possible to implement blocks per namespaces [13:16:18] <^demon> No. [13:16:26] There's a current discussions about that on ptwiki [13:16:52] <^demon> Maybe with AbuseFilter? But certainly not with normal blocks. [13:17:18] Yep, we already use abusefilters on ptwiki to do that, sometimes [13:17:39] There's a policy regarding this [13:18:04] However, we'd like to implement that by using the block tool [13:18:07] Is it possible? [13:19:28] <^demon> No, it's not. [13:19:34] :( [13:20:17] Why not? is there any softwre [13:20:24] *software restriction? [13:20:40] <^demon> The software doesn't support per-namespace blocking as a feature. [13:20:50] <^demon> You're either blocked or not blocked. [13:21:25] I understand... [13:21:43] Is there no way to modify that? [13:21:59] perhaps instead of rewriting or expanding our block code we could have something like user tags and use abuse filter to make very fine grained blocks [13:22:00] depends [13:22:13] <^demon> Well, someone would have to write the code to do so. [13:22:28] depends on how good you are at writing PHP code [13:23:03] We have a current discussion on ptwiki with strong support to do that [13:23:10] on that wiki [13:23:46] <^demon> Discussions are great. They don't write software, however. [13:23:54] we have a discussion with strong support for ending the conflict in Israel [13:24:03] xD [13:24:20] sorry, late here, I start to think I'm funny when I'm tired [13:25:03] I mean... if is not possible, I'm gonna say that to all users there [13:25:50] <^demon> I put "rewrite blocking code" up for GSoC this year. Nobody will do it though. It's not very cool, exciting or Semantic. [13:26:15] call it "rewrite blocking code to be more semantic" [13:26:25] specify blocks in RDF triple form [13:26:32] <^demon> SemanticBlocks? [13:26:36] yeah [13:32:18] Demon, so you mean that is possible to implement per-namespace blocking, but nobody will do it because it's hard to do? [13:32:55] <^demon> It's not hard necessarily. [13:33:03] <^demon> It just has to be done by *someone* [13:33:31] xD [13:33:37] *Dispenser misread "ending the conflict" as "edit conflict" [13:33:41] <^demon> We haven't made MediaWiki self-aware yet, so we still need programmers to add new features :) [13:34:54] Ok... If we get a clear consensus regarding this, do you think it could be implemented by someone, someday? [13:35:30] <^demon> Someone, someday? Sure. [13:35:40] xD [13:35:43] k [13:35:45] *ok [13:35:54] <^demon> In a timely fashion? Probably not :( [13:36:16] That discussion may take more 2 weeks or 1 month, I guess [13:36:47] but this feature would be very useful on ptwiki and other wikis [13:36:57] Because we've used abusefilters a lot [13:37:27] and, you know, not everyone knows how to use it properly [13:42:26] What do you consider a "timely fashion"? [13:42:33] 3 months? [13:42:36] 6 months? [13:42:38] 1 year? [13:42:39] <^demon> A year [13:42:41] <^demon> Maybe two [13:42:51] don't make promises you can't keep [13:43:08] :( Ok [13:43:10] <^demon> I'm not promising anything, I'm just saying I don't think anyone would get to it for the next year [13:43:22] Bah, in two years, we'll have 50 engineers and MediaWiki 3.0-flying-cars! [13:43:29] With wysiwyg and all! [13:43:35] I understand what demon said [13:43:42] <^demon> Pfft, we have to hit 2.0 first ;-) [13:43:52] we need mediawiki developer saturation [13:43:59] that would be nice [13:44:00] <^demon> guillom: In two years we'll be looking at 1.25 or so :) [13:44:05] :D [13:44:21] presumably there comes a point where you have so many developers, that as soon as someone has a good idea about something to implement, someone instantly implements it [13:44:38] so ideas become the bottleneck instead of implementation [13:45:07] Talking about version numbers, ^demon , would you mind taking a look at a draft of mine, and telling me if you see anything shocking? http://www.mediawiki.org/wiki/Development_process_improvement/Versions_and_phases [13:45:15] Ok, thanks [13:45:20] that'll never happen, looks at the security audit log on the Toolserver [13:48:52] <^demon> guillom: Nothing new or shocking. Version numbers suck. Especially when trying to figure out core/extension compatibility (which I'm very interested in a long term solution on, if you have ideas) [13:49:31] ^demon, well, why do they suck, and what else could we use? Dates? [13:49:52] ResourceLoader 2011-02-07 ? [13:50:00] <^demon> No, numbered things like that are worse. [13:50:13] <^demon> I mean tracking different version numbers is annoying and (can be) confusing. [13:50:20] ok [13:50:24] <^demon> Especially since they're somewhat arbitrarily chosen by developers. [13:50:32] <^demon> (in extensions) [13:50:37] Right. [13:51:18] <^demon> Coming up with a consistent version numbering scheme for extensions would be nice and go a long way to start tracking these compatitibilities. [13:51:24] ^demon, has nobody else in FLOS solved the issue of version numbers wrt core/extension compat? [13:51:51] Wordpress have one solution [13:52:08] <^demon> Most of the code-repo type things (pear, cpan) do a good job. [13:52:52] Another reason for automagic extension installation [13:53:06] <^demon> I really need to get my ideas down somewhere solid. [13:53:12] <^demon> I've got lots of them in my head for this. [13:53:21] Solid as in physical? :P [13:53:28] My main problem at the moment is the *lack* of version numbers for many projects currently under development. [13:53:48] <^demon> Reedy: Solid as in somewhere other than in my neurons, since you can't intercept and read those. [13:53:54] (yet) [13:54:25] Muahaha [13:54:40] guillom, one step would to be introduce arbitary numbers to projects missing them [13:55:09] Reedy, yeah, I'm trying to see if there'd be an outcry if I proposed that. [13:55:30] Rob says devs would be likely to oppose, so I'm trying to figure out why. [13:55:35] :S [13:55:43] People are starting to do it [13:56:12] <^demon> You need *something* to track versions. [13:57:10] <^demon> "rewrite" and "v2" and "redesigned" are not versions, either. [13:57:14] Another question is: should we assign version numbers to core features? e.g. ResourceLoader. [13:57:23] <^demon> Not necessary, IMO. [13:57:35] <^demon> Well, some things get version numbers [13:57:36] Nah, not unless it's publishing specific API's [13:57:40] ok [13:57:42] <^demon> Right, like that [13:57:44] I think some of the File/Foreign File repo stuff [13:57:49] <^demon> That. [13:57:50] have something along those line [13:57:51] <^demon> And parser version [13:57:54] Which sorta makes sense [13:58:00] So, ResourceLoader will only be updated when we update MediaWiki? [13:58:05] Yeah [13:58:09] ok [13:58:11] Updating it standalone could become a PITA [13:58:18] could/would [13:58:32] Fixes can get backported ofc though [13:58:39] <^demon> Updating part of MediaWiki without another part gets hairy quickly. [13:58:47] The core/extension compatibility thing should also account for cases where extensions are moved to or from core [13:59:04] It's rare, but there is more of that that needs to happen [13:59:21] <^demon> If something was split from core -> extension, it would make *most* sense to adopt the MediaWiki version it was split from. [13:59:24] <^demon> And number from that. [14:00:07] Is it safe to assume (especially with the new installer etc.) that in the future, most "bug" features will come as extensions? [14:00:14] big [14:00:17] not bug [14:00:19] heh [14:00:33] (talk about a slip of the tongue) [14:00:33] I don't quite follow [14:00:41] ok, rephrasing [14:01:01] though, we all know big is usually better [14:01:03] *Reedy coughs [14:01:31] Say someone develops a wonderful wysiwyg extension [14:01:40] but it's very large [14:02:03] should it stay an extension (proposed for installation by default) or should it be integrated into core? [14:02:11] Ah [14:02:22] <^demon> I think "extension, but you should always install it" is a bad idea. [14:02:37] The latter would probably be preferable (if made configurable), but isn't always easily doable [14:02:38] <^demon> It's why I've taken issue, since the beginning, of all the UX stuff being done in an extension. [14:02:51] <^demon> People want to download MediaWiki and they expect it to look and run like Wikipedia. [14:03:41] Mhmmm. [14:03:58] Something from this weekend, why don't wikia submit more of their changes etc upstream back to us? :) [14:03:59] <^demon> We've had countless people in #mediawiki ask why their vector doesn't look like Wikipedia [14:04:00] *:( [14:04:13] <^demon> Collapsable sidebar, missing the new editor, etc etc. [14:04:19] Yeah, there's still the vector extension ontop isn't there? [14:04:35] ok [14:06:15] So, in a nutshell: version numbers are a necessary evil to track versions, core features shouldn't generally need dedicated numbers, and there should be an extension numbering scheme that indicates the compatibility with core. [14:06:23] Did I get that right? [14:06:38] Sort of [14:06:52] For the extensions, for example, WordPress do a tracking thing [14:07:00] <^demon> Right, and we should too :) [14:07:03] <^demon> But not today [14:07:13] Where users/developers can say, for version X of core, versions Y and Z will work with it [14:07:16] But A and B won't [14:07:44] Is that something that would be easier to track automatically with the virtualization cluster? [14:07:56] Not really [14:08:00] ok [14:08:06] <^demon> It's something we need to track on MediaWiki.org [14:08:10] <^demon> With its own db tables. [14:08:11] ^ [14:08:18] ok [14:08:55] <^demon> Once that sort of thing is tracked, it should be trivial to say "I've got version 1.whatever of MediaWiki, which extensions can I install?" [14:08:57] It shouldn't be too hard to setup the infrastructure, but it's then getting the information [17:54:16] <^demon> robla: I'm wondering if we should go ahead and fire up an etherpad for today. I was thinking it might be useful for keeping a log of "last minute things that are being done / need doing" [17:54:23] <^demon> The main 1.17 doc is getting a bit large for this :) [17:54:44] *robla looks at the main 1-17 doc [17:57:43] <^demon> I want one :p [17:59:12] <^demon> http://eiximenis.wikimedia.org/1-17-lastminute [18:00:20] ^demon: rather than pointing people to yet another doc, let's archive off the bulk of the current 1-17 doc [18:00:29] <^demon> That can work too. [18:17:50] Who's dating resource loader ? [18:17:53] I hear she's going out tomorrow [18:17:53] https://bugzilla.wikimedia.org/show_bug.cgi?id=26338#c6 [18:18:00] :P [18:18:13] flipzagging: here? [18:18:22] Bryan: yes [18:18:24] in private function outputRemoteScaledThumb( $file, $params, $flags ) { [18:18:31] you use: [18:18:33] $scalerThumbName = $file->getParamThumbName( $file->name, $params ); [18:18:46] any reason why you did not use $file->thumbName() ? [18:19:09] just a minute [18:19:44] I'm puzzled by the comment "This is abstracted from getThumbName because we also use it to calculate the thumbname the file should have on remote image scalers" [18:19:50] there is no getThumbName() [18:21:48] the only difference appears that it uses the passed $urlName instead of $this->getName() [18:22:01] right [18:22:02] but then in outputRemoteScaledThumb() you pass $file->name [18:25:32] another point: [18:25:37] $thumbFile = new UnregisteredLocalFile( false, $this->stash->repo, $thumbnailImage->getPath(), false ); [18:25:39] if ( ! $thumbFile ) { [18:26:05] is there some magic PHP feature that can cause "new" to return something else than the requested object? [18:27:39] one thing at a time... [18:29:50] Bryan: you're right that the !$thumbfile check is wrong [18:30:14] the only possible return is the object, or, an exception will be thrown [18:30:44] possibly the !$thumbfile is from some older code that might have returned null, or it's just wrong-headed thinking [18:31:19] as for the original question, I'm trying to figure out what all the cases are. It's not obvious to me that this is doing the wrong thing or that there's any contradiction. [18:32:18] It seems to me just needless code duplication; I would have used $file->thumbName() instead of writing my own variant, but it might be that you have a use case that I'm overlooking [18:32:19] It seems that when I wrote this I deliberately made getParamThumbName so that it would work with outputRemoteScaledThumb [18:32:32] outputRemoteScaledThumb *is* doing something different [18:32:39] as you noted it uses file->name [18:32:51] now I can't actually remember why this is important... :) [18:33:18] oh, do [18:33:21] hehe [18:33:22] oh, duh :) [18:33:36] see getUrlName -- it's deliberately NOT related to the filename. [18:33:38] well, it should not block deployment, let me note that on the bug [18:33:42] *rev [18:34:06] for SpecialUploadStash there's this whole distinction between the name on the filesystem and the URL, which does not exist for public, ordinary files. [18:34:34] we keep the actual name secret so it isn't inadvertently "published" or otherwise used to make us look bad. [18:34:50] the user gets a URL which is only decodable if they are logged in. [18:34:53] Is that clearer? [18:35:29] as for the !$thumb thing you are right. [18:36:19] Bryan: anyway I have another meeting to prep for ASAP, can you send followups by email? otherwise thanks for going over this [18:36:53] I will leave comments at r77451 [18:37:19] shit, need to go soonish [18:47:36] I need to still review "public static function getExtensionForPath( $path )", but that'll have to wait until tomorrow I think [18:50:56] interesting, explode( ' ', null ) does not throw a warning [19:33:36] any DEV around , CU related question [20:53:09] TrevorParscal: So apparently the OSCON web site thinks I live at your address... :) [21:14:20] http://eiximenis.wikimedia.org/1-17 [21:19:39] http://www.mediawiki.org/wiki/User:Catrope/Extension_review [21:19:47] RoanKattouw: do you have a script for this? [21:20:06] Ah, probably [21:20:58] TimStarling: nightshade:/home/catrope/crstats/crstats [21:21:14] do you want to run it? [21:21:37] OK [21:21:48] Running; this will take a while [21:23:23] Oh awesome, my SIP client is stuck and won't unmute [21:26:19] robla, if you update your report again, that'll drop off a few more revs [21:26:41] *robla runs report [21:27:00] TimStarling: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/User:Catrope/Extension_review is updated now [21:27:05] The elephant in the room, of course, is ProofreadPage [21:27:22] http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/status/new&offset=77974&path=/trunk/extensions/AntiSpoof [21:27:27] Stupid path search bug [21:27:41] That' something we should deploy soon after ;) [21:28:26] Yeah [21:28:46] updated: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17/Revision_report [21:28:52] probably dumping rev numbers and linking would've been nicer ;P [21:31:32] when I click the link for ProofreadPage, I get 7 revisions, not 30 [21:31:51] TimStarling, it's the "hack" put in for the inefficient path search sql query [21:31:53] Old revision limit? [21:31:56] Yeah [21:32:12] It's like SVN Head - 30,000 [21:32:14] or 20k [21:32:16] It's fixed in trunk, though [21:32:19] There's a WHERE cr_id > (latestrev - 20k) in there for efficiency [21:33:42] anything more than about 20k revisions before the trunk will be before the 1.16 branch point [21:33:56] so we can probably assume it's pretty well tested already [21:34:21] of course there was an XSS in ProofreadPage before the 1.16 branch point that was discovered recently, so tested doesn't mean secure [21:36:52] Food.. [21:45:50] RoanKattouw: RE: missing db on toolserver bug, have you tried phpmyadmin ? [21:46:35] No [21:47:05] I just know that my scripts broke, and that echo "SHOW DATABASES;" | sql -u enwiki_p doesn't show my DB any more [21:48:12] other u_'s are still there when I log into sql-s1-user [21:48:59] I saw half a dozen I think [21:49:04] Do you see u_catrope ? [21:49:18] Nope [21:49:24] Nowhere, not on s2, s3 either [21:49:45] I do see bryan's and multichils. [21:49:56] seems personal :P [21:50:51] although could be related to http://lists.wikimedia.org/pipermail/toolserver-l/2011-February/003893.html werid that it's only for some datatbases [21:51:12] I only have one on s1 [21:51:25] k [21:58:59] down to 38 revs: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17/Revision_report [21:59:23] Yay [22:00:37] oh heya Bryan: you were asking about "nodeploy". yes, you're right that don't affect deployment can be marked [22:00:56] the visual stuff we should probably still review, though. should be an easy review [22:01:20] things like installer revisions can be marked as "nodeploy" though [22:03:47] Ok [22:04:41] Going to bed now though so see you in about ten hours [22:07:02] I haven't done the category collation patch yet [22:07:13] that's going to be a lot of work [22:08:09] Oh rigth [22:08:21] I totally forgot about that [22:08:30] That definitely needs to get done [22:08:32] mmm http://prototype.wikimedia.org/ does not look good [22:09:12] mdale: Blame pdhanda [22:09:38] TrevorParscal: So ArticleFeedback. What do you need to know? [22:09:43] mdale: i am in the process to switching to the wmf1.17 branch [22:09:50] he's not around, roan. [22:09:51] 30 seconds [22:10:16] pdhanda: no worries ... just wanted to test some gadget stuff ... let me know when its up :) [22:11:18] sigh, ok switch complete, it really is broken :/ [22:11:33] looking [22:11:42] doh [22:11:51] 1.17wmf1 has a different layout than REL1_17 [22:16:47] pdhanda: on log in "This version of Extension:Gadgets requires MediaWiki 1.17+ " ? [22:17:24] mdale: try now [22:18:09] better :) [22:20:00] cool. let me know if you see any more issues [22:23:38] RoanKattouw: howdy [22:23:44] I'm back from my adventrue [22:24:02] So, ArticleFeedback. Alolita said you needed to sync up with me? [22:24:20] well, we want to try it out on prototype [22:24:35] I know [22:24:45] we need to ensure the old version works right, and also want to verify the new version will work as well [22:24:52] I talked to you on Thursday and asked you to deploy it so I wouldn't have to [22:25:25] yeah - I saw that, but I chickened out because I haven't played with the prototype servers in a while [22:25:28] and everything is different [22:25:36] and pdhanda wasn't nearby atm [22:25:43] i'm looking at the ArticleAssessment page now [22:25:52] right [22:25:56] i mean http://www.mediawiki.org/wiki/Extension:ArticleAssessment [22:25:58] so, now is a good time to make magic happen then [22:26:16] so, we need to verify that extension is going to work OK with 1.17 [22:26:36] because we are planning on holding off 1 week before we replace it with ArticleFeedback [22:28:00] I know why we're doing this [22:28:08] TrevorParscal: http://prototype.wikimedia.org/release-en [22:28:09] I'm just wondering whether you need my help with it at all [22:28:18] sorry [22:28:22] was catching up pdhanda too [22:29:06] Oh OK [22:29:24] *RoanKattouw might be a bit cranky, just got home from the train trip from hell [22:30:02] TrevorParscal: it should be set to this 'enwiki' => array( 'Article_Feedback_Pilot', 'Article_Feedback', 'Article_Feedback_Additional_Articles' ) [22:30:54] RoanKattouw: why are you still awake? [22:30:58] ha ha [22:31:12] Because there is code to be merged [22:31:18] If it were up to me I'd have gone to sleep at like 8 [22:31:24] But I was still trying to get home at that time [22:32:20] Alright for those that can sleep :P [22:36:08] I am bummed fix to bug 27023 is not making it in... will result in some ugly hacks [22:36:57] See if you can get Trevor to fix it before tonight, preferably in a simpler way than your patch [22:37:09] It renamed and moved stuff, and at this point we really want minimal fixes [22:37:12] my patch does not fix it [22:37:24] Then why is it attached to the bug? [22:37:32] well its a start of a fix ;) [22:37:49] but was going to sit with TrevorParscal to finish it up [22:37:55] You could've made that clearer then :P the comment even says "patch attached" [22:38:13] Oh, "in preparation .... " [22:38:48] yea, I agree the last line is confusing [22:40:47] for flipzagging http://drdrestartedburningman.tumblr.com/ [22:41:23] I don't see how the patch could be made trivial.. maybe something with setting resource loader states to 'loading' instead of 'ready' .. and then a callback updating the state ... could be in the low end of a diff size .. but would have to talk to TrevorParscal about it. [22:41:53] RoanKattouw: this is where i had lunch http://tinyurl.com/6hah2jy [22:41:56] Yeah talk to Trevor [22:42:02] I can barely think right now, really need sleep [22:42:06] But SVN merges are sllloooowww [22:42:42] it should at least throw an error before you deploy.. otherwise you will get unexpected behavior for gadget developers using to load dependencies, where for one person it loads instantly because its cached and for the next person you get a symbol not defined. [22:43:24] mdale: I am going to have to go over your code and see what your are doing exactly [22:43:38] because I haven't been able to recreate what you are seeing [22:43:41] TrevorParscal: And you survived! [22:43:44] ha ha [22:43:51] my brother works over there - for Mythbusters [22:44:07] heh [22:44:09] A so that's why [22:44:12] and there's this random super-nice deli on a loading dock [22:44:21] I was gonna go "Any particular reason you had lunch all the way out in the Dogpatch?" [22:45:11] should be easy to recreate .. just run $(document).ready( function(){ mediawiki.loader.using( 'jquery.someModule', function(){ alert( 'Error module should be ready: ' + jquery.someModule ); }; [22:46:15] RoanKattouw: i took bart to 24th and mission, and biked the rest of the way [22:46:38] Right [22:48:23] robla, want to run it again? [22:48:35] sure [22:48:44] *robla figures out what "it" is [22:50:32] RoanKattouw: need some advice [22:50:58] ArticleAssessment is asking for UsabilityInitiative/js/js2stopgap/jui.combined.min.js - which is configurable [22:51:11] Reedy: "it" is done: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17/Revision_report [22:51:15] :P [22:51:21] but that file doesn't exist in 1.17 [22:51:30] That's the old hacked-together compat crap. ArticleFeedback doesn't need it because it uses RL [22:51:38] yeah [22:51:40] RoanKattouw: ArticleAssessment also has some configs that need to change require_once( "$IP/extensions/UsabilityInitiative/PrefSwitch/PrefSwitch.php" ); [22:51:53] Yes [22:51:57] should be pretty obvious if you search for UsabilityInitiative [22:51:58] basically we have to patch AA [22:52:05] ....no? [22:52:08] Just replace AA with AF? [22:52:19] um [22:52:22] Or are you talking about the upcoming deployment? [22:54:19] yeah [22:54:37] ok - so we need to run AF on prototype for a while before everyone is comfortable launching it [22:54:40] so in the meantime [22:55:33] we need to patch AA [22:55:36] TrevorParscal: The UsabilityInitiative files are not gonna disappear off the cluster, it'll be fine [22:55:51] so, I don't think patching in wmf branches is OK [22:55:56] but where should I patch this? [22:56:02] it's not in trunk [22:56:13] there is a tag somewhere that we used [22:56:22] I could bring it back to trunk [22:56:23] patch it [22:56:35] and then you can merge it - if that sounds sane... [22:57:02] Patching the WMF branch is fine [22:57:05] But don't worry about it now [22:57:06] ok [22:57:09] will do that then [22:57:12] In fact, please don't try to fix it in the next 24h [22:57:27] It'll be fine for deployment, we'll worry about doing it properly later, if at all [22:57:55] ok - so to make it fine, you just leave the usabilityinitiative ext there? [22:57:59] then we sort it out later? [22:58:02] that's right yes? [22:58:16] It'll automatically be left behind [22:58:17] Yes [22:58:20] ok [22:58:21] sounds solid [22:58:25] OK, sleep [23:00:57] TrevorParscal: i brought UsabilityInitiative back on prototype [23:03:11] robla: https://bugzilla.wikimedia.org/show_bug.cgi?id=27090 not a show stopper right? [23:03:21] pdhanda: don't set $wgArticleAssessmentJUIJSPath or $wgArticleAssessmentJUICSSPath [23:03:23] *robla looks [23:04:34] pdhanda: is 27090 correctly marked as a duplicate of https://bugzilla.wikimedia.org/show_bug.cgi?id=27021 , or is it a subtle variation? [23:04:39] TrevorParscal: done [23:05:50] it appears as though Bryan fixed 27021, and it was merged in [23:06:18] robla... i can verify quickly [23:09:06] robla: doh.. yes i verified 27090 [23:09:14] flipzagging: ^ [23:09:28] verified fixed? [23:10:43] yes it is fixed [23:11:01] hexmode: now that Roan is officially offline, we should reallocate the revs that are still assigned to him [23:11:25] pdhanda: thanks! hooray for moot questions :) [23:17:37] pdhanda: looks like SyntaxHighlight is broken on "release-en" :: http://prototype.wikimedia.org/release-en/User:Mdale/vector.css [23:19:35] ah the external geshi [23:19:41] let me go grab it [23:25:28] yeah certificate thingy. Had that too last night when I checked out 1.17wmf1 for the the wikimedia-svn-search. [23:28:34] mdale: try now [23:29:12] gracias :) [23:31:01] TrevorParscal: you linked to a vector-extension js bug earlier and I saw a commit related. Was that the same bug or should I look it up now ? [23:31:29] I sorted it [23:31:35] it was a silly mistake [23:31:39] k [23:31:41] thanks for following up though [23:31:45] np [23:32:22] I finished $.jsMessage by the way. Ofcourse not important for 1.17wmf1 but if you see time somewhere (like 15 minutes) check it out on a trunk install or translatewiki. [23:32:52] A plugin that basically solves most of the usecases that I found accross wikimedia and non-wikimedia sites. [23:33:01] regarding jsMsg() hacks [23:33:10] queue, groups, clearing [23:33:21] Krinkle: I would call jsMessage something slightly diffrent so its not confused with i8ln stuff [23:33:56] the legacy was called jsMsg(), the jQuery plugin is jQuery.fn.jsMessage() [23:34:19] Hm... which i8ln do you mean mdale ? [23:34:39] like a jquery plugin for getting localized message [23:35:20] flipzagging: should be committing something shortly.. we had it titled $.mwMessage originally .. but maybe it will be updated [23:35:24] mdale: Oh you mean a potential plugin ? [23:35:33] right [23:36:12] mdale: oh you are talking to me or about me? [23:36:19] yes, trying to commit, in meetings now :( [23:36:39] we'll call it mwMessage but I think in general the plugin should be invoked as .msg() [23:36:53] right a short hand would be better [23:37:29] Hm... what's that about ? [23:37:41] mediaWiki.msg() ? [23:37:43] for the messageBox support I think it should be called messageBox or userMessage ... jsMessage is too general [23:37:56] there are two things [23:38:09] one is getting a string from the localization system [23:38:15] which we have mediaWiki.msg for that [23:38:17] Yeah, I'll call it something more specific but not mw-specific either. [23:39:05] the other is getting a jQuery object .. like $('').append( $.msg( 'my-msg-key', function(){ /* click action for $1 */ } ) ) [23:39:15] so you can build out messages with bindings etc. [23:39:29] I am just saying that "jsMessage" maybe confused for that type of functionality ... [23:39:37] isn't that $.fn.localize() ? [23:39:49] and what jsMessage does is essentially put some text at the top of the page? [23:39:53] Yes [23:40:05] so it should be more appropriately titled. [23:40:19] its not a general javascript message thing .. its a user notification thing. [23:41:28] Well, the plugin can even be used for a refresh stream of rss content or something. It's really flexible. [23:41:32] like a twitter thing [23:42:04] ( right ... but "js" does not add meaning to its name ) [23:42:13] I agree, we're passed that :) [23:43:30] one defines a location on the page, a classname, and then one can add messages to it giving the message as a string and optionally a group (ie. 'mygadget'), and another argument is 'replace' (ie. replace earlier messages or add on top) [23:43:48]