[00:00:42] Nemo_bis: Do you use yanker? [00:00:53] I'm likely more willing to port tools that people actually care about. [00:01:00] I don't use any of them, I don't think. [05:01:35] Carmela: yes, I love yanker for all sorts of wiktionary searches, it's a good rhyme book as well ;) [07:34:05] hello everyone [07:34:53] http://stats.grok.se is down [07:36:18] does anyone knows who could fix it? [07:37:11] in 20 minutes we have a presentation of a Commons project [07:40:11] emailed [08:58:59] stats.grok.se fixed by henrik [11:23:47] YuviPanda: he has his "home" office on his user-page ;) [11:24:12] and yea, OUCH [11:24:23] Trminator: :) [11:25:10] Does anyone have any idea why Special:ProtectedPages is full of "unknowns"? [11:25:19] It starts to become intelligent about here: https://en.wikipedia.org/w/index.php?title=Special:ProtectedPages&dir=prev&offset=532100 [11:25:40] Was this a case of a table (log_search perhaps) not being populated up to that point? [11:26:04] although that would be strange, the docs say that DB table was introduced well before February 2014 [11:26:13] so what's up here then [11:26:14] ? [11:31:18] tto: seems the "lookup" algorithm changes on that page exactly? (i.e. it shows unknown once the offset in the url doesn't change anymore, but the dir(ection) variable is introduced into the url [11:31:51] Not sure what you mean; it seems to occur whichever direction you look at things [11:36:05] sorry about that. [11:36:32] seems like the earliest date is 20:29, 27 February 2014 [11:41:09] 27 Feb was a Thursday, so possibly deploy-related [11:43:18] so maybe something new was introduced filling that table? [11:45:58] https://wikitech.wikimedia.org/wiki/Deployments/Archive/2014#Week_of_February_24th [11:46:13] 1.23wmf15 to wikipedias [11:46:48] "git #782afa6e - Added summary to Special:ProtectedPages and Special:ProtectedTitles. (bug 61454)" [11:47:02] so, at least a table change to that table happened that day. [11:47:44] err [11:47:46] nvm that one [11:47:48] git #ca7c0981 - Use TablePager on Special:ProtectedPages (using log_search) [11:47:54] that's the reason I guess. [11:49:01] tto: you even commented on that patch ;) [11:49:07] https://gerrit.wikimedia.org/r/#/c/105443/ [11:49:11] Ha, did I really! [11:49:23] It's strange that there was no proposal to "back-fill" log_search [11:50:05] There should at least be a maintenance script to do that [11:50:21] I like that one can actually find out that kind of stuff from nearly 4 months in the future without being in ops or even a wiki dev ;) [11:50:37] Cool, isn't it! [11:51:25] there is a possibly relevant maintenance script (populateLogSearch.php) but it doesn't support protection [11:53:51] looking closer, seems as though a clean "back-fill" of this would be quite difficult although probably possibly [11:53:53] *possible [11:53:56] I'll file a bug [11:57:51] :) [12:00:18] https://bugzilla.wikimedia.org/show_bug.cgi?id=66777 [12:10:11] andre__: any reasons why we have broken links at https://bugzilla.wikimedia.org/weekly-bug-summary.cgi?tops=10&days=7 ? [12:11:05] andre__: "Top 10 people who resolved the most reports in the last 7 days:" is inside an tag which even has name attribute but no href attribute [12:11:21] andre__: is it an upstream bug or something broken in our Bugzilla installation? [12:14:39] "Top 10 people who most quickly fixed a report in the last 14 days:" is most hilarious [12:14:51] (Usually it's empty though, we got better!) [12:15:46] twkozlowski: I don't understand what's wrong with that report, did it really change? If you care about this report you should ensure there is a similar functionality in phabricator and file a ticket. :) [12:16:28] If you're looking for your position, https://bugzilla.wikimedia.org/weekly-bug-summary.cgi?tops=15&days=7 [12:17:21] Nemo_bis: Try hovering over the "Top 10 people who resolved the most reports in the last 7 days:" link [12:17:39] Nemo_bis: Even better, try opening the link :-) [12:19:13] I never needed that link so I have no idea how it used to be [12:19:26] twkozlowski: no real idea, that's kind of abandoned land and was once upon a time copied from KDE Bugzilla modifications, predating my existence [12:19:30] Neither have I, only stumbled on it by mistake [12:19:32] code is at https://git.wikimedia.org/blob/wikimedia%2Fbugzilla%2Fmodifications.git/HEAD/extensions%2FWeeklyReport%2Ftemplate%2Fen%2Fdefault%2Fweeklyreport%2Fweekly-bug-summary.html.tmpl if you feel like hacking [12:19:50] and that "Top 10 people" stuff has never ever worked since I'm here [12:20:26] I once tried to fix it a little bit I remember, but my skills are obviously limited. We might just want to completely remove that "Top 10 fastest blah" if anybody cares. [12:20:33] andre__: Only if I knew where to target the link, then yeah [12:20:47] twkozlowski, I think that somebody wanted to set an anchor target [12:20:52] that's the only guess I have [12:23:55] Hmm... Guess we can just make it a

