Page MenuHomePhabricator

Prevent reply links from showing on certain pages
Open, Needs TriagePublic

Description

T245890 enables people to use DiscussionTools on pages outside of the talk namespaces.

This task is about refining the initial approach described in T245890 to ensure reply links are not added on pages they should not be.

Approaches

Below are some approaches we could take to prevent the reply link from being added.

Feature-specific exclusion

  • Reply links would not appear on pages that contain a magic word, like __NOREPLYLINKS__

Content purpose declaration

  • Provide __ARCHIVEDTALK__ and let any software decide which behaviour is appropriate on this page (hiding rely links)

Exclusions within certain sections

Content-specific inclusion list

  • Reply links would only be appended to comments at a new level of indentation

References

Use Cases

Discussions

Open questions

  • What do we estimate to be the rate of pages that contain __NONEWSECTIONLINK__ syntax and do not contain discussions?
    • Per T249293#6889884, pages which transclude discussions often use __NONEWSECTIONLINK__ to prevent sections discussions being added directly to the page, but still contain many transcluded discussions that can be replied to.
  • Should topic subscriptions be disabled when the reply link is disabled?

Conditions

TBD

Done

  • Defined a set of conditions, that if met, will prevent reply links from being shown
  • Implement "Conditions"

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

One user who has enabled the reply-tool beta feature comments about invisibility of the 'reply button' in the village pump: https://nl.wikipedia.org/w/index.php?title=Wikipedia:De_kroeg&diff=prev&oldid=56123992&diffmode=source.

They suggest to outline the button to the right, with a small line to the left (in a left to right script).
I would suggest a rounded rectangle, background color blue, text color white, bold fade.

German Wikipedia does not want that threads in a talk archive might be continued.

  • Talk archive pages are in the related talk (or other) space.
  • Talk archive pages are marked as terminated by any archive template and those request explicitly __NOEDITSECTION__ and __NONEWSECTIONLINK__ to prevent thread editing by accident.

DiscussionTool must not invite to reply in a terminated thread.

@PerfektesChaos: good example. The Hungarian Wikipedia uses the same practice.

German Wikipedia does not want that threads in a talk archive might be continued.

  • Talk archive pages are in the related talk (or other) space.

Are these pages marked in anyway that would let us know they are archived?

  • Talk archive pages are marked as terminated by any archive template and those request explicitly __NOEDITSECTION__ and __NONEWSECTIONLINK__ to prevent thread editing by accident.

Discussions wrapped in a template (such as the archived template) are currently not supported by the tool for other technical reasons.

Are these pages marked in anyway that would let us know they are archived?

As PerfektesChaos says, __NOEDITSECTION__ and __NONEWSECTIONLINK__ are present on most archived talk pages. (They are referring to the noticebox templates present on talk page archives, not the templates which are used to place divs around concluded discussions.)

This also holds for the English Wikipedia, where the magic words are added by the templates which use Module:AutomaticArchiveNavigator.

German Wikipedia does not want that threads in a talk archive might be continued.

  • Talk archive pages are in the related talk (or other) space.

Are these pages marked in anyway that would let us know they are archived?

There are various templates, but all of them use both __NOEDITSECTION__ and __NONEWSECTIONLINK__ to prevent thread editing by accident.

Switch __NOEDITSECTION__ on a talk page does prevent answering and continuing a particular thread. If this is occurring on a talk page DiscussionTool must not be active.

  • Talk archive pages are marked as terminated by any archive template.

Discussions wrapped in a template (such as the archived template) are currently not supported by the tool for other technical reasons.

The page content is not wrapped in any template; that would not work due to various pipe and syntax problems.

The archive template is just producing an informative box in the page head telling visitors that editing of this page is not desired, and setting the switches.

Are these pages marked in anyway that would let us know they are archived?

There are various templates, but all of them use both __NOEDITSECTION__ and __NONEWSECTIONLINK__ to prevent thread editing by accident.

The page starts with a specific template, so yes, it is quite easy to detect.
Just for an example, see this template:
https://hu.wikipedia.org/wiki/Sablon:Arch%C3%ADv_lap
and its usage on the News village pump:
https://hu.wikipedia.org/wiki/Wikip%C3%A9dia:Kocsmafal_(h%C3%ADrek)/Arch%C3%ADv36

