Last modified: 2014-11-20 09:11:51 UTC
Steps to reproduce: User A and User B are editing section 5 of article (probably discussion page) X. User B finishes their edit, and it goes through. User A, however, is still working on his edit. He finally finishes and submits, but there's an edit conflict. Expected Results: Edit screen comes back on, showing just the section and edit conflict info. Actual Results: Edit screen comes back on, showing *entire* article and edit conflict info. This is quite annoying on discussion pages, because they can get long, they can get lots of edit conflicts, and if you suddenly have to edit the entire page, you've got to find the section again, and then edit it. Possible problems fixing it: This is likely an approach that helps prevent strange things from happening when section are reordered/added/deleted. In order to keep the current behavior in these cases, we would have to know whether or not edits changed the section layouts. This would require a new database column unfortunantely. An alternative solution, likely a feature request, is to have display only the edit conflicting sections in the edit box, making it irrelevant "where" on the page the edit is. This would likely merit a different bug.
This would require additional testing after the merge attempt to check if changes were only made within the matching section. Probably doable.
*** Bug 8644 has been marked as a duplicate of this bug. ***
As mentioned in the description, this is a particular issue on high traffic pages, such as the English Wikipedia's Help Desk (http://en.wikipedia.org/wiki/WP:HD). Users asking new questions as well as those answering them both cause edit conflicts, and with the size of that page, the chance for further edit conflicts, as well as the time needed to save the new version, rise exponentially. Definitely in support of this fix.
Also want to voice my support. I think this is an important issue. The current edit conflict page is pretty much useless on pages that exceed a certain size -- goes for most talk page. Completely useless on village pump pages, ANI, etc. It doesn't seem like a very complicated fix either. Combined with the fact that it's probably the most frequent issue on Wikipedia, this bug should be a high priority.
I'm stepping up the severity and priority on this. This problem has existed for a long time, and with the increased participation and rapid edits at long pages like WP:ANI, a fix for this problem is sorely needed and would really increase our productivity.
To avoid expanding to full-section editing, we need to be able to determine that we're only looking at the "same" section. Can we really do that reliably? original: a b c editor: a b' c current: a b'' c'' Here, we want to display b' vs b'', which seems relatively straightforward. Extract the same section number from the new text, and ignore the other sections. But consider the case where we add or delete a section, changing the numbering: original: a b c editor: a b' c current: a d b'' c Using the section numbers, we'll match the new section d with the editor's b', which won't be at all what we want. How can we reliably locate b''? We could attempt to match on section titles, but what happens when we have duplicate titles, or the title is changed during the edit?
I don't think the algorithm has to be perfect--it just can't do anything *wrong*. For example, if the sections are reordered, as long as the titles and the text contents are the same, the algorithm can try to be smart and track the new section, but if the titles and text change, I don't think it should bother. Let's consider WP:ANI. This page exemplifies the type of discussion board style that is pervasive throughout Wikipedia, and is exactly why better section edit conflict resolution is needed. There are three types of edits to these sorts of articles: 1. Section edits 2. Section addition 3. Global edits (we'll take this also to mean reordering, splitting, renaming etc) I don't think we should attempt to be smart if a type 3 edit happens. However, type 1 and 2 are very easy to identify, and account for the majority of edits to these types of pages, so if we just limit ourselves to these, we could have a workable problem.
Agree with Edward -- This fix doesn't need to be perfect. The "old" conflict screen (the one in current use), which displays the entire page for editing, can be used as a failsafe, or default, if the section can't be determined accurately enough. Given a page like ANI, improving the conflict resolution for the cases Edward has identified as types 1 and 2, would basically take care of 90% of the conflicts that occur there. And probably anywhere else.
A simple heuristic: check that the title is is the same and the hierarchical section number (the one shown in the TOC) is the same. This would catch section edits except the ones changing the title (which it probably shouldn't), and section additions excpet the adding of a same- or higher-level section before the current one (which is rare on large talk pages where most conflicts occur).
We could also parse (nothing fancy, just use the Parser class) the original revision and the conflicting revision, and see if and how their section trees differ. This'll easily identify type 1 and certain cases of type 2 (specifically, appending a section) from comment #7.
I support the proposal but do not have the expertise to comment on the technical aspects.
This problem can be responsible for deleting comments if there is a conflict with a second bug: A not recognized edit conflict. If you're doing an edit on the edit conflict page, you're editing not a section but the entire article. While editing one more edit conflict can happen with another user editing only a section. Sometimes it happens that MediaWiki don't recognize an edit conflicts. If so, than it could happen that the (meanwhile saved) edits from the other user could be overwritten with the old version of page in the edit conflict page and the edits getting lost. So it happens today: http://de.wikipedia.org/w/index.php?title=Wikipedia:Auskunft&diff=next&oldid=89518222 Previous I had three edit conflicts so that I was editing on the edit conflict page. Meanwhile a user had saved another comment and so he was creating my fourth edit conflict. But MediaWiki didn't recognize this. So as I was saving my new edited edit conflict page, and the edit of the other user (in another section) gets lost. This problem could be solved by two solutions: 1. If the edit conflict page shows only the relevant sections or 2. If edit conflicts would be solved more reliable (is there a bug report for unresolved edit conflicts?).
Just came to Bugzilla to report this problem myself and found this (actually very) old bug. It seems there was quite some interest in the bug back then and this is still a detrimental issue on highly frequented talk pages, so a solution would be highly welcome. The suggestion to check if the section title didn't change between edits and to fall back to the current behavior otherwise sounded quite promising. It would still cover most of the edit conflicts and is maybe not too complex to implement after all?
The full-page preview has been recommended as the "guaranteed" latest revision to revise and edit-save. It has been intended to still auto-merge with any non-adjacent lines, which other editors might continue to update, auto-combining the "best of both" the section re-edited plus any recent changes to other sections in the full-page text. Note a common type of full-page edit-conflict is the deletion (or "archiving") of the section above the final section, and that deleted section cannot be represented by another section-only preview (as: How is a deleted section represented, except by omission from the full-page text?). I guess this is the major point: when a section-only edit fails, then OFTEN the full-page structure has been altered by omitting, or adding sections, as perhaps most clearly shown by the full-page text. However, do not despair, because if more edit-conflicts were auto-corrected, then the size of the edit-conflict page would not matter as much (as being only rarely seen). Again, explanation: when a section-edit hits edit-conflict, then the problem is often deletion/addition (or renaming) of nearby sections, which are best shown by displaying the latest full-page text, with all current sections listed in consecutive sequence, for the proposed changes to be hand-merged into the new structure. -Wikid77
