Page MenuHomePhabricator

Implement editing specific comments
Open, Needs TriagePublic


This ticket represents requirements for the initial approach we take to editing specific comments as well as the work involved with implementing it.


⚠️This list is still evolving

The following requirements. should be implemented for use by contributors to all Wikipedia talk pages on desktop web

  • Contributors will only be able to see the edit affordance on comments they have written
    • Technically, contributors will only be able to see the edit affordance next to comments signed with the username they are logged in with
  • Contributors will not see an indication that a specific comment has been edited on the talk page (e.g. there will be no "edited" indication as there is on Slack for example)
  • Contributors should not be able to edit their signature, regardless of the edit mode (source or visual) they are using.

Open questions

  • How should notifications behave when a contributor @ mentions someone new while editing their comment. See this comment for context: T246245#5976962
  • Should edited comments have a dedicated change tag associated with them? See T273611 via @Patriccck.


  • The "Open questions" above have been answered
  • The "Requirements" above have been implemented

On-wiki mentions:

  • Akoopal at
  • Valereee at
  • @Klein ($): "...I want to be able to edit my last comment because of a typo or another minor change and for that basically I have to scroll up to the top, press edit for the whole section, scroll back to the bottom again... In long conversations it gets really tiring."

Event Timeline

Last week, over chat and during Thursday's 13-February standup, we made the below decisions as it relates to the initial approach we will take for the workflow for editing specific comments on talk pages.

The below have also been added as requirements to the task description.

What rules should inform how and where the edit comment affordance is displayed on the talk page?

  • Contributors will only be able to see the edit affordance on comments they have written
    • Technically, contributors will only be able to see the edit affordance next to comments signed with the username they are logged in with

What will indicate a comment has been edited?

  • Contributors will not see an indication that a specific comment has been edited on the talk page (e.g. there be no "edited" indication as there is on Slack for example)
    • Thinking: if we were to implement a feature like this right now, it would only work reliably on comments edited using DiscussionTools, not those using full page editing. In an effort to help contributors stay focused on what they are trying to accomplish, without needing to think unnecessarily about the internals of the system, we think the implications of the action they are taking – in this case, editing a comment – should be as consistent as possible between the Replying and full page workflows.

Should a person's signature be editable when editing their comment?

  • The user experiences of the "compose" and "edit" comment workflows should be as consistent as possible
    • Thinking: consistency will help people form a clearer understanding and more realistic expectations of what the workflow can and cannot do. We worry mixing the two will lead to confusion.

Rich text mode

  • Signature should not be editable [1]
    • Thinking: We are assuming contributors using the rich text input (more likely to be Junior Contributors) will not expect to be able to affect their comment's metadata considering: 1) this information is not exposed in the "compose" part of the experience and 2) this information is not exposed in the editing workflow on similar sites (e.g. Github [2] and Gitlab [3])

Source mode

  • Signature should not be editable [1]
    • Thinking: Exposing the signature could lead contributors to become confused about how auto-signing works and when it is triggered leading to confusion and potentially, frustration.

  1. This functionality will require some enhancements to the parser which are being worked in this task: T245220
[2] Github[3] Gitlab
Screen Shot 2020-02-17 at 1.56.19 PM.png (578×1 px, 132 KB)
Screen Shot 2020-02-17 at 1.55.52 PM.png (624×1 px, 64 KB)

I'm copying a comment from a subtask, about signatures not being editable:

This seems like a poor idea. If you cut the editable range short, they can't append after the signature. We don't usually do that for quick spelling/grammar/link fixes, but major or late changes will often get an appended second signature and possibly a note of what major change was made. Also any attempt to identify the start of the signature will be a guess, and guesses which are wrong will produce very odd behavior for the affected users.

