[04:23:43] 3MediaWiki / 3Uploading: MimeMagic: ZIP types not properly detected - 10https://bugzilla.wikimedia.org/66428#c13 (10Mark A. Hershberger) There is no automatic method that I know of. We're still checking these manually. Cherry-picking, as was done here, is the best route to go because then it will be in the... [13:31:28] 3MediaWiki / 3Uploading: Upload broken after upgrade to 1.23 - 10https://bugzilla.wikimedia.org/66467#c19 (10Andre Klapper) 5PATC>3RESO/FIX All patches merged (or abandoned) hence assuming this is FIXED. Thanks everybody for helping tracking this down. [13:31:59] 3MediaWiki / 3Uploading: Upload broken after upgrade to 1.23 - 10https://bugzilla.wikimedia.org/66467#c20 (10Andre Klapper) *** Bug 66349 has been marked as a duplicate of this bug. *** [13:42:43] 3MediaWiki extensions / 3TimedMediaHandler: Distorted thumbnail for audio files due to wrong size - 10https://bugzilla.wikimedia.org/66852 (10Andre Klapper) p:5Unprio>3Normal [14:22:42] Krinkle|detached: Can you take another look at https://gerrit.wikimedia.org/r/138999 sometime? [16:06:47] (03PS1) 10Zfilipin: Using new Cucumber browser tags [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/141453 [16:06:55] (03CR) 10jenkins-bot: [V: 04-1] Using new Cucumber browser tags [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/141453 (owner: 10Zfilipin) [16:07:29] 3MediaWiki / 3Uploading: image upload fails with complaint about it being a "corrupt or otherwise unreadable ZIP file." - 10https://bugzilla.wikimedia.org/54105 (10Andre Klapper) [16:08:31] 3MediaWiki / 3Uploading: anonymous upload gives UploadStashNotLoggedInException - 10https://bugzilla.wikimedia.org/66115 (10Andre Klapper) [16:08:37] 3MediaWiki / 3Uploading: Setting $wgVerifyMimeType to false causes upload failure with "Undefined variable mime in UploadBase.php line 420" - 10https://bugzilla.wikimedia.org/49717 (10Andre Klapper) [16:14:39] So uh [16:14:51] Did anyone figure out what happened that spammed us with grrrit-wm messages [16:14:59] 'cause there were, like, 500 [16:58:33] (03CR) 10MarkTraceur: "Patch incoming!" (038 comments) [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139295 (owner: 10MarkTraceur) [16:58:45] (03PS6) 10MarkTraceur: Add section for attribution of downloads [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139295 [16:58:50] (03CR) 10jenkins-bot: [V: 04-1] Add section for attribution of downloads [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139295 (owner: 10MarkTraceur) [17:04:00] (03PS24) 10MarkTraceur: Massive refactor [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/68835 (https://bugzilla.wikimedia.org/39746) [17:04:12] (03CR) 10MarkTraceur: "Sorry about that - reversed the booleans there" [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/68835 (https://bugzilla.wikimedia.org/39746) (owner: 10MarkTraceur) [17:26:16] (03CR) 10MarkTraceur: [C: 04-1] Separate the opt-in/opt-out actions into their own tab/graph (033 comments) [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/140888 (owner: 10Gilles) [17:31:09] (03CR) 10MarkTraceur: [C: 032] Calculate opt-in/opt-out totals [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/140889 (owner: 10Gilles) [17:31:15] (03Merged) 10jenkins-bot: Calculate opt-in/opt-out totals [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/140889 (owner: 10Gilles) [17:33:16] (03CR) 10MarkTraceur: [C: 032] Add opt-out and opt-in totals to graph [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/140890 (owner: 10Gilles) [17:34:21] (03CR) 10MarkTraceur: [C: 04-1] Display opt-out totals for each wiki on a global graph (031 comment) [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/140892 (owner: 10Gilles) [17:35:21] (03CR) 10MarkTraceur: "Sorry, am noob" (031 comment) [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/140888 (owner: 10Gilles) [17:59:43] * marktraceur can tear out the next/prev tooltips now [18:19:20] (03PS5) 10Krinkle: Fix URL handling for global usage list [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/138999 (https://bugzilla.wikimedia.org/63908) (owner: 10Gergő Tisza) [18:21:39] (03CR) 10jenkins-bot: [V: 04-1] Fix URL handling for global usage list [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/138999 (https://bugzilla.wikimedia.org/63908) (owner: 10Gergő Tisza) [18:35:00] marktraceur: Not really, I don't know that code base. I just spotted the original commit and gave some advice as it looked suboptimal. I have no intent to approve or reject it. I see you went with a different approach, fine by me. [18:35:20] (you;plural) [18:36:31] 'kay [19:19:38] bd808, I've a project since Friday but somehow don't manage to set up the proxy properly. Apache is running - firewall port is open - security groups? - proxy is in place [19:20:34] I wonder what's wrong, maybe you could have a look at https://wikitech.wikimedia.org/wiki/Special:NovaSecurityGroup [19:21:18] wget localhost over SSH tunnel works as expected but http://mol.wmflabs.org/ does not [19:22:06] and of course puppet failed ... but I think it always does for trusty? [19:22:14] rillke: Which project? Am I a member? [19:22:35] you are a member of mediahandler-tests [19:22:41] * bd808 sees that now [19:23:01] Lame wikitech requires logging out and back in to get new memberships to work correctly [19:24:31] rillke: I can't see the config pages unless you make me an admin as well. [19:25:40] argh, sorry [19:25:41] Successfully added BryanDavis to projectadmin. [19:28:34] is there still pmtpa.wmflabs ? [19:29:02] rillke: Ah ha. You got bitten by one of the lamest things in labs. Your instance is only in the "default" security group, so the "web" rules don't apply. [19:29:37] So you can either a) add the web rules to default or b) create a new instance and add the web security group to it [19:30:01] You can't change security groups after creating the instance (no idea why) [19:32:31] will someone be annoyed if I create a large one ? [19:32:56] * rillke has no idea what he needs for a "test wiki" [19:33:03] Nope. x-large would be fine too. There are plenty of resources in labs. [19:33:15] (03CR) 10Siebrand: [C: 031] "i18n/L10n reviewed." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/139295 (owner: 10MarkTraceur) [19:34:06] The puppet failure on that host looks like a bug in the manifests too. [19:48:11] Wow, wikitech notifications suck [19:51:28] * rillke now cannot login ... Permission denied (publickey). [19:51:36] bawolff: YOU HAVE A NEW NOTIFICATION AT WIKITECH!!!! [19:51:43] We just need to up the enthusiasm [19:52:26] bawolff: There's a bug. I think I figured out what needs to be fixed but I've never tried to find the code to fix. -- https://bugzilla.wikimedia.org/show_bug.cgi?id=53778#c5 [19:54:27] Of course if it got fixed then somebody would have to figure out how to get wikitech updated with the new code (1.23wmf22) [20:10:50] I can login into any new instance I create ... and puppet status is now "unkown" [20:10:58] *I cannot [20:36:59] 3MediaWiki extensions / 3UploadWizard: ApiFlickrBlacklistTest::testBlacklistMatchByNsid fails - 10https://bugzilla.wikimedia.org/66938#c1 (10Ori Livneh) It's actually three tests that are failing: PHPUnit 4.1.3 by Sebastian Bergmann. Configuration read from /srv/mediawiki/tests/phpunit/suite.xml FFF......... [20:44:53] wb neilk_ [20:45:20] marktraceur: :) [20:46:24] Howdy neilk_ [20:51:56] bawolff: ahoy [21:18:28] 3MediaWiki extensions / 3UploadWizard: ApiFlickrBlacklistTest::testBlacklistMatchByNsid fails - 10https://bugzilla.wikimedia.org/66938#c2 (10Bawolff (Brian Wolff)) This appears to be caused by not having network access to the tests (Apparently it treats unable to read flickr api response as image is ok...) [21:19:15] 3MediaWiki extensions / 3MultimediaViewer: Media Viewer is rendering some images at an incorrect ratio in IE 11 - 10https://bugzilla.wikimedia.org/66997 (10Keegan Peterzell) 3NEW p:3Unprio s:3normal a:3None Using Windows 7, Internet Explorer 11, some files are not displayed at the correct aspect rati... [21:28:01] 3MediaWiki extensions / 3MultimediaViewer: Image dimensions in IE11 are skewed - 10https://bugzilla.wikimedia.org/66998 (10Tisza Gergő) 3NEW p:3Unprio s:3normal a:3None Created attachment 15701 --> https://bugzilla.wikimedia.org/attachment.cgi?id=15701&action=edit Commons logo, displayed more wide... [21:28:33] (03PS1) 10Brian Wolff: Make unit tests be skipped if no network. [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/141582 (https://bugzilla.wikimedia.org/66938) [21:28:44] 3MediaWiki extensions / 3MultimediaViewer: Image dimensions in IE11 are skewed - 10https://bugzilla.wikimedia.org/66998 (10Tisza Gergő) [21:28:44] 3MediaWiki extensions / 3MultimediaViewer: Image dimensions in IE10 are skewed - 10https://bugzilla.wikimedia.org/66244 (10Tisza Gergő) 5PATC>3RESO/FIX [21:29:14] 3MediaWiki extensions / 3MultimediaViewer: Image dimensions in IE11 are skewed - 10https://bugzilla.wikimedia.org/66998 (10Tisza Gergő) [21:30:44] 3MediaWiki extensions / 3MultimediaViewer: Media Viewer is rendering some images at an incorrect ratio in IE 11 - 10https://bugzilla.wikimedia.org/66997#c1 (10Tisza Gergő) 5NEW>3RESO/DUP *** This bug has been marked as a duplicate of bug 66998 *** [21:30:44] 3MediaWiki extensions / 3MultimediaViewer: Image dimensions in IE11 are skewed - 10https://bugzilla.wikimedia.org/66998#c1 (10Tisza Gergő) *** Bug 66997 has been marked as a duplicate of this bug. *** [21:41:44] fabriceflorin: please burn the survey with fire. I can't take people playing with the numbers and calling us liars all day only to be might by silence much longer [21:41:53] *met by [21:42:56] https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC#Less_than_honest_approval_rating [21:42:59] * Keegan headdesk [21:43:37] Also, if a volunteer has time to explain that an RfC runs for 30 days and is closed by an uninvolved editor that'd be great [21:43:42] I tried to explain it and it didn't take [21:44:00] Keegan: Hi Keegan, your timing is impeccable. I’m getting ready to respond to the comments on the English Wikipedia now. My current recommendation is to stop inviting feedback on Wednesdays for all sites except english, german and commons. I am sending an email to the team now about this, will respond to the community next. [21:44:24] First rule of statistics - if it can't be twisted, its not real statistics :P [21:44:36] bawolff: inorite? [21:47:22] Keegan: So is the RfC supposed to close on July 9? It seems to have started on June 8. [21:47:35] bawolff: unfortunately we've developed a small camp of participants who are basically saying "A small group of you at the WMF crammed this down our throats without broad consent [fair enough]. Our small group would like to undo your changes without broad consent as well." [21:48:08] fabriceflorin: in theory. An RfC can actually sit open for, well, forever if no one closes it [21:48:29] It can also be closed against the wishes of the dissenting if they do not have enough participation [21:48:37] Which will really put a bee in their bonnett [21:48:39] *bonnet [21:48:51] I'm not quite sure they get that part of the RfC process [21:49:04] It's not a binding decision making process/body [21:51:32] Keegan: How many participants is considered a minimum for an RfC to be considered valid about a major software decision? Right now, it seems that we’re looking at about 40-50 participants. [21:51:48] On English? Hundreds [21:51:56] Well [21:52:01] Specifically for this [21:52:08] Site-wide change [21:52:37] It's the same reason the WMF can't feasibly ask the English Wikipedia to come to consensus to turn on a feature [21:53:02] Keegan: Is there a policy about the minimum number of participants? Also, there is a policy that states that the WMF doesn’t have to get consensus for all software changes, which we may support this initiative. [21:53:18] If it's an RfC about, say Stock Exchange Ticker Symbols, a couple dozen participants can come up with a decision [21:54:02] fabriceflorin: Q 1: No, no policy on participant numbers. Q 2: Why yes, that is a policy [21:54:04] * Keegan digs for the link [21:58:39] Not quite what I'm looking for, fabriceflorin, but close https://en.wikipedia.org/wiki/Wikipedia:Consensus#Decisions_not_subject_to_consensus_of_editors [21:58:47] I know it has its own page. Or did. Hmm. [21:59:25] Anyway, the policy basically says the the WMF gets to release whatever software it pleases without local consent of the English Wikipedia [21:59:34] I think some tried to bury that after VisualEditor [21:59:58] Also, this is good reading https://en.wikipedia.org/wiki/False-consensus_effect [22:01:13] (03PS1) 10Brian Wolff: Merge branch 'origin/wmf/1.23wmf22' (early part) into mergeInto123-4 [extensions/UploadWizard] (REL1_23) - 10https://gerrit.wikimedia.org/r/141586 [22:05:28] Keegan: Yes, that policy is what I remember as well. We also cited that policy during the RfC about the Orange Bar of Doom last year, but I couldn’t find the link in our discussion. Perhaps you might ask your fellow CLs if anyone knows of a more detailed policy. [22:06:24] For now, where is the best place for me to respond? On the Enwiki Media Viewer talk page? in the comments section of the RfC? In both places? [22:08:28] fabriceflorin: probably both? Parties are determined to keep these conversations fragmented :/ [22:10:06] Keegan: There's a statement that its WMF's policy to do as it pleases somewhere on the flow-deploy-to-meta stuff, if you're looking for that [22:12:23] bawolff: Yeah I've seen that...there's one specific for en.wp. I'll find it, I pinged WhatamIdoing [22:12:42] fabriceflorin: this is massive community rejection: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Default_State_RFC [22:12:51] * bawolff for the record thinks such policies are a bad idea, but that's neither here nor there [22:13:17] OK, stand by, I’ll respond within the hour. My goal is to respond very carefully — but briefly. I would like to first respond to the team about the survey, to organize my thoughts. Then post in public. [22:19:59] Cool [22:23:29] Heh, https://en.wikipedia.org/wiki/Wikipedia:You_don%27t_own_Wikipedia is amusing, but WhatamIdoing wrote it a while back (before working for the WMF) [22:27:40] (03CR) 10Gergő Tisza: [C: 032] Merge branch 'origin/wmf/1.23wmf22' (early part) into mergeInto123-4 [extensions/UploadWizard] (REL1_23) - 10https://gerrit.wikimedia.org/r/141586 (owner: 10Brian Wolff) [22:27:59] I'm off for a bit. Toodles. [22:28:04] (03Merged) 10jenkins-bot: Merge branch 'origin/wmf/1.23wmf22' (early part) into mergeInto123-4 [extensions/UploadWizard] (REL1_23) - 10https://gerrit.wikimedia.org/r/141586 (owner: 10Brian Wolff) [22:31:55] (03CR) 10Brian Wolff: "For reference: https://bugzilla.wikimedia.org/show_bug.cgi?id=64157#c23" [extensions/UploadWizard] (REL1_23) - 10https://gerrit.wikimedia.org/r/141586 (owner: 10Brian Wolff) [22:45:16] 3MediaWiki extensions / 3MultimediaViewer: Change page title to image name - 10https://bugzilla.wikimedia.org/67008 (10Tisza Gergő) 3NEW p:3Unprio s:3enhanc a:3None When showing an image, the URL is changed but the page title is not, which renders the browser history mostly useless. We should update... [23:11:25] Keegan: where did you get the active editor count from? [23:12:11] tgr: let me find it [23:16:00] tgr: ATM I can't find the exact page on meta, but here's an article from the economist verifying the numbers http://www.economist.com/news/international/21597959-popular-online-encyclopedia-must-work-out-what-next-wikipeaks [23:16:09] Sourced from the WMF [23:16:23] Special:ActiveUsers ? [23:16:29] not that that is super accurate [23:17:22] bawolff: Nah, Special:ActiveUsers counts one edit in thirty days [23:17:34] According to that we have around 129,000 "active" users [23:17:50] Narrowing the metric to at least five edits in a month whittles the pool down to 30,000 [23:18:08] It's somewhere in the meta Research: space. [23:18:11] My brain hurts. [23:18:33] Well there's always http://reportcard.wmflabs.org/ [23:19:08] https://stats.wikimedia.org/EN/SummaryEN.htm says 31,060 in april [23:19:20] bawolff: perfect, yes [23:19:33] tgr: that ^ [23:20:40] I thought I would calculate the number of active users who have disabled MMV, but I get 12K active users altogether, so I must be doing something wrong then [23:21:21] Hmm. [23:22:07] All I know is that the numbers tail-chasing is ridiculous at this point :) [23:23:21] Wikipedia is dying!!!!!! [23:23:42] tgr: Don't know if this helps or not, "Monthly totals are not normalized to 30-day months" [23:23:52] Carmela: And it's Media Viewer's fault. [23:23:58] nah, I just messed up the query [23:24:02] Media Viewer is pretty wonky. [23:24:03] Ah [23:24:08] Particularly on Commons. [23:24:12] Carmela: To be far, so are you :) [23:24:16] fair [23:24:19] Fair. And not really relevant. [23:24:34] Carmela: :P [23:24:35] On Commons, it's like "maybe you'd like to view this image on Commons." [23:25:12] Carmela: nah, if I wanted to view something on commons, I'd go to wikipedia. Obviously [23:25:24] Carmela: I don't disagree with you about Commons [23:25:36] You could just say you agree. [23:26:09] Semantics! [23:26:13] * Keegan quibbles [23:27:36] Carmela: The Powers That Be are aware that I don't think Media Viewer is appropriate on Commons. I repeat it as often as relevant to discussions :) [23:28:04] The Powers That Be? [23:28:07] You mean me? [23:28:17] It seems like it'd be trivial to disable on Commons. [23:28:21] Does Commons want it? [23:28:54] Carmela: Not overly, but they're not quite at pitch fork level [23:29:08] Probably fixable. [23:29:08] ^ [23:29:11] They mostly decided that they could turn it off in their preferences, and moved on in life [23:29:38] Carmela: I have faith in your skills as an agitator [23:29:47] The default should be sane. [23:29:52] Also, Carmela, you are not the Powers That Be. You are the Power That Is. [23:30:10] If some asshat is trying to force Media Viewer on Commons and they don't want it, I think we can disable it. [23:30:16] And take care of the aggressor. [23:30:56] Carmela: Commons didn't have any uproar. Feather ruffling was minor [23:31:08] Carmela: Wikipedia is much more angsty about it than commons ever was [23:31:09] Like bawolff said, they moved on [23:31:18] The default should be sane. [23:31:21] As I said. [23:31:28] Commons is quite mellow. You have to really piss them off for them to be angry for more than a couple days [23:31:49] Really? Ask them about URAA. [23:32:16] Or MP4, heh. [23:32:18] s/you have to really piss them off/you have to really piss them off about a technical issue [23:32:35] URAA is pretty stupid [23:32:51] MP4 wasn't even that pissy. It was pretty straight forward [23:32:55] actually, on Commons category/gallery pages turning MediaViewer on seems like a pretty sane default to me [23:33:05] those pages are linked from Wikipedia articles all the time [23:33:28] What's the purpose of Media Viewer? [23:33:40] Carmela: To view media! [23:34:12] Keegan: 1.5% of the active users disabled it on enwiki, I just did the math [23:34:14] There's already a file description page. [23:34:20] I wonder what need wasn't being met. [23:34:30] and by "math" I mean "database query" [23:34:37] Carmela: but ajax, and web 2.0, and black backgrounds [23:34:46] Right... [23:35:02] * bawolff stops being snippy for a moment and gives a serious answer [23:35:06] tgr: YOUR NUMBERS LIE LIKE YOU DO EVERYONE HATES IT... :P [23:35:07] That black background cost tens of thousands dollars. [23:35:19] I hope it was worth it. [23:36:12] Keegan: should I clarify or better not talk about numbers any more? [23:36:24] The use case was: * To avoid going to a different page when attempting to view the media in a larger size, * Some folks felt image description pages were too complicated and needed to be simplified, *some folks were confused about how commons desc page and local desc page linked to each other [23:36:41] tgr: I was joking :) 'twas a rough weekend on the talk pages from 3 people :) [23:37:08] [back to being snippy] Also, all the cool kids were doing it (e.g. Flickr, facebook) [23:37:31] bawolff: Sounds like a pretty big waste of money. [23:37:41] Plus it's a file "description" page. Where on Wikipedia can I just /view an image without templates and walls of text/???? [23:37:42] Bullets two and three haven't been addressed. [23:37:55] Keegan: Click twice? [23:38:25] Carmela: Sure, seems simple. Turns out people wander around for several minutes trying to figure that out [23:38:26] Keegan: Of course now we've got glam folks complaining that the wall of text actually had important credit information in it [just saying] [23:38:38] Keegan: https://upload.wikimedia.org/wikipedia/en/4/49/Felipe_VI%2C_King_of_Spain.jpg [23:38:41] Carmela: Not a good solution, you should see some of the outliers [23:38:45] Keegan: Problem solved for free. [23:38:50] in terms of big files [23:38:51] bawolff: as a side not, facebook etc probably spend ten times WMF's total development budget just on usability research [23:38:57] Carmela: Whom did you solve that for? [23:39:02] tgr: To clarify, I'm not complaining [23:39:04] Keegan: You. [23:39:08] not trying to learn from them would be extremely stupid [23:39:13] Where on Wikipedia can I just /view an image without templates and walls of text/???? [23:39:17] You just click the image twice. [23:39:25] What's difficult about that? [23:39:33] Carmela: It turns out, a lot [23:39:41] Right... [23:39:43] Carmela: Did you know there's a tiff file on commons that is 1.01 GB big [23:39:54] click twice on the image would end badly on that file [23:39:56] (Assuming it rendered) [23:39:59] bawolff: How does Media Viewer handle that? [23:40:31] anywho, I'm going to eat dinner. <3 Carmela [23:40:42] tgr: Nobody's suggesting not learning from others. [23:40:53] Well for the moment by exploding because its above $wgMaxImageArea. Once we switch to vips, media viewer will handle it by rendering it in the resolution of the current screen [23:40:54] tgr: But perhaps we should spend time improving existing code rather than adding code to the pile. [23:41:19] tgr: New code has very real costs, of course. [23:41:25] File description pages still suck. [23:42:15] Carmela: improving old code also has real costs, obviously [23:42:27] costs that are much higher actually [23:42:32] Not really. [23:42:40] since there is more chance of breaking existing stuff [23:43:17] Improving existing file description pages is a much better use of time and money than trying to re-create them in JavaScript. [23:43:21] also, you don't want to load a mediawiki page just to display an image [23:43:27] I actually disagree - improving old code means you have a fixed version of old code. Making new code means you still have the broken old code + new code that's going to be broken because nobody gets it the first time [23:43:30] that would make the process inherently slow [23:43:58] You're not just displaying the image. [23:44:05] You're displaying metadata about the image. [23:44:11] That's the point of the file description page. [23:44:14] bawolff: true but that does not say anything about the relative difficulty of the two [23:44:20] For reference, this is the big tiff file I was referring to: https://commons.wikimedia.org/wiki/File:Zoomit2.tif [23:44:40] Media Viewer doesn't allow the user to view only the image. [23:44:41] generally fixing broken code is much harder then writing it correctly in the first place [23:44:43] tgr: I was thinking from a cost vs benefit prespective [23:45:22] tgr: You're talking about doubling the amount of code. [23:45:25] That's not a good thing. [23:45:33] Code is bad. [23:47:39] if the goal is to present a reduced view of the metadata, I am not sure how fiddling with the file page would solve that [23:48:42] Has anyone actually written out a comprehensive argument for what's wrong with file pages [23:48:48] A) you actually hide things from the file page, in which case you will get editors puring gas on their heads and igniting themselves in protest before the WMF headquarters [23:49:30] B) you add some sort of alternative view in top of it, in which case you have implemented MediaViewer, except now you have to go to the file page first to use it [23:49:39] Is that the goal? [23:49:49] bawolff: I doubt it. [23:50:10] personally I would like to see usability tests rather than arguments [23:50:14] Just saying, everyone is taking it as a given that "file pages suck", but it seems unclear what precisely is wrong with them [23:50:24] yes, usability tests better than arguments [23:50:28] Wikimedia in general suffers from too many arguments and too little data [23:51:44] the one thing where we do have data (even if not as much as I would like) is that MediaViewer is blazing fast compared to visiting file pages [23:51:53] so that's one main advantage IMO [23:52:09] bawolff: You'd think you would write requirements before starting a project like this... [23:52:28] tgr: In my personal experience, it's not very fast at all. [23:52:36] It takes a long time for the image to load with Media Viewer. [23:52:41] While file description pages are cached. [23:52:47] And the thumbnails are already generated. [23:52:49] I don't know if "File pages inherently suck" was the sole usecase for media viewer [23:52:57] Carmela: again, data > arguments [23:53:46] Well we cache thumbnails forever, so in short order, that shouldn't be an issue with media viewer [23:53:47] if you have actual numbers and can paste them on https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Speed_reports that would be awesome [23:54:09] tgr: I'm not arguing, I'm telling you that when I click the image, it's slow to load. [23:54:17] And the pre-generated thumbnails are faster to load. [23:54:24] This isn't surprising. [23:54:41] There's also the possibility that human preception of media viewer speeds is different [23:55:12] Generating a thumbnail will always be slower than displaying a pre-generated thumbnail. [23:55:22] when you click on a thumb, with mediaviewer background changes immediately. With normal file page, it takes a little bit. Perhaps the sudden change in background makes it feel "slow" [23:55:25] Media Viewer is generating a thumbnail(?) or some shit. [23:55:35] Carmela: Not really [23:55:44] Then it's loading the full-size image? [23:55:49] It's doing something that's ungodly slow. [23:55:55] There's no such thing as a "pre-generated" thumbnail in mediawiki [23:55:59] What? [23:56:02] It's generating thumbnails [23:56:06] On the file page, its generated the first time someone views it [23:56:15] Right. [23:56:18] on media viewer its generated in the same way, on first view [23:56:20] Which is almost immediate. [23:56:28] Almost immediate for file description pages. [23:56:37] For Media Viewer, it's doing something that's substantially slower. [23:56:38] Depends on your upload method [23:57:10] * bawolff tests some random files in media veiwer to see if thumbs are already generated [23:57:51] if someone already looked at it with a similar screen size, then it is already generated [23:58:00] https://upload.wikimedia.org/wikipedia/commons/thumb/1/1f/Stora_Kronan.jpeg/800px-Stora_Kronan.jpeg from Media Viewer. [23:58:04] https://upload.wikimedia.org/wikipedia/commons/thumb/1/1f/Stora_Kronan.jpeg/429px-Stora_Kronan.jpeg from file description page. [23:58:16] So you're talking about a much larger image that has to be generated. [23:58:19] Of course it's slower. [23:58:41] there are ten-something size buckets, vs. the only one for the file page, so cache misses are somewhat more frequent but should still be rare [23:58:57] so the generation time does not really matter [23:59:11] It matters if you have any sense of time. [23:59:16] downloading the image takes longer, of course [23:59:17] Because one is slower. [23:59:40] Downloading a pre-existing thumbnail is faster than downloading a thumbnail that must first be generated. [23:59:49] No amount of JavaScript can bypass physics. [23:59:56] but that is largely offset but not having to download + initialize a huge HTML page [23:59:56] Carmela: but in your example