Talk:Talk pages project/Replying/2022

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

Provide quoting tool

T266821: Consider ways to help with quoting comments by users

It would be nice to provide a way to allow users to quote others such as by using quote templates so that they can respond to specific parts of another user's response. Lectrician1 (talk) 20:46, 7 January 2022 (UTC)

Support/Oppose buttons

T259865: Add support for voting-style discussions

It would be convenient if there were thumbs up and thumbs down buttons next to the reply link. Clicking on them would allow you to select what type of support/oppose template you want to add (support, approve, etc.) and then it would add it. Lectrician1 (talk) 23:12, 10 January 2022 (UTC)

hi @Lectrician1 – we appreciate you stopping to share this idea.

A resulting question for you: Are you able to share a link to a discussion you could imagine yourself using functionality expressing approval, support, disapproval, etc. within?

In the meantime, here is a link to the ticket where we we have been exploring functionality similar to what I understand you to be describing: T259865. PPelberg (WMF) (talk) 01:50, 11 January 2022 (UTC)

Often there are simple ideas that I support and maybe others do as well on the English Wikipedia's Village Pump but I don't always edit the topic and show my support. Lectrician1 (talk) 02:40, 11 January 2022 (UTC)

Understood; this context is helpful...thank you for sharing it. PPelberg (WMF) (talk) 19:41, 31 January 2022 (UTC)

The English Wikipedia doesn't use {{Support }} and similar templates. See this 2018 TFD and this 2021 RFC. These kinds of templates are widely used elsewhere. Whatamidoing (WMF) (talk) 22:05, 7 February 2022 (UTC)

Adding signature when bulleted list is used

