Help talk:Paragraph-based Edit Conflict Interface

About this board

Feedback and discussion page for the Paragraph-based Edit Conflict Interface.

Update: We completely revised the interface for this feature based on user feedback and user test.

Report a new bug in Phabricator

You can post in any language here, preferably English or German.

FeRDNYC (talkcontribs)

When using the "Night" site interface (the dark-mode skin), the "tour" popup labeled "Diverging changes are shown line by line." contains black-on-dark-gray text below that initial heading line (which is rendered in white). No idea if any other interface elements are similarly affected.

I'll also report this over at Reading/Web/Accessibility_for_reading/Reporting/en.wikipedia.org, but presumably it isn't limited to enwiki at all. It's also one of those rare dark-mode issues that can't be fixed with a content tweak, since it's actually an interface bug.

Reply to "Dark mode issue"

Is it possible to force the conflict interface to open?

3
KaiKemmann (talkcontribs)

In the beginning the interface would often open without any actual reason.

This seems to have gotten a lot better now and the tool has been very helpful to me many times.

I often keep an editor box open for several days and work on the content while in the meantime other editors save changes to the article as well.

The tool does not seem to realize this every time and often will not open.

This leads to two obvious questions which are not answered on the Help page:

  • How does the tool figure out whether an edit conflict might be about to happen? Does it actually know that a new version of the article was saved by another editor while I was typing in the editor box on my computer?
  • Would it be possible to force the interface to open when I already know that the source text was changed while I was intermittently editing the text in my browser over a longer period? many thanks, ~~~~
Thiemo Kreuz (WMDE) (talkcontribs)

Thanks a lot for the nice words. TwoColConflict relies on the existing conflict detection mechanism in MediaWiki core. It remembers the "base revision id" of the revision that was used to start the edit, checks if there is a more recent revision, and if the two happen to touch the same paragraphs. No, it's not possible to enforce this process. You have to click "Publish changes" and see what happens.

In case you want to play around with the feature you can open an anonymous browser window where you are not logged in (or logged in with a second account) and do slightly different edits to the same page (ideally a sandbox page) in the two windows. Whoever saves first wins, and the second one runs into an edit conflict.

FeRDNYC (talkcontribs)

The "if the two happen to touch the same paragraphs" point is probably the pivotal aspect. Many times, someone editing "over" you doesn't result in an edit conflict, because they edited some completely different part of the page that your edits don't also touch. There's no need for the conflict resolution interface to open in those cases, so it doesn't. Actual edit conflicts are (thankfully) pretty rare, no matter how long an edit has been in progress or how many times the page has been modified since it was started.

Reply to "Is it possible to force the conflict interface to open?"

Interface appearing for no reason

1
Samoasambia (talkcontribs)

Hi. Just a quick note that I just got the Edit Conflict Interface displayed for this edit reverting vandalism on a talk page. Not sure what happened there. Interestingly the edit had went through without me taking any action on the interface.

Reply to "Interface appearing for no reason"

Interface for discussion conflicts is great

4
Wugapodes (talkcontribs)

I really liked the new edit conflict interface (the one with the radio buttons), but even with that, edit conflicts in discussions were still a pain. It was great for articles or editing the same text, but when adding to a discussion, I found myself, more often than not, just reopening the edit-interface and adding my text again because it was easier. I just got this new paragraph-based interface and it's amazing. I'm really excited about this feature and am thankful to everyone who is working on it!


My only suggestion is to add more helpful tooltips or labels. Having seen the previous radio-button interface, this one confused me a bit and it took me some time to figure out what would happen when I hit "publish". I think RoySmith gave a more detailed description below which was similar to my confusion. I remember when I first got the interface with the radio buttons that there were blue dots that were part of a tutorial or something? Could those be reintroduced?

Seewolf (talkcontribs)

+1

Max Klemm (WMDE) (talkcontribs)

Hi @Wugapodes:, thanks for your feedback. We are glad to hear you like the new interfaces.

Currently, there are no blue buttons in the talk page edit conflict interface, but we will take your feedback into consideration and see how we can improve the tooltips and help text as we roll out the interface to more wikis.  --For the Technical Wishes Team

138.19.149.125 (talkcontribs)

+1

Reply to "Interface for discussion conflicts is great"
Robert McClenon (talkcontribs)

I from time to time get the Edit Conflict message, but find it to be completely useless. It doesn't tell me whether it will be preserving the other editor's edits and adding mine, or what my choice is. How do I attempt to add my edits while ensuring that the other editor's edits are preserved? It doesn't give me useful information.

~~~~

Skarmory (talkcontribs)

For me, it gives two source views, like in a diff, and you can analyze the two versions there and pick a version or edit a version to include parts from both. I suck at reading the source code and scanning for what's different, but on bigger edits it is very noticeable.

Reply to "Useless Display"

Extension Failed to Work

4
Zorua Fox (talkcontribs)

When I use this extension on my wiki, i got such errorlog:

