Page MenuHomePhabricator

Prevent DiscussionTools from being enabled on pages they should not be
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 DiscussionTools are not being enabled on pages they should not be.

Approaches

Below are some approaches we could take to prevent DiscussionTools from being enabled on pages where these tools could cause more harm than good.

Page-specific exclusion list

  • DiscussionTools would not appear on pages that contain a magic word, like __NONEWSECTIONLINK__

Content-specific exclusion list

  • Reply links would not be appended to comments that are wrapped in certain tags/DOM nodes (e.g. <blockquote>~~~~</blockquote>)

Content-specific inclusion list

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

Use cases

Open questions

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

Conditions

TBD

Done

  • Defined a set of conditions, that if met, will prevent DiscussionTools from being enabled
  • Implement "Conditions"

Event Timeline

Updated the task description to include the approaches we talked about during today's stand up.

Content-specific whitelist

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

Many people prefer not to indent their comments on talk pages (there was already a complaint on huwiki about this tool forcing indentation in its users’ comments). Disabling the reply link on such people’s comments (left without the tool) would limit users in replying to them, and would seem a quite rapsodic, hard-to-catch bug if I didn’t know what its cause is.

Content-specific whitelist

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

I don't understand this one, but if it it's saying what I think it's saying then it does not sound correct. The indentation level of a comment shouldn't affect whether it has a reply link.

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.

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).