This reply tool is the best thing since sliced bread!! I use it all the time on Wiktionary. (Sadly it can't cope with the way we transclude monthly discussion pages to the main discussion venue, say at wikt:WT:BP.)

There is one issue I've found. Suppose I want to post the following comment using the reply tool:

---

Here is a quote I found:

• "The mighty shall fall." (Perkins, A, 2004)

We could also use this one:

• "The crumbs will be all that remains." (Simpson, L, 2009)

---

The reply tool adds my signature at the end of the last bullet point, that is, after "2009)". Instead I think it should add my signature on a separate line after the bullet point. This, that and the other (talk) 05:13, 11 January 2022 (UTC)

(Sadly it can't cope with the way we transclude monthly discussion pages to the main discussion venue, say at wikt:WT:BP.)

Let me just say this is something we've considered, and it works on many other pages with a similar setup, e.g. w:fr:WP:Le Bistro.

I think it doesn't work on your page because you're using Template:discussion_recent_months to transclude them, rather than putting the transclusions directly on the page. If you substed that template, it would probably work. I assume you don't want to do that though, in which case, you'll have to wait for T259824.

The reply tool adds my signature at the end of the last bullet point, that is, after "2009)". Instead I think it should add my signature on a separate line after the bullet point.

It actually works that way in visual mode, but in source mode, so far we tried to avoid parsing wikitext, which would be needed to do that correctly. As a workaround, you can just type ~~~~ yourself in the proper place while using the reply tool source mode. Matma Rex (talk) 15:16, 11 January 2022 (UTC)

Ah, I didn't realise visual mode worked in Wiktionary - VE isn't available anywhere else on the site. Nice to know! This, that and the other (talk) 02:30, 12 January 2022 (UTC)

Highlighting is wrong

When adding a new section containing subsections (level 3 and below), on save only the last section (regardless of level) is highlighted, instead of the whole message. The last L2 section should be highlighted instead. Strainu (talk) 11:15, 12 January 2022 (UTC)

hi @Strainu: are you able to share a link to a diff that produces the highlight issue you encountered above? PPelberg (WMF) (talk) 19:39, 31 January 2022 (UTC)

@PPelberg (WMF) see here. Strainu (talk) 20:37, 31 January 2022 (UTC)

This is probably because there is no content in between the ==Section heading== and the first ===Subsection===. (I'm not certain whether it requires a signature there, or just some text, but I'm pretty certain that there must at least be some text in that location the top of the comment to be recognized as existing.) Whatamidoing (WMF) (talk) 03:26, 19 February 2022 (UTC)

Edit conflicts

T250295: Should we display a note about automatically resolving an edit conflict?

I forget if I've brought this up somewhere before, but edit conflicts are an issue with this tool that needs to be resolved before it goes out of beta. When you've been writing out a comment and someone else edits the article, before when you tried to click publish you'd get the edit conflict screen. Sometimes that'd be annoying, but other times it'd allow you to adjust what you write to take in their comment, or at least to add the edit conflict template to your comment to indicate that you wrote it without knowledge of theirs. However, the new reply tool just powers through and posts the comment, without any tag.

This could result in some awkward social situations (let me know if you're having trouble imagining them and I'd be happy to concoct examples). I'd recommend that the tool either learn to apply the EC template or display a heads up confirmation that lets you read the new comment before deciding to publish. Cheers, Sdkb ^talk 02:20, 24 January 2022 (UTC)

Ha! Now that you bring this up, I realise it's been happening to me. Several times my edit has gone through, messing up in the process an edit that someone else had made minutes before. I couldn't understand why I had been (as I thought) editing a older version of the page. MichaelMaggs (talk) 09:20, 24 January 2022 (UTC)

@Sdkb: we appreciate you bringing attention to the experiences you've had with the Reply Tool and the way that it currently goes about automatically resolving edit conflicts.

A couple of resulting questions for you below and then one more that I'm going to post a separate comment...

This could result in some awkward social situations (let me know if you're having trouble imagining them and I'd be happy to concoct examples)...

Examples would be great...can you please share them?

...needs to be resolved before it goes out of beta.

Can you say more here? What is leading you to perceive making adjustments to the way the Reply Tool automatically resolves edit conflicts as rising to the level of blocking the deployment of the Reply Tool as a default-on feature? Note: I appreciate it might be difficult to answer this question in a way that feels "complete," but an attempt will help us better understand the impact it's having on you. PPelberg (WMF) (talk) 01:08, 25 January 2022 (UTC)

@MichaelMaggs it's helpful to hear the way the Reply Tool automatically resolves edit conflicts is causing you trouble...we value you sharing this feedback with us.

A resulting question for you and @Sdkb: What – if anything – about the "need statement" below do you think needs changing?

Need Statement: "As someone who is drafting a comment using the Reply Tool, I want to know when someone publishes a comment in the same section I am drafting a comment within and what they have said, so that I can decide whether or not to make changes to the comment I'm drafting prior to publishing it." PPelberg (WMF) (talk) 01:23, 25 January 2022 (UTC)

Here's a specific example. When replying to a recent comment in an active thread it's embarrasing, to say the least, to find on posting it that the comment you are replying to has while you were writing been significantly altered by its author (as of course they are perfectly entitled to do before a reply has been posted).

I think that the Need Statement is excellent. MichaelMaggs (talk) 10:22, 25 January 2022 (UTC)

Yep, great example. Often, that'll happen when someone says something uncivil, and as another editor is writing a comment chiding them for it, they cool off enough to think better of what they wrote and change it. Sdkb ^talk 16:33, 25 January 2022 (UTC)

Examples would be where someone makes a point, and then I make the exact same point, which comes across as a violation of w:WP:READ. Or in an AfD, I !vote delete on the basis of no reliable sources provided, and then the editor who just provided such sources (that I didn't see) asks a little annoyedly why theirs aren't good enough.

On importance, a more precise way of putting this might be "this should be resolved before work on this feature stops". It's certainly an issue but not something that needs to impede wider deployment if you're getting close to that. The biggest issue for me is still that it adds a signature sometimes when I don't want it, e.g. for Barnstars and other templates that sign for you within a box. Best, Sdkb ^talk 01:41, 25 January 2022 (UTC)

@MichaelMaggs + @Sdkb: the examples you shared^{[1] [2] [3]} are helping us to clearly visualize/understand the issue the current experience is perpetuating...thank you for sharing them.

With these example in mind, we've started "sketching" what the user experience could look like to fulfill the "Need Statement" we talked about above.

You can review the proposed user experience by reading T250295's "Requirements" section. If reading it brings any thoughts/concerns/questions to mind, we'd value you sharing them with us here, or on the ticket. PPelberg (WMF) (talk) 04:44, 26 January 2022 (UTC)

Something else that might be useful to know: How often does this happen to you? Do you encounter an embarrassing situation once a day, once a week, once a month, once a year?

The team can pull stats on how often an edit conflict gets resolved automatically, but what they need editors for is to tell them how often that automatic action creates enough of a problem that you self-revert or substantially change your reply. Whatamidoing (WMF) (talk) 21:55, 7 February 2022 (UTC)

I expect you can extract stats on how often I've used the tool, but overall I've had two situations in the last two months that I'd say were difficult/embarrassing. In both cases I spent quite some time trying to work out what had gone wrong, and I think in one I apologised to another editor on the basis that I must accidentally have been editing an old version of the page.

I'd be wary about using stats in this way to inform how much priority you give to this. Nobody knows, for example, how many instances they've had when they didn't notice anything. But an unnoticed error resulting in what appears to be an irrelevant, stupid or unnecessarily aggressive reply will remain forever in that editor's history, and when it's dug out again later for the purpose of criticism or even objection to an RFA, who can then tell that it really wasn't the editor's fault?

Most important in avoiding major issues, of course, is to make sure the editor is aware of any changes to the specific comment that they are replying to. Changes to other comments in the same section, while useful to know about, are generally going to be less critical. MichaelMaggs (talk) 12:17, 8 February 2022 (UTC)

Hmm, that's a little hard to say, and it depends entirely on how active an editor is. Personally, just earlier today, I encountered a situation where I mildly feared there would be an unhelpful edit conflict when I replied to a new post at the Teahouse and worried another user might have beat me to it, creating an unhelpful duplication of information. Luckily it didn't happen for me this time, but for another user who replied a minute after me, it might've. Sdkb ^talk 22:17, 7 February 2022 (UTC)

I think the risk depends on how much time you spend on active discussion pages. I've probably used the Reply tool about 400 times during the last month. I think I've regretted the automatic resolution of edit conflicts twice during that time period. So perhaps the risk for busier pages is about 1%? Whatamidoing (WMF) (talk) 01:29, 9 February 2022 (UTC)

Improvements to Automatically Resolving Edit Conflicts

T250295: Alert people when new comment(s) posted in a discussion they are replying within

The Editing Team is in the midst of planning an improvement to the Reply Tool that will alert you, in real-time, when someone posts a new comment in the discussion you are drafting a comment within.

This way, you can decide whether the new comments that have been posted warrant you making changes to the comment you had been drafting.

Before moving forward with implementing this functionality, we had a question for you all...

===Question===

Do you think being alerted when a new comment is posted within the discussion (read: == H2 ==) you are drafting a comment within will be helpful? Do you think it will be distracting?

Note: thank you to @Sdkb and @MichaelMaggs for resurfacing this issue in Talk:Talk pages project/Replying/2022#h-Edit_conflicts-2022-01-24T02:20:00.000Z, PPelberg (WMF) (talk) 00:51, 27 January 2022 (UTC)

Yes, I would find that helpful. I often have the same problem. I could see that it might be distracting to some people, but if it were something that could be turned on and off that would take care of that. Valereee (talk) 12:58, 27 January 2022 (UTC)

Agreed; having this as a setting in mw-prefsection-editing-discussion would be nice. Tol (talk | contribs) @ 19:21, 27 January 2022 (UTC)

I could see that it might be distracting to some people, but if it were something that could be turned on and off that would take care of that.

Great observation, @Valereee. We agree with you in thinking there is a balance to be found that makes it so these alerts equip people with information they can use to improve the comments they are drafting.

For now, we think the "only show alerts when new comments are posted in the same section" approach will be a strong enough filter to make the alerts valuable to people who are receiving them.

Although, if this approach ends up causing alerts to be sent that distract people, I'm thinking we can consider improvements like:

• Making the alerts optional (as you proposed)
• Adjust the scope of the changes people are sent alerts about. More in T300216 PPelberg (WMF) (talk) 02:57, 28 January 2022 (UTC)

@PPelberg (WMF): Yes; this would be helpful. I don't think it would be distracting if done correctly (I'm imagining a little icon or dot somewhere non-intrusive). Tol (talk | contribs) @ 00:56, 27 January 2022 (UTC)

(I'm imagining a little icon or dot somewhere non-intrusive).

+1! We're imagining the kind of "alert" that you would notice in your peripheral vision.

I'm glad you mentioned this feedback explicitly for it's the reminder I needed to document where/how we've been thinking the alert ought to appear. PPelberg (WMF) (talk) 02:47, 27 January 2022 (UTC)

Reply button next to heading of topic

phab:T249886: Create a new workflow for posting a comment w/o indentation

Right now creating a new "thread" in a discussion and not replying to someone requires editing using Wikitext. It would be nice if there was a reply button next to the header of the topic so that you can create a new "thread". Lectrician1 (talk) 19:24, 29 January 2022 (UTC)

There were some previous requests for this: T249886. Matma Rex (talk) 21:05, 29 January 2022 (UTC)

Signature

T268558: minor (<small>-wrapped) comments to be saved via the reply link

I just did an edit like this: <small>Edit. --~~~~</small> The tool did not recognize my signature and added a full size signature at the end of my edit. It's the same problem, when sth. is written after the signature, like this: Edit. --94.219.4.152 02:07, 30 January 2022 (UTC) P.S. It was'nt me. Please tell the tool, that it must not add a signature, when there is a signature anywhere in the text. --94.219.4.152 02:07, 30 January 2022 (UTC)

I've had this same issue. It's not a huge deal, as generally when I'm using small it's because I'm making some sort of joke or tangential remark, but still it would be nice to be able to use the tool instead of having to go into source. Valereee (talk) 12:00, 30 January 2022 (UTC)

It's a known problem, documented here: T268558. We are planning to work on this soon (no timeline yet, but as you can see on Phabricator, it's marked as a blocker to be resolved before the opt-out deployment on English Wikipedia). Matma Rex (talk) 19:30, 30 January 2022 (UTC)

Link to reply(s)

It would be nice if there was a button that gave a link to a reply in a discussion.

This link would be the same link that scrolls to and highlights the reply that you get for reply notifications (example).

Additionally, you could select multiple replies to link to. Lectrician1 (talk) 16:46, 2 February 2022 (UTC)

This is possible, but not easy right now. The links look like this: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#c-Whatamidoing_(WMF)-2022-02-02T17:22:00.000Z-Xaosflux-2022-02-02T11:14:00.000Z – so they're ugly, and not the kind of thing you could easily construct by hand, but if you click on it, you'll see that it takes you straight to the comment, with the same highlighting style.

I believe that JKlein (WMF) has been considering something like this for a new Talk pages project/Usability sub-project. You might be interested in looking at that. Whatamidoing (WMF) (talk) 17:37, 2 February 2022 (UTC)

I don't think it matters that the link is ugly and I don't see any way we can possibly make it shorter. Just having access to the link to begin with is benefiting users a lot. Lectrician1 (talk) 18:32, 2 February 2022 (UTC)

It would be nice if there was a button that gave a link to a reply in a discussion.

@Lectrician1: we agree! In fact, we created a gadget that offers this exact functionality. If you're open to trying out experimental software, we'd value hearing what you think of the gadget.

You can find instructions for installing it here: Talk:Talk pages project/2021#h-Gadget:_Linking_to_specific_comments-2021-12-24T00:25:00.000Z. PPelberg (WMF) (talk) 03:00, 4 February 2022 (UTC)

I got a message from...

...a certain Pulciazzo. I don't have any 'wikiwhatever" account. How is it that you can send me messages about me not being correct with something I never did?

the message is (in italian):

Gentile 51.179.102.215, al prossimo contributo contrario alle linee guida di Wikipedia scatterà un blocco in scrittura sulla tua utenza, pertanto questo è l'ultimo invito a collaborare in modo costruttivo. Per favore, rispetta il lavoro altrui: segui le regole e usa il buon senso.

51.179.102.215 (talk) 15:48, 8 February 2022 (UTC)

Hello,

That message was probably not intended for you. Because you did not create an account, we have no way to distinguish you from other people who have the same IP address. This includes other people in your house, other people using the same WiFi hotspot, or in some cases other people in the same country.

You can see an explanation of this in Italian on the page where that message is shown, at the bottom: https://it.wikipedia.org/wiki/Discussioni_utente:51.179.102.215

…and you can reply to Pulciazzo on their discussion page here: https://it.wikipedia.org/wiki/Discussioni_utente:Pulciazzo – they will probably be happy to explain in more detail (also in Italian).

If you don't want to contribute to Wikipedia, then you can just ignore that message. If you want to contribute, you should create an account, so that warnings and blocks meant for other people will not affect you. Matma Rex (talk) 17:18, 8 February 2022 (UTC)

Missed special chars.

T249072: Add support in toolbar for special characters within DiscussionTools

The tool doesn't have a special char box with example "–", "€", no-break space or another. Dušan Kreheľ (talk) 14:14, 11 February 2022 (UTC)

hi @Dušan Kreheľ – you're right. Currently, the Reply Tool does not offer the special characters box/toolbar that the VisualEditor offers.

Can you please share how not having access to the special character box/toolbar within the Reply Tool has impacted you? Asked in another way: can you share what you use the special character box/toolbar for in the VisualEditor? PPelberg (WMF) (talk) 17:02, 11 February 2022 (UTC)

@PPelberg (WMF): I like using:

• "–" – Dash
• " " – No-break space

plus in Slovak:

• "„“" – Quotation mark Dušan Kreheľ (talk) 09:59, 19 February 2022 (UTC)

Dušan Kreheľ, is this a problem for typing in Czech? Whatamidoing (WMF) (talk) 03:27, 19 February 2022 (UTC)

It would be maybe nice. But for me as a programmer, it's not an obstacle to use the "reply" tool.

It might be good to have statistics at the earliest what characters users use.

Ping: @Whatamidoing (WMF). Dušan Kreheľ (talk) 10:03, 19 February 2022 (UTC)

Presumably that would depend on which language they were writing in. Amire80, has the Language team ever looked into this question (which characters are most used, or most needed-but-missing)? Whatamidoing (WMF) (talk) 02:19, 25 February 2022 (UTC)

No, we haven't looked at it systematically. Amir E. Aharoni (WMF) (talk) 05:31, 25 February 2022 (UTC)

Ouch. As someone who edits in diacritic-ridden languages, mostly using an English-optimized keyboard, that could make it more difficult for me to write non-English replies. I've had long discussions in French on Commons. This is also a problem offwiki. I have non-WP-specific tools that give me diacritics and special chars for the scripts I write in (including IPA), but on-wiki I often use the intenal tools for proximity. I wish compose keys worked reliably, it would make code-switching far easier.

Could this be done using " Alt-Shift-S for 'Publish' "-like keyboard shortcuts (see topic above)? HLHJ (talk) 00:05, 7 August 2022 (UTC)

I believe that they're hoping to add the visual editor's special character palette to the [reply] tool in the coming weeks/months. If you'd like to have a look at it (NB the first section varies per wiki), then try adding lines 7–15 from m:User:Whatamidoing (WMF)/global.js to your own global.js page. (And then make a note to take those lines back out in a few weeks, so you don't end up with two of them.) Whatamidoing (WMF) (talk) 19:43, 18 August 2022 (UTC)

@Whatamidoing (WMF) Widget ok. Design: If he scrolls down the page, there is a border on the right side of the widget. Let there be a border between the widget and the text, and it will also match the slider placed opposite. Dušan Kreheľ (talk) 17:09, 21 August 2022 (UTC)

I think NAyoub (WMF) will be interested in this detail about the borders. Whatamidoing (WMF) (talk) 00:20, 26 August 2022 (UTC)

Thank you, WAID, I've added that scriptbit. Unlike the original, I can select one "language" submenu and then scroll to another (i.e. selection "Latin" or "Often used" and scrolling to "Runes"), which was a bit unexpected and caused me momentary confusion.

This user interface might be worth looking at as a way to improve access to special chars; it chunks the special chars, which takes advantage of the fact that an editor will usually want only German special chars, or French ones, or IPA ones, or logic-symbols-related ones. It's a lot faster.

Relatedly, selecting "[underlined "A"]>Language" inserts this text:

<span dir="ltr" lang="de">Language</span>

I'm not sure what this is for. On en-wiki, there are "lang" and "transl" templates, which do left-to-right or right-to-left as needed. HLHJ (talk) 20:10, 27 August 2022 (UTC)

@HLHJ: We don't have the global template. Next way, know the user about this extra template? Use the extra addon? Dušan Kreheľ (talk) 21:07, 27 August 2022 (UTC)

The Croatian and Slovak Wikipedias do not have "transl" and "lang" templates? The reply tool could do different things on different wikis.

I don't speak Slovak or Czech, regrettably. I speak German; you can answer me in German, if you like. HLHJ (talk) 21:14, 27 August 2022 (UTC)

The "Language" item adds the HTML markup for the language you're writing in. Dann weiß mein Computer, dass ich diesen Satz auf Deutsch geschrieben habe.

It is very similar to Template:Lang, except that it works at 100% of the wikis, and not just the ~50% of wikis that have the template locally. Whatamidoing (WMF) (talk) 22:05, 31 August 2022 (UTC)

That makes sense, the templates are just easier to type. Thanks! HLHJ (talk) 00:02, 12 October 2022 (UTC)

If a page is already on my watchlist, don't offer to "Add" it

I really like the reply tool on Commons, but I've noticed a slight UI mistake. There's a checkbox marked "Add this page to your watchlist". If I'm replying on a page that's already on my watchlist, this box still appears (already selected), even though it's obviously impossible to add a page to my watchlist when it's already there. This caused me some confusion as I wondered (a) why the Village Pump wasn't on my watchlist already and (b) why the default was to add the page to my watchlist.

The normal editing page labels the equivalent control "Watch this page", which is more accurate. Bjh21 (talk) 14:56, 11 February 2022 (UTC)

I think they chose this text because it would make sense to a newcomer. If you don't know what Special:Watchlist is, then "watch this page" probably doesn't make sense. Peter, am I remembering that correctly? Whatamidoing (WMF) (talk) 03:30, 19 February 2022 (UTC)

That seems reasonable. Maybe it should switch to "Keep this page on my watchlist" in the case where it's already there. Bjh21 (talk) 13:34, 19 February 2022 (UTC)

Prototype Feedback: Automatic Edit Conflict Improvements

A prototype is ready for you all to try of functionality that will alert you, in real-time, when someone posts a new comment in the discussion you are using the Reply Tool within.^[1][2]

Below is the information you will need to:

• Try the prototype
• Share feedback about the prototype

---

1.@Sdkb surfaced the value in improvements to how the Reply Tool can more effectively resolve edit conflicts in Talk:Talk pages project/Replying/2022#h-Edit_conflicts-2022-01-24T02:20:00.000Z.

2. In Talk:Talk pages project/Replying/2022#h-Improvements_to_Automatically_Resolving_Edit_Conflicts-2022-01-27T00:51:00.000Z, @Valereee and @Tol shared feedback about the approach the mw:Editing Team were planning to implement PPelberg (WMF) (talk) 01:28, 12 February 2022 (UTC)

===Try the Prototype===

1. Visit https://patchdemo.wmflabs.org/wikis/c555f5ca84/wiki/Main_Page
2. Create an account by clicking the Create account link. Note: this is a test wiki so you will not be able to log in using the same username you use on other Wikimedia wikis.
3. Visit an old revision of a talk page (e.g. Talk:Douglas Adams)
4. Click a [ reply ] link within a section that, in subsequent revisions, has had new comments posted to it (e.g. Looking for help from a Python dev to help getting ReFill to build and run)
5. Start typing a comment
6. Wait 10-30 seconds
7. Notice the ⚠️ ___ new comments... alert appears beneath the Reply Tool's text input
8. Click the ⚠️ ___ new comments... alert to reveal the new comments that have been posted
9. Publish the comment you started drafting in "Step 5."
10. ✅ That's it PPelberg (WMF) (talk) 01:28, 12 February 2022 (UTC)

===Share Feedback===

Once you have tried the prototype and you are ready to share what you think of it, please add a new topic to this talk page by doing the following:

1. "Start a new topic" on this talk page
2. Name this new topic: "Automatic Edit Conflicts Prototype Feedback: YOUR USERNAME"
3. Write your answers to these questions:
   1. What did you find unexpected about the prototype?
   2. What do you appreciate about the prototype?
   3. What do you wish was different about the prototype?
   4. What concerns you about the prototype? PPelberg (WMF) (talk) 01:29, 12 February 2022 (UTC)

I don't think this prototype is working any longer. Whatamidoing (WMF) (talk) 03:41, 19 February 2022 (UTC)

Automatic Edit Conflicts Prototype Feedback: Sdkb

T301750: Reassure people comment drafts will be saved

T300215: Improve experience for locating changes to a discussion

T300502: Be able to refresh content on a talk page without reloading the page or losing your reply

• What did you find unexpected about the prototype?

The reload of the page was a bit more substantial than I expected. I would've thought the new comment would just appear.

• What do you appreciate about the prototype?

I liked that it overall worked effectively to let me know about the new comment.

• What do you wish was different about the prototype?

It was hard to tell what the new comment was; it would've been nice if it'd flashed in orange the same way new comments do in discussions I've subscribed to.

• What concerns you about the prototype?

From the fact it felt like the whole page reloaded and the "changes recovered" notice popped up, it seemed like there was some risk that it might have lost my comment during the reload. This would make me feel a little uneasy using the feature, especially if I was writing a long comment, since I'd worry that if the servers crashed at that moment or something it might lose my draft. Sdkb ^talk 01:42, 12 February 2022 (UTC)

Thank you for reviewing the prototype, @Sdkb. A couple of comments/questions in response below...

The reload of the page was a bit more substantial than I expected. I would've thought the new comment would just appear.

We agree with you in thinking the full page reload feels "substantial." In fact, we're working on a patch right now that will enable us to display to content on a talk page without reloading the page. More in T300502.

I liked that it overall worked effectively to let me know about the new comment.

Okay, good!

It was hard to tell what the new comment was; it would've been nice if it'd flashed in orange the same way new comments do in discussions I've subscribed to.

+1. The work you are describing above to make it easier for people to locate the new comments the alert is making them aware of will happen in T300215.

From the fact it felt like the whole page reloaded and the "changes recovered" notice popped up, it seemed like there was some risk that it might have lost my comment during the reload. This would make me feel a little uneasy using the feature, especially if I was writing a long comment, since I'd worry that if the servers crashed at that moment or something it might lose my draft.

Mmm, yes. If you can you think of a comparable experience on-wiki or off- where you are NOT worried that the changes you've made will be lost if/when you leave/reload the page, we'd be keen to know.

Reason being: I wonder whether there are design patterns we could borrow to improve the current implementation to provide the assurance you, and others, are seeking.

In the meantime, here is a new ticket for the issue you described above: T301750. PPelberg (WMF) (talk) 01:25, 15 February 2022 (UTC)

Thanks for the reply! I think resolving T300502 will take care of the recovery concern. If it's necessary to stick with the current implementation, I'm not sure much could help, as the reload of the page itself is what causes the unease. Sdkb ^talk 02:26, 15 February 2022 (UTC)

...the reload of the page itself is what causes the unease.

Understood. PPelberg (WMF) (talk) 22:09, 21 February 2022 (UTC)

Automatic Edit Conflicts Prototype Feedback: MichaelMaggs

T300216: Improve accuracy of discussion change detection

T300215: Improve experience for locating changes to a discussion

T300502: Be able to refresh content on a talk page without reloading the page or losing your reply

   1    What did you find unexpected about the prototype?

The need for a full page reload was unexpected.

   2    What do you appreciate about the prototype?

The notification bar looks good - not too intrusive - and can be clicked on easily.

   3    What do you wish was different about the prototype?

I hoped that it would indicate in some way what the changes actually were, for example with a coloured background. In very long, active discussions, it can be almost impossible to pick out which comments are new – and that's the exactly the scenario in which a warning will most often be triggered. With this prototype, I feel that in long sections I'll still have to find the changes manually by opening up a separate browser tab and looking at the page history while keeping the existing tab open so I don't lose my text

   4    What concerns you about the prototype?

The original motivation (Talk:Talk pages project/Replying/2022#h-Edit_conflicts-2022-01-24T02:20:00.000Z) was the concern was that changes can result in an embarrassing/socially difficult situation; but this prototype seems cover new comments only, and doesn't address the major concern that the specific post to which I am about to reply has been changed by its editor while I am typing. It's far more important to warn of changes to the comment being replied to than to warn of a new comment added perhaps several screens away from my current position within a long discussion section.

This could easily be addressed by providing two warnings, as appropriate: "The comment you are replying to has been changed" as well as "A new reply has been added". MichaelMaggs (talk) 09:54, 12 February 2022 (UTC)

hi @MichaelMaggs – we appreciate the thorough feedback you shared! A couple of comments and questions in response below...

The need for a full page reload was unexpected.

Noted. Would it be accurate for us to think you expected the discussion to be updated seamlessly, without the page reloading? If so, we are working to implement this in T300502.

I hoped that it would indicate in some way what the changes actually were, for example with a coloured background.

We agree it ought to be easier for people to locate what exactly has changed about a discussion. The work to improve this experience will happen in T300215.

By the way, thank you for taking the time to articulate the scenario that prompted you to share this feedback. This level of specificity helps me more clearly understand the impact of not addressing the issue you are raising!

...this prototype seems cover new comments only, and doesn't address the major concern that the specific post to which I am about to reply has been changed by its editor while I am typing. It's far more important to warn of changes to the comment being replied to than to warn of a new comment added perhaps several screens away from my current position within a long discussion section.

A couple of thoughts:

1. It is accurate to think the prototype will only show an alert when new comment(s) are added.
2. With "1." said, we are planning to improve the "change detection" so that the Reply Tool will also alert you when content within the discussion was edited. The work to implement this will happen in T300216.^[1]

Related to the above: can you think of any scenarios where you would value being notified about a comment being edited that is NOT the comment you were replying to?

---

i. If you are curious to know why we decided to only show people alerts about new comments to start, T250295#7654982 contains the thinking that went into this decision. PPelberg (WMF) (talk) 01:59, 15 February 2022 (UTC)

Hi, @PPelberg (WMF) thanks for the response here. You asked

can you think of any scenarios where you would value being notified about a comment being edited that is NOT the comment you were replying to?

Occasionally that might be helpful, for example in something like an RFC where the editor who started the section changes some text we are supposed to be discussing. It's of interest, but normally of lesser importance.

I don't know exactly what the devs understand by the term "edit conflict", but to my mind a change to the comment I'm actually replying to (or the deletion of that comment) feels like a real "edit conflict", as does the creation of new reply to the same comment by somebody else. Other more distant edits within the section feel to me more like "things it would be useful to know about".

In an ideal world, I'd like to be notified in some way that makes a clear distinction between (1) changes/additions/deletions/new reply to the specific comment I'm replying to, and (2) all other changes/additions/deletions within the section. I will always want to view the first, and only sometimes the second.

Obviously, when you get round to displaying the changes in some way, eg by colour-coding, it would make sense to mark up everything, including deletions. MichaelMaggs (talk) 14:50, 15 February 2022 (UTC)

In case you're curious, I understand that an "edit conflict", from the technical side, is a change to the line of wikitext where you are typing, plus the line immediately above or immediately below the one where you are typing. A "line" is roughly what you think of as a paragraph when you're looking at the wikitext.

If you are using the wikitext editors, and you are the second person to reply in a discussion, you will not see an edit conflict if the original post is changed while you are typing your reply. Whatamidoing (WMF) (talk) 04:47, 3 March 2022 (UTC)

I've also had this problem; while I was writing a reply, comments were added to the discussion, and when I saved my reply I got no notification and did not notice (actually, I don't remember reading the comment which the indent level says I was replying to). This produced the impression that I was rudely ignoring the last two posts and railroading the discussion. I felt the need to post an apology ("Sorry, I somehow did not see Aoidh's or rsjaffee's comments from just prior before posting, but did not get an edit conflict; my comment was more suitable for an earlier point in the discussion, and I didn't mean to come off as ignoring you!"; full discussion quoted.

I can manually check for new posts or changes, but that is easier for a computer to do. I hope this won't keep happening, as it would increase the time cost and/or social cost of this tool. HLHJ (talk) 23:52, 6 August 2022 (UTC)

Add subscribe button to specific subheadings/sections

Tracked in Phabricator
Task T303541

There should automatically or manually via a Wikitext tag/template be a way to indicate that a section should be a discussion and therefore able to be subscribed-to and have a "subscribe" button.

For example, I would like the "Discussion" section on Wikidata property proposals and the "Discussion" and "Voting" voting sections on Community Wishlist proposals to have "subscribe" buttons. Lectrician1 (talk) 17:30, 12 February 2022 (UTC)

The team is discussing some magic words, but it will probably not happen soon. Whatamidoing (WMF) (talk) 04:50, 3 March 2022 (UTC)

I don't think this is T249293 as that is about the reply tool, not topic subscriptions. While we have discussed the issue of <h2> not always being the correct heading level, we have no task yet for providing users with an override for this. ESanders (WMF) (talk) 16:39, 10 March 2022 (UTC)

Good spot, @ESanders (WMF). I've filed: phab:T303541. PPelberg (WMF) (talk) 17:30, 10 March 2022 (UTC)

Standard keyboard shortcut for 'Preview' causing problems

Tracked in Phabricator
Task T302742

Users of Source Editor are probably familiar with Alt-Shift-S for 'Publish' and Alt-Shift-P for Preview. These are two really useful keyboard shortcuts when editing.

I don't mind that Alt-Shift-S does not work with the Reply Tool, but I wish I had £5 for every time I hit Alt-Shift-P and immediately lost the reply box and couldn't find it again!

Unfortunately, Alt-Shift-P still functions, but not in a good way. I am continuously using it out of years of habit for Previewing using Source Editor, but am immediately taken right to the top of the page I was replying on and offered a Print dialogue box.

The Print dialogue box is easily cancelled, but on a really long talk page it is quite hard to scroll down to re-find the reply box again. Luckily the typed text is not lost, but the shortcut either needs deactivating, or at the very least, stopping it scrolling up to the top of the page. Nick Moyes (talk) 17:48, 12 February 2022 (UTC)

I've been annoyed by the Tab ↹ button, too. Whatamidoing (WMF) (talk) 19:58, 28 February 2022 (UTC)

Automatic Edit Conflicts Prototype Feedback: Tol

T301750: Reassure people comment drafts will be saved T300215: Improve experience for locating changes to a discussion

1. What did you find unexpected about the prototype?

   The reload was a bit surprising.

2. What do you appreciate about the prototype?

   It works well! It notifies you of new comments and presents them when requested.

3. What do you wish was different about the prototype?

   I would like if it highlighted the new comments (like it highlights comments you've just made), and if there wasn't the "changes recovered" dialogue (it makes it feel like an accidental reload).

4. What concerns you about the prototype?

   Probably the "changes recovered" dialogue, like I said above.

Thanks for the feature; it looks promising! Tol (talk | contribs) @ 19:06, 13 February 2022 (UTC)

hi @Tol! We appreciate you taking the time to review the prototype and share what you think about it. A couple of comments and clarifying questions for you below...

The reload was a bit surprising.

Can you say a bit more about this...? What did you expect to happen when you clicked the ⚠️ # new comments have been added in this section. Click to reload. bar?

I would like if it highlighted the new comments (like it highlights comments you've just made)...

+1! The work to make it easier to locate/see the changes in the discussion will happen in T300215.

...if there wasn't the "changes recovered" dialogue (it makes it feel like an accidental reload).

Good spot. We're going to address this issue in T301750.

If you can you think of a comparable experience on-wiki or off- where you are NOT worried that the changes you've made will be lost if/when you leave/reload the page, we'd be keen to know.

Reason being: I wonder whether there are design patterns we could borrow to improve the current implementation to provide the assurance you, and others, are seeking. PPelberg (WMF) (talk) 01:37, 15 February 2022 (UTC)

Sure, @PPelberg (WMF)! I think I should have clarified the "surprising" comment; sorry! I was referring to how it jumped around a bit when it loaded the new comments, so it was a bit abrupt and hard to see which comments were new. On second thought, I think that this would probably be resolved by highlighting new comments.

As for saving changes in general, I like the text editor approach (where Ctrl+S saves the file, and it warns you before closing if you have unsaved changes) and the Google Docs approach (where it automatically saves and lets you know with a small indicator). For this specific application, I think that this isn't needed; I think that removing the "changes recovered" dialogue will be fine. Perhaps also changing the wording of "click to reload" (maybe "load new comments"?), as (for me) "reload" implies the Ctrl+R type, in which changes are usually lost. Tol (talk | contribs) @ 04:17, 15 February 2022 (UTC)

I was referring to how it jumped around a bit when it loaded the new comments, so it was a bit abrupt and hard to see which comments were new. On second thought, I think that this would probably be resolved by highlighting new comments.

Ah, I see; I appreciate you clarifying! If this issue persists after T300215 is resolved, please let me know.

I think that removing the "changes recovered" dialogue will be fine. Perhaps also changing the wording of "click to reload" (maybe "load new comments"?), as (for me) "reload" implies the Ctrl+R type, in which changes are usually lost.

The two suggestions you offered above are helpful...I've noted them in Phabricator here. Thank you! PPelberg (WMF) (talk) 22:30, 21 February 2022 (UTC)

No problem, @PPelberg (WMF)! Tol (talk | contribs) @ 05:11, 22 February 2022 (UTC)

AECP feedback: Valereee

1. Nothing was so surprising that as an experienced user I wouldn't figure it out. I could see a newer user (one who hasn't yet figured out how we thread) being very confused by having some new comments appear below their proposed addition. I'm not sure that's really fixable, though?
2. Very visible but not distracting notice. Again this is going to be unalarming for experienced users but newer users...maybe offer something like "copy comment to clipboard and reload page instead?" or something?
3. Defintely found it confusing to not have the new comments highlighted.
4. I'm thinking this should be a definite opt-in. Newer users are less likely to face the embarrassment that's been discussed, I think, so the upsides might not be outweighed by the things I've mentioned. Valereee (talk) 10:34, 15 February 2022 (UTC)

1. This might be fixable, but it would depend on where the newer comments are supposed to end up.
2. Do you think that would be more reassuring?
3. I agree with you.
4. Just make it a user preference has some limitations, but I think your idea should be considered. Thinking about enwiki, though, I wonder how often new users might realistically encounter an edit conflict. Perhaps only at Teahouse or ANI? Whatamidoing (WMF) (talk) 21:30, 28 February 2022 (UTC)

Re: 'copy comment to clipboard and reload instead' would solve issues with 1. being afraid that your comment will disappear and 2. surprise at the reload, so yeah, I think it might be more reassuring. But I don't think it's a big deal. It's only an issue the first time you use that tool.

Yes, newer users probably encounter edit conflicts very seldom unless they're jumping into discussions they shouldn't be in. :) And when they do encounter one, they aren't as likely to be embarrassed because they probably don't yet understand that there'd be any cause for embarrassment. :) So maybe it doesn't matter much. Valereee (talk) 14:34, 1 March 2022 (UTC)

I added that idea to phab:T250295#7770810. (I didn't ping you because I assume that Phabricator is not your usual haunt, but feel free to subscribe to the ticket or add additional information if you want to.) Whatamidoing (WMF) (talk) 20:28, 11 March 2022 (UTC)

<pre> tag breaks

Known limitation; see Help:DiscussionTools#Reply Tool.

I had to reply with a <pre> block and it breaked completely. It's nice to see that the reply tool supports multi-line reply, but apparently it doesn't take <pre> tags into account when replying in an indented comment, adding indenting markup (::) inside the <pre> tags.

See this edit for an example. Ciencia Al Poder (talk) 09:19, 17 February 2022 (UTC)

This is a known limitation, see Help:DiscussionTools#Reply Tool. Tacsipacsi (talk) 14:46, 17 February 2022 (UTC)

Reply tool beta didn't do what I expected

I clicked the [ Reply ] link on a discussion at an en-wiki Talk page, and it added my comment with no indentation, and without notifying the user I was replying to. To me, "Reply" means one thing, and "Add comment" would mean something different. When I see "Reply" as a link on a comment, I think right away of the Reply template at en-wiki (which also exists on numerous other language wikipedias with the same spelling); I also expect a reply to be indented properly (extra credit: offer me the option to add an Outdent template if already indented greater than <configurable number of tab stops>). The tool did neither. I think some consideration should be given to the word "reply", or else there should be a tooltip for desktop users telling them what to expect, and what their responsibility is wrt 1) indentation, 2) notification, and 3) signature (yes/no). Thanks, Mathglot (talk) 22:42, 2 March 2022 (UTC)