Task description update
Adding use cases mentioned by @gh87, @Urbanecm, and @Zache to the task description's newly-created ===Use cases section.

What do we estimate to be the rate of pages that contain NONEWSECTIONLINKsyntax and do not contain discussions?

Don't we want to know how many pages have this marker yet *do* have discussions.

So, this is technically easy to implement, we could easily do it by recognizing a magic word like __NOREPLYLINKS__ (to disable on entire page), and/or by recognizing CSS classes like <div class="noreplylinks">…</div> (to disable in a fragment of the page).

My only concern is that the markup above would have to be added to the actual discussion pages (or at least, to templates used on discussion pages). It seems a bit inappropriate for a beta feature to require extra markup on existing wikitext pages. I'm not sure if this is really a problem, but maybe we should only implement this on wikis where reply links are enabled for everyone by default?

There is no need to grab sourcecode.

  • Both nonewsectionlink and noeditsection are pageprops.
  • They might be retrieved via API in advance, leaving the tool immediately.

In finnish wikipedia there is two use cases for disabling the links because the page is archived or project page. Currently there is no known problems with this except that the css is custom local change.

  1. Pages which are fully archived or real talk pages: __NONEWSECTIONLINK__ works ok
  2. Pages which are only partially archived with template:ArkistoituOsa
    1. Example: https://fi.wikipedia.org/wiki/Keskustelu:Havaiji
    2. these are currently handled by adding css-class noreplylinks to the html fragment via base template (diff) and hiding reply links using local css.

Use case: Wikiprojects, where there is a list of member on the main page, often with full signatures, but without the need for discussion (example).

Note: in the example the reply tools actually does not work because the list is on a transcluded page. I will look for a better example (without transclusion).

In T249293#6652526, @Zache wrote...
In T249293#6654315, @Samat wrote...

@Zache + @Samat: thank you for sharing these additional examples; I've added them to the task descriptions ===Use cases section. If I've misrepresented the examples you've shared in any way, please boldly edit the task description.

these are currently handled by adding css-class noreplylinks to the html fragment via base template (diff) and hiding reply links using local css.

This is probably a reasonable approach for archived discussions et al. It is considerably simpler that introducing new parser words.

Use case: Wikiprojects, where there is a list of member on the main page, often with full signatures, but without the need for discussion (example).

This may be covered by something like T259865#6655698.

In T275881 we implemented a small part of this task – reply links will no longer be added inside <blockquote> tags (and also <q> and <cite>).

Don't know if it has any worth, but here's the model that Convenient-Discussions uses to differentiate between types of pages where the script can load. With each of these types of pages the script behaves differently.

Page activeness levels.png (1×1 px, 109 KB)

Arrows denote page type transitions when the page is reloaded dynamically (with Ajax), for example after a reply.

DiscussionTools currently seems to have no functionality related to inactive existing talk pages (the right part of the right circle). But the "New discussion" functionality, I would argue, should run on 404 talk pages (the left part of the left circle) for the user to be able to create the first topic, which it currently doesn't. It's also interesting how the tool will handle type transitions mentioned on the diagram (say, an active talk page is becoming an archive, a redirect, getting __NONEWSECTIONLINK__ all of a sudden, or being removed). Some of these cases are extremely rare, but others are less.

Regarding __NONEWSECTIONLINK__ and discussion pages—in Russian Wikipedia, a lot of pages (including forums, the main meeting place, analog of "Village pump" in enwiki) use "New topics on top" topic order. Many of these pages don't use __NONEWSECTIONLINK__ because they are in the "Project" namespace, where there is no "Add topic" link anyway, but others do use. The other reason to use __NONEWSECTIONLINK__ is to have some special editing mode on the page, i.e., adding topics with preloaded text from a template (preload= query string parameter). These could be applications to participate in an event, to request a flag, to nominate a page for a certain procedure.

It's also interesting how guideline and coordination pages in the "Project" and other namespaces are going to be filtered out, assuming that these namespaces are included in the list exposed to frontend as mw.config.get('wgExtraSignatureNamespaces') (if I'm not mistaken, the tool currently looks at that value to get signature namespaces other than odd ones). Many of these pages include signatures, but they are not intended to be treated as comments one can reply to.

