WeRelate:Suggestions/Change handling of edit conflicts

Edit conflicts don't happen often, but presumably more so as more users are added. The edit conflict screen is very hard to use, resulting usually in the need to throw away the conflict screen and completely re-enter one's edits (and it is usually the longer, more involved, edits that get to the conflict screen, not the quick, short ones). Some of the reasons for this is that one's own edits are shown in raw XML that cannot simply be copied into the edit screen. If you add a source, you cannot simply copy the entire source entry, you must do it field by field, carefully grabbing the data and not including the keywords and punctuation. If there is any wiki formatting in the source text, it will have been converted to HTML and needs to be converted back (i.e., " to &quot;, <sup> to &lt;sup&gt;, etc.

It would much more useful to have a conflict screen that looks like the one used in the merge process, where the saved version is shown on one side, and the aborted edit on the other side, and the parts of each may be selected by checking the boxes desired as happens in the merge process.

Of course, any alternate approach would be acceptable that relieves the need to read, parse, and copy raw XML as the only way to re-use the pending data of a conflicted edit. --Jrich 10:23, 3 August 2012 (EDT)

Reiterating the need for such a change. The current method of handling this penalizes the "loser" by presenting their unsaved data as xml so that it cannot be copied and pasted into a fresh edit. This essentially requires re-typing EVERYTHING FROM SCRATCH for any kind of source citation or any edit using anything but straight unformatted text. I have often re-typed in my changes multiple times only to have an edit conflict reported EACH TIME because somebody is doing lots of small edits, fixing typos, or playing with spacing, instead of one comprehensive change. --Jrich 23:44, 5 April 2017 (UTC)