tag with an id attribute so people can link to it if they want [12:24:31] twkozlowski, upstream looks the same: https://projects.kde.org/projects/websites/bugs-kde-org/repository/revisions/f24e4c815e8b69fd6a17ed4e79bdeda16cdeecfc/entry/template/en/custom/reports/weekly-bug-summary.html.tmpl#L53 [12:26:29] andre__: Well, I can change this if you want [12:27:14] also can upstream it to KDE as they use Git as well [12:27:39] twkozlowski, I'm pretty neutral here but I won't stop you from patching if you feel like fixing it :) [12:47:50] lol https://tools.wmflabs.org/catscan2/catscan2.php [12:49:45] Nemo_bis: explain context? :) [12:51:16] YuviPanda: https://jira.toolserver.org/browse/TS-1731 http://tools.wmflabs.org/wikisense/ [12:52:22] ah [13:01:29] yay andre__, comment conflict [13:01:46] wasn't me! [16:50:46] http://meta.wikimedia.org/w/index.php?title=Special:Contributions&contribs=newbie [16:51:11] PHP fatal error in /usr/local/apache/common-local/php-1.24wmf9/extensions/Flow/includes/Data/CachingObjectMapper.php line 49: [16:51:11] Argument 1 passed to Flow\Data\CachingObjectMapper::fromStorageRow() must be an array, null given, called in /usr/local/apache/common-local/php-1.24wmf9/extensions/Flow/includes/Data/ObjectLocator.php on line 301 and defined [16:51:44] Glaisher: Thanks. I'll file it as a bug [16:52:00] Oh, already reported [16:52:01] https://bugzilla.wikimedia.org/show_bug.cgi?id=66509 [16:54:28] Reedy: That's about something else, I think? [16:54:47] interwiki refs O_o [16:55:02] Back to reporting it then ;) [16:56:32] https://bugzilla.wikimedia.org/show_bug.cgi?id=66797 [16:57:01] thanks [17:30:59] [17:33:22] hi [18:12:25] Z [18:12:56] Papaul [18:19:15] Cmjohnson1 mgt asw mgt msw will be better [18:21:06] papaul: goto operations [19:51:36] !!! MediaWiki release management applicant's IRC office hour starts in 10 minutes over in #wikimedia-office !!! [19:53:16] Hmmm. Is there no separate project for Mediaviewer on Bugzilla? [19:54:17] Excirial: MediaWiki extensions -> Multimedia Viewer? [19:55:24] MatmaRex: Thanks, that was indeed what i was looking for. Seems i stared straight past it. [19:59:15] Hi [19:59:37] Something came up when dealing with something in realtion to VADA at English Wikipedia [19:59:49] Currently it downloads entire articles to do minor search and replace... [20:00:14] Is there a way to offload search and replace so that entire articles don't need to be transfered each time? [22:49:27] Anyone here? [22:49:36] * Mono could use some help with a labs problem [22:49:49] see also: #wikimedia-labs [22:50:03] yep :)