As a result,

  • pages with __NONEWSECTIONLINK__ in signature namespaces can both have legit discussions ("New topic on top" odd namespace pages, pages with special editing mode) and have no (archives);
  • pages without __NONEWSECTIONLINK__ in signature namespaces can both have legit discussions (most discussions) and have no (archives, guideline and coordination pages in extra signature namespaces).

I suspect there is no good way to do such filtration without introduction of new magic word(s). (Convenient Discussions uses whitelist and blacklist, with the latter having priority, but it's hard for me to imagine how these could be implemented in an extension so that users could quickly add/remove pages.) I would also be happy if the page properties potentially brought about by these magic words were introduced to frontend somehow (via a config property, for example), so that user scripts (including mine) could use them.

I would also be happy if the page properties potentially brought about by these magic words were introduced to frontend somehow (via a config property, for example), so that user scripts (including mine) could use them.

  • Each mw.config.get(wg) is blowing up the size of the delivered HTML page and adding bandwidth.
  • In most cases, when reading an article, none of these page properties are needed.
  • Delivering a pile of unnecessary page properties increases resource consumption for all readers and users.
  • If a particular script is interested in a particular property which happens in 0,0001 % of cases that may be retrieved via API rather easily.
  • The number of mw.config globals might be reduced for rare site properties.

These are fair points. Still, the main concern here, I believe, is readers, the absolute majority of whom don't ever visit talk pages, which gives your digit of 0,0001%. If there was a way to expose a page property to frontend other than configuration (that is set on all pages or something like that), it would be beneficial to a significantly higher share. Say, the nonewsectionlink property is de facto introduced to frontend via the presence of the #ca-addsection element.

As for API requests—as of now, Convenient Discussions manages to do without any API requests on wikis where it's preconfigured, thanks to which, if it's also a gadget, it finishes its execution almost as quickly as DiscussionTools. Being able to execute quickly is essential for its features (for example, jumping to a linked comment, modifying layout, and displaying new comments).

Change 701653 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Allow dtenable=0 to disable DiscussionTools

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

DLynch added a subscriber: DLynch.

Wrong ticket number in the patch, sorry.

A way to disable the [reply] button (specifically for archived discussion pages) has been requested again, this time at https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#%22Antworten%22 and https://www.mediawiki.org/wiki/Topic:Wixpngarb42mrxik

Now that DT is deployed everywhere in some form, I'm less worried about adding a parser magicword. It seems it would be useful for archive pages.

The only remaining question is which features should be disabled:

  • Reply tool: This is the main reason for this fix. Reply links should be hidden.
  • Topic subscriptions; It seems pointless to subscribe to an archived discussion, but it would be harmless, and someone may want to do it to monitor an archive? Unlike the [reply] links, [subscribe] links are going to be harmless it terms of generating unwanted edits.
  • New topic tool: As this is already covered by __NONEWSECTIONLINK__ this can be ignored
  • Future visual enhancements: This will need to be considered as part of that work. Potentially we can style archived conversations differently.

I would then propose having a magic word __NOREPLYLINKS__, and we can decide later if this should affect topic subscriptions.

Change 737763 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] [POC] Hide reply links when __NOREPLYLINKS__ is used

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

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/298de56585/w/

Esanders renamed this task from Prevent DiscussionTools from being enabled on pages they should not be to Prevent reply link from showing on certain pages.Nov 10 2021, 2:24 PM
Esanders updated the task description. (Show Details)

I would then propose having a magic word __NOREPLYLINKS__, and we can decide later if this should affect topic subscriptions.

I don't think that [subscribe] buttons should be suppressed. Consider:

  • I subscribe to a discussion.
  • It's archived.
  • I want to unsubscribe (maybe because I want the Special page to be more readable).

or:

  • A discussion is in an archive.
  • Editors are talking about un-archiving it to re-open the discussion.
  • If they do that, I want to be notified about any future comments added to the discussion. Subscribing while it's still archived would let me do that.

I would then propose having a magic word __NOREPLYLINKS__, and we can decide later if this should affect topic subscriptions.

