Help talk:Paragraph-based Edit Conflict Interface/2020
Add topicThis page used the Structured Discussions extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made. |
Feedback and discussion page for the Paragraph-based Edit Conflict Interface.
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.
Many False Positive Conflicts
[edit]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. Btphelps (talk) 20:13, 2 January 2020 (UTC)
- 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! Thiemo Kreuz (WMDE) 17:22, 8 January 2020 (UTC)
- 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? 70.102.106.34 (talk) 17:25, 8 January 2020 (UTC)
- 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. Thiemo Kreuz (WMDE) 18:01, 8 January 2020 (UTC)
- I can reproduce the issue very readily in my home laptop. I'll try disabling all browser extensions, experiment, and report back. Btphelps (talk) 20:19, 8 January 2020 (UTC)
- 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! Ravensfire (talk) 21:56, 8 January 2020 (UTC)
- 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? Ravensfire (talk) 22:10, 8 January 2020 (UTC)
- 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. Alsee (talk) 17:47, 22 January 2020 (UTC)
- It's not related to a mouse. It's browser-specific. It only happens with Chrome. Btphelps (talk) 04:44, 24 January 2020 (UTC)
- 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. Spiffy sperry (talk) 03:45, 16 February 2020 (UTC)
- 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! Adamw (talk) 12:33, 26 February 2020 (UTC)
- See https://commons.wikimedia.org/wiki/File:Curb_Safe_Charmer_conflict_screenshot.jpg (diff#942741035) Curb Safe Charmer (talk) 15:27, 26 February 2020 (UTC)
- 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 (talk) 17:45, 26 February 2020 (UTC)
- @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. Curb Safe Charmer (talk) 08:51, 27 February 2020 (UTC)
- I can avoid an edit conflict if I click Submit twice, rapidly. But the editor reopens the article in edit mode. Btphelps (talk) 07:08, 27 February 2020 (UTC)
- A screenshot for my latest edit conflict is at https://commons.wikimedia.org/wiki/File:Self-caused_edit_conflict.jpg Spiffy sperry (talk) 05:31, 29 February 2020 (UTC)
- 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 T246440 which might be related, I'm not sure yet. Adamw (talk) 08:09, 29 February 2020 (UTC)
- 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. Spiffy sperry (talk) 17:59, 8 March 2020 (UTC)
- 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. Thiemo Kreuz (WMDE) 13:37, 10 March 2020 (UTC)
- 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
- I confirm Spiffy sperry's experience, hitting ENTER does not cause a conflicting edit. Btphelps (talk) 22:28, 8 March 2020 (UTC)
- I received
onefalse-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. Alsee (talk) 07:23, 10 March 2020 (UTC)
- 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. Adamw (talk) 15:37, 10 March 2020 (UTC)
Add button to select all instances of your version
[edit]RESOLVED | |
Done, see phab:T229217. |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Very frustrating when one tiny edit in one paragraph disrupts an edit you've made that affects 20 other paragraphs and you have to manually click through 19 of them selecting "your version".
Simple feature request. Thank you. · • SUM1 • · (talk) 23:54, 16 January 2020 (UTC)
The new Edit Conflict software appears to mishandle page info passed to template logic
[edit]RESOLVED | |
Patched, reviewed, and merged in just a few hours. Nice work @Thiemo Kreuz (WMDE). Thanx. The fix will presumably be deployed soon. |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
- I encountered an edit conflict at English Wikipedia:Village_pump_(policy), with the beta edit conflict software enabled.
- The page included several copies of the the Talk Quote template, {{Tq }}. This template includes logic to verify the namespace of the current page. This template generates a red error message when it detects that it is being used on an inappropriate page. The template normally detects and accepts Village Pump as an appropriate page.
- The {{Tq }} template failed to render correctly in the new edit conflict preview. The template generated warning messages that it was being used on an inappropriate page.
- I saved the edit. The template and everything else rendered correctly on the saved page.
I believe the most likely explanation is that the edit conflict software passed incorrect information about the page to the template logic. I only encountered this issue once, I was in the middle of clicking save when I spotted the problem, and I have not attempted any testing. My interpretation and explanation of the issue seem obvious and simple, but it is merely a hasty hypothesis. Alsee (talk) 18:09, 22 January 2020 (UTC)
- That is indeed exactly what happens. Thanks a lot for the wonderful report (especially for clearly marking hypothesis as such) and for creating that Phabricator ticket. This will be fixed. Thiemo Kreuz (WMDE) 09:46, 23 January 2020 (UTC)
WMDE additional edit conflict resolution idea
[edit]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. Camouflaged Mirage (talk) 17:36, 26 February 2020 (UTC)
- 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! Reception123 (talk) 17:41, 26 February 2020 (UTC)
You cannot edit the comment of someone else
[edit]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 (talk) 07:01, 27 February 2020 (UTC)
- @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)
维基百科如何添加一二级目录,维基百科内链接怎么添加
[edit]RESOLVED | |
Responded in the user's wiki. |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
- 维基百科如何添加一二级目录,维基百科内链接怎么添加 Wlchunxiaodi (talk) 08:37, 16 March 2020 (UTC)
- 您好,一级就这样 == (内容) == 。第二级就这样 === (内容) ===。至于内部链接,想链接的部分放入[[(链接页面名称)]]。如果有不懂的地方,可以去中文维基互助客栈/求助寻求。 Camouflaged Mirage (talk) 18:23, 23 March 2020 (UTC)
- 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? Thiemo Kreuz (WMDE) 11:14, 16 March 2020 (UTC)
- Hello, I had replied in zh to their question. Thanks for your attention. Camouflaged Mirage (talk) 18:25, 23 March 2020 (UTC)
Very nice feature!
[edit]The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The new feature saved me a lot of time. Thanks. Taste1at (talk) 15:40, 30 March 2020 (UTC)
1 second interval
[edit]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. Omotecho (talk) 07:07, 4 April 2020 (UTC)
- We are aware of this issue and try to gather information about it in phab:T222805. Thiemo Kreuz (WMDE) 09:29, 4 April 2020 (UTC)
Falsches Dilemma
[edit]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. Man77 (talk) 13:11, 4 April 2020 (UTC)
- 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)
Neuen Abschnitt hinzufügen
[edit]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. Man77 (talk) 07:50, 5 April 2020 (UTC)
- 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! Man77 (talk) 17:09, 6 April 2020 (UTC)
way out
[edit]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.?
W!B: (talk) 21:08, 5 April 2020 (UTC)
- 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. W!B: (talk) 09:41, 8 April 2020 (UTC)
- 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.
W!B: (talk) 21:44, 8 April 2020 (UTC)- Hi @W!B:: wir sind uns der möglichen Komplexität von Diskussionen auf Diskussionsseiten bewusst und probieren die Oberfläche daraufhin zu entwickeln (T230231).
Es wäre großartig, wenn du dir die zusätzliche Oberfläche für Bearbeitungskonflikte auf Diskussionsseiten nochmals anguckst und uns Feedback geben würdest, wenn sie im späteren Verlaufe dieses Jahres bereitgestellt wird. --Für das Team Technische Wünsche: Max Klemm (WMDE) (talk) 09:32, 15 April 2020 (UTC)
Does not work
[edit]Today this tool does not work: when there is an edit conflict, starts the "old tool". Valcio (talk) 13:32, 6 April 2020 (UTC)
- @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)
- Why? This week every day I've had numerous edit conflicts and all of them with the old interface. First I was thinking this is a cache issue or some bug, but after a week of seeing old bad interface I searched for any explanation (unsuccessfully). Dvorapa (talk) 17:59, 12 April 2020 (UTC)
- Hi @Dvorapa: We turned off the Two Column Edit Conflict Interface for talk pages, because it helps merging two versions of a page. This is not helpful for edit conflicts on talk pages.
- I guess the reason why you still see the old interface is that it only is a default feature on the German, Farsi, and Arabic Wikipedia. However, if you want to use it already on the Czech Wikipedia, you should be able to enable it as a beta feature in your settings. --For the Technical Wishes Team: Max Klemm (WMDE) (talk) 08:02, 14 April 2020 (UTC)
- I don't understand anything from your answer, I'm sorry, please be more specific. Why do you think it is more helpful to use the old interface for talk pages instead of the new one? Is there a way to turn it back on even on talk pages? Dvorapa (talk) 08:12, 14 April 2020 (UTC)
- Hi @Dvorapa: When an edit conflict occurs, the Two Column Conflict interface works in such way that it needs you to choose either between your edit or the edit of the person you are having the edit conflict with. On talk pages this set up does not make any sense, since you do not want to choose between the other persons comment or yours. Both should be on there. In most cases you only want to adjust the order of the comments. Is this more specific? As always, you can find more information on the Two Column Conflict Edit Conflict View project page.
No, there is currently no way to turn it back on. There will be an additional interface to help solve edit conflicts on talk pages in the future. --For the Technical Wishes Team: Max Klemm (WMDE) (talk) 10:37, 14 April 2020 (UTC) - Now I understand your response, thank you for the explanation. But still Two Column Edit Conflict interface also allows both compared versions to be edited, which several cswiki users used to merge both changes also on talk pages, choosing their order and putting them together. In the old interface there is just one edit window with the full page text (not just the conflicting parts), which makes such merge not an easy task. That's what I liked most on the tool's interface: The ability to edit only the conflicting parts, not the whole page and it seemed to me as a key feature of it. I hope this will eventually become the main interface and once again we could use Two Column Edit Conflict tool. Shame I have to turn the Beta Feature off because seeing the new interface in 1 of 10 cases makes me quite confused. Dvorapa (talk) 10:54, 14 April 2020 (UTC)
- I also hope the talk page edit conflict interface you mentioned will launch soon. It looks awesome on the screenshots. Dvorapa (talk) 11:02, 14 April 2020 (UTC)
- @Max Klemm (WMDE): Ah, ok. Thank you! Valcio (talk) 13:56, 6 April 2020 (UTC)
- And why isn't it working also on Wikipedia: namespace pages? Ferdi2005 12:20, 1 May 2020 (UTC)
- Hi @Ferdi2005: , we temporarily disabled the Two Column Conflict interface for the "Wikipedia:" namespace, because there are many discussion happening in this namespace and the Two Column Edit Conflict View doesn't work as well on these kind of pages. We are working on an additional interface for talk pages and will enable it on these pages soon. -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 13:09, 6 May 2020 (UTC)
Unacceptable replacement of <> symbols
[edit]RESOLVED | |
Fixed since 2020-04-13. |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I used the tool to resolve an edit conflict at Bob the Builder This munged the formatting by replacing < and > with ampersand codes. As these symbols are widely used on the English Wikipedia, this is unacceptable and so I'm no longer using the beta. Andrew Davidson (talk) 11:02, 10 April 2020 (UTC)
- I just ran into this myself. See [https://en.wikipedia.org/w/index.php?title=Michael_Peterson_(criminal)&diff=950237197&oldid=950237182]. I had reverted the edit from an IP [https://en.wikipedia.org/w/index.php?title=Michael_Peterson_(criminal)&diff=950237182&oldid=950231864], got the edit conflict, chose my revision and accepted and then see the lead messed up. The history showed a second edit from me that appears to have come from the edit conflict resolution. Something's not right.
- Interestingly, I got an EC on a subsequent article, clicked preview and saw the same formatting issues. Clicked cancel, and in the history, my original edit was there. This is just odd. Ravensfire (talk) 23:42, 10 April 2020 (UTC)
- The same happened also here:
- [1]
- The replacement occurred for all unchanged text and all text modified by the other user (which I have accepted in conflict resolution). Those lines I did change have not been affected by the bugous replacements. Taste1at (talk) 09:01, 11 April 2020 (UTC)
- It happens not only with "<" and ">" but also with &; the commonly used "&nspb;" became "&npsb;" See https://it.wikipedia.org/w/index.php?title=2MASS_J10475385%2B2124234&diff=prev&oldid=112097269
Ysogo (talk) 14:13, 11 April 2020 (UTC)- As someone noted below, this doesn't seem to happen if I press Enter when submitting the edit, only when I click on the save button. Ravensfire (talk) 14:28, 11 April 2020 (UTC)
- We had this on a recent death page <,>," and & were affected. Because of the rate of editing I ended up fixing one character type at a time, which is not ideal. Because "Recent event" articles are more likely to create conflicts, this bug is more likely to express in these circumstances.
- Is there a Phab for this? Rich Farmbrough (talk) 12:53, 12 April 2020 (UTC)
- Yes. I founf this Phab: https://phabricator.wikimedia.org/T107679 Ysogo (talk) 13:41, 12 April 2020 (UTC)
- That's an old task, and the issue looks somewhat different. The task for the current issue is phab:T249986 – Ammarpad (talk) 20:04, 12 April 2020 (UTC)
- I'm able to reproduce the behavior and can confirm this is clearly a bug. I appears like the actual bug was introduced more than 3 years ago, but only surfaced now because of other changes. I'm really sorry this happened during the Easter holidays. We will backport a fix as soon as we can. Thiemo Kreuz (WMDE) 09:06, 13 April 2020 (UTC)
- The issue was fixed and this fix is life on all Wikis. Thanks a lot for the report. --For the Technical Wishes Team: Max Klemm (WMDE) (talk) 09:28, 14 April 2020 (UTC)
Editors are mixed together
[edit]I edited an article today ([[:hu:Bismarck (csatahajó) ]]). When I intended to save my modifications, the "Two Column Edit Conflict View" warned me of a conflict with another editor. I have sent him a message, but he did not respond. I did not "save" my modifications yet!
Meanwhile I checked the differences between the two versions, and I noticed, that only I modified the article, the "other" editor did not. However, the article was somehow saved, with the name of the other editor, but the content was my modifications!
Here is the link to the differences: https://hu.wikipedia.org/w/index.php?title=Bismarck_%28csatahaj%C3%B3%29&type=revision&diff=22661743&oldid=22661703
The histrory says "2020. május 24., 15:22 Sepultura", which is incorrect, because editor Sepultura says he did not edit the article.
More importantly I recognize my text (under his name).
Misibacsi (talk) 16:13, 24 May 2020 (UTC)
- Hi @Misibacsi, we looked into your request last week and tried to understand what was going on here.
- It is quite a head scratcher, to be honest.
- After going through the version history, it seems to us as if you and Sepultura made very similar edits (maybe following a convention?). Thus, our best interpretation so far is that the text you thought to recognize as your own actually comes from Sepultura and just looks very similar to your edits.
- Do you think that’s possible?
- PS: Unfortunately, we don’t have any Hungarian speakers on our end, so we had to rely on auto-translation for our research. This might have led to misinterpretations of the situation - apologies if that is the case. If we misunderstood anything, please let us know. Robin Strohmeyer (WMDE) Robin Strohmeyer (WMDE) (talk) 11:38, 2 June 2020 (UTC)
- It seems you are right: we made very similar edits (following conventions and mostly correcting typos). When I saw the article some minutes later, I was sure that "these were my edits". Which was strange, because I did not save my edits.
- Meanwhile I wrote to the other editor several times, but he did not respond.
- As I did not receive answers from him, I thought, that the "History" of the article contains a mistake as those were my edits and not his.
- Later he admitted, that he made modifications and when he finished editing he left his home, so he could answer to my questions. (Much later he returned and answered to me).
- So, it is settled, sorry for the inconvenience, but I thought I found a serious software bug in the system... (fortunately it was not the case).
Misibacsi (talk) 12:18, 2 June 2020 (UTC)
Good
[edit]The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
it's good. I don´t hace problems with this tool Sheenbrino (talk) 19:54, 24 June 2020 (UTC)
- Great, we are glad to hear it works for you. :) Max Klemm (WMDE) (talk) 10:07, 25 June 2020 (UTC)
This is totally confusing
[edit]I just got the new beta interface for the first time. To be honest, I find it totally confusing. Some of it makes sense. There's two text boxes, highlighted in yellow and blue. I get that. The blue one on the bottom is what I wrote, the yellow one on the top is what somebody else wrote. So far, so good.
Then, there's a button with up and down arrows which flips those two. I don't understand this. It switches which is on top, but other than this trivial layout change, I don't see that it performs any useful function.
My text has two controls on it, a checkmark and an X. Again, I have no clue what these do. The checkmark has a tooltip, "Apply your changes to this text". I don't understand what that means. Does it mean, take this change and automatically merge it into the other text? The X tooltip says, "Discard all your changes to this text". I'm afraid to even click that one because I don't know what it'll do. Discard permanently with no way to recover the text?
Sorry, this is just totally mystifying. And I say that as a software engineer with many years of using merge conflict resolution tools. RoySmith (talk) 14:43, 27 June 2020 (UTC)
- PS, I did what I usually do. I copied my text to the clipboard, opened up the same page in another window, and redid my edit there. That seems much simpler and understandable than any of the automatic merge tools I've seen tried. RoySmith (talk) 14:45, 27 June 2020 (UTC)
- Hi @RoySmith: , we have seen your feedback and need some more time to discuss it with our team. I will come back to you at the beginning of next week. -- For the Technical Wishes Team Max Klemm (WMDE) (talk) 09:56, 2 July 2020 (UTC)
- Hi @RoySmith: , thanks for your constructive feedback. Your comments are helpful for understanding where usability improvements could be made to the interface. To explain what the controls you mention should do, both symbols (the check mark and the X) only appear if you decide to edit your post (click into the textbox) in the talk page edit conflict interface. By clicking the check mark, you save any changes you’ve made to your post in the interface. By clicking on the X, every change you made in the talk page edit conflict interface is discarded and you will see the text of your initial post (which resulted in the initial edit conflict). --For the Technical Wishes Team Max Klemm (WMDE) (talk) 09:15, 7 July 2020 (UTC)
How to test this interface?
[edit]I've tried to edit conflict with myself in the Sandbox, but it just overwrote my first change with the second. A demo setup would be helpful.
Help:Paragraph-based Edit Conflict Interface#Usage mentions to enable the beta feature. There's no such option in my Beta Preferences, though according to the roadmap it's still in beta. —Aron Man.🍂 edits🌾 13:09, 3 July 2020 (UTC)
- Hi @Aron Manning: , thanks for your feedback. Unfortunately, there is no demo setup available for this feature. You can create an edit conflict with yourself if you make one of the changes from a private/incognito window where you aren’t logged in to your account.
- Whether the feature is available as a Beta Preference depends on which wiki you are on. On MediaWiki it is a default feature already, so it’s not shown as a Beta Preference in the list. The reason it’s still a beta feature on the roadmap is because it’s currently only a default feature on dewiki, arwiki, fawiki and Group 0 wikis (MediaWiki is in this group). For all other wikis it remains a beta feature for now. --For the Technical Wishes Team Max Klemm (WMDE) (talk) 11:36, 8 July 2020 (UTC)
- > You can create an edit conflict with yourself if you make one of the changes from a private/incognito window where you aren’t logged in to your account.
- Thank you for the detailed answers. To clarify: this means that if a user conflicts with themself, that case is ignored? —Aron Man.🍂 edits🌾 19:47, 8 July 2020 (UTC)
- Hi @Aron Manning: , yes, that’s right. But the fact that a user’s conflict with themselves is ignored is not actually something that is decided by this interface. It’s something that the MediaWiki core code does through the “EditPage class”. We didn’t work on that code in this project, so whether an edit conflict is detected and then shown actually depends on the same MediaWiki core code that has been in place for a long time, not on the new paragraph-based edit conflict interface. -- For the Technical Wishes Team Max Klemm (WMDE) (talk) 14:18, 16 July 2020 (UTC)
- I suspected that is the case. From one aspect it makes sense to avoid complicating editing with conflict resolution with oneself - probably editors just want their last version. Thank you for confirming this. —Aron Man.🍂 edits🌾 09:42, 17 July 2020 (UTC)
- I'm sorry to hear this is causing confusion. MediaWiki's behavior is underspecified and rather inconsistent when "conflicting with yourself". There are dozens of tickets discussing this problem for years, most notably phab:T36423, phab:T58849, and phab:T222805, as well as very recent incidents, see phab:T246726. When testing the conflict resolution interface it's important to do this with two different users. One of them can be an anonymous, not logged in user, as Max already mentioned. That can be done using an incognito window. Thiemo Kreuz (WMDE) 09:55, 26 July 2020 (UTC)
The new tool is missing the "Show changes" button
[edit]The standard edit mode has three core buttons:
- Publish Changes
- Show Preview
- Show Changes
The third button is missing in the new tool. The button brings up a standard DIFF which shows what changes will be made, and it does so in a familiar, formal, and extremely precise format. My last conflict was a bit more complicated than average, I did resolve it correctly, but during the process I wasn't 100% sure I had solved the edit conflict cleanly. I was painfully hesitant to save without being able to verify it via the ShowChanges diff. (It happened to be a talk page edit conflict, and there is heightened feeling of responsibility not to screw up other people's comments.) Alsee (talk) 00:55, 4 July 2020 (UTC)
- Hi @Alsee: , thanks for your feedback. We decided to publish the feature without the ‘Show Changes’ option, because it actually is a very complex and resource intensive function to integrate into the feature.
- However, we appreciate your feedback and will consider it in any further development of the tool. -- For the Technical Wishes Team Max Klemm (WMDE) (talk) 12:37, 8 July 2020 (UTC)
- @Max Klemm (WMDE) your comment did not match my experience. I did directly handle the text of the other person's comment. Below I will describe my edit conflict and resolution. (If requested, I could dig up a link for the conflict diff.)
- In the tool I had three separated regions of conflict to resolve:
- Top conflict choice: I had inserted a new line (a template). I resolved this conflict-region by selecting my version.
- Gray unchanged text: Old comments from multiple people.
- Middle conflict choice: One side had a new comment from someone else (I believe in yellow), the other side had a new comment by me (I believe in blue). I resolved this conflict-region by CTRL-C copying their text, clicking the edit pencil on my comment-area, and pasting their comment above mine. At the time I did not see any other way to resolve this conflict-portion. Either there was no other option present, or I missed it.
- Gray unchanged text: The start of a ===subsection===.
- Bottom conflict choice: Two people had added comments in this subsection. I resolved this conflict-region by selecting their version.
- We decided to publish the feature without the ‘Show Changes’ option, because it actually is a very complex and resource intensive function to integrate into the feature.
- Your meaning is somewhat unclear. Did you mean you would add the button in a later publication? Or did you mean you decided to drop the button from the end product? ShowChanges is probably used less often, but it serves an important function. ShowPreview and ShowChanges highlight or conceal essentially opposite aspects of the content. Alsee (talk) 16:10, 8 July 2020 (UTC)
- Hi @Alsee: , sorry, if the last answer was not clear. Based on your description, you did not end up in the edit conflict interface for talk pages, but in the general edit conflict interface shown in all other cases. The edit conflict interface for talk pages or discussion-based edit conflicts appears in the talk or project namespace when two people insert a new line in the same single place on the page at the same time. The general edit conflict interface appears, when two people edit two or more parts of the same page at the same time. In your case, unfortunately, you ended up in the general interface since you added both a new line and added a new comment to the discussion on the page. This is of course not optimal, so thank you for letting us know about this case so that we can try to address it through future improvements.
- As for the ShowChanges button, currently we do not have plans to add the button. However, we will consider your feedback in any planning of changes we would make in the future and potentially come back to you for more input if you would be open to it? -- For the Technical Wishes Team Max Klemm (WMDE) (talk) 14:17, 16 July 2020 (UTC)
Not for thinkers
[edit]If I open the editor for an answer and then think long enough about my answer, the tool erases every answer which was saved in the meantime. I don't think that's the way it should work. Seewolf (talk) 11:23, 9 July 2020 (UTC)
- We just had a Sperrprüfung because of this behavior[2]and I could reproduce it easily. --~ Seewolf (talk) 11:26, 9 July 2020 (UTC)
- @Seewolf yikes, that's unfortunate to say the least. I added a bug report to Phabricator and will provided an update as soon as possible --~ Robin Strohmeyer (WMDE) (talk) 10:27, 10 July 2020 (UTC)
- @Seewolf: We haven't been able to reproduce the issue. You said you could do that. Can you explain in a little more detail how you did it? Thiemo Kreuz (WMDE) 14:26, 12 August 2020 (UTC)
Interface for discussion conflicts is great
[edit]I really liked the new edit conflict interface (the one with the radio buttons), but even with that, edit conflicts in discussions were still a pain. It was great for articles or editing the same text, but when adding to a discussion, I found myself, more often than not, just reopening the edit-interface and adding my text again because it was easier. I just got this new paragraph-based interface and it's amazing. I'm really excited about this feature and am thankful to everyone who is working on it!
My only suggestion is to add more helpful tooltips or labels. Having seen the previous radio-button interface, this one confused me a bit and it took me some time to figure out what would happen when I hit "publish". I think RoySmith gave a more detailed description below which was similar to my confusion. I remember when I first got the interface with the radio buttons that there were blue dots that were part of a tutorial or something? Could those be reintroduced? Wugapodes (talk) 20:39, 10 July 2020 (UTC)
- +1 Seewolf (talk) 12:07, 13 July 2020 (UTC)
- Hi @Wugapodes: , thanks for your feedback. We are glad to hear you like the new interfaces.
- Currently, there are no blue buttons in the talk page edit conflict interface, but we will take your feedback into consideration and see how we can improve the tooltips and help text as we roll out the interface to more wikis. --For the Technical Wishes Team Max Klemm (WMDE) (talk) 14:18, 16 July 2020 (UTC)
- +1 138.19.149.125 (talk) 02:42, 5 August 2020 (UTC)
False positive
[edit]I made this https://ru.wikipedia.org/w/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%9A%D0%BD%D0%B8%D0%B3%D0%B0:%D0%9B%D1%83%D1%80%D1%8C%D0%B5-%D0%90%D0%B4%D0%BC%D0%B8%D1%80%D0%B0%D0%BB%D1%8B-1941-1945/doc&diff=108478188&oldid=93717675 edit, clicked save and was shown the conflict interface. (perhaps the mouse could quickly click twice on the save button) But the interface compared my edit with the revision (the last in the history of the template) from 2018! Sunpriat 15:23, 31 July 2020 (UTC)
wrong interlanguages WP links translations
[edit]I've translated the en.WP article Coordination Council (Belarus) on the French Wikipedia (Conseil de coordination (Biélorussie)). The good interlanguage links to Russian Wikipedia when the articles doesn't exist in the english WP have been wrongly translated in the French translation into English Wikipedia links to english WP articles which do not exist ! TCY (talk) 15:45, 27 August 2020 (UTC)
- This does indeed sound like a bug. But:
- The interlanguage links are on Wikidata at d:Q98437710.
- I reviewed the history of fr:Conseil de coordination (Biélorussie) but couldn't spot an edit that fixes broken links, despite interlanguage links.
- How is this related to the edit conflict interface?
- I see that the first edit on fr:Conseil de coordination (Biélorussie) is tagged as being done with Content translation/V2. Maybe your report was meant to go to Talk:Content translation? Thiemo Kreuz (WMDE) 07:13, 28 August 2020 (UTC)
in hebrew it's written אתה יכול עזור instead of אתה יכול לעזור when using it
[edit]I said the issue in the title Omer abcd (talk) 17:28, 23 September 2020 (UTC)
- Thanks for the report! All translations (except English) are done on translatewiki.net. I had a look, but can't find this exact sentence. The word "לעזור" appears a single time in twocolconflict-split-header-hint. The other words appear a few more times in these messages:
- If you can't make the edits yourself, please let me know which message needs to be changed, and how. Thiemo Kreuz (WMDE) 08:56, 24 September 2020 (UTC)
Edit conflict template
[edit]On EnWikipedia we have {{Edit conflict }}. It would be very useful if this interface could automatically add the template to comments when triggered. Wugapodes (talk) 01:59, 29 September 2020 (UTC)
Up and down?
[edit]I suddenly see conflict interface is now for up and down. I have no idea which one survives when it saves, so I opted to just re-do the edit from the scratch. I don't know why this changes were made (or for what), but please clearly indicate WHICH version survives. — Revi 11:31, 15 October 2020 (UTC)
- Hi @-revi: This is the interface, which is shown for edit conflicts on talk pages. In this case both edits survives. You can just adjust the order of the comments and edit your own comment. Max Klemm (WMDE) (talk) 12:20, 15 October 2020 (UTC)
- That was not what it was originally implemented (Special:Permalink/4055984 screenshot - is what I expected).
- In that case, I think your messages on the edit conflict should be more clear that both will survive. You can't assume everyone knows "both will survive", as I demonstrated. — Revi 13:06, 15 October 2020 (UTC)
Add both
[edit]example edit 1
Header: Request article name1
name1 Cookie Hello the example look here sign1
example edit 2
Header: Request article name2
name2 Hello the look here urgent !!!! sign2
I want to add both headings to the page at the same time, but it forces me to choose one or the other because of some similarities between the edits.
(Header: Request article name1) (Header: Request article name2)
(name1 Cookie ... example ... sign1) (name2 ... urgent !!!! sign2)
(all of example edit 1) (nothing)
(nothing) (all of example edit 2)
It's probably hard to tell when to separate words but i'll report this anyway AltoStev (talk) 22:36, 16 October 2020 (UTC)
- The analysis in Phabricator was correct - I'm also going to note that the page was Wikipedia:Requests for page protection AltoStev (talk) 14:06, 20 October 2020 (UTC)
This is awesome
[edit]RESOLVED | |
Thanks. Let us know if problems emerge. |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Does it work with experimental source code editor 2017 that's still experimental I've recently deleted edit from one person on Wikipedia article and on discussion while in middle of conversation about me deleting her edits. Because of this I needed to diable auto experimental use feature on Wikipedia and disable the editor. Jcubic (talk) 18:04, 24 October 2020 (UTC)
- This feature should work independently of which editor you use. Did you wittiness any problems that you think are related to it? Not sure if I understand you correctly. Michael Schönitzer (WMDE) (talk) 01:41, 27 October 2020 (UTC)
- I had problem with overwritten data, but I'm not sure if it was when this feature was enabled, it was a while ago. Maybe I'll try to use new source editor (editor 2017) and see how it work, it's much better then the old one. Jcubic (talk) 08:55, 27 October 2020 (UTC)
Line breaks between paragraphs being removed
[edit]RESOLVED | |
This was an actual bug, which is fixed now, see phab:T266860. |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I have used the edit conflict interface several times, and while helpful, I am noticing that line breaks are being removed between paragraphs in the source code whenever I am choosing to retain the right-side edits. Y2kcrazyjoker4 (talk) 04:08, 30 October 2020 (UTC)
Edit conflicts (with myself)
[edit]Quite frequently I post a reply and find an Edit Conflict alert, but then discover that my post was published and that the edit conflict notification is actually with myself. It's as if I've double-clicked 'Publish', and my second (blank) edit is trying to overwrite my original response.
I find this quite annoying, though I do generally like the interface as I edit at a very active Forum (the English Wikipedia Teahouse). I am using Winndows 10 Home 64 bit, on Chrome browser Version 86.0.4240.198
My one suggested improvement is to provide a 'Click to copy contents' button so I can quickly select my reply text and ensure I don't completely lose it if things don't work. Nick Moyes (talk) 21:29, 18 November 2020 (UTC)
- Hi, that should not happen. Most likely it's not due to the Paragraph-based Edit Conflict Interface but due to some other changes on the software. We know that a team of the Foundation currently works on something very related. If this happens again, could you please send us an screenshot and the link to the edit? Michael Schönitzer (WMDE) (talk) 16:21, 3 December 2020 (UTC)
- Yes - will do that. Nick Moyes (talk) 17:26, 3 December 2020 (UTC)
- I can confirm this exact behavior. At least one other editor on cs-wiki also encountered this :https://cs.wikipedia.org/wiki/Wikipedie:Pod_l%C3%ADpou_(technika)#Edita%C4%8Dn%C3%AD_konflikt_na_diskusi . It seems to happen occasionally on discussion pages. The last time it happened for me today here: https://cs.wikipedia.org/w/index.php?title=Diskuse_s_wikipedistou:Polanka,_Jando%C5%A1,_%C5%A0%C3%ADma,_Pechmann&action=history . First version of the page (13:31 CET) is the result of clicking on "publish" button. At the same time, the editation conflict interface was inicialized, reporting editation conflict, presumably with myself. The second version of the page (13:32 CET) is the result of "resolving" that editation conflict.
- Editing in wikitext editor 2010, Chrome browser, desktop. Other editor on our wiki reports this behavior from Chrome browser on desktop as well, but also from Chrome on Android, classic (not mobile) view. Vachovec1 (talk) 18:45, 3 December 2020 (UTC)
- I have received some responses from editors at the en-wiki Teahouse (see here) who have also experienced edit conflicts with themselves. I have also captured a screenshot, as requested. See here.
- Having tried saving a few edits with very rapid double-clicks of my mouse, I am now starting to wonder whether this might actually be more of an issue caused by over-responsiveness of the blue 'Publish' button which ought not to be able to act on a second mouseclick (or tap) immediately afterwards at all. I tried this intentional rapid double-click on my own talk page, which did cause an edit conflict report . Resolving the conflict only modified the timestamp (rather than adding in a duplicate copy of what I'd posted), but the time wasted in wondering why one has got an edit conflict is probably quite significant - and especially so on busy, talk pages and help fora.
- Maybe the folks behind this tool can push to get that over-responsiveness of the mediawiki software Publish button addressed if, as now seems probable, the fault actually lies elsewhere? Nick Moyes (talk) 16:13, 8 December 2020 (UTC)
Bug:for some reason, undoing an edit activates this feature for no reason sometimes
[edit]Let me explain, in the Hebrew Wiki I'm checking edits a lot, but now for some reason, every time I use the "undo" button and save edits, it appears that I got a cconflict messege even though there was no edit after the edit I reverted, for example, this edit gave me an alert and activated the tool while the verison history doesn't show any edit between the IP user and me... Can you check the problem? Omer abcd (talk) 20:46, 23 November 2020 (UTC)
Awesome stuff
[edit]The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Great tool; well done to everyone who worked on this, for making something really cool and solving a tough problem. Enterprisey (talk) 10:04, 3 December 2020 (UTC)
del tag and white-space: pre-wrap
[edit]RESOLVED | |
Fixed. |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Please add rule .diffchange-inline { white-space: break-spaces; }
because Google Chrome incorrect displays diffs with deleted trailing spaces, which tagged inside .diff-deletedline
. See Diff Test in Google Chrome. ~ DonRumata (talk) 13:31, 21 December 2020 (UTC)
- Thanks for the report, Unfortunately this is unrelated to the two-column conflict-resolution interface. However, thanks to the super helpful example it was easy to create a patch, see gerrit:651181. Thiemo Kreuz (WMDE) 14:15, 21 December 2020 (UTC)
- You accidentally left the old rule
white-space: pre-wrap;
. DonRumata (talk) 14:20, 21 December 2020 (UTC) - That's called a fallback for browsers that don't understand the value further down. MediaWiki still needs to support Internet Explorer 11, that's why I did it like this. Thiemo Kreuz (WMDE) 15:02, 21 December 2020 (UTC)