From ddd391b6dbf0f0ae985adf28fff13cb9619ac667 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bartosz=20Dziewo=C5=84ski?= Date: Sun, 31 Jul 2022 03:36:54 +0200 Subject: [PATCH] Ignore "tracked" templates at the beginning of comments This improves the behavior when replying to these comments and the message snippets shown in notifications. Bug: T313097 Change-Id: Ia10400472c9e999fa526c7437a03b72461c37b74 --- includes/CommentUtils.php | 2 + modules/utils.js | 2 + .../en-big-oldparser-formattedreply.html | 48 +++++++++---------- .../en-big-oldparser-getHTML.json | 24 +++++----- .../en-big-oldparser-getText.json | 24 +++++----- .../en-big-oldparser/en-big-oldparser.json | 30 ++++++------ .../en-big-parsoid-getHTML.json | 24 +++++----- .../en-big-parsoid-getText.json | 24 +++++----- .../en-big-parsoid-threadItemsHtml.json | 30 ++++++------ .../cases/en-big-parsoid/en-big-parsoid.json | 30 ++++++------ tests/cases/sr-ec/sr-ec.json | 2 +- tests/cases/sr-el/sr-el.json | 2 +- .../tracked-template-getHTML.json | 2 +- .../tracked-template-getText.json | 2 +- .../tracked-template-transcludedFrom.json | 4 +- .../tracked-template/tracked-template.json | 45 +++++++++-------- 16 files changed, 149 insertions(+), 146 deletions(-) diff --git a/includes/CommentUtils.php b/includes/CommentUtils.php index c94e28791..e32a130da 100644 --- a/includes/CommentUtils.php +++ b/includes/CommentUtils.php @@ -153,6 +153,8 @@ class CommentUtils { strtolower( $node->tagName ) === 'hr' || // {{outdent}} templates DOMCompat::getClassList( $node )->contains( 'outdent-template' ) || + // {{tracked}} templates (T313097) + DOMCompat::getClassList( $node )->contains( 'mw-trackedTemplate' ) || // Wikitext definition list term markup (`;`) when used as a fake heading (T265964) ( strtolower( $node->nodeName ) === 'dl' && diff --git a/modules/utils.js b/modules/utils.js index 1361b950d..87f0acc2e 100644 --- a/modules/utils.js +++ b/modules/utils.js @@ -117,6 +117,8 @@ function isCommentSeparator( node ) { node.tagName.toLowerCase() === 'hr' || // {{outdent}} templates node.classList.contains( 'outdent-template' ) || + // {{tracked}} templates (T313097) + node.classList.contains( 'mw-trackedTemplate' ) || // Wikitext definition list term markup (`;`) when used as a fake heading (T265964) ( node.nodeName.toLowerCase() === 'dl' && diff --git a/tests/cases/en-big-oldparser/en-big-oldparser-formattedreply.html b/tests/cases/en-big-oldparser/en-big-oldparser-formattedreply.html index 55839ccda..05b1087a5 100644 --- a/tests/cases/en-big-oldparser/en-big-oldparser-formattedreply.html +++ b/tests/cases/en-big-oldparser/en-big-oldparser-formattedreply.html @@ -358,8 +358,8 @@ Tag: Rescuing 14 sources and tagging 0 as dead. #IABot (v2.0beta15)
Thank you it helped, I applied similar tweaks descibred there (in the detailed settings changing to 30 days and enabling 1000 entries as maximum). though, still I don't have 30 days, I assume mainly because of the 1000 entry limitation (I don't know where would be the url to tweak it higher). Thus practically I could go back two weeks, so my initial problem has been solved (going back between 4-7 days)...maybe as an important note for the others or the developers, even this worked only by unchecking the "Expand watchlist to show all changes, not just the most recent" in the Advanced Options...(initially at the first tweak attempt, I automatically checked this box assuming it is essential, but anything written above did not work until it was unchecked, ironically it had a contraproductive effect despite it's name...(KIENGIR (talk) 10:39, 2 July 2019 (UTC))[(discussiontools-replylink)]

(discussiontools-topicsubscription-button-subscribe-label)Issues with alerts, June 2019
(discussiontools-topicheader-latestcomment: 1562112120)(discussiontools-topicheader-commentcount: 93)(discussiontools-topicheader-authorcount: 20)

Missing notification icons in MonoBook

-
Tracked in Phabricator
Task T226503
-

I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503. Suffusion of Yellow (talk) 19:52, 25 June 2019 (UTC)[(discussiontools-replylink)] +

Tracked in Phabricator
Task T226503
+

I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503. Suffusion of Yellow (talk) 19:52, 25 June 2019 (UTC)[(discussiontools-replylink)]

I'm getting it in MonoBook too. The appropriate CSS rules are present in the stylesheets: 
.oo-ui-icon-bell, .mw-ui-icon-bell:before {
     background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=bell&format=rasterized&lang=en&skin=monobook);
@@ -396,8 +396,8 @@ Tag: Rescuing 14 sources and tagging 0 as dead. #IABot (v2.0beta15)

in your meta:Special:MyPage/global.css. Suffusion of Yellow (talk) 19:54, 29 June 2019 (UTC)[(discussiontools-replylink)]

Suffusion of Yellow, now you're talking my language. It seems to work. Thank you. Bishonen | talk 20:20, 29 June 2019 (UTC).[(discussiontools-replylink)]

Excessive width on monobook

-
Tracked in Phabricator
Task T226594
-

So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosflux Talk 03:14, 26 June 2019 (UTC)[(discussiontools-replylink)] +

Tracked in Phabricator
Task T226594
+

So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosflux Talk 03:14, 26 June 2019 (UTC)[(discussiontools-replylink)]

Merged to phab:T226594. — xaosflux Talk 03:41, 26 June 2019 (UTC)[(discussiontools-replylink)]
Thank you. Just noticed this, and thought it was a broken ref spilling across the page I was on! Lugnuts Fire Walk with Me 06:54, 26 June 2019 (UTC)[(discussiontools-replylink)]
@@ -442,8 +442,8 @@ Tag: Rescuing 14 sources and tagging 0 as dead. #IABot (v2.0beta15)
@DuncanHill: Ideally, that should go in Special:MyPage/monobook.css instead of Special:MyPage/common.css, not I think it will make a big difference. Suffusion of Yellow (talk) 22:34, 27 June 2019 (UTC)[(discussiontools-replylink)]
Thanks again, have moved it over. Seems to be much the same effect. DuncanHill (talk) 22:40, 27 June 2019 (UTC)[(discussiontools-replylink)]

Message & notification icons in Modern skin

-
Tracked in Phabricator
Task T226684
-
Modern skin icons.jpg
+
Tracked in Phabricator
Task T226684
+
Modern skin icons.jpg

The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4). Nthep (talk) 14:52, 27 June 2019 (UTC)[(discussiontools-replylink)]

@@ -617,8 +617,8 @@ Evolutionary history of life · ‎Timeline of the evolutionary ... · ‎Earlie
This is not so much a VPT matter as a question for WP:BOTREQ - and I see that an identical thread has been posted at WT:BOTREQ, contrary to WP:MULTI. --Redrose64 🌹 (talk) 23:09, 3 July 2019 (UTC)[(discussiontools-replylink)]
To answer the technical question KAVEBEAR, no - assuming this phrase appears in the source text it would require creating another version of the source text for each page (which yes a bot could do, but that is how it would do it). The only way around that would have been if the name was actually a template that could be changed once. — xaosflux Talk 13:19, 4 July 2019 (UTC)[(discussiontools-replylink)]

(discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]Stuck tooltips
(discussiontools-topicheader-latestcomment: 1562284320)(discussiontools-topicheader-commentcount: 3)(discussiontools-topicheader-authorcount: 2)

-
Tracked in Phabricator
Task T226983
-

Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June [8]. Any help appreciated as this is currently on the main page in the In the News section. Espresso Addict (talk) 23:34, 4 July 2019 (UTC)[(discussiontools-replylink)] +

Tracked in Phabricator
Task T226983
+

Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June [8]. Any help appreciated as this is currently on the main page in the In the News section. Espresso Addict (talk) 23:34, 4 July 2019 (UTC)[(discussiontools-replylink)]

@Espresso Addict: It's not just that one page. In fact, I'm not sure that the preview has updated for any page since June 28. See phab:T227033. Suffusion of Yellow (talk) 23:48, 4 July 2019 (UTC)[(discussiontools-replylink)]
Thanks. At least someone is hopefully looking into the issue. Espresso Addict (talk) 23:52, 4 July 2019 (UTC)[(discussiontools-replylink)]
@@ -895,9 +895,9 @@ Evolutionary history of life · ‎Timeline of the evolutionary ... · ‎Earlie
Note: This might not be isolated to Wikimedia or Tools. I just got the identical error message at Find A Grave. On second try, Find a Grave loaded. — Maile (talk) 23:26, 10 July 2019 (UTC)[(discussiontools-replylink)]

(discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]XTools
(discussiontools-topicheader-latestcomment: 1562867400)(discussiontools-topicheader-commentcount: 6)(discussiontools-topicheader-authorcount: 2)

-
Tracked in Phabricator
Task T207959
+
Tracked in Phabricator
Task T207959
Tracked in Phabricator
Task T182182
-

I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved? GiantSnowman 15:27, 10 July 2019 (UTC)[(discussiontools-replylink)] +

I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved? GiantSnowman 15:27, 10 July 2019 (UTC)[(discussiontools-replylink)]

@GiantSnowman: The limit is there to prevent long-running queries that likely wouldn't finish, and would unnecessarily slow down XTools for everyone else. I can try increasing it a little bit, but we have to have some sort of sane limit. phab:T182182 is about analyzing the most recent 350,000 edits, but I suspect this wouldn't really help because in theory we'd still have to scan all of your contributions to get the most recent 350,000. The issue with Pages Created, specifically, is tracked at phab:T207959. One idea is to use the page creation log (phab:T221730), which is fast, but it would only produce pages you created going back to June 2018.

It's a tough problem to solve. We have to balance satisfying the needs of our users, such as yourself, while protecting stability and preventing unrealistic queries from being ran. This is compounded by more general issues with the replica databases, such as the inability to estimate how slow queries will be (phab:T188677) and more recently, general slowness following recent schema changes (phab:T226050). In the meantime, you could try using tools that don't have any limits (or the scalability problems that XTools has), such as Sigma's Pages created tool. Sorry for the inconvenience! — MusikAnimal talk 16:19, 10 July 2019 (UTC)[(discussiontools-replylink)]

I have increased the edit count limit to 400,000. It seems right now, the replicas are going fairly fast. Both Pages Created and Edit Counter didn't time out for your account. I can't promise it will stay that way, though. As an FYI, you can make the Edit Counter go faster by asking only for the data you need, using the checkboxes at https://xtools.wmflabs.org/ec. Best, — MusikAnimal talk 16:27, 10 July 2019 (UTC)[(discussiontools-replylink)] @@ -909,8 +909,8 @@ Evolutionary history of life · ‎Timeline of the evolutionary ... · ‎Earlie

For talk page. See https://en.wikipedia.org/wiki/Talk:Nicotine_marketing QuackGuru (talk) 03:00, 12 July 2019 (UTC)[(discussiontools-replylink)]

(discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]Alerts and alarms
(discussiontools-topicheader-latestcomment: 1562910540)(discussiontools-topicheader-commentcount: 6)(discussiontools-topicheader-authorcount: 4)

-
Tracked in Phabricator
Task T88781
-

Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created? bd2412 T 22:52, 10 July 2019 (UTC)[(discussiontools-replylink)] +

Tracked in Phabricator
Task T88781
+

Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created? bd2412 T 22:52, 10 July 2019 (UTC)[(discussiontools-replylink)]

While this would be a godsend, e.g. for checking back on a talk page in 7 days or so, or allowing a 24-hour 3RR to expire, I am not sure it is MediaWiki's job to be tracking our reminders. That seems to present unnecessary load to the servers for something that individual editors would best be equipped to track locally. I have used Google Calendar and assorted alarm-clock apps to do this, so far. Elizium23 (talk) 23:06, 10 July 2019 (UTC)[(discussiontools-replylink)]
@BD2412: this may be incorporated in the existing feature request: phab:T88781. — xaosflux Talk 23:12, 10 July 2019 (UTC)[(discussiontools-replylink)] @@ -965,8 +965,8 @@ Evolutionary history of life · ‎Timeline of the evolutionary ... · ‎Earlie

My watchlist is again showing pages and diffs I have already seen, even though I have it set to show only unseen changes. Bolding of these pages in the list is also inconsistent. Anyone know why this exceptionally fun behaviour has returned? —Joeyconnick (talk) 22:50, 13 July 2019 (UTC)[(discussiontools-replylink)]

(discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]Citation generator in Visual Editor not working for PMID or PMC numbers
(discussiontools-topicheader-latestcomment: 1563088500)(discussiontools-topicheader-commentcount: 9)(discussiontools-topicheader-authorcount: 4)

-
Tracked in Phabricator
Task T227415
-
Screencap of Wikipedia page.png
+
Tracked in Phabricator
Task T227415
+
Screencap of Wikipedia page.png

It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this. --Anthonyhcole (talk · contribs · email) 05:05, 9 July 2019 (UTC)[(discussiontools-replylink)]

It's a known issue involving the tool labs DNS being blocked or something, see T226088. @AManWithNoPlan: could probably explain in more details what the issue is. Headbomb {t · c · p · b} 05:13, 9 July 2019 (UTC)[(discussiontools-replylink)] @@ -1219,8 +1219,8 @@ Evolutionary history of life · ‎Timeline of the evolutionary ... · ‎Earlie
If anyone is interested, but no idea how to proceed, take a look at mw:How_to_become_a_MediaWiki_hacker. Some knowledge of LAMP is necessary. --qedk (t 桜 c) 06:37, 17 July 2019 (UTC)[(discussiontools-replylink)]
I have made a related suggestion at MediaWiki talk:Confirmdeletetext#Add link to delete an associated talk page. PrimeHunter (talk) 10:08, 17 July 2019 (UTC)[(discussiontools-replylink)]

(discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]"Publish changes"
(discussiontools-topicheader-latestcomment: 1563359280)(discussiontools-topicheader-commentcount: 11)(discussiontools-topicheader-authorcount: 9)

-
Tracked in Phabricator
Task T228116
-

Some time ago, the save button was replaced with a "publish changes" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see "publish changes" and hesitate because of the implications of "publish". +

Tracked in Phabricator
Task T228116
+

Some time ago, the save button was replaced with a "publish changes" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see "publish changes" and hesitate because of the implications of "publish".

I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise? — Rhododendrites talk \\ 17:44, 11 July 2019 (UTC)[(discussiontools-replylink)]

