Since I've stumbled upon this thing again when cleaning up things on wiki, I've submitted a patch that makes it configurable what (additional) CSS classes are present on the PhonosButton element (noexcerpt included). This can be done in two ways:

• per-wiki, using $wgPhonosButtonClasses, which can be set to eg. [ 'noexcerpt' ] to preserve the current behavior;
• per-instance, passing class attribute to the <phonos .../> tag, which overrides (is not merged with) the above, eg. <phonos class="" ... /> will suppress extra classes that are added by default on the given wiki and <phonos class="lorem-ipsum" /> will make Phonos button with only lorem-ipsum as the custom class.

It appears that the mass message hasn't been delivered to some pages (eg. pl:Pomoc:Pytania_nowicjuszy), with an error code saying "This page will be moved and archived" to Pomoc:Pytania nowicjuszy was skipped because _target was in a namespace that cannot be posted in. This seems to be the case also for ptwiki help desk.

Unfortunately, fix to T379218: New pages are not autoreviewed despite creator having autoreview right doesn't fix this issue, so moved pages still become unreviewed.

If anyone is interested in that, I've created a bot to automatically review moved and created pages (this is the bot that Wargo talks about above). It works in real time, based on EventStreams, so as to make an impression that this issue is no longer present. (Review log from plwiki).

In T379218#10304174, @binbot wrote:

For the time the issue will be corrected, I hacked a little scipt that reviews new pages that were edited only by trusted users. Please forward the information to the bot owners in your wiki.
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/huwiki/temp_review.py

Yet another place where I noticed this wrong link color is the [dismiss] link in the site notice (can be seen on the page linked in original description). This is the same case of role=button

This change causes link-buttons like (thank) on RecentChanges to use old (pre-July 2022) link color and do not adapt to the dark mode, example (from testwiki RecentChanges) below. This is not particularly visible in light mode (only if you know, you'll spot that).

In T377553#10249810, @STran wrote:

Would this imply a level of optionality that isn't present? The filter is going to forcibly set itself to protected if it uses a protected variable.

This message is edited and maintained on-wiki: https://en.wikipedia.org/wiki/MediaWiki:Citethispage-content where local admins and interface admins can adjust the style tag.

In T368380#10183841, @Eugene wrote:

Locally, I am unable to reproduce this issue.

The red link issue could be also overcome by making the links inherit the font color from the proper token (as most code editors do). This would be my preferred option but I'm not going to die for it.

I've found out that this issue affects 13 messages in the Impact module. They rely on {{GENDER:$1|...}} (where $1 is current user name), which works only at the server side. Client side code should use {{GENDER:|...}} which refers to the current user. I'll submit a patch for this to fix those messages and remove unnecesary code for getting the current user name to be put as $1 param to the messages.

This feature fails for jsdoc for objects as well:

@param {{ key1: valueType1, key2: valueType2 }} paramName

is linked to Template:key1: valueType1, key2: valueType2 even though it's unwanted. This is a valid template name but it can be checked for jsdoc keywords presence (in fact, I did it in my script for links in source code).

Here, it can be seen that the same IP got blocked thrice at the same time: https://pl.wikipedia.org/w/index.php?page=Wikipedysta%3A103.87.212.123&title=Specjalna:Rejestr&type=block&uselang=en (and indeed, there are three entries in the special page listing blocked users).

In T372048#10129365, @Nikerabbit wrote:

This is not unique to Translate. Common workaround is to use explicit parameter name 1=, which you already mentioned. Also the nowrap option of Translate could be used.

I believe that it should work either as option 2 or option 3 - so either functionality of a popup or of a dialog, not a mix of those.

I've applied a hotfix on plwiki, maybe others will find it useful given the backport happens in over two days: https://pl.wikipedia.org/wiki/MediaWiki:Vector-2022.js

I found EditCheck to also activate in Wikipedia: namespace on plwiki (apart from User: as flagged in the task description): https://pl.wikipedia.org/w/index.php?diff=74668368

For the record, EditCheck on plwiki has been just enabled in T373079: Enable EditCheck on Polish Wikipedia

EditCheck has been deployed and is now available for newcomers (<100 edits) without the URL flag.

I don't have a strong preference here – either delete those two buttons or make it a proper dialog that appears on click and that is modal (completely or dismissed by clicking outside).

Given that the patch has been reviewed, I'll go on with backporting it on Monday, 2 September.

In T373079#10106990, @ppelberg wrote:

However, we'd welcome you writing a patch provided someone on the Editing Engineering team can review it before you move forward with backporting.

In T373079#10089090, @ppelberg wrote:

Wonderful. Next Tuesday it is, Tufor!

I'll ping you here should that date need to change for any reason.

What's interesting, occurences of missing revision windows seem to be correlated between wikis. Based on the @matej_suchanek query, I've checked bigger wikis from s2 (plwiki, itwiki, nlwiki, svwiki) and it turns out that often (especially during the severe windows) when there are missing RC entries on one wiki, there are also missing ones on another wikis within a few minutes.

In T71550#10069925, @Jdlrobson wrote:

I guess MediaWiki:Gadget-ReferenceTooltips.js, also has been moved into core, but I'm not sure what work is involved in removing it as a default gadget for anonymous users on en.wikipedia.org?

Even though the specific layout of the table could be indeed tweaked as mentioned above, I think that the alignment of the buttons and links in the same columns is beneficial overall and I second keeping this special page displayed as a table

As a plwiki admin and patroller I think that this change will be beneficial and helpful for people

I've prepared a patch for that.

The issue has been reported in plwiki tech village pump as well: https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#X_zmian%28a%29_oczekuje_na_przejrzenie

I've browsed through the move log at plwiki and the issue started appearing between Wed, 2024-06-19 19:39 UTC (the last move that was automatically reviewed) and Thu, 2024-06-20 09:11 UTC (the first move that wasn't auto-reviewed but should be).