VM2235:956  Uncaught TypeError: Cannot read properties of undefined (reading '$ui')
    at RealtimePreview.isScreenWideEnough (<anonymous>:798:893)
    at <anonymous>:793:1381
    at Object.add (<anonymous>:956:537)
    at realtimepreview/init.js (<anonymous>:793:959)
    at runScript (load.php?lang=zh&modules=startup&only=scripts&raw=1&skin=citizen:12:268)
    at Array.<anonymous> (load.php?lang=zh&modules=startup&only=scripts&raw=1&skin=citizen:12:948)
    at flushCssBuffer (load.php?lang=zh&modules=startup&only=scripts&raw=1&skin=citizen:4:956)
Thiemo Kreuz (WMDE) (talkcontribs)

That's an error message from the WikiEditor extension. I can't tell how this is related, sorry. Maybe you need to update that extension first? What was on screen when this error appeared?

Zorua Fox (talkcontribs)

Thanks for the reply, but this is the only error I saw when the issue occurred, and nothing seems to be happening on my backend (including the Nginx logs).Besides my wikieditor is already up to date.

This post was hidden by Zorua Fox (history)
Reply to "Extension Failed to Work"

Unable to figure out how to use feature

4
Danbloch (talkcontribs)

Feature showed my addition with a check and an "X". I clicked the check. I then clicked "Show preview" and nothing happened. I then gave up.

Thereza Mengs (WMDE) (talkcontribs)

Hey @Danbloch,

we tested the feature on deWiki and it worked. In order to solve your problem, could you please tell me which page you were trying to edit? And if possible also send a link to the diff of the change you were making? We will then try to solve your problem or figure out why it occurs and get back to you.

Danbloch (talkcontribs)
Thereza Mengs (WMDE) (talkcontribs)

Hello @Danbloch,

thank you for the details and information. We have reconstructed your problem and indeed found that the interface seems to fail scrolling to the preview part when clicking the "Show Preview" button. Many thanks, for your awareness and your comment! We have created a Phabricator ticket to resolve the issue. You can also follow-up the next steps there.

Reply to "Unable to figure out how to use feature"
Liz (talkcontribs)

For some reason, this "tool" posts my comments duplicate times, as if I have an edit conflict with myself. I then have to go back and remove the excess comments from the page. This has happened more often than not with this tool. When I have a chance, I'll try to figure out how to disable it.

Thiemo Kreuz (WMDE) (talkcontribs)

Thank you for the report. Unfortunately, I'm not sure what kind of response you expect? Are you able to post some example links where this happened? That would help a lot investigating this issue further. So far it sounds like a long known issue with the edit conflict detection algorithm in MediaWiki core, which is what TwoColConflict depends on. See for example phab:T28821, phab:T36423, phab:T59264, or phab:T222805. TwoColConflict is essentially just an interface on top of that.

Liz (talkcontribs)

Well, when the Beta feature pops up, I get a message to come here to offer feedback so that's what I did. I don't know if I have expectations, I just followed the suggestion to come here and post.

You can see one example of this if you look at my contributions and look at the posting to WP:ANI at 21:03, November 5, 2021. It posts twice in the same moment and the next edit I delete the duplicate entry.

Thiemo Kreuz (WMDE) (talkcontribs)

I would love to do something about this. Let's see. There are two edits, the first at 04:03:14 UTC, the second 27 second later. That's not exactly the same moment. Furthermore, the second edit is marked as a revert. Why is that?

KaiKemmann (talkcontribs)

This happens to me several times a month.

I encounter these "Edit conflicts with myself" when I try to edit my previous edit shortly afterwards to correct some mistake or other.

It is often not possible to choose between different versions (as there are no check boxes or rather check circles offered) so the obvious option is to click "publish" which results in the corrected text passage being appended to the one added in the previous edit.

See here where I tried to correct a small spelling mistake in my previous edit when the "Edit conflict" interface popped up ...

This post was hidden by TMg (history)
Reply to "Argh!"
Robert McClenon (talkcontribs)

The edit conflict interface doesn't indicate whether forcing one's edit through will preserve the edit by the other user or will wipe out the previous edit. Since it doesn't say that the previous edit will be preserved, I have found it best to temporarily save my edit, and back out from it, and apply it again. If the edit conflict interface is meant to preserve the other edit, it should say so. ~~~~

Chris troutman (talkcontribs)

I have the same problem, which is why I'm dropping this gadget. Preventing an edit conflict should make clear about where my comment is going and this interface has never successfully done that for me.

Reply to "Vagueness of Message"
JanB46 (talkcontribs)

Ik gebruik deze ongevraagd verschijnende mogelijkheid liever niet en beschouw hem dan ook als een vervelend obstakel. JanB46 (talk) 06:03, 7 April 2024 (UTC)

PETEROYALASCIIANCE (talkcontribs)

well written matrix .

Reply to "Liever niet"
Return to "Paragraph-based Edit Conflict Interface" page.