Jump to content

Talk:Talk pages project/Replying

From mediawiki.org

Former discussions are available at Talk:Talk pages project/Replying/Flow.

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

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

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply