Talk:Talk pages project/Replying

Complete signature required

This has probably been aked before, but I do not know how to search among the topics:

When answering using "Edit source", and manually signing, the reply-link is only added if four tilde is used. If three tilde or five tilde is used the signature will lack time stamp or only be time stamp respectively.

Is this on purpose? There must be very few scenarios where three or five tilde is not also an attempt to be a signature, and never as final letters. LittleGun (talk) 13:13, 10 March 2024 (UTC)

The whole data structure is based on the assumption that every comment has an author and a date. If only three tildes were used, it’s impossible to determine the date reliably; if five tildes were used, it’s impossible to determine the author reliably (remember that comments don’t stay forever where they were placed, they may be moved, archived etc., so using the page history is not reliable). Placing {{Unsigned }} after a such comment (with both author and timestamp filled) will make the reply link appear, which can be used to fix these incomplete signatures. —Tacsipacsi (talk) 20:49, 10 March 2024 (UTC)

Ping or no ping?

Source: Using the automatic dropdown from typing "@" results in "@[[User:User|User]" being shown, from what I understand, manually typing this wouldn't result in a ping, so I think it's confusing. EnTerbury (talk) 15:22, 4 April 2024 (UTC)

@EnTerbury: It will result in a ping, I believe; this edit should be an example of that. Jdforrester (WMF) (talk) 15:52, 4 April 2024 (UTC)

Leaving the browser

Hello, I use the Firefox browser and have the following problem in de.WP. When I double click on a word in order to create a link, then the browser asks me if I want to stay on the page or leave it loosing the content that I have entered. Thanks to the browser, I don't just leave the page (unintentionally) but can click on "stay on this page". - I have just noticed that this happens to me on de.WP, but not here on the mediawiki.org-wiki. 77.164.32.65 07:41, 1 May 2024 (UTC)

Unwanted nowiki tags

Something that happens very often: I paste an external URL into square brackets and add text for the link, and the reply gizmo silently wraps the whole thing in nowiki tags, which is evident in the preview but not in the source, despite being in "source" mode. There's a noticeable pause while it does the necessary malicious processing to cause this unwanted effect. Cutting and repasting makes no difference, it's still nowiki'd, like invisible tags came with it. What does work is to delete the link, tab away in the browser, copy the URL again, tab back, ''allow the edit to reload'' (seems crucial) and paste the link all over again: with luck, I won't get nowiki tags the second time. Edit: the apparent quote marks in that sentence were supposed to be italics, but they got nowiki'd! It's happening again! Card Zero (talk) 18:24, 13 June 2024 (UTC)

Which browser, how did you copy the link ? Are you copying a link from an article, or from the browser url, or by right clicking a link and choosing copy ? etc etc. —TheDJ (Not WMF) (talk • contribs) 19:57, 13 June 2024 (UTC)

Reply formatting

Would it be possible to tweak how indenting is handled? The current format breaks how indenting is handled on CFD. See [1] for a recent example of how my reply doesn't align with the typical formatting. Smasongarrison (talk) 15:53, 22 September 2024 (UTC)

Currently no. This is tracked as phab:T259865. Nardog (talk) 03:05, 23 September 2024 (UTC)

Issues

I don't know if it's better to report this directly only on phabricator or here or whether this is already tracked (if so this could be archived):

• When somebody screwed up intendation, ie with the source editor added a reply without intendation (same layer as original post), then it puts the reply above that comment that misses intendation when using the Reply tool instead of putting it at the bottom. I hope it's clear what I mean. It should put the reply in the correct layer at the bottom and maybe it could even fix the intendation of other comments.
• The reply button is missing in empty sections. I'm not entirely sure what I meant with that or which problem I had where the button was missing but I think e.g. here there should also be a reply button in those sections that only have a header so one can use the Reply tool for replying instead of the source editor.
• It would probably be great if you could add a button to mark a section as solved to the options (see c:Template:Section resolved).
• People often if not usually use a bullet point in deletion discussions. With the reply tool it moves the signature to a new line. Please enable that the signature can also be put into the same line somehow. Example solution: if a comment only has one bullet point but not multiple it should not add a newline at the end.

Prototyperspective (talk) 22:23, 24 September 2024 (UTC)

Also included the request for a mark as solved button in meta:Community Wishlist/Wishes/Do not fully archive unsolved issues on Talk pages. There's further issues (I'll add some below). If there's no phab issues for these I intend to submit code issues there later since I hope this could be moved from beta to become the default way people reply on talk pages with few exceptions.

• When using <gallery> it shows correctly in the preview but screws it up when publishing due to the intendation. See e.g. c:Special:Diff/949550947.

Prototyperspective (talk) 17:32, 26 October 2024 (UTC)

• When using templates it can add double dots : example (here is the change to how the reply should have looked like).

Prototyperspective (talk) 01:53, 6 March 2025 (UTC)

