Talk:Talk pages project/Replying/2021/06

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

What is the captcha thing? It wouldn't let me reply, & it brought up no captcha for me to solve.

Nnothing appeared on screen. 2001:4479:302:8000:F8B4:AEAA:EF1D:8A06 (talk) 01:14, 3 June 2021 (UTC)

I'm from Miraheze and I cannot see the image (even using Firefox to see the resources), making it impossible to reply. 177.152.89.100 (talk) 19:10, 3 June 2021 (UTC)

We test DiscussionTools with FancyCaptcha and QuestyCaptcha; other ConfirmEdit modules may not work. Matma Rex (talk) 15:11, 4 June 2021 (UTC)

What do you type in for Captcha? SHANEY SHOE (talk) 19:19, 8 June 2021 (UTC)

Not working with !vote styles

Tracked in Phabricator
Task T259865

In voting discussions (such as in WP:RM), when replying to the proposal it adds ":", but the style used by others is a bullet "*", which then produces ":*". There should be a way for this to work in such discussions without needing an additional edit to fix the layout. Other than this so far I'm loving this. Gonnym (talk) 09:33, 3 June 2021 (UTC)

An "indentation style" selector or something would be perfect to solve this. Or detect whether my edit starts with an indentation character (:,*,#) and then replace the auto-indent by my chosen one. Kusma (talk) 10:40, 3 June 2021 (UTC)

Also worth mentioning that in a Requests for adminship vote it doesn't work at all, as those discussions use sub-sections. Gonnym (talk) 09:03, 11 June 2021 (UTC)

Edited someone else's comment along with mine.

I've used this tool lot, and just now something odd happened - it added a line break in an other editor's comment. see here. Any idea what might have happened? שי אבידן (talk) 08:06, 11 June 2021 (UTC)

No, it didn’t add any line break. Two unusual things happened here:

• A space was removed from the end of the other editor’s comment’s first line. DiscussionTools tries to avoid such edits, even though their only consequence is that diffs become harder to read. Trailing spaces are stripped off by MediaWiki anyways. (It should be fixed though if it’s easily fixable.)
• One might say the reply appeared at the wrong place, since the comment below it starts with one indentation level more. However, that comment ends not indented at all, so the software has to make a guess what indentation level the comment actually belongs to, and happened to choose the less-indented one. This isn’t a software bug, since there’s no general good answer for the question; the only way to avoid such issues is that others don’t write comments starting and ending with different indentation levels in the first place. (I didn’t say it’s an easy way. 😉) Tacsipacsi (talk) 16:27, 11 June 2021 (UTC)

Fails when trying to reply to an outdent comment

I've tried replying to someone who used en:Template:Outdent and it failed to work. Gonnym (talk) 09:02, 11 June 2021 (UTC)

Did it not let you type a comment, or did it post it in the wrong place? Whatamidoing (WMF) (talk) 03:13, 24 July 2021 (UTC)

I don't remember, but I believe it did not let me write a comment. Gonnym (talk) 11:17, 24 July 2021 (UTC)

Unexpected edit summary

See https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Did_you_know&diff=1028075103&oldid=1028067794 The section name for the edit summary is taken from a subsection that is hidden in a collapsed box on a transcluded page. (The subsection's edit link would actually edit a different page). Kusma (talk) 18:16, 11 June 2021 (UTC)

This is the expected behavior. The Reply tool can "see" (and edit) the transcluded content, and it chooses the nearest section heading. Whatamidoing (WMF) (talk) 03:15, 24 July 2021 (UTC)

Add an edit button

Tracked in Phabricator
Task T245225

Would be great if I can also use this feature to edit my reply without needing to go back to the regular edit. Gonnym (talk) 10:58, 12 June 2021 (UTC)

It's on the team's list. I don't know when it will get done. It's been a fairly popular request. Whatamidoing (WMF) (talk) 03:12, 24 July 2021 (UTC)

Should be more like VE

This should act more like the Visual Editor used for articles. In other uses of VE (say, what I'm using now), if I type {{, it recognizes that I want to enter a template and opens the template editor tool. If I do that in the reply tool, I get the "Wikitext not allowed here". There should be a uniform VE UX across all uses of it. RoySmith (talk) 16:27, 17 June 2021 (UTC)

That'd be great. The talk page project is designed to help new editors reply. Greeting them with a "Wikitext not allowed here" message could just confuse them. --Ferien (talk) 16:37, 17 June 2021 (UTC)

Yeah, that'd be great. Frostly (talk) 16:44, 17 June 2021 (UTC)

Agreed. Interestingly, copy-pasting templates works perfectly fine (and you can then edit the template like in VE) — there's already the functionality to do this. Tol (talk | contribs) @ 16:55, 17 June 2021 (UTC)

Some templates break the list item syntax used for replying (* or :), and it is difficult to determine programatically which ones (templates like {{done}} are obviously okay, templates like infoboxes are obviously not okay, but there's a lot of grey area), so we opted to just discourage using templates until a multi-line list item syntax can be introduced to MediaWiki. Task T247421 has some context.

You can still use templates in wikitext mode (and we trust you not to do anything that messes up the syntax). Matma Rex (talk) 21:51, 18 June 2021 (UTC)

Despite the grey areas, would it be possible to look at TemplateData and infer that a template is safe if it has format: inline and no parameters with type: UnbalancedWikitext ? Pelagic (talk) 02:38, 27 June 2021 (UTC)

No, neither of those cause the problem with list syntax.

Problems occur when the wikitext output generated by the template contains line break characters, except if those line breaks introduce nested lists, or XML-style extension tags like <syntaxhighlight>, or tables in narrow circumstances (only valid if we're in a : list and at the start of a line).

The result is that part of the template (and your comment) is in the indented list item, and part of it (and your comment) is un-indented outside the list item, and this is not apparent in the visual editor until you save. (You can have line breaks in the template transclusion though, so block format is fine. But I guess unbalanced wikitext can also cause various issue that are not apparent in the visual editor… I did not really think about that before, but we should keep it in mind in the future.) I guess my explanation above was not great, the problem is not in determining whether the template will break the list syntax (we can just run it through the wikitext parser and look at the HTML that comes out) – it is in determining this before the user spends the effort to fill in the template (since we can't know whether template output will include a line break until we know the template parameters), and in explaining to the user why this particular template isn't allowed (without teaching them everything there is to know about line breaks in wikitext). Matma Rex (talk) 13:19, 28 June 2021 (UTC)

I came here to suggest this same thing. We use templates on talk pages all the time, often simple ones like {{Tq }} or {{Tl }}; having to switch tabs to do that rather than just typing brackets makes it a lot less convenient. Sdkb ^talk 00:44, 4 July 2021 (UTC)

Thanks for the explanation, Matma Rex! I only really understood after I tried to reply...

I was thinking that some is better than none. (E.g. some common templates like {{Tq }}, {{Xt }}, {{Noping }} could be available.) Adding a dedicated "list-safe: yes" flag to TemplateData would be the "proper" way, but might not be well received.

I now see what you mean about "wikitext output generated by the template contains line break characters" rather than linebreaks in the pre-transcluded template code itself. I was (incorrectly) considering behaviour when editing, not rendering. You're right that parsing after entry is the only completely correct test, but is not a good user experience – I don't think we'd want that.

Parameters that normally allow or expect multi-line input could also be troublesome: short of adding special mode in the template helper that treats all unknown, string, or content fields as if they were line. (For example, with w:en:Template:Tq, I was able to enter a line break that was invisible in VE but present in classic source mode.)

I agree with your point that there's an unenviable choice between saying "no templates for you" versus "w e l l, this template isn't allowed but that one is, because reasons". So maybe it's not the case that "some is better than none".

I guess we just wait until there is a new multi-line syntax, or we stop using <dl><dd> for indenting threads. Sigh. Pelagic (talk) 03:37, 4 July 2021 (UTC)

P.S. for anyone reading along or who finds this thread later, the task where {{ was disabled for Reply Tool is phab:T253667 "Visual mode lets you insert multi-line templates using the sequence `{{`". Pelagic (talk) 08:52, 4 July 2021 (UTC)

There's a draft of the technical RFC at User:PPelberg (WMF)/sandbox. I don't know when the Editing team will get back to this, but if you're interested in this problem, it'd be helpful to have a couple of people read that draft and tell me whether it makes sense to people who haven't been talking about this problem for the last couple of years. Whatamidoing (WMF) (talk) 00:49, 21 July 2021 (UTC)

Don't allow replies to old page versions

Tracked in Phabricator
Task T250295

If you look at an old version of a page, you probably want to suppress the "reply" links, just like "edit" links are suppressed on individual sections. I haven't tried replying on an old revision, but I can't imagine the results would be what the user expects. RoySmith (talk) 17:44, 17 June 2021 (UTC)

It will be what the user expects (or at least, it is what I expect… I worked on that part). That is, if the comment still exists in the latest version of the page, your reply will be posted as if you replied on the latest version; and if it doesn't exist any more (e.g. it was archived), you'll get an error message when clicking [reply].

I think this is a valuable feature, since I think that people often end up reading comments after following diff links from their watchlist.

Also, it may seem weird to allow this, but actually it's equivalent to a situation where you open the latest version of the page, read it for 15 minutes, try replying, and in the meantime other people have posted their own comments and the version you're looking at is no longer the latest. We had to make the software work in that scenario (without sending you to the edit conflict screen), so allowing it when you start with an old version seemed useful.

The interface could be improved by adding a note that there may be newer comments in the discussion that are not being shown – or even better, by loading and showing those comments when you try replying. But this improvement would also be helpful in the same way in the second scenario I described. Matma Rex (talk) 21:41, 18 June 2021 (UTC)

We had to make the software work in that scenario (without sending you to the edit conflict screen)

Actually this is the most annoying feature of DiscussionTools for me. Of course I don’t want to manually resolve edit conflicts, but I’d like to be notified about changes, at least when I try to post my reply (if possible, also when I start drafting it). After the browser tab being open for 15 minutes (or even hours), I find myself every now and then answering questions that have already been answered in the meantime, replying to things that are no longer relevant etc. Tacsipacsi (talk) 23:51, 18 June 2021 (UTC)

I like being able to reply on "old" pages, and it works. (If the comment you're replying to has been removed/archived, then you get an error message.)

I'd probably also appreciate a warning about it not being the most recent version of the page. Whatamidoing (WMF) (talk) 00:52, 21 July 2021 (UTC)

Page title doesn't show talk page is being edited

Tracked in Phabricator
Task T262066
Open

I doubt this can be fixed, but 'Replying' rather than 'Editing' a topic on a talk or forum page doesn't lead to any change in the displayed title in a Windows Tab. That's quite a loss of functionality for me, despite all the other benefits I've been discovering with this tool today. Can it be fixed?

I so often have 10 to 15 Wikipedia Tabs open at once - often needing duplicate versions of one Talk page to be open - and need to switch between them to continue editing replies as part of my administrative workflow. Being able to see one starting 'Editing:' amongst all the others is really, really helpful to quickly find it again. But that no longer happens because replying isn't detected as actual editing. So every single tab then just looks identical, saying 'User talk' or 'Wikipedia:' with the rest of the title lost from view. The one that shows 'Editing' really stands out and stops me losing my mind amongst the jumble of open talk pages and fora like en-wiki's Teahouse. Nick Moyes (talk) 23:00, 17 June 2021 (UTC)

I wouldn't worry about the technical difficulty of changing a page title, the JavaScript for that is just document.title = 'Replying: ' + document.title. GKFX (talk) 17:27, 18 June 2021 (UTC)

+1. When replying, add "Editing:" or "Replying: " in the title tag. Geraki (talk) 08:03, 18 June 2021 (UTC)

Tracked as T262066. Matma Rex (talk) 12:56, 19 June 2021 (UTC)

Issue with replying to a bulleted comment

Please see this edit, where I replied to a bulleted comment but it spat out a comment that was indented at the same level (so

:

instead of

*:

). Is that intentional? Sdrqaz (talk) 15:46, 18 June 2021 (UTC)

@Sdrqaz I'd have thought that, rather than an asterisk and a colon (*:) as you've suggested, the best indenting would have been two colons (::), as you would not normally reply to a bulleted comment with another bulleted comment, would you? Nick Moyes (talk) 16:10, 18 June 2021 (UTC)

@Nick Moyes I agree, but if I wanted to reply to a bulleted comment with another, I'd use two asterisks (**). The asterisk and the colon does not give out a bullet: it just matches the previous indentation level then adds another indent. The use of two colons in response to a bulleted comment is not encouraged on English Wikipedia due to the disruption it causes to screen readers: this has more on the issue. Sdrqaz (talk) 16:42, 18 June 2021 (UTC)

I was just coming here to post the same: there are pages like en:WP:TfD where most comments are not a reply to someone else, so the convention is a bulleted list presumably so as to make the start of each comment more visible. The tool should just match whatever the style is currently in the thread, probably with an option in the toolbar to set the list type for a new thread or new sub-list. GKFX (talk) 17:12, 18 June 2021 (UTC)

I think we're talking about two different issues: mine is that it didn't indent properly (the reply was on the same level as the comment to which I was replying), while yours is whether bullets can be added into replies. Sdrqaz (talk) 17:49, 18 June 2021 (UTC)

@Sdrqaz The pseudo-heading "Comments:", and in fact the entire discussion introduction above it, is treated as part of the comment you were replying to, and because of that it was treated as if it was unindented. It's not obvious how the software should behave in these cases; from my perspective it would be best if the page used a real === heading there. We have a task to track these issues: T265964.

@GKFX Currently the tool always replies using : (added to whatever indentation the previous comment had). We actually implemented it the way you suggested at first, but changed it in response to feedback from the first few wikis (T252708). Different wikis have differing conventions, and as far as we could tell, always using : is the approach which is least likely to annoy someone. This is not set in stone though, task T255841 and its subtasks discuss various proposed changes to this behavior. Matma Rex (talk) 12:50, 19 June 2021 (UTC)

== button == Currently in the toolbar (in source mode) there is an button to generate <nowiki><code> tags, but that isn't very helpful if the code I want to display is "{{some template}}". I think the code style button should probably generate <code><nowiki></nowiki></code> in one go. Users can always remove the nowiki tags in the unusual case that they want text formatting or a template transclusion within the code tag. GKFX (talk) 17:22, 18 June 2021 (UTC)

There's a similar feature request for the new wikitext editor: T157625 Matma Rex (talk) 22:00, 18 June 2021 (UTC)

My usual workaround is to type the message in the visual mode, which adds the nowiki tags automatically. This isn't convenient if you're trying to use templates in your reply (because those are blocked on a long-delayed technical RFC), but it works most of the time. Whatamidoing (WMF) (talk) 19:26, 20 July 2021 (UTC)

Repeated page-load events in Source mode

When you switch to Source mode, it looks like the page is getting extraneous javascript events as you type. For example, on enwiki, put this in your common.js:

mw.loader.load('https://tools-static.wmflabs.org/spi-tools-dev/spi/tag-check.js');

maxUsersCUStaleness = 300;

mw.loader.load("/w/index.php?title=User:Writ Keeper/Scripts/cuStaleness.js&action=raw&ctype=text/javascript");

mw.loader.load("/w/index.php?title=User:Writ Keeper/Scripts/sockStaleness.js&action=raw&ctype=text/javascript");

These are three scripts commonly in use by SPI clerks. Now, navigate to an SPI page (say, :en:Wikipedia:Sockpuppet investigations/Jinnifer, reply to a comment, go into Source mode, and start typing. The scripts will run repeatedly every keystroke or so, as seen in the attached screenshot. RoySmith (talk) 20:11, 19 June 2021 (UTC)

This is exactly what I was worried about in phab:T279141#6986316. I don’t know how exactly these scripts work, but users of the wikipage.content hook should rely on, and only on, the hook parameter; they should not use global queries (e.g. $('.myClassname')), only those that work with the content passed by the hook (e.g. $content.find('.myClassname') or $('.myClassname', $content)). Tacsipacsi (talk) 21:55, 19 June 2021 (UTC)

My javascript skills are pretty much in the "knows just enough to be dangerous" category, so yeah, I was relying on global queries, i.e.

$("span.cuEntry a[href*='/User:']").each(async function() {...}

in my wikipage.content hook. Thanks for the suggestion. I pinged the author of the other script here too :-) RoySmith (talk) 22:29, 19 June 2021 (UTC)

There's a similar issue with the marked-blocked gadget on w:en. w:en:Wikipedia talk:Talk pages project#Performance with blocked username gadget. Pelagic (talk) 01:50, 27 June 2021 (UTC)

This is happening with Hot Cat as well. See en:WT:HotCat#Doubled HotCat insertions with Reply Tool. RoySmith (talk) 15:43, 27 June 2021 (UTC)

It looks like all of the problems reported so far have been fixed:

https://tools-static.wmflabs.org/spi-tools-dev/spi/tag-check.js

I don't know where to check the revision/commit history, but the code looks like it should handle this correctly now, I assume you fixed it RoySmith? Thanks!

• w:User:Writ Keeper/Scripts/cuStaleness.js
• w:User:Writ Keeper/Scripts/sockStaleness.js

Fixed by the author:

• https://en.wikipedia.org/w/index.php?title=User:Writ_Keeper/Scripts/sockStaleness.js&diff=1029434239&oldid=935647142
• https://en.wikipedia.org/w/index.php?title=User:Writ_Keeper/Scripts/cuStaleness.js&diff=1029434185&oldid=1014995847

(Not in the ideal way – the scripts no longer use the hook, and won't run again after page content is updated without reloading – but whatever…)

w:en:Wikipedia talk:Talk pages project#Performance with blocked username gadget

Fixed by me: https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-markblocked.js&diff=1032763221&oldid=1021641704

en:WT:HotCat#Doubled HotCat insertions with Reply Tool

Fixed by me: https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-HotCat.js&diff=574182738&oldid=568234975 (although this one was not related to the use of wikipage.content hook). Matma Rex (talk) 14:29, 9 July 2021 (UTC)

tag-check.js is at https://github.com/roysmith/spi-tools/blob/master/spi/static/spi/tag-check.js I haven't updated it in several months. RoySmith (talk) 14:44, 9 July 2021 (UTC)

The version at https://tools-static.wmflabs.org/spi-tools-dev/spi/tag-check.js is different, and it is fixed (I just checked). Matma Rex (talk) 16:08, 9 July 2021 (UTC)

You fixed it in https://github.com/roysmith/spi-tools/commit/437abed9ffa4ea84ac9426770c6180becdc13f2b on the dev branch. Consider merging it into master ;) Matma Rex (talk) 16:10, 9 July 2021 (UTC)

Oh, how embarrassing :-) RoySmith (talk) 16:11, 9 July 2021 (UTC)