Help talk:Two Column Edit Conflict View

Feedback and discussion page for the Two Column Edit Conflict View.

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.

das werkzeug ist schrecklich, wenn ich in den konflikt einfach manuell lösen will.

wie komm ich da wieder raus?

wie kann ich _nur einen_ von mehreren blöcken anders auflösen als durch pores überschrieben?.

wieso beschränkt sich das tool nicht nur auf _den_ abschnitt, den ich bearbeitet habe, wie das die alt versionsansicht schon konnte.?

Hi@W!B::, du kannst die Oberfläche in den Einstellungen abschalten. Dann kommst du zur vorherigen Ansicht zurück. Es sollten nur Textabschnitte, die sich unterscheiden, nebeneinander angezeigt werden. Du kannst diese bearbeiten, indem du auf das 'Stift- Symbol' in der rechten, oberen Ecke des Textfeldes klickst. Die Textabschnitte, die gleich sind, sollten über die volle Länge der Seite in grauen Kästen angezeigt werden. --Für das Team Technische Wünsche: Max Klemm (WMDE) (talk) 16:26, 6 April 2020 (UTC)

danke. ja, wenn es keine möglichkeit gibt, schnell zwischen den beiden werkzeugen umzuschalten, werd ich es ganz deaktivieren.

der grund ist übrigens, dass ein editkonflikt auf einer diskussionsseite gänzlich anders aufzulösen ist als in einem artikel. bei zweiterem muss man zwei textversionen konsolodieren, bei ersterem aber meist einfach die selbe antwort nur anders plazieren. dafür ist dieses tool untauglich.

und mir kommen konflikte hauptsächlich auf diskseiten unter.

Hi {{ping|W!B:}}, das wurde uns auch von anderen Wikipedianerin zurückgemeldet, dass das tool auf Diskussionsseiten keine Hilfe ist. Dafür soll es in Zukunft eine angepasste Oberfläche für Diskussionsseiten geben. --Für das Team Technische Wünsche: Max Klemm (WMDE) (talk) 10:57, 8 April 2020 (UTC)

danke dir für den hinweis. nichtsdestotrotz wird das nicht helfen, auch hierbei gibt es mehrere häufige fälle: vor dem EK-beitrag des kollegen einschieben (direkte antwort zum vorausgegangenen); danach (mit hinweis EK, wenn das gespräch so weiterlaufen kann); meinen text aufteilen zwischen diesen optionen; nur teilweise neu formulieren; antwort gänzlich neu gestalten.

da ich kaum annehme, dass die "neue" skin das leisten wird, wird auch diese nur etwas bringen, wenn ich sie schnell ein- und ausschalten kann, um in reinem text-modus zu editieren, wenn das besser geht (ganz wie beim WikiEd und klassischem Quelltext-editor, WikiEd kann zb. lähmend träge laufen und ist mir viel zu überladen, weshalb ich ihn nur in ausnahmefällen verwende)

ein gespräch -- auch schriftlich -- ist halt wesentlich komplexer als nur eine simple abfolge von tweets und re-tweets. zumindest in der gesprächskultur, in der ich sozialisert bin, und die zum glück in der WP auch noch gepflegt wird -- weshalb sich auch diese hiesige form der "diskussionsseite" nie durchsetzen wird, da sie vereinsamte dialoge forciert, anstatt echte diskussionen in der gruppe: das hier ist _keine_ diskussionsseite, sondern ein "small talk", der es leicht macht, beiträge anderer effizient zu ignorieren -- besser, um echte zwiegespräche (dialoge) zu führen, also einer hilfe- und ratgeberseite durchaus angemessen.

und auch die "neue" skin leidet aber unter demselben denkmodell (gesprächskulturmodell), auch in ihr hab ich keinerlei überblick zum gesamtkontext des gespräches, weil die weiteren vorbeiträge ausgeblendet sind. in einem mehr-personen-gespräch knüpft man aber _nie_ nur an den direkten vorredner an. auch -- eigentlich insbesondere -- dann nicht , wenn man sich versehentlich gegenseitig ins wort gefallen ist. das wäre auch reallife eine der heikelsten gesprächssituationen überhaupt, und lässt sich nicht nach schema-f lösen.

Tracked in Phabricator
Task T230231

Wie ich gerade erlebt habe, ist die Lösung eines BK nicht immer, dass man sich für eine der zwei Versionen einer Zeile entscheidet. In einer Diskussion antwortet Benutzer B einzeilig auf einen Beitrag von Benutzer A, während Benutzer C selbst an einer einzeiligen Antwort schreibt und beim Speichern in den BK-Modus kommt. Dort muss er sich entscheiden, ob er seine Antwort oder die von Benutzer B speichern will.

In der früheren Softwarelösung war es so, dass man von der eigenen Version was kopieren konnte und in die momentan gespeicherte einfügen konnte. Das geht jetzt scheinbar nicht. Man muss die Zeile von B oder C nehmen und die andere verschmähen. Das ist eine Verschlimmbesserung.