@Mathglot, the only edit of yours that I can find on English Wikipedia using the Reply tool is this one. It looks like the tool added your comment with the proper indentation, and you used Template:Re to notify the user you replied to (WikiCleanerMan). Is this the comment you are referring to, or is there another one that I didn't see? Tol (talk | contribs) @ 23:09, 2 March 2022 (UTC)

That's the one, and I added the "Reply" template upon review, when I noticed in Preview mode that the user notification wasn't automatically added. From my way of thinking, "The 'Reply' did not Reply to Tol." As for the indentation, I didn't notice that problem until I saved the comment, and then followed up with this edit fixing the indentation, and remarking upon the issue. I'm faced with the same problem right now regarding indentation, as I don't know whether I should add a colon in front of this reply to you or not. Arguing in favor of adding a colon: the blue border box I see is aligned flush left and the left border lines up vertically with the left edge of your message. Arguing against: the word "That's" initiating my reply appears indented about half a tab stop wrt to your message (the 'T' of "That's" sits under the 'e' of the hyperlinked 'Reply" prompt between your message and mine, as well as under the '@' in the first character of your message. This holds for both Visual and Source edit modes.) Mathglot (talk) 23:52, 2 March 2022 (UTC)

This talk page uses Structured Discussions (Flow), which is entirely different from the reply tool; there are generally no indents with Flow. For the Reply Tool, you can mention another user by entering "@" (a box will pop up with suggested usernames). I'd also like to clarify that you replied to WikiCleanerMan's comment "Mathglot, be bold...", correct? Tol (talk | contribs) @ 00:46, 3 March 2022 (UTC)

