About the example on nl.wikipedia that @matmarex quoted:

In T305721#7841615, @matmarex wrote:

[..]

In T298371#7840142, @Marc wrote:

[..]

• See for example: https://nl.wikipedia.org/wiki/Wikipedia:Te_beoordelen_pagina's/Toegevoegd_20220406 [..]

Any temporary quickfixes for these "Articles for deletion" pages on nl.wikipedia are made in the tbp-links template. So keep that in mind while checking this example when investigating/fixing the issue.
With kind regards, Mar(c).

Setting the marker to display:inline-block appears to break something else after all. An empty inline element in front of a <div> block is invisible, but an empty inline-block element in front of a <div> block appears to cause a quite visible space. B.t.w. I'm not sure if this is only the case with <div> blocks.

• See for example: https://nl.wikipedia.org/wiki/Wikipedia:Te_beoordelen_pagina's/Toegevoegd_20220406 (large gap between the section header and the standard link collection — tested in FF, Chrome and IE; on Windows and Linux; in desktop view and mobile view; in Vector, Monobook and Minerva skins)
• Discussion (in Dutch): https://nl.wikipedia.org/wiki/Help:Helpdesk#Witregel_op_beoordelingslijsten

Is it possible to narrow the above fix to the browser/system/circumstances it is intended for?

The invisible hr element is also reported on nl.wp (and temporarily 'fixed' in the project's monobook.css).

• general styles loaded for monobook on nl.wp
• the skins.monobook.styles module, with the "MediaWiki style sheet for addressing (normalizing) browser bugs and inconsistencies" at the near-end

Ah yes, last week I noticed it works fine after the update (but forgot to mention it here). Thanks!

Thanks for the quick investigation and fix!

The inserting of 'top-level' <span data-mw-comment="..."> elements may have something to do with the issue, but that's just my guess.
See also WP:SHEIC, the technical village pump on nl.wp (so in Dutch), for some discussion leading to this ticket.

• Could something like mw:Manual:PurgeList.php offer a possible solution here? Maybe combined with some MediaWiki:Purge-list message that can be edited by the project's admins, containing a list like [[Main page]], [[Portal:...]], ... (the pages to be purged on a 24-hour interval; a fixed time would be better).

or:

• Should we just let a maintenance bot do a daily purge action? (This may be easier to execute at the same time every day, also taking DST into account.)

Would such purge solutions work well, and are there any downsides?

In T260841#6398110, @Amire80 wrote:

... It is only shown once to people who didn't enable the beta feature. ...

I assume the Thursday fix train didn't arrive this morning yet, but also assume more examples of disruptive reply tool edits are still welcome. (Or are these from another category, especially the first mentioned one?)

Some examples in article space (so not with a namespace prefix), where the parenthesized part is really a part of the subject's name:

• Hide and see(k)
• Poly(N-isopropylacrylamide)
• Cyclopentadienylindium(I)
• Kaliumhexacyanoferraat(II)
• Kaliumhexacyanoferraat(III)
• Wij Zijn Moe(dig)

I.m.o. there shouldn't be anything stripped (by default) in these links' labels. Of course, as with page titles containing a comma, if the parenthesized term (or the comma, plus what follows) is really a part of the article subject's name, and the editor doesn't want it to get stripped off, then s/he just shouldn't enter a pipe. I couldn't find any picnic/pebcak tag to add to this ticket, so if in (almost) all cases of page titles that end with [non-space](parenthesized term) the parenthesized term is part of the subject's name —also on other (e.g. non-alphabetic script?) projects— I guess this could better be excluded from the pipe trick.

(Because I'm mentioned here )
I'm aware of this since probably the early days of my wiki career, and always thought of it as a funny side effect of the pipe trick. I'm actually surprized it doesn't happen more often when people mention me, ending up shortening my username to "Mar" ([[Gebruiker:Mar(c)|Mar]]) — it happened two days ago, I don't remember any previous instance.

Since the beginning of my awareness of the Reply Tool, I use some css to style the 'reply' links. My considerations:

• a background color and rounded corners to give it a button-ish look,
• overall light colors to prevent it from being too prominently in view (too intrusive),
• a reply icon in front of the text to make it better recognizable and more easy to spot (also for languages with a very short translation of 'reply').

@ppelberg Thanks for sharing this here. In case new users shouldn't be confronted with mark-up code (like the special section linking mark-up in the summary box) too soon, that part could be left out of the text field. I updated the mockup also with empty vs prefilled with a default summary (the one I see most fit, see T254117):

I strongly oppose to inserting a snippet from the comment itself into the edit summary, for the following reasons:

1. It's not a summary of the comment, it's duplicating the same text to multiple places. I.m.o. that's a bad habit: only after reading the same thing twice you realize you just read the same thing twice (I get a feeling from it similar to the one I get from needless cross-posting).
2. It's actually cluttering the history etc. pages with a lot of text that contains hardly any information, related to the amount of text. (One of the reasons that makes Flow history pages pretty useless, i.m.o.)
3. From @Whatamidoing-WMF I got the impression (here) that inappropriate statements in edit summaries —aside from "almost all of the edit summaries for replies look useless"— might be an important reason not to add an edit summary field, or why it was never added. Using a snippet from the comment conflicts with this 'abuse prevention' argument: any inappropriate statement in the start of the comment will also be included in the —(afterwards) uneditable— edit summary. (Besides: such a reason should be part of a broader discussion and development decision about edit summaries in discussion namespaces.)

See also T258235

In T254287#6303453, @TheDJ wrote:

The Dutch wikipedia is ready and aware, they discussed it on the last VP announcement.
https://nl.m.wikipedia.org/?mfnolegacytransform=1&debug=1 Not perfect, but it will do for now.

I wouldn't recommend making secondary sort the default; that is not expected behaviour.
It doesn't look like that's the intention of the original request either. I assume it was a sorting stability issue/bug back then (and with that, I guess this ticket can be closed).

This might have an easy explanation: when using the reply tool on a diff page, after publishing the reply the updated page replaces the entire page content, including the part where the diff is shown. So in fact the vertical scroll position doesn't change, but a 'jump' of the height of the disappeared parts (diff table, diff-currentversion-title h2, probably some more elements) can be perceived.

Ah, it looks like this is basically the same as T250295 but with some expanded examples.

To summarize the reasoning I expressed here:

• no short default description like "Reply" will cover all use cases (semi-related comments, additions to previous comments);
• it looks like user-added text, which it isn't, especially because of the inability to customize it;
• with the tags, it's superfluous.

I noticed it too, on nl-wiki. As far as I could see in the short time it happened, it affected only action=history pages . The page I still have open mentions skins.vector.styles.legacy in the loaded styles:

Okay, that sounds good. I read a few tickets but apparently missed the latest developments. Thanks!

Imho, it's not "nicer for it to have a localised name", it's highly obfuscating.