Community Wishlist request with more: Wish:Fix the issues breaking the Reply tool. Prototyperspective (talk) 12:05, 15 May 2025 (UTC)

Inconsistency of the Reply button

In the Discussion Namespace, the Reply button is a bold blue "Reply", but in the Wikipedia Namespace (for example this page) the button becomes [ reply ]. A member in the Vietnamese community wants to ask about the reason of this inconsistency and wonder if we can make them the same button. Thank you very much. Bluetpp (talk) 09:47, 28 September 2024 (UTC)

The technical reason is that the bold button is part of the so-called usability improvements, and usability improvements are enabled in non-talk namespaces (including the Wikipedia namespace) only if either __NEWSECTIONLINK__ or __ARCHIVEDTALK__ is present on the page (or both, but that doesn’t make much sense) – the mere presence of a comment doesn’t enable them. (Notice that vi:Wikipedia:Thảo luận, which is also in the Wikipedia namespace, but does have __NEWSECTIONLINK__, has the bold buttons.) I don’t know why it works this way, but maybe because signatures can also appear in policies and guidelines as examples? Also, it would likely be mostly uncontroversial to make the buttons bold everywhere by default, but the different styling of the headings and the lack of metadata (number of comments, last comment etc.) would remain. —Tacsipacsi (talk) 20:46, 28 September 2024 (UTC)

Feedback on reply interface

There's a bit too much going on with the reply widget for experienced editors.

• I wish there was a preference to only use the source editor and not display the headerWrapper.
• I don't think the advanced toggle is necessary, or at least I wish the toggle could be disabled to always leave the advanced controls open. It takes up vertical space and pushes the edit summary box downwards, making it more likely that it's below the visible area of the screen.
• I wish there was a master preference agreeing to CC licensing so I don't need to see the notice for the ten-thousandth time. The notice also takes up vertical space.
• I found the "Preview" ::before text unnecessary, but I get that it's probably generally necessary.
• The borders for the preview and advanced sections should probably be the same, something a bit less bright, but not too bright (in dark mode).

To summarize:

    div.ext-discussiontools-ui-replyWidget-headerWrapper,
    span.ext-discussiontools-ui-replyWidget-advancedToggle,
    div.ext-discussiontools-ui-replyWidget-actionsWrapper p {
        display: none;
    }
    div.ext-discussiontools-ui-replyWidget-preview::before {
        content: "";
    }
    div.ext-discussiontools-ui-replyWidget-preview,
    div.ext-discussiontools-ui-replyWidget-advanced {
        border: 1px solid var(--border-color-base) !important;
    }

Thanks for all of the work on the interface. Daniel Quinlan (talk) 05:20, 2 October 2024 (UTC)

How can the "rich formatting" popup be disabled?

I'm in the source editor and editing a template. I clearly don't want "rich formatting". This is the popup in question. Daniel Quinlan (talk) 05:50, 3 October 2024 (UTC)

Mangling of preformatted text

Whenever I use the "pre" or "code" or similar tags in a comment reply, the output is mangled, as in this edit. The simplest way to fix this is to go back in and manually remove the leading ":"s from each line. Though this is not great for indenting, it's better than unreadable code. (I'm sure a fix for the indenting could be whipped up, though for preformatted blocks maybe it's best to give them the whole screen width?) -- Beland (talk) 18:57, 5 December 2024 (UTC)

Add "Reply to thread" button

Right now there's no way to reply to a thread, just the individual comments in the thread. This can be a huge pain for long discussions, where replying to the discussion requires scrolling all the way to the top of the thread to reply to the original comment. Could we get a button for this, like the "reply to section" button in Convenient Discussions? Thanks! —Closed Limelike Curves (talk) 18:38, 7 January 2025 (UTC)

Cancel button looks like a dead link

Currently, the “Cancel” button has no border and looks identical to a dead link, which implies an unimplemented feature. Northern Moonlight (talk) 22:32, 19 March 2025 (UTC)

It's a standard "quiet destructive" button per our design system, Codex: [2] and I agree that the design where the buttons lack visual indication that they are buttons is unfortunate; I have complained about this before in T336676. That said, in the context of the reply tool, I hope that such confusion would be unlikely – the placement of "Cancel" next to "Reply" should indicate that it is also a button, and I have never seen anyone think that red buttons imply unimplemented features, even though they look like red wikilinks (a disabled button might imply that). Matma Rex (talk) 15:02, 21 March 2025 (UTC)

Inappropriate activation

I happened to look at the page history of a page on which I had an open pending reply. I was just looking at some diffs, but these also display a copy of the page as it was. This caused the "resurrect saved but unsent reply" feature to open a comment dialog box in the old versions and IIRC scroll to it. At some point, I think I submitted the comment but still had other tabs open. But because they were looking at older versions, it looked like the comment hadn't been submitted, and I nearly submitted it twice. This feature should not activate when looking at non-current versions. -- Beland (talk) 12:26, 2 May 2025 (UTC)