Okay, then I'm probably confused between the two tools, and maybe this isn't an issue, I'm not sure any more. Mathglot (talk) 22:50, 4 March 2022 (UTC)

Mathglot, the location of the reply suggests that you clicked the [reply] button for the first comment in the section (The "Unused source banner template" comment, not the "Mathglot, be bold" one). Whatamidoing (WMF) (talk) 04:16, 3 March 2022 (UTC)

Ability to outdent

Tracked in Phabricator
Task T265750

Hello! So recently, I often reply to comments and then it starts to get too deep. When this happens I end up having to go into the source editor and add the outdent template to the start of my reply (possibly with the parameter with the number of colons, depending on how deep it got). Maybe this could be integrated into the reply tool, with a button allowing you to outdent your reply, optionally with the parameter of the number of colons. I don't have a mockup of how I think this would look like (i'm not an artist and never intend on becoming one) so hopefully I'm able to get my point across like this. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:22, 8 March 2022 (UTC)

Auto-outdent-template seems a reasonably uncontroversion automation. When it gets too deep, the reply tool could automatically insert an outdent template. We'd just need to decide on the wrap threshold. HLHJ (talk) 23:34, 6 August 2022 (UTC)

I always outdent once posts exceed eight indentations deep. Eight indentations, in my experience, is the maximum indentation level where comments are still fairly easy to read on mobile. Bowler the Carmine (talk) 23:11, 20 November 2022 (UTC)

+1 for outdent feature too. —MarcoAurelio (talk) 12:55, 26 February 2023 (UTC)

In addition to the need for an outdent feature, using the outdent template used at English Wikipedia appears to break the ability to use the "Reply" feature. Firefangledfeathers (talk) 04:21, 1 March 2023 (UTC)

A [ reply ] isn't always warranted or needed

One example would be closing statements. We see the [ reply ] tool after requested move closing statements. Just not sure about this tool. It's so easy to right click the header and reply that I doubt I'll ever use this tool. Just old-fashioned I guess. P.I. Ellsworth , ed. ^put'r there 19:37, 10 March 2022 (UTC)

This is basically what phab:T295553 requests, so it’s on the way. Tacsipacsi (talk) 00:02, 11 March 2022 (UTC)

Thank you, Tacsipacsi! Now I wonder why this wasn't anticipated and fixed before the [ reply ] link was launched. Ah well. P.I. Ellsworth , ed. ^put'r there 01:47, 11 March 2022 (UTC)

Feedback -- using the Reply tool.

Sample session over three days: An editor has asked for help on an article, to which I constructed replies, over several days. Then I attempted to ping that editor, but I am not sure my reply got through; we have not had much of a conversation. It feels one-sided. The tool is not too intrusive, but if it gets difficult, I can work around the tool, if need be. For the time being, I am working within the tool. For example, I'm not sure what title of my contribution is going to show up as. The topic header (title) seems a bit more intuitive on the Article Talk page. The Browse topics widget works, except for the current topic, I think. I don't see my current topic in the list. I am going to Add topic (to see what happens to the list) --Ancheta Wis (talk) 01:41, 14 March 2022 (UTC)

I see now that my contribution is LIFO (last in, first out in the Browse topics widget) --Ancheta Wis (talk) 01:44, 14 March 2022 (UTC)

The system we're using on this page is Flow, which uses top-posting. Also, you don't have to sign your posts in Flow, since it auto-signs for you.

The editor you were talking to has made no edits since starting that section. The ping in this edit should have been sent, but it appears that the editor hasn't been on wiki since then. The ping should be there when the editor returns to the wikis. Whatamidoing (WMF) (talk) 17:40, 16 March 2022 (UTC)

Changed mind

How do you make the reply tool go away if you have changed your mind about using it? For example, on https://en.wikipedia.org/wiki/User_talk:Ripomobo11#Do_you_need_help? I was trying to type a reply to Ripomobo11's comment. I wanted to show him how to use a citation template to cite a source. I started my comment using the reply tool, but it wasn't giving me as many options as the source editor does. I decided it would be easier to type my comment in the normal source editor, so I copied what I had written and then tried to edit the page directly. However the reply tool kept coming back and telling me my changes were automatically recovered. Finally I opened the source editor in a new tab, but when I saved my changes, up popped the reply tool telling me my changes were automatically recovered again. I had to use another new tab to check to see if my changes made in the source editor took or not (they did).

So, if one changes their mind about using the reply tool for a particular edit, how do they make it go away? ONUnicorn (talk) 16:12, 16 March 2022 (UTC)

There's a red "Cancel" button next to the big blue "Reply" button. Click that (and confirm), and it will forget everything you typed. Pressing Escape is the same as clicking the "Cancel" button. Whatamidoing (WMF) (talk) 17:10, 16 March 2022 (UTC)

(It looks like that editor is mobile-only. I don't know if you've tried it, but the mobile editing environment is quite different in many respects.) Whatamidoing (WMF) (talk) 17:12, 16 March 2022 (UTC)

Expected it to add text that ensures notifying the user

When I hit the reply button I expected it to insert the `@username` of the previous user for me. But that didn't happen. AdithyaKL (talk) 09:22, 18 March 2022 (UTC)

@AdithyaKL My experience is that you simply type the '@' symbol, and you get a drop-down of likely names in that thread that you can select from. Obviously, a complete newcomer might not appreciate that, but in many other circumstances one needs to be able to choose which specific user one is replying to. So I assume this is an intentional design. A 'prompt' might be nice to help such a newcomer to understand that, though. Nick Moyes (talk) 10:02, 18 March 2022 (UTC)

@Nick Moyes yes that works. But a good default should serve most cases no ? AdithyaKL (talk) 20:53, 19 March 2022 (UTC)

Is there a reason to assume that the comment where the Reply link is clicked is not the comment that the user intends to reply to? 151.132.206.250 (talk) 15:43, 24 March 2022 (UTC)

I also expected it to ping the user I was responding to, given that this functionality is present on my user talk page and it would be pointless for me to post a reply there that didn't ping the user. Perhaps the interface should step in and suggest adding a ping, when someone is about to post an unpinged response to their own talk page? Belbury (talk) 22:41, 24 March 2022 (UTC)

Is there a reason to assume that the comment where the Reply link is clicked is not the comment that the user intends to reply to?

It may be, in case there is no one specific comment the user intends to reply to, e.g. in village pump discussions, where one often just generally comments on the topic. Tacsipacsi (talk) 23:34, 24 March 2022 (UTC)

If the Talk pages project/Notifications feature proves popular, then editors might not want to ping as often. ("Why did you ping me? I was already following that section via the [subscribe] button!") Also, at some wikis, the convention is to split the discussion across User_talk: pages. I post on your page, you reply on my page, and I post my reply back on your page. In that case, pinging isn't used. Whatamidoing (WMF) (talk) 18:52, 11 April 2022 (UTC)

Since I am replying directly to a thread, I also expected it to ping the person to which I was replying to and not having to do it manually. OhanaUnited^{Talk page} 03:53, 5 May 2022 (UTC)

Please provide a way of previewing edit summaries

Tracked in Phabricator
Task T274434

