Talk:Talk pages project/Replying

Jump to navigation Jump to search

About this board

The team would value any thoughts and/or questions you have about this new tool for Replying to specific comments on talk pages.

Levivich (talkcontribs)

How do I turn off the reply tools? Turning off the reply tool in my preferences is not actually turning off the reply tool for me (turning off discussion tools in the preferences works fine for me tho).

Reply to "How to turn off?"
ToBeFree (talkcontribs)
ToBeFree (talkcontribs)
ToBeFree (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

In that last diff, did you reply to the first comment? Or to the last one?

ToBeFree (talkcontribs)

To the first one, resulting in one indentation level

Whatamidoing (WMF) (talkcontribs)

That's what I thought. This is "technically correct" but not what I want. It supports this use case:

Which articles should we edit next? Let's make a list. User:Whatamidoing (WMF) (talk)

  • Apples
  • Bananas
  • Oranges
Maybe we shouldn't just edit articles about fruit? Example (talk)

but not the more common use case:

Please vote. User:Whatamidoing (WMF) (talk)

This should be addressed as part of handling votes.

ToBeFree (talkcontribs)

The first use-case should probably look like this:

Which articles should we edit next? I propose these:

  • A
  • B
  • C


Sounds good. ~~~~

Reply to "Listgap"
আফতাবুজ্জামান (talkcontribs)

this edit broken the page (scroll down at the end to see).

Tacsipacsi (talkcontribs)

There’s an unbalanced <nowiki> in the section titled সাহায্য. This doesn’t cause any issues as long as no </nowiki> appears on the page after it, which is what happened in this edit. While the page appears broken after this edit, it was already broken before, and a non-reply tool edit containing a nowiki’d signature would have also broken it. DiscussionTools tries to avoid “dirty diffs”, i.e. edits that touch other parts of the page, and not breaking the layout would need a dirty diff.

Whatamidoing (WMF) (talkcontribs)

Do you know what the person typed? Tacsipacsi is correct about the source of the problem. Did the person type ~~~~ (unnecessary, but usually harmless)? Or maybe paste the code?

আফতাবুজ্জামান (talkcontribs)

The person (he) was in visual mode. I'm not sure what he typed first. But it looks like at the end he added four tilde, then visual mode automatically added nowiki to escape it. And since there was unbalanced nowiki in the section titled সাহায্য, after saving the reply, it broke the page. I think this is expected behaviour. Only problem was, subsequent edit moved everything in one line, later i fixed that manually.

Tacsipacsi (talkcontribs)
Reply to "Bug?"

Adding templates in New Discussion tool Visual mode

Pelagic (talkcontribs)

I like it that the Visual mode in New Discussion handles templates, wikitables, pre, etc. that were created in Source mode (which can't be used in Reply Tool until there’s markup for multi-line list items ... well, templates could, if there was some way to flag in TemplateData which ones are single-line safe).

I noticed that some VE magic text like ‘[[‘ and ‘<pre>‘ activates the corresponding edit cards, but ‘{{‘ doesn’t. Instead I get the message ‘wikitext markup detected ... switch to source mode’.

Patrik L. (talkcontribs)

Hmm, I noticed one interest thing. Go here and copy one of the templates (listed in the table after "Indikátory"). Then try to reply to any comment and paste copied template in VE. It works until I switch to a source mode and back to VE.

Whatamidoing (WMF) (talkcontribs)

The {{ key sequence (the devs assure me that a key sequence is importantly different from a keyboard shortcut) used to work, but was disabled when they turned off template insertion in the visual mode. I expect the key sequence to be re-enabled whenever the RFC about multi-line comments is finally handled.

BTW, if you two are interested in that RFC, then the draft is at User:PPelberg (WMF)/sandbox. I'll ask @PPelberg (WMF) about it the next time we talk. Maybe we can at least get the draft moved to the mainspace here, so that people can start putting it on their watchlists.

Reply to "Adding templates in New Discussion tool Visual mode"

Copy paste text from previous comments, and keepwiki-links

LittleGun (talkcontribs)

I have really adopted this functionality, and use it constantly.

I miss one thing:

Very often I want to copy text from previous comments, to quote, but mostly to copy the wikitext; url:s and wikilinks for clarifcation (rather than saying "look above, it is somewhere in previous links" implying "you lazy S*B") and usernames (for pinging).

Now when you copy it becomes plain text.

  • So, when hitting answer, if text marked and copied around the "answer-dialogue-box" would be wikiformated in the same way as it was when pasted into the answer dialogue, is missed.

I hope it is understandable what i miss, and I understand it is a lot to ask for. But does such a function make sense to anyone but me? To me it affects more than half of my answers, maybe more, mostly due to pinging where I cant use copy-paste.

Valereee (talkcontribs)

LittleGun, I think you're saying you'd like to copy formatted text and have it transfer still formatted? I suspect that would fight with another feature in Visual, which is to allow you to type formatted text and have it appear as typed, such as when you want to teach a newbie how to create a ping. In Visual, if you insert or type an existing page, it should offer to format as a wikilink for you. I haven't tried with a URL.

Maybe if Source allowed you to copy formatted text and when you pasted, it would reformat? Is that what you're looking for?

LittleGun (talkcontribs)

Yes, i want it to work as when copying text from visual editor editing: if I paste to a wikitext window it becomes wikicode. If I paste to a visual editor window it becomes formatted text. I want copied text to keep its formatting. Now it becomes plain text.

Tacsipacsi (talkcontribs)

I tried the copying and pasting into the visual mode, and some basic formatting like links and bullet points are kept. (Other things like headings and images are lost, though.) Maybe it depends on the browser/operating system; I have Firefox 78 on Debian GNU/Linux 10 “buster”.

LittleGun (talkcontribs)

OK, thank you. What I am after is the links; for pinging, to refer and to quote. If possible. (I am using Chrome on a Chromebook, mainly)

Tacsipacsi (talkcontribs)

As I wrote, copying and pasting links works for me right now. Do you have issues? Now I tried in Chromium as well, and it also works for me. (Chromium is Google Chrome’s completely open-source version, with hardly any difference between Chrome and Chromium, so if it doesn’t work for you, it’s more likely to be caused by the difference between Chrome OS and the Cinnamon desktop environment I use on Debian than the one between Chrome and Chromium.)

Pelagic (talkcontribs)

Yes, in a section-edit you can copy source from higher up in the edit box, but in Reply mode, the previous comments are HTML, so handling that formatting is useful. LittleGun, are you thinking of the “NWE” / “2017 wikitext editor”, where you can paste formatted text and it will ask do you want to convert to wikitext? There’s a prototype toolbar for Source mode which uses the 2017/NWE editor and offers that conversion. Paste formatted should already work in Visual mode.

Reply to "Copy paste text from previous comments, and keepwiki-links"
Hgzh (talkcontribs)

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:

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

PerfektesChaos (talkcontribs)

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.

PerfektesChaos (talkcontribs)

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.
Tacsipacsi (talkcontribs)


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


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.
Hgzh (talkcontribs)

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

Tacsipacsi (talkcontribs)

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

PerfektesChaos (talkcontribs)

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.
Reply to "Feedback from dewiki"

Suggestion: one-click to add user(s) to edit summary

YFdyh000 (talkcontribs)

Allow one click to quickly adding the user being replied or multiple participants in the section to the edit summary to mention (ping).

Valereee (talkcontribs)

Oh, that would be nice, I agree!

Whatamidoing (WMF) (talkcontribs)

They're talking about a couple of different options. So, first: have you tried the ping tool, which is (currently) only in the "visual" mode? (Most experienced editors are going to default to the wikitext mode.

Another option is to have a tickbox (outside the message) that says something like "Do you want to ping other participants? ☑︎ Alice ☐ Bob ☐ Chris" or "You're replying to a comment by Alice. Ping Alice? ☑︎ Alice" What do you think would be best?

Valereee (talkcontribs)

I do use the ping tool, but sometimes I'd prefer to ping someone (or link to something for that matter) in the edit summary for whatever reason -- like, maybe I'm making them aware of the situation without actually asking them to chime in, or pinging them actually in the post feels like I'm being aggressive toward whomever I'm discussing something with. I always find linking/pinging in the edit summary a challenge as you can't preview it to make sure you've done it right, and of course you can't edit. So having the tool make sure that ping/link is correct would be helpful for this non-techie.

YFdyh000 (talkcontribs)

1. I have tried the ping tool in visual mode, but I prefer the wikitext to editing because of some advanced usage and modify templated contents is crappy in visual mode.

2. I expected it to be an input field rather than a select boxs area, and to avoid increasing harassment to irrelevant people. The user should be clearly aware of who he responded to, rather than mentioning based on the username or all selected.

This can also use a separate mention input field, and then allow the pasted content to include the username links to convert the mentioned person, and append these to the edit summary. But this seems to be non-touch friendly, so the selection mode may still be needed.

This should also disclose who declined to receive mentions, if this is not privacy.

Reply to "Suggestion: one-click to add user(s) to edit summary"

Replying to deletion discussions

Timtrent (talkcontribs)

Please see Wikipedia:Miscellany for deletion/Draft:Endeavor Business Media where I replied to the original nomination. Unlike Reply Link (Enterprisey's script) I did not get the the chance to reply to the discussion per se, but chose to use intelligent indenting to place an indented reply below the comment left by the editor who nominiated the draft for discussion, at the foot.

I am content with this comment's indentation by happenstance and good fortune, but normally would not haven

You wight wish to set up dummy AfD and Mfd discussions to test behaviour in them. I acknowledge that thsi is Beta.

Reply to "Replying to deletion discussions"
Psychoslave (talkcontribs)

I activated it today on French Wiktionary, and didn't encountered any issue. I especially like the fact that it's possible to switch from VE and wikicode while keeping a visual rendering is excellent.

I see that models are not yet available in VE mode, but the notification message is clear, well done.

Here are some additional feature I would love: - in wikicode edit mode, option to show the rendering side by side with the wikicode, rather than a top/bottom layout - possibility to switch to "edit section wikicode" while keeping what was typed so far. Not a big deal, as the wikicode can be copied and pasted, but it would be fine to avoid this additional step and the "are you sure you want to leave this page, all changes will be lost?" message.

Have you been through accessibility tests?

Matma Rex (talkcontribs)

Have you been through accessibility tests?

If you mean keyboard and screen reader accessibility, then there are a few known issues: T271773, T274423. We'd appreciate feedback on this, especially if you use a screen reader regularly. We neglected keyboard accessibility a bit, because bug T172694 made it impossible to leave the editor area using only the keyboard (in visual mode), but that is fixed now, so we can test other improvements more easily.

Psychoslave (talkcontribs)

Thank you for the feedback with the precise hints to the relevant tickets. I greatly appreciate it.

I don't use a screen reader, and have no particular accessibility requirements personally. I'm careful on this topic purely because I desire that knowledge becomes as widely accessible as possible to all human beings. I can ask for feedback in canals that I know as including people with such a profile though.

Psychoslave (talkcontribs)

Hey @Matma Rex, I was able to get a reply from someone who uses a screen reader, after a message on April’s accessibility mailing list. We talked by phone and it appears that actually even consulting Wikipedia (in French) is quite a big challenge. Luckily we live in the same city. So we planned to meet next week, and that way I will be able to help better and better understand this difficulties.

If you have particular recommendations on how to conduct this test session, or know someone or some documentation I should consult before this meet up, please let me know. The better I'm prepared, the more useful feedback I'll be able to give.


Matma Rex (talkcontribs)

Wow, I didn't expect that when I said we'd appreciate feedback, thanks! I'm curious to hear what they say.

I don't really have recommendations, sorry. If you're meeting with someone who's generally comfortable using websites with a screen reader, I wonder what they think about the general structure of the discussion – I would expect that the most difficult part of replying would be making sense of the nested lists used to indent comments (they're messy enough even if you're not sight-impaired), as well as the signatures, rather than actually submitting the reply.

I also wonder if they know about any of the keyboard shortcuts (in the editor and elsewhere in the interface), and whether they're be able to use the tools in the visual mode (poorly named, huh), like e.g. adding a link.

Matma Rex (talkcontribs)

If you haven't used a screen reader yourself, it might be helpful to try one out. Windows and macOS/iOS both have basic ones built in (they're called Narrator and VoiceOver, respectively). Windows Narrator will show you a quick start guide, with the basic navigation commands, when you open it fo the first time. It's probably not the same software as they're using, but it at least follows the same concepts.

Psychoslave (talkcontribs)


Good to see that this kind of approach raises positive appreciations.

I can't promise you we will go as far as engaging in a discussion using this extension, since from my early feedback, it looks like even consultation might be a problem. But we will go as far as possible in testing interactions with a Mediawiki instance when you can only access it through screen reader.

Chances are good that it will be conducted with a FLOSS tool, since I found the person through the April mailing list, maybe Orca. For now I can't tell more, but will provide all relevant information I might acquire with the planned session.


Psychoslave (talkcontribs)

Hey @Matma Rex, I finally was able to take time to fill a report of the session we made Monday. Sorry for the delay. Accessibility of Wikipedia, a March 2021 use test session is on Meta. Please share your thoughts about it, here or on the talk page on Meta. Please let anyone you know as interested in the topic know that the page exists and that comments are welcome. That might help me to do better in future actions like that one.


Reply to "Seems great, thanks"

Missing toolbar in source mode

Summary by Patrik L.

Prototype is here (and yes, Patchdemo is slow, it is only protoype).

Ijoe2003 (talkcontribs)

I noticed that the source mode in new talk page reply UI has missing the toolbar and it's less useful than Visual mode. It's very odd that source mode doesn't share an important element from Visual mode.