[00:38:10] I think there's an open bug report about that. [00:38:44] How can someone be banned for impersonation on IRC? [02:07:50] is there a way to force a content-disposition header on a file (possibly a thumbnail) hosted on upload.wikimedia.org? [02:09:36] i'll rephrase: is there a way to link to a WMF-hosted file in such a way that it will be downloaded instead of displayed? [02:10:01] on old browsers which do not support the download HTML5 attribute [02:11:31] Anybody else recently report bits being slow? [02:12:32] tgr: example? [02:15:49] Betacommand: >> Here is our amazing picture of the day! you can download it, too! << - user clicks link, browser tries to display one-gazillion-byte JPEG file, and crashes [02:16:14] i was wondering if it was possible to link in such a way that avoids this [02:16:36] add an extra query parameter which is understood by the file servers, or something [02:17:05] tgr: I would recommend instructions about right-clicking and saving [02:17:34] Ive seen browsers going back to IE6 that supports viewing and not downloading [02:18:23] you mean it does not understand content-disposition: attachment headers? [02:19:28] yeah [02:20:03] tgr: Ive almost never seen an image auto-download ive always viewed it [02:21:39] that still leaves an awful lot of browsers which have sane download behavior but you cannot force it from HTML [02:22:10] Betacommand: http://caniuse.com/download [02:22:25] i'm pretty sure most of these do understand the header [02:23:35] tgr: IE never has [02:23:46] "Here is this link. Please don't click on it or your browser will explode" is kind of horrible usability [02:24:06] safari doesnt either [02:24:54] tgr: you could use some JS hacks to detect the browser version and only provide the link in supported browsers [02:25:49] Betacommand: that's the plan, but I would like to increase the set of supported browsers by adding a header on server-side [02:26:35] tgr: you would need to either hack thumbs.php or write your own extension [02:27:35] i don't think those are involved in an image request [02:27:42] on public wikis, anyway [02:27:57] this should be an apache setting [02:30:24] tgr: Difficult to implement. [02:30:37] I think don't think Betacommand is right about headers. [02:31:07] tgr: Ideally we'd do something server-side, as you suggest, but knowing what the appropriate behavior is can be tricky. [02:31:17] For some users, it's not a big deal to load a large image in-browser. [02:31:23] And "large" is ambiguous. [02:32:50] tgr: You can probably create an "always download" link currently by futzing with index.php. [02:33:16] index.php?title=Media:Foo.png&action=raw maybe. Or something like it. [02:34:30] Gloria: piping images through PHP sounds a bit scary to me [02:35:08] Scary how? [02:35:12] i suppose people won't download hundred-megabyte images too often, but still, seems an unnecessary risk just for adding one header [02:35:14] Every private wiki does it, as I recall. [02:35:28] What risk are you referring to? [02:36:10] Whether you download the file and it displays in your browser or downloads a file to your local machine, the difference to the server is almost non-existent. You're still using the bandwidth and server (and client) resources. [02:37:44] yeah, but the server has to keep a PHP thread open during the whole process [02:38:14] and if something is misconfigured, the whole image will be loaded into the server's memory [02:38:43] but i guess people don't download images too often so even that should not be problematic [02:38:58] People download images very often. [02:39:03] On nearly every page request. [02:39:46] Or they get re-read from browser cache. [02:39:52] i mean, download with the intent to download [02:40:11] People do that a lot too. [02:40:29] Some Wikimedia wikis are pretty popular. :-) [04:41:16] those were probably readded on unsplit [13:49:30] https://ganglia.wikimedia.org/latest/graph.php?r=month&z=large&c=Miscellaneous+eqiad&h=sodium.wikimedia.org&jr=&js=&v=15942&m=exim_queued_messages&vl=messages [13:54:52] this saner https://ganglia.wikimedia.org/latest/graph.php?r=month&z=large&c=Miscellaneous+pmtpa&h=mchenry.wikimedia.org&jr=&js=&v=49&m=exim+queued+messages&vl=messages [14:00:07] Nemo_bis: interesting, thanks [14:00:21] it looks like 14k of these 16k are just 6 users [14:00:37] 4 for them with a .pl domain [14:00:51] root@sodium:/var/log# zgrep -c wp.pl exim4/mainlog.3.gz [14:00:52] 999921 [14:01:10] host mx.wp.pl [212.77.101.4]: 450 sorry, recipient's account limit exceeded [14:06:05] lol [14:06:20] so yeah, it looks like a red herring [14:06:59] My favorite type of herring. [14:09:36] I eat it with broccoli on pasta [14:10:17] :) [16:01:53] It's always nice when open bugs decrease http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075288.html [16:10:31] Nemo_bis, yeah, but it's a lot of work :D [16:28:40] hi, X!'s edit counter isn't working, but I'm not sure if it's an issue with the script or an issue with the server. [16:28:56] trying to access it gives "The URI you have requested, http://tools.wmflabs.org/?502, appears to be non-functional at this time. [16:28:56] " [16:37:25] Labs is migrating. [16:38:49] okay, thanks. [16:38:56] Is that why the tools are not working? [16:39:06] ah well [16:39:15] It is. [16:39:26] I just read the scrollback. [17:55:05] Gloria: you're listed as participant for https://www.mediawiki.org/wiki/Project_management_tools/Review , I suppose you remember about it? :) Weird for it not to be linked in your thread. [17:55:46] Nemo_bis: I'm not sure the conflation of code review and project management is a good thing. :-) [17:55:53] I might be alone, though. [17:56:39] It's just one of the features some of those tools offer. [17:56:51] I'm rather sure we're not considering merging mediawiki.org to a trac wiki, for instance. [17:57:22] Hm, that's interesting. [17:57:58] Is a development model "agile" when you have communication problems due to excessive number of tracking tools? [17:58:06] :-) [17:58:10] twkozlowski: http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075299.html is the mentioned thread. [18:00:12] twkozlowski: agile doesn't mean fluid, it only means that instead of crashing on the floor at 100 m/s every 6 months you only crash at 4 m/s every week. (For instance because of miscommunication.) <--- just a metaphor, not a definition [19:00:03] I just accidentally told Wikidata to show me the interface in French, and I can't find the language setting in the preferences [19:00:05] any suggestions? [19:00:50] oh wait, there it is. [19:01:10] https://www.wikidata.org/wiki/Special:Preferences#mw-prefsection-personal-i18n [20:02:42] Well that was a slow page load [20:02:53] Oh, no, better now. [20:02:55] Ignore meeeeee