Community Wishlist Survey 2019/Admins and patrollers/Smarter undo function

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Random proposal◄ Admins and patrollers  The survey has concluded. Here are the results!

Smarter undo function

  • Problem: When trying to revert vandalism or undo past edits which are problematic, there are still edits that cannot be "undone" which should be able to be undone. The software frequently refuses to use the undo function on edits that it should be able to recognize and undo.
  • Who would benefit: People reverting vandalism or undoing old, previously missed vandalism.
  • Proposed solution: I'm not very technical, but it seems to me that there should be a way to create a smarter function that recognizes better when a block of text added by an edit has no interlaced text from later edits that would conflict with removing it, without otherwise messing with the rest of the article. Currently, the "undo" function will bug out often even when the only changes to the article are to unrelated parts of the article.
  • More comments:
  • Phabricator tickets:


  • You might want to provide examples of cases you think the software should be able to handle as an undo. As it is, this seems too vague for anyone to actually do anything about. Note that to properly evaluate cases, we'd need to know both the diff being undone and the page's current revision at the time. Anomie (talk) 19:20, 30 October 2018 (UTC)[reply]
  • I believe undo is not possible when there is only one single author... Geert Van Pamel (WMBE) (talk) 09:52, 4 November 2018 (UTC)[reply]
    I think what you mean is that an edit cannot be undone if it's the first and only edit in the page. This little issue has forced me to blank talk pages created by vandals, which isn't optimal. --Felipe (talk) 10:50, 4 November 2018 (UTC)[reply]
    At least in earlier versions of MediaWiki, I could not undo my nth change of the same page as long as I was the only author... As a workaround I needed to edit the previous version, and save it again to simulate the undo. This seems to be a bug that has been solved (since longtime?). I have verified that it correctly works now on Geert Van Pamel (WMBE) (talk) 17:38, 4 November 2018 (UTC)[reply]
  • Here is an example of what (I think) the proposal is about: Clicking the undo link for this edit currently results in the message "The edit could not be undone due to conflicting intermediate edits; if you wish to undo the change, it must be done manually." Presumably because of this subsequent change within the same paragraph. I guess this is a special case of improving the automatic edit conflict resolution. Regards, HaeB (talk) 09:53, 7 November 2018 (UTC)[reply]
    It is normal that no automatic rollback is possible in this case; the same section has been subsequently edited. Therefore only manual editing is possible. The system cannot decide about what is actually wanted. — The preceding unsigned comment was added by Geertivp (talk) 09:24, 8 November 2018 (UTC)[reply]
I already mentioned and linked that subsequent diff in my comment. The point is that the system could get a little smarter in such cases. Regards, HaeB (talk) 09:22, 9 November 2018 (UTC)[reply]

Would Community Wishlist Survey 2019/Bots and gadgets/Machine readable diffs help here? If MediaWiki can generate diffs in a format it can easily understand, then maybe it becomes easier to make a finer grained undo that looks into each paragraph. MER-C (talk) 19:25, 15 November 2018 (UTC)[reply]

Agree with MER-C. The async wiki grant proposal I linked to from the machine-readable diffs discussion uses Git, which by almost all accounts does about as good a job as can reasonably be done of merging changes. If MediaWiki could do this natively, we'd all manually merge fewer edits, and all editing would be a bit faster and less frustrating. HLHJ (talk) 04:10, 22 November 2018 (UTC)[reply]
Git is actually not any better than MediaWiki, it basically merges two changes if they did not touch the same line, or neighbouring lines. That works pretty well for programming where lines tend to be the fundamental units of meaning, and it works poorly for wikitext. So one approach is making the diff algorithm non-line based - probably do some kind of sentence segmentation and then use sentences as the units of diffing. I think this is what HaeB was implying as well. --Tgr (talk) 04:52, 25 November 2018 (UTC)[reply]