Hello. Is there a way to return to previous version of the tool, a couple of weeks ago? It was wonderful. I can't even understand the current one, but trying to use all the buttons does not help to solve conflicts. If it's impossible, I'll remove it at all. Thank you.
Help talk:Two Column Edit Conflict View
Jump to navigation
Jump to search
Hi, sorry to hear that. Maybe you can describe us more what your problems with the new interface are, so that we can try to improve it and it's documentation?
Thank you for your answer. No problem. I do not know what to do to resolve the conflict. I see too many buttons. I can't understand what each one is for. I can't find how to edit the current version so I could paste my changes. And so on.
Hi, for our better understanding: did you see/use the help-button? If so, did the help dialogs helped?
One, the previous version was extremally intuitive, so I did not need any help. And two, no, I did not.
I second this. The new version is much more difficult to use.
I had a conflict again. Found the help link, read the help. Now I know what did you want it to be. And yes, it is much more harder to use. So my question, again, is there a way to return to the previous version on my account, or I'll just turn the tool off? Thank you.
There is unfortunately no way to switch to the previous version.
)-:
Hi @IKhitron and @Natureium! The interface you'd like to return to is this version here, right?
It would help us if you could describe a bit what this interface did well that you are missing in the new one. If you can spare a few minutes to describe this, this would be much appreciated.
Best,
Johanna
Yes, it is. Well, it is very unconvenient and very unintuitive. I believe it's possible to solve a conflict using the new version, and it's possible to remember how to do it, but it is not worth. The first version was millions better than the regular wikitool, and in the same time the second version is much worse than the regular one. If I can't use the first version, I use the regular one. I could use the second one if it was the only existing. But if the regular wikitool is much better - why would I not use it? I even did not find a window in the second version with the text that will be published, just parts of it splitten on different windows. Hope it helps.
@IKhitron Thanks for clarifying which versions you're talking about. Trying to get to the bottom of the problem, would you say the new version is inconvenient and unintuitive mainly because you don't see the whole text that will be published? If it's not "just" about that, could you describe a bit more? I know this has turned into a long thread, but your feedback could really help us here. So if you have the time, it would be of much help if you could describe where you have trouble and why (E.g. "I've just run into an edit conflict and I don't know how to select the changes I made before" or "I've made all the changes I want to keep, but I can't see the whole text that will be published").
Also, do you usually run into edit conflicts on talk pages or in articles?
Best,
Johanna
- It's not "just" that, there are other issues.
- I have some time, but I'm not sure I can describe it clearly better. It's just the whole experience, and it isn't usual for me, because regularly I like new features and use them with pleasure.
- Both.
Maybe I can help you other way, Johanna. If it does not bother you, could you please describe me, in a nutshell, what points in the second version should make it better than the first one, and what problems does thay solve? If you could, I can give my feedback on each point, I think. Thank you very much.
@IKhitron Thanks a lot, I really appreciate this. So, we have this summary of the feedback we received on our first beta feature: https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Edit_Conflicts#Test_page_&_feedback_round
These were the points we tried to solve with the new approach. Does that help?
Best,
Johanna
Great, thanks! Well:
- It is hard to find own changes -> It was easy to me in the first version and hard to impossible in the second one.
- It is not clear which column is going to be saved so it is hard to figure out which version I should edit -> It was clear in the first version and absolutely impossible in the second one.
- It should be easier to merge conflicting changes -> I am not sure if it's about the whole process or the one specific point. If whole process, it's much harder now. If the specific point, it's the same as in the first version.
- The selection of the base version is too complicated -> It was simple in the first version, and very frustrating in the second one.
@IKhitron Thank you for this. I'll take your feedback back to the rest of the team, and we might get in touch again if we have more questions.
I've successfully used the previous version of the edit conflict tool quite a few times, however the new version completely failed.
First, it took me uncomfortably long to find and grab a copy of the text I was trying to add. Perhaps it's just because I was seeing the new version for the first time, but it was an unpleasant start.
Next, I was severely puzzled that there was no live edit-box anywhere. I after a bit of effort I did manage to activate the old-text as an edit area and add my own text. I am going to be cautious in commenting because it's my first time seeing the new version, but I have a vague but strong feeling that that this design is very wrong somehow. It's hard to give more specific feedback because the system-as-a-whole failed completely.
After modifying the old-text-area to include my new comment, my natural next steps would be (1) preview and (2) a diff-check, prior to saving. Except the preview button didn't work! Repeated clicks on Preview did nothing. I was unable to get to diff either.
Unable to progress, I went back and tried to review and absorb the conflict-system as a whole, and see if maybe I was missing something. I can pretty much see what you were aiming for, but when I tried the system for expanding/collapsing sections(?) it was either broken or not doing what I expected. I couldn't find any way to get the preview button to work. Somehow the whole design around activating the edit areas felt very wrong.
I was never able to resolve the edit conflict. If I can't go back to the previous version of the tool, I'll have to shut off the Beta-preferences and go back to the "native" conflict resolution system.
This may be a strange comment, but I get this weird feeling that new design went wrong because someone from the VisualEditor or Flow team showed up to take charge.
I see that Phab task T216837 exists to address the non-working preview button. My other impressions of the system should still be reviewed, under the caveat that it's difficult to evaluate the design when it's impossible to complete the process.
Same issue in previewing and diff-check.
Thank you for your input (it is very much appreciated and needed) and sorry for the delayed answer. The problem with the broken preview and diff buttons it known and will be fixed. About the general experience with the new version: We tested both versions with various users of different backgrounds. And while all solutions have there pros and cons and did confuse some users, the new version was understood better by most people and resulted in more conflicts being successfully resolved. We therefore decided for the new version and try to improve it further to be more easily understood and better to use.
Scenario: user or article TP discussion - click on save comment...edit conflict window appears...choose my text to add, thinking it will be added either above or below the conflicted text. Instead, it deletes the conflicted text and adds mine in its place. Why isn’t it simply added above or below the conflicted text instead of deleting one or the other? The tool doesn’t resolve the conflict, it creates one. ~~~~
Hi, thanks for the input. The conflict resolution algorithms can't (yet) detect when two answers have been added independently, since it's working paragraph-wise not linewise. Therefore the conflict resolution pages is shown. The current work-flow would be to merge the two versions by selecting one and copying the other additions to it. There is already a ticket for improving this T213270 – I added a link to your input.
After I’ve copied my post to the “current” (left-hand) side and clicked the checkmark, the Preview button does nothing (using Safari v.12.0.3 on a Macintosh, at enWP & Commons). Sometimes I just cross my fingers and Publish, but if I need to verify that a template or link works as expected, I have to back out and start over, defeating the purpose of the conflict-resolver.
Thanks for the bug-report! I gave it to the developers, so that we can look into it.
When getting a conflict on a talk page (because another user has added a comment on the same topic), I would like to be able to "use both", mine after the other (or vice versa, not sure we need both options).
This would be great. The conflict view mainly triggers in cases like this for me. For example, two "!votes" on a page should be added sequentially if they both start with a single #. Or if two people respond to the same talk page comment, both at the ::: level, can set the first registered comment to ::: and the second to ::* to keep at the same level but differentiate the second comment. (Not watching page but ping me as needed)
There is no option to merge conflicting edits, is there? It would be really helpful to add this feature...
Hi, thanks for you inputs and the proposals! I create a phabricator-task for this: T213270, so we have it on our radar and can take a look. Can you also take a look at the ticket if this describes your issue well?
@Draceane: have you noticed that you can edit every section to merge in your edits?
@Michael Schönitzer (WMDE): Thanks for creating the ticket. Meanwhile I did find the workaround with edit-and-copy, but as stated by you, this is unintuitive and ugly.
I would be very happy if this came to fruit. 9 out of 9 times the editing conflicts I have are on talk pages. For now the copy-paste workaround works.
So I added a lot of stuff to a cat in Commons and meanwhile someone else changed a few cats. When the edit conflict page generated by this gadget come over, there were some highlighted changes and I could either “publish” or cancel. Where’s my wikitext, though in case I wanna keep it for later?
There’s a link that says «Go to editing area», but it’s not really editing (wikitext) it’s a VE-style gizmo that ate half of what I had typed. Is this your way to create productivity tools? Well, keep it, I’m gonna turn off this thing in my prefs and let you dupe someone else to be your lab rats. Tuvalkin (talk) 19:11, 4 March 2019 (UTC)
Oh and the warning message is precious, showing an unresolved template call: {{#ifeq:{{NAMESPACE}}|{{ns:6}}|[[File:{{PAGENAME}}|350x220px|none]]}}. Classy!
Hey @Tuvalkin, sorry to hear that you ran into problems with an edit conflict.
From your description I cannot entirely see if this is an issue with the Two Column Edit Conflict View beta feature or if this was a problem you ran into while using the classic conflict screen though. If your conflict looked something like this it is the former. If it looked more like that its the latter.
Can you please confirm the one or the other?
Thanks, Christoph
Neither: What I was handed had no textbox nor any other way I could have retrieved the wikitext in question, either in toto or only the affected snippet. (Also: The way you linked those two images, with (…)«#/media/File:», within a remote page, instead of simple (…)«File:» is outright evil.) (Also 2: This Flow contraption has no preview? Wtf?) Tuvalkin (talk) 11:45, 12 March 2019 (UTC)
That sounds indeed very strange then. - If it was neither the one nor the other, than I really have a hard time understanding what happened there. :-/
Do you have the two column edit conflict feature enabled in the beta features section? Could you try to "provoke" a new edit conflict and provide a screenshot of what you're seeing?
To provoke an edit conflict you can just do the following:
- go to a page ( e.g. a subpage of your user page with some content )
- open it in edit mode and make a change ( but don't save it yet! )
- open the same page in edit mode but with another browser ( or a private tab )
- make a ( different ) change in the same line as above and save it
- go back to the first edit and save it
Thanks!
Thanks for looking into the matter. I did turn this gadget off, but I can turn it back on for experiment sake. I will do as you suggest ASAP.
And of course no preview means I could not correct my botched closing tags will be corrected never ever. You guys managed to destroy a wiki’s most basic function with your airhead gadgets. Tuvalkin (talk) 11:48, 12 March 2019 (UTC) (Later:) Oh, it is editable! Fantastic: it's not a button that says edit or that shows a pencil, it's a button that shows both but which is in turn hidden inside another button that shows three dots; all buttons frameless of course, to make it easier. Well, easy it aint. Tuvalkin (talk) 11:51, 12 March 2019 (UTC)
Great update, and completely impressed with the new experience; pretty time saving to solve conflict. By the way, the "Review changes" button does not seem to work, after I have chosen which edit version either on the left or on the rightside column. Is it final when I check either box, I mean, do I have to correct other things before solving ediitng conflict as in this edit? Anyway, thank you so much for your hard work, guys :)
@Omotecho Thanks a lot for this feedback! It seems in fact that something is broken with the "Review changes" button. I've filed a bug report for T216742
Thanks again!
Johanna
@Omotecho It turns out I was wrong. For some reason, I confused the "Review changes" with the "Preview" button yesterday. Sorry about that!
So, the correct information is: The "Review changes" button doesn't work because it doesn't exist in the new interface anymore. That's because technically speaking the two-column layout is basically an editable diff view. As in the diff view, you see all of the changes between the two versions in yellow and blue, and all of the unchanged text in grey. To compose the version you want to publish, you select the text passages you want to keep, and click on "Publish". That's it. Optionally, you can edit the text in the selected text boxes, and also in the grey text boxes.
I hope this helps.
Best,
Johanna
Thank you, Johanna Strodt to taking care of my question, and I am excited to update my skill using two-column preview:
- I find it very useful as when I choose the rightside box, then the diff is highlighted inside the text box (in my case in blue for the r-column) so that I am assured my choice is correct.
- The new thing in my guess, before on-hand experiment myself: I will click on the right column in two-column display during checking edit conflict, and I will edit in that display; I used to go back to editing mode prior to the current update. (If my guess is right, then it's worth to announce to the users using Tech News, isn't it?)
@Omotecho Yes, in this new interface, you can edit directly in the two-column display without going to back to a separate editing page. Right now, the feature is in beta phase. We've announced it quite a bit already, including Tech News, and we'll announce it again once it becomes a default feature for everyone.
Have a good week!
Case solved for me. Wonderful! Can’t wait to translate messages on this topic on future Tech News issues, appreciating your hard work and very inventive solution for maximising human and time resource for editors :) Enjoy good meal.
Thanks a lot! I'll pass this on to the rest of the team. :)
Just now I lost an edit that took me 20 minutes to craft. Thanks. I really thought I was publishing *my* edit (overwriting the other ec edit, with good reason), but in the end my own text was gone. Doesn't the Preview button function as intended? WHY does a feature like this still SURPRISE and DISAPPOINT me?
I have tried to get into this feature (seriously, for is it 18 months?), but from now I will deny and kill it with every option I have. I am a serious editor, this nonsense spoiled my wikiweek.
I mean: these days, every browser has a warning that says: "You really want to throw away your edits?".
Hello @DePiep, I'm sorry to hear that you've lost your edit. Have you experienced this before with the new interface?
We've looked into the problem that you're describing, but couldn't reproduce it. So to understand what this is about, could you tell us which editor you used, and give us a link to the edit this was concerning? Also, it would be helpful to get a list of the gadgets you have enabled.
For the warning idea, I've created a ticket: T216813
Thanks a lot,
Johanna
Thanks for this action. I have not experienced this before in the 2-column version, but I must say I never tried this before: to overwrite (overrule) the other edit (the conflicting one). IIRC, when the 2-column ec screen appeared, I choose to have my own edit in the righthand column, and saw my text in there so OK. I clicked Preview button, but it had no effect (no reaction). Then I pressed "Publish" button (=Save) in the blind (unchecked unpreviewed). Moments later I saw that the wrong edit was saved, and I could not walk back to my editing page (where my edited text might still be). I did not open or follow the manual linked. All as I recall. (Usually, I copy/paste my edited text into an extra opened page to merge the edits, i.e., manually).
I was editing Firefox, in old Wikitext not VE.
The edit that won is: [https://en.wikipedia.org/w/index.php?title=Talk:Brexit&diff=884465789&oldid=884462294&diffmode=source]
Beta gadgets: Visual Differences, Two column edit conflict
Gadgets active:
(I will add the list from Preferences later. You need all ~20?)
Thanks, @DePiep. We'll look into this more beginning of next week. For now, I've filed a ticket for the Preview button that doesn't react: T216837 I could reproduce this myself.
Have a good weekend!
Johanna
Quite probably I was sloppy checking, it might *not* be a Preview failure (as I tried to describe above). My frustration was: the interaction failing. As I noted before on this ec feature: losing one's edited text is horrifying. Preventing that should be prio #1. (also, I wrote: obvious non-conflicts should be handled more smartly).
Actually, and to be honest: ever since this ec new thing 18 months ago (a "3-colum" version before?), I did this: EC situation -> open new tab with same talkpage -> copy/paste my new text -> save.
@DePiep Thanks for the update. I understand your main concern is that it's not clear when you're about to lose your text, which you can't get back. I'll take your remarks back to our team.
Best,
Johanna
Great mod! Only I just tried editing my changes after a conflict was detected, clicking on the pencil and... nothing happened. I tried all pencils, to no avail.
I'm working on the French Wiki, using Firefox (up to date) on Win 8.1.
@Vega Thanks for letting us know. We'll look into it.
Best,
Johanna
Hey @Vega,
unfortunately I can't reproduce the issue. It would be great if you could try to get another edit conflict to see, if the problem is at least reproducible for your setup.
There are two ways to do that ( that each could have another result, so it would be great if you could try both in the case you can't see the problem in one of the two ):
1st:
Visit the edit conflict simulation page and click through the interface until you get to the edit conflict screen. ( you do not really have to add something anywhere, just go by the defaults )
2nd:
To provoke a "real" edit conflict you can just do the following:
- go to a page ( e.g. a subpage of your user page with some content )
- open it in edit mode and make a change ( but don't save it yet! )
- open the same page in edit mode but with another browser( or a private tab )
- make a ( different ) change in the same line as above and save it
- go back to the first edit and save it
Now you should also see an edit conflict screen.
If you still get the bug it would be also good to know which gadgets you use and if you have any ( other ) custom user scripts enabled.
Thanks again for your report,
best,
Christoph
Hello Christoph Jauera,
Thanks for looking into this.
1st method is ok, I was able to edit and publish;
2nd method is weird: I used a private tab as per your recommendations, logged in, and the edit conflict was ignored altogether! The changes I made in the 2nd window were discarded with no warning.
I do have different gadgets enabled. I'll see what happens when edit conflicts appear with other contributors before I take more of your time with this case.
Thanks for your useful work,
Vega
Hey, thanks for trying this.
To the 2nd method: Don't log-in on the 2nd window. It's essential that this edit comes from a "different" user ( normally you can edit as anonymous user on an arbitrary page in your user space ). There won't be a conflict if both edits come from the same user ( since MediaWiki will assume you're aware of the overwriting actions ).
And no worries. Better report a potential bug that does not turn out to be one than not reporting a critical issue :-).
Hello,
Ok, so this time I didn't log in, and correctly managed to edit within the edict conflict page. Still don't know why it didn't work the first time.
I thought MediaWiki would warn me that I am already editing the same page, but it seems they trust I don't make mistakes ^^ Anyway, thanks for your kind support.
Hi there,
just by coincidence I had an edit conflict last week and used the updated "two column edit conflict view" – as I was positively surprised. I really like the view, the possibility to switch between wiki text view and wysiwyg/visual view and – especially – the possibility to edit directly in this view.
Thanks a lot for your work!
Thanks so much!
