Page MenuHomePhabricator

Comment parser should report range of comment and signature separately
Closed, ResolvedPublic

Description

Currently the parser only returns a range covering the whole comment including the signature. For comment editing we would like to separate the signature from rest of the comment body.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 13 2020, 11:14 PM

I avoided implementing this because identifying the beginning of the signature is difficult. Currently parser#findSignature kind of detects the location of a signature, but actually it only returns nodes beginning with the first link within the signature. This was sufficient for the debug mode (?dtdebug=1), but probably isn't good enough for anything user-facing.

I think we need to handle various little "prefixes" users have before their signatures, like "--" or "—". Otherwise they will appear at the end of the actual comment when editing, and will look silly. (Screenshot from https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Many_auto_edits_and_account_risks)

In particular "--" is encouraged by the signature button on the old wikitext toolbar, which inserts --~~~~. (Don't ask me why.)

We discussed today possible approach for auto-detecting non-word characters. I think making too many characters editable is preferable to making too few characters editable so I would err on the side of only including characters we are sure belong in the signature, so probably just hard-coding -- to begin with, or doing nothing.

Alsee added a subscriber: Alsee.Feb 20 2020, 12:12 PM

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.

@Alsee I'll copy your comment to T245225: Implement editing specific comments, that's a better place to argue about how editing comments should work (and you have a point here).

Even if we don't use it for editing comments, having the ability to separate the signature+timestamp from the comment would still be useful, e.g. for time/date formatting (T240360) or for reformatting the signatures (we have no plans for this right now, but there are existing tools like https://en.wikipedia.org/wiki/User:Kephir/gadgets/unclutter).

matmarex renamed this task from Comment parser should report range of comment and signature separately for comment editing to Comment parser should report range of comment and signature separately.Feb 27 2020, 12:10 AM

Change 576894 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] parser: Return signature and timestamp ranges

https://gerrit.wikimedia.org/r/576894

This patch only exposes the data we already have, it doesn't solve the problem with "prefixes".

Change 576894 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] parser: Return signature and timestamp ranges

https://gerrit.wikimedia.org/r/576894

ppelberg added a comment.EditedMar 18 2020, 3:32 PM

This patch only exposes the data we already have, it doesn't solve the problem with "prefixes".

@matmarex, does this work have a task already or is one needed?

There isn't a task, but I don't think we're planning to work on that, so I didn't file one.

I don't think we're planning to work on that, so I didn't file one.

Got it. Would it be responsible for me to assume support for prefixes is not required to implement editing specific comments?

ppelberg closed this task as Resolved.Mar 27 2020, 2:26 AM
ppelberg claimed this task.

Yes. Either the signature prefix would be included in the editable comment text, which isn't ideal but it shouldn't be a big problem, or we could just include the entire signature in the editable text, which also should be fine.