I agree with what you (@Esanders) and @Whatamidoing-WMF are proposing: for this new magic word to only impact whether [ reply ] links are visible on the page the magic word is present on.

@Esanders two resulting questions for you...

  1. Question: would it be accurate for me to think that the approach we take now for enabling people to suppress [ reply ] links on a per-page-basis will not jeopardize a potential future wherein we introduce additional magic words to offer people the ability to suppress Topic Subscriptions (read: [ subscribe ] links) and the usability improvements we have planned (e.g. T269950 + T293522) on a per-page-basis?
  2. Question: related to "1.", in saying "...we can decide later if this should affect topic subscriptions." are you suggesting that in the event people have a need to suppress [ subscribe ] links on a per-page-basis, we could offer this by way of expanding the scope/impact of the __NOREPLYLINKS__ magic word? If so, can you share what's leading you to propose an approach wherein a single magic word could come to affect multiple features rather than there being a "1:1" [i] relationship between a magic word and the functionality it impacts?

i. I put "1:1" in quotation marks to allude to the fact that the "one-magic-word-to-one-feature" relationship is more of a conceptual linkage rather than a literal one.

  1. Question: would it be accurate for me to think that the approach we take now for enabling people to suppress [ reply ] links on a per-page-basis will not jeopardize a potential future wherein we introduce additional magic words to offer people the ability to suppress Topic Subscriptions (read: [ subscribe ] links) and the usability improvements we have planned (e.g. T269950 + T293522) on a per-page-basis?

Yes, we can add more magic words later if required.

  1. Question: related to "1.", in saying "...we can decide later if this should affect topic subscriptions." are you suggesting that in the event people have a need to suppress [ subscribe ] links on a per-page-basis, we could offer this by way of expanding the scope/impact of the __NOREPLYLINKS__ magic word? If so, can you share what's leading you to propose an approach wherein a single magic word could come to affect multiple features rather than there being a "1:1" [i] relationship between a magic word and the functionality it impacts?

There may be cases where disabling one feature results in us logically wanting to disable another feature. In that case it probably doesn't make sense to require users to add two magic words when one is logically a subset of the other. With Sherry's counter-examples I don't think that is the case here, but I think it's ok to consider.

Having considered the issue more on T295553, I think the magic words should describe the state of the content rather than the specific feature we want to suppress. So in this case __NOREPLYLINKS__ might become __ARCHIVEDTALK__. I think this is more flexible and future proof: while we currently describe the feature as "reply links", it may in the future be "reply & edit links", or "reply, edit & like links". If the magic word just describes the state of the page ("archived") then future implementors can decide which features should be available on archived talk pages.

Yeah, I do prefer __ARCHIVEDTALK__ as content based, and any software in the next centuries might decide on appropriate behaviour.

__NOREPLYLINKS__ might become __ARCHIVEDTALK__

I know this is bikeshedding, but __TALKARCHIVE__ sounds better to me, maybe because it’s a noun and not a phrase. __ARCHIVEDTALK__ is also totally acceptable for me, though.

Per https://fr.wikipedia.org/wiki/Discussion_Projet:Outils_de_discussion#Pas_convaincu_non_plus it might be useful to disable [reply] links in a single section. In addition to its use in semi-structured voting, which is T259865: Add support for voting-style discussions, imagine being able to turn off the [reply] tool in a boxed up/closed discussion (e.g., via https://en.wikipedia.org/wiki/Template:Closed_rfc_top).

@Whatamidoing-WMF, more fine-grained control than per-page is tracked in T295553.

Obviously a little late, but it would be nice if there were a way to disable reply links within archived discussions (while still having them enabled on the rest of the page). A magic word would presumably apply to the entire page, but perhaps something similar to <nowiki> (<noreply>?) that could be used as needed within discussions?

Edit: I see something that kind of addresses this is T295553.

Change 738221 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] [WIP] Support hiding reply links and suppressing comment detection

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

Change 737763 abandoned by Esanders:

[mediawiki/extensions/DiscussionTools@master] [POC] Hide reply links when __NOREPLYLINKS__ is used

Reason:

squashed

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

Esanders renamed this task from Prevent reply link from showing on certain pages to Prevent reply links from showing on certain pages.Mar 10 2022, 2:26 PM
Esanders updated the task description. (Show Details)