reproduced here using the original article contents:

Thanks! Task should be resolved then.

jobs are all moved to kubernetes, however it seems there are 16 running jobs on GridEngine left that are stuck, don't know if and how I can abort them.

Done.

Thanks for having a look on this, we will check on thursday if there's still a problem.

I edited the local messages; don't know if jqueryMsg getting enhanced is likely, if not the task could be closed.

This is T308398 I guess

dewiki also uses some of the thumb classes (thumbinner, tleft, tright, thumbcaption) in templates and article text. Will they be preserved for a migration period? And is it possible to give a complete list of classes that will be changed/renamed?

Came here as a part of the ongoing discussion in dewiki, IMO the talk page behaviour should be consistent over all talk pages; enabling topic containers on NEWSECTIONLINK pages could be an extra option.

No problem, the maintainer of our most important template tool is informed and I'll check what has to be changed locally onwiki.

Okay, thanks. Thought there would be another announcement before it starts, but I haven't followed this process that close so I may have missed some previous messages and deadlines.

Has writing the old colums already stopped on dewiki? There are currently ~14000 empty ones via https://quarry.wmcloud.org/query/66578; by-article example: https://quarry.wmcloud.org/query/66579

Thanks! Another observation I made: the message also appears on talk page redirects with ?redirect=no (e.g. https://de.wikipedia.org/w/index.php?title=Modul_Diskussion:Radsportplatzierungen&redirect=no). This should also be avoided IMO.

I like the idea, but from an UX viewpoint it would probably be better to have the clear button next to the reason input field.

Should be resolved with https://gerrit.wikimedia.org/r/772046

The move form tranformation is done by https://de.wikipedia.org/wiki/MediaWiki:Gadget-old-movepage.js

Seems like the same as T225366

I think the problem is caused by monobook's conversion to responsive/non-responsive. .monobook-capitalize-all-nouns becomes body:not(.skin--responsive) .monobook-capitalize-all-nouns resp. body.skin--responsive .monobook-capitalize-all-nouns and that doesn't match anymore as .monobook-capitalize-all-nouns is a class assigned to body.

Just for the record: dewiki uses it ~2000 times: https://de.wikipedia.org/w/index.php?search=insource%3A%2Fmw-datatable%2F&title=Spezial%3ASuche&go=Artikel&ns0=1

Seems like it doesn't work. Everything is lowercased at https://de.wikipedia.org/wiki/Wikipedia:Hauptseite?useskin=monobook

Yes, the pages are looking fine again. Thank you!

for dewiki main page, it seems like the class(es) are stripped from the h2 elements and replaced by ext-discussiontools-section which leads to the broken look.

The behaviour of the watch checkbox seems to be inverted. In addition to the effect mentioned by Count Count: if you try to protect a currently unwatched page, the 'watch page' checkbox is set by default.

This recently came up again on the administrator's noticeboard on dewiki; the recreate-message appears after the editnotices and the newarticletext that is quite long (https://de.wikipedia.org/wiki/MediaWiki:Newarticletext-0) so in the end will only be shown after scrolling down which most users won't do. It should at least be moved to the top of the flyout as it is actually a warning rather than just information messages like newarticletext.

Side effect to this: both revisions are shown on Special:Undelete (with correct summary and tags), but clicking on one timestamp always leads to the same text.

dewiki has made the change today. I think we found a clean and sustainable solution.

Has this been reverted? dewiki seems to have the proportional font back. In addition, diffs shown in unreviewed revisions of a page (FlaggedRevs) did not use the monospaced font even before today.

Some new cases today:
https://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=198231736#Verschiebung_funktioniert_nicht,_Seite_ist_auf_einmal_ungesichtet

@matej_suchanek @Toni_Mueller that could be the reason. I found a link on dewiki's administartor's noticeboard containing enhanced=1 added on the day when the first complaints popped up. An user also already seemed to be on the right track.

probably the same issue led to inquiries at dewiki: https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt#Fataler_Ausnahmefehler_des_Typs_%E2%80%9ELogicException%E2%80%9C

Just noticed this behaviour on dewiki: https://de.wikipedia.org/w/index.php?title=Kohlenstoff&type=revision&diff=192062719&oldid=191962285

It's simply difficult to read words which have linebreaks at unusual positions (e.g. after the first letter, this disturbs the reading flow). I often read diffs and would like to have word wrap only around spaces or something like hyphenation.

In T158458#3188256, @Catrope wrote:

This should be done now.

In T158458#3161869, @Kipod wrote:

BROKEN WORKFLOW :
some (many) patrollers work off "recent changes" page, where they click on the page (or on "prev", or any other "diff" link), examine the edit, and return to recentchanges page.
until this change, the "prev" link was painted as "visited", but now, the "visited" page has the "freomrc=1" parameter, while the link on the rc page does not. this makes the link non-visited, and the browser paints it as such.

Sorry, but at the moment this seems to be unusable for the article namespace:

• There is no way to set the widths/heights of the images - the gallery resizes randomly for every image
• The gallery caption size is a way to big especially if you have small images
• the extended mode (clicked on the center icon) is not very intuitive and stylish.
• mode="slideshow" and perrow="..." causes vertical scrolling

This is because 2/24 = 0,83333... which gets cut to 15 decimals in the html form. But we check the &days= parameter in php to be exactly 2/24 which returns false and so the option doesn't get selected.