Ich bitte darum, dass das Ding so weiterentwickelt wird, dass man auch bestimmen kann, dass beide Versionen genommen werden und der Text der eigenen über oder unter den der fremden Version eingesetzt wird. Bei mehrzeiligen BKs ist das vielleicht ein bisschen komplex, aber in meinen Augen ist da eine Nachbesserung unumgänglich. Ich arbeite lieber mit einem etwas mühsamen altbackenen Interface als mit einem hippen, das in der Praxis nicht verlässlich anwendbar ist.

Hi @Man77:, entschuldige, dass ich auf diese Bemerkung erst so spät reagiere. Die habe ich leider übersehen. Wir haben die neue Oberfläche für Diskussionsseiten abgeschaltet, da wir von den Problemen, die du schilderst, auch schon gehört haben. Es soll in Zukunft eine zusätzliche Oberfläche für Bearbeitungskonflikte auf Diskussionsseiten geben. --Für das Team Technische Wünsche: Max Klemm (WMDE) (talk) 07:26, 7 April 2020 (UTC)

Ich hab bisher gerne die Funktion "neuen Abschnitt hinzufügen genutzt", wo dies möglich war und BKs zu erwarten sind. Bitte bin ich damit in einen BK geraten. Mit diesem Ding jetzt schon.

Hi @Man77:, wenn ich dich richtig verstehe, dann hast du das Gefühl öfters in Bearbeitungskonflikte zu geraten, als dies vorher der Fall war, richtig? Dies sollte eigentlich nicht der Fall sein, da wir nichts am Code verändert haben, der entschiedet, ob ein Konflikt vorliegt. Könntest du dies weiter beobachten und dich sonst nochmals hier melden, wenn du weiterhin das Gefühl haben solltest, dass du öfters in Bearbeitungskonflikte gerätst? --Für das Team Technische Wünsche: Max Klemm (WMDE) (talk) 16:21, 6 April 2020 (UTC)

Hi.

Ich hab diese Lösung jetzt abgeschaltet. Wenn sie funktioniert, ist es ja gut, aber momentan stört sie meine Kreise mehr, als dass sie mir das Leben leichter macht.

Dass ich öfter in BKs gerate als zuvor, würde ich gar nicht behaupten. Aber beim "Abschnitt hinzufügen" war das vorher nie der Fall.

LG!

Today this tool does not work: when there is an edit conflict, starts the "old tool".

@ValeJappo: We disabled the tool for edit conflicts on talk pages. If your edit conflict was on a talk page, this is the reason why you saw the old interface. -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 13:49, 6 April 2020 (UTC)

@Max Klemm (WMDE):Ah, ok. Thank you!

Tracked in Phabricator
Task T222805

I am working on old iPad, Safari, web view, keyboard connected with Bluetooth, so maybe it has its own limitation; the interface shows edit conflict with myself by my own edit one second ago.

We are aware of this issue and try to gather information about it in phab:T222805.

The new feature saved me a lot of time. Thanks.

维基百科如何添加一二级目录，维基百科内链接怎么添加

您好，一级就这样 == （内容） == 。第二级就这样 === （内容） ===。至于内部链接，想链接的部分放入[[(链接页面名称)]]。如果有不懂的地方，可以去中文维基互助客栈/求助寻求。

I'm sorry, but I'm afraid I don't get the question. According to the Google Translate service the question is "Wikipedia how to add a primary and secondary directories, how to add links in Wikipedia", which does not make a lot of sense to me. Are you able to post in English?

Hello, I had replied in zh to their question. Thanks for your attention.

I hate this feature. It seems like almost every edit I make is reported as an edit conflict when it is not, as in this recent edit https://en.wikipedia.org/w/index.php?title=Sykes_Camp&diff=933743700&oldid=933743640. Unless this can be fixed, I hope this feature is not implemented.

As far as we are aware of, there is no way the TwoColConflict feature can influence the number of conflicts users run into. All the feature is supposed to do is providing a better interface after a conflict happened. You can disable it in your "Beta" preferences and see if this changes anything. Are you still running into conflicts then? Please let us know!

I disabled the beta feature. It apparently wasn't the problem. I am still experiencing many false positive edit conflicts. How can I fix this?

We are very much curious and would love to know more about this. We created phab:T222805 to collect all we know about this issue. Unfortunately it looks like it is very hard to track. It might be related to the webbrowser or a browser extension you use. Possibly even some malware silently running on your computer. It could be your computer mouse or your hand accidentally doing double-clicks whenever you click a save button. If you have an idea, please let us know.

I can reproduce the issue very readily in my home laptop. I'll try disabling all browser extensions, experiment, and report back.