Edit summaries are not always straightforward! They may contain piped links or numeric HTML entities. When I make a change to complex code involving links, I sometimes try to reproduce my change to the wikitext in the edit summary by inserting a zero-width space between two consecutive instances of the square bracket ([) so that they do not actually create a link. I need a way of checking that I’ve done it right. Anyhow, as errors in published edit summaries cannot be corrected, I always have previewed my edit summaries before publishing. Peter M. Brown (talk) 22:31, 20 March 2022 (UTC)

"Advanced" button does that I guess ~ AdithyaKL (talk) 07:10, 21 March 2022 (UTC)

Not in any way that I can see. "Advanced" allows me to formulate the edit summary but not to preview it. Peter M. Brown (talk) 14:31, 21 March 2022 (UTC)

No, it’s not currently possible. See the Phabricator ticket I linked above about Whatamidoing (WMF)’s request (you may want to create a Phabricator account using your Wikimedia account and subscribe to the task to be alerted when the developers start working on it). Tacsipacsi (talk) 19:04, 21 March 2022 (UTC)

As a workaround, if you're in the wikitext source mode, you could paste your edit summary into the main editing box (on a separate line) and see what the live preview says. Then remove it from your comment before you post.

I don't know if this request will get implemented this year. Whatamidoing (WMF) (talk) 19:01, 22 March 2022 (UTC)

There are differences in how wikitext works in summaries and in the reply text itself (e.g. templates are not expanded, no bold, italic etc. markup, C-style /* comments */ create section links, and so on), so this workaround provides only an approximation. Tacsipacsi (talk) 12:43, 31 March 2022 (UTC)

True. Whatamidoing (WMF) (talk) 17:56, 4 April 2022 (UTC)

Feedback. Pasting in the reply tool results in a double paste

I was looking for how to provide feedback in the reply tool. I found my way here by clicking on the “reply” blue link in the edit summary. It’s unclear how to give feedback, but I think directions are to use this talk page.

when I reply, and paste a wikilink, on saving, the pasted wikilink is duplicated in front of my signature. I think it is 100% repreatable. —~ SmokeyJoe (talk) 08:25, 31 March 2022 (UTC)

What is this place? SmokeyJoe (talk) 08:25, 31 March 2022 (UTC)

Would you please point to a demonstration of this problem, e.g. a link to the comment or diff? Matěj Suchánek (talk) 10:13, 4 April 2022 (UTC)

SmokeyJoe, this page is using Flow. It has some advantages and some disadvantages. You don't need to type your signature here. You can edit previous comments in the ••• menu.

I'd love to have a diff of this problem. Whatamidoing (WMF) (talk) 18:53, 11 April 2022 (UTC)

Encourage edit summary

Tracked in Phabricator
Task T261908

Please can the edit summary input box be revealed by default? Many of us would like to provide a more helpful ES than "Reply", if only we were prompted to do so. Certes (talk) 12:40, 8 April 2022 (UTC)

Thanks to your comment User:Certes, it appears the WMF has installed the ability to add an edit summary. Ottawahitech (talk) 13:51, 13 May 2022 (UTC)

If you open the "Advanced" menu, which contains the edit summary input, it will be revealed for future replies. Matma Rex (talk) 16:07, 8 April 2022 (UTC)

Yes, I saw that, and it's a useful feature once discovered. Perhaps the menu should be open automatically for everyone. Certes (talk) 19:51, 8 April 2022 (UTC)

I actually came here to suggest that. Sometimes an edit summary of "reply" is fine, but at least 60% of the time it would be helpful to leave more than that. ONUnicorn (talk) 20:44, 22 April 2022 (UTC)

I was also going to suggest this. If the text is short enough, it should be put into the edit summary.

Longer texts may be included by being truncated, but if at least short replies were put into the edit summary field, that would make it more useful. Anerisys (talk) 00:54, 30 April 2022 (UTC)

Yes, we could go further and suggest text for an edit summary. But the simple first step I was suggesting is to replicate the functionality we have in the current workflow (replying by editing the page/section), of revealing the edit summary box to everyone who hasn't consciously opted out of it. I think that just requires setting a different default value for a flag. Certes (talk) 06:47, 30 April 2022 (UTC)

I talked to the product manager about putting short replies into the edit summary automagically, but there is a significant downside: if someone posts something and thinks better of it later, then getting that original text off the wiki requires help from an admin or oversighter, because edit summaries can't be edited after posting.

I looked through talk-page edit summaries for non-Reply-tool replies at the English Wikipedia a couple of months ago (filtering out script-assisted edits, new sections, etc.). Half the editors didn't add an edit summary at all, or only used a generic edit summary like "re". There are a few editors who are strongly committed to good edit summaries on talk pages, but most of us don't use it even when it's easy to do so. Whatamidoing (WMF) (talk) 04:19, 5 May 2022 (UTC)

I understand the reasons for not automatically copying content into the edit summary. However, making the box visible by default (with "Reply" or a blank summary) should help the 50% of editors who use talk edit summaries, without unduly inconveniencing the others, and doesn't seem like a difficult change. Certes (talk) 17:47, 13 May 2022 (UTC)

@Certes EDIT SUMMARIES have been available at en-wikiquote for a-wiki-while now, and so has a REPLY-PREVIEW.

The edit summaries are used by some of the few who use the REPLY tool there, so you can see them in action. HTH Ottawahitech (talk) 14:28, 20 May 2022 (UTC)

I think the issue is that, when using the reply tool, the default setting hides the edit summary field under small text that says "advanced" with a little arrow that you have to click on in order to find the edit summary field. This is not intuitive. What we are requesting is that the edit summary field be displayed by default, rather than hidden by default as it currently is. ONUnicorn (talk) 15:02, 20 May 2022 (UTC)

Yes, thank you ONUnicorn, that is exactly what we are requesting. Some editors would also like the edit summary autofilled with a copy of the reply, but that is a separate request and need not hold up the simple change of default from hidden to displayed. Certes (talk) 15:08, 20 May 2022 (UTC)

@User:Certes, Just curious: when you say "we" who do you mean? Me and you or others as well? I also do not understand what you mean when you say "change of default from hidden to displayed." Thanks in advance, Ottawahitech (talk) 15:20, 21 May 2022 (UTC)

By "change of default from hidden to displayed", I meant that an editor who does not deliberately change their preferences (including a logged-out or IP editor) would be offered a box for an edit summary, rather than first having to discover that the button marked "Advanced" reveals it.

By "we" I did mean you and I, but perhaps I'm the only person who wants to see the edit summary box or receive any clue that it exists. I suspect that 99% of affected editors will never find this talk page on a different wiki. Certes (talk) 15:26, 21 May 2022 (UTC)

When I type, I see text move below

Tracked in Phabricator
Task T313988

Hello, the reply-tool is impossible to use. When I type my reply, then the window below the writing field shows a preview of the reply I am writing, updated immediately. That means when I type there is always something moving on the page. That is extremely annoying. I want to turn of the preview, but I don't see how. Ziko (talk) 15:02, 17 April 2022 (UTC)

Have you tried switching to the visual mode? Whatamidoing (WMF) (talk) 17:31, 18 April 2022 (UTC)

Ah! Thank you very much! Ziko (talk) 17:35, 18 April 2022 (UTC)

Most of the "key sequences" that you use in typing wikitext work in the visual mode. For example, if you type [[ to start a link, it will open the link box. If you type <ref, it will offer a reference dialog. Press Escape to get these nowiki'd and back to regular typing.

IMO the only real shortcoming for the visual mode is that you can't add templates (directly). This is because some templates (e.g., infoboxes) can make a real mess right now. Whatamidoing (WMF) (talk) 18:37, 18 April 2022 (UTC)

Seems to be mostly in line with the Visual Editor. Thanks again! Ziko (talk) 18:38, 18 April 2022 (UTC)

I have this issue too, but I can't (and wouldn't want to) use the visual mode. Can there please be a way to switch to a preview button instead? It should at least respect my browser's prefers-reduced-motion settings and not have things moving around on the page when I'm typing. Nikki (talk) 10:40, 14 July 2022 (UTC)

Nikki, the devs tell me that there's a "unique CSS class" for the live preview area, which means that if you post a request at WP:VPT (or I can, if you prefer), someone ought to be able to throw together a script that would completely hide the live preview for you.

You wouldn't get a preview button this way, but I suppose you could switch to the visual mode to check links. It won't let you switch to visual mode if you have any templates in the message, so this would be an imperfect solution. Maybe it'd be better for you overall than the default, though? Whatamidoing (WMF) (talk) 17:37, 1 August 2022 (UTC)

A persistant-state radiobutton next to the grey word "Preview", which froze it or turned it off, would be welcome. Am I right to take it that the browser is actually sending ~every keystroke to the WMF servers, which run it thru Parsoid, and send back the result? HLHJ (talk) 19:06, 1 August 2022 (UTC)

> " ~every keystroke to the WMF servers"

There is a debounce/throttling, so only every second (or something, I don't know the exact timeframe), will it send the input and ask the servers for a new preview. —TheDJ (Not WMF) (talk • contribs) 10:00, 3 August 2022 (UTC)

I don't know how it handles live preview. Extension:DiscussionTools/How it works has some technical information, but I didn't see anything about the preview system. Whatamidoing (WMF) (talk) 22:47, 2 August 2022 (UTC)

If I were on an expensive pay-per-bandwidth system, which many poor people around the world are, the minimal bandwidth of just sending the text when completed might be useful. Bandwidth also has a carbon footprint. I don't know what the bandwidth-use difference of this system is in practice, given real-world levels of pausing, deleting, rewriting, typo fixing etc.. It may be quite small, and an acceptable cost for measured benefits. But an estimate of the CO2 cost of this change globally, and the financial cost to the editor in a worse-case scenario, would be really good to have.

I'd guess that the majority of my talkpage edits contain not markup beyond the tildes of my signature, and I really don't need a preview for them. I do want a preview sometimes (I miss it on these talk pages, though the "thank" link is nice), but I'm happy to have preview only on-demand. HLHJ (talk) 14:10, 3 August 2022 (UTC)

Metered connections is a good point. I’m not sure if it causes significant extra CO₂ emission, but if one has to pay for every byte, it may very much make a difference for them. The class-based approach I proposed only hides the preview, doesn’t prevent it from being generated, so the costs are still there. Looks like we really need a real solution (I consider this class-based thing rather a quick workaround/hack than a real solution). Tacsipacsi (talk) 11:38, 4 August 2022 (UTC)

I'd be surprised if that matters much. You'll probably need about fifty to a hundred previews like that before you are close to even a single time of opening the edit page itself. —TheDJ (Not WMF) (talk • contribs) 15:16, 4 August 2022 (UTC)

Okay, so let's say I make an edit of a few hundred characters, a typical length, and get a update of the preview once a word or so, which is what seems to be happening; English words average about 5 characters. So that would mean 50-100 previews is about what I get per 250- to 500-character edit, meaning that that, if the data for loading the edit page is about that of 50-100 previews, I double my bandwith consumption for each edit. On the carbon-emissions issue, what matters is really the aggregate effect across all users, which may be fairly negligable, but we must have the A/B data to tell by now.

If you are on a 56 kbaud connection (a single voice channel, still very common), loading even simple webpages can be noticably slow. Images are really slow. In my experience, on lousy connections, if you send data in discrete bursts of low-bandwidth stuff like text, ideally with the transmission manually prompted, it works; stuff that requires fairly continuous 2-way transmission often just doesn't work. This may be due to latency and intermittent signal degredation and lousy error handling and all sorts of other issues beyond straight bandwidth; I don't know. If you turn off the loading of Javascript from en.wikipedia.org, the "reply" links and functionality vanish, and on a slow or expensive connection you'd probably do that. If you had the technical knowledge.

Even on a very fast fiberoptic connection, turning off scripts makes a large proportion of webpages load noticably faster, with no detriment to content; it breaks a small proportion of webpages, and they are mostly pretty useless ones, too (and you can just turn scripts back on for the few that need scripts). And it blocks a lot of tracking and bad ads and privacy/security risks, and slashes your bandwidth requirements and browsing carbon footprint. Nonetheless, I doubt most people in the developed world use a browser firewall to block loading of useless-to-the-user content. So I'm not expecting that most new internet users in the developing world will do that. Also, most browser firewalls can't be installed on smartphones, the favoured way to access the internet in the developing world.

Live-updating text as annoying movement in one's peripheral vision is a completely separate issue, and one some people won't care about. I'd prefer not to have it.

I'd also like the edit summary above the preview, as when it's below, I'm more likely to forget to fill it out. HLHJ (talk) 22:48, 6 August 2022 (UTC)

> On the carbon-emissions issue, what matters is really the aggregate effect across all users, which may be fairly negligible, but we must have the A/B data to tell by now.

While people definitely look at reducing bandwidth usage, cutting features for the sole purpose of reducing carbon is not a good long term strategy. Technology moves fast and it is way more efficient to squash bytes on the 'big stuff' (new types of compression, http2 and http3 usage etc) than choosing to remove functionality that most people expect. Because the best CO2 usage is no website at all (and no computer at home to browse a website for that matter).

> If you are on a 56 kbaud connection

Opening Wikipedia as an editor on a 56kbaud modem should take about 2 minutes to load a single page (1,5 MB). I have trouble believing editors actually use 56kbaud connections to edit. If they are, this won't be many users, and they are already used to having lots of problems with websites.

> This may be due to latency and intermittent signal degredation and lousy error handling

It is. And where found, it should definitely be fixed. But even if it fails, that doesn't necessarily create much impact in this particular case. You'd just get 1 fewer preview.

> Even on a very fast fiberoptic connection, turning off scripts makes a large proportion of webpages load noticably faster

It does, but that doesn't require anything from the website to be achieved.

> turning off scripts makes a large proportion of webpages load noticeably faster, with no detriment to content;

"no detriment to content", seems to me like a very personal judgement call that many people would heavily disagree with.

> I'd also like the edit summary above the preview, as when it's below, I'm more likely to forget to fill it out.

With the current position it is just as close to the submit button, which you will always need to progress right ?

I'm not convinced personally. The only thing I would say is that it might be wise to have a mode, which detects that rendering takes very long (more than a second say) and then automatically disable auto previewing. I'm pretty sure that we have that functionality in another component (the new realtime preview ?). I think that would make sense, especially for ppl on unstable or very slow connections. That will work automatically, which seems much more user friendly to me. —TheDJ (Not WMF) (talk • contribs) 14:19, 8 August 2022 (UTC)

I entirely agree that it's worth emitting carbon for useful features. I don't actually want to cut a feature; I just want to be able to click on the word "Preview" and toggle it on and off. I've maybe been insufficiently clear; I personally find continuous preview actively undesirable, though I can see it has utility, especially for new editors learning markup. I don't want it removed; I would favour adding a side-by-side live preview option to article-space editing, though I don't think I would use it very often myself.

I've read Wikipedia over a voice-width channel. It is indeed patience-demanding (not loading images helps), and I don't think I've ever tried to edit that way; at any rate I doubt I've edited much. Mostly, I've used uneditable offline copies: Kiwix and, before that, CDs. I'd agree that we probably have few editors on very slow or expensive connections, and they would have low expectations for functionality from most websites. I did read of an offline Wikipedia editing project that sneakernetted Wikipedia contributions and manually merged them, so there must be some unmet demand; half the world's population is offline, and a lot of offline people read Wikipedia content. I've taken an interest in asynchronous editors, but nothing has emerged; I should perhaps write a simple one for this usecase.

For reading text-based content, which is a lot of what I do online, I personally find that turning off scripts and occasionally enabling (usually only first-party ones) on an as-needed basis mostly removes the ads and tracking. The most frequent problem is accordions that don't default to unfolded if there is no Javascript (on Wikipedia, the big thing I like about scripts is popup citations). You're quite right that most people don't use the internet that way, and probably many wouldn't want to even if they knew how. But this is by-the-by; my poorly-made point was that new internet users will use the default settings. A default that disables the preview on slow connections sounds great, and very user-friendly for that use case, much more so than my toggle suggestion.

...but it doesn't solve my/Nikki's problem, that we don't like the live preview and want to turn it off. HLHJ (talk) 02:14, 9 August 2022 (UTC)

My two cents

I wanted to post a reply to a comment on the Talk page for Black Ice, and decided to click on the Reply link instead of edit. I found it very easy to use, and simpler than having to preview my post one or more times. JDZeff (talk) 21:58, 22 April 2022 (UTC)

We (the Editing Team), are glad to hear you're finding the tool useful ^ _ ^

If you are curious, there are a collection of other new tools we're developing for talk pages which you can review here. You can also turn on all of these features by enabling the "Discussion tools" setting in Beta Features. PPelberg (WMF) (talk) 22:53, 22 April 2022 (UTC)

Better default edit summary

Instead of simply 'Reply', it would be a lot better if the default edit summary was 'Replying to User:Example'. ~ 156.34.233.97 (talk) 21:03, 2 May 2022 (UTC)

That's just an unnecessary ping in my opinion. Are you saying that the user would have to be pinged or only mentioned without a ping in the edit summary? --Ferien (talk) 21:08, 2 May 2022 (UTC)

The reply need not cause a ping, but including the user name in the summary is a good idea — GhostInTheMachine ^{talk to me} 21:12, 2 May 2022 (UTC)

I can't see why that's an especially good thing: I'd never do that in a manual edit summary. It seems somewhat unnecessary to me - you'd look at the actual edit if you wanted to know who someone was replying to, surely. Nick Moyes (talk) 22:39, 2 May 2022 (UTC)

@GhostInTheMachine, how would that longer edit summary help you? What if (as happens frequently in larger discussions, I use the [reply] button to "reply to" someone, but it's really just a general comment, and not actually a response to that person's comment? Whatamidoing (WMF) (talk) 04:13, 5 May 2022 (UTC)

If you don't want the reply some someone specific, you can easily delete 'ing to User:Example' from 'Replying to User:Example' to give 'Reply'. The mention is an improvement, and when I reply to someone, I expect them to be pinged, rather than to manually add @Username: in my reply. Headbomb (talk) 21:54, 18 May 2022 (UTC)

See also https://www.mediawiki.org/wiki/Talk%3ATalk%20pages%20project/Replying/2022#h-Add_a_%22reply_to%22_button_next_to_the_section_header-2022-05-18T21%3A57%3A00.000Z which could easily contrast replies to people vs replies to topics. Headbomb (talk) 21:58, 18 May 2022 (UTC)

How would an edit summary of "Reply to Alice" be better for you than "Reply"? Whatamidoing (WMF) (talk) 20:40, 27 May 2022 (UTC)

Yes please. "Reply to Alice" should be the default. "Reply" is better than "Replying" as the space makes a double click simple and the user could easily alter it to "Reply about ABC ..." etc. — GhostInTheMachine ^{talk to me} 21:04, 27 May 2022 (UTC)

@GhostInTheMachine Whilst I might click the Reply button just after Alice's post, I might not be directly responding just to Alice, but to a number of editors in the thread above. If I really needed to be specific, I can always change the edit summary. I feel this is an unnecessary suggestion, sorry. Nick Moyes (talk) 22:00, 27 May 2022 (UTC)

My question is how it would be better. Tell me a story that says something like "If the edit summary is the generic 'Reply', then I will _____ but if it says 'Reply to Alice', I will do this other thing, _____". Or if the story is "I'll do exactly the same thing no matter what the edit summary is, but I'll feel happier", then tell me that, too. Whatamidoing (WMF) (talk) 21:26, 27 May 2022 (UTC)

If the generic summary is "Reply", I will not ping the person I'm replying to. I will then have to look up the username of that person, and type "ing to [[User:Click-and-Drag+CTRL+V]] to go back and fix the less-than-helpful edit summary. This is time intensive.

If the generic summary is "Replying to [[User:Username]], then I don't have to do that. If I desire a generic reply, I can easily delete "to [[User:Username]]", or learn to reply to the header (see other request), instead of replying to a person. 156.34.233.97 (talk) 23:33, 27 May 2022 (UTC)

or you can type '@' ' and you get a dropdown from which to select the names of who you specifically want to reply to, should you feel you do want to ping them. Not a huge amount of difficulty, I'd have thought. Nick Moyes (talk) 17:00, 28 May 2022 (UTC)

@ doesn't bring up anything. Maybe in the visual editor it does, but certainly not in the classic interface. 2607:FEA8:CC6A:B400:9CBF:EBB8:6546:1E09 (talk) 23:56, 28 May 2022 (UTC)

It's working on this page; it's working on en-wiki; it's working on desktop and on laptop. I believe it doesn't work on mobile, and as an IP editor like yourself isn't able to ping anyone, so it probably doesn't work for you if you aren't registered. Have you tried logging in to a non-mobile device and trying it there? Nick Moyes (talk) 09:05, 29 May 2022 (UTC)

This page doesn't have edit summaries. It also uses a weird annoying interface that isn't what's on enwiki. Headbomb (talk) 22:11, 29 May 2022 (UTC)

This page uses Flow, which has advantages and disadvantages. Whatamidoing (WMF) (talk) 22:38, 30 May 2022 (UTC)

It sounds like people don't actually want the edit summary to say "Reply to Alice". Instead, they want Alice to be pinged automatically, and the edit summary is one way to implement that. Is that correct? Whatamidoing (WMF) (talk) 22:40, 30 May 2022 (UTC)

As long as Alice is pinged, I don't particular care how that's implemented. The ES seems the best way to implement it, since it'll show in the edit history and let others know Alice was pinged. But if there's another way, sure. Headbomb (talk) 00:06, 31 May 2022 (UTC)

I believe the devs were saying last year that the ping could be sent automagically, without showing in the edit summary. You'd want a tick box in the "Advanced" drawer, so you could un-tick the person you're nominally replying to (e.g., if your comment were more general), or to tick it if you normally have it turned off.

The next step in that workflow is to figure out whether it's the recipient or the sender whose preferences matter. Could I say "nobody should ping me automatically", and what happens if your settings are "ping everyone I reply to"? Or, as I say, to wonder whether pinging one previous participant for a reply is the right answer at all, if everyone's going to have the [subscribe] button auto-ping them for all comments. Whatamidoing (WMF) (talk) 05:31, 13 June 2022 (UTC)

The pinger should be the one in control 156.34.233.97 (talk) 05:32, 13 June 2022 (UTC)

Of course the pinger should have the final decision, but I find it an interesting idea that the pingee could set the default—some people like to be pinged about replies to them, as they wouldn’t notice it otherwise, others put the pages they comment on on their watchlist anyway and are just annoyed by the extra notifications. The pinger usually doesn’t know in which group the replied-to user belongs, so it was nice if the software knew it. Tacsipacsi (talk) 11:49, 14 June 2022 (UTC)

The pingee can completely reject pings in Special:Preferences#mw-prefsection-echo (from everyone or from named individuals; this prevents certain kinds of harassment), but it's that problem of not know whether I want to be pinged everywhere that could be added. We currently have:

• You can ping me, if you remember to.
• I reject {some/all} pings.

And we could expand this to offer:

• I will always be pinged, even if you don't remember to.
• You can ping me, if you remember to.
• I reject {some/all} pings. Whatamidoing (WMF) (talk) 18:50, 16 June 2022 (UTC)

"Reply to Alice" was the default for reply-link. I got feedback that it wasn't really correct when you were replying to the discussion as a whole, not specifically to that person (see https://en.wikipedia.org/wiki/Special:Permalink/1086806346#Reply_without_ping). Perhaps it should only show "Reply to Alice" if your comment has a ping to Alice at the front. Enterprisey (talk) 19:33, 30 July 2022 (UTC)

Or perhaps "Reply to Alice", so that the edit summary pings her, if you have the "Ping everyone" button clicked. Whatamidoing (WMF) (talk) 22:39, 2 August 2022 (UTC)

Why am I asked a CAPTCHA: after adding my reply?

Why am I asked a CAPTCHA:  after adding my reply?

Cancelling then seems the only way of finishing this activity. 185.143.182.2 (talk) 22:09, 14 May 2022 (UTC)

It looks like there are two issues here:

• Why are you asked a CAPTCHA. Probably because you tried to insert a new external link. This is a necessary inconvenience to prevent automated spam bots. If you create an account, you’ll soon be able to insert new external links without solving CAPTCHAs. (But you don’t have to; you can continue to edit without an account if registration is more inconvenient for you than solving CAPTCHAs every now and then.)
• Why cancelling is the only way out. This may be a bug, could you please explain why you can’t publish your comment? Nothing happens when you press the Reply button? An error message appears? If the latter, what does it say? CAPTCHAs should be supported in the reply tool for a long time. Tacsipacsi (talk) 11:39, 15 May 2022 (UTC)

Add a "reply to" button next to the section header

Instead of replying to someone specific, replying to the header would be good. Adding the comment at the very bottom with the generic summary "Reply to %HEADER" or "Reply". Headbomb (talk) 21:57, 18 May 2022 (UTC)

See also https://www.mediawiki.org/wiki/Talk%3ATalk%20pages%20project/Replying/2022#h-Better_default_edit_summary-2022-05-02T21%3A03%3A00.000Z, where you could contrast a reply to someone with a reply to a topic Headbomb (talk) 21:58, 18 May 2022 (UTC)

Do you expect that comment to be unindented/same level as the original comment? Whatamidoing (WMF) (talk) 06:12, 19 May 2022 (UTC)

I think I'd expect that to be at the same level as a first reply. Maybe same level makes more sense though. Headbomb (talk) 06:54, 19 May 2022 (UTC)

This idea looks interesting. Maybe it would be worth to give it a try. (A/B test?) J. N. Squire (talk) 11:06, 19 May 2022 (UTC)

MediaWiki doesn't handle A/B tests with grace, so at this point, when I hear "A/B test", I begin to think "six-month delay".

This feels related to the "vote" problem. If you have a voting-style discussion (e.g., Help:Sample discussion#Vote for the logo), then you want unindented bullet points. The team's talked about a magic word or other way to signal that a section is voting-style. Whatamidoing (WMF) (talk) 20:45, 27 May 2022 (UTC)

I didn't know they were that slow. Ouch. Good to know. HLHJ (talk) 23:31, 6 August 2022 (UTC)

Conversely, the "reply" link makes it easier to have very long conversations. The longer discussions also make it harder to edit your own comments, or add a comment to the end using the old interface especially if you are on a mobile. The reply link is at the end of every post; the edit link is only in the header at the top of the discussion, not at the bottom (also a problem in articles).

Links at the top and bottom, to reply at the same indent level as the topmost or bottommost post, might make sense. An "edit" link on the end of posts, one that opened the whole section, would also make it easier to correct indentation errors.

I also note I can't use indent level and vertical position independently; I can't reply to a post other than the last one and still add my comment to the end of the discussion.

But this is not really simplicity, and I value simple, uncluttered, easy-maintenance interfaces. HLHJ (talk) 23:31, 6 August 2022 (UTC)

Different styles

Tracked in Phabricator
Task T259865

Could there be a way to set the reply tool to use (*) instead of (:) when the other comments use (*) per w:en:MOS:INDENTMIX which states:

Definitely do not X attempt to use a colon to match the indentation level, since (as mentioned above) it produces three separate lists

IAmChaos (talk) 00:21, 31 May 2022 (UTC)

Please note that the reply tool doesn't produce the incorrect output shown in the example on that page:

Definitely do not N attempt to use a colon to match the indentation level, since (as mentioned above) it produces three separate lists:

* This is one item.
: This is an entirely separate list.
* This is a third list.

…but rather this, which is considered acceptable:

This is also acceptable practice (to suppress the bullet on a reply):

* Support. I like this idea. —User:Example 
*: Question: What do you like about it? —User:Example2
*:: It seems to fit the spirit of Wikipedia. —User:Example

You might still want it to produce different output sometimes, but it is definitely not an accessibility problem.

(Also, sorry about the trouble you had with markup – templates from en.wp are not all available on this wiki, and this is a different discusison software too – we're making the reply tool to replace it ;) ) Matma Rex (talk) 00:42, 31 May 2022 (UTC)

I meant when starting a new reply off the base level. So if someone has a top level

Original topic {reply}
* First person
* Second person
* Third person

and you need to reply to the person whose reply is not indented, but inline with the rest of the people. IAmChaos (talk) 01:16, 31 May 2022 (UTC)

Problem pasting non-Latin-script text

I encountered this issue when trying to paste some Cyrillic text from an online converter tool. Now, I don't really know how the Javascript clipboard API works in detail, but I believe there's a difference between styled and non-styled text, with the former having some formatting information mixed in with the text itself, that the reply box text editor tries to then convert to wikitext.

The specific converter I use sets a style of 'font-family: sans-serif; word-spacing: 120%;' in the <output> tag the converted text is output into. Now, if I give the converter gibberish input that it passes back out as plain-ASCII Latin letters (but in the same <output> tag), I can paste those into the box just fine. However, attempting to paste any Cyrillic text (including spaces) fails, and just moves the cursor to the beginning of the text area. If I remove the styling, by first pasting the output into Notepad and copying it from there, then pasting works.

I know this is a very specific set of circumstances, that most users probably won't face, and honestly I don't expect you to debug and fix it, it's a weird edge case and probably also at least partly a browser bug. (Firefox 100.0.2, btw.) Oatco (talk) 14:58, 19 June 2022 (UTC)

Do you have the same problem if you use a "Paste and Match Style" or "Paste without formatting" option? Whatamidoing (WMF) (talk) 19:07, 24 June 2022 (UTC)

"Paste without formatting" (using Shift-Ctrl-V) pastes the text without a problem (without formatting, of course), while a normal paste (Ctrl-V) has the problem. Oatco (talk) 23:29, 24 June 2022 (UTC)

If you have the same <output> tag, but Latin characters in it, do you get the same problem? VisualEditor only accepts certain kinds of copy/paste content (e.g., you can't copy/paste photos). Perhaps the <output> tag is rejected. Whatamidoing (WMF) (talk) 22:49, 2 August 2022 (UTC)

Replying on archived pages?

T249293 : Prevent reply links from showing on certain pages

On Archived pages we use magic words like __NOEDITSECTION__ to prevent unwanted editing, however an "[reply]" still appeares in those archives.

Maybe this "[reply]" should be turned of with this or a new magic word. Wurgl (talk) 06:14, 27 June 2022 (UTC)

Good point! Nick Moyes (talk) 08:52, 27 June 2022 (UTC)

We can't re-use the same magic word, as there are pages that allow replying but not adding new sections, but a new magic word has been proposed in T249293. Matma Rex (talk) 19:11, 27 June 2022 (UTC)

Number localization

T312033: Number localization in reply tool new comment warning

On bnwiki, we use Bengali numeral. Number shown in this screenshot (this appear when someone reply before you while you're writing a reply) needs to be localized. Vector-2022's language button also had this problem and they fixed it. Please fix it for reply tool also. Thank you. আফতাবুজ্জামান (talk) 23:11, 2 July 2022 (UTC)

Thanks for the bug report, I filed it as T312033 and we'll fix it soon. Matma Rex (talk) 15:55, 4 July 2022 (UTC)

This should be fixed. Whatamidoing (WMF) (talk) 22:43, 2 August 2022 (UTC)

Edit notices

Tracked in Phabricator
Task T263710

It has come to my attention that edit notices aren't displayed when using this tool. See for example en:talk:goofy. This should probably be rectified. ONUnicorn (talk) 19:02, 12 July 2022 (UTC)

Technically, they are shown when you create a new topic, but not when you make a reply. —TheDJ (Not WMF) (talk • contribs) 08:48, 13 July 2022 (UTC)

As far as I remember, not displaying them in the reply tool was an intentional decision—the reply tool should be as lightweight as possible (e.g. to see the comment you’re replying to: if there’s a two-screens-high edit notice between the two, it’s difficult to react to the points in the comment), and many edit notices are irrelevant: “sign your posts”-type things are unnecessary and confusing, and would cause raw tildes appearing in replies by people using the visual mode; while others like Talk:Goofy’s one are relevant only when starting new topics—edit requests shouldn’t usually appear in existing sections anyway.

That being said, I would like notices about staying on point and civil in controversial topics or about Arbitration Committee decisions to appear, but unfortunately it’s impossible to programmatically tell necessary and (in this context) useless edit notices apart. Tacsipacsi (talk) 15:14, 14 July 2022 (UTC)

Most of the reply links don't work

Hi, most of the reply links don't work on ckbwiki. For example, please go to this talk page and if you click/tap on the reply links, you see an error message, which contains these two messages (MediaWiki:Discussiontools-error-comment-disappeared and MediaWiki:Discussiontools-error-comment-disappeared-reload]), saying that the statement could not be found, but the statements exist. Thanks! Aram (talk) 22:15, 16 July 2022 (UTC)

Thanks for the report, I filed T313188. This is related to a change that took effect last Tuesday, it seems to be a bug that only affects some languages. We'll get it fixed on Monday. Matma Rex (talk) 15:19, 17 July 2022 (UTC)

This should be fixed. Aram, if it is still broken, please let us know! Whatamidoing (WMF) (talk) 22:43, 2 August 2022 (UTC)

@Whatamidoing (WMF) I think the problem is gone. Thank you to everyone who took care of this problem and fixed it. Aram (talk) 11:01, 3 August 2022 (UTC)

Parts of the text are erased or scrambled

I tried this feature several times. It works great for short texts, but when writing a long reply parts of the texts sometimes disappear completely or get scrambled. This can he very frustrating. I use the feature in the Hebrew Wikipedia. Thanks and cheers, Ithamar 85.250.228.85 17:33, 18 July 2022 (UTC)

We have this as well. Annea72 (talk) 21:28, 24 October 2022 (UTC)

Are you using the "visual" mode, or the wikitext "source" mode? Whatamidoing (WMF) (talk) 22:44, 2 August 2022 (UTC)

I got this today in "source" mode (without special chars installed, vanilla installation, writign in plain English). When I tried to paste the title of a WP article for a wkilink, it pasted the formatted title, complete with font and underline, and then the editing field messily and stopped being editable, with deteriorating function. I tried switching to visual mode and back; I couldn't switch. It also looked as if it had lost some of my text, which I copy-pasted back from the unchanged preview. But then the text shifted and it was pasted in the wrong place... In the end I saved it and edited the comment in a seperate edit.

I have previously had intermittent problems copy-pasting into the reply field from other tabs, including from the HTML and from the URL bar. Since I do this all the time, it's very noticable. I paste selections with middle-mouse-button clicks and CTRL-C CTRL-V, and both would not-work simultaneously.

I also often copy-paste from earlier posts to the talk page. I'd like to convert such pasted text to wikisource without prompting when I'm using the source editor; the delay is long even without the pop-up. The most common think I copy-[aste is a username of someone I"m replying to; I've noticed that I have to include a non-marked-up character before their wikilinked username (i.e. " WhatamIdoing") in order to get the option of pasting the linked name instead of plain text. This one is reliably reproducible. HLHJ (talk) 20:26, 27 August 2022 (UTC)

Does this problem seem to appear after copying and pasting? See phab:T319090 for some links to previous bug reports. Also, do you have the GoogleTrans gadget installed? Do you have this problem in safemode? Whatamidoing (WMF) (talk) 01:53, 1 October 2022 (UTC)

Sorry for the slow response, and that apallingly ill-proofread post of mine. It does appear after copying and pasting, it does sound similar to a lot of those bug reports, and if it happens again I'll try to reduce it to something like the solid bug report at phab:T302147. I did nto have GoogleTrans installed; I may have had the "Content Translation" beta feature enabled. I will try it with safemode if I see the problem again. HLHJ (talk) 23:47, 11 October 2022 (UTC)

This happened to me again yesterday. I was copying and pasting names from other websites. The devs said that if I can catch it again, the thing to do is to open the "Web console" and send them the error messages (feel free to e-mail me; sometimes they contain URLs or other information that you'd rather keep private). In Chrome, it looks like you go to View > Developer > JavaScript Console; in Firefox, it's Tools > Browser Tools > Browser Console.

Pbsouthwood, this tip might help you track down that bug, too. Whatamidoing (WMF) (talk) 18:23, 11 October 2022 (UTC)

Where do I find "Tools"? Pbsouthwood (talk) 06:25, 12 October 2022 (UTC)

It’s in the menu bar, which I think is always visible on macOS, but usually not on other operating systems. Pressing Alt or F10 should reveal it. (If your Firefox is English, pressing Alt+T directly opens the Tools menu; other languages may have other hotkeys. However, Alt and F10 are as far as I know language-independent.) Tacsipacsi (talk) 20:47, 12 October 2022 (UTC)

Something similar just happened to me: this edit just now. I didn't copy/paste; I just typed in "Yep; that's it!" in source mode and it spat out "p; that's it!e". The preview also had the mangled text, but I only noticed after I pressed Ctrl+Enter. Tol (talk | contribs) @ 12:30, 20 October 2022 (UTC)

How to turn off a tool on a specific page?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi! Is there any way to disable the tool on the page? For example, on this: w:ru:Википедия:Выборы_арбитров/Лето_2022/Голосование/Голоса. Iniquity (talk) 13:59, 30 July 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Unable to reply

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Unable to reply here: https://bn.wiktionary.org/wiki/ব্যবহারকারী_আলাপ:আফতাবুজ্জামান . How can i fix it? আফতাবুজ্জামান (talk) 19:43, 9 August 2022 (UTC)

Hi, the page had some mistakes in the wikitext that prevented the reply tool from working.

I fixed it in this edit: [1]

You can find some guidance about these issues at Help:Lint errors/fostered. Matma Rex (talk) 20:20, 9 August 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Header with stats

I think the new added "stats" header [Latest comment: för 12 år sedan| 2 comments| 2 people in discussion] disturbs the reading of discussions: It creates an extra grap between header and first actual topic, and it is meta-information that I cant see is normally relevant in an normal discussion flow. It could be added to the "advanced" flipout tab after clicking "reply" instead, as a quick link to the interested of such stats. Or as a advanced setting, but not "forced". LittleGun (talk) 07:10, 18 August 2022 (UTC)

hi @LittleGun – I appreciate you coming here to share the feedback you have about the new section heading styling (we're calling them "Topic Containers") that became available as a Beta Feature at more wikis yesterday.

Two questions in response to the feedback you shared above:

1. What – if anything – do you find helpful about the "stats" that appear beneath level 2 section headings?
2. Were you aware, before me asking this question, that you are able to disable the "new added stats header" by turning off the "Show discussion activity" setting that appears within Special:Preferences? PPelberg (WMF) (talk) 18:51, 18 August 2022 (UTC)
3. Not much. I go to a discussion page to a) start a discussion, then I scroll through the old ones first to see if it the subject have been handled. That gives me a good view of how many have discussed and when, b) to check out a discussion I see happening or are pinged to, then I want to check the topics comments before answer and get a good view before I answer. If I want to check latest and so on I go to the history tab. Maybe, some isolated time, the topic container could alert me that someone have added a comment in an older thread. That is it, and it is not very often (if ever) I need to know that but it would save me the time to go to history tab. At all other times the unwanted information creates a space separating the heading of the topic from the topic.
4. No, I did not know that. However, I want to work with and help beginners. To me it is important not to mess with the skins settings too much, because then I will not know their experience or understand their questions. So it is all good that these settings can be adapted for each individual, and I know most settings can either through settings or just to ask people that know about scripts. But it is very important the default skin is as adapted to beginners as possible and is as basic as possible. And they have enough trouble finding edit buttons and editing tools, and is not helped by this meta data in such prominent position, at their first steps replying in a discussion. LittleGun (talk) 19:54, 18 August 2022 (UTC)

@LittleGun thank you for following up with me! Responses below. Please let me know if anything I've said here brings new ideas/questions to mind.

Not much. I go to a discussion page to a) start a discussion, then I scroll...

I appreciate you describing the typical workflow you follow when arriving at a talk page. As someone who is practiced with using history pages, and talk pages more broadly, it sounds like the additional information Topic Containers show is going to be more distracting than it is helpful to you for now.

But it is very important the default skin is as adapted to beginners as possible and is as basic as possible. And they have enough trouble finding edit buttons and editing tools, and is not helped by this meta data in such prominent position, at their first steps replying in a discussion.

+1! It sounds like we are aligned in thinking it's important that beginners be able to arrive on a talk page and immediately recognize it as a place where they can communicate with other people and, as you said, find the buttons/tools necessary for them to communicate.

In fact, the objectives it sounds like we share are precisely what led us to include this "metadata" in the first place. The thinking here being that people who are new would intuitively recognize the sections on talk pages as discussions if there was information within the interface that reinforced this idea (e.g. the number of people participating in the discussion, the number of comments, the date the last comment was published, etc.).

I too was mindful of the potential for this additional information to distract people who are new. Although, the usability tests we ran proved otherwise: the beginners who participated in the usability tests both understood the metadata and helped them recognize talk pages as places to communicate.

At all other times the unwanted information creates a space separating the heading of the topic from the topic.

Oh, and so you're aware, we are going to decrease the amount of whitespace between the section heading and the topic. This work is happening in T314449.

I realize what you're saying above is slightly different from the issue the ticket I linked to is meant to address and I thought you would still value knowing that we're still iterating on the overall design :) PPelberg (WMF) (talk) 00:24, 23 August 2022 (UTC)

Очень полезная функция. @Лариса94 Лариса94 (talk) 10:30, 19 August 2022 (UTC)

Ok. Also considering newcomers? Do you mind if you have to turn it on instead of it being default?

I can personally live with it, I can understand some very experienced users like it. For beginners it is uneccessary information, causing distraction. The Vector 2022 aim to hide as much as possible, in the reply feature after clicking reply most things are hidden under menues and cryptic icons. Here we should do the opposite. What is the justification? LittleGun (talk) 12:19, 19 August 2022 (UTC)

Новичкам сложно в начале. Потом разбираются и привыкают. "По умолчанию" позволяет экономить время - не нужно искать нужную строку и считать звёздочки (*), чтобы ответить как положено - "лесенкой". Все просто, как грабли:)) нажимаешь - отвечаешь, @Лариса94 Лариса94 (talk) 17:11, 19 August 2022 (UTC)

Yes, we are all beginners in the behinning. All things can be default to save time (even if its something only done once). So, what is the justification to prioritize an advanced feature creating a disturbing effect? LittleGun (talk) 04:45, 20 August 2022 (UTC)

In my opinion, there is no "disturbing effect" in the new function.@Лариса94 Лариса94 (talk) 13:40, 24 August 2022 (UTC)

This is great to hear, @Лариса94!

We intentionally made it possible for people to disable the feature thinking there will be people who favor the existing experience and people who will favor the changes the new feature brings about. PPelberg (WMF) (talk) 15:50, 24 August 2022 (UTC)

One possibility for this feature is that it will help beginners. Specifically, seeing "Latest comment: för 12 år sedan | 2 comments | 2 people in discussion" could help them think "This is a place for comments and discussion. This is not the place to paste my new article". Whatamidoing (WMF) (talk) 00:24, 26 August 2022 (UTC)

ok. But, as mentioned before, other improvement projects (vector 2022 or this tool) did not previously want to overinform. So why do this feature so prominent for such advanced information.. If it is to clarify for beginners, a more explicit note would be better than cryptic metadata.

I understand we all have different behaviour and needs, but I was really hoping for a better justification and more thought out reason prior to roll out I will however get used to having the information there and maybe found it useful some time, but I have not yet. LittleGun (talk) 05:49, 26 August 2022 (UTC)

It usually takes about two weeks to get used to a big change. I hope you'll give it a fair trial, but if you decide that you hate it, then the devs tell me that it could be easily hidden with a .css user script. Whatamidoing (WMF) (talk) 01:06, 27 August 2022 (UTC)

I dont hate it. I will learn to live with it. I cannot see the use. I do not understand why this advanced meta data summary shall be so prominent, when the scope in other changes is to hide as much as possible.

I think you fail to justify this. So I think the CSS should work the other way.

I will not remove it. I dont want to customize too much. Then I wont understand what new users or otger fellow user describe. LittleGun (talk) 07:40, 27 August 2022 (UTC)

Find User Broken

Just FYI, phab:T316219 is open about the user-fill component being broken right now. Xaosflux (talk) 13:21, 25 August 2022 (UTC)

Thank you for the ping, @Xaosflux. This issue should be fixed today. PPelberg (WMF) (talk) 16:31, 25 August 2022 (UTC)

Thanks link

Tracked in Phabricator
Task T249893

Could there be a thanks link next to the reply link, as on this page? New editors often have trouble finding the thanks facility, and even for experienced editors, it's slower to go to the history page and thank. This would save time visiting pages and reading messages which are purely thanks. HLHJ (talk) 20:29, 27 August 2022 (UTC)

Thank you! Leonaardog (talk) 20:31, 27 August 2022 (UTC)

It’s already being (not very actively) worked on, see phab:T249893. Tacsipacsi (talk) 23:01, 27 August 2022 (UTC)

In jawp, I will appreciate Thanks button very much personally . As in my view and focusing on ja community.

• it will be a wise tool which will calm down experienced editors when they don't be replied by Junior editors: not like SNS, you don't know if your advice is perceived or not.
• Another gap a Junior/less than 500 edit history not aware yet of, or often times long term editors tend to forget: they say it's a protocol to reply thanks, but that is not very popular among beginner editors to thank ASAP you read and understand an advice;
• elders (in age) think it's applicable anywhere in your life on/off wiki.

Are we not ignoring another unwritten but shared knowledge among senior/long-term editors, if limited to particular language community(ies). And IMHO I wish you need not to learn wiki-manner (local) after many wounds by getting scolded/ridiculed you are bad-mannered. /:

Thus, I wish we have thanks button as one remedy, among many, for enhancing friendlier and welcoming exchange of help. (with thanks to (@HLHJ's input, updated as my view could be bound with local culture.~~~~~) Cheers, Omotecho (talk) 00:35, 28 August 2022 (UTC)

Long long ago (on English Wikipedia, before 2013), there was no thanks button. If you wanted to thank someone, you had to type a message. Also there were dinosaurs (they went extinct before the 2020s). I do not think it is impolite to not use the thanks tool. But saying thank-you is polite, and the thanks tool makes it faster for the thanker and thankee both. HLHJ (talk) 00:58, 28 August 2022 (UTC)

misspelling

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This is not a bug. Please help me to find it.

Please see this. It says ১ ঘন্টা আগে (1 hour ago). Here spelling for ঘন্টা (hour) is wrong, should be ঘণ্টা Q: Where does it coming from? I was unable to locate it on translatewiki.net. আফতাবুজ্জামান (talk) 22:42, 29 August 2022 (UTC)

It is provided by the CLDR extension using data from the Common Locale Data Repository. Translatewiki has some instructions for contributing to those translations at https://translatewiki.net/wiki/CLDR. Matma Rex (talk) 23:01, 29 August 2022 (UTC)

Thanks. I will file a request. Last time i filed a request, it took a year to fix. I also asked/emailed Nemo bis for an account but never got any reply :/ আফতাবুজ্জামান (talk) 23:25, 29 August 2022 (UTC)

Filed a request: https://unicode-org.atlassian.net/browse/CLDR-15975

However it will probably take months to fix, can you provide any workaround? আফতাবুজ্জামান (talk) 22:30, 30 August 2022 (UTC)

I think we can. I filed https://phabricator.wikimedia.org/T316843 about it, so it doesn't get forgotten. Matma Rex (talk) 00:04, 1 September 2022 (UTC)

Can you double-check that the spelling here is correct on every line? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/cldr/+/828662/1/LocalNames/LocalNamesBn.php Matma Rex (talk) 00:32, 1 September 2022 (UTC)

Thank you. Yes, all the spelling are correct. আফতাবুজ্জামান (talk) 01:58, 1 September 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Nach links rücken

Tracked in Phabricator
Task T265750

Manche Diskussionen sind so lang, dass die Antworttexte immer weiter nach rechts rücken. Das kann dann unübersichtich werden. Es wäre gut, wenn es die Möglichkeit gäbe, wieder ganz links mit dem Schreiben der Antwort zu beginnen. Rita2008 (talk) 13:50, 20 September 2022 (UTC)

Reply on diff listing

This feature works on a diff listing. After replying on a diff listing, can/should it reload the page itself and not just the diff listing? I think I would prefer to see the page, but perhaps others would prefer to continue to see the diff listing so they can make further replies. MB (talk) 18:38, 22 September 2022 (UTC)

What is a diff listing ? —TheDJ (Not WMF) (talk • contribs) 08:38, 24 September 2022 (UTC)

A comparison of two versions of a page showing the differences. For example, https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Disambiguation&oldid=prev&diff=1112103034&diffmode=source MB (talk) 00:03, 25 September 2022 (UTC)

So you mean just a diff. Presumable a diff, with preview mode enabled ? You are making a reply on that page, and then it refreshes the diff, but not the preview ? Or rather I guess, you see the same diff, with the same preview, and not the later revision that you have just created I guess.

Honestly, I wonder if previews of diffs shouldn't even have reply links... —TheDJ (Not WMF) (talk • contribs) 10:07, 26 September 2022 (UTC)

I'm not sure what you mean by "preview mode enabled". If I open a diff listing (commonly by clicking on (xxx changes) on a watchlist entry, I see the changes that were made to the talk page. The reply tool works on this diff listing and I am able to add to the discussion. I see my new comment on the page. So what I am seeing at this point is not really the diff between the versions listed at the top anymore, it is the diff listing I had been looking at with the new comment appended. If I reload the page with the browser reload, the new comment disappears.

It is convenient to be able to reply on a diff listing. but it can lead to confusion also. Sometimes, I do a browser reload to see if there have been responses to my reply, and of course that doesn't work because the url is set to the diff listing, not the "live page".

Perhaps, as you say, "previews of diffs shouldn't even have reply links" MB (talk) 16:32, 26 September 2022 (UTC)

I'm not sure what you mean by "preview mode enabled".

There’s a setting on Special:Preferences#mw-prefsection-rendering-diffs labeled Don't show page content below diffs. The default is disabled, so most users probably don’t even know about it.

If I reload the page with the browser reload, the new comment disappears. […] Sometimes, I do a browser reload to see if there have been responses to my reply, and of course that doesn't work because the url is set to the diff listing, not the "live page".

It depends on how you open the diff. Most on-wiki diff links contain the revision ID of both the “before” and the “after” revisions, so they indeed don’t contain changes made after the link has been generated. Links in notification emails, however, contain a special diff link that ends with diff=0&oldid=123456 – 123456 is of course a made-up revision ID and is substituted with the actual revision ID of the “before” revision, but 0 is literally a zero, and means “the latest revision at the moment the page is loaded”, so if I press F5, I see my own comment as well as any eventual replies to it. This is probably a workaround for the fact the link is clicked potentially much later than it’s generated (and thus new edits may happen during this time), but it has the side affect that reloads behave differently (which may or may not match the user’s expectations). These are not some black magic, such links could be generated on-wiki as well, for example using gadgets/user scripts. Actually, there’s one on-wiki place where such links are generated (in this case probably for performance reasons): the diff-to-current links on non-diff old revision pages like https://www.mediawiki.org/w/index.php?oldid=123456. (N.B. There are reply links even on this page, although reloading would clearly not work. The links don’t work as these comments have been archived since, but they would if DiscussionTools could find the comments in the latest version.)

Perhaps, as you say, "previews of diffs shouldn't even have reply links"

I’m strongly against removing the links from diffs. As I mentioned above, in some cases there’s no confusion, but even in others having to navigate to another URL to be able to reply makes one of the core values of the reply tool (being able to reply quickly) less true. Maybe there could be a warning within the tool or after posting that informs the user if the issue is really present (i.e. old revisions without diffs and diff views without diff=0). Tacsipacsi (talk) 16:41, 27 September 2022 (UTC)

Special Characters/Symbols like „ & “ are missing: ?

2003:ED:B742:9CC1:69C4:CAD8:D65C:983A (talk) 09:25, 3 October 2022 (UTC)

Frustrating

If I want to edit a section, I just want to edit the section. I do not want the editor to get in the way and decide I am making a reply. I do not want the editor to decide what my summary should be. It breaks my workflow.

And *this* talk gives me hives. I will never use it again. (Also note: I am logged in, but apparently not here…) 208.98.223.22 (talk) 15:32, 7 October 2022 (UTC)

I don't think the 'reply' function is appropriate if all you want to do is simply edit some pre-existing text in a thread, rather than reply to others at an appropriate point. Of course, you still have your original option to "Edit source" - which is still there at the end of the heading for each thread. For many people, simple 'replying' with this tool should be a lot easier than it once was for us 'oldies', and I, for one, find myself using it all the time. Nick Moyes (talk) 19:24, 7 October 2022 (UTC)

Need preview and diff functionality

For some actions, like replying with something that contains uses of templates, we need preview functionality. Yes, the "edit source" is still there, but to the "seldom, but long-time" user, it's not even obvious that there are two buttons - the "edit source" button may even have scrolled out of view. Let us switch to "edit source" mode from the reply mode. 77.190.103.245 (talk) 11:15, 10 October 2022 (UTC)

The reply tool has itself a source mode, which contains a (live) preview. The visual mode doesn’t contain an extra preview, since it’s already WYSIWYG – if you see wiki syntax in visual mode, it will appear that way after saving (it’ll be <nowiki>d). There’s no diff in either mode, but neither do I see a reason for it: the difference will be that your comment will be added, existing parts of the page won’t be modified (unless there’s a bug in the tool). Tacsipacsi (talk) 18:46, 11 October 2022 (UTC)

Auto-converting links to wikilinks

Hi, I'm using the reply-tool for more than a year now (first as a beta feature, now as a global default). Recently I noticed a change which I don't really like:

When inserting a difflink (e.g. [2]) everything works as it used to. But when inserting a regular link to a wiki page (e.g. [3]) the reply tool is automatically converting it to a wiki link (e.g. metawiki:User:Johannnes89) even if I want the link to be displayed the same way as the difflink.

Is there a way to disable (or at least revert) this auto-converting @Whatamidoing (WMF)? The same problem also applies to the „new topic“-tool. Johannnes89 (talk) 18:57, 4 November 2022 (UTC)

You want to add a link (e.g., to your userpage on Meta-Wiki), and you paste in the whole URL. It converts it to a normal internal link. You sometimes want the whole URL instead. Is that correct?

If so, then either switch to the source mode to paste in the URL, or use your computer's "Paste and Match Style" option. That will give you a nowiki'd copy of the URL (like this: https://meta.wikimedia.org/wiki/User:Johannnes89 ). Backspace over the last character, re-type it, and press the space bar. That will turn it back into a working link (like this: https://meta.wikimedia.org/wiki/User:Johannnes89 ). Whatamidoing (WMF) (talk) 23:47, 7 November 2022 (UTC)

Thanks, that's what I want tot do. I'm using the source mode but it's still converting links.

The „paste and match style“-option works. And I figured out another way: Instead of pasting the link directly to the textbox, using the „add link“-button, choosing „external site“ and then pasting the copied link also stops auto converting :) Johannnes89 (talk) 06:40, 8 November 2022 (UTC)

Bullet point replies

I find it difficult to see the boundaries between consecutive comments when there are several at the same indentation level unless each starts with a bullet point. Since the reply tool does not have an option to start my reply with a bullet point (without increasing the indentation level more than necessary), I have stopped using it on the English Wiktionary. ExcarnateSojourner (talk) 00:52, 11 November 2022 (UTC)

@ExcarnateSojourner: Bullets are not meant for that purpose, see en:WP:THREAD. Each comment should end with a signature. Alternatively, please try reading diffs.   — Jeff G. ツ 10:53, 11 November 2022 (UTC)

Each thread ends with a sig, but those aren't as easy to see as an indent or a bullet is. So when there a multiple replies to a single comment, you're scanning along looking for a sig. A bullet is easy to see, and I too would find it helpful if I could add one without changing the indent level. Valereee (talk) 15:05, 11 November 2022 (UTC)

I agree; it's difficult to distinguish parse message threads without some visual separation or other que (such as bullets). ~The-erinaceous-one 2601:647:CC00:15:F90C:8414:7193:83DA (talk) 11:02, 14 November 2022 (UTC)

Indentation completely broken

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This tool does not auto-indent, as expected from a tool to reply to comments on talk pages. I always have to go back and fix my indentation manually, which means that at present this tool confers no benefit over simple source editing. Bowler the Carmine (talk) 16:12, 22 November 2022 (UTC)

It does auto-indent. Can you link to an example comment where it didn't do that? Perhaps you found a bug, or perhaps you were actually using a different tool than the one this page is about. Matma Rex (talk) 16:34, 22 November 2022 (UTC)

It seems to only do this on mobile: https://en.wikipedia.org/w/index.php?title=Talk:Colorado_Springs_nightclub_shooting&diff=prev&oldid=1123120279 Bowler the Carmine (talk) 16:39, 22 November 2022 (UTC)

Thanks for the example. The mobile talk page interface you used for this edit is a different tool, part of MobileFrontend. We're currently working to replace it with this tool, and I hope you'll find it does a much better job.

There is no way to enable it permanently yet, but you can try out its behavior on that page by clicking this link: https://en.m.wikipedia.org/wiki/Talk:Colorado_Springs_nightclub_shooting?dtenable=1

You can follow the progress of this work at Talk pages project/Mobile. Matma Rex (talk) 16:47, 22 November 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Enabling subscribe action in Wikipedia namespace

Hi. How can one enable the discussion tools in Wikipedia:Something? Is this something community can do alone?

The page Help:DiscussionTools/Why can't I reply to this comment? says that this might be namespace specific, but doesn't provide details.

Specifically I would want to add a subscribe button on pl:Wikipedia:Poczekalnia. Nux (talk) 19:32, 4 December 2022 (UTC)

The subscribe action is limited to level 2. I think that limit is ridiculous.   — Jeff G. ツ 19:45, 4 December 2022 (UTC)

It's already very difficult to find and keep track of level 2 sections. Smaller heading levels have many more irregularities, complexities and are much more often wrapped in all sort of custom HTML. Maybe at some point it might be possible, but it's probably not a good idea to further complicate this already complex problem at this point in time. Small steps will guarantee much more predictable and stable results for the communities. —TheDJ (Not WMF) (talk • contribs) 12:03, 5 December 2022 (UTC)

Even on m:srg?   — Jeff G. ツ 13:07, 5 December 2022 (UTC)

@Jeff G. on plwiki we will change heading levels up a notch. I think you can do the same. Probably some bots and scripts would need to change but that is mostly just a problem of organizing migration. Nux (talk) 14:38, 5 December 2022 (UTC)

So it would work if we would be able to change header levels? I think that might be doable in our case (would have to ask community).

Still, would be nice if that would be configurable somehow (per prefix maybe?). Nux (talk) 20:48, 4 December 2022 (UTC)

I don't see any discussions on the Polish page that you linked. Whatamidoing (WMF) (talk) 20:01, 5 December 2022 (UTC)

It is on subpages like this one: pl:Wikipedia:Poczekalnia/kwestie techniczne. There are 3 like that. And each topic is on a subpage... So this will require some work. Nux (talk) 20:08, 5 December 2022 (UTC)

This tool closes up talk page tables if they haven't been closed

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

See this edit. Aaron Liu (talk) 15:18, 10 December 2022 (UTC)

Repairing some types of broken wikitext, including closing tables, is expected behavior. Whatamidoing (WMF) (talk) 18:27, 10 December 2022 (UTC)

Is there a way to disable this on certain pages? If it closes up that talk page table then new topics will no longer automatically show up inside it Aaron Liu (talk) 18:44, 10 December 2022 (UTC)

If you put the formatting in a template (or on a transcluded subpage), the tool will refuse to work. By the way, you shouldn’t use tables for formatting purposes, as such usage breaks semantic markup, thus confusing e.g. screenreader users; please use two nested <div>s instead. (Using <div>s may or may not disable autoclosing, I’m not sure. Using a template/subpage will disable the reply tool for sure.) Tacsipacsi (talk) 21:57, 10 December 2022 (UTC)

Just to close the thread: it looks like <div>s work in practice: [4]. Matma Rex (talk) 18:39, 11 December 2022 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Error posting replies

On simple:Wikipedia:Requests for checkuser, if you try to reply to a request, you'll get an error saying "Your comment could not be published to the most recent version of the page. To see the latest changes, copy your drafted comment and then use your browser to reload the page." --Ferien (talk) 22:31, 30 December 2022 (UTC)

Ferien: That happens to me sometimes, too. I used w:User:BrandonXLF/QuickEdit.js on that page instead, and that worked.   — Jeff G. ツ 10:49, 31 December 2022 (UTC)

See Help:DiscussionTools/Why can't I reply to this comment? (I'd start with the "accidental complex tranclusion" point.) Whatamidoing (WMF) (talk) 04:11, 10 January 2023 (UTC)

@Whatamidoing (WMF): That error message is not found on that page, and that section is not complexly transcluded, it's a simple level 3 wikitext section. Please see this edit.   — Jeff G. ツ 10:30, 10 January 2023 (UTC)