(Previously discussed at T355028: Visual editor skin requirement not listed (#mw-content-subtitle))

The patch seems to resolve the issue for all skins except Minerva (see T417372#11616493), so I want to say that this is a Minerva bug at this point.

Tested the patch on several skins:
(demo wikis: before: https://patchdemo.wmcloud.org/wikis/c93b0ed9a0, after: https://patchdemo.wmcloud.org/wikis/844a4c67e5)

@PerfektesChaos Good point, this patch will do that. We probably overlooked it because the introduction is empty by default.

Updated plan, since things got a bit more complex with the added dependencies, and a migration from WikimediaEvents to WikimediaCustomizations:

1. (This week) Deploy Configure rate limit class for global bots to avoid changing existing behavior
2. (Next week) Wait for all of the patches to roll out with the train
3. Deploy Configure rate limit class for local bots (and local-bot global group)
4. Run the CentralAuth:UpdateAutomaticGlobalGroupMembership maintenance script on each wiki

After this change, the links are marked as uneditable, and do not cause corruption when touched. For making them appear right and be editable, see the subtask.

Oops, sorry about that. Thanks for fixing it for us.

The fix will be deployed to Wikimedia wikis this week, on the usual schedule. Thanks @SomeRandomDeveloper, and thanks for the bug reports everyone.

It looks like this was done as part of T406003: Share the UI generation between Special:UserRights and Special:GlobalGroupMembership.

I don't think this is worth implementing over one mistake.

This was at least partially implemented in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1195690 and related changes (GlobalGroupAssignmentService).

MediaWiki has some cross-wiki capabilities, but they are not complete in this area, and so I had to make some workarounds. I think this is acceptable, but if it isn't, another approach we could take would be to insert the log entry from a job that would always run on Meta-Wiki, but could be scheduled cross-wiki (we do something similar for account vanishing).

Someone will have to figure out why this happened if we want to reapply…

I created the group: https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions/local-bot

Hi @STei-WMF, I added a draft here: https://meta.wikimedia.org/wiki/Tech/News/2026/07.

Yeah, this is my doing from T393289: Deploy user style to reduce bot comments on Phabricator.

Uhh, maybe I'll just take out the $3 for now, it's not very important.

Does this mean you want to move all messages from WikimediaMessages and WikimediaEvents? I don't really understand why, either. It would make sense to do it for any messages that will be used by WikimediaCustomizations code, but otherwise, they seem fine in their current places.

This will need one more deployment to remove the old private mitigation code (otherwise both versions run, and which message the user gets is basically random). This can be done after the new code is deployed with wmf.15.

I wasn't fast enough to comment on Gerrit before the patch was approved. The new patch causes a regression in T349436: Kerns are clipped from sides of sticky header title.

With T290778 having been resolved, newcomers should receive a notification from topic subscriptions when they get a reply. Does it work?

In T415588#11576487, @NguoiDungKhongDinhDanh wrote:

What permissions, exactly, will this group contain? I assume "higher rate limits" means apihighlimits and not noratelimit. If it's just the former, then wouldn't apihighlimits-requestor suffice? Several bots have been granted that group already.

In T397224#11376026, @Johannnes89 wrote:

Another weird case: https://en.wikibooks.org/w/index.php?title=Special:Log&logid=5292619 caused https://en.wikibooks.org/wiki/Special:Log/gblrights even though the relevant local group (CU) wasn't even changed – and local admins shouldn't be able to do anything that affects global groups: All local/global group changes (CU/OS/GS) which trigger granting/removing GTAIV can only be done by stewards.

As discussed today, I sent a note to the Stewards asking for comments: https://meta.wikimedia.org/wiki/Stewards'_noticeboard#Planned_addition_of_a_global_user_group:_'local-bot' and proposed a message in the next Tech News: https://meta.wikimedia.org/wiki/Tech/News/2026/07.

Object.assign() is often used to insert raw parameters in parsed messages.

In T215517#11564200, @gerritbot wrote:

Change #1234524 had a related patch set uploaded (by Func; author: Func):
[mediawiki/core@master] gallery: Avoid width error when overlapping with floating elements
https://gerrit.wikimedia.org/r/1234524

If you change the order to display whichever site's data loaded first, that would resolve my concerns, but I don't really use GlobalWatchlist daily, and I don't know how much people rely on the order. I hope someone else can comment on that.

In my experience the sites are currently always shown in the order defined in settings. I thought it was a feature :)

My proposed patch for T320871: Special:Log should show action combo box when switching log types happens to fix this issue (since it effectively creates separate subtype fields for every log type, instead of having one field that has different allowed values depending on the log type).

Nice find @A_smart_kitten!

I filed T416057 for the underlying issue causing the warning to be dropped during the redirection.

If this change would cause the page content to shift as the data for each wiki comes in, users would still have to wait for every wiki to be finished before they can start using the page. It may feel worse than before, even if it would be faster.

Thanks y'all.

It works on my phone too!

Probably caused by rELUAe9b011351735: Use PHP8 constructor property promotion and readonly properties / https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1233835

On some further testing, this also affects pages that use {{DISPLAYTITLE}} to override the title display, e.g. https://test.wikipedia.org/wiki/Äöü – note the small text used for the page title:

Caused by rSVEC49271cc32621: Fix sticky header TOC spacing and TOC disappearing on viewport change / https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1229147

The fonts are obviously wrong. I filed T415932 for this. I don't think it's a regression from this change, though.

I think I would remove it, and just wrap the "Tags:" in <bdi> like everything else. It seems like the most complex and least valuable part of your change :)

Deployment plan – please review:

1. Document what the 'local-bot' group does, somewhere on Meta-Wiki (unless we can just link to this task?)
2. Deploy the WikimediaMessages patch
3. Create the 'local-bot' global group using https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions (grant it 'read' permission only)
4. Deploy the operations/mediawiki-config patch
5. Deploy the WikimediaEvents patch – this will start using the configured rate limit class ('approved-bot') instead of the previously hardcoded one ('global-bot'). It's not clear to me whether we're using these for anything already; if we do, we should keep using 'global-bot' even though it's inaccurate and change it later.
6. Deploy the CentralAuth patch (this is just the maintenance script)
7. Run the CentralAuth:UpdateAutomaticGlobalGroupMembership maintenance script on each wiki

I don't think I understand why we have to fetch the "Tags:" system message in a different language from the rest of the interface, and *only* do this for Wikidata rows? It seems that would just make them inconsistent. The tags for every wiki are displayed in that wiki's language.

Thanks for the fix @InsertMode!

Open questions include:

• Is new code encouraged to use Status and/or StatusValue?
  • Which one? Are both encouraged, or is one discouraged?
  • Which features? Are some specific features (e.g. warnings, or OK-but-not-good status, or statusData) discouraged?

Added to Tech News draft: https://meta.wikimedia.org/w/index.php?title=Tech/News/2026/06&diff=prev&oldid=29983024

I think, based on the comments above, that we can say that this is declined, and this behavior of the job queue will not change. Given that we fixed the only job type (that we know of) which had a problem with this, I think this is fine.

In T260220#11523128, @IKhitron wrote:

Well, @matmarex, I made a patch, created a Patch Demo, see https://3a4fde509c.catalyst.wmcloud.org/wiki/Special:GlobalWatchlist for Alice.

• Do we need to remove the (<Log action performer>) at the end because it is already in the message?
• Do we need to remove the page name from the same reason?

I made the same for Bob, who is a checkuser now, and there is no button there, so, waiting for your answer from before. Thank you.

Hi @AnshdeepThakur, what is the "MediaWiki cohort"?

Some of the reply buttons work for me, others display the message "Could not find the comment you're replying to on the page. It might have been deleted or moved to another page.".