I'll add to this, I'm seeing this way, way too often. Craziest one, I was creating my 2019 talk page archive (https://en.wikipedia.org/wiki/User_talk:Ravensfire/Archive_11) and got the edit conflict on the page creation!

Did a very quick test on this scenario, where I created one archive (12) and quickly added text and saved, no problem. I created another one (https://en.wikipedia.org/wiki/User_talk:Ravensfire/Archive_13) where I clicked on Create Source, then ignored it, using other tabs and brower windows for several minutes, then added text and saved. Boom, edit conflict happened. I wonder if the time involved could be an issue, or using multiple tabs / windows or a combination of these?

If anyone encounters this repeatedly I would consider whether it might be a symptom of a mouse button beginning to flake-out. Junk edit conflicts can come up when multiple clicks register on the save button.

I think I recall a current-or-recent discussion at English Village Pump (Technical) where someone was getting edit conflicts and they eventually concluded it was a mouse issue.

It's not related to a mouse. It's browser-specific. It only happens with Chrome.

False positives happen frequently when I use Chrome and single-click the "Publish changes" button. (I ignore the conflict, because my edit went through.) When I double-click the button (even though a single-click is sufficient), I do not get the false positive. None of this happens with other browsers I use.

If anyone experiencing this bug is able to post a screenshot of the conflict, that might provide some helpful clues. The "tabs" and "double-click" theories are unlikely because it's impossible to create an edit conflict with yourself (actually, this has always been a dangerous feature but not something we can tackle at the moment). Maybe the browser is sending both a logged-in and a logged-out submission... More information needed!

See https://commons.wikimedia.org/wiki/File:Curb_Safe_Charmer_conflict_screenshot.jpg (diff#942741035)

Thanks! Well, it seems like you did get an edit conflict with yourself, which surprises me. You were making the second edit using the same username, I assume? Is there anything else you can say about what happened? From the edit summary, I'm guessing the first edit was made using a toollabs service "reFill 2"? I'm not familiar with that tool but according to the documentation you submit the page in a toollabs form, probably in a separate tab. This means the page you're working on will be updated relative to what is loaded in the other tab. Depending on how you arrived at the editing page, maybe it's targeting a specific oldid, or maybe you already have the editor open while you run reFill in the second tab?

Either way, now I can imagine why this is happening. Try reloading your editor tab after using reFill: #1 save any outstanding changes and arrive on the article's "Read" tab, #2 run Refill in the second tab, #3 reopen the editor. Hopefully this improves the situation for you!

@Adamw the reFill thing is a red herring. I've just done an undo on an IP editor's edit to the en article on Praveen Linga. I hadn't run reFill on this article - at least not recently. Up came the edit conflict comparison. I have a screenshot if you need it.

I can avoid an edit conflict if I click Submit twice, rapidly. But the editor reopens the article in edit mode.

A screenshot for my latest edit conflict is at https://commons.wikimedia.org/wiki/File:Self-caused_edit_conflict.jpg

Hi, thanks. These screenshots are interesting… The new interface might give a bit more information about the conflict, but even from this I suspect that something unusual is happening. It does seem that you were the only one editing, and from the timestamps it looks like you did successfully save a version of the article, immediately before seeing the conflict. I've created Phabricator task T246440 which might be related, I'm not sure yet.

I may have a better clue as to what the problem is. It seems when I click on the Submit button, whether with the mouse or by tapping a touchscreen, I may get the phantom edit conflict. However, if I instead press the enter button on the keyboard while the cursor is in the edit summary field (which I rarely did until now), there is no edit conflict.

Thanks a lot for this insight! As far as I know the only difference between the two actions is that clicking the button submits the buttons wpSubmit value, while pressing enter in a textfield does not. I had a quick look and could not spot any code doing anything with the extra value. That's puzzling. We will definitely look closer into this.

I confirm Spiffy sperry's experience, hitting ENTER does not cause a conflicting edit.

I received one false-positive edit conflict. Here's the diff. The previous edit was two months ago. I made an edit, set the edit summary, and I clicked PUBLISH. The new edit conflict screen came up. It gave me the option to merge my edits into the current version of the page, but I saw no conflicting content to resolve. I was puzzled so I checked the page history. I found my edit had already been saved, with no other recent edit I could have conflicted with. I then abandoned the unneeded edit-conflict screen.

Edit: I just had another one. Here's the second diff. The new event report would be otherwise identical to my report above.

I found no logging from these empty conflicts, which is strange. There should have been no way to show a conflict page without also logging... A screenshot of the conflict page might have additional clues, please snap one if this happens again.

On the page there is the text "You cannot edit the comment of the person you have the edit conflict with, because there should be no need for you to edit the comment of someone else in a discussion." This might be the case on some Wikipedia's, on other Wikipedia's this is allowed or is allowed in certain circumstances. For example, I know users that have specifically have indicated that they would appreciate and allow other users to help them with fixing spelling. Also the indentation can use a fix. And more. Please don't state this is an absolute fact.

@Romaine: Thanks for your perspective on this part of the interface. And I am sorry if you understood this as an 'absolute fact'. I just wanted to give an explanation why we decided for this. Max Klemm (WMDE) (talk) 09:19, 27 February 2020 (UTC)

Per the message to village pump, I think this is a good idea. Will be certainly helpful as the entire chunk of text I inputed can be copied rather than the previous kind where I either have to search deep in the page to find the chunk (the bottom part "My Text") or rather need to copy line by line (diff view). Thanks for the idea.

I agree with Camouflaged Mirage. Edit conflicts are annoying and it's great to see that you are working on a feature that would make it way more practical to resolve them. Keep up the work!