The decision if an edit is a conflict or not is done in MediaWiki core and doesn't have anything to do with the extension. The task is to understand what information core provides about the conflict. Is it even possible for the extension to understand if a conflict can automatically be resolved, and how?
What we would need is a decision like "two conflicting edits have been made, both adding new text at the exact same position, without touching any existing text". Is this possible?
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | None | T213270 Possibility to use both versions of a paragraph in two-col-conflict | |||
| Open | None | T230231 Allow resolution suggestions of edit conflicts on talk pages | |||
| Resolved | None | T239792 Exploration: What data do we have to decide if a conflict can be resolved? |
The plan to suggest a automatic resolution would be the following:
We are given the Title of the page and can extract the Namespace
- create a diff between the base version and the conflicting version
- create a diff between the base version and your version
We have access to the EditPage so we can extract the base version from it and calculate the diffs above using TwoColConflict's SplitConflictMerger
- if both diffs contain one addition on the same line and nothing else, they could be auto merged by putting the newer addition underneath the older one
We also have access to the new, unsaved revision text.
If the edit is happening in a section, we have the section identifier.
As can be seen in patch https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/530148/ , if we hook in after the external 3-way merge tool, we can detect whether automatic resolution failed.
Introducing a new hook in the edit page in core would be another idea. But I think, acting exclusively in the existing code of the extension gives us everything needed. It's not necessarily important to know, if a previous three way merge failed or not.
In TwoColConf, we're at a point where there's clear that every (core-) attempt failed to resolve the issue and we can go our own way from there. It's just another special case with it's own little workflow there.
The relevant line of code in the existing code is where a new \Diff() is created and processed in LineBasedUnifiedDiffFormatter::format(). The detection algorithm would do something very similar:
That should be it. We just shared what we learned in person within the WMDE-TechWish and consider this exploration done.
Further note: