[09:00:18] *RoanKattouw waves at flipzagging's nocturnal presence [09:00:55] *flipzagging cannot see him, it is too dark [09:10:38] hey Roan, I'm having some issues now with uwd branch [09:10:47] I think it has to do with the mw / mediaWiki change [09:11:01] Oh [09:11:03] Hm [09:11:09] What's going wrong exactly? [09:11:35] trevor changed one or two of my "mw.blah" to point to mediaWiki.blah [09:12:03] via the ( function(mw) { ... } )( window.mediaWIki ) [09:12:23] I didn't notice any errors on my own machine, which is core trunk and extension trunk. [09:12:32] I tried it on uwd branch and got errors. [09:12:41] so I fixed everything to point to mediaWiki [09:12:45] and now... nothing happens [09:13:02] not sure what's wrong [09:13:09] http://commons.prototype.wikimedia.org/uwd/Special:UploadWizard [09:14:28] mw.Language is undefined [09:14:39] Aha [09:14:45] mw and mediaWiki are different objects [09:15:01] where [09:16:16] On that page [09:16:31] Go to Firebug console, type mw, then type mediaWiki, see that their different. mw == mediaWiki returns false [09:16:44] Which is strange, mw is supposed to be set to point to mediaWiki somewhere [09:16:57] Or maybe you should just s/mw/mediaWiki/ throughout [09:17:02] I did the latter [09:17:14] and I always wrap calls in those function bodies [09:17:17] ... [09:17:25] You must've missed /something/ [09:17:40] well, it's obviously something like that, I'll just hack it so they are the same anyway [09:17:42] Because mw exists and has lots of members [09:17:48] need to show this to others [09:18:33] dammit, no effect [09:19:18] argh. [09:19:50] nm fixed it [17:22:43] I'm currently sat in a second year lecture.. [17:55:56] 2nd year? I thought you were a 4th-year? [17:56:27] I am [17:56:34] We were trying to wind up the lecturer [17:56:41] but he's not noticed we're not supposed to be here [17:56:47] Even though he knows us [17:57:27] haha [17:57:52] I passed my databases lecturer in a hallway yesterday after not seeing him for a year [17:58:00] He taught us all that ORM modeling crap [17:58:34] His lectures were in English (international students present) with a Texan accent, which is strange because he's just a Dutch guy AFAICT [17:58:59] haha [17:59:16] Well that was a waste of my time [17:59:21] Home time, see you in an hour [18:00:18] Heya flipzagging [18:00:33] hey [18:00:33] I'm almost finished doing a quick JS security review of UW, one file to go [18:00:41] (mw.UploadWizard.js , which is a few thousand lines) [18:00:57] any q's? [18:01:05] One quick thing [18:01:12] "Next" button above the licensing tutorial [18:01:33] yeah, it's a desired feature [18:01:49] limiting myself to necessary stuff right now [18:02:38] that's seriously your only question [18:02:41] ? [18:02:52] Well I have remarks, for sure [18:03:00] It'll be in an e-mail once I'm done [18:03:33] Only security-related issue I found is widespread (in fact, near-ubiquitous) usage of i18n message contents as HTML [18:05:03] you mean concatenated right into html [18:07:08] Yes [18:07:11] Without escaping [18:07:15] Grr, he left [18:23:21] hi RoanKattouw [18:23:32] Hi [18:23:36] how's life? [18:23:52] Life [18:23:53] 's good [18:24:14] Dealing with insurance paperwork but otherwise just fine :) [18:24:47] They're scrapping free dental for 18-21yos starting in 2011, so I have to get dental insurance [18:25:24] bah! [18:25:45] It's OK, I got the 2-star variant (out of 4) and it's like $10 a month [18:26:11] I see... [18:26:22] so, do they get your teeth less clean or something? [18:26:40] haha [18:26:47] Nah, less coverage [18:33:51] TrevorParscal, do you know where does this url come from? http://wiki.wikimedia-es.org/w/skins/cc.41356ec1004d2d5cfebbfe7d61c384a5.wmes,_header,s?301Y+wmes,_style,s?301Y+common,_oldshared,s?301Y+wmes,_footer,s?301Y.css [18:34:29] That's seriously messed u [18:34:31] p [18:34:43] where did that come from? [18:34:46] WTF? [18:35:17] the fact is, the content is there [18:35:35] with no apache rules for that [18:36:00] it's nothing I've ever messed with [18:36:06] it's some url encoding scheme though [18:36:13] for loading multiple files [18:36:48] Aha [18:36:52] yes, they were skins/wmes/header.css?301Y, skins/wmes/style.css?301Y and so on [18:37:18] Are you using that thing that you (was it you?) suggested on wikitech-l for automatically combining CSS/JS and stuff? [18:37:56] ? [18:37:58] not me [18:37:59] that skin is not even using a resoure loader module [18:38:34] they are plain calls to $out->addStyle() [18:38:53] Wait what [18:38:56] seems crazy [18:39:04] They're using a resource loader module that in turn calls $out->addStyle() ?!? [18:39:38] that's really dumb [18:39:53] It would be, if that's true [18:39:58] speaking of RL, we need to sort out this $wgResourceModules thing [18:40:03] Yes [18:40:16] Some time when I'm not reviewing UW code and expected for a meeting in 15 mins :) [18:40:56] if Tim is going to put his foot down on this, I can live with myself, but we should at least update the documentation accordingly - however I think this is a case of premature-optimization and should be looked at with great scrutiny before it's accepted [18:42:05] I suggest you fight this out with Tim, his timezone works better with yours than it does with mine [18:42:16] At least in winter when they have DST and we don't [18:46:11] TrevorParscal: in url(filename) , what needs to be escaped? ) at least, ' and " for paranoia (filename could start with a quote and have quote halfway); anything else? [18:46:47] *TrevorParscal looks at RFC [18:48:14] so, the quotes must match, but they are also optional [18:48:26] and should be escaped using normal escaping rules [18:48:27] and that's it [18:48:35] http://www.w3.org/TR/CSS21/syndata.html#uri [18:48:57] there's a tad more to it, but that's basically the deal [18:49:30] "Some characters appearing in an unquoted URI, such as parentheses, commas, white space characters, single quotes (') and double quotes ("), must be escaped with a backslash so that the resulting URI value is a URI token: '$', '$', '\,'. " [18:50:28] Yeah [18:50:35] Instead of using \ it's better to just urlencode them [18:54:15] yes [18:55:51] *vvv suddenly discovered that he had 500 monobook.js across all Wikimedia projects [18:56:04] Which now, of course, have to be renamed to vector.js [18:57:03] Did anyone ever suggest creating something like common.js? [18:57:53] no no no [18:57:56] do not just rename them [18:58:02] Monobook still needs them [18:58:12] and they probably won't work the way you expect on vector [18:58:26] you will need to write a new set of vector-specific customizations [18:58:33] TrevorParscal: for 500 wikis? [18:58:47] They all transclude my JS file on meta [18:58:55] I suggest you follow your instincts and generalize them [18:59:01] put them into common.js instead [18:59:14] hmm [18:59:15] TrevorParscal: does mediawiki support common.js? [18:59:20] yes [18:59:52] Yes, trunk supports User:Foo/common.js [19:00:17] Wikibits should already wrap the differences of things like addPortletLink, but if you are doing more.. creative things, you will need to make sure they work in vector carefully [19:00:26] the dom structure is different [19:00:35] many of the styling techniques are different [19:00:43] It's 11am, meeting? [19:00:45] and things like search are in entirely different places [19:00:49] *TrevorParscal heads to meeting [19:00:54] RoanKattouw, apparently [19:00:59] RoanKattouw: and wmf-deployment? [19:01:04] Hmm, which is worse, CPanel or IIS... [19:01:09] vvv: Doesn't support commons.js [19:01:13] *common [19:01:14] Oh [19:01:16] *pain* [19:01:18] Reedy: IIS [19:01:28] CPanel is fairly dreadful [19:02:49] *RoanKattouw lols @ Sam's Kopfschmerzen [19:03:02] I'm probably the only person on the team that understands that [19:03:06] Es ist sehr lustig [19:03:19] 2003? [19:03:59] Yeah [19:04:57] I understood "Kopf" and guessed the rest. [19:05:44] Although I hesitated between "headache" and "hangover". [19:06:27] guillom, I'm many weeks sober [19:06:29] :P [19:06:36] Is that an achievement? :) [19:06:49] Nope [19:07:10] *guillom is many years sober. [19:07:20] (well, it depends on whether cider counts or not) [19:08:18] That's alcoholic [19:08:25] yup [19:08:28] Oh hey flipzagging's here [19:08:29] Ok, then a few months. [19:08:34] hi [19:08:45] flipzagging> you mean concatenated right into html [19:08:45] I need the phone # for the meeting [19:08:47] |<-- flipzagging has left freenode (Quit: flipzagging) [19:08:48] Yes [19:08:50] Without escaping [19:08:50] power [19:08:52] Grr, he left [19:08:53] ext 2003 [19:08:57] (415) 839 6885 [19:08:59] I used to make cider in our backyard in Normandy. [19:09:08] viva la francais! [19:10:23] flipzagging, when you get a chance: http://eiximenis.wikimedia.org/FeaturesTeam20101123 [19:10:33] If I am to introduce global CSS and JS file for user, where would I put it? [19:10:40] Meta? Or let the user choose? [19:10:41] It's already done in trunk [19:10:45] Oh global [19:10:49] Yeah [19:10:49] i'm in the meeting now [19:10:55] Bug 13953 [19:11:40] We don't have a way to specify / change our home wiki, do we? [19:11:45] So, I'd say meta. [19:12:06] Plus, meta admins already have access to global stuff. [19:12:22] Hello Bryan. [19:12:31] hi [19:14:25] we should probably get around to making a home wiki selector then :) [19:14:33] on general principal at least [19:14:36] principle? [19:14:41] princeship? [19:14:45] prince consul? [19:14:48] eh forget it [19:15:48] I can haz global preferences too plz? :) [19:15:59] That'd be nice ;) [19:16:08] According to werdna backend support is not difficult, but it needs a decent interface (i.e. UX folks) [19:16:13] I said I'd try to come up with a UI for it, but I've never got around to doing it. [19:16:22] global watchlist? [19:16:44] Maybe I can try to do that in December, when all the decision-making people will be away :P [19:17:06] Oh, grammar fail [19:17:42] global watchlist is harder but not impossible [19:17:54] doing it well would benefit from more shared data streams being available [19:18:02] brion: I'm not sure whether we should use "home wiki" model or allow user to specify page to transclude code from for each code page [19:18:16] global watchlist would need a global recentchanges [19:18:28] Would global recentchanges be an appropriate solution? [19:18:37] woah, global recent changes would be interesting [19:18:41] heh [19:18:44] I think SWMT folks would love it [19:18:49] domas is gonna kill y'all [19:19:29] Bryan: why? [19:19:43] well, let's get things like central repository of geocoordinates, etc. to share on wikis [19:20:42] because the global rc is going to kill his poor db servers obviously [19:22:21] WIKIDATA!!!!1111 [19:36:08] Reedy, flipzagging: Please mute yourselves [19:36:28] I can hear the noise, it's not me [19:36:34] not me [20:14:31] vvv: There's a reasonable argument that Commons should be the home of global JS/CSS. [20:14:47] Shirley: what is it? [20:14:48] Though I think Meta makes more sense. [20:14:55] Commons is the common repo, I guess. [20:16:23] Shirley: I am currently inclined to set it to "home wiki" [20:17:09] I think that adds a lot of complexity for no real benefit. [20:17:19] Having it consistently in one place is nice. [20:18:43] Shirley: what about users with SUL conflict on Meta? [20:18:58] They should resolve the conflict. [20:20:43] Shirley: and if it is impossible? [20:21:05] I don't see how it would be impossible to resolve a conflicted account. [20:21:22] But otherwise they won't have global CSS/JS, then. [20:21:30] That's the cost of not having a proper global account. [20:21:51] The concept of a home wiki doesn't really make sense when dealing with global pages. [20:21:54] Shirley: e.g. this account was used by a user with non-zero contribution [20:22:03] It doesn't matter what your home wiki is, the point is that you want the code to work globally. [20:29:36] Shirley: I am not sure we should bind the user to some ceratin arbitrary wiki [20:30:18] Global JS and CSS should be editable through your (global) preferences on any wiki. Problem solved :) [20:30:26] vvv: What page structure were you thinking about? [20:30:55] guillom: Hmm. [20:32:06] I'm considering following variants: [20:32:06] 1) Bind user to a certain wiki and user subpage on it; [20:32:06] 2) Allow him to choose "home wiki" where all the CSS, JS, whatever is stored; [20:32:06] 3) Allow him to specify which page is his global CSS, JS, whatever; [20:32:06] 4) Store it in a separate storage in a database [20:32:52] In case 4, we either need to mess with cross-wiki page editing or invent a new storage [20:33:10] If you have a global /common.js, how would you specify local JS on that wiki? [20:33:41] Rename common.js to global.js or whatever [20:33:48] Hmm. [20:34:21] I like the global preferences option, but there are some benefits to being able to see other users' JS/CSS. [20:35:19] Shirley: if we implement global prefs, we will be forced to implement history [20:35:56] Why? [20:36:04] Current prefs have no history. [20:37:16] Yes, but they are trivial [20:37:25] JS is non-trivial and you may want to rollback [20:43:00] I believe I'll stick to (1) [20:45:56] You could have both: using global preferences only as a wrapper, an access point to a central subpage. But then you'd need to make sure the user isn't blocked there. Oh, well. [20:46:39] The easiest way right now would be to just provide a link in your preferences to the central subpage [20:47:19] Might be nice if the page actually did something, though. [20:47:28] Not that a link wouldn't be nice. [20:48:39] A link would be an easy first step. An editor would be a nice improvement. [20:49:18] Another pain would be loading it [20:50:31] allowing users to add an arbitrary url as their js? [20:54:03] Bryan: that would mean that users will be forced to write a URL for their global.js page themselves [20:54:17] Which is action=raw&ctype=text/javascript&... [20:54:29] yeah that sucks [20:59:43] What's a good term for "CSS & JS"? [20:59:51] Resources? [21:00:03] But JS/CSS is often used [21:00:49] [21:57:10] this program .. wow... NOT at all user friendly. [21:00:54] well, duh? :p [21:11:56] Bryan, blasphemy! [21:12:41] mediawiki was not designed to be user friendly [21:12:59] oh right, mediawiki was not designed at all :p [21:15:05] Design? What is design? [21:15:20] *vvv looks through the MediaWiki code [21:17:38] well, some parts were designed [21:17:55] They were particularly lucky [21:17:56] then people who did not read the design docs started messing with it [21:18:01] *Bryan points to filerepo [21:18:14] Are there filerepo design docs? [21:18:21] yes [21:18:24] Wow [21:18:24] I admit guilt [21:18:39] *vvv did not read them when he was hacking it [21:19:06] oh yeah, you are guilty as well [21:48:03] RoanKattouw: are user resources loaded via ResourceLoader as well? [21:48:22] Yes [22:07:44] hey vvv [22:07:55] hi flipzagging [22:08:02] I saw your comment about UploadWizard being Soviet software ;) [22:08:28] In Soviet Russia, comments see you! :) [22:08:43] <^demon> In Soviet Russia, files upload you! [22:09:05] it is now something more like Canadian software [22:09:12] it apologizes that it can't do what you actually wanted [22:10:20] flipzagging: http://xkcd.com/612/ [22:10:50] heh [22:11:16] this software is trying to reveal to you that life is unpredictable [22:11:20] it's really a zen experience [22:11:42] http://www.trevorparscal.com/stuff/thehawk (make sure your audio is loud enough to hear before clicking - it's not a rick roll don't worry) [22:15:01] it's more of a hawk roll [22:35:39] flipzagging: http://www.ama3.com/anytime/ [22:35:58] hm [22:36:25] look at the demo in section 4 [22:36:42] if you click on the next/prev button for the year [22:36:54] That is ridonkulous [22:37:00] enter a year by pressing four buttons? [22:37:10] I'm not saying I think it's awesome [22:37:13] just interesting [22:37:25] and better than the way jquery-ui handles it [22:38:01] Well, it does handle CE / BCE dates better [22:38:04] the stock datepicker is not going to be able to be used for setting old dates [22:38:08] I really don't like the button-happy nature [22:38:24] even if you set the minDate to new Date( 0, 1, 1 ) [22:38:33] it only goes back to 1900 [22:38:35] I'd be happy if we could go back to the 1850s [22:38:41] even 1900 isn't too bad [22:38:48] so the other thing is [22:38:53] we only need to notate the year of capture in this app [22:38:59] the drop-down list will only show 20 years at a time [22:39:15] so you have to click, and select the oldest date 4 consecutive times [22:39:32] Honestly it doesn't bother me at all. [22:39:49] 99.9% of the time the date of capture is within the last decade. [22:40:03] if they have to click 4x to get to 1900 that's ok [22:40:41] TrevorParscal: is it possible to make ResoureLoader load a resource from a URI? [22:40:45] I agree that some better solution might be a good idea, but we'd have to test if this guy's date handling routines understand the Julian date switchover and other bizarre anomalies. [22:41:21] vvv: mediawiki.loader.load currently supports loading anything, just pass it a string that begins with http:// [22:41:28] the second optional param is the media type [22:41:35] TrevorParscal: and if I am inside the code? [22:41:50] what code? [22:41:54] the client or the server? [22:42:16] TrevorParscal: anyway, my advice is just mark a new enhancement for dates before 1900 and be done with it... [22:42:23] TrevorParscal: server [22:42:55] flipzagging: ok, I can get it to do 1800s, by using new Date( -1000, 1, 1 ) [22:43:05] wow [22:43:12] is that documented? [22:43:13] vvv, just use $wgOut->addScript then [22:43:27] Heh [22:43:41] anyway the Any+Time plugin does look neat but let's defer that [22:43:58] flipzagging: for sure [22:44:13] I'm not suggesting we use it even, I'm just saying, it's interesting [22:44:20] robla can i use flaggedrevs prototype to test stuff or would you rather i waited till after the push? [22:44:57] flipzagging: the -1000 is 1000 years previous to today [22:45:00] I can use 1850 [22:45:05] pdhanda: go ahead and use it in the 12 min we have left :) [22:45:08] but 0 doesn't work [22:45:11] I could even use 1 [22:45:14] interesting [22:45:17] it would be 1BCE [22:45:26] i mean [22:45:27] 1CE [22:45:54] robla: ok, feel free to revert my changes there if you need to [22:46:37] TrevorParscal: Especially since the interface for going back years is deficient in your view, we should cut it off at somewhere like 1800. [22:46:46] k [22:46:57] I mean, you can still write a date in text [22:47:10] which really old ones will probably be done that way anyways