This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I guess the tool could see the '*' replies as a '*'-list inside the nominator's post. Is this an accepted limitation of the Reply Tool that I should keep in mind? It could use the signatures in the '*'-list to decide that they're separate comments, but maybe that would be unreliable?
Support for "voting-style" discussions is a known limitation. The devs have been thinking about a new magic word that could be used to identify when this behavior is wanted (e.g., in RFCs) and when it's not (e.g., most of the time). Whatamidoing (WMF) (talk) 19:56, 28 January 2022 (UTC)
Location of subscribe link
Once upon a time, the section edit link was right justified, but then it was moved to immediately following the section title for... user experience reasons I cannot remember and I can't find the discussion on the matter. Does anyone remember the motivation for the change? I'm just wondering if it should be taken into account regarding the placement of the subscribe link. isaacl (talk) 22:54, 13 December 2021 (UTC)
I remember the change, but I don't remember the reason for it. It might have been a way to simplify the technical side.
Jess (the designer) is looking at rearranging several things, and that might be one of them. I'm calling this mw:Talk pages project/Usability, and hopefully we'll get a few screenshots/mockups posted in the next few days. One of the ideas is to add more information/features (e.g., a permalink to the section) in a ⋮kebab menu. If people primarily use the [reply] buttons, and if automatic topic subscriptions turns out to be a good thing, then even the [edit source] button could be "hidden" in a drop-down menu. Whatamidoing (WMF) (talk) 20:16, 15 December 2021 (UTC)
Honestly, if a right-justified link is considered OK now, I'd rather have the edit link there and the subscribe link next to the title or somewhere else. But... it would probably be too much churn to the user experience at this point. isaacl (talk) 21:55, 1 February 2022 (UTC)
Hi y'all – as we prepare to offer the Reply Tool as an on-by-default feature at en.wiki on desktop, the Editing Team thought you would value knowing about the work we'll continue doing to improve the Reply Tool and to, more broadly, make it easier for people to use talk pages in productive ways.
With the above said, below is a non-exhaustive list of the upcoming work we have planned. We would valuing knowing if anything here prompts thoughts, questions, etc.
Upcoming Talk Page Work
Reply Tool: most immediately, the Editing Team is working on an enhancement to the Reply Tool that will alert you, in real time, when new comment(s) are posted in a discussion you are drafting a comment within. Follow the development and/or share your feedback about it.
Hi! I created a script (here) for toggling all the subscribe buttons on a page, because I find the subscribe tool notifications more useful than the watchlist. Enjoy! ― Qwerfjkltalk 11:45, 19 November 2021 (UTC)
What a neat idea, @Qwerfjkl! Once I install the script, what should I expect to see when I visit a talk page at en.wiki? A button/link of some sort that enables me to subscribe to all of the discussions present on the page?
I ask the above having tried both installation "Method 2" and "Method 3" that you described here[1][2] tho I'm still not noticing any changes when I visit a talk page like this one... PPelberg (WMF) (talk) 19:39, 28 January 2022 (UTC)
@PPelberg (WMF): Hi! You should see a 'subscribe all' link under the 'Tools' section on the left-hand navigation bar (at least on Vector). ― Qwerfjkltalk 19:44, 28 January 2022 (UTC)
Got it! I see the Subscribe all link now. However, when I click it, I'm not seeing:
A) The [ subscribe ] affordances on the page turn to the [ unsubscribe ] state
Thank you for your help troubleshooting this! PPelberg (WMF) (talk) 00:57, 29 January 2022 (UTC)
Strange. I get a bunch of notifications saying You have (un)subscribed. Do you get any errors in your console log? (ctrl+⇧ Shift+j on Windows) ― Qwerfjkltalk 09:01, 29 January 2022 (UTC)
Thank you for continuing to look into this, @Qwerfjkl. Here is what I'm seeing in my browser's (Chrome) console after: 1) Loading this page and clicking the 2) Subscribe all link. Do you see anything that could help explain the issue I'm experiencing? Also, if there is any other information I can help provide to make debugging this easier, please let me know!
It used to work on my user talk page. Now it doesn't. Did I mess something up? The [reply] buttons are there but clicking them does nothing. Usedtobecool☎️ 17:15, 21 February 2022 (UTC)
Not just you. I'm having the same issue on your talk page (possibly just your talk page specifically since I'm using the reply tool to reply to you here). ― Blaze WolfTalkBlaze Wolf#6545 18:25, 21 February 2022 (UTC)
Works for me — xaosfluxTalk 00:18, 22 February 2022 (UTC)
The reply tool currently fails on pages that contain video or audio embeds (such as your talk page in this section) if you have the "New video player" beta feature enabled. This is a known issue and it should be fixed soon: T301427. Matma Rextalk 00:31, 22 February 2022 (UTC)
@Matma Rex: thanks for the note, FYI: It also fails for me if trying to reply to that section, even without that beta player. And once it fails, it fails for the rest of the page until a reload. — xaosfluxTalk 10:08, 22 February 2022 (UTC)
phab:T302296 opened for the non-beta version of this failing. — xaosfluxTalk 14:56, 22 February 2022 (UTC)
Watchlist notice opened for final gamma test. As this has been advertised we are assuming no blocking tasks unless new issues are reported here or at phab. — xaosfluxTalk 15:53, 21 February 2022 (UTC)
@Xaosflux: Apologies if this isn't an appropriate question here but, why is it called the "Gamma test" instead of "beta test"? ― Blaze WolfTalkBlaze Wolf#6545 16:02, 21 February 2022 (UTC)
@Blaze Wolf: I suspect because since it's been an opt-in functionality for some time, that was the alpha test. This is more like a brief third tranche just short of global opt-out Nosebagbear (talk) 16:17, 21 February 2022 (UTC)
Because the beta test already completed - but we pushed back that we wanted more testing, so have gone for a third test wave - all of the functional requirements are expected to be met already from the beta test, this is really a last chance to raise blocking bugs before deployment. — xaosfluxTalk 16:35, 21 February 2022 (UTC)
@Blaze Wolf Once it's been fully rolled out and everyone's got it, we're going to call it Omicron! Nick Moyes (talk) 15:02, 22 February 2022 (UTC)
*Ba dum tss* ― Blaze WolfTalkBlaze Wolf#6545 15:10, 22 February 2022 (UTC)
There is a function that I would like to be in the reply tool that hasn't been added yet. That is that the reply tool doesn't see any stylization after you add your signature and thinks that you didn't add your signature if you add anything, resulting in a double signature, one with the styling and one without. For example, if I were to make my comment small, if I add </small> after my signature to make my entire comment small, it thinks I didn't add my signature and inserts it again. ― Blaze WolfTalkBlaze Wolf#6545 16:47, 21 February 2022 (UTC)
@Blaze Wolf: I've opened phab:T302257 on this. I don't think it should be considered a blocking bug, but should be looked in to. — xaosfluxTalk 00:25, 22 February 2022 (UTC)
How do you sign up for the Gamma Test? I'm interested. J390 (talk) 01:30, 22 February 2022 (UTC)
@J390: Preferences -> Beta Features -> Select the one called "Discussion Tools" -> Save. This includes more than just the reply tool from what I've been told but you don't have to use the other features. ― Blaze WolfTalkBlaze Wolf#6545 01:36, 22 February 2022 (UTC)
@Isaacl: are you getting this with only reply tool enabled, or only if all of the DT experiments are enabled? — xaosfluxTalk 14:58, 22 February 2022 (UTC)
@Isaacl: ok thanks - don't see that as a "reply tool rollout" blocker, yet. — xaosfluxTalk 16:18, 22 February 2022 (UTC)
I guess it can affect discussions on Wikipedia namespace pages? References aren't used often there, but it does happen. Given that a fix has been merged and I think is currently awaiting or undergoing quality assurance testing (I'm not sure how to read the Phabricator task status), personally I suggest waiting until the fix is released. isaacl (talk) 16:25, 22 February 2022 (UTC)
This patch is up for QA review. My guess is that it's likely to be fixed on wiki by next WP:THURSDAY. Whatamidoing (WMF) (talk) 22:13, 22 February 2022 (UTC)
Reply tool configuration
Hello, it would be very useful if we were able to change some parts of the reply tool such as the pinging function. For example, I find it useful to have a dropdown, however I prefer using {{re}} instead of @[[User:<user>]]. Additionally, would it be possible to add a preload to the reply tool like Enterprisey's reply tool? Thank you! ―sportzpikachumy talkcontribs 01:48, 22 February 2022 (UTC)
Where would you want this "preload" to come from? Also note: the "reply function" doesn't work at all in "source" mode, which could be nice. These do seem more like "feature requests" though, so shouldn't block roll outs. — xaosfluxTalk 10:14, 22 February 2022 (UTC)
@Xaosflux, if you get this ping, then the "Mention a user" button and keyboard shortcut works in source mode. (Do you have the toolbar turned off?) Whatamidoing (WMF) (talk) 22:18, 22 February 2022 (UTC)
@Whatamidoing (WMF) - ahh ok, I had to also opt-in to Enable editing tools in source mode in preferences; thanks! — xaosfluxTalk 22:42, 22 February 2022 (UTC)
@Sportzpikachu the @USER<user> option is much more sustainable, local templates can come and go. — xaosfluxTalk 22:43, 22 February 2022 (UTC)
As of now, the reply tool automatically adds a signature to posts, but this can cause issues when using subst templates that add a signature already. An example is Template:RMassist. Maybe there could be a way to toggle it on and off? ᴢxᴄᴠʙɴᴍ (ᴛ) 10:09, 23 February 2022 (UTC)
I think this is similar to the one below, personally I think the best solution is to "not autosign" if signature code is present in the text already. — xaosfluxTalk 13:21, 23 February 2022 (UTC)
see phab:T268558 (my last comment following the merge) for what I think is the bigger issue. — xaosfluxTalk 13:26, 23 February 2022 (UTC)
Another approach would be to standardize the templates on never auto-signing. Then editors wouldn't have to look up which template has which behavior each time. Whatamidoing (WMF) (talk) 20:09, 23 February 2022 (UTC)
If you are suggesting we make a blacklist of autosign templates, per project, that sounds computationally expensive. — xaosfluxTalk 20:26, 23 February 2022 (UTC)
I have a huge problem with this - no edit summaries
I think that editors should be able to leave edit summaries when replying. The tool prevents me from doing this. Doug Wellertalk 12:07, 22 December 2021 (UTC)
If you click "advanced" below the edit box you will see a place to enter an edit summary. Whether it should be hidden by default is a different matter. Thryduulf (talk) 13:53, 22 December 2021 (UTC)
Thanks. I'm told it's not automatically available in order not to distract new users. IMHO we should want them to see it and get the idea they should be using it. Doug Wellertalk 14:32, 22 December 2021 (UTC)
I completely agree. Edit summaries should not be seen as a distraction, but as an integral part of leaving a comment. Thryduulf (talk) 15:16, 22 December 2021 (UTC)
See my discussion here.[1]. Are people with no experience with watchlists or even the actual Wikipedia encyclopedias making decisions about this? Doug Wellertalk 17:05, 22 December 2021 (UTC)
I wasn't previously aware of this practice. I don't think edit summaries are relevant to leaving a comment. What should be written besides "reply"? Update: I read the linked discussion at mw:Talk:Talk pages project and am not convinced that we need to encourage such edit summaries. It also doesn't seem to be a widespread community practice, although there is a subset of editors doing it (from a random survey of discussion pages). If I need to figure out what a comment on my watchlist is, I use User:Writ Keeper/Scripts/inlineDiffDocs to expand the diff inline.On the other hand: EDITSUMCITE does seem to mention talk pages (which surprised me), and I can see how watchlists and contribs lists would be more useful. Overall, though, I don't think the convenience is worth it. Enterprisey (talk!) 03:28, 25 December 2021 (UTC)
Agreed. There's just a small set of users who use edit summaries for talk page comments, so the field should not be made visible by default. Maybe there could be an opt-in feature that makes it visible by default, as in reply-link and CD. – SD0001 (talk) 06:57, 25 December 2021 (UTC)
I don't understand where you are getting this "small set of users" nonsense from? Nearly every editor here uses an edit summary on nearly every page - just look at the page history of any page - even Enterprisey is using edit summaries! Thryduulf (talk) 10:18, 25 December 2021 (UTC)
That's not true for most users while adding new talk page comments (which is the only thing reply tool supports). In any case, I don't think an edit summary like this is helpful. – SD0001 (talk) 12:06, 25 December 2021 (UTC)
They are very useful when you want to be sure that a point you are making in the discussion is recorded somehow in the history. This can be particularly useful when discussing issues involving sanction areas, NPOV/RS etc areas, vandalism and more. Sure, I often use just C for comment if I don't think it merits a description in the edit summary. And of course there's watchlists, where edit summaries on discussion pages can be very useful. Doug Wellertalk 11:11, 25 December 2021 (UTC)
As a thread gets longer, the tool keeps indenting until it's all squeeze to the right -I haven't yet seen what happens if people continue, does it have a version of "od"? Doug Wellertalk 15:41, 29 December 2021 (UTC)
There's no "outdent" built-in (it's been requested, but not designed or built yet). However, if you reply to an earlier comment, it will align your comment with the one you're replying to, so you can work around this limitation. (This depends upon the discussion complying with WP:LISTGAP, so sometimes it won't.) Whatamidoing (WMF) (talk) 19:24, 4 January 2022 (UTC)
On the open question of whether custom edit summaries should be encouraged more, I think it's always useful to see what experienced editors have actually been doing. Here's a sample of the latest behavior in the article Talk: namespace only:
::I googled "Sisak children concentration camp" and this page was the first hit. ~~~~
[no edit summary used]
no.
Reply [used Reply tool]
I eliminated any edit that created a new section using &action=edit§ion=new, because the 2010 wikitext editor doesn't permit custom edit summaries in that case (the Reply tool's counterpart, the New Discssion tool, does), and all of the edits that used scripts (e.g., Twinkle, AFCH, various WikiProject rating scripts), and edits that didn't involve a comment. I attempted to include only those edits that could have been made with the Reply tool, but it was a manual process, so I probably misclassified a few. All of these edits were made by editors with >500 edits (WP:EXTCONFIRMED).
As you can see, about half of the edits didn't use any edit summary at all, or used only general edit summaries, like "cmt" or "more comments". Based on the ::formatting, two of them seem to have copied and pasted their comment into the edit summary.
Overall, the existing behavior does not seem to me to be very strong evidence that experienced editors consider custom edit summaries to be a critical component of participating in a discussion on a talk page.
For comparison, I did a separate search, looking specifically at edits made with the Reply tool. This search showed 100% edit summaries (because it defaults to "Reply"), of which almost 7% were custom edit summaries. It looked like a handful of editors use the custom edit summary option regularly, and others occasionally. Whatamidoing (WMF) (talk) 20:21, 4 January 2022 (UTC)
The edit summary option setting is sticky. If you click the "Advanced" link then it reveals the edit summary. Once you've done this, future replies will show the edit summary by default.
My view is that the interface should not use the word "Advanced" for this. This suggests that there's a bundle of advanced options whereas it just seems to conceal the edit summary. The option should be more clearly labelled as Edit summary (hide) or Edit summary (show).
Most of the time, a default edit summary of "reply to <user>" will be fine. The evidence presented by Whatamidoing (WMF) shows that this default would be superior to current manual summaries as they are usually blank.
Agreed. The word "advanced" is confusing. It makes much more sense for the label to clearly state what it does. I'd also prefer it if the word "reply" wasn't there when I click it - what's the point? Doug Wellertalk 10:00, 23 February 2022 (UTC)
"More options"? Enterprisey (talk!) 11:02, 23 February 2022 (UTC)
I was suggesting "More options" as a label for that part, assuming the developers will someday want to put more stuff in there than just the edit summary. Enterprisey (talk!) 08:56, 24 February 2022 (UTC)
I think if there aren't more options, that would be confusing. Doug Wellertalk 08:57, 24 February 2022 (UTC)
I actually think that "Reply" is a very reasonable default edit summary for a reply on a talk page. I would only need to alter that if I needed to somehow belabour or highlight a point, ping someone silently, or make my particular post stand out in View History. In all other situations - especially for new users - it is what it says on the tin: a Reply. I do, however, think Edit summary (hide)/(show) is an excellent proposal. Nick Moyes (talk) 11:46, 23 February 2022 (UTC)
Reply is fine for a default if you don't want to add your own. But if there is any way to not have it show when you click on whatever it will say when we want to actually make an edit summary, it would be nice. Doug Wellertalk 12:03, 23 February 2022 (UTC)
I don't mind it autofilling with reply, but I would like this to default appear for all. We want to try to inculate leaving an edit summary into new editors as quickly as possible, and having it hidden as an "advanced option" (which it's not) is counter to that. Nosebagbear (talk) 15:17, 23 February 2022 (UTC)
So as you can see I'm using the tool here, right? Now, let's say I want to have the citation needed template. {{Citation needed}} ... but it's nowiki-ed. There's a disclaimer saying "You are using the visual editor - wikitext does not work here. To switch to source editing at any time without losing your changes, click on the switch button." Problem is, when I switch to the source... say there's a template with several parameters. What are the short names for those parameters? It'll be a hassle for me to google the template documentation and switch back and forth. The current visualeditor, when I type the template code, it automatically leads me to a box with all the parameters. I'd suggest having that feature. GeraldWL 14:11, 28 February 2022 (UTC)
Hi, @Gerald Waldo Luis. This is blocked on an expansion of MediaWiki's wikitext code. Basically, to make templates "safe" (also tables and some other things), you'd have to wrap the whole comment in a new wikitext code. This could easily be done automatically by DiscussionTools, but it would look different in the diffs. It would also solve several other problems (see https://www.mediawiki.org/w/index.php?oldid=4731762#Motivation, especially the broken list in the middle of the table). Whatamidoing (WMF) (talk) 21:03, 28 February 2022 (UTC)
Partial signatures
Hello,
I occasionally use three-tilde signatures (name-only), when the full signature would be either duplicative or obtrusive for the usecase.
However, it seems that if you do a three tilde signature, the reply tool will still try to add the full signature. I'll demonstrate below this. It would be best if the auto-sign disabled if any form of signature generated by tildes was used. Nosebagbear (talk) 11:14, 23 February 2022 (UTC)
see phab:T268558 (my last comment following the merge) for what I think is the bigger issue. — xaosfluxTalk 13:26, 23 February 2022 (UTC)
To do this, the tool would have to be able to reliably differentiate between adding a link to your username for some other reason ("Just go to WhatamIdoing and scroll down about halfway to read about that and which") and a partial signature, which is difficult. When you don't want a quick, simple, standard, pre-indented auto-signing tool, then just use the [edit source] button instead of the [reply] button. Whatamidoing (WMF) (talk) 20:13, 23 February 2022 (UTC)
@Whatamidoing (WMF) wouldn't something like "if the input text has the ~~~, ~~~~, or ~~~~~ magic words in it, don't autosign"? The tool seems to be fine knowing if these are present, as the live preview output shows them. — xaosfluxTalk 20:24, 23 February 2022 (UTC)
That would work, as would a simple checkbox saying "don't auto-sign this comment". If you want to create a link to your userpage, just write [[user:Thryduulf|]], yes it's a few keystrokes more, but it doesn't confuse software. Thryduulf (talk) 00:38, 24 February 2022 (UTC)
Perhaps some "suppress autosign" button would be more than enough? — xaosfluxTalk 00:50, 24 February 2022 (UTC)
I would prefer the magic word detection/removal, as well as a suppress autosign, given the choice. Nosebagbear (talk) 12:52, 24 February 2022 (UTC)
It's been about a year since I asked about this, but I believe that the explanation for why that isn't as simple or reliable as it seems like it should be involved the words "pre-save transformation". It might be possible, but it might not be proportionate effort for the small benefit. Whatamidoing (WMF) (talk) 18:44, 24 February 2022 (UTC)
A "DO NOT Auto sign" button (perhaps in Advanced) shouldn't have that problem. — xaosfluxTalk 18:50, 24 February 2022 (UTC)
True. On the other hand, at what point does cramming in all the features we want tip this away from "simple, lightweight tool for quick replies (use the [edit] button if you want to do something complicated)" into a tool that can do anything but which is no longer simple, lightweight, or quick? There's always room for me to put one more cow on the commons, but if we all do that... Whatamidoing (WMF) (talk) 21:39, 24 February 2022 (UTC)
Not sure the good balancing point, personally think I'd rather have "sig is already there, don't add it" then more UI elements to turn it off. As far as the tipping point- we are about to put (on some pages) hundreds or more links to this tool on pages. Putting the sig in "for you" is already new functionality being added (vs just clicking edit), so looking at the sig specific components seems worthwhile. — xaosfluxTalk 21:51, 24 February 2022 (UTC)
hi @Nosebagbear – are you able to share a link to a comment where a ... full signature would be either duplicative or obtrusive for the usecase. ?
...I ask the above in an effort to form a clearer image in my mind for the kind of scenario that, I assume, prompted you to raise this issue here and @Thryduulf to raise a similar issue in phab:T278357... PPelberg (WMF) (talk) 21:40, 24 February 2022 (UTC)
I couldn't recall any specific situations off the top of my head, my experience over the years is that they are rare but they do exist. Searching project space for sign with three tildes finds mainly lists of participants in WikiProjects/attendees at meetups/events and similar.
Wikipedia:Third opinion/Instructions explicitly instructs to use five tildes, WP:TALK#REVISE notes "Best practice is to add a new timestamp, e.g., ; edited ~~~~~, using five tildes, after the original timestamp at the end of your post.", although in practice most editors who note a correction/amendment to their comment do so with four tildes.
As I noted in phab:T278357 though by far the most common uses of three and five tildes are typos for four (as at Special:Diff/1072386554). The cases when tildes other than four are intentionally desired are rare enough that needing to explicitly request the software not auto-add your signature (which will be of benefit in other scenarios too) is no burden. Thryduulf (talk) 22:41, 24 February 2022 (UTC)
ps: I just now recall that, several years ago, there was some reason (possibly humour) why I wanted my signature to display as something other than "Thryduulf" and so typed [[user:Thryduulf|foo]] ~~~~~. An even hazier recollection is of wanting something (no idea what) to display between by username and signature, resulting in ~~~ foo ~~~~~. If there have been five instances of my doing this since I got here in December 2004 I would be surprised. Thryduulf (talk) 22:41, 24 February 2022 (UTC)
Volunteer-me has been dubious about the advice in WP:TALK#REVISE, which is rarely followed and sometimes annoying. But even if you wanted to follow it, you can't make that kind of edit in the [reply] tool anyway. Ditto for adding your username to a list of participants/attendees.
Five tildes are sometimes wanted for starting RFCs (to have an RFC question without the posting individual's name), but that usually involves starting a ==New section==, which you can't do with the [reply] button. Five tildes are also used in MassMessage, which again doesn't involve the [reply] button. Usually, if someone adds a comment to an existing section with five tildes, it's a typo. Whatamidoing (WMF) (talk) 02:33, 25 February 2022 (UTC)
@Thryduulf the links you shared above were precisely the examples I was seeking...thank you for locating them and sharing them here.
As such, I do not think we should consider adding support for partial signatures within the Reply Tool to warrant blocking the opt-out deployment scheduled for 7 March.
On the topic of signature typos, I imagine those will be most common amongst experienced volunteers who I assume will be confident using the source editor to make corrections of this sort.
Please let me know if anything in what I shared above prompts new thoughts/questions. PPelberg (WMF) (talk) 01:06, 26 February 2022 (UTC)
@PPelberg (WMF) While I think dealing with phab:T278357 before the opt-out deployment would be desirable I can't in good faith describe it as essential (I would rank phab:T278355 the same way). The phab tickets don't give me any sense of how much effort would be required to fix them, though. A button or checkbox or something to disable auto-signing for a given post is something that can, imo, wait 1 or 2 releases but shouldn't be something we're still waiting for three or four years from now. Thryduulf (talk) 07:09, 26 February 2022 (UTC)
Having now read phab:T302550 (where I have also commented) I think you've misunderstood the intent of phab:T278357 - it is not about intentional uses of three and five tildes but graceful handling of unintentional ones, which are very significantly more common (they are almost impossible to search for, but I encounter them probably 1-2 times a month on average and I read only a tiny fraction of the discussions) Thryduulf (talk) 07:20, 26 February 2022 (UTC)
Currently, the tool displays a note if you type ~~~~. Do you want it to display a note for ~~~ and ~~~~~ as well (e.g., "You probably have a typo there. Did you really mean to add a partial signature?")? Whatamidoing (WMF) (talk) 20:40, 28 February 2022 (UTC)
The note is more annoying than useful in visual mode tbh. Adding one wouldn't harm, but just silently fixing it would much better. Note that it doesn't display a note in source mode at all - the only change is that the signature in the preview area changes from grey to black. In source mode (which is what I almost always use) three and five tildes do display the output you'll get, but I don't always look at that - if I'm not doing anything complicated with markup I have no need to. Thryduulf (talk) 16:56, 1 March 2022 (UTC)
@PPelberg (WMF) and Whatamidoing (WMF): Once deployed I'd like to see if we can get our edit request forms to start using this. Open eg [2] in incognito, the "Submit an edit request" link going via the Reply Tool (for new sections) would be neat. Any idea if this is technically possible, and if so what the best technical implementation may be? (we often have issues with people messing up the {{subst:trim}} part for example, so I wonder if we could give instructions in an 'editnotice' or have it prefill the {{edit extended-protected}} template 'behind the scenes' for example). ProcrastinatingReader (talk) 17:05, 27 February 2022 (UTC)
@ProcrastinatingReader We experimented with this in T269310. It is technically possible (and you can even find old demos on that task – please beware, it's an outdated version of the tool), but we found that many existing forms with preload either use complicated templates that don't work well in our visual mode, or they don't expect a signature to be added. It can be done, but at the time, it did not seem like the best place to put our effort.
That said… in my personal opinion, with my Wikipedian hat on: I don't think the problem with the edit request form is that it uses an old interface. The problem is that it has so many edit notices, you literally can't see the space where you're supposed to write when you open the page (see screenshot on the side, for posterity). Swapping the edit field for the shiny new tool would not improve anyone's experience if it would have all the same redundant boxes at the top. Matma Rextalk 00:29, 28 February 2022 (UTC)
Whenever I create a new post by using this Tool, the page width temporarily changes or squeezes. When I refresh the page, the width goes back to normal. George Ho (talk) 19:24, 2 March 2022 (UTC)
What skin are you using? Are you using the normal webui? What is your screen resolution width? — xaosfluxTalk 19:39, 2 March 2022 (UTC)
New Vector (2022) on desktop; 1366 x 768 landscape. I bet using this tool to reply can also result the same... unless I stand corrected. George Ho (talk) 19:44, 2 March 2022 (UTC)
This happens to me as well, and also affects CD (also Evil Vector). ― Qwerfjkltalk 20:53, 2 March 2022 (UTC)
Yes. The issue started when New Vector became a separate skin. ― Qwerfjkltalk 07:05, 3 March 2022 (UTC)
Can you try legacy vector, just want to see if 'new vector' is the only differentiator. — xaosfluxTalk 11:36, 3 March 2022 (UTC)
Confirmed, only affects New Vector. ― Qwerfjkltalk 17:01, 3 March 2022 (UTC)
Hope the issue doesn't occur in other skins besides New Vector. (this is a test post, actually, while using Monobook.) George Ho (talk) 02:42, 4 March 2022 (UTC)
Would one of you mind checking this on another wiki, e.g., French Wikipedia, which has had Vector 2022 turned by default for months? Nobody there has reported this problem. I wonder if there's something specific about this wiki's set up that causes this, rather than a problem affecting everyone. Whatamidoing (WMF) (talk) 21:42, 4 March 2022 (UTC)
The problem seems to have disappeared for now. I'll notify you if it reoccurs. ― Qwerfjkltalk 07:41, 5 March 2022 (UTC)
@Whatamidoing (WMF): The page width squeeze extends to Wikimedia Commons just on New Vector. I'm using safemode as you suggested for this reply. If the width squeezes here also, then this would be a problem. George Ho (talk) 03:02, 7 March 2022 (UTC)
As I thought, the width squeeze still persists, even on safemode. George Ho (talk) 03:03, 7 March 2022 (UTC)
I can't reproduce the problem. Can you upload screenshots demonstrating it? Matma Rextalk 13:38, 7 March 2022 (UTC)
@George Ho Thank you. This, however, leaves me very confused, because your screenshots look like neither the new Vector nor the old Vector. Here's what I see when using these skins: old Vectornew Vector. Your screenshots have the pure white background like new Vector, but they also have the light-blue lines like old Vector. I'm wondering if you're using something to change how Wikipedia looks that could be conflicting with the reply tool somehow. Matma Rextalk 23:21, 7 March 2022 (UTC)
Sorry about that. I was using the bottom of the page. I'll provide more screenshots using the top of the page right away. George Ho (talk) 23:37, 7 March 2022 (UTC)
@George Ho Thanks. Can you clarify if this happens only after posting your reply, or after simply opening the reply tool?
If it's only after posting, I might have some ideas for what could be happening (it looks kind of like we're loading the new page content using the wrong skin and creating an weird hybrid), although no idea yet why it's happening. Matma Rextalk 02:26, 8 March 2022 (UTC)
After posting either a reply or a new thread. Doesn't squeeze after simply opening the tool. George Ho (talk) 02:29, 8 March 2022 (UTC)
When this happened to me, it looked exactly like the third screenshot, with the tabs at the top mangled. ― Qwerfjkltalk 07:07, 8 March 2022 (UTC)
This will probably get a response of "that's a feature, not a bug", but something I've noticed is that the tool resolves edit conflicts. That's great with high-traffic noticeboards and when the reply that causes the edit conflict is not germane to your conversation, but what's happened with me is that a user makes a comment, I start replying to it, and during that time they alter it or add a supplementary comment, rendering my reply moot. Is there a way of showing the latest revision of the page when edits have happened inbetween the time you loaded it and the time you're about to publish? Example: message, supplement, my reply, not knowing it was moot, response alerting me to the change. Sdrqaz (talk) 21:17, 23 February 2022 (UTC)
Thanks! Sdrqaz (talk) 22:13, 23 February 2022 (UTC)
I particularly hope people will count the (raw) number of times that this happens to them, and that knowing about other replies would have resulted in a significant change to their comment. I'd love to be able to say with some confidence that this happens to highly active editors "once a week" or "once a month" or whatever. Right now, I can only say that some people have encountered it and mentioned it to me once (ever), and that I personally encounter this problem about once a month (out of hundreds of comments posted each month). Whatamidoing (WMF) (talk) 02:35, 25 February 2022 (UTC)
For clarity, I think the talk pages project has done a great deal of good, especially for our newer editors (I can't count the number of times I've seen errors with indenting and lack of signatures). Resolution of edit conflicts in this manner isn't ideal, but it's still better than not resolving them at all. Sdrqaz (talk) 11:08, 25 February 2022 (UTC)
Indeed, but while the phab task would be the ideal solution, if it can detect something at all, then perhaps adding {{ec}} at the front (even when the edit conflict isn't ultimately relevant) would be a huge (further) mitigation. Nosebagbear (talk) 11:21, 25 February 2022 (UTC)
Is would be nice if it handles this like CD does, i.e. notifying the user if the page has changed while they were typing, and allowing them to reload the page. ― Qwerfjkltalk 16:39, 25 February 2022 (UTC)
On a busy page like ANI, I don't think I'd appreciate being notified every time the whole page changed. At most, I think I'd like to be notified if new comments were added in the same section (preferably just to the same comment that I was replying to). Whatamidoing (WMF) (talk) 19:39, 25 February 2022 (UTC)
It's not a very obtrusive notification: The notification is the +1 on the left. ― Qwerfjkltalk 21:59, 25 February 2022 (UTC)
I concur with regard to (sub)-section - I hadn't thought that awareness of changes to the full page was even being considered. Nosebagbear (talk) 00:51, 27 February 2022 (UTC)
I understand that it would be easier to detect whole-page changes, but the devs are looking at better solutions.
WP:ANI averages one edit every 7 minutes, which is a lot of opportunity for whole-page notifications, especially if it takes you more than a couple of minutes to read what's already been written in that section. I'd probably have a 50% chance of seeing that notification before I even started typing a comment. Whatamidoing (WMF) (talk) 20:48, 28 February 2022 (UTC)
As a rough answer to your question on frequency, WAID, on my en-wiki side, I've had this come up 5 times in about 15/16 days. In two of those it's had some relevance to my answer, the other three had no relevance
I am fairly active on AN, TH, HD, ANI, and so imagine I have a higher than average rate of edit conflicts in talk posts Nosebagbear (talk) 15:45, 9 March 2022 (UTC)
New discussion tool enabled at Teahouse
Hi! Just dropping a courtesy note that we've decided to activate the new discussion tool for all visitors to the Teahouse. Thanks to the WMF folks for your work on this! Cheers, {{u|Sdkb}}talk 05:01, 13 March 2022 (UTC)
For the most part I'm liking the new reply tool. From an accessibility perspective, it's certainly a lot easier to use than hitting the edit button on a section or subsection, and then trying to find the specific comment you want to reply to inside the entire unformatted text representation of that section. However editing a comment you've made still requires that. Would it be possible to add an edit button, so that you can use the new reply tool to edit a comment you've already made? Sideswipe9th (talk) 16:42, 20 March 2022 (UTC)
Currently, only CD can do this. ― Qwerfjkltalk 16:50, 20 March 2022 (UTC)
Thanks! I was unaware of that script, I've added it now.Addendum Is there a way to get CD to always show the reply and edit buttons beside a comment, instead of them appearing when I mouse over the comment? I can't seem to find an obvious setting for that. Sideswipe9th (talk) 17:02, 20 March 2022 (UTC)
It's been a while since I installed the script, but does reformatting the comments do anything (it's one of the settings on the Talk page tab)? I get links to reply, edit, and thank (on others) on all comments. —Tenryuu 🐲 ( 💬 • 📝 ) 17:25, 20 March 2022 (UTC)
I think it moves the signature to the top of the comment, as well as some other things. ― Qwerfjkltalk 17:29, 20 March 2022 (UTC)
Been using it for a few hours now. While it has some nice features, unfortunately more of it annoys me than the good. Sideswipe9th (talk) 02:17, 21 March 2022 (UTC)
I would like to endorse an edit button, because right now, answering edit requests requires traditional source editing to mark them answered and actually replying at once CreecregofLife (talk) 02:14, 21 March 2022 (UTC)
No I haven’t. I haven’t explored the user-created add-ons. I’m still not sure who gets the right to use what, like, which tools are walled off to higher-ups and what have you. Twinkle feels like one of those, it has those vibes CreecregofLife (talk) 06:26, 21 March 2022 (UTC)
Easier linking to comments?
One thing that I've already encountered multiple times is wanting to link to someone else's comment using the new URL structure you've introduced. Editors presently tend to use diffs, but your structure is nicer, since it shows readable prose rather than markup and allows one to see subsequent comments. It's quite tedious, though, since it requires carefully copying the username and timestamps in UTC time. Would it be possible to introduce something like a link icon that would appear when you hover over a comment, and that when clicked would copy the link to it so you can paste it elsewhere? {{u|Sdkb}}talk 22:08, 24 March 2022 (UTC)
What new URL structure? --Redrose64 🌹 (talk) 22:25, 24 March 2022 (UTC)
That's not a new URL structure, it's the long-established form for an external link (as opposed to a wikilink) to a talk page with the addition of a fragment. The fragment is merely the value of an id= attribute somewhere in that talk page. So, you should be able to use your browser's "Inspect element" feature to identify an id= at the start of the relevant post. --Redrose64 🌹 (talk) 20:22, 25 March 2022 (UTC)
This would be extremely convenient and I support the idea. One reason they may not want to do this just yet is that the precise format for the IDs isn't 100% settled. (No idea if this is actually the case, just speculating.) Enterprisey (talk!) 04:06, 25 March 2022 (UTC)
I haven't, but that sounds very cool! {{u|Sdkb}}talk 15:32, 25 March 2022 (UTC)
BTW, rumor holds that we might get actual permalinks. The kind that won't be broken by archiving. Fingers crossed... Whatamidoing (WMF) (talk) 20:00, 6 April 2022 (UTC)
Marked unsigned comments
I noticed that the on-page reply feature hasn’t extended to comments that are marked unsigned. Like, I get why they don’t appear for comments that are plainly unsigned, but for what the unsigned template does, it should probably adopt that quality too--CreecregofLife (talk) 16:52, 22 March 2022 (UTC)
Unfortunately, there's no way for the software to tell the difference between a line that should have been signed ("Can someone help me?") and a line that is intentionally unsigned ("This section is for listing sources that we should use. Don't sign anything in this section, so that the bot won't archive it"). Whatamidoing (WMF) (talk) 18:22, 22 March 2022 (UTC)
I don’t mean intentionally unsigned, see I was dealing with an IP user on their talkpage and they wouldn’t sign their comments (presumably due to inexperience), so I’d keep having to go to the source to reply (and also put the unsigned template on their comments). By the time I could explicitly tell them to sign their comments, they stopped replying. CreecregofLife (talk) 18:54, 22 March 2022 (UTC)
How would you expect the software to identify an intentionally unsigned piece of text on a talk page? Whatamidoing (WMF) (talk) 18:42, 23 March 2022 (UTC)
I’m not. I’m hoping that this feature could be extended to the unsigned template. Is that unreasonable? CreecregofLife (talk) 18:45, 23 March 2022 (UTC)
Note the reply tool is part of the MediaWiki software and so applies to all MediaWiki installations, whereas templates are specific to what has been created by editors of a specific MediaWiki deployment. (Almost) anything can be handled in software, of course, given enough development time but it means the design and rollout is more complicated, with more potential interactions with other future features, thus affecting their development time and rollout. isaacl (talk) 00:04, 24 March 2022 (UTC)
I believe CreecregofLife may be talking about comments that have been marked with {{unsigned}} or a similar template. Which I would suspect would be painful but feasible. Enterprisey (talk!) 00:06, 24 March 2022 (UTC)
How easy or difficult it will be will depend on exactly how the reply determines what is and isn't a signature. Depending what that is, it might be possible (and if it is, probably easier) to modify the unsigned template to output something the reply tool sees as a signature. Thryduulf (talk) 14:05, 24 March 2022 (UTC)
It needs a link to any user page (User:, User_talk:, Special:Contributions) plus a valid timestamp. A blank copy of Template:Unsigned, which produces this: — Preceding unsigned comment added by [[User:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}#top|talk]] • [[Special:Contributions/{{{1}}}|contribs]]) isn't going to work. Whatamidoing (WMF) (talk) 17:40, 24 March 2022 (UTC)
If it's not working on a filled out/correct unsigned template, then it'd be helpful to have links/diffs. I thought that the [reply] tool worked with most of the unsigned templates at this wiki. Most wikis had to make a few changes to unsigned templates, but I thought that was done here more than a year ago. Whatamidoing (WMF) (talk) 17:44, 24 March 2022 (UTC)
Here's a diff that shows all the unsigneds on my motivating example getting substed, and you can see what I mean from there CreecregofLife (talk) 16:54, 25 March 2022 (UTC)
There are no timestamps in those signatures. You have to have a user plus a timestamp. Whatamidoing (WMF) (talk) 21:54, 6 April 2022 (UTC)
Currently reply links show up in archived discussion pages too, where they won't be of any use. Archive page templates like {{aan}} use the magicword __NOEDITSECTION__ to suppress section edit links. It would be nice if reply links can be suppressed this way as well. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:13, 2 March 2022 (UTC)
@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ are you able to share a link to the archived discussion page(s) where you noticed reply links appearing where they shouldn't be?
Reason being: I'd like to add links to these pages to the ticket that @Xaosflux mentioned above (T249293). PPelberg (WMF) (talk) 23:50, 4 March 2022 (UTC)
Related: is it possible to suppress reply links in pages that are not intended for active discussions? For example, Wikipedia:Requests for comment/Biographies and similar pages where the content is bot-copied from the real discussion pages. --Redrose64 🌹 (talk) 00:12, 8 March 2022 (UTC)
@Redrose64 not currently, if the solution is a magicword, then that could be applied on any page. — xaosfluxTalk 01:24, 8 March 2022 (UTC)
Somewhat related: I noticed the reply links show up when viewing past revisions of a talk page and when reviewing talk page diffs. What happens if someone uses it on an old revision or below an old diff? I suppose it's fine unless there are any sort of undesirable consequences, in which case I would recommend suppressing them there as well. DB1729 (talk) 05:22, 8 March 2022 (UTC)
If the comment you're replying to is still on the page, it will automatically resolve the ensuing "edit conflict". If it's not (e.g., due to archiving), you'll get an error message. Whatamidoing (WMF) (talk) 05:46, 8 March 2022 (UTC)
Thanks. That's cool, but on further thought, when viewing an old version of any page, the edit source links for sections disappear. There have been a handful of occasions when viewing an old diff, I would notice something that needs correcting and look for the edit link for the section. Seeing it not there, I would realize I nearly edited an old version and back out. It might be worth considering to similarly disable the reply links to offer that same clue. Just a suggestion. DB1729 (talk) 06:23, 8 March 2022 (UTC)
Agree on that. --Redrose64 🌹 (talk) 09:20, 8 March 2022 (UTC)
@DB1729 @Redrose64 There is a nice improvement to the reply tool's behavior on old revisions coming this week (powered by the same code that provides the edit conflict warning I promised here): when you start replying on an old revision, and there are new comments in the same section in future revisions, you'll get a warning about it and a prompt to display them. I hope that will resolve this concern. Matma Rextalk 12:37, 8 March 2022 (UTC)
Reply button on archives
I was browsing some Noticeboard archives and noticed the Reply button was very much present. I haven’t quite checked User talk archives, and I’m not sure what can actually be done about it, but I imagine should anyone jump in on those archived threads they’ll just be reverted.--CreecregofLife (talk) 07:23, 7 April 2022 (UTC)
I've encountered some unexpected behavior with headings. This situation is that I'm giving out a bunch of identical {{subst:FAR notice}} messages, and after the first one, I only wanted to have to copy and paste one thing, rather than the header and body separately. So I went into the source code and copied the full section, including the header, and then pasted it into the body on the next user talk page. This worked, but I noticed that it caused me to leave a message without an edit summary [3], which isn't ideal for communication and harms my edit summary usage stats. So for the next talk page, I clicked on the advanced button and entered a summary ("FAR notice") manually. This time, though, without any sort of preview, it added my summary as the header, creating a duplicate header I had to remove [4]. There are a few different paths you could take to resolve this issue, but you should do something so that this unexpected behavior isn't occurring. {{u|Sdkb}}talk 22:04, 9 April 2022 (UTC)
Sounds like a bug. Thanks for reporting it. Whatamidoing (WMF) (talk) 16:33, 11 April 2022 (UTC)
Reply tool ... no option to indent with asterisks instead of colons?
In the reply tool, is there no way to indent with an asterisk instead of a colon? Long story short ... [this edit was obviously unintentional, but it caused the intention to be one level too many. If there is no option, there should be one. Steel1943 (talk) 23:46, 11 April 2022 (UTC)
It's complicated. On the one hand, most people at most wikis prefer : for discussions. A few, most notably including a sizable number of editors at the Russian-language Wikipedia, prefer * as the main formatting code. So the default is : and it's possible to change that default wiki-wide (but not user-by-user).
But even if you prefer : for most discussions, you might:
want to add a voting-style comment (e.g., your diff)
want to reply to an item in a bulleted or numbered list (e.g., to ask someone a question about their !vote).
When you want to add a voting-style comment, then you need to change the formatting code, but you also (and more importantly) need to change the indentation. Changing the indentation is the step that would have prevented the :* problem in your diff. This will require work, and possibly a way to "code" the page (e.g., by adding a template) to say "Dear DiscussionTools, please note that this is RFC and the normal behavior here is a bulleted list, not a threaded discussion". The Editing team talked about this last year (see phab:T259865), but I don't know if it will get done. A smaller but possibly just as useful idea is to give editors more control over outdenting (see phab:T265750).
For the second case, if the first item is * and I want to reply to that, then some editors prefer to use ** and others prefer *:. The reply tool originally matched (** or :: but not *:) but someone said they liked it better the other way, so it now uses : always. Whatamidoing (WMF) (talk) 19:30, 12 April 2022 (UTC)
Finding discussions
Not sure the best place to get in touch with the relevant editing team (ping @Whatamidoing (WMF) and PPelberg (WMF):, but a regular issue seems to be duplicated sections being created for issues already being discussed. Example at Talk:Bucha massacre (permalink) where we have the same issue being discussed in lots of different sections (e.g. many sections effectively about the same concern with the 'Reactions' section, ditto with Russia's involvement in the issue, etc). I imagine part of the issue is that many editors independently see the issue, the talk page is unmaintained and has too many sections so they can't be bothered to read through and find if the issue is already being discussed, so they create a new section. It makes discussion more split and harder to reach a consensus on issues, or figure out which of the many sections you should reply to.
I don't have a solution, but maybe a way to highlight 'key/highly active' ongoing discussions could be one way. Another way could be improved refactoring tools for volunteers to more easily merge sections together. ProcrastinatingReader (talk) 15:16, 5 April 2022 (UTC)
@ProcrastinatingReader, thanks for this. The designer's been thinking about this problem. Take an unofficial peek at this demo to see a starting point. There are several small-to-medium problems that they'd like to address. Some of these are about finding out which discussions need attention/are active now. Others are not so obviously related to this (e.g., look at WT:V's history for all the new editors posting article content on the talk page).
As for the specific page in question (which I haven't looked at), one way to manage exceptionally large discussions with several "themes" is to have the regular talk page work more like a signpost than a talk page. Imagine that people reaching that page see something like this, instead of the normal talk page:
and that clicking the relevant button takes you to a separate page (or a specific section) where that subject is discussed. In my experience, so long as you direct people to a page where they believe their concerns are being taken into consideration (e.g., you have to respond to the comments on all pages; also, no fair sending one group to a page called /Bad ideas or /Null), it seems to work. In this instance, you could even EC-protect the regular talk page to discourage "accidental" posts on the wrong page.. Whatamidoing (WMF) (talk) 21:53, 6 April 2022 (UTC)
That demo is interesting. Colour coding the "last comment" value would be useful, pure date-based comparisons mean somewhat little to me, to be honest, but colour-coding (based on activity within past day / past week) may be more useful.
I feel like signposting/protecting main talk page is unconventional enough such that it'd be difficult to get consensus to try this on a talk page where it's actually required (there would be a lot of active editors on it, and this would be a big enough change to their workflow s.t. I doubt many people would want to try it). ProcrastinatingReader (talk) 21:43, 22 April 2022 (UTC)
@ProcrastinatingReader – I'm glad you stopped by to share the issue you've been encountering/observing.
I also agree with you in thinking that the length of Talk:Bucha_massacre, combined with the lack of an easy way to review all that's been/is being discussed on the page [i], could help to explain why you have been seeing people starting new discussions about a topic that is already being discussed.
It's with the above in mind that I wonder: would you be open to trying updated version of the prototype [ii] @Whatamidoing (WMF) referenced above that includes a new table of contents? I'm thinking the new table of contents might help with the "there not being an easy way to review all that's been/is being discussed on the page" part of the problem.
And while I don't think the prototype I've shared a link to above will solve this issue outright, I am curious to learn whether you think it is a step in the right direction.
---
i. has too many sections so they can't be bothered to read through and find if the issue is already being discussed...
ii. I've added the contents of the Talk:Bucha massacre to the prototype to make evaluating it through the frame of the issue you came here to share a bit easier. PPelberg (WMF) (talk) 00:43, 23 April 2022 (UTC)
Reply tool inserts comment between warning and shared IP notice
As seen in this diff, when the unregistered user replied to my warning, their comment was placed between the warning proper and the shared IP address note supplied by Twinkle.
Is this intended behavior? Something still being worked on? I didn't see anything about it here. Or is it Thursday? I haven't noticed if it was doing this before today or not. --DB1729 (talk) 14:53, 21 April 2022 (UTC)
Honestly, I feel like that should be how it’s done. Let it behave like a footnote especially as the conversation goes on and doesn’t address it directly CreecregofLife (talk) 14:58, 21 April 2022 (UTC)
Fair enough. That point had occurred to me as well. It just looked odd. I guess because I'm not used to seeing it like that. --DB1729 (talk) 15:07, 21 April 2022 (UTC)
I think it’s a little weird when multiple of that same note are in the same section. I’m not saying it should be programmed to recognize it, but it should be okay to just let the bottom-most instance encompass it all CreecregofLife (talk) 15:39, 21 April 2022 (UTC)
If comments are always placed at the bottom of a section, they'll be placed at the bottom of the section even when the bottom-most matter is or {{reflist-talk}}. Whatamidoing (WMF) (talk) 20:51, 25 April 2022 (UTC)
Feedback: New talk page designs
Mockups are ready for the changes designed to make it easier for people to understand and use talk pages on desktop and mobile. We would value hearing what you all think.
Below is the information you will need to review the designs and share feedback about them.
Proposed design for mobile wikitext talk pages.
An annotated mockup showing the proposed design for mobile wikitext talk pages (landing page view).
An annotated mockup showing the proposed design for mobile wikitext talk pages (individual discussion view).
Proposed design for desktop wikitext talk pages.
An annotated mockup showing the proposed design for desktop wikitext talk pages.
Do you have a mockup of the desktop that shows multiple sections and more comments at once? Perhaps a scrolled down version of that one? — xaosfluxTalk 21:55, 25 April 2022 (UTC)
hi @Xaosflux – we don't have a mockup that that shows multiple sections and more comments at once; however, there is a prototype ready that I think will enable you to see and use a page like you are describing.
Can you please let me know what you think of the prototype linked below? It's a test wiki, so please feel free to experiment.
@PPelberg (WMF) Are there any plans for how to handle level 3+ sections on talk pages? A discussion having many level-3 sections is often a key indicator it's a major one, so I'd like the ability to see them easily preserved. {{u|Sdkb}}talk 21:22, 15 May 2022 (UTC)
The current table of contents on talk pages shows all the level-3 sections in a way that doesn't require any uncollapsing. {{u|Sdkb}}talk 21:59, 16 May 2022 (UTC)
This new Table of Contents is part of Vector 2022, and the only thing Editing is doing is sticking the icons into it. If you think that the TOC should generally be uncollapsed, then I encourage you to share your suggestion at mw:Reading/Web/Desktop Improvements. Whatamidoing (WMF) (talk) 16:51, 19 May 2022 (UTC)
2. As evidenced by the link to the patchdemo above, there is a prototype of the new talk pages designs on a test wiki that I'm keen to hear what you think about. I'm going to post more details about the prototype and the kinds of things we are seeking to learn in a post I'm drafting now. PPelberg (WMF) (talk) 00:31, 20 May 2022 (UTC)
New Topic Tool for everyone
...or maybe not everyone. phab:T306481#7904753 suggests that the mw:New Topic tool is good for newer editors, but once you've made a few thousand edits, it's not as important, and people may not be interested in changing to the new system. OTOH, there's a built-in opt-out button, and remembering to sign your comment with ~~~~ when you start a new ==section== but not when you [reply] could be an unnecessary amount of mental effort. I'm interested in hearing people's thoughts about this. We should probably deploy this to newcomers, but should we skip the old hands, or do everyone (with the expectation that many will opt out)? There is no urgency and no pre-determined "correct" answer about this. I would just like to hear what you think would be best. Whatamidoing (WMF) (talk) 00:33, 14 May 2022 (UTC)
Perhaps you can provide a capsule summary of the feature, or point to somewhere on the linked metawiki page that describes it? (I couldn't find it in a very quick skim through some of the page; I imagine with more searching I'd be able to find something.) isaacl (talk) 03:40, 14 May 2022 (UTC)
@Whatamidoing (WMF) If there's an easy option to opt out, I don't foresee much chance of a big uproar if it were enabled for everyone by default. The main things that, as an experienced editor, I wish the new topic tool handled better were templates that either include a heading automatically or sign for you automatically.
At this point, I'd like to see the tool deployed by default at en-WP, as it's holding up us being able to finally remove the "please remember to sign with ~~~~" instruction in a bunch of newcomer-focused messages, and it'll be nicer to have a longer post-deployment period in which you're able to make changes from feedback. Best, {{u|Sdkb}}talk 21:32, 15 May 2022 (UTC)
AIUI your main wish requires rich-text editing in the visual editor, which is a huge project. (But imagine the payoffs: you could edit some contents of an infobox while it was being displayed in the editing window, without having to open a form.) Whatamidoing (WMF) (talk) 20:23, 16 May 2022 (UTC)
At this point, I'd like to see the tool deployed by default at en-WP...
@Sdkb what do you think would be a good first step to take to start the conversation with volunteers at en.wiki about the prospect of enabling the New Topic Tool on desktop by default?
The process for scaling the New Topic Tool as a default-on feature is going to happen in phases, with us thinking en.wiki being a part of the last stage. See more in phab:T287804.
With "1." and "2." in mind, for the Editing Team, a deployment to enable the New Topic Tool by default at en.wiki is still some time away. Tho, if you have capacity to start that conversation, we'd be eager to support you. PPelberg (WMF) (talk) 00:22, 20 May 2022 (UTC)
@PPelberg (WMF) I think a proposal to turn it on by default would currently pass, so for that specific thing, there's not really further conversation needed. Just start an RfC at WP:VPR asking "Should it be turned on by default?", provide a background section concisely explaining what the tool is (with a link to try it out) and why you developed it, and issue {{please see}} invites to relevant other pages like this one.
The part where there is room for further conversation is refining the feature. I've encountered other features before where enabling on en-WP is seen as the culminatory step, and after it's deployed, a bunch of editors see it for the first time and come to the team with feedback, but by that point they've moved onto something else and are no longer available to work on changes. Do you have some period planned post-deployment where you'll be able to work on changes in response to feedback? I'd much rather that the tool be released earlier, while it still has a few rough spots, than that feedback arrive too late. Cheers, {{u|Sdkb}}talk 22:38, 20 May 2022 (UTC)
@Sdkb, I wonder if you'd be willing to write and post that RFC yourself. If you have to wait on me for it, it's unfortunately going to take a while. (IMO the key point is that it is very easy to turn off.) Whatamidoing (WMF) (talk) 20:20, 27 May 2022 (UTC)
@Whatamidoing (WMF) and @PPelberg (WMF), sure — I've gone ahead and started it here. The ultimate rollout schedule is something you'll handle on your end, but I hope that if the RfC is successful, it'll make you comfortable proceeding on en-WP at your earliest convenience. Cheers, {{u|Sdkb}}talk 21:38, 27 May 2022 (UTC)
@Sdkb: I appreciate you taking the initiative to get the RfC started. I'm subscribed to the discussion and I am standing by for any questions or issues people might raise that I, @Whatamidoing (WMF), or any members of the team can help address.
In the meantime, I wonder: do you think it would be worthwhile to mention within the RfC how, in addition to people having the option to ...opt-out...in their preferences., the tool offers peoples the ability to switch back to the existing section = new experience from directly within the tool as pictured here: File:New Discussion Tool Hint.png? PPelberg (WMF) (talk) 23:44, 27 May 2022 (UTC)
@PPelberg (WMF) I wasn't aware of that; very cool! It could definitely be worth sharing in the discussion section. {{u|Sdkb}}talk 01:08, 28 May 2022 (UTC)
I've encountered this twice now. If you're using a {{subst}} template that inserts a section header, for example using {{subst:An3-notice}}, if you leave the Title field blank but fill in the Edit Summary to match the header, the new section tool will automatically add a header based on the edit summary.
In this diff you can see that two headers have been created. == Notice of edit warring noticeboard discussion == comes from the substitution template. == /* Notice of edit warring noticeboard discussion */ == comes from the text in the edit summary.
Not sure how to resolve this to allow use of substitution templates and edit summaries with the new section tool. The correct behaviour should be that only one section header is created. Sideswipe9th (talk) 17:26, 6 June 2022 (UTC)
The MediaWiki software is written so that you can have a "Subject" box above the edit window, or an "Edit summary" box below it; but you won't have both. Whichever way you fire up an edit window, you will have exactly one of those: no more, no less. As it happens, the underlying HTML has the same id="wpSummary" attribute for both the Subject and the Edit summary input boxes, so your browser uses the same table of prefill values. Except probably MS browsers, which have always been ... different.
Tip: if you're using a template that adds its own heading (n.b. not "header"), don't use the new section feature. Instead, go to the bottom of the page and edit the last thread. Paste your {{subst:An3-notice}} below that, preview, copy the new heading to your clipboard (which might be Notice of edit warring noticeboard discussion), then click on the edit summary box, blank out whatever is in there currently, and replace it with this:
/* Notice of edit warring noticeboard discussion */ new section
making sure that the part between /* ... */ is pasted from the section heading that you copied. --Redrose64 🌹 (talk) 21:02, 6 June 2022 (UTC)
The MediaWiki software is written so that you can have a "Subject" box above the edit window, or an "Edit summary" box below it; but you won't have both. That isn't true for the new section tool, which per the screenshot that should be embedded with this reply has both. I've checked in the current versions of Firefox, Chrome, and Edge, and all have both a title and summary box per the screenshot.
Oh, whoops, I'd thought this was VPT or somewhere like that, didn't notice that it's a new feature trial. --Redrose64 🌹 (talk) 22:31, 6 June 2022 (UTC)
No worries! That's why I included a screenshot with the reply, cause it visualises it better than I can describe! Sideswipe9th (talk) 22:32, 6 June 2022 (UTC)
This is a bug in the MediaWiki API we use in the new topic tool to save your edit (T54747), somewhat related to the situation in the wikitext editor that Redrose64 described above. Matma Rextalk 10:55, 8 June 2022 (UTC)
So, when using the quick reply tool, can TAB go to either the edit summary or the submit button, similar to if you are in the wikitext editor? Having it go to the next hyperlink on the page (for example in the preview) doesn't seem very helpful. — xaosfluxTalk 12:56, 8 June 2022 (UTC)
This idea was previously discussed in T271773. At the time it seemed like it wouldn't necessarily be intuitive, and could be particularly confusing for screen-reader users. In my own experience, in cases where I'd previously press Tab then Enter to submit a message, I just press Ctrl+Enter. Matma Rextalk 16:49, 9 June 2022 (UTC)
This closed with strong support for deploying this. I'll talk to the Editing team today about when we can get it done. (It will not be this week.) Whatamidoing (WMF) (talk) 17:04, 23 June 2022 (UTC)
So with the varying voting events around the site, should there be a reminder or something to vote by replying to the nomination (for the on page reply box system) rather than the previous vote or are we trusting the users to come to this conclusion on their own? CreecregofLife (talk) 05:42, 8 July 2022 (UTC)
New Subsection Tool as a counterpart to the New Topic Tool
I recently added the new topic tool, and I've found it to be very useful. I like the consistency between it and the reply tool, in terms of how it looks and functions. Would it be possible to get a counterpart to the New Topic Tool focused on adding new subsections to existing topics? I'd envisage it using the same UI as the topic and reply tools, and accessed with a "New Subsection" button that appears next to the edit source button at each section header. Sideswipe9th (talk) 15:24, 29 May 2022 (UTC)
This has been suggested before, but I can't find a ticket in Phab: for it right now. Whatamidoing (WMF) (talk) 00:12, 9 July 2022 (UTC)
New topic doesn't seem to play well with DS alerts
I add the alert by hand, ie not using Twinkle, and it simply adds the alert instead of bringing up the notice to check the talk page, etc. Doug Wellertalk 09:18, 21 July 2022 (UTC)
I can't say I've noticed this. I use the {{subst:alert|topic=...}} and always get the edit alerts. How are you adding the alerts? Sideswipe9th (talk) 13:17, 21 July 2022 (UTC)
Can you explain this a little more? Are you expecting an abuse-filter interception that is not working? — xaosfluxTalk 14:08, 21 July 2022 (UTC)
Possibly related to the similar report in phab:T298263? — xaosfluxTalk 14:15, 21 July 2022 (UTC)
It's kind of an awkward problem to test, as you don't want to go around warning random editors. I suppose people could test this at User talk:Example. Whatamidoing (WMF) (talk) 17:36, 21 July 2022 (UTC)
Just had a look at that phabricator ticket. @Doug Weller: do you still use User:Bellezzasolo/Scripts/arb for issuing the alerts? In one of the screenshots there was a talk page discussion from December 2021 where you mentioned using it. Is it possible it's a bug or weird interaction with that script and the new topic tool? Sideswipe9th (talk) 23:48, 22 July 2022 (UTC)
@Sideswipe9th yes I do. I use the what I think is the normal new topic + sign in the top menu. Doug Wellertalk 08:35, 23 July 2022 (UTC)
Put in a subject, put in an alert (e.g. {{subst:alert|topic=Test}})
Click "Add topic"
The abusefilter warning should dispaly
Click "Add topic" again
I think I managed to get it to skip once, but not consistently. Are there any steps that always cause failure? — xaosfluxTalk 18:18, 21 July 2022 (UTC)
@Xaosflux I can’t reproduce this on my iPad, at least right now, will try on Windows later. It’s happened more than once. Doug Wellertalk 08:33, 23 July 2022 (UTC)
Using Windows, click on +, add DS alert, added immediately with no warning. Doug Wellertalk 09:33, 23 July 2022 (UTC)
@Doug Weller thanks for the update, is this your last example? The log suggests that it first warned you at 09:29:05 (Special:AbuseLog/33042063), then you confirmed and published that edit 09:29:10, which logged at 09:29:11 (Special:AbuseLog/33042065). Are you sure nothing happened during that 6 second span? Perhaps like in the prior report it didn't display the abuse filter warning, but you had to click the publish button a second time? — xaosfluxTalk 11:22, 23 July 2022 (UTC)
@Xaosflux Odd. I'll report back next time I try. I don't think there was a warning or that I clicked twice, but... Doug Wellertalk 12:06, 23 July 2022 (UTC)
Thanks, it may be that there should be the abusefilter warning, but it isn't showing - that is also an occasional open issue with the very-related reply tool. — xaosfluxTalk 12:08, 23 July 2022 (UTC)
I'd really like to get to the bottom of this, but I haven't had any good ideas since the last time you reported the problem in phab:T298263. It seems like no one else can see this, which makes it difficult to fix.
@Xaosflux Thanks for finding the abuse logs, I didn't think of that the last time and this could be very helpful. This rules out a whole class of issues (e.g. it can't be a problem with AbuseFilter receiving wrong data for API edits, like phab:T191722). And it's good to know that AbuseFilter thinks the warning was shown.
I tried it again just now on my own talk page, and I got the warning as expected, but also noticed something interesting – I had my browser developer tools open, taking up most of the screen, and after the warning was shown it wasn't actually visible on my screen (as it appears above the input box, and I had scrolled down to the preview). If you're using a small device, you could just think clicking "Add topic" did nothing and click it again. @Doug Weller Is there any chance that this is what is happening? We should probably scroll the warning into view, and maybe that's all we need to fix this? Matma Rextalk 16:26, 23 July 2022 (UTC)
@Matma Rex Possibly. I haven’t been able to reproduce it today but then I’ve not given many alerts. I’ll be more mindful about what to look for, thanks. Doug Wellertalk 17:14, 23 July 2022 (UTC)
@Matma Rex I think that must be what is happening, and apologies for not realising that. Scrolling the warning into view would help as I have the same problem on my PC with a decent size monitor. Doug Wellertalk 15:27, 25 July 2022 (UTC)
@Matma Rex See my screen shot here. Perhaps the abusefilter warning could be moved to after the preview section instead of before it, making it closer to the publish control? — xaosfluxTalk 15:44, 25 July 2022 (UTC)
@Xaosflux I'm not sure why, but showing the errors/warning below the big input field seems weird to me. I wrote a patch to scroll the warning into view instead, which hopefully won't feel weird to anyone and which is a very simple change. Hopefully that resolves this, and @Doug Weller it's definitely not your fault. Thanks for your patience. Matma Rextalk 16:24, 25 July 2022 (UTC)
In that patch, it will scroll the output and control buttons off the bottom of the screen though? At least editors should "naturally" know to scroll back down? — xaosfluxTalk 16:42, 25 July 2022 (UTC)
The new reply feature has the edit summary hidden away in a button that reads "advanced". I think it shouldn't be hidden because it encourages and misguides editors in not writing an edit summary. Maybe there should be a prompt that can be disabled reminding editors to leave an edit summary. --Thinker78(talk) 18:17, 14 July 2022 (UTC)
As I do with articles. I write an indication of what I did, so people have an idea what is it about and have less need to open the diff to see what's going on. For example if I reply to someone I indicate so, if I make a correction to my comment I say so, if I attribute an unsigned comment, likewise. Edit summaries does help to a useful degree in my experience. Thinker78(talk) 15:32, 19 July 2022 (UTC)
My question is how you use the edit summaries that other people post on talk pages. How often do you read them? (I almost never do; I just make a diff to show me everything that's happened since the last time I read that page.) Do their edit summaries change your behavior? For example, if the edit summary says "Yes", do you decide not to read the comments? Whatamidoing (WMF) (talk) 17:31, 21 July 2022 (UTC)
Actually edit summaries that other people write are generally very useful to me. That's why when someone doesn't leave an edit summary it bothers me, because when I'm checking my watchlist out or patrolling in general, it makes me have to go check the diff to see what's going on instead of just reading the edit summary. This is specially irritating when it was a hard to notice change, like a typo fix. Another way it is helpful is when Im interested in a discussion and an editor replies to a different thread, if the editor says so, it saves me precious seconds which accumulate along the day. I mean there is a great reason why edit summaries are part of the editing process. Thinker78(talk) 16:39, 24 July 2022 (UTC)
Thanks for this detailed response. I’ve been concerned that this discourages edit summaries and agree with you. I wonder if it will discourage edit summaries for articles, etc. Doug Wellertalk 19:06, 24 July 2022 (UTC)
Ironic, I meant to leave an edit summary but forgot. On most pages I can’t publish without one. Doug Wellertalk 19:08, 24 July 2022 (UTC)
@Thinker78, it sounds like you're picking and choosing which comments and discussions to read, and skipping anything that doesn't sound interesting or relevant.
Have you tried the [subscribe] tool? This is a good option when you don't want to watch a busy page, and instead you only want to know if a new comment (not, e.g., a typo fix) has appeared in the specific section that you care about. Whatamidoing (WMF) (talk) 21:15, 25 July 2022 (UTC)
Very few people use meaningful edit summaries for talk page edits, so this is a bit hypothetical. I would use them in the same way as I use edit summaries on articles, though: they help me prioritize my interest in looking at the diff. If it's a typo fix, I might skip it. If it addresses a portion of the discussion I'm not interested in, I'd put it lower down on the list to look at, if at all. If the summary reveals that the comment addresses an area I'm particularly interested in, or is in response to something I wrote, I'd put the diff higher in the list of priorities. Much like you, I look at the aggregate view of diffs since I've last looked at the page. Nonetheless the prioritization still holds in deciding what aggregate to look at first; I'll look over the edit summaries either on the watchlist or in the history view. isaacl (talk) 01:31, 25 July 2022 (UTC)
How often does the manually added edit summary help you, vs the automatic /* Section heading */? Whatamidoing (WMF) (talk) 21:16, 25 July 2022 (UTC)
The automatic section heading is useful when one is interested in a particular section. Otherwise if one is patrolling articles, not that much, except in certain contexts. It should be coupled with an explanation of what one did in that section to maximize its usefulness. Btw, thanks for the subscription tip, I was not aware of such tool. I will find out about it. Thinker78(talk) 21:31, 25 July 2022 (UTC)
Since as I mentioned, almost no one writes meaningful edit summaries (most of them are some variant of "reply"), in absolute terms, manually written edit summaries don't help much. In the few cases where they are meaningful, in concert with the section heading info in the comment they assist in my prioritization, as I described, and thus are very helpful. isaacl (talk) 20:20, 26 July 2022 (UTC)
Works for me — xaosflux Talk 00:18, 22 February 2022 (UTC)
Nick Moyes (talk) 15:02, 22 February 2022 (UTC)
Proposed design for mobile wikitext talk pages.
An annotated mockup showing the proposed design for mobile wikitext talk pages (landing page view).
An annotated mockup showing the proposed design for mobile wikitext talk pages (individual discussion view).
Proposed design for desktop wikitext talk pages.
An annotated mockup showing the proposed design for desktop wikitext talk pages..jpg)
.jpg)
.jpg)
.jpg)
.jpg)
You are invited to join the discussion at Wikipedia:Village pump (proposals) § Enabling the New Topic Tool by default. {{u|Sdkb}} talk 21:34, 27 May 2022 (UTC)