[02:32:36] 6MediaWiki-API-Team, 10SUL-Finalization, 10Wikimedia-Site-requests, 5Patch-For-Review: Set $wgCentralAuthCheckSULMigration = true in production - https://phabricator.wikimedia.org/T95735#1202055 (10Dereckson) a:3Legoktm [15:27:16] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7Design, 5Patch-For-Review: keyboard Tab order in OAuth Confirm dialog starts with Cancel - https://phabricator.wikimedia.org/T64763#1203081 (10MarkTraceur) @Jaredzimmerman-WMF it doesn't look like we have a good option, then. The way that tabindex works m... [15:33:10] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7Design, 5Patch-For-Review: keyboard Tab order in OAuth Confirm dialog starts with Cancel - https://phabricator.wikimedia.org/T64763#1203112 (10MarkTraceur) For the record, they gave me two or three ideas for "hacks" that would make the tab index "right" a... [15:38:20] manybubbles: Have you had a chance to create smaller stories? [15:38:44] meeple27: yeah! I think I did that already. [15:38:55] ok cool. I didn't notice them but haven't really looked [15:41:26] I just checked - I hadn't added them to the search team board - only the wikidata query board. Fixed. [15:44:59] ori: I took yet another shot at the Monolog config for prod. I'm not sure if I'm getting any closer to what you were wishing for or not. Input welcome -- https://gerrit.wikimedia.org/r/#/c/191259/ [15:45:38] manybubbles: thanks [15:49:17] bd808: i'll take a closer look but it already looks better at a glance [15:49:41] cool [15:50:45] It is still way more complicated than the ideal, but I don't think I can do much better until we cleanup the use of wfDebug* methods in core & extensions [15:58:58] meeple27, legoktm: We should be about unblocked on https://gerrit.wikimedia.org/r/#/c/182858/, finally, since PS27 removed the problematic wfDeprecated calls (because Wikidata is still dragging their feet on the one issue and because Gather introduced new calls to some of the other methods) and Daniel was satisfied (for now) with PS26 other than that. [16:01:31] anomie: yay [16:01:43] sorry..that wasn't a sarcastic yay [16:01:52] good to hear [16:02:16] great news [16:03:19] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Only show grants that the user has permission to use, to avoid confusion - https://phabricator.wikimedia.org/T94478#1203292 (10MarkTraceur) @Anomie I guess the problem is that if the user ever, in the future, *gains* those rights, then there's no way to work o... [16:03:56] The bad news is that it changed a lot since PS22 when legoktm last reviewed it. [16:05:40] * marktraceur looks at the backlog... [16:07:15] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Split privacy policy message into link and display text - https://phabricator.wikimedia.org/T59457#1203294 (10MarkTraceur) a:3MarkTraceur [16:07:40] marktraceur: how many blockers of https://phabricator.wikimedia.org/T75062 have you poked at so far? [16:09:58] Maybe three? [16:10:23] bd808: I'm picking around the edges to start with, I intend to ask various people what they actually want done this week [16:10:39] excellent plan [16:16:19] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Only show grants that the user has permission to use, to avoid confusion - https://phabricator.wikimedia.org/T94478#1203333 (10csteipp) For history, ux was very anti showing a list of rights, which is how we got to the rights bundles. The ux of showing a summ... [16:16:39] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Split privacy policy message into link and display text - https://phabricator.wikimedia.org/T59457#1203338 (10MarkTraceur) Should I make them two messages as in "one that says 'privacy policy' and another that is the URL" or should I make them two messages as... [16:17:43] 6MediaWiki-API-Team, 10MediaWiki-Internationalization, 10MediaWiki-extensions-OAuth, 7I18n: Split privacy policy message into link and display text - https://phabricator.wikimedia.org/T59457#1203346 (10MarkTraceur) [16:21:50] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Only show grants that the user has permission to use, to avoid confusion - https://phabricator.wikimedia.org/T94478#1203380 (10Anomie) Could do. Although you might have to back-calculate the list of granted grants based on which rights the user has, which were... [16:29:23] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth: Privacy policy text should be aligned with the rest of the text, not outdented - https://phabricator.wikimedia.org/T69051#1203398 (10MarkTraceur) a:3MarkTraceur [16:36:00] anomie: how much has changed? :/ I saw the new errorreporter class [16:39:00] legoktm: I believe PS23 was just a rebase, and it hasn't been rebased since. Most files were touched, but most only because I renamed "defineFoo" to "addFoo". [16:40:41] legoktm: As for major new stuff, there's also ApiContinuationManager and killing of ApiResult::transformFoo in favor of flags to $result->getResultData(). [16:50:08] ok [16:50:27] anomie: do any extensions need updates for that stuff? [16:51:09] legoktm: Not immediately (I kept the old names as @deprecated methods), I'll make patches for them once this is merged to avoid having to do it a third time. [16:53:37] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7I18n: Split privacy policy message into link and display text - https://phabricator.wikimedia.org/T59457#1203500 (10Nemo_bis) [16:54:43] Krinkle: anomie and I are hacking together an OOUI dialog that, upon an action, will call .click() on one of two buttons via jquery. I had made the buttons position: absolute; top: -1000px; left: -1000px; because I was having trouble getting the click() to go through, but now it seems to be working with display: none;. Will display: none; and a click() call be a problem on older browsers or IE or Safari or anything? [16:55:03] (I should say, I'm hacking, anomie is reviewing) [16:55:30] Krinkle: That patch is https://gerrit.wikimedia.org/r/#/c/201230/ [16:56:44] (Krinkle is about to say "don't do that", which I already know, but this is step #1) [17:00:13] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7Design, 5Patch-For-Review: keyboard Tab order in OAuth Confirm dialog starts with Cancel - https://phabricator.wikimedia.org/T64763#1203530 (10TheDJ) I think you can only properly do this by using Javascript to set an initial focus. I guess we should bui... [17:01:50] marktraceur: will check after standp [17:02:54] Fair enough [17:10:37] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7I18n: Split privacy policy message into link and display text - https://phabricator.wikimedia.org/T59457#1203574 (10Nemo_bis) At this point, a possibility is just to make the message `[https://wikimediafoundation.org/wiki/Special:MyLanguage/Privacy_policy/e... [17:15:01] easy: https://gerrit.wikimedia.org/r/#/c/203860/ [17:16:15] thanks bd808 [17:16:22] np [17:22:50] 6MediaWiki-API-Team, 6CA-team, 10MediaWiki-API, 10MediaWiki-User-login-and-signup, and 4 others: App says I'm logged in, but edits are saved from IP - https://phabricator.wikimedia.org/T75086#1203642 (10KLans_WMF) @etonkovidova can you help us repro/check this? [17:25:22] marktraceur: Indeed. This is most definitely medium-high severity technical debt, but should be fine. [17:25:34] marktraceur: However I'd at least try and find a way other than .click() [17:26:03] Krinkle: I have brainwaves about that, but I'd like to do the interface first, since people are actually complaining about that [17:26:05] can you submit the form directly, without jQuery? [17:26:31] Krinkle: How do you mean? [17:26:47] Like...make the ooui buttons the submit/cancel buttons somehow? [17:26:54] Because I tried that already I think [18:00:47] Also I am 93.5% sure that the documentation uses exactly that example (.then( function ( o ) { o.then( function ( p ) { p.then( function () { ... } ); } ); }) [18:00:53] RIP grrrit-wm. [18:00:53] marktraceur: No, I mean instead of calling button.click() call form.submit() [18:00:53] marktraceur: I've seen this exact open/opened pattern before, exactly once in the history of OOjs UI and I remember calling it out there and it was fixed. [18:00:53] Where did you copy it from? [18:00:54] Oh, hm. [18:00:54] Krinkle: I forget, maybe it was the patch that added that other example [18:00:54] That might be an outdated snapshot from the short time it was that way [18:00:54] And someone linked it as helpful documentation of something that isn't documented [18:00:54] Let me look through visualeditor logs. [18:00:54] marktraceur: https://github.com/search?q=%22opening.then(+function%22+@wikimedia&type=Code&utf8=%E2%9C%93 [18:00:55] got it [18:00:55] Krinkle: i think it comes from our docs on mw.org [18:00:55] Krinkle: https://www.mediawiki.org/wiki/OOjs_UI/Windows/Message_Dialogs [18:00:55] Took me a sec. [18:00:55] https://github.com/wikimedia/mediawiki-extensions-TemplateData/blob/3820295f23844f18935259833c59eb9fec35c52f/modules/ext.templateDataGenerator.ui.js#L77-L110 [18:00:55] Use that as example isntead [18:00:55] Note that the indirection of open/opened is strange to begin with but that's for another day [18:00:55] Yeahhhh. [18:00:56] Krinkle: The problem with .submit(), IIRC, is that the submit and cancel buttons have values that indicate the action to take [18:00:56] Which I could emulate by adding hidden inputs but I never got that to work [18:00:56] Maybe it's magically fixed now, I'll try again [18:00:56] marktraceur: what does cancel do [18:00:56] Krinkle: Submits the form with cancel=Cancel basically. [18:00:56] It's the same form, just with cancel=Cancel or submit=Submit depending on what button you use. [18:00:56] Krinkle: The backend will do nothing on "cancel" [18:00:57] marktraceur: I know they both submit the form, but afaik that's an abstraction for non-js purposes. [18:00:57] There's no reason the js interface should submit with cancel [18:00:57] it can probably do that on the client-side [18:00:57] Redirect to some url or something [18:00:57] I'll try to sort out what URL it needs, yeah. [18:00:57] cheesecat, csteipp, ori: Just a friendly reminder that the Q3 review meeting is Wednesday morning and the three of you have not accepted the calendar invite yet. As team/group/project leads during Q3 I think it would be great if you can all make it to the meeting. [18:00:57] bd808: done [18:00:57] :) [18:00:57] Krinkle: But the weird thing is, the form doesn't get submitted with submit() [18:00:57] Like, I append to the form and call $form.submit() but it doesn't go. [18:00:58] Oh, because $.fn.submit doesn't do what I expect it to. [18:00:58] marktraceur: form.submit() not $form.submit() [18:00:58] Right. [18:01:01] Krinkle: It's because I'm a fool, obviously. [18:01:01] I left two elements on the page with the same ID. -.- [18:01:01] But, working now. [18:01:01] $.fn.submit should actually work fine [18:01:01] similar to click() [18:01:01] it will fire virtual events within jQuery but also trigger native [method] behaviour [18:01:01] but only when it exists. [18:01:01] so you might've gotten a non-form [18:01:01] I did. It was a div. [18:01:01] Fixed! [18:19:23] aw crap. [18:19:24] * anomie grrs about T88732 [18:21:05] Keegan|Away: so...there's a good chance any stats I've given you or published on wiki are total crap [18:21:05] Nemo_bis: ^ [18:22:19] I want to smash my head into a wall while this query runs. brb [18:22:52] * marktraceur watches legoktm leave in anticipation [18:23:05] He's walked past like three walls. [18:28:07] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7I18n: Split privacy policy message into link and display text - https://phabricator.wikimedia.org/T59457#1203807 (10csteipp) Also, T64686 is to get rid of this message and replace it, potentially, with a link to the app's privacy policy, if we know what it... [18:49:50] legoktm: thanks for finding out :) [18:49:55] legoktm: http://www.gossamer-threads.com/lists/wiki/foundation/1517?#1517 [18:49:56] > The idea here is that resolving name conflicts is so complicated that we simply defer the issue for now. [18:49:56] yippe :P [18:49:56] s/for now/for the coming decade/ [18:49:58] legoktm: you've been dealing with jenkins too much, you're starting to say yippee :) [18:55:15] Nemo_bis, Keegan|Away: filed as https://phabricator.wikimedia.org/T95927?workflow=create [19:08:55] legoktm: thanks [19:09:12] legoktm: you've got text files [19:11:09] legoktm: will there be stats that aren't crap? [19:11:17] The blog doesn't go out until the morning [19:12:10] Not that I care much about that blog, but it's the "published" whatever. [20:15:02] ori: https://gerrit.wikimedia.org/r/#/c/203432/2 [20:15:03] cheesecat: Are you Aaron? :P [20:15:08] heh [20:15:09] >1) is very complex, and we may not find someone willing to deal with the name conflict resolution issue and take the blame from annoyed users at the same time. [20:15:09] Aaron has been *cat for a few weeks. burritocat was my favorite short term nick so far [20:15:09] bd808: springle said the same [20:15:09] great minds... [20:15:09] * hoo googles burritocat [20:15:09] * hoo is not disappointed [20:15:11] Keegan: I don't know, depends on when someone fixes the database server...or I get access to an up to date one [20:15:12] * cheesecat misses http://www.madmex.com/columbus?location=columbus [20:15:12] Okies. Well, the numbers I'm quoting aren't based on global accounts, it's based on all accounts, and the other figures are from attachments and whatnot, soooo I'll just sit tight. Thanks :) [20:15:16] cheesecat: If you got a bit, I'd like to further talk with you about the job problem on wikidata [20:15:18] which problem? [20:15:18] https://phabricator.wikimedia.org/T92789 [20:15:18] I tried looking at the code myself a bit, but I couldn't figure anything about how abandoned really works deep down [20:15:25] * cheesecat looks [20:15:32] cheesecat: Would be awesome if you could give me any pointers :) [20:15:32] * cheesecat is multitasking too much [20:15:32] hoo: so I tried rebuilding and running a few jobs, but got no errors (and a "true" result) [20:15:32] just ~3 [20:15:32] hoo: are those idempotent, not sure I want to run anymore [20:15:33] (e.g. do they not blindly assume the update hasn't happened yet and do something weird?) [20:15:33] You can't really ruin anything as they revalidate the changed sitleinks with the api before altering anything [20:15:33] so you can just hit of one job 100 times [20:15:36] Keegan: springle says it should be a few hours so I can re-run the stats after that. [20:15:36] legoktm: w00t [20:16:52] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 5Patch-For-Review: OAuth permission screen needs redesign for better usability and comprehension - https://phabricator.wikimedia.org/T75062#1204433 (10MarkTraceur) a:3MarkTraceur [20:24:07] ori: could you review https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/XAnalytics+status:open,n,z ? or is there another person maintaining that extension? [20:26:26] Keegan: what username do you want the log entries and page moves to be associated with? right now it's just 'Maintenance script' [20:27:21] legoktm: hm. What do you suggest? [20:28:38] I could set up a dummy account name [20:28:38] legoktm: ottomata is [20:28:59] Keegan: well keeping the current name means a little less work for me ;) [20:39:23] hoo: https://phabricator.wikimedia.org/T87523 hasn't shown up again right? [20:40:17] legoktm: Not that I know off [20:44:28] hoo|away: I assume T92789 is still reproducible? [20:51:20] ori: Hm.. would you be up to join a perf sprint related to mediawiki core phpunit tests? [20:51:39] 6MediaWiki-API-Team, 6CA-team, 10MediaWiki-API, 10MediaWiki-User-login-and-signup, and 4 others: App says I'm logged in, but edits are saved from IP - https://phabricator.wikimedia.org/T75086#1204620 (10Etonkovidova) I checked it with 2.0-alpha-2015-04-02. My steps: 1. I logged to the apps with my creden... [20:54:49] Krinkle: I'd love to. It depends on when you run it and how long you'll run it for [20:56:26] ori: Yeah, I just made it up on the spot here. But getting a few trained eyes on the matter would help to get things moving. Afterwards it'll hopefully be easier to identify low hanging fruit and for others to pick it up forwards. [20:56:47] Right now it's quite dirty, there's no clear path on where to start scrubbing or cutting things [20:58:21] I imagine mocking file system (vfsStream?) would probably help. And finding a way to cut down our unintended database interactions. It'll be hard to do without also changing code in MediaWiki core, but I'm hoping to find areas where we can make a few big gains in how tests are written and run first. [20:58:23] 6MediaWiki-API-Team, 6CA-team, 10MediaWiki-API, 10MediaWiki-User-login-and-signup, and 4 others: App says I'm logged in, but edits are saved from IP - https://phabricator.wikimedia.org/T75086#1204643 (10bearND) @Etonkovidova Good. I see it used the IP address. That means you can repro the issue with an apk... [20:58:28] ori: I was thinking during the Lyon hackathon or before it. A few days upto a week. 1-2 hours a day. [20:58:59] Krinkle: have you done any profiling of test runs, to see where most time is spent? [20:58:59] you could probably drop 20-30s by making ApiTestCase no use the database by default [20:58:59] not* [20:59:02] parser tests take the most time wall clock [20:59:26] ori: I haven't done flamegraph-style profiling, but we do have test-level profiling. [20:59:54] https://integration.wikimedia.org/ci/job/mediawiki-phpunit-zend/4663/testReport/(root)/ [20:59:54] sort by Duration [21:00:02] https://integration.wikimedia.org/ci/job/mediawiki-phpunit-zend/4665/testReport/%28root%29/ [21:00:26] that particular run was on a dedicated slave and took 8 minutes [21:00:32] under load it's usually 15-21 minutes [21:00:33] on Zend [21:00:58] HHVM is about 4 minutes ideally and 6-8 minutes under load [21:01:15] Of course Precise/Trusty also factors in with regards to other systems having improved. [21:02:12] The Parser being slow is fine, those 4-5 minutes are for granted. [21:02:16] Krinkle: well, even there you can do something -- first, iterate through all parser tests in the test file [21:02:20] group by common options [21:02:28] and then perform the setup code once per group [21:02:45] When we switched from sqlite to mysql, runtime almost doubled. [21:02:56] for Zend. Not for HHVM though. Interestingly. [21:02:57] e.g., there are a bunch of tests with language=ca, no reason not to run those together [21:03:00] ah, hm [21:03:38] Tests that involve Database, get their database setup/torndown every test. And with data providers, every test case. [21:03:52] I imagine that makes a big hit [21:04:10] getting flamegraphs to prove that would be nice [21:04:31] e.g. lots of time spent in setup(), or maybe setup is fine, but individual tests are doing lots of Database::query() [21:06:08] Krinkle: Why do we have so many unused jquery libraries in core [21:06:16] Or at least, mostly unused. [21:06:56] marktraceur: Because *you* haven't removed them yet :P [21:07:32] A few examples? [21:07:50] jquery.form is the one I just found [21:08:12] jquery.hoverIntent is only used by TMH and SMW [21:08:23] And probably not necessary [21:09:17] marktraceur: We don't have a good way to deal with multiple extensions having the same dependency. [21:09:29] composer and npm isolate that stuff and get away with it [21:09:35] but we've got to go publicly in the browser [21:09:42] True. I'd probably go on a rampage to remove it from TMH and SMW, then dump it. [21:09:45] and in RL of course [21:10:22] We could maybe provide some meta data assertions [21:10:31] Like what npm@v3 does for front-end usage [21:11:26] Right now in VE and a few other repos, we check if !registered and then register the third-party library [21:11:39] this means it can easily use the wrong version if another extension provides an old version first [21:11:48] we can give it a version parameter [21:11:53] and then negiotiate [21:12:21] e.g. $rl->maybeRegisterVersionedModule( name, version, Array module ) [21:12:31] if already registered and different version: Throw [21:12:42] if same version, keep that one as-is. [21:12:50] Krinkle: That would be Bad. [21:13:00] Why? [21:13:02] Krinkle: DI also has a newer version of $.validate than core [21:13:15] marktraceur: Well, that is Worse. [21:13:19] Well, yeah. [21:13:33] marktraceur: Whenever DI loads its module, it will blow away whatever core loaded. [21:13:39] It has to use a different library name [21:13:43] which is fine [21:13:52] append an extra file to the file module that renames the propery [21:13:52] Ah, yeah, suppose so [21:14:23] This method would only enforce a resolution server-side for a battle we'd already be fighting in client-side [21:14:58] we can maybe provide a separate requireversion [21:15:08] e.g. version=1.2.1 require='1.2.x' [21:15:27] to allow some flexibility in case one of the extensions is very soon with minor updates. [21:15:58] are we still not able to use a real package manager for JS yet? [21:17:11] and it would keep the newest one after having received all meta data [21:17:11] like npm does [21:17:11] * Krinkle captures nodepad [21:18:52] legoktm: I'm fine with Maintenance script [21:27:57] <^d> 2 [13696ms] at runtime/ext_mysql: slow query: UPDATE /* User::incEditCount 127.0.0.1 */ `user` SET user_editcount=user_editcount+1 WHERE user_id = '' [21:28:26] <^d> 127.0.0.1 is less than useful :) [21:29:06] cheesecat: Yes, it is AFAIK [21:29:42] yeah, I'm seeing weirdness testing around [21:31:10] hoo: are the jobs using the title of a foreign wiki page on wikidatawiki? [21:32:10] https://gerrit.wikimedia.org/r/#/c/203958/ targets one code path where jobs would be popped, not run, not acked, and not logged [21:32:14] cheesecat: They work on the page "entityId" and check "newTitle" against the api of the client wiki (siteId) [21:33:11] what determines the main job title? they seem to depend on the target wiki [21:33:28] We don't set any [21:33:33] Core defaults to the main page [21:33:36] AFAIR [21:34:20] right, and there are enqueued from the triggering wiki [21:34:23] *they are [21:40:21] cheesecat: That's it, doh [21:40:32] > var_dump( Title::makeTitleSafe( 100, 'Forside' ) ); [21:40:32] NULL [21:40:57] Wikidata doesn't have a namespace 100, thus that fails [21:40:57] (that's svwiki) [21:40:57] * from svwiki [21:41:03] hoo: https://gerrit.wikimedia.org/r/#/c/203958/ is fix but kludgy [21:41:17] it should probably just hardcode english in the fallback [21:41:21] * cheesecat changes that too [21:41:34] or at least ns 0 [21:42:32] Ok [21:42:43] Shall I just set a dummy title for the jobs in Wikibase? [21:42:56] newFromText( 'UpdateRepo' ) or so [21:46:55] /me updates JobSpecification [21:47:00] hoo: is it using that? [21:47:37] yeah [21:47:48] > var_dump( Title::makeTitleSafe( 100, 'Forside' ) ); [21:47:48] NULL [21:47:52] doh [21:48:05] $this->title = $title ?: Title::newMainPage(); [21:48:33] Please link the bug in the commit summary :) [21:50:53] is Title::newMainPage() really a sensible default? what if the job automatically edits pages and misfires on the main page? [21:51:04] hoo: https://gerrit.wikimedia.org/r/#/c/203967/ [21:51:13] oh, you're removing that :D [21:51:33] no way to edit that page ;) [21:53:41] legoktm: https://gerrit.wikimedia.org/r/#/c/203514/ trivial [21:54:24] +2'd [21:54:54] cheesecat: +2ed both, thanks [22:00:24] cheesecat: Ok, ^d has a better idea for a fallback title... want to amend? [22:00:36] * hoo would like to ahve that ready for SWAT tomorrow [22:08:13] 10MediaWiki-Core-Team, 7HHVM, 5MW-1.25-release, 5Patch-For-Review: Revert HHVM tag hiding hack - https://phabricator.wikimedia.org/T1205#1205058 (10Legoktm) 5Open>3Resolved [22:10:37] ^d: https://gerrit.wikimedia.org/r/#/c/203432/ [22:13:22] <^d> Yeah I was just looking at it [22:15:38] cheesecat: I'll backport and sign up for the SWAT in 45 min. if that's ok with you [22:15:49] We're loosing data due to this... :/ [22:16:01] (although that can be fixed by bots) [22:16:45] sure [23:25:14] ori: are you on 3? [23:33:04] 6MediaWiki-API-Team, 6CA-team, 10MediaWiki-API, 10MediaWiki-User-login-and-signup, and 4 others: App says I'm logged in, but edits are saved from IP - https://phabricator.wikimedia.org/T75086#1205359 (10Etonkovidova) Re-checked with 2.0-alpha-2015-04-13 - all edits are attributed to a logged in user. {F11... [23:51:01] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7I18n: Split privacy policy message into link and display text - https://phabricator.wikimedia.org/T59457#1205368 (10MarkTraceur) @csteipp well, in that case, we'd need to support arbitrary URLs, which are presumably redirected to per-language versions on th... [23:57:00] 6MediaWiki-API-Team, 10MediaWiki-extensions-OAuth, 7I18n: Split privacy policy message into link and display text - https://phabricator.wikimedia.org/T59457#1205379 (10MarkTraceur) Actually, as a matter of fact, the helpful skin class has a privacyLink method that I'll use instead. Brilliant. If we implemen...