[00:02:23] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Flow: Flow isAllowed gets actual revision text before it is needed - https://phabricator.wikimedia.org/T172025#3483243 (10Mattflaschen-WMF) [00:02:40] 10Collaboration-Team-Triage, 10Flow, 10Dumps-Generation, 10MW-1.30-release-notes (WMF-deploy-2017-07-11_(1.30.0-wmf.9)), 10Patch-For-Review: Make flow dumps run faster - https://phabricator.wikimedia.org/T164262#3227664 (10Mattflaschen-WMF) a:05Mattflaschen-WMF>03Ariel [00:04:10] 10Collaboration-Team-Triage, 10Flow, 10Community-Tech, 10XTools, 10User-Matthewrbowker: Add Flow contributions to XTools - https://phabricator.wikimedia.org/T136950#3483263 (10MusikAnimal) [00:06:45] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-RC-Page: [wmf.11] "Number of edits to show in recent changes ..." form accepts invalid numbers - https://phabricator.wikimedia.org/T172026#3483267 (10Etonkovidova) [00:07:04] 10Collaboration-Team-Triage, 10Flow, 10Community-Tech, 10XTools, 10User-Matthewrbowker: Add Flow contributions to XTools - https://phabricator.wikimedia.org/T136950#3483281 (10Mattflaschen-WMF) @Matthewrbowker There are dumps, but you'd currently have to maintain your own DB imported from the XML. I won... [00:07:54] mooeypoo: RoanKattouw: https://phabricator.wikimedia.org/T172026 -- kind of an amusing bug (though typical...). Please take a look [00:09:35] 10Collaboration-Team-Triage, 10Flow, 10Data-Services, 10labs-sprint-119: Make Flow database available / accessible on Labs/Tools - https://phabricator.wikimedia.org/T69397#3483282 (10Mattflaschen-WMF) @Ariel I wonder if importing from the dumps would be a good way to solve this. It's not the only approach... [00:10:34] Ugh, I fixed this for hours but not for days [00:10:51] etonkovidova: Can you confirm that this works correctly for &hours= ? [00:11:00] Sorry, I mean &days= [00:11:41] RoanKattouw: I will re-check, but the validation for days is much better than for # of changes [00:11:52] That's because I fixed the days validation this week :D [00:11:56] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10Design, 10MW-1.30-release-notes (WMF-deploy-2017-07-25_(1.30.0-wmf.11)), and 2 others: Integrate 'Number of Changes Selector' in the new filters for ... - https://phabricator.wikimedia.org/T162786#3483287 [00:12:01] And I didn't do anything about the limit validation [00:13:11] OK the old interface does cap days at 30 correctly, but the new UI doesn't [00:13:37] And the old interface handles negative limits correctly too (the new UI doesn't), but it doesn't seem to cap the limit because &limit=123456789 times out for me [00:14:00] RoanKattouw: yup, &days are fine [00:17:26] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-RC-Page: [wmf.11] "Number of edits to show in recent changes ..." form accepts invalid numbers - https://phabricator.wikimedia.org/T172026#3483267 (10Catrope) I recently fixed the validation of the days parameter in the old U... [00:20:41] 10Collaboration-Team-Triage, 10Flow, 10Community-Tech, 10XTools, 10User-Matthewrbowker: Add Flow contributions to XTools - https://phabricator.wikimedia.org/T136950#3483309 (10Matthewrbowker) @Mattflaschen-WMF I don't think maintaining our own databases would be a very good use of time or resources. The... [00:24:59] 10Collaboration-Team-Triage, 10Notifications: No notification when someone mentions you on a page and their signature is in a template - https://phabricator.wikimedia.org/T67910#694841 (10Catrope) >>! In T67910#3483151, @XXN wrote: > I just saw [[ https://www.wikidata.org/w/index.php?title=Wikidata:Requests_fo... [00:25:02] etonkovidova, sticky works? [00:25:14] I mean, I should sound more confident. etonkovidova - sticky works now! [00:25:55] mooeypoo: Whether you sound confident or cautious, she's going to crush your dreams just as hard, so you might as well sound confident [00:26:29] 10Collaboration-Team-Triage, 10Edit-Review-Improvements-RC-Page, 10Epic: Graduate New Filters for Edit Review on RC page out of beta on Recent Changes - https://phabricator.wikimedia.org/T157642#3483322 (10Krinkle) [00:26:33] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-RC-Page, 10MW-1.30-release-notes, 10Patch-For-Review, 10User-notice-collaboration: Unify the "user registration" and "experience level" groups - https://phabricator.wikimedia.org/T165160#3483320 (10Krinkle) 05Resolved... [00:26:34] etonkovidova - the professional dream crusher. [00:26:43] RoanKattouw, this should be bash'ed. [00:27:42] Also, etonkovidova RoanKattouw "amusing bug (though typical)" -- I can't decide if this is an ominous warning, or an insult. [00:28:03] mooeypoo: be more specific sticky what? :) Legend still gets uncollapsed with each change of filters, sigh [00:28:08] 10Collaboration-Team-Triage, 10Edit-Review-Improvements-RC-Page, 10Epic: Graduate New Filters for Edit Review on RC page out of beta on Recent Changes - https://phabricator.wikimedia.org/T157642#3483333 (10Catrope) [00:28:12] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-RC-Page, 10MW-1.30-release-notes, 10Patch-For-Review, 10User-notice-collaboration: Unify the "user registration" and "experience level" groups - https://phabricator.wikimedia.org/T165160#3483331 (10Catrope) 05Open>03... [00:28:14] RoanKattouw, but I do like the fact it added commas correctly :D :D :D [00:28:27] mooeypoo: the user settings for days/changes seems to be ok [00:28:33] etonkovidova, that should change too soon (I think it should be merged?) but I am talking about days/limit [00:28:45] that should remember your choice + not get overridden when you go to defaults, etc [00:28:51] or load a new saved query or anything like that [00:28:54] mooeypoo: If you're talking about https://gerrit.wikimedia.org/r/#/c/368358/ , that one is very -1ed [00:28:56] whatever you chose in those two should stick [00:29:10] RoanKattouw, oh, I didn't notice [00:29:35] but I was talking aobut this https://gerrit.wikimedia.org/r/#/c/368521/ [00:29:37] which is merged [00:29:47] That one fixed the legend state [00:30:07] etonkovidova, the legend collapsing/expanding should be fixed now........ [00:30:24] mooeypoo: yes, it is fixed - in beta [00:30:38] RoanKattouw, I believe you regarding ->plain() I just don't get it. What's ->parse() for? [00:35:22] RoanKattouw, I answered comments + submitted a new patchset. [00:35:36] the .contents() business is just an OOUI hack to get the mw.msg() to render HTML properly [00:35:55] the label: accepts string (and then displays raw html) or jQuery object, so I have to make it a jQuery object so it gets properly parsed. [00:36:15] And I didn't want to wrap it with a span unnecessarily; it was just a hack to get things parsed [00:38:02] OK [00:38:06] Re ->plain() vs ->parse() [00:38:15] You are right that normally ->parse() would be used here [00:38:25] ->parse() means "interpret the message as wikitext, parse it, and give me HTML" [00:38:48] However, in this case the code is using Html::rawElement() to build *wikitext*, not HTML [00:38:53] Which is crazy, but that's how it is [00:39:14] You can tell because the result gets passed to addWikiText(), which as you might expect takes a wikitext string as its input, parses it, and outputs the resulting HTML to the page [00:39:37] So if you use ->parse(), that's conceptually incorrect because the message will be parsed twice (once by ->parse(), the second time by addWikiText()) [00:39:52] oh [00:40:00] In practice it doesn't matter because "Foo" is the same before and after the WT->HTML parse [00:40:04] OK, that makes sense [00:40:05] yeah [00:40:06] But imagine it was [[Foo|Bar]] [00:40:24] RoanKattouw, but that also means that this message CAN be '''Foo''' [00:40:31] The first parse makes that Bar or something along those lines [00:40:32] not just [00:40:38] ... wait, NO... jQuery won't have that [00:40:46] forget it. it needs to get parsed in the front end too. [00:40:49] The second parse makes that <a href="/wiki/Foo" class="new">Bar</a> [00:40:57] Yeah [00:41:16] So the use of ->plain() here makes sure it doesn't get parsed at all [00:41:28] Note that not even ->text() is used! That would at least have expanded {{PLURAL}} etc [00:41:41] Yeah, OK, that makes sense. I didn't think about that. [00:41:48] Or well, bad example because that requires params, but let's say {{SITENAME}} [00:42:04] It wouldn't hurt to do that in this case, but it's also unnecessary because addWikiText() will expand too [00:42:24] And yes the message could be '''Foo''' and that would work [00:42:29] yeah [00:42:41] But it's special because the result of that parse is itself valid wikitext that parses to itself [00:42:42] But then it wouldn't in the front end, when I replace it wth a button [00:42:57] Are you using this message in the front-end too? [00:43:15] If so, this message is terrible because it only works if it's a wikitext/HTML polyglot message [00:43:36] (I mean, that whole bit of code handling this message in PHP is kinda terrible anyway) [00:43:52] It would make much more sense to use ->parse() and then addHTML() instead of addWikiText() [00:44:01] Feel free to fix that, that would make that whole block of code less insaen [00:44:38] Cause now that I think about it there's no good reason at all to do what that code is doing [00:45:27] Because, you know, if we're going to have code that it takes 10 minutes to explain to people, we should at least have a reason for it, and we don't [00:46:02] (Plus not many reviewers seem to notice format mismatches like this) [00:46:25] RoanKattouw, I am, when I replace the title with a button [00:46:39] RoanKattouw, no no just the title [00:46:41] not the whole blob [00:47:01] Just this: https://gerrit.wikimedia.org/r/#/c/368478/2/languages/i18n/en.json [00:47:28] RoanKattouw, wait, I'm confused. [00:47:44] We are adding two things: A title (which I added) and the contents of a wiki page [00:47:49] addWikiText() is for the wiki page [00:48:03] I mean it's a message but it's usually in a wiki page [00:48:16] so doesn't it make sense to use addWikiText() ? [00:48:45] RoanKattouw, and since we're wrapping it, I can't add one and then the other [00:49:42] so this whole addWikiText() is adding the entire block... so if it is required for the 'recentchangestext' (which is nothing in i18n and overridden locally within a wiki page, so that makes sense) then what should I even change? [00:49:45] Where is the contents of a wiki page? [00:49:52] MediaWiki:recentchangestext [00:49:53] If you mean MediaWiki:recentchangestext, that *is* a message [00:49:56] It is [00:50:01] Which means you can call ->parse() on it [00:50:09] So, right now, the wikitext is parsing is the whole div structure [00:50:10] but since it's effectively a wiki page, it's written as such -- can contain whatever [00:50:22] We could instead parse the messages, then just generate the div structure and output that as HTML instead of wikitext [00:50:36] The difference being that 1) you don't run the div structure through the parser and 2) the code becomes more sane and readable [00:50:51] What's the difference between addWikiText and parsing a blob of wikitext and adding it? [00:50:57] 10Collaboration-Team-Triage, 10Flow, 10Community-Tech, 10XTools, 10User-Matthewrbowker: Add Flow contributions to XTools - https://phabricator.wikimedia.org/T136950#3483370 (10Mattflaschen-WMF) >>! In T136950#3483309, @Matthewrbowker wrote: > @Mattflaschen-WMF I don't think maintaining our own databases... [00:51:06] It'll functionally be the same, but the code won't be as confusing [00:51:13] And the difference is what gets parsed: [00:51:17] in my version only the messages get parsd [00:51:27] in hte current code, all the divs that we generate around them get parsed too [00:51:43] I think you can just change addWikiText to addHTML and change plain to parse, that should do it [00:51:54] * mooeypoo nods [00:51:59] ok let me change and see if that's what you meant [00:52:14] In theory you have to do something about the newlines surrounding $content, but I'm not sure why those are even there. It's HTML, they'll be ignored, right? [00:52:32] Unless there is a second newline and then it magically becomes a