IIRC this change was made by WMF legal and is non-negotiable; they wanted to make it clear to editors that the moment one clicks that button, whatever is in your edit window becomes publicly available for anyone to view and not saved to a private userspace inaccessable to others, whatever the namespace being edited. It was a global change, so the discussions will I assume be on Meta. The announcement was here, so the discussions if there were any will be shortly before that. ‑ Iridescent 17:49, 11 July 2019 (UTC)[(discussiontools-replylink)] @@ -1685,8 +1685,8 @@ Sorry should have said, monobook, Edge, Win10. Thanks, Nardog, for the fix! (Apologies to Paine; not only weren't they the cause of the problem, but that edit was (nearly exactly!) a year ago. I was too tired and in too much of a hurry to see clearly.) Mathglot (talk) 17:41, 1 August 2019 (UTC)[(discussiontools-replylink)]

(discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]The notification button
(discussiontools-topicheader-latestcomment: 1564724700)(discussiontools-topicheader-commentcount: 45)(discussiontools-topicheader-authorcount: 9)

Resolved: Fixed in the last update of MediaWiki. Nardog (talk) 05:45, 2 August 2019 (UTC)[(discussiontools-replylink)]
-
Tracked in Phabricator
Task T228744
-

Hi, so I am using my mobile. +

Tracked in Phabricator
Task T228744
+

Hi, so I am using my mobile.

  1. Just 1 hour ago, an editor posted a comment in my talk page.
  2. I got a notification.
    3. @@ -2352,8 +2352,8 @@ above now done, but (discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]Conflict between Template:Shortcut, lists and Microsoft
    (discussiontools-topicheader-latestcomment: 1565728740)(discussiontools-topicheader-commentcount: 1)(discussiontools-topicheader-authorcount: 1)
    FYI: Pointer to relevant discussion elsewhere.

    Please see Template talk:Shortcut#When in a list item, Edge and IE have a sad day. --Redrose64 🌹 (talk) 20:39, 13 August 2019 (UTC)[(discussiontools-replylink)]

    (discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]Thumbnail image doesn't show in List of tallest structures in Tokyo
    (discussiontools-topicheader-latestcomment: 1565761380)(discussiontools-topicheader-commentcount: 6)(discussiontools-topicheader-authorcount: 4)

    -
    Tracked in Phabricator
    Task T188831
    -

    The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help. +

    Tracked in Phabricator
    Task T188831
    +

    The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help.

    Any clue? Thanks.--fireattack (talk) 22:49, 29 July 2019 (UTC)[(discussiontools-replylink)]

    It works for me. Try to bypass your own cache. PrimeHunter (talk) 01:13, 30 July 2019 (UTC)[(discussiontools-replylink)] @@ -2365,9 +2365,9 @@ above now done, but Saw the issue at List of highest-grossing films as well with the first image. Hopefully it will be resolved before long. Master of Time (talk) 05:43, 14 August 2019 (UTC)[(discussiontools-replylink)]

    (discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]How to prevent VisualEditor from automatically loading when clicking red links?
    (discussiontools-topicheader-latestcomment: 1565801340)(discussiontools-topicheader-commentcount: 6)(discussiontools-topicheader-authorcount: 4)

    -
    Tracked in Phabricator
    Task T211379
    +
    Tracked in Phabricator
    Task T211379
    Tracked in Phabricator
    Task T226267
    -

    Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards SoWhy 07:31, 14 August 2019 (UTC)[(discussiontools-replylink)] +

    Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards SoWhy 07:31, 14 August 2019 (UTC)[(discussiontools-replylink)]

    This is the default behaviour for clicking all redlinks in both VE and Source editor (except Userpage redlink on mobile). There's a phab:T211379 asking to change this and there are comments that this is by design. – Ammarpad (talk) 08:21, 14 August 2019 (UTC)[(discussiontools-replylink)]
    @Ammarpad: Thanks for the phab-link! I dug up a snippet at T195914 that prevents it (thanks to Classicwiki). Regards SoWhy 09:13, 14 August 2019 (UTC)[(discussiontools-replylink)] @@ -2661,8 +2661,8 @@ Greetings, Community tech bot appears to be down (not running) since April, 2019
    Thanks, @Galobtter:, not quite sure how or where I saw the change, I do appreciate the hack! :) --qedk (t 桜 c) 17:25, 12 August 2019 (UTC)[(discussiontools-replylink)]
    Thanks, @DannyS712 and Legoktm:! --qedk (t 桜 c) 19:51, 19 August 2019 (UTC)[(discussiontools-replylink)]

    (discussiontools-topicsubscription-button-subscribe-label)[(discussiontools-topicsubscription-button-subscribe)]Picking a draft to review: RandomInCategory isn't very random
    (discussiontools-topicheader-latestcomment: 1566330180)(discussiontools-topicheader-commentcount: 8)(discussiontools-topicheader-authorcount: 4)

    -
    Tracked in Phabricator
    Task T200703
    -

    I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 "random" drafts, and got: +

    Tracked in Phabricator
    Task T200703
    +

    I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 "random" drafts, and got:

    1. Draft:Declan Meagher
    2. Draft:Gary Soulz
      3. diff --git a/tests/cases/en-big-oldparser/en-big-oldparser-getHTML.json b/tests/cases/en-big-oldparser/en-big-oldparser-getHTML.json index ffc0fb704..977ec59be 100644 --- a/tests/cases/en-big-oldparser/en-big-oldparser-getHTML.json +++ b/tests/cases/en-big-oldparser/en-big-oldparser-getHTML.json @@ -43,7 +43,7 @@ "c-KIENGIR-2019-07-02T10:39:00.000Z-Redrose64-2019-07-01T20:36:00.000Z": "

      @Redrose64:,

      \n

      Thank you it helped, I applied similar tweaks descibred there (in the detailed settings changing to 30 days and enabling 1000 entries as maximum). though, still I don't have 30 days, I assume mainly because of the 1000 entry limitation (I don't know where would be the url to tweak it higher). Thus practically I could go back two weeks, so my initial problem has been solved (going back between 4-7 days)...maybe as an important note for the others or the developers, even this worked only by unchecking the \"Expand watchlist to show all changes, not just the most recent\" in the Advanced Options...(initially at the first tweak attempt, I automatically checked this box assuming it is essential, but anything written above did not work until it was unchecked, ironically it had a contraproductive effect despite it's name...(

      ", "h-Issues_with_alerts,_June_2019": "Issues with alerts, June 2019", "h-Missing_notification_icons_in_MonoBook-Issues_with_alerts,_June_2019-2019-06-25T19:52:00.000Z": "Missing notification icons in MonoBook", - "c-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z-Missing_notification_icons_in_MonoBook": "
      Tracked in Phabricator
      Task T226503
      \n

      I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503.

      ", + "c-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z-Missing_notification_icons_in_MonoBook": "I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503.", "c-Redrose64-2019-06-25T20:21:00.000Z-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z": "I'm getting it in MonoBook too. The appropriate CSS rules are present in the stylesheets: 
      .oo-ui-icon-bell, .mw-ui-icon-bell:before {\n    background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=bell&format=rasterized&lang=en&skin=monobook);\n    background-image: linear-gradient(transparent,transparent),url(\"data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Ebell%3C/title%3E%3Cpath d=%22M16 7a5.38 5.38 0 0 0-4.46-4.85C11.6 1.46 11.53 0 10 0S8.4 1.46 8.46 2.15A5.38 5.38 0 0 0 4 7v6l-2 2v1h16v-1l-2-2zm-6 13a3 3 0 0 0 3-3H7a3 3 0 0 0 3 3z%22/%3E%3C/svg%3E\");\n}\n.oo-ui-icon-tray, .mw-ui-icon-tray:before {\n    background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=tray&format=rasterized&lang=en&skin=monobook);\n    background-image: linear-gradient(transparent,transparent),url(\"data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Etray%3C/title%3E%3Cpath d=%22M3 1a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V3a2 2 0 0 0-2-2zm14 12h-4l-1 2H8l-1-2H3V3h14z%22/%3E%3C/svg%3E\");\n}\n
      Switching to Vector displays them properly, even though the CSS rules are virtually identical - the only differences are that the word \"monobook\" becomes \"vector\" in the first and third url(...) value.", "c-Killiondude-2019-06-25T23:42:00.000Z-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z": "Um, did the fix also give a ton of scroll-space to the right of anyone else's window? I can now scroll for a very long time to the right, despite there being no content.", "c-Suffusion_of_Yellow-2019-06-25T23:45:00.000Z-Killiondude-2019-06-25T23:42:00.000Z": "@Killiondude: Yes, I see the same thing. (Firefox 67, Linux)", @@ -63,7 +63,7 @@ "c-Suffusion_of_Yellow-2019-06-29T19:54:00.000Z-Missing_notification_icons_in_MonoBook": "

      @Bishonen: Ok, try putting:

      .skin-monobook #pt-notifications-notice .mw-echo-notifications-badge, .skin-monobook #pt-notifications-alert .mw-echo-notifications-badge {\n\ttext-align: left;\n}\n

      in your meta:Special:MyPage/global.css.

      ", "c-Bishonen-2019-06-29T20:20:00.000Z-Suffusion_of_Yellow-2019-06-29T19:54:00.000Z": "Suffusion of Yellow, now you're talking my language. It seems to work. Thank you.", "h-Excessive_width_on_monobook-Issues_with_alerts,_June_2019-2019-06-26T03:14:00.000Z": "Excessive width on monobook", - "c-Xaosflux-2019-06-26T03:14:00.000Z-Excessive_width_on_monobook": "
      Tracked in Phabricator
      Task T226594
      \n

      So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above.

      ", + "c-Xaosflux-2019-06-26T03:14:00.000Z-Excessive_width_on_monobook": "So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above.", "c-Xaosflux-2019-06-26T03:41:00.000Z-Xaosflux-2019-06-26T03:14:00.000Z": "Merged to phab:T226594.", "c-Lugnuts-2019-06-26T06:54:00.000Z-Xaosflux-2019-06-26T03:41:00.000Z": "Thank you. Just noticed this, and thought it was a broken ref spilling across the page I was on!", "c-RainFall-2019-06-26T07:13:00.000Z-Xaosflux-2019-06-26T03:14:00.000Z": "Jeez. Hadn't noticed. Can't unsee now. Here's a temporary fix.", @@ -100,7 +100,7 @@ "c-Suffusion_of_Yellow-2019-06-27T22:34:00.000Z-DuncanHill-2019-06-27T22:28:00.000Z": "@DuncanHill: Ideally, that should go in Special:MyPage/monobook.css instead of Special:MyPage/common.css, not I think it will make a big difference.", "c-DuncanHill-2019-06-27T22:40:00.000Z-Suffusion_of_Yellow-2019-06-27T22:34:00.000Z": "Thanks again, have moved it over. Seems to be much the same effect.", "h-Message_&_notification_icons_in_Modern_skin-Issues_with_alerts,_June_2019-2019-06-27T14:52:00.000Z": "Message & notification icons in Modern skin", - "c-Nthep-2019-06-27T14:52:00.000Z-Message_&_notification_icons_in_Modern_skin": "
      Tracked in Phabricator
      Task T226684
      \n
      \"Modern
      \n

      The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4).

      ", + "c-Nthep-2019-06-27T14:52:00.000Z-Message_&_notification_icons_in_Modern_skin": "
      \"Modern
      \n

      The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4).

      ", "c-Xaosflux-2019-06-27T14:57:00.000Z-Nthep-2019-06-27T14:52:00.000Z": "@Nthep: - so in summary - there is a bunch going on and this is coming from upstream not local styles. See phab:T226684 (and some of the discussion at phab:T226594) to catch up on the goings-on.", "c-Nthep-2019-06-27T15:10:00.000Z-Xaosflux-2019-06-27T14:57:00.000Z": "Thanks.", "c-Isarra-2019-07-01T15:55:00.000Z-Nthep-2019-06-27T15:10:00.000Z": "@Nthep: Same as the monobook issues, should be fully fixed at the end of the week/next week depending on how they're doing deployments. Unless you don't like how we fixed it once it does change, in which case do please tell me.", @@ -206,7 +206,7 @@ "c-Redrose64-2019-07-03T23:09:00.000Z-KAVEBEAR-2019-07-03T21:01:00.000Z": "This is not so much a VPT matter as a question for WP:BOTREQ - and I see that an identical thread has been posted at WT:BOTREQ, contrary to WP:MULTI.", "c-Xaosflux-2019-07-04T13:19:00.000Z-KAVEBEAR-2019-07-03T21:01:00.000Z": "To answer the technical question KAVEBEAR, no - assuming this phrase appears in the source text it would require creating another version of the source text for each page (which yes a bot could do, but that is how it would do it). The only way around that would have been if the name was actually a template that could be changed once.", "h-Stuck_tooltips-2019-07-04T23:34:00.000Z": "Stuck tooltips", - "c-Espresso_Addict-2019-07-04T23:34:00.000Z-Stuck_tooltips": "
      Tracked in Phabricator
      Task T226983
      \n

      Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June [8]. Any help appreciated as this is currently on the main page in the In the News section.

      ", + "c-Espresso_Addict-2019-07-04T23:34:00.000Z-Stuck_tooltips": "Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June [8]. Any help appreciated as this is currently on the main page in the In the News section.", "c-Suffusion_of_Yellow-2019-07-04T23:48:00.000Z-Espresso_Addict-2019-07-04T23:34:00.000Z": "@Espresso Addict: It's not just that one page. In fact, I'm not sure that the preview has updated for any page since June 28. See phab:T227033.", "c-Espresso_Addict-2019-07-04T23:52:00.000Z-Suffusion_of_Yellow-2019-07-04T23:48:00.000Z": "Thanks. At least someone is hopefully looking into the issue.", "h-Google_Maps_template_not_displaying_accessdates-2019-07-05T14:02:00.000Z": "Google Maps template not displaying accessdates", @@ -379,7 +379,7 @@ "c-Maile66-2019-07-10T23:26:00.000Z-DuncanHill-2019-07-10T21:26:00.000Z": "Note: This might not be isolated to Wikimedia or Tools. I just got the identical error message at Find A Grave. On second try, Find a Grave loaded.", "c-MusikAnimal-2019-07-10T22:08:00.000Z-DuncanHill-2019-07-10T21:26:00.000Z": "I asked about this at meta:User talk:Whym#WHOIS gateway returning 500 internal server error.", "h-XTools-2019-07-10T15:27:00.000Z": "XTools", - "c-GiantSnowman-2019-07-10T15:27:00.000Z-XTools": "
      Tracked in Phabricator
      Task T207959
      \n
      Tracked in Phabricator
      Task T182182
      \n

      I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved?

      ", + "c-GiantSnowman-2019-07-10T15:27:00.000Z-XTools": "I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved?", "c-MusikAnimal-2019-07-10T16:19:00.000Z-GiantSnowman-2019-07-10T15:27:00.000Z": "@GiantSnowman: The limit is there to prevent long-running queries that likely wouldn't finish, and would unnecessarily slow down XTools for everyone else. I can try increasing it a little bit, but we have to have some sort of sane limit. phab:T182182 is about analyzing the most recent 350,000 edits, but I suspect this wouldn't really help because in theory we'd still have to scan all of your contributions to get the most recent 350,000. The issue with Pages Created, specifically, is tracked at phab:T207959. One idea is to use the page creation log (phab:T221730), which is fast, but it would only produce pages you created going back to June 2018.

      It's a tough problem to solve. We have to balance satisfying the needs of our users, such as yourself, while protecting stability and preventing unrealistic queries from being ran. This is compounded by more general issues with the replica databases, such as the inability to estimate how slow queries will be (phab:T188677) and more recently, general slowness following recent schema changes (phab:T226050). In the meantime, you could try using tools that don't have any limits (or the scalability problems that XTools has), such as Sigma's Pages created tool. Sorry for the inconvenience!

      ", "c-MusikAnimal-2019-07-10T16:27:00.000Z-MusikAnimal-2019-07-10T16:19:00.000Z": "I have increased the edit count limit to 400,000. It seems right now, the replicas are going fairly fast. Both Pages Created and Edit Counter didn't time out for your account. I can't promise it will stay that way, though. As an FYI, you can make the Edit Counter go faster by asking only for the data you need, using the checkboxes at https://xtools.wmflabs.org/ec. Best,", "c-GiantSnowman-2019-07-10T16:36:00.000Z-MusikAnimal-2019-07-10T16:27:00.000Z": "Thanks!", @@ -388,7 +388,7 @@ "h-Request_bot_for_auto_archiving-2019-07-12T03:00:00.000Z": "Request bot for auto archiving", "c-QuackGuru-2019-07-12T03:00:00.000Z-Request_bot_for_auto_archiving": "
      \"\" Resolved
      \n

      For talk page. See https://en.wikipedia.org/wiki/Talk:Nicotine_marketing

      ", "h-Alerts_and_alarms-2019-07-10T22:52:00.000Z": "Alerts and alarms", - "c-BD2412-2019-07-10T22:52:00.000Z-Alerts_and_alarms": "
      Tracked in Phabricator
      Task T88781
      \n

      Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created?

      ", + "c-BD2412-2019-07-10T22:52:00.000Z-Alerts_and_alarms": "Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created?", "c-Elizium23-2019-07-10T23:06:00.000Z-BD2412-2019-07-10T22:52:00.000Z": "While this would be a godsend, e.g. for checking back on a talk page in 7 days or so, or allowing a 24-hour 3RR to expire, I am not sure it is MediaWiki's job to be tracking our reminders. That seems to present unnecessary load to the servers for something that individual editors would best be equipped to track locally. I have used Google Calendar and assorted alarm-clock apps to do this, so far.", "c-Xaosflux-2019-07-10T23:12:00.000Z-BD2412-2019-07-10T22:52:00.000Z": "@BD2412: this may be incorporated in the existing feature request: phab:T88781.", "c-Xaosflux-2019-07-10T23:13:00.000Z-Xaosflux-2019-07-10T23:12:00.000Z": "Note though, this is related to phab:T2582 - which has been pending for 10 years.", @@ -432,7 +432,7 @@ "h-watchlist_inaccuracies_again-2019-07-13T22:50:00.000Z": "watchlist inaccuracies again", "c-Joeyconnick-2019-07-13T22:50:00.000Z-watchlist_inaccuracies_again": "My watchlist is again showing pages and diffs I have already seen, even though I have it set to show only unseen changes. Bolding of these pages in the list is also inconsistent. Anyone know why this exceptionally fun behaviour has returned?", "h-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers-2019-07-09T05:05:00.000Z": "Citation generator in Visual Editor not working for PMID or PMC numbers", - "c-Anthonyhcole-2019-07-09T05:05:00.000Z-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers": "
      Tracked in Phabricator
      Task T227415
      \n
      \"Screencap
      \n

      It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this.

      ", + "c-Anthonyhcole-2019-07-09T05:05:00.000Z-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers": "
      \"Screencap
      \n

      It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this.

      ", "c-Headbomb-2019-07-09T05:13:00.000Z-Anthonyhcole-2019-07-09T05:05:00.000Z": "It's a known issue involving the tool labs DNS being blocked or something, see T226088. @AManWithNoPlan: could probably explain in more details what the issue is.", "c-Anthonyhcole-2019-07-09T05:35:00.000Z-Headbomb-2019-07-09T05:13:00.000Z": "Thanks Headbomb. Seems from this Phabricator discussion that no one knows what the problem is. It's been 3 weeks now, and I can't see that anyone has taken this on as their task - but perhaps I just don't understand how WMF technical people work.", "c-TheDJ-2019-07-09T07:26:00.000Z-Anthonyhcole-2019-07-09T05:35:00.000Z": "Anthonyhcole, there are literally 2 people discussing and analysing network traffic in that ticket... What more are you looking for ? A fix before understanding the cause of the problem is not possible.", @@ -507,7 +507,7 @@ "c-QEDK-2019-07-17T06:37:00.000Z-Winged_Blades_of_Godric-2019-07-17T05:58:00.000Z": "If anyone is interested, but no idea how to proceed, take a look at mw:How_to_become_a_MediaWiki_hacker. Some knowledge of LAMP is necessary.", "c-PrimeHunter-2019-07-17T10:08:00.000Z-Winged_Blades_of_Godric-2019-07-17T05:58:00.000Z": "I have made a related suggestion at MediaWiki talk:Confirmdeletetext#Add link to delete an associated talk page.", "h-\"Publish_changes\"-2019-07-11T17:44:00.000Z": "\"Publish changes\"", - "c-Rhododendrites-2019-07-11T17:44:00.000Z-\"Publish_changes\"": "
      Tracked in Phabricator
      Task T228116
      \n

      Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\". \n

      I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise?

      ", + "c-Rhododendrites-2019-07-11T17:44:00.000Z-\"Publish_changes\"": "

      Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\". \n

      I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise?

      ", "c-Iridescent-2019-07-11T17:49:00.000Z-Rhododendrites-2019-07-11T17:44:00.000Z": "IIRC this change was made by WMF legal and is non-negotiable; they wanted to make it clear to editors that the moment one clicks that button, whatever is in your edit window becomes publicly available for anyone to view and not saved to a private userspace inaccessable to others, whatever the namespace being edited. It was a global change, so the discussions will I assume be on Meta. The announcement was here, so the discussions if there were any will be shortly before that.", "c-JoJo_Eumerus_mobile-2019-07-11T18:44:00.000Z-Iridescent-2019-07-11T17:49:00.000Z": "I recall seeing some discussion on Phabricator; I'll see if I can find links.", "c-Snaevar-2019-07-11T19:32:00.000Z-Rhododendrites-2019-07-11T17:44:00.000Z": "Actually the save button was changed to \"publish changes\" because of newbies. In UX testing newbies did expect the save button to work more like drafts. There was a need to change the text of the button to be more decisive. The bug behind this change is T131132, which explains this further.", @@ -736,7 +736,7 @@ "c-Mathglot-2019-08-01T17:41:00.000Z-Nardog-2019-08-01T09:11:00.000Z": "Thanks, Nardog, for the fix! (Apologies to Paine; not only weren't they the cause of the problem, but that edit was (nearly exactly!) a year ago. I was too tired and in too much of a hurry to see clearly.)", "h-The_notification_button-2019-07-22T21:52:00.000Z": "The notification button", "c-Nardog-2019-08-02T05:45:00.000Z-The_notification_button": "\"\" Resolved: Fixed in the last update of MediaWiki.", - "c-SharabSalam-2019-07-22T21:52:00.000Z-The_notification_button": "
      Tracked in Phabricator
      Task T228744
      \n

      Hi, so I am using my mobile.\n

      \n
      1. Just 1 hour ago, an editor posted a comment in my talk page.
        2. \n
      2. I got a notification.
        3. \n
      3. I didn't click on the notification,
        4. \n
      4. I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.)
        5. \n
      5. I saw the comment diff.
        6. \n
      6. I went to another site, returned to Wikipedia again and saw that the notification button is still red,
        7. \n
      7. I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications.
        8. \n
      8. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again.
        9. \n
      9. Cleared the cache it didn't help still red.
      \n

      So can someone help me to fix this? Thanks.

      ", + "c-SharabSalam-2019-07-22T21:52:00.000Z-The_notification_button": "

      Hi, so I am using my mobile.\n

      \n
      1. Just 1 hour ago, an editor posted a comment in my talk page.
        2. \n
      2. I got a notification.
        3. \n
      3. I didn't click on the notification,
        4. \n
      4. I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.)
        5. \n
      5. I saw the comment diff.
        6. \n
      6. I went to another site, returned to Wikipedia again and saw that the notification button is still red,
        7. \n
      7. I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications.
        8. \n
      8. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again.
        9. \n
      9. Cleared the cache it didn't help still red.
      \n

      So can someone help me to fix this? Thanks.

      ", "c-SharabSalam-2019-07-22T21:57:00.000Z-SharabSalam-2019-07-22T21:52:00.000Z": "Something I haven't tried; which is to trigger the notification again. I will ping a wrong random editor and see. This usually triggers a notification saying: “the ping was not sent because the user doesn't exist”. agsbshsisbsidsb.", "c-SharabSalam-2019-07-22T21:59:00.000Z-SharabSalam-2019-07-22T21:52:00.000Z": "I got a notification, I clicked, read it, refreshed, the notification button returned red so it didn't help.", "c-Xaosflux-2019-07-22T22:00:00.000Z-SharabSalam-2019-07-22T21:59:00.000Z": "@SharabSalam: if you go to Special:Notifications is it there? Also, I have no idea who User:agsbshsisbsidsb is, will assume you just typed random characters for some reason?", @@ -1026,14 +1026,14 @@ "h-Conflict_between_Template:Shortcut,_lists_and_Microsoft-2019-08-13T20:39:00.000Z": "Conflict between Template:Shortcut, lists and Microsoft", "c-Redrose64-2019-08-13T20:39:00.000Z-Conflict_between_Template:Shortcut,_lists_and_Microsoft": "
      \"\" FYI: Pointer to relevant discussion elsewhere.

      Please see Template talk:Shortcut#When in a list item, Edge and IE have a sad day.

      ", "h-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo-2019-07-29T22:49:00.000Z": "Thumbnail image doesn't show in List of tallest structures in Tokyo", - "c-Fireattack-2019-07-29T22:49:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "
      Tracked in Phabricator
      Task T188831
      \n

      The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help.\n

      Any clue? Thanks.

      ", + "c-Fireattack-2019-07-29T22:49:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "

      The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help.\n

      Any clue? Thanks.

      ", "c-PrimeHunter-2019-07-30T01:13:00.000Z-Fireattack-2019-07-29T22:49:00.000Z": "It works for me. Try to bypass your own cache.", "c-Fireattack-2019-07-30T10:17:00.000Z-PrimeHunter-2019-07-30T01:13:00.000Z": "

      I think the reason is that particular thumbnail returns the header says \"content-type: application/x-www-form-urlencoded\" instead of common \"image/jpeg\".

      \n

      Can you try to open http://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Shin-marunouchi.Building-2007-01.jpg/100px-Shin-marunouchi.Building-2007-01.jpg directly and see what happens? Here, it will try to download itself instead of just display. I can see this weird behavior in both Firefox and Chrome and it doesn't happen to other images.

      \n

      But in Firefox, it can still display the image this way in <img> tag (but not in Chrome).

      ", "c-George_Ho-2019-08-06T00:13:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Not just this list, some other thumbnail images don't load well at List of Cheers characters, List of Friends characters, and List of The Big Bang Theory and Young Sheldon characters. Check other list pages.", "c-Fireattack-2019-08-06T20:42:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Update: The root cause is Phab:T188831. And about why it starts to cause more apparent issue, see https://bugs.chromium.org/p/chromium/issues/detail?id=990853 .", "c-Master_of_Time-2019-08-14T05:43:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Saw the issue at List of highest-grossing films as well with the first image. Hopefully it will be resolved before long.", "h-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?-2019-08-14T07:31:00.000Z": "How to prevent VisualEditor from automatically loading when clicking red links?", - "c-SoWhy-2019-08-14T07:31:00.000Z-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?": "
      Tracked in Phabricator
      Task T211379
      \n
      Tracked in Phabricator
      Task T226267
      \n

      Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards

      ", + "c-SoWhy-2019-08-14T07:31:00.000Z-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?": "Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards", "c-Ammarpad-2019-08-14T08:21:00.000Z-SoWhy-2019-08-14T07:31:00.000Z": "This is the default behaviour for clicking all redlinks in both VE and Source editor (except Userpage redlink on mobile). There's a phab:T211379 asking to change this and there are comments that this is by design.", "c-SoWhy-2019-08-14T09:13:00.000Z-Ammarpad-2019-08-14T08:21:00.000Z": "@Ammarpad: Thanks for the phab-link! I dug up a snippet at T195914 that prevents it (thanks to Classicwiki). Regards", "c-Xaosflux-2019-08-14T11:39:00.000Z-SoWhy-2019-08-14T09:13:00.000Z": "@SoWhy: have you tried setting \"Temporarily disable the visual editor while it is in beta\" in Special:Preferences#mw-prefsection-editing? I have that set and never get the visual editor unless I specifically switch to it.", @@ -1180,7 +1180,7 @@ "c-QEDK-2019-08-12T17:25:00.000Z-Galobtter-2019-08-12T06:13:00.000Z": "Thanks, @Galobtter:, not quite sure how or where I saw the change, I do appreciate the hack! :)", "c-QEDK-2019-08-19T19:51:00.000Z-QEDK-2019-08-12T17:25:00.000Z": "Thanks, @DannyS712 and Legoktm:!", "h-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random-2019-08-18T17:57:00.000Z": "Picking a draft to review: RandomInCategory isn't very random", - "c-RoySmith-2019-08-18T17:57:00.000Z-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random": "
      Tracked in Phabricator
      Task T200703
      \n

      I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got:\n

      \n
      1. Draft:Declan Meagher
        2. \n
      2. Draft:Gary Soulz
        3. \n
      3. Draft:Ananth Narayanan
        4. \n
      4. Draft:Frank Verboven
        5. \n
      5. Draft:Maths Time Joy
        6. \n
      6. Draft:Gary Soulz
        7. \n
      7. Draft:Ananth Narayanan
        8. \n
      8. Draft:Eni Vasili
        9. \n
      9. Draft:Shorts México - Mexico International Short Film Festival
        10. \n
      10. Category:Pending AfC submissions in userspace
        11. \n
      11. Draft:John Haze
        12. \n
      12. Draft:Alisha Rai (author)
        13. \n
      13. Draft:Leonardo3 Museum
        14. \n
      14. Draft:Wake. (2018 film)
        15. \n
      15. Category:Pending AfC submissions in article space
        16. \n
      16. Draft:Anastasiya Makarevich
        17. \n
      17. Draft:Alisha Rai (author)
        18. \n
      18. User:ItsYaBoiAustin/sandbox/Odyssey: Extraction
        19. \n
      19. Draft:Scott Stambach
        20. \n
      20. Draft:Christian Lillinger
        21. \n
      21. Draft:Gudula Naiga Basaza
        22. \n
      22. Draft:Scott Stambach
        23. \n
      23. Draft:Katherine Boyer
        24. \n
      24. Draft:Walter Ferguson
        25. \n
      25. Draft:Faryal Mehmood
      \n

      Not only are there four duplicates:\n

      \n
      • Draft:Scott Stambach
        • \n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
        • \n
      • Draft:Alisha Rai (author)
      \n

      but two pairs of duplicates in the same order:\n

      \n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
      \n

      There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much.\n

      Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap.\n

      My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations:\n

      \n
      0.000249\n0.000489\n0.000508\n0.000544\n0.000573\n0.000536\n0.000559\n0.000568\n0.000563\n0.000599\n
      \n

      That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing.\n

      Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.\n

      ", + "c-RoySmith-2019-08-18T17:57:00.000Z-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random": "

      I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got:\n

      \n
      1. Draft:Declan Meagher
        2. \n
      2. Draft:Gary Soulz
        3. \n
      3. Draft:Ananth Narayanan
        4. \n
      4. Draft:Frank Verboven
        5. \n
      5. Draft:Maths Time Joy
        6. \n
      6. Draft:Gary Soulz
        7. \n
      7. Draft:Ananth Narayanan
        8. \n
      8. Draft:Eni Vasili
        9. \n
      9. Draft:Shorts México - Mexico International Short Film Festival
        10. \n
      10. Category:Pending AfC submissions in userspace
        11. \n
      11. Draft:John Haze
        12. \n
      12. Draft:Alisha Rai (author)
        13. \n
      13. Draft:Leonardo3 Museum
        14. \n
      14. Draft:Wake. (2018 film)
        15. \n
      15. Category:Pending AfC submissions in article space
        16. \n
      16. Draft:Anastasiya Makarevich
        17. \n
      17. Draft:Alisha Rai (author)
        18. \n
      18. User:ItsYaBoiAustin/sandbox/Odyssey: Extraction
        19. \n
      19. Draft:Scott Stambach
        20. \n
      20. Draft:Christian Lillinger
        21. \n
      21. Draft:Gudula Naiga Basaza
        22. \n
      22. Draft:Scott Stambach
        23. \n
      23. Draft:Katherine Boyer
        24. \n
      24. Draft:Walter Ferguson
        25. \n
      25. Draft:Faryal Mehmood
      \n

      Not only are there four duplicates:\n

      \n
      • Draft:Scott Stambach
        • \n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
        • \n
      • Draft:Alisha Rai (author)
      \n

      but two pairs of duplicates in the same order:\n

      \n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
      \n

      There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much.\n

      Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap.\n

      My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations:\n

      \n
      0.000249\n0.000489\n0.000508\n0.000544\n0.000573\n0.000536\n0.000559\n0.000568\n0.000563\n0.000599\n
      \n

      That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing.\n

      Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.\n

      ", "c-Guy_Macon-2019-08-18T18:43:00.000Z-RoySmith-2019-08-18T17:57:00.000Z": "Good catch! Would this be a good candidate for a Phabricator ticket?", "c-Huji-2019-08-18T18:58:00.000Z-RoySmith-2019-08-18T17:57:00.000Z": "

      Huh! I am virtually never active on enwiki. I happened to open the thread right above this one and see this as a result. I also happen to be the person who wrote RandomInCategory!

      \n

      I think it is best to move this to Phab. Essentially (if I understand it well) the problem is that page_random is (hopefully) uniformly distributed across all pages; but when thinking about a small category, its values will certainly not be uniformly distributed. There exist ways through which we could circumvent this, but I'm not sure if these ways are efficient enough to be adopted into MW source code. It is best to have that discussion in Phab, where more technical users can discuss its efficiency (or propose more efficient implementations of it). Please add me (Huji) on Phab once you create the task.

      ", "c-RoySmith-2019-08-18T19:11:00.000Z-Huji-2019-08-18T18:58:00.000Z": "I'm happy to open a Phab ticket, but I'm not sure what the ticket should say. The problem isn't (I don't think) that RandomInCategory is broken. I think the current implementation actually a pretty good solution for its intended purpose, which I assume is driving the \"Random article\" link on the main page. It's just that how we use it for managing the draft work queue is not a good fit.", diff --git a/tests/cases/en-big-oldparser/en-big-oldparser-getText.json b/tests/cases/en-big-oldparser/en-big-oldparser-getText.json index 7b8b647e9..522a13703 100644 --- a/tests/cases/en-big-oldparser/en-big-oldparser-getText.json +++ b/tests/cases/en-big-oldparser/en-big-oldparser-getText.json @@ -43,7 +43,7 @@ "c-KIENGIR-2019-07-02T10:39:00.000Z-Redrose64-2019-07-01T20:36:00.000Z": "@Redrose64:, Thank you it helped, I applied similar tweaks descibred there (in the detailed settings changing to 30 days and enabling 1000 entries as maximum). though, still I don't have 30 days, I assume mainly because of the 1000 entry limitation (I don't know where would be the url to tweak it higher). Thus practically I could go back two weeks, so my initial problem has been solved (going back between 4-7 days)...maybe as an important note for the others or the developers, even this worked only by unchecking the \"Expand watchlist to show all changes, not just the most recent\" in the Advanced Options...(initially at the first tweak attempt, I automatically checked this box assuming it is essential, but anything written above did not work until it was unchecked, ironically it had a contraproductive effect despite it's name...(", "h-Issues_with_alerts,_June_2019": "Issues with alerts, June 2019", "h-Missing_notification_icons_in_MonoBook-Issues_with_alerts,_June_2019-2019-06-25T19:52:00.000Z": "Missing notification icons in MonoBook", - "c-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z-Missing_notification_icons_in_MonoBook": "Tracked in Phabricator Task T226503 I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503.", + "c-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z-Missing_notification_icons_in_MonoBook": "I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503.", "c-Redrose64-2019-06-25T20:21:00.000Z-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z": "I'm getting it in MonoBook too. The appropriate CSS rules are present in the stylesheets: .oo-ui-icon-bell, .mw-ui-icon-bell:before { background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=bell&format=rasterized&lang=en&skin=monobook); background-image: linear-gradient(transparent,transparent),url(\"data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Ebell%3C/title%3E%3Cpath d=%22M16 7a5.38 5.38 0 0 0-4.46-4.85C11.6 1.46 11.53 0 10 0S8.4 1.46 8.46 2.15A5.38 5.38 0 0 0 4 7v6l-2 2v1h16v-1l-2-2zm-6 13a3 3 0 0 0 3-3H7a3 3 0 0 0 3 3z%22/%3E%3C/svg%3E\"); } .oo-ui-icon-tray, .mw-ui-icon-tray:before { background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=tray&format=rasterized&lang=en&skin=monobook); background-image: linear-gradient(transparent,transparent),url(\"data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Etray%3C/title%3E%3Cpath d=%22M3 1a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V3a2 2 0 0 0-2-2zm14 12h-4l-1 2H8l-1-2H3V3h14z%22/%3E%3C/svg%3E\"); } Switching to Vector displays them properly, even though the CSS rules are virtually identical - the only differences are that the word \"monobook\" becomes \"vector\" in the first and third url(...) value.", "c-Killiondude-2019-06-25T23:42:00.000Z-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z": "Um, did the fix also give a ton of scroll-space to the right of anyone else's window? I can now scroll for a very long time to the right, despite there being no content.", "c-Suffusion_of_Yellow-2019-06-25T23:45:00.000Z-Killiondude-2019-06-25T23:42:00.000Z": "@Killiondude: Yes, I see the same thing. (Firefox 67, Linux)", @@ -63,7 +63,7 @@ "c-Suffusion_of_Yellow-2019-06-29T19:54:00.000Z-Missing_notification_icons_in_MonoBook": "@Bishonen: Ok, try putting: .skin-monobook #pt-notifications-notice .mw-echo-notifications-badge, .skin-monobook #pt-notifications-alert .mw-echo-notifications-badge { text-align: left; } in your meta:Special:MyPage/global.css.", "c-Bishonen-2019-06-29T20:20:00.000Z-Suffusion_of_Yellow-2019-06-29T19:54:00.000Z": "Suffusion of Yellow, now you're talking my language. It seems to work. Thank you.", "h-Excessive_width_on_monobook-Issues_with_alerts,_June_2019-2019-06-26T03:14:00.000Z": "Excessive width on monobook", - "c-Xaosflux-2019-06-26T03:14:00.000Z-Excessive_width_on_monobook": "Tracked in Phabricator Task T226594 So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above.", + "c-Xaosflux-2019-06-26T03:14:00.000Z-Excessive_width_on_monobook": "So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above.", "c-Xaosflux-2019-06-26T03:41:00.000Z-Xaosflux-2019-06-26T03:14:00.000Z": "Merged to phab:T226594.", "c-Lugnuts-2019-06-26T06:54:00.000Z-Xaosflux-2019-06-26T03:41:00.000Z": "Thank you. Just noticed this, and thought it was a broken ref spilling across the page I was on!", "c-RainFall-2019-06-26T07:13:00.000Z-Xaosflux-2019-06-26T03:14:00.000Z": "Jeez. Hadn't noticed. Can't unsee now. Here's a temporary fix.", @@ -100,7 +100,7 @@ "c-Suffusion_of_Yellow-2019-06-27T22:34:00.000Z-DuncanHill-2019-06-27T22:28:00.000Z": "@DuncanHill: Ideally, that should go in Special:MyPage/monobook.css instead of Special:MyPage/common.css, not I think it will make a big difference.", "c-DuncanHill-2019-06-27T22:40:00.000Z-Suffusion_of_Yellow-2019-06-27T22:34:00.000Z": "Thanks again, have moved it over. Seems to be much the same effect.", "h-Message_&_notification_icons_in_Modern_skin-Issues_with_alerts,_June_2019-2019-06-27T14:52:00.000Z": "Message & notification icons in Modern skin", - "c-Nthep-2019-06-27T14:52:00.000Z-Message_&_notification_icons_in_Modern_skin": "Tracked in Phabricator Task T226684 The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4).", + "c-Nthep-2019-06-27T14:52:00.000Z-Message_&_notification_icons_in_Modern_skin": "The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4).", "c-Xaosflux-2019-06-27T14:57:00.000Z-Nthep-2019-06-27T14:52:00.000Z": "@Nthep: - so in summary - there is a bunch going on and this is coming from upstream not local styles. See phab:T226684 (and some of the discussion at phab:T226594) to catch up on the goings-on.", "c-Nthep-2019-06-27T15:10:00.000Z-Xaosflux-2019-06-27T14:57:00.000Z": "Thanks.", "c-Isarra-2019-07-01T15:55:00.000Z-Nthep-2019-06-27T15:10:00.000Z": "@Nthep: Same as the monobook issues, should be fully fixed at the end of the week/next week depending on how they're doing deployments. Unless you don't like how we fixed it once it does change, in which case do please tell me.", @@ -206,7 +206,7 @@ "c-Redrose64-2019-07-03T23:09:00.000Z-KAVEBEAR-2019-07-03T21:01:00.000Z": "This is not so much a VPT matter as a question for WP:BOTREQ - and I see that an identical thread has been posted at WT:BOTREQ, contrary to WP:MULTI.", "c-Xaosflux-2019-07-04T13:19:00.000Z-KAVEBEAR-2019-07-03T21:01:00.000Z": "To answer the technical question KAVEBEAR, no - assuming this phrase appears in the source text it would require creating another version of the source text for each page (which yes a bot could do, but that is how it would do it). The only way around that would have been if the name was actually a template that could be changed once.", "h-Stuck_tooltips-2019-07-04T23:34:00.000Z": "Stuck tooltips", - "c-Espresso_Addict-2019-07-04T23:34:00.000Z-Stuck_tooltips": "Tracked in Phabricator Task T226983 Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June [8]. Any help appreciated as this is currently on the main page in the In the News section.", + "c-Espresso_Addict-2019-07-04T23:34:00.000Z-Stuck_tooltips": "Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June [8]. Any help appreciated as this is currently on the main page in the In the News section.", "c-Suffusion_of_Yellow-2019-07-04T23:48:00.000Z-Espresso_Addict-2019-07-04T23:34:00.000Z": "@Espresso Addict: It's not just that one page. In fact, I'm not sure that the preview has updated for any page since June 28. See phab:T227033.", "c-Espresso_Addict-2019-07-04T23:52:00.000Z-Suffusion_of_Yellow-2019-07-04T23:48:00.000Z": "Thanks. At least someone is hopefully looking into the issue.", "h-Google_Maps_template_not_displaying_accessdates-2019-07-05T14:02:00.000Z": "Google Maps template not displaying accessdates", @@ -379,7 +379,7 @@ "c-Maile66-2019-07-10T23:26:00.000Z-DuncanHill-2019-07-10T21:26:00.000Z": "Note: This might not be isolated to Wikimedia or Tools. I just got the identical error message at Find A Grave. On second try, Find a Grave loaded.", "c-MusikAnimal-2019-07-10T22:08:00.000Z-DuncanHill-2019-07-10T21:26:00.000Z": "I asked about this at meta:User talk:Whym#WHOIS gateway returning 500 internal server error.", "h-XTools-2019-07-10T15:27:00.000Z": "XTools", - "c-GiantSnowman-2019-07-10T15:27:00.000Z-XTools": "Tracked in Phabricator Task T207959 Tracked in Phabricator Task T182182 I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved?", + "c-GiantSnowman-2019-07-10T15:27:00.000Z-XTools": "I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved?", "c-MusikAnimal-2019-07-10T16:19:00.000Z-GiantSnowman-2019-07-10T15:27:00.000Z": "@GiantSnowman: The limit is there to prevent long-running queries that likely wouldn't finish, and would unnecessarily slow down XTools for everyone else. I can try increasing it a little bit, but we have to have some sort of sane limit. phab:T182182 is about analyzing the most recent 350,000 edits, but I suspect this wouldn't really help because in theory we'd still have to scan all of your contributions to get the most recent 350,000. The issue with Pages Created, specifically, is tracked at phab:T207959. One idea is to use the page creation log (phab:T221730), which is fast, but it would only produce pages you created going back to June 2018. It's a tough problem to solve. We have to balance satisfying the needs of our users, such as yourself, while protecting stability and preventing unrealistic queries from being ran. This is compounded by more general issues with the replica databases, such as the inability to estimate how slow queries will be (phab:T188677) and more recently, general slowness following recent schema changes (phab:T226050). In the meantime, you could try using tools that don't have any limits (or the scalability problems that XTools has), such as Sigma's Pages created tool. Sorry for the inconvenience!", "c-MusikAnimal-2019-07-10T16:27:00.000Z-MusikAnimal-2019-07-10T16:19:00.000Z": "I have increased the edit count limit to 400,000. It seems right now, the replicas are going fairly fast. Both Pages Created and Edit Counter didn't time out for your account. I can't promise it will stay that way, though. As an FYI, you can make the Edit Counter go faster by asking only for the data you need, using the checkboxes at https://xtools.wmflabs.org/ec. Best,", "c-GiantSnowman-2019-07-10T16:36:00.000Z-MusikAnimal-2019-07-10T16:27:00.000Z": "Thanks!", @@ -388,7 +388,7 @@ "h-Request_bot_for_auto_archiving-2019-07-12T03:00:00.000Z": "Request bot for auto archiving", "c-QuackGuru-2019-07-12T03:00:00.000Z-Request_bot_for_auto_archiving": "Resolved For talk page. See https://en.wikipedia.org/wiki/Talk:Nicotine_marketing", "h-Alerts_and_alarms-2019-07-10T22:52:00.000Z": "Alerts and alarms", - "c-BD2412-2019-07-10T22:52:00.000Z-Alerts_and_alarms": "Tracked in Phabricator Task T88781 Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created?", + "c-BD2412-2019-07-10T22:52:00.000Z-Alerts_and_alarms": "Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created?", "c-Elizium23-2019-07-10T23:06:00.000Z-BD2412-2019-07-10T22:52:00.000Z": "While this would be a godsend, e.g. for checking back on a talk page in 7 days or so, or allowing a 24-hour 3RR to expire, I am not sure it is MediaWiki's job to be tracking our reminders. That seems to present unnecessary load to the servers for something that individual editors would best be equipped to track locally. I have used Google Calendar and assorted alarm-clock apps to do this, so far.", "c-Xaosflux-2019-07-10T23:12:00.000Z-BD2412-2019-07-10T22:52:00.000Z": "@BD2412: this may be incorporated in the existing feature request: phab:T88781.", "c-Xaosflux-2019-07-10T23:13:00.000Z-Xaosflux-2019-07-10T23:12:00.000Z": "Note though, this is related to phab:T2582 - which has been pending for 10 years.", @@ -432,7 +432,7 @@ "h-watchlist_inaccuracies_again-2019-07-13T22:50:00.000Z": "watchlist inaccuracies again", "c-Joeyconnick-2019-07-13T22:50:00.000Z-watchlist_inaccuracies_again": "My watchlist is again showing pages and diffs I have already seen, even though I have it set to show only unseen changes. Bolding of these pages in the list is also inconsistent. Anyone know why this exceptionally fun behaviour has returned?", "h-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers-2019-07-09T05:05:00.000Z": "Citation generator in Visual Editor not working for PMID or PMC numbers", - "c-Anthonyhcole-2019-07-09T05:05:00.000Z-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers": "Tracked in Phabricator Task T227415 It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this.", + "c-Anthonyhcole-2019-07-09T05:05:00.000Z-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers": "It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this.", "c-Headbomb-2019-07-09T05:13:00.000Z-Anthonyhcole-2019-07-09T05:05:00.000Z": "It's a known issue involving the tool labs DNS being blocked or something, see T226088. @AManWithNoPlan: could probably explain in more details what the issue is.", "c-Anthonyhcole-2019-07-09T05:35:00.000Z-Headbomb-2019-07-09T05:13:00.000Z": "Thanks Headbomb. Seems from this Phabricator discussion that no one knows what the problem is. It's been 3 weeks now, and I can't see that anyone has taken this on as their task - but perhaps I just don't understand how WMF technical people work.", "c-TheDJ-2019-07-09T07:26:00.000Z-Anthonyhcole-2019-07-09T05:35:00.000Z": "Anthonyhcole, there are literally 2 people discussing and analysing network traffic in that ticket... What more are you looking for ? A fix before understanding the cause of the problem is not possible.", @@ -507,7 +507,7 @@ "c-QEDK-2019-07-17T06:37:00.000Z-Winged_Blades_of_Godric-2019-07-17T05:58:00.000Z": "If anyone is interested, but no idea how to proceed, take a look at mw:How_to_become_a_MediaWiki_hacker. Some knowledge of LAMP is necessary.", "c-PrimeHunter-2019-07-17T10:08:00.000Z-Winged_Blades_of_Godric-2019-07-17T05:58:00.000Z": "I have made a related suggestion at MediaWiki talk:Confirmdeletetext#Add link to delete an associated talk page.", "h-\"Publish_changes\"-2019-07-11T17:44:00.000Z": "\"Publish changes\"", - "c-Rhododendrites-2019-07-11T17:44:00.000Z-\"Publish_changes\"": "Tracked in Phabricator Task T228116 Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\". I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise?", + "c-Rhododendrites-2019-07-11T17:44:00.000Z-\"Publish_changes\"": "Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\". I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise?", "c-Iridescent-2019-07-11T17:49:00.000Z-Rhododendrites-2019-07-11T17:44:00.000Z": "IIRC this change was made by WMF legal and is non-negotiable; they wanted to make it clear to editors that the moment one clicks that button, whatever is in your edit window becomes publicly available for anyone to view and not saved to a private userspace inaccessable to others, whatever the namespace being edited. It was a global change, so the discussions will I assume be on Meta. The announcement was here, so the discussions if there were any will be shortly before that.", "c-JoJo_Eumerus_mobile-2019-07-11T18:44:00.000Z-Iridescent-2019-07-11T17:49:00.000Z": "I recall seeing some discussion on Phabricator; I'll see if I can find links.", "c-Snaevar-2019-07-11T19:32:00.000Z-Rhododendrites-2019-07-11T17:44:00.000Z": "Actually the save button was changed to \"publish changes\" because of newbies. In UX testing newbies did expect the save button to work more like drafts. There was a need to change the text of the button to be more decisive. The bug behind this change is T131132, which explains this further.", @@ -736,7 +736,7 @@ "c-Mathglot-2019-08-01T17:41:00.000Z-Nardog-2019-08-01T09:11:00.000Z": "Thanks, Nardog, for the fix! (Apologies to Paine; not only weren't they the cause of the problem, but that edit was (nearly exactly!) a year ago. I was too tired and in too much of a hurry to see clearly.)", "h-The_notification_button-2019-07-22T21:52:00.000Z": "The notification button", "c-Nardog-2019-08-02T05:45:00.000Z-The_notification_button": "Resolved: Fixed in the last update of MediaWiki.", - "c-SharabSalam-2019-07-22T21:52:00.000Z-The_notification_button": "Tracked in Phabricator Task T228744 Hi, so I am using my mobile. Just 1 hour ago, an editor posted a comment in my talk page. I got a notification. I didn't click on the notification, I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.) I saw the comment diff. I went to another site, returned to Wikipedia again and saw that the notification button is still red, I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again. Cleared the cache it didn't help still red. So can someone help me to fix this? Thanks.", + "c-SharabSalam-2019-07-22T21:52:00.000Z-The_notification_button": "Hi, so I am using my mobile. Just 1 hour ago, an editor posted a comment in my talk page. I got a notification. I didn't click on the notification, I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.) I saw the comment diff. I went to another site, returned to Wikipedia again and saw that the notification button is still red, I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again. Cleared the cache it didn't help still red. So can someone help me to fix this? Thanks.", "c-SharabSalam-2019-07-22T21:57:00.000Z-SharabSalam-2019-07-22T21:52:00.000Z": "Something I haven't tried; which is to trigger the notification again. I will ping a wrong random editor and see. This usually triggers a notification saying: “the ping was not sent because the user doesn't exist”. agsbshsisbsidsb.", "c-SharabSalam-2019-07-22T21:59:00.000Z-SharabSalam-2019-07-22T21:52:00.000Z": "I got a notification, I clicked, read it, refreshed, the notification button returned red so it didn't help.", "c-Xaosflux-2019-07-22T22:00:00.000Z-SharabSalam-2019-07-22T21:59:00.000Z": "@SharabSalam: if you go to Special:Notifications is it there? Also, I have no idea who User:agsbshsisbsidsb is, will assume you just typed random characters for some reason?", @@ -1026,14 +1026,14 @@ "h-Conflict_between_Template:Shortcut,_lists_and_Microsoft-2019-08-13T20:39:00.000Z": "Conflict between Template:Shortcut, lists and Microsoft", "c-Redrose64-2019-08-13T20:39:00.000Z-Conflict_between_Template:Shortcut,_lists_and_Microsoft": "FYI: Pointer to relevant discussion elsewhere. Please see Template talk:Shortcut#When in a list item, Edge and IE have a sad day.", "h-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo-2019-07-29T22:49:00.000Z": "Thumbnail image doesn't show in List of tallest structures in Tokyo", - "c-Fireattack-2019-07-29T22:49:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Tracked in Phabricator Task T188831 The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help. Any clue? Thanks.", + "c-Fireattack-2019-07-29T22:49:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help. Any clue? Thanks.", "c-PrimeHunter-2019-07-30T01:13:00.000Z-Fireattack-2019-07-29T22:49:00.000Z": "It works for me. Try to bypass your own cache.", "c-Fireattack-2019-07-30T10:17:00.000Z-PrimeHunter-2019-07-30T01:13:00.000Z": "I think the reason is that particular thumbnail returns the header says \"content-type: application/x-www-form-urlencoded\" instead of common \"image/jpeg\". Can you try to open http://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Shin-marunouchi.Building-2007-01.jpg/100px-Shin-marunouchi.Building-2007-01.jpg directly and see what happens? Here, it will try to download itself instead of just display. I can see this weird behavior in both Firefox and Chrome and it doesn't happen to other images. But in Firefox, it can still display the image this way in tag (but not in Chrome).", "c-George_Ho-2019-08-06T00:13:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Not just this list, some other thumbnail images don't load well at List of Cheers characters, List of Friends characters, and List of The Big Bang Theory and Young Sheldon characters. Check other list pages.", "c-Fireattack-2019-08-06T20:42:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Update: The root cause is Phab:T188831. And about why it starts to cause more apparent issue, see https://bugs.chromium.org/p/chromium/issues/detail?id=990853 .", "c-Master_of_Time-2019-08-14T05:43:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Saw the issue at List of highest-grossing films as well with the first image. Hopefully it will be resolved before long.", "h-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?-2019-08-14T07:31:00.000Z": "How to prevent VisualEditor from automatically loading when clicking red links?", - "c-SoWhy-2019-08-14T07:31:00.000Z-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?": "Tracked in Phabricator Task T211379 Tracked in Phabricator Task T226267 Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards", + "c-SoWhy-2019-08-14T07:31:00.000Z-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?": "Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards", "c-Ammarpad-2019-08-14T08:21:00.000Z-SoWhy-2019-08-14T07:31:00.000Z": "This is the default behaviour for clicking all redlinks in both VE and Source editor (except Userpage redlink on mobile). There's a phab:T211379 asking to change this and there are comments that this is by design.", "c-SoWhy-2019-08-14T09:13:00.000Z-Ammarpad-2019-08-14T08:21:00.000Z": "@Ammarpad: Thanks for the phab-link! I dug up a snippet at T195914 that prevents it (thanks to Classicwiki). Regards", "c-Xaosflux-2019-08-14T11:39:00.000Z-SoWhy-2019-08-14T09:13:00.000Z": "@SoWhy: have you tried setting \"Temporarily disable the visual editor while it is in beta\" in Special:Preferences#mw-prefsection-editing? I have that set and never get the visual editor unless I specifically switch to it.", @@ -1180,7 +1180,7 @@ "c-QEDK-2019-08-12T17:25:00.000Z-Galobtter-2019-08-12T06:13:00.000Z": "Thanks, @Galobtter:, not quite sure how or where I saw the change, I do appreciate the hack! :)", "c-QEDK-2019-08-19T19:51:00.000Z-QEDK-2019-08-12T17:25:00.000Z": "Thanks, @DannyS712 and Legoktm:!", "h-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random-2019-08-18T17:57:00.000Z": "Picking a draft to review: RandomInCategory isn't very random", - "c-RoySmith-2019-08-18T17:57:00.000Z-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random": "Tracked in Phabricator Task T200703 I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got: Draft:Declan Meagher Draft:Gary Soulz Draft:Ananth Narayanan Draft:Frank Verboven Draft:Maths Time Joy Draft:Gary Soulz Draft:Ananth Narayanan Draft:Eni Vasili Draft:Shorts México - Mexico International Short Film Festival Category:Pending AfC submissions in userspace Draft:John Haze Draft:Alisha Rai (author) Draft:Leonardo3 Museum Draft:Wake. (2018 film) Category:Pending AfC submissions in article space Draft:Anastasiya Makarevich Draft:Alisha Rai (author) User:ItsYaBoiAustin/sandbox/Odyssey: Extraction Draft:Scott Stambach Draft:Christian Lillinger Draft:Gudula Naiga Basaza Draft:Scott Stambach Draft:Katherine Boyer Draft:Walter Ferguson Draft:Faryal Mehmood Not only are there four duplicates: Draft:Scott Stambach Draft:Gary Soulz Draft:Ananth Narayanan Draft:Alisha Rai (author) but two pairs of duplicates in the same order: Draft:Gary Soulz Draft:Ananth Narayanan There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much. Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap. My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations: 0.000249 0.000489 0.000508 0.000544 0.000573 0.000536 0.000559 0.000568 0.000563 0.000599 That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing. Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.", + "c-RoySmith-2019-08-18T17:57:00.000Z-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random": "I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got: Draft:Declan Meagher Draft:Gary Soulz Draft:Ananth Narayanan Draft:Frank Verboven Draft:Maths Time Joy Draft:Gary Soulz Draft:Ananth Narayanan Draft:Eni Vasili Draft:Shorts México - Mexico International Short Film Festival Category:Pending AfC submissions in userspace Draft:John Haze Draft:Alisha Rai (author) Draft:Leonardo3 Museum Draft:Wake. (2018 film) Category:Pending AfC submissions in article space Draft:Anastasiya Makarevich Draft:Alisha Rai (author) User:ItsYaBoiAustin/sandbox/Odyssey: Extraction Draft:Scott Stambach Draft:Christian Lillinger Draft:Gudula Naiga Basaza Draft:Scott Stambach Draft:Katherine Boyer Draft:Walter Ferguson Draft:Faryal Mehmood Not only are there four duplicates: Draft:Scott Stambach Draft:Gary Soulz Draft:Ananth Narayanan Draft:Alisha Rai (author) but two pairs of duplicates in the same order: Draft:Gary Soulz Draft:Ananth Narayanan There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much. Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap. My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations: 0.000249 0.000489 0.000508 0.000544 0.000573 0.000536 0.000559 0.000568 0.000563 0.000599 That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing. Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.", "c-Guy_Macon-2019-08-18T18:43:00.000Z-RoySmith-2019-08-18T17:57:00.000Z": "Good catch! Would this be a good candidate for a Phabricator ticket?", "c-Huji-2019-08-18T18:58:00.000Z-RoySmith-2019-08-18T17:57:00.000Z": "Huh! I am virtually never active on enwiki. I happened to open the thread right above this one and see this as a result. I also happen to be the person who wrote RandomInCategory! I think it is best to move this to Phab. Essentially (if I understand it well) the problem is that page_random is (hopefully) uniformly distributed across all pages; but when thinking about a small category, its values will certainly not be uniformly distributed. There exist ways through which we could circumvent this, but I'm not sure if these ways are efficient enough to be adopted into MW source code. It is best to have that discussion in Phab, where more technical users can discuss its efficiency (or propose more efficient implementations of it). Please add me (Huji) on Phab once you create the task.", "c-RoySmith-2019-08-18T19:11:00.000Z-Huji-2019-08-18T18:58:00.000Z": "I'm happy to open a Phab ticket, but I'm not sure what the ticket should say. The problem isn't (I don't think) that RandomInCategory is broken. I think the current implementation actually a pretty good solution for its intended purpose, which I assume is driving the \"Random article\" link on the main page. It's just that how we use it for managing the draft work queue is not a good fit.", diff --git a/tests/cases/en-big-oldparser/en-big-oldparser.json b/tests/cases/en-big-oldparser/en-big-oldparser.json index b5da259fb..21cd43677 100644 --- a/tests/cases/en-big-oldparser/en-big-oldparser.json +++ b/tests/cases/en-big-oldparser/en-big-oldparser.json @@ -848,7 +848,7 @@ "timestamp": "2019-06-25T19:52:00.000Z", "author": "Suffusion of Yellow", "range": [ - "78/0", + "80/0", "80/6/27" ], "signatureRanges": [ @@ -1258,7 +1258,7 @@ "timestamp": "2019-06-26T03:14:00.000Z", "author": "Xaosflux", "range": [ - "93/0", + "95/0", "95/6/26" ], "signatureRanges": [ @@ -2018,7 +2018,7 @@ "timestamp": "2019-06-27T14:52:00.000Z", "author": "Nthep", "range": [ - "109/0", + "111/0/0", "113/4/27" ], "signatureRanges": [ @@ -2894,7 +2894,7 @@ "timestamp": "2019-06-25T19:52:00.000Z", "author": "Suffusion of Yellow", "range": [ - "78/0", + "80/0", "80/6/27" ], "signatureRanges": [ @@ -3304,7 +3304,7 @@ "timestamp": "2019-06-26T03:14:00.000Z", "author": "Xaosflux", "range": [ - "93/0", + "95/0", "95/6/26" ], "signatureRanges": [ @@ -4064,7 +4064,7 @@ "timestamp": "2019-06-27T14:52:00.000Z", "author": "Nthep", "range": [ - "109/0", + "111/0/0", "113/4/27" ], "signatureRanges": [ @@ -6457,7 +6457,7 @@ "timestamp": "2019-07-04T23:34:00.000Z", "author": "Espresso Addict", "range": [ - "281/0", + "283/0", "283/8/25" ], "signatureRanges": [ @@ -11158,7 +11158,7 @@ "timestamp": "2019-07-10T15:27:00.000Z", "author": "GiantSnowman", "range": [ - "480/0", + "484/0", "484/7/26" ], "signatureRanges": [ @@ -11332,7 +11332,7 @@ "timestamp": "2019-07-10T22:52:00.000Z", "author": "BD2412", "range": [ - "496/0", + "498/0", "498/4/26" ], "signatureRanges": [ @@ -12187,7 +12187,7 @@ "timestamp": "2019-07-09T05:05:00.000Z", "author": "Anthonyhcole", "range": [ - "552/0", + "554/0/0", "556/8/27" ], "signatureRanges": [ @@ -13721,7 +13721,7 @@ "timestamp": "2019-07-11T17:44:00.000Z", "author": "Rhododendrites", "range": [ - "670/0", + "672/0", "673/2/29" ], "signatureRanges": [ @@ -18749,7 +18749,7 @@ "timestamp": "2019-07-22T21:52:00.000Z", "author": "SharabSalam", "range": [ - "1013/0", + "1015/0", "1019/4/27" ], "signatureRanges": [ @@ -24574,7 +24574,7 @@ "timestamp": "2019-07-29T22:49:00.000Z", "author": "Fireattack", "range": [ - "1418/0", + "1420/0", "1421/4/27" ], "signatureRanges": [ @@ -24711,7 +24711,7 @@ "timestamp": "2019-08-14T07:31:00.000Z", "author": "SoWhy", "range": [ - "1431/0", + "1435/0", "1435/3/28" ], "signatureRanges": [ @@ -28796,7 +28796,7 @@ "timestamp": "2019-08-18T17:57:00.000Z", "author": "RoySmith", "range": [ - "1606/0", + "1608/0", "1628/4/28" ], "signatureRanges": [ diff --git a/tests/cases/en-big-parsoid/en-big-parsoid-getHTML.json b/tests/cases/en-big-parsoid/en-big-parsoid-getHTML.json index 354dcca69..099720eca 100644 --- a/tests/cases/en-big-parsoid/en-big-parsoid-getHTML.json +++ b/tests/cases/en-big-parsoid/en-big-parsoid-getHTML.json @@ -43,7 +43,7 @@ "c-KIENGIR-2019-07-02T10:39:00.000Z-Redrose64-2019-07-01T20:36:00.000Z": "

      @Redrose64:,

      \n\n

      Thank you it helped, I applied similar tweaks descibred there (in the detailed settings changing to 30 days and enabling 1000 entries as maximum). though, still I don't have 30 days, I assume mainly because of the 1000 entry limitation (I don't know where would be the url to tweak it higher). Thus practically I could go back two weeks, so my initial problem has been solved (going back between 4-7 days)...maybe as an important note for the others or the developers, even this worked only by unchecking the \"Expand watchlist to show all changes, not just the most recent\" in the Advanced Options...(initially at the first tweak attempt, I automatically checked this box assuming it is essential, but anything written above did not work until it was unchecked, ironically it had a contraproductive effect despite it's name...(

      ", "h-Issues_with_alerts,_June_2019": "Issues with alerts, June 2019", "h-Missing_notification_icons_in_MonoBook-Issues_with_alerts,_June_2019-2019-06-25T19:52:00.000Z": "Missing notification icons in MonoBook", - "c-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z-Missing_notification_icons_in_MonoBook": "\n

      I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503.

      ", + "c-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z-Missing_notification_icons_in_MonoBook": "I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503.", "c-Redrose64-2019-06-25T20:21:00.000Z-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z": "I'm getting it in MonoBook too. The appropriate CSS rules are present in the stylesheets: 
      .oo-ui-icon-bell, .mw-ui-icon-bell:before {\n    background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=bell&format=rasterized&lang=en&skin=monobook);\n    background-image: linear-gradient(transparent,transparent),url(\"data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Ebell%3C/title%3E%3Cpath d=%22M16 7a5.38 5.38 0 0 0-4.46-4.85C11.6 1.46 11.53 0 10 0S8.4 1.46 8.46 2.15A5.38 5.38 0 0 0 4 7v6l-2 2v1h16v-1l-2-2zm-6 13a3 3 0 0 0 3-3H7a3 3 0 0 0 3 3z%22/%3E%3C/svg%3E\");\n}\n.oo-ui-icon-tray, .mw-ui-icon-tray:before {\n    background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=tray&format=rasterized&lang=en&skin=monobook);\n    background-image: linear-gradient(transparent,transparent),url(\"data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Etray%3C/title%3E%3Cpath d=%22M3 1a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V3a2 2 0 0 0-2-2zm14 12h-4l-1 2H8l-1-2H3V3h14z%22/%3E%3C/svg%3E\");\n}\n
      Switching to Vector displays them properly, even though the CSS rules are virtually identical - the only differences are that the word \"monobook\" becomes \"vector\" in the first and third url(...) value.", "c-Killiondude-2019-06-25T23:42:00.000Z-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z": "Um, did the fix also give a ton of scroll-space to the right of anyone else's window? I can now scroll for a very long time to the right, despite there being no content.", "c-Suffusion_of_Yellow-2019-06-25T23:45:00.000Z-Killiondude-2019-06-25T23:42:00.000Z": "@Killiondude: Yes, I see the same thing. (Firefox 67, Linux)", @@ -63,7 +63,7 @@ "c-Suffusion_of_Yellow-2019-06-29T19:54:00.000Z-Missing_notification_icons_in_MonoBook": "

      @Bishonen: Ok, try putting:

      .skin-monobook #pt-notifications-notice .mw-echo-notifications-badge, .skin-monobook #pt-notifications-alert .mw-echo-notifications-badge {\n\ttext-align: left;\n}\n

      in your meta:Special:MyPage/global.css.

      ", "c-Bishonen-2019-06-29T20:20:00.000Z-Suffusion_of_Yellow-2019-06-29T19:54:00.000Z": "Suffusion of Yellow, now you're talking my language. It seems to work. Thank you.", "h-Excessive_width_on_monobook-Issues_with_alerts,_June_2019-2019-06-26T03:14:00.000Z": "Excessive width on monobook", - "c-Xaosflux-2019-06-26T03:14:00.000Z-Excessive_width_on_monobook": "\n

      So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above.

      ", + "c-Xaosflux-2019-06-26T03:14:00.000Z-Excessive_width_on_monobook": "So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above.", "c-Xaosflux-2019-06-26T03:41:00.000Z-Xaosflux-2019-06-26T03:14:00.000Z": "Merged to phab:T226594.", "c-Lugnuts-2019-06-26T06:54:00.000Z-Xaosflux-2019-06-26T03:41:00.000Z": "Thank you. Just noticed this, and thought it was a broken ref spilling across the page I was on!", "c-RainFall-2019-06-26T07:13:00.000Z-Xaosflux-2019-06-26T03:14:00.000Z": "Jeez. Hadn't noticed. Can't unsee now. Here's a temporary fix.", @@ -100,7 +100,7 @@ "c-Suffusion_of_Yellow-2019-06-27T22:34:00.000Z-DuncanHill-2019-06-27T22:28:00.000Z": "@DuncanHill: Ideally, that should go in Special:MyPage/monobook.css instead of Special:MyPage/common.css, not I think it will make a big difference.", "c-DuncanHill-2019-06-27T22:40:00.000Z-Suffusion_of_Yellow-2019-06-27T22:34:00.000Z": "Thanks again, have moved it over. Seems to be much the same effect.", "h-Message_&_notification_icons_in_Modern_skin-Issues_with_alerts,_June_2019-2019-06-27T14:52:00.000Z": "Message & notification icons in Modern skin", - "c-Nthep-2019-06-27T14:52:00.000Z-Message_&_notification_icons_in_Modern_skin": "\n
      \n

      The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4).

      ", + "c-Nthep-2019-06-27T14:52:00.000Z-Message_&_notification_icons_in_Modern_skin": "
      \n

      The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4).

      ", "c-Xaosflux-2019-06-27T14:57:00.000Z-Nthep-2019-06-27T14:52:00.000Z": "@Nthep: - so in summary - there is a bunch going on and this is coming from upstream not local styles. See phab:T226684 (and some of the discussion at phab:T226594) to catch up on the goings-on.", "c-Nthep-2019-06-27T15:10:00.000Z-Xaosflux-2019-06-27T14:57:00.000Z": "Thanks.", "c-Isarra-2019-07-01T15:55:00.000Z-Nthep-2019-06-27T15:10:00.000Z": "@Nthep: Same as the monobook issues, should be fully fixed at the end of the week/next week depending on how they're doing deployments. Unless you don't like how we fixed it once it does change, in which case do please tell me.", @@ -206,7 +206,7 @@ "c-Redrose64-2019-07-03T23:09:00.000Z-KAVEBEAR-2019-07-03T21:01:00.000Z": "This is not so much a VPT matter as a question for WP:BOTREQ - and I see that an identical thread has been posted at WT:BOTREQ, contrary to WP:MULTI.", "c-Xaosflux-2019-07-04T13:19:00.000Z-KAVEBEAR-2019-07-03T21:01:00.000Z": "To answer the technical question KAVEBEAR, no - assuming this phrase appears in the source text it would require creating another version of the source text for each page (which yes a bot could do, but that is how it would do it). The only way around that would have been if the name was actually a template that could be changed once.", "h-Stuck_tooltips-2019-07-04T23:34:00.000Z": "Stuck tooltips", - "c-Espresso_Addict-2019-07-04T23:34:00.000Z-Stuck_tooltips": "\n

      Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June . Any help appreciated as this is currently on the main page in the In the News section.

      ", + "c-Espresso_Addict-2019-07-04T23:34:00.000Z-Stuck_tooltips": "Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June . Any help appreciated as this is currently on the main page in the In the News section.", "c-Suffusion_of_Yellow-2019-07-04T23:48:00.000Z-Espresso_Addict-2019-07-04T23:34:00.000Z": "@Espresso Addict: It's not just that one page. In fact, I'm not sure that the preview has updated for any page since June 28. See phab:T227033.", "c-Espresso_Addict-2019-07-04T23:52:00.000Z-Suffusion_of_Yellow-2019-07-04T23:48:00.000Z": "Thanks. At least someone is hopefully looking into the issue.", "h-Google_Maps_template_not_displaying_accessdates-2019-07-05T14:02:00.000Z": "Google Maps template not displaying accessdates", @@ -379,7 +379,7 @@ "c-Maile66-2019-07-10T23:26:00.000Z-DuncanHill-2019-07-10T21:26:00.000Z": "Note: This might not be isolated to Wikimedia or Tools. I just got the identical error message at Find A Grave. On second try, Find a Grave loaded.", "c-MusikAnimal-2019-07-10T22:08:00.000Z-DuncanHill-2019-07-10T21:26:00.000Z": "I asked about this at meta:User talk:Whym#WHOIS gateway returning 500 internal server error.", "h-XTools-2019-07-10T15:27:00.000Z": "XTools", - "c-GiantSnowman-2019-07-10T15:27:00.000Z-XTools": "\n\n\n

      I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved?

      ", + "c-GiantSnowman-2019-07-10T15:27:00.000Z-XTools": "I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved?", "c-MusikAnimal-2019-07-10T16:19:00.000Z-GiantSnowman-2019-07-10T15:27:00.000Z": "@GiantSnowman: The limit is there to prevent long-running queries that likely wouldn't finish, and would unnecessarily slow down XTools for everyone else. I can try increasing it a little bit, but we have to have some sort of sane limit. phab:T182182 is about analyzing the most recent 350,000 edits, but I suspect this wouldn't really help because in theory we'd still have to scan all of your contributions to get the most recent 350,000. The issue with Pages Created, specifically, is tracked at phab:T207959. One idea is to use the page creation log (phab:T221730), which is fast, but it would only produce pages you created going back to June 2018.

      It's a tough problem to solve. We have to balance satisfying the needs of our users, such as yourself, while protecting stability and preventing unrealistic queries from being ran. This is compounded by more general issues with the replica databases, such as the inability to estimate how slow queries will be (phab:T188677) and more recently, general slowness following recent schema changes (phab:T226050). In the meantime, you could try using tools that don't have any limits (or the scalability problems that XTools has), such as Sigma's Pages created tool. Sorry for the inconvenience!

      ", "c-MusikAnimal-2019-07-10T16:27:00.000Z-MusikAnimal-2019-07-10T16:19:00.000Z": "I have increased the edit count limit to 400,000. It seems right now, the replicas are going fairly fast. Both Pages Created and Edit Counter didn't time out for your account. I can't promise it will stay that way, though. As an FYI, you can make the Edit Counter go faster by asking only for the data you need, using the checkboxes at https://xtools.wmflabs.org/ec. Best,", "c-GiantSnowman-2019-07-10T16:36:00.000Z-MusikAnimal-2019-07-10T16:27:00.000Z": "Thanks!", @@ -388,7 +388,7 @@ "h-Request_bot_for_auto_archiving-2019-07-12T03:00:00.000Z": "Request bot for auto archiving", "c-QuackGuru-2019-07-12T03:00:00.000Z-Request_bot_for_auto_archiving": "
      \"\" Resolved
      \n

      For talk page. See https://en.wikipedia.org/wiki/Talk:Nicotine_marketing

      ", "h-Alerts_and_alarms-2019-07-10T22:52:00.000Z": "Alerts and alarms", - "c-BD2412-2019-07-10T22:52:00.000Z-Alerts_and_alarms": "\n

      Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created?

      ", + "c-BD2412-2019-07-10T22:52:00.000Z-Alerts_and_alarms": "Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created?", "c-Elizium23-2019-07-10T23:06:00.000Z-BD2412-2019-07-10T22:52:00.000Z": "While this would be a godsend, e.g. for checking back on a talk page in 7 days or so, or allowing a 24-hour 3RR to expire, I am not sure it is MediaWiki's job to be tracking our reminders. That seems to present unnecessary load to the servers for something that individual editors would best be equipped to track locally. I have used Google Calendar and assorted alarm-clock apps to do this, so far.", "c-Xaosflux-2019-07-10T23:12:00.000Z-BD2412-2019-07-10T22:52:00.000Z": "@BD2412: this may be incorporated in the existing feature request: phab:T88781.", "c-Xaosflux-2019-07-10T23:13:00.000Z-Xaosflux-2019-07-10T23:12:00.000Z": "Note though, this is related to phab:T2582 - which has been pending for 10 years.", @@ -432,7 +432,7 @@ "h-watchlist_inaccuracies_again-2019-07-13T22:50:00.000Z": "watchlist inaccuracies again", "c-Joeyconnick-2019-07-13T22:50:00.000Z-watchlist_inaccuracies_again": "My watchlist is again showing pages and diffs I have already seen, even though I have it set to show only unseen changes. Bolding of these pages in the list is also inconsistent. Anyone know why this exceptionally fun behaviour has returned?", "h-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers-2019-07-09T05:05:00.000Z": "Citation generator in Visual Editor not working for PMID or PMC numbers", - "c-Anthonyhcole-2019-07-09T05:05:00.000Z-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers": "\n\n
      \n

      It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this.

      ", + "c-Anthonyhcole-2019-07-09T05:05:00.000Z-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers": "
      \n

      It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this.

      ", "c-Headbomb-2019-07-09T05:13:00.000Z-Anthonyhcole-2019-07-09T05:05:00.000Z": "It's a known issue involving the tool labs DNS being blocked or something, see T226088. @AManWithNoPlan: could probably explain in more details what the issue is. ", "c-Anthonyhcole-2019-07-09T05:35:00.000Z-Headbomb-2019-07-09T05:13:00.000Z": "Thanks Headbomb. Seems from this Phabricator discussion that no one knows what the problem is. It's been 3 weeks now, and I can't see that anyone has taken this on as their task - but perhaps I just don't understand how WMF technical people work.", "c-TheDJ-2019-07-09T07:26:00.000Z-Anthonyhcole-2019-07-09T05:35:00.000Z": "Anthonyhcole, there are literally 2 people discussing and analysing network traffic in that ticket... What more are you looking for ? A fix before understanding the cause of the problem is not possible.", @@ -507,7 +507,7 @@ "c-QEDK-2019-07-17T06:37:00.000Z-Winged_Blades_of_Godric-2019-07-17T05:58:00.000Z": "If anyone is interested, but no idea how to proceed, take a look at mw:How_to_become_a_MediaWiki_hacker. Some knowledge of LAMP is necessary.", "c-PrimeHunter-2019-07-17T10:08:00.000Z-Winged_Blades_of_Godric-2019-07-17T05:58:00.000Z": "I have made a related suggestion at MediaWiki talk:Confirmdeletetext#Add link to delete an associated talk page.", "h-\"Publish_changes\"-2019-07-11T17:44:00.000Z": "\"Publish changes\"", - "c-Rhododendrites-2019-07-11T17:44:00.000Z-\"Publish_changes\"": "\n\n

      Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\".

      \n\n

      I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise? —

      ", + "c-Rhododendrites-2019-07-11T17:44:00.000Z-\"Publish_changes\"": "

      Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\".

      \n\n

      I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise? —

      ", "c-Iridescent-2019-07-11T17:49:00.000Z-Rhododendrites-2019-07-11T17:44:00.000Z": "IIRC this change was made by WMF legal and is non-negotiable; they wanted to make it clear to editors that the moment one clicks that button, whatever is in your edit window becomes publicly available for anyone to view and not saved to a private userspace inaccessable to others, whatever the namespace being edited. It was a global change, so the discussions will I assume be on Meta. The announcement was here, so the discussions if there were any will be shortly before that. ‑", "c-JoJo_Eumerus_mobile-2019-07-11T18:44:00.000Z-Iridescent-2019-07-11T17:49:00.000Z": "I recall seeing some discussion on Phabricator; I'll see if I can find links.", "c-Snaevar-2019-07-11T19:32:00.000Z-Rhododendrites-2019-07-11T17:44:00.000Z": "Actually the save button was changed to \"publish changes\" because of newbies. In UX testing newbies did expect the save button to work more like drafts. There was a need to change the text of the button to be more decisive. The bug behind this change is T131132, which explains this further.", @@ -736,7 +736,7 @@ "c-Mathglot-2019-08-01T17:41:00.000Z-Nardog-2019-08-01T09:11:00.000Z": "Thanks, Nardog, for the fix! (Apologies to Paine; not only weren't they the cause of the problem, but that edit was (nearly exactly!) a year ago. I was too tired and in too much of a hurry to see clearly.)", "h-The_notification_button-2019-07-22T21:52:00.000Z": "The notification button", "c-Nardog-2019-08-02T05:45:00.000Z-The_notification_button": "\"\" Resolved: Fixed in the last update of MediaWiki.", - "c-SharabSalam-2019-07-22T21:52:00.000Z-The_notification_button": "\n\n

      Hi, so I am using my mobile.

      \n
      1. Just 1 hour ago, an editor posted a comment in my talk page.
        2. \n
      2. I got a notification.
        3. \n
      3. I didn't click on the notification,
        4. \n
      4. I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.)
        5. \n
      5. I saw the comment diff.
        6. \n
      6. I went to another site, returned to Wikipedia again and saw that the notification button is still red,
        7. \n
      7. I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications.
        8. \n
      8. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again.
        9. \n
      9. Cleared the cache it didn't help still red.
      \n

      So can someone help me to fix this? Thanks.

      ", + "c-SharabSalam-2019-07-22T21:52:00.000Z-The_notification_button": "

      Hi, so I am using my mobile.

      \n
      1. Just 1 hour ago, an editor posted a comment in my talk page.
        2. \n
      2. I got a notification.
        3. \n
      3. I didn't click on the notification,
        4. \n
      4. I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.)
        5. \n
      5. I saw the comment diff.
        6. \n
      6. I went to another site, returned to Wikipedia again and saw that the notification button is still red,
        7. \n
      7. I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications.
        8. \n
      8. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again.
        9. \n
      9. Cleared the cache it didn't help still red.
      \n

      So can someone help me to fix this? Thanks.

      ", "c-SharabSalam-2019-07-22T21:57:00.000Z-SharabSalam-2019-07-22T21:52:00.000Z": "Something I haven't tried; which is to trigger the notification again. I will ping a wrong random editor and see. This usually triggers a notification saying: “the ping was not sent because the user doesn't exist”. agsbshsisbsidsb.", "c-SharabSalam-2019-07-22T21:59:00.000Z-SharabSalam-2019-07-22T21:52:00.000Z": "I got a notification, I clicked, read it, refreshed, the notification button returned red so it didn't help.", "c-Xaosflux-2019-07-22T22:00:00.000Z-SharabSalam-2019-07-22T21:59:00.000Z": "@SharabSalam: if you go to Special:Notifications is it there? Also, I have no idea who User:agsbshsisbsidsb is, will assume you just typed random characters for some reason?", @@ -1026,14 +1026,14 @@ "h-Conflict_between_Template:Shortcut,_lists_and_Microsoft-2019-08-13T20:39:00.000Z": "Conflict between Template:Shortcut, lists and Microsoft", "c-Redrose64-2019-08-13T20:39:00.000Z-Conflict_between_Template:Shortcut,_lists_and_Microsoft": "
      \"\" FYI: Pointer to relevant discussion elsewhere.

      Please see Template talk:Shortcut#When in a list item, Edge and IE have a sad day.

      ", "h-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo-2019-07-29T22:49:00.000Z": "Thumbnail image doesn't show in List of tallest structures in Tokyo", - "c-Fireattack-2019-07-29T22:49:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "\n\n

      The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help.

      \n\n

      Any clue? Thanks.

      ", + "c-Fireattack-2019-07-29T22:49:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "

      The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help.

      \n\n

      Any clue? Thanks.

      ", "c-PrimeHunter-2019-07-30T01:13:00.000Z-Fireattack-2019-07-29T22:49:00.000Z": "It works for me. Try to bypass your own cache.", "c-Fireattack-2019-07-30T10:17:00.000Z-PrimeHunter-2019-07-30T01:13:00.000Z": "

      I think the reason is that particular thumbnail returns the header says \"content-type: application/x-www-form-urlencoded\" instead of common \"image/jpeg\".

      \n

      Can you try to open http://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Shin-marunouchi.Building-2007-01.jpg/100px-Shin-marunouchi.Building-2007-01.jpg directly and see what happens? Here, it will try to download itself instead of just display. I can see this weird behavior in both Firefox and Chrome and it doesn't happen to other images.

      \n

      But in Firefox, it can still display the image this way in <img> tag (but not in Chrome).

      ", "c-George_Ho-2019-08-06T00:13:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Not just this list, some other thumbnail images don't load well at List of Cheers characters, List of Friends characters, and List of The Big Bang Theory and Young Sheldon characters. Check other list pages.", "c-Fireattack-2019-08-06T20:42:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Update: The root cause is Phab:T188831. And about why it starts to cause more apparent issue, see https://bugs.chromium.org/p/chromium/issues/detail?id=990853 .", "c-Master_of_Time-2019-08-14T05:43:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Saw the issue at List of highest-grossing films as well with the first image. Hopefully it will be resolved before long.", "h-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?-2019-08-14T07:31:00.000Z": "How to prevent VisualEditor from automatically loading when clicking red links?", - "c-SoWhy-2019-08-14T07:31:00.000Z-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?": "\n\n

      Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards

      ", + "c-SoWhy-2019-08-14T07:31:00.000Z-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?": "Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards", "c-Ammarpad-2019-08-14T08:21:00.000Z-SoWhy-2019-08-14T07:31:00.000Z": "This is the default behaviour for clicking all redlinks in both VE and Source editor (except Userpage redlink on mobile). There's a phab:T211379 asking to change this and there are comments that this is by design.", "c-SoWhy-2019-08-14T09:13:00.000Z-Ammarpad-2019-08-14T08:21:00.000Z": "@Ammarpad: Thanks for the phab-link! I dug up a snippet at T195914 that prevents it (thanks to Classicwiki). Regards", "c-Xaosflux-2019-08-14T11:39:00.000Z-SoWhy-2019-08-14T09:13:00.000Z": "@SoWhy: have you tried setting \"Temporarily disable the visual editor while it is in beta\" in Special:Preferences#mw-prefsection-editing? I have that set and never get the visual editor unless I specifically switch to it.", @@ -1180,7 +1180,7 @@ "c-QEDK-2019-08-12T17:25:00.000Z-Galobtter-2019-08-12T06:13:00.000Z": "Thanks, @Galobtter:, not quite sure how or where I saw the change, I do appreciate the hack! :)", "c-QEDK-2019-08-19T19:51:00.000Z-QEDK-2019-08-12T17:25:00.000Z": "Thanks, @DannyS712 and Legoktm:!", "h-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random-2019-08-18T17:57:00.000Z": "Picking a draft to review: RandomInCategory isn't very random", - "c-RoySmith-2019-08-18T17:57:00.000Z-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random": "\n

      I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got:

      \n\n
      1. Draft:Declan Meagher
        2. \n
      2. Draft:Gary Soulz
        3. \n
      3. Draft:Ananth Narayanan
        4. \n
      4. Draft:Frank Verboven
        5. \n
      5. Draft:Maths Time Joy
        6. \n
      6. Draft:Gary Soulz
        7. \n
      7. Draft:Ananth Narayanan
        8. \n
      8. Draft:Eni Vasili
        9. \n
      9. Draft:Shorts México - Mexico International Short Film Festival
        10. \n
      10. Category:Pending AfC submissions in userspace
        11. \n
      11. Draft:John Haze
        12. \n
      12. Draft:Alisha Rai (author)
        13. \n
      13. Draft:Leonardo3 Museum
        14. \n
      14. Draft:Wake. (2018 film)
        15. \n
      15. Category:Pending AfC submissions in article space
        16. \n
      16. Draft:Anastasiya Makarevich
        17. \n
      17. Draft:Alisha Rai (author)
        18. \n
      18. User:ItsYaBoiAustin/sandbox/Odyssey: Extraction
        19. \n
      19. Draft:Scott Stambach
        20. \n
      20. Draft:Christian Lillinger
        21. \n
      21. Draft:Gudula Naiga Basaza
        22. \n
      22. Draft:Scott Stambach
        23. \n
      23. Draft:Katherine Boyer
        24. \n
      24. Draft:Walter Ferguson
        25. \n
      25. Draft:Faryal Mehmood
      \n\n

      Not only are there four duplicates:

      \n\n
      • Draft:Scott Stambach
        • \n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
        • \n
      • Draft:Alisha Rai (author)
      \n\n

      but two pairs of duplicates in the same order:

      \n\n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
      \n\n

      There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much.

      \n\n

      Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap.

      \n\n

      My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations:

      \n\n
      0.000249\n0.000489\n0.000508\n0.000544\n0.000573\n0.000536\n0.000559\n0.000568\n0.000563\n0.000599\n
      \n\n

      That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing.

      \n\n

      Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.

      \n\n

      ", + "c-RoySmith-2019-08-18T17:57:00.000Z-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random": "

      I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got:

      \n\n
      1. Draft:Declan Meagher
        2. \n
      2. Draft:Gary Soulz
        3. \n
      3. Draft:Ananth Narayanan
        4. \n
      4. Draft:Frank Verboven
        5. \n
      5. Draft:Maths Time Joy
        6. \n
      6. Draft:Gary Soulz
        7. \n
      7. Draft:Ananth Narayanan
        8. \n
      8. Draft:Eni Vasili
        9. \n
      9. Draft:Shorts México - Mexico International Short Film Festival
        10. \n
      10. Category:Pending AfC submissions in userspace
        11. \n
      11. Draft:John Haze
        12. \n
      12. Draft:Alisha Rai (author)
        13. \n
      13. Draft:Leonardo3 Museum
        14. \n
      14. Draft:Wake. (2018 film)
        15. \n
      15. Category:Pending AfC submissions in article space
        16. \n
      16. Draft:Anastasiya Makarevich
        17. \n
      17. Draft:Alisha Rai (author)
        18. \n
      18. User:ItsYaBoiAustin/sandbox/Odyssey: Extraction
        19. \n
      19. Draft:Scott Stambach
        20. \n
      20. Draft:Christian Lillinger
        21. \n
      21. Draft:Gudula Naiga Basaza
        22. \n
      22. Draft:Scott Stambach
        23. \n
      23. Draft:Katherine Boyer
        24. \n
      24. Draft:Walter Ferguson
        25. \n
      25. Draft:Faryal Mehmood
      \n\n

      Not only are there four duplicates:

      \n\n
      • Draft:Scott Stambach
        • \n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
        • \n
      • Draft:Alisha Rai (author)
      \n\n

      but two pairs of duplicates in the same order:

      \n\n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
      \n\n

      There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much.

      \n\n

      Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap.

      \n\n

      My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations:

      \n\n
      0.000249\n0.000489\n0.000508\n0.000544\n0.000573\n0.000536\n0.000559\n0.000568\n0.000563\n0.000599\n
      \n\n

      That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing.

      \n\n

      Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.

      \n\n

      ", "c-Guy_Macon-2019-08-18T18:43:00.000Z-RoySmith-2019-08-18T17:57:00.000Z": "Good catch! Would this be a good candidate for a Phabricator ticket?", "c-Huji-2019-08-18T18:58:00.000Z-RoySmith-2019-08-18T17:57:00.000Z": "

      Huh! I am virtually never active on enwiki. I happened to open the thread right above this one and see this as a result. I also happen to be the person who wrote RandomInCategory!

      \n

      I think it is best to move this to Phab. Essentially (if I understand it well) the problem is that page_random is (hopefully) uniformly distributed across all pages; but when thinking about a small category, its values will certainly not be uniformly distributed. There exist ways through which we could circumvent this, but I'm not sure if these ways are efficient enough to be adopted into MW source code. It is best to have that discussion in Phab, where more technical users can discuss its efficiency (or propose more efficient implementations of it). Please add me (Huji) on Phab once you create the task.

      ", "c-RoySmith-2019-08-18T19:11:00.000Z-Huji-2019-08-18T18:58:00.000Z": "I'm happy to open a Phab ticket, but I'm not sure what the ticket should say. The problem isn't (I don't think) that RandomInCategory is broken. I think the current implementation actually a pretty good solution for its intended purpose, which I assume is driving the \"Random article\" link on the main page. It's just that how we use it for managing the draft work queue is not a good fit.", diff --git a/tests/cases/en-big-parsoid/en-big-parsoid-getText.json b/tests/cases/en-big-parsoid/en-big-parsoid-getText.json index 765c035ca..3956a99d1 100644 --- a/tests/cases/en-big-parsoid/en-big-parsoid-getText.json +++ b/tests/cases/en-big-parsoid/en-big-parsoid-getText.json @@ -43,7 +43,7 @@ "c-KIENGIR-2019-07-02T10:39:00.000Z-Redrose64-2019-07-01T20:36:00.000Z": "@Redrose64:, Thank you it helped, I applied similar tweaks descibred there (in the detailed settings changing to 30 days and enabling 1000 entries as maximum). though, still I don't have 30 days, I assume mainly because of the 1000 entry limitation (I don't know where would be the url to tweak it higher). Thus practically I could go back two weeks, so my initial problem has been solved (going back between 4-7 days)...maybe as an important note for the others or the developers, even this worked only by unchecking the \"Expand watchlist to show all changes, not just the most recent\" in the Advanced Options...(initially at the first tweak attempt, I automatically checked this box assuming it is essential, but anything written above did not work until it was unchecked, ironically it had a contraproductive effect despite it's name...(", "h-Issues_with_alerts,_June_2019": "Issues with alerts, June 2019", "h-Missing_notification_icons_in_MonoBook-Issues_with_alerts,_June_2019-2019-06-25T19:52:00.000Z": "Missing notification icons in MonoBook", - "c-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z-Missing_notification_icons_in_MonoBook": "Tracked in Phabricator Task T226503 I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503.", + "c-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z-Missing_notification_icons_in_MonoBook": "I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503.", "c-Redrose64-2019-06-25T20:21:00.000Z-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z": "I'm getting it in MonoBook too. The appropriate CSS rules are present in the stylesheets: .oo-ui-icon-bell, .mw-ui-icon-bell:before { background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=bell&format=rasterized&lang=en&skin=monobook); background-image: linear-gradient(transparent,transparent),url(\"data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Ebell%3C/title%3E%3Cpath d=%22M16 7a5.38 5.38 0 0 0-4.46-4.85C11.6 1.46 11.53 0 10 0S8.4 1.46 8.46 2.15A5.38 5.38 0 0 0 4 7v6l-2 2v1h16v-1l-2-2zm-6 13a3 3 0 0 0 3-3H7a3 3 0 0 0 3 3z%22/%3E%3C/svg%3E\"); } .oo-ui-icon-tray, .mw-ui-icon-tray:before { background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=tray&format=rasterized&lang=en&skin=monobook); background-image: linear-gradient(transparent,transparent),url(\"data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Etray%3C/title%3E%3Cpath d=%22M3 1a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V3a2 2 0 0 0-2-2zm14 12h-4l-1 2H8l-1-2H3V3h14z%22/%3E%3C/svg%3E\"); } Switching to Vector displays them properly, even though the CSS rules are virtually identical - the only differences are that the word \"monobook\" becomes \"vector\" in the first and third url(...) value.", "c-Killiondude-2019-06-25T23:42:00.000Z-Suffusion_of_Yellow-2019-06-25T19:52:00.000Z": "Um, did the fix also give a ton of scroll-space to the right of anyone else's window? I can now scroll for a very long time to the right, despite there being no content.", "c-Suffusion_of_Yellow-2019-06-25T23:45:00.000Z-Killiondude-2019-06-25T23:42:00.000Z": "@Killiondude: Yes, I see the same thing. (Firefox 67, Linux)", @@ -63,7 +63,7 @@ "c-Suffusion_of_Yellow-2019-06-29T19:54:00.000Z-Missing_notification_icons_in_MonoBook": "@Bishonen: Ok, try putting: .skin-monobook #pt-notifications-notice .mw-echo-notifications-badge, .skin-monobook #pt-notifications-alert .mw-echo-notifications-badge { text-align: left; } in your meta:Special:MyPage/global.css.", "c-Bishonen-2019-06-29T20:20:00.000Z-Suffusion_of_Yellow-2019-06-29T19:54:00.000Z": "Suffusion of Yellow, now you're talking my language. It seems to work. Thank you.", "h-Excessive_width_on_monobook-Issues_with_alerts,_June_2019-2019-06-26T03:14:00.000Z": "Excessive width on monobook", - "c-Xaosflux-2019-06-26T03:14:00.000Z-Excessive_width_on_monobook": "Tracked in Phabricator Task T226594 So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above.", + "c-Xaosflux-2019-06-26T03:14:00.000Z-Excessive_width_on_monobook": "So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above.", "c-Xaosflux-2019-06-26T03:41:00.000Z-Xaosflux-2019-06-26T03:14:00.000Z": "Merged to phab:T226594.", "c-Lugnuts-2019-06-26T06:54:00.000Z-Xaosflux-2019-06-26T03:41:00.000Z": "Thank you. Just noticed this, and thought it was a broken ref spilling across the page I was on!", "c-RainFall-2019-06-26T07:13:00.000Z-Xaosflux-2019-06-26T03:14:00.000Z": "Jeez. Hadn't noticed. Can't unsee now. Here's a temporary fix.", @@ -100,7 +100,7 @@ "c-Suffusion_of_Yellow-2019-06-27T22:34:00.000Z-DuncanHill-2019-06-27T22:28:00.000Z": "@DuncanHill: Ideally, that should go in Special:MyPage/monobook.css instead of Special:MyPage/common.css, not I think it will make a big difference.", "c-DuncanHill-2019-06-27T22:40:00.000Z-Suffusion_of_Yellow-2019-06-27T22:34:00.000Z": "Thanks again, have moved it over. Seems to be much the same effect.", "h-Message_&_notification_icons_in_Modern_skin-Issues_with_alerts,_June_2019-2019-06-27T14:52:00.000Z": "Message & notification icons in Modern skin", - "c-Nthep-2019-06-27T14:52:00.000Z-Message_&_notification_icons_in_Modern_skin": "Tracked in Phabricator Task T226684 The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4).", + "c-Nthep-2019-06-27T14:52:00.000Z-Message_&_notification_icons_in_Modern_skin": "The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4).", "c-Xaosflux-2019-06-27T14:57:00.000Z-Nthep-2019-06-27T14:52:00.000Z": "@Nthep: - so in summary - there is a bunch going on and this is coming from upstream not local styles. See phab:T226684 (and some of the discussion at phab:T226594) to catch up on the goings-on.", "c-Nthep-2019-06-27T15:10:00.000Z-Xaosflux-2019-06-27T14:57:00.000Z": "Thanks.", "c-Isarra-2019-07-01T15:55:00.000Z-Nthep-2019-06-27T15:10:00.000Z": "@Nthep: Same as the monobook issues, should be fully fixed at the end of the week/next week depending on how they're doing deployments. Unless you don't like how we fixed it once it does change, in which case do please tell me.", @@ -206,7 +206,7 @@ "c-Redrose64-2019-07-03T23:09:00.000Z-KAVEBEAR-2019-07-03T21:01:00.000Z": "This is not so much a VPT matter as a question for WP:BOTREQ - and I see that an identical thread has been posted at WT:BOTREQ, contrary to WP:MULTI.", "c-Xaosflux-2019-07-04T13:19:00.000Z-KAVEBEAR-2019-07-03T21:01:00.000Z": "To answer the technical question KAVEBEAR, no - assuming this phrase appears in the source text it would require creating another version of the source text for each page (which yes a bot could do, but that is how it would do it). The only way around that would have been if the name was actually a template that could be changed once.", "h-Stuck_tooltips-2019-07-04T23:34:00.000Z": "Stuck tooltips", - "c-Espresso_Addict-2019-07-04T23:34:00.000Z-Stuck_tooltips": "Tracked in Phabricator Task T226983 Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June . Any help appreciated as this is currently on the main page in the In the News section.", + "c-Espresso_Addict-2019-07-04T23:34:00.000Z-Stuck_tooltips": "Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June . Any help appreciated as this is currently on the main page in the In the News section.", "c-Suffusion_of_Yellow-2019-07-04T23:48:00.000Z-Espresso_Addict-2019-07-04T23:34:00.000Z": "@Espresso Addict: It's not just that one page. In fact, I'm not sure that the preview has updated for any page since June 28. See phab:T227033.", "c-Espresso_Addict-2019-07-04T23:52:00.000Z-Suffusion_of_Yellow-2019-07-04T23:48:00.000Z": "Thanks. At least someone is hopefully looking into the issue.", "h-Google_Maps_template_not_displaying_accessdates-2019-07-05T14:02:00.000Z": "Google Maps template not displaying accessdates", @@ -379,7 +379,7 @@ "c-Maile66-2019-07-10T23:26:00.000Z-DuncanHill-2019-07-10T21:26:00.000Z": "Note: This might not be isolated to Wikimedia or Tools. I just got the identical error message at Find A Grave. On second try, Find a Grave loaded.", "c-MusikAnimal-2019-07-10T22:08:00.000Z-DuncanHill-2019-07-10T21:26:00.000Z": "I asked about this at meta:User talk:Whym#WHOIS gateway returning 500 internal server error.", "h-XTools-2019-07-10T15:27:00.000Z": "XTools", - "c-GiantSnowman-2019-07-10T15:27:00.000Z-XTools": "Tracked in Phabricator Task T207959 Tracked in Phabricator Task T182182 I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved?", + "c-GiantSnowman-2019-07-10T15:27:00.000Z-XTools": "I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved?", "c-MusikAnimal-2019-07-10T16:19:00.000Z-GiantSnowman-2019-07-10T15:27:00.000Z": "@GiantSnowman: The limit is there to prevent long-running queries that likely wouldn't finish, and would unnecessarily slow down XTools for everyone else. I can try increasing it a little bit, but we have to have some sort of sane limit. phab:T182182 is about analyzing the most recent 350,000 edits, but I suspect this wouldn't really help because in theory we'd still have to scan all of your contributions to get the most recent 350,000. The issue with Pages Created, specifically, is tracked at phab:T207959. One idea is to use the page creation log (phab:T221730), which is fast, but it would only produce pages you created going back to June 2018. It's a tough problem to solve. We have to balance satisfying the needs of our users, such as yourself, while protecting stability and preventing unrealistic queries from being ran. This is compounded by more general issues with the replica databases, such as the inability to estimate how slow queries will be (phab:T188677) and more recently, general slowness following recent schema changes (phab:T226050). In the meantime, you could try using tools that don't have any limits (or the scalability problems that XTools has), such as Sigma's Pages created tool. Sorry for the inconvenience!", "c-MusikAnimal-2019-07-10T16:27:00.000Z-MusikAnimal-2019-07-10T16:19:00.000Z": "I have increased the edit count limit to 400,000. It seems right now, the replicas are going fairly fast. Both Pages Created and Edit Counter didn't time out for your account. I can't promise it will stay that way, though. As an FYI, you can make the Edit Counter go faster by asking only for the data you need, using the checkboxes at https://xtools.wmflabs.org/ec. Best,", "c-GiantSnowman-2019-07-10T16:36:00.000Z-MusikAnimal-2019-07-10T16:27:00.000Z": "Thanks!", @@ -388,7 +388,7 @@ "h-Request_bot_for_auto_archiving-2019-07-12T03:00:00.000Z": "Request bot for auto archiving", "c-QuackGuru-2019-07-12T03:00:00.000Z-Request_bot_for_auto_archiving": "Resolved For talk page. See https://en.wikipedia.org/wiki/Talk:Nicotine_marketing", "h-Alerts_and_alarms-2019-07-10T22:52:00.000Z": "Alerts and alarms", - "c-BD2412-2019-07-10T22:52:00.000Z-Alerts_and_alarms": "Tracked in Phabricator Task T88781 Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created?", + "c-BD2412-2019-07-10T22:52:00.000Z-Alerts_and_alarms": "Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created?", "c-Elizium23-2019-07-10T23:06:00.000Z-BD2412-2019-07-10T22:52:00.000Z": "While this would be a godsend, e.g. for checking back on a talk page in 7 days or so, or allowing a 24-hour 3RR to expire, I am not sure it is MediaWiki's job to be tracking our reminders. That seems to present unnecessary load to the servers for something that individual editors would best be equipped to track locally. I have used Google Calendar and assorted alarm-clock apps to do this, so far.", "c-Xaosflux-2019-07-10T23:12:00.000Z-BD2412-2019-07-10T22:52:00.000Z": "@BD2412: this may be incorporated in the existing feature request: phab:T88781.", "c-Xaosflux-2019-07-10T23:13:00.000Z-Xaosflux-2019-07-10T23:12:00.000Z": "Note though, this is related to phab:T2582 - which has been pending for 10 years.", @@ -432,7 +432,7 @@ "h-watchlist_inaccuracies_again-2019-07-13T22:50:00.000Z": "watchlist inaccuracies again", "c-Joeyconnick-2019-07-13T22:50:00.000Z-watchlist_inaccuracies_again": "My watchlist is again showing pages and diffs I have already seen, even though I have it set to show only unseen changes. Bolding of these pages in the list is also inconsistent. Anyone know why this exceptionally fun behaviour has returned?", "h-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers-2019-07-09T05:05:00.000Z": "Citation generator in Visual Editor not working for PMID or PMC numbers", - "c-Anthonyhcole-2019-07-09T05:05:00.000Z-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers": "Tracked in Phabricator Task T227415 It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this.", + "c-Anthonyhcole-2019-07-09T05:05:00.000Z-Citation_generator_in_Visual_Editor_not_working_for_PMID_or_PMC_numbers": "It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this.", "c-Headbomb-2019-07-09T05:13:00.000Z-Anthonyhcole-2019-07-09T05:05:00.000Z": "It's a known issue involving the tool labs DNS being blocked or something, see T226088. @AManWithNoPlan: could probably explain in more details what the issue is.", "c-Anthonyhcole-2019-07-09T05:35:00.000Z-Headbomb-2019-07-09T05:13:00.000Z": "Thanks Headbomb. Seems from this Phabricator discussion that no one knows what the problem is. It's been 3 weeks now, and I can't see that anyone has taken this on as their task - but perhaps I just don't understand how WMF technical people work.", "c-TheDJ-2019-07-09T07:26:00.000Z-Anthonyhcole-2019-07-09T05:35:00.000Z": "Anthonyhcole, there are literally 2 people discussing and analysing network traffic in that ticket... What more are you looking for ? A fix before understanding the cause of the problem is not possible.", @@ -507,7 +507,7 @@ "c-QEDK-2019-07-17T06:37:00.000Z-Winged_Blades_of_Godric-2019-07-17T05:58:00.000Z": "If anyone is interested, but no idea how to proceed, take a look at mw:How_to_become_a_MediaWiki_hacker. Some knowledge of LAMP is necessary.", "c-PrimeHunter-2019-07-17T10:08:00.000Z-Winged_Blades_of_Godric-2019-07-17T05:58:00.000Z": "I have made a related suggestion at MediaWiki talk:Confirmdeletetext#Add link to delete an associated talk page.", "h-\"Publish_changes\"-2019-07-11T17:44:00.000Z": "\"Publish changes\"", - "c-Rhododendrites-2019-07-11T17:44:00.000Z-\"Publish_changes\"": "Tracked in Phabricator Task T228116 Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\". I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise? —", + "c-Rhododendrites-2019-07-11T17:44:00.000Z-\"Publish_changes\"": "Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\". I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise? —", "c-Iridescent-2019-07-11T17:49:00.000Z-Rhododendrites-2019-07-11T17:44:00.000Z": "IIRC this change was made by WMF legal and is non-negotiable; they wanted to make it clear to editors that the moment one clicks that button, whatever is in your edit window becomes publicly available for anyone to view and not saved to a private userspace inaccessable to others, whatever the namespace being edited. It was a global change, so the discussions will I assume be on Meta. The announcement was here, so the discussions if there were any will be shortly before that. ‑", "c-JoJo_Eumerus_mobile-2019-07-11T18:44:00.000Z-Iridescent-2019-07-11T17:49:00.000Z": "I recall seeing some discussion on Phabricator; I'll see if I can find links.", "c-Snaevar-2019-07-11T19:32:00.000Z-Rhododendrites-2019-07-11T17:44:00.000Z": "Actually the save button was changed to \"publish changes\" because of newbies. In UX testing newbies did expect the save button to work more like drafts. There was a need to change the text of the button to be more decisive. The bug behind this change is T131132, which explains this further.", @@ -736,7 +736,7 @@ "c-Mathglot-2019-08-01T17:41:00.000Z-Nardog-2019-08-01T09:11:00.000Z": "Thanks, Nardog, for the fix! (Apologies to Paine; not only weren't they the cause of the problem, but that edit was (nearly exactly!) a year ago. I was too tired and in too much of a hurry to see clearly.)", "h-The_notification_button-2019-07-22T21:52:00.000Z": "The notification button", "c-Nardog-2019-08-02T05:45:00.000Z-The_notification_button": "Resolved: Fixed in the last update of MediaWiki.", - "c-SharabSalam-2019-07-22T21:52:00.000Z-The_notification_button": "Tracked in Phabricator Task T228744 Hi, so I am using my mobile. Just 1 hour ago, an editor posted a comment in my talk page. I got a notification. I didn't click on the notification, I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.) I saw the comment diff. I went to another site, returned to Wikipedia again and saw that the notification button is still red, I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again. Cleared the cache it didn't help still red. So can someone help me to fix this? Thanks.", + "c-SharabSalam-2019-07-22T21:52:00.000Z-The_notification_button": "Hi, so I am using my mobile. Just 1 hour ago, an editor posted a comment in my talk page. I got a notification. I didn't click on the notification, I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.) I saw the comment diff. I went to another site, returned to Wikipedia again and saw that the notification button is still red, I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again. Cleared the cache it didn't help still red. So can someone help me to fix this? Thanks.", "c-SharabSalam-2019-07-22T21:57:00.000Z-SharabSalam-2019-07-22T21:52:00.000Z": "Something I haven't tried; which is to trigger the notification again. I will ping a wrong random editor and see. This usually triggers a notification saying: “the ping was not sent because the user doesn't exist”. agsbshsisbsidsb.", "c-SharabSalam-2019-07-22T21:59:00.000Z-SharabSalam-2019-07-22T21:52:00.000Z": "I got a notification, I clicked, read it, refreshed, the notification button returned red so it didn't help.", "c-Xaosflux-2019-07-22T22:00:00.000Z-SharabSalam-2019-07-22T21:59:00.000Z": "@SharabSalam: if you go to Special:Notifications is it there? Also, I have no idea who User:agsbshsisbsidsb is, will assume you just typed random characters for some reason?", @@ -1026,14 +1026,14 @@ "h-Conflict_between_Template:Shortcut,_lists_and_Microsoft-2019-08-13T20:39:00.000Z": "Conflict between Template:Shortcut, lists and Microsoft", "c-Redrose64-2019-08-13T20:39:00.000Z-Conflict_between_Template:Shortcut,_lists_and_Microsoft": "FYI: Pointer to relevant discussion elsewhere. Please see Template talk:Shortcut#When in a list item, Edge and IE have a sad day.", "h-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo-2019-07-29T22:49:00.000Z": "Thumbnail image doesn't show in List of tallest structures in Tokyo", - "c-Fireattack-2019-07-29T22:49:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Tracked in Phabricator Task T188831 The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help. Any clue? Thanks.", + "c-Fireattack-2019-07-29T22:49:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help. Any clue? Thanks.", "c-PrimeHunter-2019-07-30T01:13:00.000Z-Fireattack-2019-07-29T22:49:00.000Z": "It works for me. Try to bypass your own cache.", "c-Fireattack-2019-07-30T10:17:00.000Z-PrimeHunter-2019-07-30T01:13:00.000Z": "I think the reason is that particular thumbnail returns the header says \"content-type: application/x-www-form-urlencoded\" instead of common \"image/jpeg\". Can you try to open http://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Shin-marunouchi.Building-2007-01.jpg/100px-Shin-marunouchi.Building-2007-01.jpg directly and see what happens? Here, it will try to download itself instead of just display. I can see this weird behavior in both Firefox and Chrome and it doesn't happen to other images. But in Firefox, it can still display the image this way in tag (but not in Chrome).", "c-George_Ho-2019-08-06T00:13:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Not just this list, some other thumbnail images don't load well at List of Cheers characters, List of Friends characters, and List of The Big Bang Theory and Young Sheldon characters. Check other list pages.", "c-Fireattack-2019-08-06T20:42:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Update: The root cause is Phab:T188831. And about why it starts to cause more apparent issue, see https://bugs.chromium.org/p/chromium/issues/detail?id=990853 .", "c-Master_of_Time-2019-08-14T05:43:00.000Z-Thumbnail_image_doesn't_show_in_List_of_tallest_structures_in_Tokyo": "Saw the issue at List of highest-grossing films as well with the first image. Hopefully it will be resolved before long.", "h-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?-2019-08-14T07:31:00.000Z": "How to prevent VisualEditor from automatically loading when clicking red links?", - "c-SoWhy-2019-08-14T07:31:00.000Z-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?": "Tracked in Phabricator Task T211379 Tracked in Phabricator Task T226267 Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards", + "c-SoWhy-2019-08-14T07:31:00.000Z-How_to_prevent_VisualEditor_from_automatically_loading_when_clicking_red_links?": "Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards", "c-Ammarpad-2019-08-14T08:21:00.000Z-SoWhy-2019-08-14T07:31:00.000Z": "This is the default behaviour for clicking all redlinks in both VE and Source editor (except Userpage redlink on mobile). There's a phab:T211379 asking to change this and there are comments that this is by design.", "c-SoWhy-2019-08-14T09:13:00.000Z-Ammarpad-2019-08-14T08:21:00.000Z": "@Ammarpad: Thanks for the phab-link! I dug up a snippet at T195914 that prevents it (thanks to Classicwiki). Regards", "c-Xaosflux-2019-08-14T11:39:00.000Z-SoWhy-2019-08-14T09:13:00.000Z": "@SoWhy: have you tried setting \"Temporarily disable the visual editor while it is in beta\" in Special:Preferences#mw-prefsection-editing? I have that set and never get the visual editor unless I specifically switch to it.", @@ -1180,7 +1180,7 @@ "c-QEDK-2019-08-12T17:25:00.000Z-Galobtter-2019-08-12T06:13:00.000Z": "Thanks, @Galobtter:, not quite sure how or where I saw the change, I do appreciate the hack! :)", "c-QEDK-2019-08-19T19:51:00.000Z-QEDK-2019-08-12T17:25:00.000Z": "Thanks, @DannyS712 and Legoktm:!", "h-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random-2019-08-18T17:57:00.000Z": "Picking a draft to review: RandomInCategory isn't very random", - "c-RoySmith-2019-08-18T17:57:00.000Z-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random": "Tracked in Phabricator Task T200703 I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got: Draft:Declan Meagher Draft:Gary Soulz Draft:Ananth Narayanan Draft:Frank Verboven Draft:Maths Time Joy Draft:Gary Soulz Draft:Ananth Narayanan Draft:Eni Vasili Draft:Shorts México - Mexico International Short Film Festival Category:Pending AfC submissions in userspace Draft:John Haze Draft:Alisha Rai (author) Draft:Leonardo3 Museum Draft:Wake. (2018 film) Category:Pending AfC submissions in article space Draft:Anastasiya Makarevich Draft:Alisha Rai (author) User:ItsYaBoiAustin/sandbox/Odyssey: Extraction Draft:Scott Stambach Draft:Christian Lillinger Draft:Gudula Naiga Basaza Draft:Scott Stambach Draft:Katherine Boyer Draft:Walter Ferguson Draft:Faryal Mehmood Not only are there four duplicates: Draft:Scott Stambach Draft:Gary Soulz Draft:Ananth Narayanan Draft:Alisha Rai (author) but two pairs of duplicates in the same order: Draft:Gary Soulz Draft:Ananth Narayanan There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much. Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap. My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations: 0.000249 0.000489 0.000508 0.000544 0.000573 0.000536 0.000559 0.000568 0.000563 0.000599 That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing. Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.", + "c-RoySmith-2019-08-18T17:57:00.000Z-Picking_a_draft_to_review:_RandomInCategory_isn't_very_random": "I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got: Draft:Declan Meagher Draft:Gary Soulz Draft:Ananth Narayanan Draft:Frank Verboven Draft:Maths Time Joy Draft:Gary Soulz Draft:Ananth Narayanan Draft:Eni Vasili Draft:Shorts México - Mexico International Short Film Festival Category:Pending AfC submissions in userspace Draft:John Haze Draft:Alisha Rai (author) Draft:Leonardo3 Museum Draft:Wake. (2018 film) Category:Pending AfC submissions in article space Draft:Anastasiya Makarevich Draft:Alisha Rai (author) User:ItsYaBoiAustin/sandbox/Odyssey: Extraction Draft:Scott Stambach Draft:Christian Lillinger Draft:Gudula Naiga Basaza Draft:Scott Stambach Draft:Katherine Boyer Draft:Walter Ferguson Draft:Faryal Mehmood Not only are there four duplicates: Draft:Scott Stambach Draft:Gary Soulz Draft:Ananth Narayanan Draft:Alisha Rai (author) but two pairs of duplicates in the same order: Draft:Gary Soulz Draft:Ananth Narayanan There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much. Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap. My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations: 0.000249 0.000489 0.000508 0.000544 0.000573 0.000536 0.000559 0.000568 0.000563 0.000599 That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing. Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.", "c-Guy_Macon-2019-08-18T18:43:00.000Z-RoySmith-2019-08-18T17:57:00.000Z": "Good catch! Would this be a good candidate for a Phabricator ticket?", "c-Huji-2019-08-18T18:58:00.000Z-RoySmith-2019-08-18T17:57:00.000Z": "Huh! I am virtually never active on enwiki. I happened to open the thread right above this one and see this as a result. I also happen to be the person who wrote RandomInCategory! I think it is best to move this to Phab. Essentially (if I understand it well) the problem is that page_random is (hopefully) uniformly distributed across all pages; but when thinking about a small category, its values will certainly not be uniformly distributed. There exist ways through which we could circumvent this, but I'm not sure if these ways are efficient enough to be adopted into MW source code. It is best to have that discussion in Phab, where more technical users can discuss its efficiency (or propose more efficient implementations of it). Please add me (Huji) on Phab once you create the task.", "c-RoySmith-2019-08-18T19:11:00.000Z-Huji-2019-08-18T18:58:00.000Z": "I'm happy to open a Phab ticket, but I'm not sure what the ticket should say. The problem isn't (I don't think) that RandomInCategory is broken. I think the current implementation actually a pretty good solution for its intended purpose, which I assume is driving the \"Random article\" link on the main page. It's just that how we use it for managing the draft work queue is not a good fit.", diff --git a/tests/cases/en-big-parsoid/en-big-parsoid-threadItemsHtml.json b/tests/cases/en-big-parsoid/en-big-parsoid-threadItemsHtml.json index 069bdf12a..a02d69099 100644 --- a/tests/cases/en-big-parsoid/en-big-parsoid-threadItemsHtml.json +++ b/tests/cases/en-big-parsoid/en-big-parsoid-threadItemsHtml.json @@ -591,7 +591,7 @@ "author": "Killiondude" } ], - "html": "\n

      I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503. Suffusion of Yellow (talk) 19:52, 25 June 2019 (UTC)

      ", + "html": "I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503. Suffusion of Yellow (talk) 19:52, 25 June 2019 (UTC)", "timestamp": "2019-06-25T19:52:00.000Z", "author": "Suffusion of Yellow" }, @@ -965,7 +965,7 @@ "author": "Suffusion of Yellow" } ], - "html": "\n

      So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosflux Talk 03:14, 26 June 2019 (UTC)

      ", + "html": "So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosflux Talk 03:14, 26 June 2019 (UTC)", "timestamp": "2019-06-26T03:14:00.000Z", "author": "Xaosflux" } @@ -1014,7 +1014,7 @@ "author": "Xaosflux" } ], - "html": "\n
      \n

      The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4). Nthep (talk) 14:52, 27 June 2019 (UTC)

      ", + "html": "
      \n

      The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4). Nthep (talk) 14:52, 27 June 2019 (UTC)

      ", "timestamp": "2019-06-27T14:52:00.000Z", "author": "Nthep" } @@ -1573,7 +1573,7 @@ "author": "Killiondude" } ], - "html": "\n

      I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503. Suffusion of Yellow (talk) 19:52, 25 June 2019 (UTC)

      ", + "html": "I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503. Suffusion of Yellow (talk) 19:52, 25 June 2019 (UTC)", "timestamp": "2019-06-25T19:52:00.000Z", "author": "Suffusion of Yellow" }, @@ -1947,7 +1947,7 @@ "author": "Suffusion of Yellow" } ], - "html": "\n

      So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosflux Talk 03:14, 26 June 2019 (UTC)

      ", + "html": "So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosflux Talk 03:14, 26 June 2019 (UTC)", "timestamp": "2019-06-26T03:14:00.000Z", "author": "Xaosflux" } @@ -1996,7 +1996,7 @@ "author": "Xaosflux" } ], - "html": "\n
      \n

      The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4). Nthep (talk) 14:52, 27 June 2019 (UTC)

      ", + "html": "
      \n

      The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4). Nthep (talk) 14:52, 27 June 2019 (UTC)

      ", "timestamp": "2019-06-27T14:52:00.000Z", "author": "Nthep" } @@ -3158,7 +3158,7 @@ "author": "Suffusion of Yellow" } ], - "html": "\n

      Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June . Any help appreciated as this is currently on the main page in the In the News section. Espresso Addict (talk) 23:34, 4 July 2019 (UTC)

      ", + "html": "Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June . Any help appreciated as this is currently on the main page in the In the News section. Espresso Addict (talk) 23:34, 4 July 2019 (UTC)", "timestamp": "2019-07-04T23:34:00.000Z", "author": "Espresso Addict" } @@ -5459,7 +5459,7 @@ "author": "MusikAnimal" } ], - "html": "\n\n\n

      I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved? GiantSnowman 15:27, 10 July 2019 (UTC)

      ", + "html": "I use two XTools - edit counter and article counter, both of which have stopped working for me as I have over 350,000 edits. Any idea how this can be resolved? GiantSnowman 15:27, 10 July 2019 (UTC)", "timestamp": "2019-07-10T15:27:00.000Z", "author": "GiantSnowman" } @@ -5545,7 +5545,7 @@ "author": "QEDK" } ], - "html": "\n

      Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created? bd2412 T 22:52, 10 July 2019 (UTC)

      ", + "html": "Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created? bd2412 T 22:52, 10 July 2019 (UTC)", "timestamp": "2019-07-10T22:52:00.000Z", "author": "BD2412" } @@ -6001,7 +6001,7 @@ "author": "TheDJ" } ], - "html": "\n\n
      \n

      It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this. --Anthonyhcole (talk · contribs · email) 05:05, 9 July 2019 (UTC)

      ", + "html": "
      \n

      It works, most of the time, when you insert the doi number or the article title, but not at all for PMID or PMC numbers. Not sure where I should report this. --Anthonyhcole (talk · contribs · email) 05:05, 9 July 2019 (UTC)

      ", "timestamp": "2019-07-09T05:05:00.000Z", "author": "Anthonyhcole" } @@ -6728,7 +6728,7 @@ "author": "Snaevar" } ], - "html": "\n\n

      Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\".

      \n\n

      I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise? — Rhododendrites talk \\\\ 17:44, 11 July 2019 (UTC)

      ", + "html": "

      Some time ago, the save button was replaced with a \"publish changes\" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see \"publish changes\" and hesitate because of the implications of \"publish\".

      \n\n

      I'm sure there have been threads about this in the past, but I'm not sure the best way to search for this. Has this change been well-received otherwise? — Rhododendrites talk \\\\ 17:44, 11 July 2019 (UTC)

      ", "timestamp": "2019-07-11T17:44:00.000Z", "author": "Rhododendrites" }, @@ -9571,7 +9571,7 @@ "author": "JIP" } ], - "html": "\n\n

      Hi, so I am using my mobile.

      \n
      1. Just 1 hour ago, an editor posted a comment in my talk page.
        2. \n
      2. I got a notification.
        3. \n
      3. I didn't click on the notification,
        4. \n
      4. I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.)
        5. \n
      5. I saw the comment diff.
        6. \n
      6. I went to another site, returned to Wikipedia again and saw that the notification button is still red,
        7. \n
      7. I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications.
        8. \n
      8. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again.
        9. \n
      9. Cleared the cache it didn't help still red.
      \n

      So can someone help me to fix this? Thanks.--SharabSalam (talk) 21:52, 22 July 2019 (UTC)

      ", + "html": "

      Hi, so I am using my mobile.

      \n
      1. Just 1 hour ago, an editor posted a comment in my talk page.
        2. \n
      2. I got a notification.
        3. \n
      3. I didn't click on the notification,
        4. \n
      4. I went to the watchlist and see what triggered the notification. (I didn't click on the notification button.)
        5. \n
      5. I saw the comment diff.
        6. \n
      6. I went to another site, returned to Wikipedia again and saw that the notification button is still red,
        7. \n
      7. I clicked on it, surprisingly, I didn't see the comment that was posted to my talk page, I saw old notifications.
        8. \n
      8. I refreshed the page and the notification button returned red. I clicked on it and the red button disappeared and I refreshed it appeared again.
        9. \n
      9. Cleared the cache it didn't help still red.
      \n

      So can someone help me to fix this? Thanks.--SharabSalam (talk) 21:52, 22 July 2019 (UTC)

      ", "timestamp": "2019-07-22T21:52:00.000Z", "author": "SharabSalam" } @@ -12034,7 +12034,7 @@ "author": "PrimeHunter" } ], - "html": "\n\n

      The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help.

      \n\n

      Any clue? Thanks.--fireattack (talk) 22:49, 29 July 2019 (UTC)

      ", + "html": "

      The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help.

      \n\n

      Any clue? Thanks.--fireattack (talk) 22:49, 29 July 2019 (UTC)

      ", "timestamp": "2019-07-29T22:49:00.000Z", "author": "Fireattack" }, @@ -12129,7 +12129,7 @@ "author": "RoySmith" } ], - "html": "\n\n

      Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards SoWhy 07:31, 14 August 2019 (UTC)

      ", + "html": "Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards SoWhy 07:31, 14 August 2019 (UTC)", "timestamp": "2019-08-14T07:31:00.000Z", "author": "SoWhy" } @@ -14118,7 +14118,7 @@ "author": "Huji" } ], - "html": "\n

      I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got:

      \n\n
      1. Draft:Declan Meagher
        2. \n
      2. Draft:Gary Soulz
        3. \n
      3. Draft:Ananth Narayanan
        4. \n
      4. Draft:Frank Verboven
        5. \n
      5. Draft:Maths Time Joy
        6. \n
      6. Draft:Gary Soulz
        7. \n
      7. Draft:Ananth Narayanan
        8. \n
      8. Draft:Eni Vasili
        9. \n
      9. Draft:Shorts México - Mexico International Short Film Festival
        10. \n
      10. Category:Pending AfC submissions in userspace
        11. \n
      11. Draft:John Haze
        12. \n
      12. Draft:Alisha Rai (author)
        13. \n
      13. Draft:Leonardo3 Museum
        14. \n
      14. Draft:Wake. (2018 film)
        15. \n
      15. Category:Pending AfC submissions in article space
        16. \n
      16. Draft:Anastasiya Makarevich
        17. \n
      17. Draft:Alisha Rai (author)
        18. \n
      18. User:ItsYaBoiAustin/sandbox/Odyssey: Extraction
        19. \n
      19. Draft:Scott Stambach
        20. \n
      20. Draft:Christian Lillinger
        21. \n
      21. Draft:Gudula Naiga Basaza
        22. \n
      22. Draft:Scott Stambach
        23. \n
      23. Draft:Katherine Boyer
        24. \n
      24. Draft:Walter Ferguson
        25. \n
      25. Draft:Faryal Mehmood
      \n\n

      Not only are there four duplicates:

      \n\n
      • Draft:Scott Stambach
        • \n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
        • \n
      • Draft:Alisha Rai (author)
      \n\n

      but two pairs of duplicates in the same order:

      \n\n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
      \n\n

      There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much.

      \n\n

      Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap.

      \n\n

      My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations:

      \n\n
      0.000249\n0.000489\n0.000508\n0.000544\n0.000573\n0.000536\n0.000559\n0.000568\n0.000563\n0.000599\n
      \n\n

      That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing.

      \n\n

      Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.

      \n\n

      -- RoySmith (talk) 17:57, 18 August 2019 (UTC)

      ", + "html": "

      I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 \"random\" drafts, and got:

      \n\n
      1. Draft:Declan Meagher
        2. \n
      2. Draft:Gary Soulz
        3. \n
      3. Draft:Ananth Narayanan
        4. \n
      4. Draft:Frank Verboven
        5. \n
      5. Draft:Maths Time Joy
        6. \n
      6. Draft:Gary Soulz
        7. \n
      7. Draft:Ananth Narayanan
        8. \n
      8. Draft:Eni Vasili
        9. \n
      9. Draft:Shorts México - Mexico International Short Film Festival
        10. \n
      10. Category:Pending AfC submissions in userspace
        11. \n
      11. Draft:John Haze
        12. \n
      12. Draft:Alisha Rai (author)
        13. \n
      13. Draft:Leonardo3 Museum
        14. \n
      14. Draft:Wake. (2018 film)
        15. \n
      15. Category:Pending AfC submissions in article space
        16. \n
      16. Draft:Anastasiya Makarevich
        17. \n
      17. Draft:Alisha Rai (author)
        18. \n
      18. User:ItsYaBoiAustin/sandbox/Odyssey: Extraction
        19. \n
      19. Draft:Scott Stambach
        20. \n
      20. Draft:Christian Lillinger
        21. \n
      21. Draft:Gudula Naiga Basaza
        22. \n
      22. Draft:Scott Stambach
        23. \n
      23. Draft:Katherine Boyer
        24. \n
      24. Draft:Walter Ferguson
        25. \n
      25. Draft:Faryal Mehmood
      \n\n

      Not only are there four duplicates:

      \n\n
      • Draft:Scott Stambach
        • \n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
        • \n
      • Draft:Alisha Rai (author)
      \n\n

      but two pairs of duplicates in the same order:

      \n\n
      • Draft:Gary Soulz
        • \n
      • Draft:Ananth Narayanan
      \n\n

      There's \"approximately 4,581\" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much.

      \n\n

      Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap.

      \n\n

      My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations:

      \n\n
      0.000249\n0.000489\n0.000508\n0.000544\n0.000573\n0.000536\n0.000559\n0.000568\n0.000563\n0.000599\n
      \n\n

      That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing.

      \n\n

      Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.

      \n\n

      -- RoySmith (talk) 17:57, 18 August 2019 (UTC)

      ", "timestamp": "2019-08-18T17:57:00.000Z", "author": "RoySmith" }, diff --git a/tests/cases/en-big-parsoid/en-big-parsoid.json b/tests/cases/en-big-parsoid/en-big-parsoid.json index 8a9507a9d..d4ee93b64 100644 --- a/tests/cases/en-big-parsoid/en-big-parsoid.json +++ b/tests/cases/en-big-parsoid/en-big-parsoid.json @@ -848,7 +848,7 @@ "timestamp": "2019-06-25T19:52:00.000Z", "author": "Suffusion of Yellow", "range": [ - "10/2/2/0", + "10/2/4/0", "10/2/4/6/27" ], "signatureRanges": [ @@ -1258,7 +1258,7 @@ "timestamp": "2019-06-26T03:14:00.000Z", "author": "Xaosflux", "range": [ - "10/3/2/0", + "10/3/4/0", "10/3/4/6/26" ], "signatureRanges": [ @@ -2018,7 +2018,7 @@ "timestamp": "2019-06-27T14:52:00.000Z", "author": "Nthep", "range": [ - "10/4/2/0", + "10/4/4/0", "10/4/6/4/27" ], "signatureRanges": [ @@ -2894,7 +2894,7 @@ "timestamp": "2019-06-25T19:52:00.000Z", "author": "Suffusion of Yellow", "range": [ - "10/2/2/0", + "10/2/4/0", "10/2/4/6/27" ], "signatureRanges": [ @@ -3304,7 +3304,7 @@ "timestamp": "2019-06-26T03:14:00.000Z", "author": "Xaosflux", "range": [ - "10/3/2/0", + "10/3/4/0", "10/3/4/6/26" ], "signatureRanges": [ @@ -4064,7 +4064,7 @@ "timestamp": "2019-06-27T14:52:00.000Z", "author": "Nthep", "range": [ - "10/4/2/0", + "10/4/4/0", "10/4/6/4/27" ], "signatureRanges": [ @@ -6457,7 +6457,7 @@ "timestamp": "2019-07-04T23:34:00.000Z", "author": "Espresso Addict", "range": [ - "20/2/0", + "20/4/0", "20/4/8/25" ], "signatureRanges": [ @@ -11158,7 +11158,7 @@ "timestamp": "2019-07-10T15:27:00.000Z", "author": "GiantSnowman", "range": [ - "40/2/0", + "40/6/0", "40/6/7/26" ], "signatureRanges": [ @@ -11332,7 +11332,7 @@ "timestamp": "2019-07-10T22:52:00.000Z", "author": "BD2412", "range": [ - "42/2/0", + "42/4/0", "42/4/4/26" ], "signatureRanges": [ @@ -12187,7 +12187,7 @@ "timestamp": "2019-07-09T05:05:00.000Z", "author": "Anthonyhcole", "range": [ - "51/2/0", + "51/4/0", "51/6/8/27" ], "signatureRanges": [ @@ -13721,7 +13721,7 @@ "timestamp": "2019-07-11T17:44:00.000Z", "author": "Rhododendrites", "range": [ - "63/2/0", + "63/4/0", "63/6/4/29" ], "signatureRanges": [ @@ -18749,7 +18749,7 @@ "timestamp": "2019-07-22T21:52:00.000Z", "author": "SharabSalam", "range": [ - "100/4/0", + "100/6/0", "100/10/4/27" ], "signatureRanges": [ @@ -24574,7 +24574,7 @@ "timestamp": "2019-07-29T22:49:00.000Z", "author": "Fireattack", "range": [ - "147/2/0", + "147/4/0", "147/6/4/27" ], "signatureRanges": [ @@ -24711,7 +24711,7 @@ "timestamp": "2019-08-14T07:31:00.000Z", "author": "SoWhy", "range": [ - "148/2/0", + "148/6/0", "148/6/3/28" ], "signatureRanges": [ @@ -28796,7 +28796,7 @@ "timestamp": "2019-08-18T17:57:00.000Z", "author": "RoySmith", "range": [ - "167/2/0", + "167/4/0", "167/28/4/28" ], "signatureRanges": [ diff --git a/tests/cases/sr-ec/sr-ec.json b/tests/cases/sr-ec/sr-ec.json index c42368b14..3c655fd9f 100644 --- a/tests/cases/sr-ec/sr-ec.json +++ b/tests/cases/sr-ec/sr-ec.json @@ -6760,7 +6760,7 @@ "timestamp": "2018-07-29T21:44:00.000Z", "author": "НиколаБ", "range": [ - "553/0", + "555/0", "555/6/29" ], "signatureRanges": [ diff --git a/tests/cases/sr-el/sr-el.json b/tests/cases/sr-el/sr-el.json index c42368b14..3c655fd9f 100644 --- a/tests/cases/sr-el/sr-el.json +++ b/tests/cases/sr-el/sr-el.json @@ -6760,7 +6760,7 @@ "timestamp": "2018-07-29T21:44:00.000Z", "author": "НиколаБ", "range": [ - "553/0", + "555/0", "555/6/29" ], "signatureRanges": [ diff --git a/tests/cases/tracked-template/tracked-template-getHTML.json b/tests/cases/tracked-template/tracked-template-getHTML.json index 56abf812d..82a490857 100644 --- a/tests/cases/tracked-template/tracked-template-getHTML.json +++ b/tests/cases/tracked-template/tracked-template-getHTML.json @@ -6,5 +6,5 @@ "h-HTTP_500,_server_down?-2021-12-28T00:30:00.000Z": "HTTP 500, server down?", "c-Marsupium-2021-12-28T00:30:00.000Z-HTTP_500,_server_down?": "

      For me https://wcqs-beta.wmflabs.org/ throws a 500 Internal Server Error:

      \n
      Problem accessing /oauth/check_login. Reason:\nRequest failed.
      \n

      Is this known? Any information when the query service might be back? Thanks in advance for any information or linking to relevant other places!

      ", "c-Shisma-2021-12-31T11:48:00.000Z-Marsupium-2021-12-28T00:30:00.000Z": "@Marsupium: issue was reported in T297454", - "c-Marsupium-2021-12-31T12:19:00.000Z-Marsupium-2021-12-28T00:30:00.000Z": "\n
      Thanks for the link!
      " + "c-Marsupium-2021-12-31T12:19:00.000Z-Shisma-2021-12-31T11:48:00.000Z": "Thanks for the link!" } diff --git a/tests/cases/tracked-template/tracked-template-getText.json b/tests/cases/tracked-template/tracked-template-getText.json index 2ed55dd55..6c2da2129 100644 --- a/tests/cases/tracked-template/tracked-template-getText.json +++ b/tests/cases/tracked-template/tracked-template-getText.json @@ -6,5 +6,5 @@ "h-HTTP_500,_server_down?-2021-12-28T00:30:00.000Z": "HTTP 500, server down?", "c-Marsupium-2021-12-28T00:30:00.000Z-HTTP_500,_server_down?": "For me https://wcqs-beta.wmflabs.org/ throws a 500 Internal Server Error: Problem accessing /oauth/check_login. Reason: Request failed. Is this known? Any information when the query service might be back? Thanks in advance for any information or linking to relevant other places!", "c-Shisma-2021-12-31T11:48:00.000Z-Marsupium-2021-12-28T00:30:00.000Z": "@Marsupium: issue was reported in T297454", - "c-Marsupium-2021-12-31T12:19:00.000Z-Marsupium-2021-12-28T00:30:00.000Z": "Tracked in Phabricator Task T297454 Thanks for the link!" + "c-Marsupium-2021-12-31T12:19:00.000Z-Shisma-2021-12-31T11:48:00.000Z": "Thanks for the link!" } diff --git a/tests/cases/tracked-template/tracked-template-transcludedFrom.json b/tests/cases/tracked-template/tracked-template-transcludedFrom.json index f402237ba..8775a66b8 100644 --- a/tests/cases/tracked-template/tracked-template-transcludedFrom.json +++ b/tests/cases/tracked-template/tracked-template-transcludedFrom.json @@ -3,6 +3,6 @@ "c-Zache-2021-01-04T06:55:00.000Z-FrankieRayRobertson-2020-12-21T13:38:00.000Z": false, "c-Multichill-2021-02-13T18:31:00.000Z-Zache-2021-01-04T06:55:00.000Z": false, "c-Marsupium-2021-12-28T00:30:00.000Z-HTTP_500,_server_down?": false, - "c-Shisma-2021-12-31T11:48:00.000Z-Marsupium-2021-12-28T00:30:00.000Z": true, - "c-Marsupium-2021-12-31T12:19:00.000Z-Marsupium-2021-12-28T00:30:00.000Z": true + "c-Shisma-2021-12-31T11:48:00.000Z-Marsupium-2021-12-28T00:30:00.000Z": false, + "c-Marsupium-2021-12-31T12:19:00.000Z-Shisma-2021-12-31T11:48:00.000Z": false } diff --git a/tests/cases/tracked-template/tracked-template.json b/tests/cases/tracked-template/tracked-template.json index cbb983af9..57bdbecd8 100644 --- a/tests/cases/tracked-template/tracked-template.json +++ b/tests/cases/tracked-template/tracked-template.json @@ -126,29 +126,28 @@ "name": "c-Shisma-2021-12-31T11:48:00.000Z", "id": "c-Shisma-2021-12-31T11:48:00.000Z-Marsupium-2021-12-28T00:30:00.000Z", "warnings": [], - "replies": [] - }, - { - "type": "comment", - "timestamp": "2021-12-31T12:19:00.000Z", - "author": "Marsupium", - "range": [ - "2/8/0/7/0", - "2/8/0/9/0/4/31" - ], - "signatureRanges": [ - [ - "2/8/0/9/0/1", - "2/8/0/9/0/4/31" - ] - ], - "level": 2, - "name": "c-Marsupium-2021-12-31T12:19:00.000Z", - "id": "c-Marsupium-2021-12-31T12:19:00.000Z-Marsupium-2021-12-28T00:30:00.000Z", - "warnings": [ - "Comment starts and ends with different indentation" - ], - "replies": [] + "replies": [ + { + "type": "comment", + "timestamp": "2021-12-31T12:19:00.000Z", + "author": "Marsupium", + "range": [ + "2/8/0/9/0/0", + "2/8/0/9/0/4/31" + ], + "signatureRanges": [ + [ + "2/8/0/9/0/1", + "2/8/0/9/0/4/31" + ] + ], + "level": 3, + "name": "c-Marsupium-2021-12-31T12:19:00.000Z", + "id": "c-Marsupium-2021-12-31T12:19:00.000Z-Shisma-2021-12-31T11:48:00.000Z", + "warnings": [], + "replies": [] + } + ] } ] }