[16:48:48] anomie: in API query modules, would is be possible for the API result to have the same order of pages as the query? e.g. https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&format=jsonfm&formatversion=2&prop=info&titles=A|B|C|D|E – the result for me is E, C, B, A, D; i would like A, B, C, D, E [16:49:12] anomie: i'm asking for this because of https://phabricator.wikimedia.org/T139130#2579428 , sometimes it's not trivial to map the input titles to the API result titles [16:53:33] MatmaRex: It's not entirely impossible, but would require preserving the input ordering somewhere and doing a sort later on in ApiQuery while considering what you might do if inputs are subject to normalization or redirect resolution. [16:55:51] For example, if you have input A1|B|C|A2, what happens if A1 and A2 redirect or normalize to the same thing? Or if you have outright repeats like A|B|C|A, for that matter? [16:56:03] anomie: hrmph, okay. any idea what i could do to avoid the problem, other than just querying no more than one title at once? [16:56:19] * anomie is looking at the bug to try to see what the problem exactly is [16:57:11] essentially, titles that are not normalized correctly by mw.Title in javascript, for complicate reasons [17:02:28] MatmaRex: So the problem is that MediaWiki NFC-normalizes the input before the API ever sees it, so the API doesn't tell you about the change, so you can't match up the request with the response. And you can't do NFC normalization on the client because doing that needs relatively huge data tables like https://phabricator.wikimedia.org/diffusion/ELUA/browse/master/engines/LuaCommon/lualib/ustring/normalization-data.lua. Is that right? [17:03:04] yeah [17:12:17] MatmaRex: Hmm. I might be able to do the same sort of thing you hated about https://gerrit.wikimedia.org/r/#/c/305126/ to detect the NFC normalization of the titles for ApiPageSet and output it in the 'normalized' section. [17:15:22] anomie: yeah, i still hate that thing though :( [17:19:37] anomie: i still think that keeping the input order would be the neatest solution. or if that's too difficult, then we could have a map of input_index→normalized_title (in addition to 'normalized', which is input_title→normalized_title) [17:20:47] the latter actually doesn't look difficult to do, assuming that only ApiPageSet::processTitlesArray needs changing [17:24:51] Except it adds another clutter parameter like indexpageids. [17:27:14] eh. indexpageids is for api clients where the creator doesn't know how to iterate over a map. my proposal would be for api clients that are unable to replicate the complete logic of normalizing mediawiki titles. [17:27:41] i wouldn't call it clutter. but it would be a new parameter, yes. [17:28:51] Instead of directly addressing the problem, you're adding clutter to let the client be able to work around it. [17:29:46] what would be directly addressing the problem? bypassing NFC normalization of input, and adding those titles to 'normalized'? i'm not sure if we should ever allow api output to have non-NFC-form text. [17:54:46] anomie: it looks like you'd actually have to bypass normalization both on input and output, since ApiResult::validateValue() looks like it'd normalize it again. i really don't think that is the way to go. [19:33:25] AaronSchulz: do we still need https://phabricator.wikimedia.org/T134554 ? I understand we've decided to go mcrouter option, so we don't actually need to do special work for recent-changes daemon? [19:39:50] any mediawiki hooks fan around? Just had an idea which would be to define interface for each of our hooks with proper signatures [19:39:51] SMalyshev: I'll mark it stalled. If mcrouter works then it can declined. [19:40:02] AaronSchulz: ok, thanks [19:40:03] and have extensions class to implement the hook interfaces, so we have the proper function signatures [19:40:05] (e.g. works in prod) [19:40:50] eg MediaWiki\Hook interface ArticlePurge { function onArticlePurge( WikiPage $page ) } [19:41:30] then in extension class Foo implements MediaWiki\Hook::ArticlePurge { function onArticlePurge( WikiPage $page ) } [19:42:03] and we can then check that the extension implementation is in sync with what MediaWiki pass [19:51:09] That'd be 544 new interfaces, assuming docs/hooks.txt is up to date. And would probably mean updates to every extension using the hook whenever a hook adds parameters, even if the extension doesn't need it. [19:56:18] anomie: yeah that is lame thanks! [19:56:23] abandoning the crazy idea :] [21:02:12] RFC meeting starting now in #wikimedia-office: Schema change for page content language [22:14:24] Hi. We've currently an issue with Proofreadpage deployed with the train. I fixed it sooner, but after careful tests with a wikisource administrator, we detected a side effect. There is a typehint signature update fix at https://gerrit.wikimedia.org/r/#/c/306545/ Could someone review it? (I'd like to then be able to cherry-pick and add it to this evening SWAT) [22:20:10] Dereckson: +2'd [22:20:22] I agree with the follow-up. [22:21:01] I suspect this part of the extension code to be a little old. [22:22:44] the Article/WikiPage split can be kind of confusing [22:24:18] Filled as https://phabricator.wikimedia.org/T143838 [22:26:38] Krinkle / AaronSchulz: could either of you review https://gerrit.wikimedia.org/r/#/c/306325/ ? I'd like to backport/deploy it [22:35:34] one thing about windows...git takes its time [22:43:00] Krinkle: thanks. so you'd be fine with something that converts action=purge links into API requests on a click handler or something? [22:43:03] (in core) [22:43:30] legoktm: I don't think it belongs in core still. Because we don't output links to that in the first place. [22:43:55] I can't stand the form being there and then submitting later. [22:43:58] * AaronSchulz plays in vagrant [22:43:59] It's a fairly tiny effort to do that wherever a link like that is produced. [22:44:19] the alernative being creating a snippet that wikis just copy everywhere? [22:45:34] legoktm: If it's about purging the current page only (e.g. not [purge] links in templates), we could formalise a proper content action "Reload" link, like watch/move/delete etc. and attach the API/reload snippet to that. [22:45:46] Maybe disabled by default and can be enabled somehow. [22:46:28] based on comments on the bugs I think users are mostly concerned about purge links in templates [22:46:34] legoktm: Wikis already have their own snippet for adding a Purge link [22:46:55] Which for the most part have already been updated to use the API [22:47:14] AaronSchulz: If you install such snippet, you can click "Purge" instead of adding ?action=purge to the url bar (which is I assume what you're doing) [22:47:45] https://www.mediawiki.org/wiki/Snippets/Purge_action ? [22:47:58] Right [22:49:04] hm. [22:49:11] I'm not sure we should be making purge more prominent [22:49:25] It doesn't have to be visible by default. [22:49:39] But then again [purge] is visible to everyone now in those templates [22:50:01] Could be a simple snippet to attach a listener to that one as well [22:50:21] We could also provide a parser function that outputs a
that looks like a link that will submit POST to action=purge [22:50:25] {{#purge:title}} [22:50:27] :D [22:50:43] Lots of options, but I'd like to avoid client-side submitting a page on load. [22:51:15] which of those are you okay with in core? :) [23:01:36] legoktm: Site-configurable "purge" action in the menu could be in core. Though I doubt any production site would actually want to enable it (besides dev sites like Vagrant/Beta). {{#Purge}} could be in core too, which template helpers would use. [23:02:01] Listening to arbitrary (or template specific) action=purge links seems like a Common.js thing [23:02:28] Purge_action as a gadget makes sense and is that already on many wikis. [23:02:37] We could add the logic to that gadget perhaps. [23:02:45] And perhaps even hide it by default. Like sysop-show [23:03:26] So this gadget would add "Purge" or "Reload" (like the snippet does now) and also listen for other action=purge links on the page, and some class for hiding them readers. [23:03:36] (or not, if we want to keep it but with the confirmation page) [23:04:18] I don;t buy the argument about documentation needing updating. "Click the purge link" still works just as well. The user will undstand the interface that follows. It's just a confirmation.