Sorry! I migrated Klexibot some time ago already, but forgot to close this task here. I see the bot running on Kubernetes:

I didn't even officially request access to the tool yet and already got my first task assigned. 😂 Thanks, I guess...

Migration completed successfully: Erinnermich is running on Kubernetes now.

German mentor here, supporting this proposal (after aligning with my fellow mentors here). And if it's too complex to solve in one step, we'd suggest to start with the following first changes:

Why is this column needed anyway? One of our mentors already expressed her resentment about this kind of forced transparency (here, in German), and I don't see a significant advantage of having this data collected on this page. Can we remove it completely, please?

No need to apologize. I'm aware of the upcoming migration since a couple of months and even tried to do it for my tools back in May (?), but failed due to my inexperience with Kubernetes and decided to (temporarily) settle with the Buster alternative instead. I'll give it another try soon.

No need to apologize. I'm aware of the upcoming migration since a couple of months and even tried to do it for my tools back in May (?), but failed due to my inexperience with Kubernetes and decided to (temporarily) settle with the Buster alternative instead. I'll give it another try soon.

The same error is back again (as reported in various discussions in the German Wikipedia).

Ah, ok. I somehow missed this second string. Thanks!

Not sure whether this is worth a new task: The newly activated mentor dashboard in the German Wikipedia is shown as "Mentor dashboard" in the top navigation, although the correct translation ("Lotsen-Verwaltungsseite") was already added months ago: https://translatewiki.net/w/i.php?title=MediaWiki:Growthexperiments-mentor-dashboard-title/de&oldid=10241188

known consequence of wikitext not yet supporting multi-line comments.

I understand why some might find the current syntax hard to use, but claiming tables or other things cannot effectively be embedded in talk page comments is just wrong. Taking the original example from above:

A new link was added yesterday, and I just tried it myself: The task type is still available:

Huh? I just corrected the description, but according to the log, I also changed Prio and Subcribers?! Sorry about that, don't know how this happened.

I'm pretty sure it's the Vector skin: I can reproduce the problem in all browsers both logged in and logged out, but it's gone once I switch to any other skin.

Another report. First edit by a new user. And yes, he/she confirmed to also use a browser plugin.

I'm dumb. Or need a coffee. Or both. Text is correct.

Reported again in https://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/R%C3%BCckmeldungen#Bearbeitungskommentar

Ah, thanks - I didn't know about that one. But wouldn't a change of the rendering engine also fix T212085?

To add a current example to the discussion:

Also happening in the German Wikipedia:

This issue (Citoid replacing given URLs with the ones found in meta data) does not only cause problems with anchors, but also with sites using short urls in their meta data:

Yes please! And while you're at it, please also consider adding a warning ("Your new value is not the preferred value yet") or even adding a checkbox ("Set this entry as the new preferred entry") when entering new values (as suggested here: https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Wunschparkplatz#Hinweis_auf_Bedeutung_der_R%C3%A4nge_bei_der_Wikidata-Eingabe)

@Esanders : Is this the only change? If yes: Where does "Show preview" lead to? If it's the same page as today, I would have no chance to add an edit summary / comment between checking the preview and publishing the change. :-(

Oh! The original bug reported by the task author (Copy {{Other uses|Target (disambiguation)}} from HTML, e.g. https://en.wikipedia.org/wiki/Template:Other_uses The paste logic detects this as non-plain text HTML (which it is) and so converts it to wikitext, so the {{ are <nowiki>'d) is also reproducable in Edge and Firefox. So the bug seems to be more prevalent in Chrome, but some cases can be reproduced in other browsers as well.

I did some more tests:

@Deskana: Just tested it again with Chrome 50 in Windows 7. (I know it's outdated, but I tested it with Chrome 64 earlier - same results) Both Wikitext 2017 (Beta) and Syntax-Highlighting (Beta) are enabled in my settings.

@Deskana: Now that you can reproduce it, this issue should no longer be in status "stalled", should it?

Thanks for the tip with Ctrl+Shift+V. I was tearing my hair when I tried to manually archive a discussion section by copying it to an archive page. I agree with @dialmove and others above: This is not intuitive and should be fixed (e.g. by asking the user after pressing Ctrl+V whether he wants to convert the text or not).

@Jdforrester-WMF : We got another complaint about this behaviour in the German Wikipedia (https://de.wikipedia.org/wiki/Wikipedia:Technik/Text/Edit/VisualEditor/R%C3%BCckmeldungen#Betreff_Plazierung_eines_Buttons), and I agree with the creator of this task: Discarding all changes without warning when leaving a dialog window should not be the standard behaviour. Especially when the same dialog window is modal for all other types of references (i.e. you can't discard a manually entered reference by leaving the window).

Another complaint regarding this issue in the German Wikpedia:
https://de.wikipedia.org/w/index.php?title=Wikipedia:Technik/Text/Edit/VisualEditor/R%C3%BCckmeldungen&diff=170376196&oldid=170337810

@clel: There's a "Attention!" note when opening the editor, stating that you're editing an older version, which will become the current version after saving. It also says that clicking the "Edit" button again would fix this issue. However, clicking this button does not have any effect at all. After closing this note, there's no further warning message when saving your changes.

As a workaround on the desktop, you can hit the Escape key to return to a usable state. But yes, this should be fixed.

Additional feedback from a German editor regarding this issue:
"Wikipedians delete the '↵' in VisualEditor and replace it with a space. But this character '↵' only indicates that a break was added to the source for better readability, which is automatically translated into a space. It's often used in long citation blocks, for example. This' ↵'-character makes the Wikitext / source text more readable. The good readability of the source text in the source editor (Edit window) is still one of the quality indicators explicitly mentioned in our guidelines for good articles. The meaning in the VisualEditor is only that the user should insert a new text not to the left but to the right of the '↵' character. Just simply so that the line break in the source text remains directly behind the left character. But, when looking at the instructions, this subtlety is not mentioned. Also, no warning is displayed when you delete the '↵' character in the VisualEditer. Apparently the character can not be inserted in the VirtualEditor any more, if it was deleted. [...] I would hope that there is a warning when deleting the character or a tooltip when the mouse is hovering above the character. Thank you."

Here's another example from de-wiki (not purged yet):