I looked up our internal discussion from 13 February and we actually considered this, but decided that "supporting that use case would be more complex, as we'd have to let people insert content after the signature". (I'm not really convinced if that's true, I'd have to think about it more.)

Also, comments like this (with multiple signatures) can exist on pages if they were added using the normal wikitext editor, and we already support replying to them (T240640). When we implement editing, editing such a comment will open the edit box with the signature in the middle, and no signature at the end, which would be pretty confusing (although, admittedly, comments like that are somewhat rare).

My proposal for handling signatures while editing:

  • In source mode, the signature(s) should be visible and editable as normal
  • In visual mode, the signature(s) should be visible, but treated as a focusable node (basically, you can't edit inside of it)
    • Kind of similar to how mentions are treated in Flow now (and how we'll probably treat mentions in our visual mode too)
      image.png (496×1 px, 42 KB)
    • Visual editor already has partial support for signatures: it can insert them (this is only enabled in some namespaces on some wikis, try e.g. on – but it couldn't parse them in existing pages, because a signature is just a link and some text
      image.png (155×923 px, 19 KB)
    • But we have a parser that detects signatures, and we should be able to use the signature ranges it reports (T245220) to also parse signatures in our visual mode
  • In both modes, if the user removes every signature from the existing comment, add a new signature
    • Removing the signature is never a good idea, and probably indicates the user is confused or did it accidentally, but we can't really prevent it…
    • We must ensure there is a signature, otherwise it would become impossible to edit/reply-to this comment using our tool, because it would no longer be detected as a comment
    • (Maybe investigate if we actually can prevent the user from removing the signature(s), that would probably be better if it is possible)

@matmarex I think you should reconsider how you're conceptualizing the product. We're not building a discussion system, we're building a convenience-tool for wikipages. Consider your points here:

  • We must ensure there is a signature (because reason)
  • Maybe investigate if we actually can prevent the user from removing the signature(s)

The rationale for the constraint is irrelevant. Constraints-based reasoning does not hold for this product unless you're planning to enforce those constraints in full page edit mode as well.

@Alsee I don't see how the behavior of full-page editing is relevant here. We are not changing how it works.

We're building a tool to post or edit comments. If you need to do something other than posting or editing a single comment, you should use the full-page editing interface. I thought that was obvious, but perhaps it was not.

Making it possible to remove a signature in a comment would mean corrupting pages, and we're committed to not causing page corruption.

@matmarex first note that I'm not actually taking any position here on how the product should work in this case. I'm talking about how we reason about the design. Discussion Tools is a parallel option for posting and editing comments. Any rationale for how Discussion Tools will work should be based on what makes sense for the product given that attempted constraints do not actually hold.

Making it possible to remove a signature

It is possible. Given that it is possible, does it make sense for the new tool to lack that ability? Maybe, but not based on an "it should not be possible" rationale. Any deliberate limitation or constraint in the product should be considered in terms of "Would the product be better if we force users to go full-page-edit to do that?"

Development update: 17-March
@Alsee + @matmarex, considering I don't have anything to add to y'alls conversation at this moment, I'm going to sidestep what you have been discussing to share the following update:

For the time being, we are going to pause development on the new workflow for editing single comments on talk pages.

More details here: T242562#5977993

Disassociating this task from T245221 as editing specific comments is no longer functionality we plan to deploy as part of "Version 2.0" of the Reply tool.

ppelberg updated the task description. (Show Details)

I just noticed this task. On the one hand, I agree that the tool should not allow removing the signature—yes, removal is always possible using full page editing, but if the tool doesn’t allow it, the chances of accidentally removing the signature are much lower. On the other hand, just stripping it from the end and putting back on save isn’t going to work:

  • There may be a signature in the middle. That can’t be stripped, how would you handle it?
  • Even if the signature is at the end, it may not be preceded by the current content of discussiontools-signature-prefix (either because the message changed in the meanwhile, or because the user originally typed the tildes manually—e.g. I usually type – ~~~~, where the space is U+00A0 NO-BREAK SPACE, not U+0020 SPACE as in the message). Just stripping and putting back will change the prefix from U+2013 U+00A0 to U+2013 U+00A0 U+0020, i.e. there will be two spaces (and because one of them is a non-breaking one, actually two spaces will appear). If you strip just the signature itself but not the prefix, it’s quite likely that someone appending a new sentence to their comment will not leave an extra space at the end, just like they’re not supposed to do this when posting a new comment.
  • Also you should consider that a signature is not a static thing. The timestamp part is almost certainly different from (older than) the timestamp ~~~~~ would generate at the time pre-save transform happens during saving the edit. Which is actually something the user may want to take advantage of (e.g. if they update their comment just after publishing it, they might want to update the timestamp as well), but probably most of the time wants to avoid.