Approach #1: Only show the [subscribe] links on sections that already contain at least one comment

@matmarex, can you think of scenarios where taking the above approach might lead to false positives (read: [ subscribe ] links not appearing where we would expect them to)?

Yeah, kind of:

• There are some discussions where a proposal is presented in a separate section than the discussion, so the discussion section starts empty, but you might still want to subscribe to the comments there.
• But they usually also use level 3 or lower subsections, and our interface only allows subscribing to level 2 sections, so we're not compatible with them anyway.

For example, en.wp's requests for adminship are like that. Note the empty headings at the bottom here: https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_adminship/Trialpears&oldid=1027007611 (they were filled up with comments in later revisions)

(per meeting today)

In T285796#7188013, @matmarex wrote:

In the main namespace…

I think it’s just as confusing in other namespaces as well, for example on policy/guideline/help pages in the project namespace.

Right, that should probably read "In the namespaces listed in wgExtraSignatureNamespaces" instead.

Possible alternative approach(?):

• Checking whether the page contains __NEWSECTIONLINK__ (directly or via transclusion)

AFAIK, that is the standard way that the communities use to make non-"Talk" namespace pages, have the "New section" link in the page-tools bar.
E.g. https://meta.wikimedia.org/wiki/Meta:Babel transcludes it via the <includeonly> within https://meta.wikimedia.org/wiki/Template:Babel_header
Note: I don't know how widespread that is beyond the largest of our wikis, but the couple of mid-size wikis that I spot-checked do use it (e.g. Swwiki, and Htwiki)

@Whatamidoing-WMF also noticed that this can affect any page on any project when the dtenable=1 URL parameter (from T284491) is used to show the topic subscriptions interface.

While we were talking about that, I also realized that these subscribe links are actually entirely useless. I wrote before that they might be useful in some cases (T285796#7185059). But in fact you will never get a notification if you subscribe to an empty section, even if it's on a discussion page and someone posts a comment. This is because the thread names, to which subscriptions are connected, are based on the author and time of the oldest comment in a thread. If someone adds a comment in an empty section, that's now the oldest comment, so the thread name is different, and so your subscription points to a different thread.

I'll update the description per the above.

In T285796#7194756, @Quiddity wrote:

Possible alternative approach(?):

• Checking whether the page contains __NEWSECTIONLINK__ (directly or via transclusion)

We do that as well, but we also want to treat whole namespaces on some wikis as discussion pages, and wgExtraSignatureNamespaces was a good way to do it. See T249036.

Change 704153 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Only show [subscribe] links on sections that contain at least one comment

https://gerrit.wikimedia.org/r/704153

Change 704153 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Only show [subscribe] links on sections that contain at least one comment

https://gerrit.wikimedia.org/r/704153

I am still seeing [ subscribe ] links in the main namespace (e.g. https://www.mediawiki.org/wiki/Talk_pages_project).

This is unexpected to me considering:

• The patch to correct this issue "rode" the train that went on Tuesday, 19 July
• Mediawiki.org is part of Group 0 which I assume MW-1.37 will have already arrived to

...@Ryasmeen are you seeing [ subscribe ] links on this page: https://www.mediawiki.org/wiki/Talk_pages_project ?

In T285796#7231014, @ppelberg wrote:

I am still seeing [ subscribe ] links in the main namespace (e.g. https://www.mediawiki.org/wiki/Talk_pages_project).

This is unexpected to me considering:

• The patch to correct this issue "rode" the train that went on Tuesday, 19 July
• Mediawiki.org is part of Group 0 which I assume MW-1.37 will have already arrived to

...@Ryasmeen are you seeing [ subscribe ] links on this page: https://www.mediawiki.org/wiki/Talk_pages_project ?

Hey @ppelberg, I am not seeing any Subscribe links on that page:

In T285796#7231084, @Ryasmeen wrote:

Hey @ppelberg, I am not seeing any Subscribe links on that page:

Are you able to share a screenshot of the page that spans its full width? ...[ subscribe ] links, were they to appear, would be visible on the right-most part of the page.

I can confirm I am still seeing the [subscribe] links at some Main-namespace pages, but not all, at both meta-wiki and mediawiki-wiki.
However, it seems to consistently resolve itself (i.e. those links vanish) if I purge the page.
E.g.

• I saw it on the [[mw:Main Page]] in both my volunteer and staff accounts.
• Refreshing/Hard-refreshing the page didn't change anything.
• I did an ?action=purge in the volunteer-account tab - the links vanished.
• I refreshed the page in the staff-account tab - the links vanished.

HTH!

Our [subscribe] and [reply] links are stored in the parser cache as part of the page contents, so if someone previously viewed the page and it has been cached, they will only disappear when either the page is manually purged (as @Quiddity described), or when the page is edited, or after a few weeks. Sorry, I probably should have thought about that and noted it.

@ppelberg and @Ryasmeen, you may be seeing different cached versions of the page depending on your user preferences. Some user preferences "split" the parser cache, e.g. if you set "Thumbnail size" in Preferences → Appearance. (This is the same mechanism as our own splitting of the parser cache into two versions, one with [reply] links and one without.)

In T285796#7231014, @ppelberg wrote:

• Mediawiki.org is part of Group 0 which I assume MW-1.37 will have already arrived to

You don’t need to assume. The current MW version is visible on Special:Version, but if you want to get an overview about how far the train has ridden yet, versions.toolforge.org provides a nice quick summary (and some useful links).