Here's screen recording of me reproducing the bug on plwiki: (I was doing it in Help: namespace but it's not significant for the problem)

In T361717#9882777, @DTorsani-WMF wrote:

Although the blue spectrum has a blue250 value, in order to be more visually balanced with the diff removed background color of yellow500, we use blue300 instead to address the goal mentioned above:

The task was also inspired by plwiki configuration changes to limit lint errors introduced by user signatures: T364769 and T362414 that for example stopped legacy <font> tags from being inserted.

Sure, no problem

The config change has been deployed.

For reference, here is some description of the script as well: https://meta.wikimedia.org/wiki/User:Msz2001/AbuseFilter_analyzer

In T362856#9749606, @Wargo wrote:

They had problems T363086 with deployment procedure and I don't know how they finalized it.

I can replicate those on Windows 11 + Edge 124, so the result seems to be independent from the OS newline convetions. Tested /tools on plwiki and both /tools and real filter on a local installation of MW 1.40.

In T363628#9750833, @suffusion_of_yellow wrote:

If that doesn't work, try using new_wikitext_pst.

I've just copied the content of Użytkownik:Swam_pl/brundopis3 to Użytkownik:Msz2001/brudnopis (examine) and the result is the same: the edit is recognized in an examine mode but not while saving.

In T362856#9749452, @Wargo wrote:

No, from 23 to 25. Last event was 18:20, deployments are on 20:00 (in Poland)

The patch that @KartikMistry mentioned was deployed on 22 April to plwiki, but it seems that it doesn't completely prevent unqualified users from publishing translations to mainspace. The edit filter for that caught two cases on 24.04. and 25.04.: https://pl.wikipedia.org/w/index.php?title=Specjalna:Rejestr_nadu%C5%BCy%C4%87&wpSearchFilter=38&uselang=en

I can confirm this on plwiki as well, as reported in https://pl.wikipedia.org/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Wyszukiwarka_si%C4%99_popsu%C5%82a (permalink).

In T362139#9724671, @matmarex wrote:

I'll be honest, I'm not sure how it's supposed to work. But I think I managed to restore how it worked.

I set up demo wikis to compare:
Before the bug: https://patchdemo.wmflabs.org/wikis/777f1587e8/w/index.php?title=Test1&action=edit&undoafter=152&undo=153
Current buggy version: https://patchdemo.wmflabs.org/wikis/1010d4fce1/w/index.php?title=Test1&action=edit&undoafter=152&undo=153
After the fix: https://patchdemo.wmflabs.org/wikis/83a92cb3f0/w/index.php?title=Test1&action=edit&undoafter=152&undo=153

If someone here feels like they understand it, I'd appreciate if you could test on those demo wikis as well.

Deployed to wiki

The change was deployed today.