Jan 9 2021
Dec 27 2020
Ah yes, last week I noticed it works fine after the update (but forgot to mention it here). Thanks!
Dec 15 2020
Thanks for the quick investigation and fix!
Dec 13 2020
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.
Dec 12 2020
Sep 18 2020
Aug 24 2020
- 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).
- 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?
Aug 20 2020
Aug 13 2020
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?)
Aug 4 2020
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)
- 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.
Jul 21 2020
Jul 20 2020
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').
Jul 18 2020
@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):
Jul 17 2020
I strongly oppose to inserting a snippet from the comment itself into the edit summary, for the following reasons:
- 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).
- 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.)
- 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
Jul 14 2020
Jun 9 2020
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).
Jun 8 2020
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.
Jun 2 2020
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.
May 28 2020
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:
Mar 16 2019
Mar 13 2019
Jan 7 2019
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.