Topic on Talk:Talk pages project/Replying/Flow

Hi, in the last days I collected some feedback from using the tool at dewiki. I know some of the following points are already known and have a phabricator task, but I still want to mention them to indicate that these issues also came up on our project.

Already known:

• Don't show reply links on archives and pages which are not designated for further discussion (per NONEWSECTIONLINK): phab:T249293
• Dont't show reply links on pages you can't edit because of protection: phab:T276393
• Toolbar in source mode is missing: phab:T257391
• Missing possibility to define watchlist expiry: phab:T278190
• Restrictions on visual mode: Help:DiscussionTools/Reply tool visual mode limitations
• Editing (at least your own) comment afterwards: phab:T245225

And now some (I guess) new points, please excuse if there are any already being discussed:

• We use editMenus as a standard gadget on dewiki as the replacement for MediaWiki:Onlyifediting.js and mw.toolbar. This adds a bar with special characters below the wikitext editor (see screenshot on the gadget's page). It would be nice and consistent to have this one also while replying. The maintainer of the gadget said that he needs a hook being fired when opening the reply tool for adding the bar, because currently it is only loaded at page load once for all visible edit boxes.
• Reply links also show up in templates that (for example) indicate when a discussion is closed. On dewiki we use :de:Template:Erledigt which requires a signature for the archive bot. Currently the reply link is shown inside the template and could lead unexperienced users to reply to the topic even though it's marked as closed (no further replies wanted). Maybe you could introduce a css class indicating elements in which signatures should not get a reply link.
• The standard wikitext editor uses syntaxhighlight with CodeMirror. I don't know if it's possible to adapt to the reply form, but would make handling of wikitext more consistent.
• It is currently not possible to mark your reply as minor change
• There is no space added between colon and reply text, could make the source harder to read while editing the page in a normal way

A personal note from me at the end: I think this is the best new feature since years and finally an approach to simplify discussion pages without breaking the workflow of experienced users. So thank you very much for your effort. And as you can see on the Kurier page, the dewiki community is not always rejecting changes ;)

I am the one mentioned as maintainer of the tool permitting insertion of special characters and even more sophisticated things, like enclosing the currently selected text etc.

• Many wikis have similar tools for more than a decade, like editTool or whatever, heading for source code.
• There should be a common interface for all those gadgets:
  • mw.hook( "DiscussionTools.opened" ).fire( $wrapper );
  • Transferring a $wrapper or DOM with the block element where any insertion tool may be appended, typically below a textarea.

editMenus is able to feed character insertion on VE mode as well, not only source text mode.

• Therefore gadget developers will need two more hooks, for hiding toolbar or for changing insertion mode when toggled:
  • mw.hook( "DiscussionTools.source" ).fire( $textarea );
  • mw.hook( "DiscussionTools.visual" ).fire( ve.object );

I am really looking forward to see DiscussionTools growing and very helpful for new and occasional users.

While the hooks in my previous contribution are to be fired by DiscussionTools, it might listen to another one:

• mw.hook( "DiscussionTools.inhibit" ).add( finish );
• This one will be issued if the wiki does not like to apply DiscussionTools to certain pages with signatures.

There are local patterns for pages that are not supposed to receive comments, like straw polls or RfC or whatever.

• Kondolenzliste is a list of signatures if a German wikipedian has passed away. A list of condolescences, usually in user space, but should never happen to trigger talk page mode.
• Many other patterns are known locally, they will permit to open new sections, but not opening a conversation. Especially in project space.

@Hgzh:

• It is currently not possible to mark your reply as minor change

I don’t think it should be, either. According to m:Help:Minor edit, a minor edit is a version that the editor believes requires no review—a reply always requires review, why else would one write it? Fixing typos in one’s previous comment and the like are valid minor edits on talk pages, but they’re not (yet) available in DiscussionTools.

---

@PerfektesChaos:

While the hooks in my previous contribution are to be fired by DiscussionTools, it might listen to another one:

• mw.hook( "DiscussionTools.inhibit" ).add( finish );

If the CSS class proposed by Hgzh is not suitable and you want to disable the reply tool on the whole page instead, I think a parser switch like __NOREPLYLINK__ is a better solution, as it requires no JS, which means that

• no interface admin is required—smaller communities often have no interface admins, so the ability to configure DT themselves instead of relying on global interface editors is a huge difference;
• the reply tool can be disabled on server side—instead of adding the reply links on the server side and disabling them on the client side, the links are not added in the first place, so no unnecessary JS/HTML is downloaded and executed, and there’s no flash of the reply links.

@Tacsipacsi I don't think every reply requires review (by everyone). Imagine a discussion on a frequented talk page. User B helps user A who had a question on a side aspect in this discussion and A just replies thank you, B - it's a kind reply but not interesting for everyone else following the discussion, and could be skipped on their watchlists if wanted. But in general I think this can have quite low priority.

@Hgzh: A thank you message doesn’t require review, indeed—however, a minor edit still appears on watchlists, RC etc.; the thanks feature solves this problem better. I’d prioritize the ability to thank comments inline, with a button around the reply button (as opposed to thanking edits from the page history).

On parser switch like __NOREPLYLINK__:

• This would extend the entire Wikisyntax to support one feature of one particular tool on the old-fashioned talk page mode.
• A pattern recognition of pages with a certain naming scheme, e.g. names containing /poll or /archive or whatever in local language, can be applied to all pages without a need to change them. This can be maintained at central point.
• The __NOREPLYLINK__ approach would require that every user creating a page and all existing pages need to be equipped with this switch itself or a template providing that. That makes it more difficult for users to maintain those issues.