Because Wikitext? But that would be crazy [00:53:12] I don't think that whoever put those newlines there thought things through very well, they seem unnecessary [00:53:32] https://gerrit.wikimedia.org/r/#/c/368358/8/includes/specials/SpecialRecentchanges.php [00:53:33] ^ ? [00:53:55] hm good point about the newlines [00:54:10] LGTM apart from my rant about the newlines [00:54:41] Also you now don't have to pass the true and false params anymore, those were for addWikiText [00:54:43] I can take them off but I'm not sure what that'll do to the pre-RCFilters version [00:54:46] $lineStart and $interface [00:55:20] Oooh but wait, I just realized you did something here that isn't quite right [00:55:24] Do you see the dir and lang attributes [00:55:40] If the $contentTitle thing is added, they're wrong [00:55:54] and should be applied to collapsible-content instead [00:55:55] why [00:56:00] oh [00:56:03] that's right [00:56:18] Because recentchangestext is ->inContentLanguage() but other-review-tools is not [00:56:50] Sorry :/ that makes it more complicated [00:57:28] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist: Integrate standard Watchlist management links into new UX - https://phabricator.wikimedia.org/T172030#3483372 (10jmatazzoni) [00:57:31] But otherwise it's wrong and I'm sure you of all people would appreciate that
Other review tools:
[hebrew text]
is bad news [00:57:46] yeah [00:57:47] hang on [01:00:20] RoanKattouw, https://gerrit.wikimedia.org/r/#/c/368358/10/includes/specials/SpecialRecentchanges.php [01:01:14] wait [01:01:45] I like the way you've done that, adding some nitpicks inline [01:01:50] RoanKattouw, https://gerrit.wikimedia.org/r/#/c/368358/11/includes/specials/SpecialRecentchanges.php [01:01:54] updated [01:02:06] I added the var and forgot to array_merge it to the wrapper too [01:02:23] Yeah well spotted [01:02:31] RoanKattouw, so the issue with T172025 is that we load the external content very early (when the revisions are still in row form), and it's also batched (including the calls to ExternalStore::batchFetchFromURLs). [01:02:32] T172025: Flow isAllowed gets actual revision text before it is needed - https://phabricator.wikimedia.org/T172025 [01:03:25] mooeypoo: Added comments inline. BTW, DYK that you can use + with arrays? It leads to very bad results for numerical keys, but for this case it should work. That'd also let you use += [01:04:03] At least, I confirmed it's sometimes batched. [01:04:04] RoanKattouw, updated [01:04:07] RoanKattouw, so right now I'm figuring out whether to make it an option (preferable, but I'm working on how) or to drop the batching and just do pure lazy-loading on an individual revision basis. [01:04:11] matt_flaschen: Hmm so should it perhaps be lazy-loading the content? Or would that break batching? [01:04:17] RoanKattouw, yeah but I know it has some weird behavior [01:04:23] so I just go with straight-up array_merge usually [01:05:06] RoanKattouw, yeah, that's my dilemma. I could just do straight lazy loading in getContentRaw, but then I think I'd have to lose the batching. [01:06:07] RoanKattouw, https://gerrit.wikimedia.org/r/#/c/368358/11..12/includes/specials/SpecialRecentchanges.php [01:06:11] matt_flaschen: Hmm surely this bites us in other cases too, like when rendering history pages? [01:06:21] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist: Integrate standard Watchlist management links into new UX - https://phabricator.wikimedia.org/T172030#3483393 (10jmatazzoni) [01:06:34] Perhaps the default should be to lazy-load content, and maybe there should be a utility for batch-loading it when explicitly requested? [01:08:58] mooeypoo: OK, I've +2ed the patch. Could you respond to Pau on T166919 with a "never mind" and a screenshot? [01:08:59] T166919: Put community-defined 'related links' into a collapsible panel - https://phabricator.wikimedia.org/T166919 [01:09:05] RoanKattouw, not really because we show the content on the history pages. [01:09:15] Ah, what [01:09:30] It's kind of nice, I think. [01:09:32] RoanKattouw, https://www.mediawiki.org/w/index.php?title=Project_talk:Sandbox/Flow_test&action=history . [01:09:34] RoanKattouw, should I, or should we just wait for him to notice it? [01:09:35] :D :D [01:09:49] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10Design, 10MW-1.30-release-notes (WMF-deploy-2017-07-25_(1.30.0-wmf.11)), and 2 others: Integrate 'Number of Changes Selector' in the new filters for ... - https://phabricator.wikimedia.org/T162786#3483395 [01:09:49] mooeypoo: I guess in ~15 mins you can just link to beta labs :D [01:09:52] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist: Integrate standard Watchlist management links into new UX - https://phabricator.wikimedia.org/T172030#3483396 (10jmatazzoni) [01:10:22] matt_flaschen: Oh, right, for the fake edit summaries that are really truncated content [01:10:35] RoanKattouw, I'm thinking of adding an option ('options' as in the queries/options arguments). It's never documented what the options are, so... [01:10:52] of course, why would it be [01:12:43] RoanKattouw, I'll try that this weekend. [01:13:03] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist: Integrate standard Watchlist management links into new UX - https://phabricator.wikimedia.org/T172030#3483398 (10jmatazzoni) [01:13:07] * RoanKattouw mumbles something about not working on weekends [01:13:29] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10Patch-For-Review: Put community-defined 'related links' into a collapsible panel - https://phabricator.wikimedia.org/T166919#3483399 (10Mooeypoo) >>! In T166919#3480673, @Pginer-WMF wrote: >>>! In T166... [01:14:50] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10Patch-For-Review: Put community-defined 'related links' into a collapsible panel - https://phabricator.wikimedia.org/T166919#3483401 (10Mooeypoo) By the way -- it is **next to** the 'saved filters' but... [01:15:40] Speaking of which -- have a good one! I'm off for the weekend [01:15:49] mooeypoo, you too. [01:31:42] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist: Rename 'Mark all pages as Visited" button to "Mark all changes as Seen" and put in the new UI style - https://phabricator.wikimedia.org/T171121#3483419 (10jmatazzoni) On the button... [01:55:40] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist, 10Easy: Small language tweak in 'Changes to show' menu - https://phabricator.wikimedia.org/T172031#3483429 (10jmatazzoni) [01:55:55] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist, 10Easy: Small language tweak in 'Changes to show' menu - https://phabricator.wikimedia.org/T172031#3483443 (10jmatazzoni) [01:55:57] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10Design, 10MW-1.30-release-notes (WMF-deploy-2017-07-25_(1.30.0-wmf.11)), and 2 others: Integrate 'Number of Changes Selector' in the new filters for ... - https://phabricator.wikimedia.org/T162786#3174591 [01:57:34] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist, 10Easy: Small language tweak in 'Changes to show' menu - https://phabricator.wikimedia.org/T172031#3483429 (10jmatazzoni) [02:02:23] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Edit-Review-Improvements-Integrated-Filters, 10MediaWiki-Watchlist, 10Easy: Small language tweak in 'Changes to show' menu - https://phabricator.wikimedia.org/T172031#3483449 (10Catrope) Do we also want to work "Number of" into this message? [07:31:27] 10Collaboration-Team-Triage, 10Notifications: No notification when someone mentions you on a page and their signature is in a template - https://phabricator.wikimedia.org/T67910#3483513 (10Mbch331) Yes, this is the same issue. The signature clearly isn't the default signature Wikimedia would produce. (The (ple... [07:42:16] 10Collaboration-Team-Triage (Collab-Team-Q1-Jul-Sep-2017), 10Flow: Flow isAllowed gets actual revision text before it is needed - https://phabricator.wikimedia.org/T172025#3483514 (10ArielGlenn) [07:43:02] 10Collaboration-Team-Triage, 10Flow, 10Dumps-Generation, 10MW-1.30-release-notes (WMF-deploy-2017-07-11_(1.30.0-wmf.9)), 10Patch-For-Review: Make flow dumps run faster - https://phabricator.wikimedia.org/T164262#3483515 (10ArielGlenn) a:05Ariel>03ArielGlenn [07:47:36] 10Collaboration-Team-Triage, 10Flow, 10Data-Services, 10labs-sprint-119: Make Flow database available / accessible on Labs/Tools - https://phabricator.wikimedia.org/T69397#713063 (10ArielGlenn) There's already replication to WMF Cloud for most dbs; I'd prefer that we add the Flow db to that workflow. Amon... [07:48:55] 10Collaboration-Team-Triage, 10Flow, 10Data-Services, 10labs-sprint-119: Make Flow database available / accessible on Labs/Tools - https://phabricator.wikimedia.org/T69397#3483521 (10ArielGlenn) @Mattflaschen-WMF P.S. The 'Ariel' user exists only for purposes of the CoC committee; they needed a non WMF acc... [10:10:46] 10MediaWiki-Watchlist, 10Wikidata, 10TestMe: I see Wikidata entries in the watchlist in hewiki, but not in enwiki or cswiki - https://phabricator.wikimedia.org/T110825#3483546 (10matej_suchanek) @IKhitron: please #testMe. [12:36:22] 10MediaWiki-Watchlist, 10Wikidata, 10TestMe: I see Wikidata entries in the watchlist in hewiki, but not in enwiki or cswiki - https://phabricator.wikimedia.org/T110825#3483626 (10IKhitron) Sorry, @matej_suchanek, what do you mean? [14:37:45] 10MediaWiki-Watchlist, 10Wikidata, 10TestMe: I see Wikidata entries in the watchlist in hewiki, but not in enwiki or cswiki - https://phabricator.wikimedia.org/T110825#3483778 (10matej_suchanek) Sorry, I misread the title. (I thought you could help in hewiki but that is not the place where the problem was.)... [15:36:27] 10MediaWiki-Watchlist, 10DBA, 10Wikimedia-General-or-Unknown, 10Wikimedia-log-errors: User with 40000 entries in their Watchlist cannot access it on Commons anymore: Database error - https://phabricator.wikimedia.org/T171898#3483825 (10Aklapper) > @zhuyifei1999 added a project: #DBA. @zhuyifei1999: What do... [16:57:25] 10MediaWiki-Watchlist: Allow seeing all changes since last visit directly from Special:Watchlist - https://phabricator.wikimedia.org/T171717#3483951 (10Aklapper) [17:16:15] 10MediaWiki-Watchlist, 10DBA, 10Wikimedia-General-or-Unknown, 10Wikimedia-log-errors: User with 40000 entries in their Watchlist cannot access it on Commons anymore: Database error - https://phabricator.wikimedia.org/T171898#3483969 (10zhuyifei1999) >>! In T171898#3483825, @Aklapper wrote: > @zhuyifei1999:... [20:24:23] 10Collaboration-Team-Triage, 10Notifications: No notification when someone mentions you on a page and their signature is in a template - https://phabricator.wikimedia.org/T67910#3484077 (10Quiddity) But that signature isn't coming from a //template//, is it? (Custom signatures are fine - the only problem (for... [20:38:18] (03CR) 10jenkins-bot: Localisation updates from https://translatewiki.net. [extensions/Echo] - 10https://gerrit.wikimedia.org/r/368564 (owner: 10L10n-bot)