Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• Jump to bottom
• New topic
• All village pumps

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for 5 days.

« Archives, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225

Tech News: 2025-43

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• To optimize how user data is stored in our databases, the saved preferences of users who haven't logged in for over five years and have fewer than 100 edits will be cleared. When those users return, default settings will apply. [1]
• View all 20 community-submitted tasks that were resolved last week. For example, there was a broken link from the GlobalContributions interface message to the XTools GlobalContributions page which has now been fixed. [2]

Updates for technical contributors

• The work to reroute all traffic to API endpoints under the rest.php route through a common API gateway is now complete. If any issues are observed, please file a phabricator ticket to the Service Ops team board.
• Edits to Wikidata references or qualifiers will now be shown in RecentChanges and Watchlist entries on other wikis less often, reducing unnecessary notifications. This will reduce the overall quantity of 'noisy' entries. Wikidata's own pages remain unchanged. [3]
• Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 19:32, 20 October 2025 (UTC)

What does users who haven't logged in for over five years mean, exactly? With WP:SUL, when I log in here, and I visit another WMF wiki, I'm also logged in there. But in order to preserve my settings on other WMF wikis, do I actually need to (a) log in as a separate act on each WMF wiki in order to generate a fresh login cookie; (b) log in on en.wp and visit each WMF wiki in order to send an existing login cookie; (c) log in on en.wp and ignore the other WMF wikis? --Redrose64 🌹 (talk) 21:13, 21 October 2025 (UTC)

It's not very clear, since the person responsible seems to be making several unwarranted assumptions as to how things actually work. But it does seem like if whatever they're looking at doesn't indicate activity on the specific wiki, they're intending to delete. Anomie⚔ 22:29, 21 October 2025 (UTC)

It appears from this comment on phabricator that the decision will be made wiki by wiki, so if there's a WMF wiki that you've not logged in to for five years then your settings there will get cleared. (Though global settings will still apply, of course.) DLynch (WMF) (talk) 00:21, 22 October 2025 (UTC)

@DLynch (WMF): if there's a WMF wiki that you've not logged in to for five years - this is itself unclear. Please see my original question: is logging in on en.wp sufficient, or do I need to explicitly log in on each WMF wiki as a separate action? --Redrose64 🌹 (talk) 17:42, 22 October 2025 (UTC)

Each wiki is separate. DLynch (WMF) (talk) 20:16, 22 October 2025 (UTC)

So it's (a) log in as a separate act on each WMF wiki in order to generate a fresh login cookie. This seems to be requiring a great deal from users that want their settings to be preserved. --Redrose64 🌹 (talk) 20:04, 24 October 2025 (UTC)

Maybe a more concrete example would be clearer. If I log into Meta and then visit Commons, I am automatically logged in there as well, thanks to SUL. Have I updated my user_touched on both Meta and Commons, or only Meta? jlwoodwa (talk) 19:38, 27 October 2025 (UTC)

I believe that then you would have updated it on both, because the SUL system logs you in when you visit. DLynch (WMF) (talk) 17:22, 29 October 2025 (UTC)

Tiny subheadings on mobile

Wikipedia screenshot - 2025-10-22 - tiny subheadings on mobile

Recently, using Firefox mobile on my Android phone, if I visit a page in "Desktop" view, the subheadings are miniscule, as the above screenshot shows. Is this a known issue? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:36, 22 October 2025 (UTC)

@Pigsonthewing, desktop mode doesn't work well with skinny screens. I'd advise sticking in mobile view on mobile devices. JayCubby 14:15, 23 October 2025 (UTC)

Thank you. I'm not asking for advice on how to use Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:38, 23 October 2025 (UTC)

Having edited on mobile using the desktop site for a couple of years I would say the exact opposite. The mobile site is barely usable on any device.
Is the header small on Chrome or just Firefox? -- LCU ActivelyDisinterested «@» °∆t° 18:55, 23 October 2025 (UTC)

@Pigsonthewing Which browser version of Firefox mobile are you using? Which skin (I believe this might be Vector but I'm not 100%)? Do you get the same problem in safe mode? If not, which gadgets do you have enabled? Could you also share what your Firefox accessibility settings are? (those arE: Automatic font sizing, font-size, zoom on all websites and available via the settings).

I can't replicate this personally right now but I have a theory on what is happening. I just need a lot more information. 🐸 Jdlrobson (talk) 22:13, 23 October 2025 (UTC)

Just seen this; thanks. I'll play around over the weekend and get back to you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:31, 27 October 2025 (UTC)

anchor encoding changed?

Tracked in Phabricator
Task T407617

I'm pretty sure it used to be that space characters in an anchor were replaced with a plain underscore character (low line: _; U+0095). That seems to have recently changed and doesn't match the uri encoding:

• {{anchorencode:string with spaces}} → string_with_spaces → string_with_spaces
• {{urlencode:string with spaces|WIKI}} → string_with_spaces → string_with_spaces

So now the anchor encoding does not use the single character _ but instead uses the html numeric entity string _. Note that the anchor encoding does not match the url encoding.

This is known to be breaking {{sfn}}, {{harvnb}}, etc templates that link to a {{Template:National Heritage List for England}}:

• {{harvnb|Historic England|1087857|ps=none}} → [[#CITEREFHistoric_England1087857|Historic England & 1087857]] → Historic England & 1087857

The above {{harvnb}} (by way of Module:Footnotes) uses mw.uri.anchorEncode() and should link to this template without error:

• {{NHLE |num= 1087857|desc= Moore's Farmhouse, Bamford|access-date= 28 February 2022|mode=cs2}}

  Historic England, "Moore's Farmhouse, Bamford (1087857)", National Heritage List for England, retrieved 28 February 2022

It does link. Because the target template is a wrapper template around {{cite web}} and because the {{NHLE}} template doesn't expose the information necessary for Module:Footnotes to identify its anchor ID, Module:Footnotes emits an error message. We get round that by use of a whitelist. The whitelist links a template name with a CITEREF anchor ID. In this example case, the whitelist lists {{NHLE}} with the anchor ID lua pattern {'Historic_England%d+'}. That pattern was added to Module:Footnotes/whitelist at this edit 1 December 2024. The whitelist pattern expects a simple underscore in place of the space character in 'Historic England'.

So, was the change to use the html numeric entity string _ intentional? Is it permanent? Why was it done?

—Trappist the monk (talk) 14:21, 23 October 2025 (UTC)

Seems like a bug report in Phabricator would be appropriate. I note that {{subst:anchorencode:foo bar baz}} is giving this behavior here and on testwiki, but not on https://en.wikipedia.beta.wmcloud.org/ or a local wiki running trunk. Which makes me wonder if it's a side effect of some attempted security patch. Anomie⚔ 15:14, 23 October 2025 (UTC)

It's indeed probably caused by the same security patch as T407617. Matma Rex talk 15:32, 23 October 2025 (UTC)

"Is there a patch for the patch?"

-

"No, at least not in Wikimedia production."

How does this get fixed? The current situation isn't acceptable. -- LCU ActivelyDisinterested «@» °∆t° 16:19, 24 October 2025 (UTC)

Developers are working on a "patch for the patch" now. Matma Rex talk 08:42, 25 October 2025 (UTC)

Thanks Matma Rex. -- LCU ActivelyDisinterested «@» °∆t° 20:22, 25 October 2025 (UTC)

I've just deployed an updated patch that should fix the template issues discussed within this thread. Please let me know either here or on T407617 if the issues persist. SBassett (WMF) (talk) 21:30, 30 October 2025 (UTC)

I've just checked the examples given in the original thread on Help talk:Citation Style 1 (Listed buildings in Bamford, Burleigh Pottery, and Cleveland Point Light). The articles required purging, but upon doing so all the error messages were cleared. Thanks for the fix. -- LCU ActivelyDisinterested «@» °∆t° 21:46, 30 October 2025 (UTC)

Not just NHLE. For example, this edit by Nempnet (talk · contribs) showed up on my watchlist today. It works, in that it fixes the current issue on that specific article, but it should not have been necessary. This is because this edit of mine from December 2023 did precisely the same job - but for all articles using Template:RCTS-LocosGWR-5 and not individual articles one by one. It worked at the time, and should still be working - but apparently not. --Redrose64 🌹 (talk) 23:31, 27 October 2025 (UTC)

It's effecting a number of different whitelisted templates, I'd estimate it's impacted roughly 600 articles. -- LCU ActivelyDisinterested «@» °∆t° 01:25, 28 October 2025 (UTC)

Watchlist down?

When I just tried to check my watchlist, I found it blank; this has never happened before. There's just a notice saying, "No changes during the given period match these criteria". I'm using the latest version of Firefox and Windows 11, and have made no changes to my watchlist preferences. Any help appreciated. All the best, Miniapolis 21:10, 23 October 2025 (UTC)

Maybe related? my watchlist loads but entirely in alphabetical order, regardless of days left. Sarsenet•he/they•(talk) 21:20, 23 October 2025 (UTC)

@Sarsenet Are you talking about the Watchlist itself (Special:Watchlist) or about the listing of pages on your watchlist (Special:EditWatchlist)? -- If the former, that's a new and distinct bug, please start a new Topic for it and share more details (and ideally a screenshot) or file a bug on Phabricator. -- If the latter, that might be related to the ongoing changes to fix the bugs/timeout issues for users with very large watchlists (phab:T41510) where some things have been changed for performance reasons, including no longer showing "temporarily watchlisted pages" at the top of each section. Quiddity (WMF) (talk) 22:30, 23 October 2025 (UTC)

@Quiddity (WMF) it was (Special:EditWatchlist), oops. Well I'm not particularly happy with the reformatting of temporarily watchlisted pages, but oh well. Sarsenet•he/they•(talk) 23:56, 23 October 2025 (UTC)

In that link, you've got the filters for both "Unseen changes" and "Seen changes" selected. That shouldn't have any effect as they should combine to just show all changes [i.e. cancel each other out] (I'll file a bug-report: phab:T408167), but it does seem to currently; so to temporarily (and permanently!) fix it, just unselect both those 2 filters. Quiddity (WMF) (talk) 21:56, 23 October 2025 (UTC)

FWIW, my watchlist has 21 pages. I'll check my filters, but haven't changed anything. All the best, Miniapolis 23:21, 23 October 2025 (UTC)

Aha; unselecting those filters (unseen and seen changes) seems to have fixed it. Never a dull moment here :-). Thanks Quiddity (WMF) and all the best, Miniapolis 23:24, 23 October 2025 (UTC)

Too good to be true, apparently; my watchlist was blank again today until I deselected "unseen changes" (that and "seen changes" were back). Unseen changes have been in bold, which was useful. All the best, Miniapolis 19:33, 24 October 2025 (UTC)

In case it helps: You can save your preferred default-filters, using the icon at the right-edge of the Filters menu there. Quiddity (WMF) (talk) 21:01, 24 October 2025 (UTC)

(←) Thanks, Quiddity (WMF), but I saved "seen changes" as a default filter after removing "unseen changes"; when I left the page and returned, unseen changes was back and the watchlist was blank. When I removed it, my changes returned as seen; I miss the bold unseen changes, but it's better than a blank watchlist. I've been here a while, and this used to be a no-brainer; frankly, I'm surprised it hasn't been reported by others. Thanks for your help and all the best, Miniapolis 22:40, 24 October 2025 (UTC)

The problem persists, alas, with "unseen changes" continuing to return; this is a first in my almost 20 years of editing. Any help appreciated. All the best, Miniapolis 13:52, 27 October 2025 (UTC)

Update: watchlist appears as it should when I remove the "seen" and "unseen changes" filters. Miniapolis 17:21, 27 October 2025 (UTC)

The seen- and unseen-changes filters keep coming back, although they're not saved like the other filters. I can configure the watchlist by removing them, but wish that the watchlist worked like it did before. Miniapolis 20:47, 29 October 2025 (UTC)

Hi Miniapolis. I've got 2 questions, and some detailed context, which I think might help us resolve this:

Q1. How are you accessing/opening the link to your watchlist? [I.e. Are you using the link in the top-corner of your browser, or some other method?]

Context: I ask because: the only way that filters should be changing for any individual, from the site-wide defaults, is:

(A) if we manually edit them in real-time. [Not the problem here]

(B) if we have created a custom default filter (screenshot) and we access our watchlist from the standard top-corner link (which just points to Special:Watchlist without any parameters) hence it will use our custom default. [Probably not the problem here? Unless you have multiple filters and the 'wrong' one is currently your default],

(C) if we access our watchlist from a browser-bookmark or webpage link (or browser-history autocomplete, etc) and that link already includes some custom parameters in the URL, in which case it would override/append-to the site-defaults or our custom-defaults. [I wonder if this is the cause of the reappearing problem you're encountering?]

Or, to put it in other words: Your first link in this thread includes the URL parameter&value watchlistactivity=all and that's what is leading to the error (per the bug I filed earlier, phab:T408167); but that should not be unexpectedly reappearing in the URL at all. [Sidenote: The only other possible values for that parameter are =seen or =unseen.]

Q2. Please could you test if it is appearing in the URL, even when you visit Special:Watchlist (plain link) or a URL with a single specified parameter&value like this example (which should just restrict your default/custom filter to only show minor edits)? If it does reappear in the resulting URL after clicking either of those links, then that would be a separate new bug, and I'd need to ask about your browser/gadgets/etc. But I'm hopeful that the details/questions above will lead us to understand a more logical/expected cause of it all! HTH. Quiddity (WMF) (talk) 22:04, 29 October 2025 (UTC)

(←) Thanks, Quiddity (WMF); it's a puzzlement, but I've learned more about how watchlist filters work. When I clicked on my original link in the thread, I got no results until I hid seen and unseen changes. I access my watchlist from the upper-right-corner link, and that seems to be working; I've saved a group of the filters I want, which doesn't include seen and unseen changes :-). Clicking Special:Watchlist seems to work, as does clicking the example. HTH, and I can live with what I've got; I rely on bold unseen changes, and they're back. Thanks again and all the best, Miniapolis 00:52, 30 October 2025 (UTC)

Quiddity (WMF), I just realized that the first thing I do here every day is check my watchlist by clicking a link I bookmarked years ago (probably the original link in this thread). Changing the bookmark seems to have worked. All the best, Miniapolis 13:50, 31 October 2025 (UTC)

"Error: no page names specified (help)" – a safesubst error on my part?

I recently created template User:Mathglot/sandbox/Templates/Uh-page-numbers, and added substability. The template still works fine unsubsted, but substed, it emits an error similar to this:

Error: no page names specified (help)

with the blue 'help' link targeting local section #Errors on the page where it is substed. See a substed example at User:Mathglot/sandbox5. What could be causing this? Note: this error also appears on these 121 pages. I suspect I added safesubst protection incorrectly, but I don't see it. Thanks, Mathglot (talk) 07:34, 25 October 2025 (UTC)

Something with the {{Further}} link maybe? Mathglot (talk) 07:55, 25 October 2025 (UTC)

Yes, {{Further}} doesn't support subst. PrimeHunter (talk) 12:03, 25 October 2025 (UTC)

That was it; thanks. Mathglot (talk) 20:55, 25 October 2025 (UTC)

This was traced to an error message emitted by Module:Labelled list hatnote, with some reasoning there pointing to Template:Further as the culprit. I don't pretend to understand the interaction between the two enough to know where the locus of the problem truly lies, but I have raised Template talk:Further#Possible bug in error handling related to module-emitted error message, and hopefully that will get some attention and lead to a more robust handling at the template, the module, or wherever it is needed. Thanks, Mathglot (talk) 20:27, 27 October 2025 (UTC)

Strange notification effect

For the last 72 hours or so, when I get notified about talk page message there's a block of solid colour over the message that caused the notification, with an information icon and a "reply…" tag. I have to click this to see the text. The "i" icon takes me to the image page… which I suppose is a type of information about the icon.

This may, of course, have something to do with my settings. Even so it's a change in behaviour, so we should be able to track down the proximate cause. All the best: Rich Farmbrough 21:09, 25 October 2025 (UTC).

What skin are you using? — xaosflux ^Talk 12:55, 27 October 2025 (UTC)

Monobook. All the best: Rich Farmbrough 19:59, 27 October 2025 (UTC).

It seems that there is some kind of custom url being created, for example url 1 puts the contents in a box - which does not hide it if I'm logged out:

1. https://en.wikipedia.org/wiki/User_talk:Rich_Farmbrough#c-MediaWiki_message_delivery-20251027192800-Tech_News:_2025-44
2. https://en.wikipedia.org/wiki/User_talk:Rich_Farmbrough#Tech_News:_2025-44

The second url does not do this. So if I could supress or change that I'd probably be OK.

All the best: Rich Farmbrough 19:59, 27 October 2025 (UTC).

The background color for highlighted comments (i.e. the link given by Notifications, or by clicking on the timestamp in an existing comment) is coming from .ext-discussiontools-init-targetcomment in the DiscussionTools feature.

However, I cannot reproduce this bug/screenshot above. I tried turning on the "Dark Mode" gadget and setting my skin to Monobook, but highlighted comments still display with the expected dark-blue background (screenshot dark gadget, or compare with screenshot in light mode). How are you getting the black background that is shown in the rest of the screenshot above? (perhaps a browser extension like "Dark Reader"?). It would be best if we could track down the conflict between systems, but we need more details to do that.

As temporary hack-ish solutions, you can either: (A) just click outside of the highlighted-area each time (which will remove the highlight), or (B) you could add this line -- .ext-discussiontools-init-targetcomment {background-color: unset} -- into your Common or Monobook user-CSS. Hope that helps. Quiddity (WMF) (talk) 20:41, 27 October 2025 (UTC)

Thanks. The code paints a box, (it's pale blue in light mode) which is supposed to be behind the content. I'm not sure why it is pushing forward but I fixed it with:

.ext-discussiontools-init-highlight {
  z-index: -1;
}

in my monobook.css ( -1 because 0 didn't work).

All the best: Rich Farmbrough 20:57, 27 October 2025 (UTC).

Looks like .ext-discussiontools-init-highlight is using mix-blend-mode: darken to do the highlighting. Perhaps the dark mode gadget doesn't have an override (to mix-blend-mode: lighten) like Vector's built-in dark mode does? Anomie⚔ 21:07, 27 October 2025 (UTC)

Interesting. I tried overriding this property to no effect, alas. There may be some Chrome extension doing things also, I suppose. For now the Z-index is a good workaround for me, even though it's not a fix for the underlying issue (unless implemented in the DT code, of course). All the best: Rich Farmbrough 22:05, 27 October 2025 (UTC).

box … which is supposed to be behind the content. I'm not sure why it is pushing forward – The blue highlight is drawn as an overlay instead of a background, so that it is visible in cases where the comment itself has a background, e.g. like the barnstar boxes or many of the talk page warnings. It also allows the highlight to cover images, tables (which have a light grey background) and so on. Matma Rex talk 13:15, 28 October 2025 (UTC)

An alternate solution was to set a lower opacity on the box. This is partly why I assumed it was meant to be at the back. It's really a bit of a hack either way, threading and comments were never designed, so they have no representation that can have clean attributes applied. All the best: Rich Farmbrough 10:52, 29 October 2025 (UTC).

dark mode toggle

how do i make it so the dark mode toggle gadget doesnt change the logo when dark mode is enabled? i want to use File:Wikipedia logo v2 (white).svg instead of this weird black puzzle globe. plus, when dark mode is enabled, it makes this weird effect where images are slightly desaturated, makes transparent images have a white background and also makes emojis' colors inverted. How do i fix all those glitches Harringstars ᐸ Talk
Contribs 18:46, 26 October 2025 (UTC)

You are using the dark mode gadget. Simply put, don't use the gadget. It's not maintained and isn't the supported way of using dark mode on this wiki at this point in time. Izno (talk) 18:53, 26 October 2025 (UTC)

Izno, should it be disabled? — Qwerfjkltalk 13:39, 27 October 2025 (UTC)

i'm not using vector 2022. i'm using vector 2010. Harringstars ᐸ Talk
Contribs 19:05, 27 October 2025 (UTC)

Then there's nothing else to do. There is functionally no way to fix this in the way you want. You may fork it to your local CSS/JS if you wish and then attempt to improve it for yourself. Izno (talk) 19:14, 27 October 2025 (UTC)

how do i make it so it just has the dark effect without changing everything else? Harringstars ᐸ Talk
Contribs 19:16, 27 October 2025 (UTC)

I personally use Dark Reader to view Wikipedia and other websites in dark theme. 🐲Jothefiredragon🔥talk🧨contributions✨log🐉 02:35, 27 October 2025 (UTC)

There's a hack that replaces the logo. If you replaced it with a negative of the real logo, dark mode would make it positive again. All the best: Rich Farmbrough 22:08, 27 October 2025 (UTC).

how do i make it on css Harringstars ᐸ Talk
Contribs 13:19, 28 October 2025 (UTC)

Unicode Not Appearing à

With Unicode, i.e. U+E0: vis-à-vis

W/O Unicode, i.e. pasting from Gnome Character Map 15.1.0: vis-à-vis.

The oddity is that on Wikipedia proper, in the edited articles, the accented letter appears in the previews, but not on main, whereupon I have to copy-paste. Even weirder: In this forum, I can't duplicate this behavior.

Unicode for me hasn't stuck several times, I don't know how far back, but it began fairly recently, particularly in subsection titles.

kencf0618 (talk) 00:48, 27 October 2025 (UTC)

Always link to an example page that demonstrates the error. As explained in the edit notice for this page: Where did you encounter the problem? Please add links when possible. ... What browser and what version of your browser are you using? Those characters look fine to me here, as you indicate. – Jonesey95 (talk) 01:59, 27 October 2025 (UTC)

https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Dates_and_numbers&diff=prev&oldid=1318948277

There are a couple of reversions (due to a misunderstanding on my part) which aren't relevant to the matter at hand. kencf0618 (talk) 04:12, 27 October 2025 (UTC)

At the moment, I suspect this might be a problem in your operating system or browser, not in Mediawiki or Wikipedia software.

Please describe exactly what you did.

• Which operating system? Linux, I guess, but which one?
• Which browser and which version?
• How exactly did you try to type the letter "à"? (Above you talked about U+E0 and "with Unicode" / "without Unicode", but it's unclear what you mean by that.)
• Did this happen only once? Or multiple times?

Please include any other information that might be useful.

In case this happened only once, or only happens occasionally on your operating system and browser, I guess it's unlikely that much will be done about it, since it's unlikely to affect more than a few users.

— Chrisahn (talk) 07:31, 27 October 2025 (UTC)

• 1) Linux Mint 22.2
• 2) Mozilla Firefox for Linux Mint-001 - 1.0
• 3) Keep Ctrl-Shft depressed. Type "uE0", which stays on-screen until Ctrl-Shft is released whereupon "à" appears.
• 4) Numerous times, numerous keyboards.

— kencf0618 (talk) 11:53, 27 October 2025 (UTC)

There is no need to use Unicode U+00E0 à LATIN SMALL LETTER A WITH GRAVE to display à. -- Michael Bednarek (talk) 13:45, 27 October 2025 (UTC)

Section headings change the font so you may lack support for some Unicode characters in the default font for section headings. I don't know whether there are circumstances where a preview and the saved page can use different fonts in the same place. PrimeHunter (talk) 15:59, 27 October 2025 (UTC)

Saying "use Unicode" is confusing: you definitely need to "use Unicode" in the sense of "enter a character outside of basic ASCII" to display "à", but there are many ways of accomplishing that that don't involve using an input method and typing the code point number.

From the one diff linked above, it seems unlikely that it's a font issue as Special:Diff/1318948277 linked above shows that "vis-" was saved rather than "vis-à-vis" that was apparently intended.

On the other hand, I have no guess as to what actually is going on here, particularly when it's claimed that the character appears when previewed preview but somehow disappears when the edit is saved. Anomie⚔ 16:28, 27 October 2025 (UTC)

@Kencf0618: +1 to PrimeHunter above, as you mention "particularly in subsection titles" which makes me think it might be related to the Serif/Sans-Serif differences for H2/H3+ headings in most namespaces. I'd suggest trying to reproduce this bug in a simple user-sandbox (e.g. like this demo) so that there's a clear test-case. [EDIT: Although, as Anomie notes, if it's just writing the character that fails, that's a different problem.]

Also, +1 to Michael, you may want to investigate alternative (easier!) methods to input non-ascii characters, e.g. I'm a heavy user of the Compose Key – which can be enabled on Mint (Cinnamon) via the "OS Menu->Keyboard->Options" settings (see screenshot on imgur) – hence I can just type fairly logical key-combos for most characters, e.g. [composekey]→ a → ' to get á. (See the linked article for a short list, and the top entry in External links for a complete list).

Hope that helps. Quiddity (talk) 21:52, 27 October 2025 (UTC)

I've reproduced the Unicode unput bug in my sandbox. On the composition page the full phrase appears, whereas on both preview pages it's just "vis-". Until I shift down a line, whereupon it appears. kencf0618 (talk) 13:30, 28 October 2025 (UTC)

Addendum: The Enter, Any Arrow, and Backspace methods all work. kencf0618 (talk) 13:37, 28 October 2025 (UTC)

This is sounding a lot like your input method is somehow displaying the input but not "committing" it to the browser until you "confirm" it with enter, arrow, backspace, or the like. Anomie⚔ 14:53, 28 October 2025 (UTC)

I'll deal the the issue with some combination of memorized Unicodes & the composition key method, then. Thanks, all!~ kencf0618 (talk) 16:48, 29 October 2025 (UTC)

Very large table slows page rendering

User:Seppi333 made an interesting observation:

After running the performance and network monitoring tools, I found that the real culprit is actually browser css recomputing, which accounts for over 90% of the page load time. It’s not a result of a large page size or DOM size. It’s due to the fact that the entire page consists of a single wikitable (4x5000 html elements) and the DOM size exceeds a threshold that results in recurring and lengthy css rendering computations every time more page data is loaded.

In a nutshell, reducing the column count and the row count has a much bigger impact on page load times than reducing page size.

Is the actual point where this becomes critical (perhaps browser-dependent?) known; and is it, or should it be, recorded somewhere? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:23, 27 October 2025 (UTC)

It very likely depends on the browser, and maybe other factors too such as the amount of memory available. Special:PermaLink/928937476, for example, loads quickly for me on Firefox 144. Anomie⚔ 19:38, 27 October 2025 (UTC)

Amount of memory seems interesting. That took my computer about 30 seconds to go from click to first content paint, but I'm rocking no dedicated GPU these days due to a recent Linux transition that I don't know what I'm doing about and only 8 GB of memory. (Thanks, Microsoft end of lifing Windows 10.) Izno (talk) 19:41, 27 October 2025 (UTC)

Izno, I have 8 GB of memory as well, but it took under 5 seconds for first content paint (I don't have a dedicated GPU either). Using a Firefox-based browser. — Qwerfjkltalk 21:05, 27 October 2025 (UTC)

It's still like 13 seconds in private mode logged out. Izno (talk) 01:09, 28 October 2025 (UTC)

There seems to be a big performance difference for me depending on if I'm using parsoid or the legacy parser btw... —TheDJ (talk • contribs) 09:20, 28 October 2025 (UTC)

I note the Parsoid output is 6.2MiB of HTML while the normal parser is only 2.4MiB, and also takes longer for the server to generate. Anomie⚔ 13:21, 28 October 2025 (UTC)

I'm almost certain that's because of every element having an ID. sapphaline (talk) 19:01, 28 October 2025 (UTC)

That's part of it. It also adds a bunch of largish data-mw properties, and some other properties too. Anomie⚔ 01:16, 29 October 2025 (UTC)

ping @Cscott and @SSastry (WMF) just want to put this on your radar, because it seems quite a large difference. —TheDJ (talk • contribs) 10:03, 29 October 2025 (UTC)

Thanks! Yes, This is one of the things on our radar. But, good to know about these exceptional cases where the difference is 2.5x vs 15%. SSastry (WMF) (talk) 14:02, 29 October 2025 (UTC)

@SSastry (WMF): why does Parsoid assign an ID to every element? sapphaline (talk) 20:03, 29 October 2025 (UTC)

Parsoid needs to convert HTML edits to wikitext without dirty diffs. To do that, it needs to store source offsets and some other information for DOM nodes. That information is keyed off node ids and stored separately (and not shipped with the HTML). But, one of the things we are considering for read views (vs. API views) is if it makes sense to strip metadata (data-* attributes produced by Parsoid and element ids). VE and any other clients (bots, for ex.) that (want to) edit HTML and have it convert to wikitext use (or will have to use) HTML from the REST API. SSastry (WMF) (talk) 23:41, 29 October 2025 (UTC)

Private window logged out with legacy parser gets me below 10 seconds (8ish). Woo? Izno (talk) 16:47, 28 October 2025 (UTC)

For me, on this several years old Windows 11 laptop with 16 GB RAM + 8 GB for the GPU, in Edge, the Special:PermaLink/928937476 page was rendered without any significant delay, effectively instantly. I have a larger table than that in a subpage User:Sean.hoyland/ARBPIA_page_protection_status for interest and that takes several seconds to complete loading (so that the show link for a collapsed section works). Sean.hoyland (talk) 17:11, 28 October 2025 (UTC)

Tech News: 2025-44

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• The Wikipedia iOS app has launched an A/B/C test of improvements made to the tabbed browsing feature for select regions and languages. The test, named “More dynamic tabs”, explores new tab experiences and includes “Did you know” and “Because you read” article recommendations. You can read more on the project page.
• Autoconfirmed users on small and medium wikis with the CampaignEvents extension can now use Event Registration without the Event Organizer right. This feature lets organizers enable registration, manage participants, and lets users register with one click instead of signing event pages.
• View all 31 community-submitted tasks that were resolved last week. For example, the issue of flashing colors when holding or pressing the arrow keys under the dark mode settings in Vector 2022 has been fixed. [4]

Updates for technical contributors

• The CampaignEvents extension will be deployed to all remaining wikis during the week of 17 November 2025. The extension currently includes three features: Event Registration, Collaboration List, and Invitation List. For this rollout, Invitation List will not be enabled on Wikifunctions and MediaWiki unless requested by those communities. Visit the deployment page to learn more.
• The SwaggerUI-based REST sandbox experience is now live on all wiki projects. The sandbox can be accessed through the Special:RestSandbox page. Please report any issues to the MediaWiki Interfaces team board, or join the discussion on the project launch page. [5]
• Transform endpoints with a trailing slash path in the MediaWiki REST API are now marked as deprecated. They will remain functional during this time, but removal is expected by the end of January 2026. All API users currently calling them are encouraged to transition to the non-trailing slash versions. Both endpoint variations can be found and tested using the REST Sandbox. See the MediaWiki REST API Deprecation page for more detailed information about the API deprecation policies and procedures.
• A dedicated changelog now exists for the MediaWiki REST API. The changelog provides an overview of these changes, making it easier for developers to keep track of improvements and iterations. Announcements will also continue to flow through the standard communication channels, including Tech News and email distribution lists, but can now be more easily referenced from a central location. If you have feedback about the style, structure, or content of this changelog, please join the discussion.
• Administrators can delete the tracking category which was previously added by the JsonConfig extension, as it is no longer used. See the categories linked from Q130635582. It is OK if there are still pages listed in the category as that is just a caching issue, and they will be automatically cleared out the next time each page is edited. [6]
• Detailed code updates later this week: MediaWiki

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 19:27, 27 October 2025 (UTC)

Re-enable TLS 1.1 support, and possibly 1.0(?)

The Wikipedia page itself makes quite a few concessions for old browsers. In addition, MediaWiki offers several skins that work perfectly with very old rendering engines due to their age, like Monobook and Modern.

You can't make use of this great compatibility because the minimum protocol supported is TLSv1.2. This blocks most browsers older than 2014 from connecting. However several sites, like:

• Google,
• Bing,
• Facebook,
• Instagram,
• reddit,
• Snapchat,
• and YouTube

have legacy TLS versions enabled, despite their sites (except reddit's) being broken on browsers of that age. It doesn't make sense, then, for the one major website with proper rendering support for old browsers to not support TLS1.1/1.0. OmegaAOL (talk) 22:04, 27 October 2025 (UTC)

Also, I have an iPad 1 which I use for things like YouTube, reddit, and e-books. Not being able to connect to the Wikipedia site on it is inconvenient. OmegaAOL (talk) 22:06, 27 October 2025 (UTC)

Based on wikitech:HTTPS/Browser Recommendations this request would be instantly declined, for your own safety I would recommend phasing out these devices. Sjoerd de Bruin (talk) 22:18, 27 October 2025 (UTC)

Cool, more e-waste. Also, the iPad 1 was upgraded to iOS5, which does support TLSv1.2 per Version history for TLS/SSL support in web browsers. --Ahecht (TALK
PAGE) 15:37, 29 October 2025 (UTC)

Change to how pages are formated

I use the desktop site in mobile (Android, Chrome, Vector 2010), and it always worked well. The format was responsive to my screen aspect ratio, but this morning it's broken. I'm guessing this is because of the en.m.wiki URL being retired, but why has it stopped the responsive formatting? -- LCU ActivelyDisinterested «@» °∆t° 15:23, 28 October 2025 (UTC)

This sounds similar to Wikipedia:Village pump (technical)/Archive 224 § The desktop view on mobile (Chrome on Android) has gone zoomed out again, in which case it's a change to how Chrome displays text and not the URL change, despite the timing. There are some hints in that thread and at phab:T407447 as to what you can try to get the old behaviour back. Rummskartoffel 21:20, 28 October 2025 (UTC)

Thanks Rummskartoffel, you're right. The timing threw me off, but disabling chrome://flags#force-off-text-autosizing (as originally suggested by Srapoj[7]) solves the problem so it's an issue with Android Chrome. -- LCU ActivelyDisinterested «@» °∆t° 01:55, 29 October 2025 (UTC)

Changes to Special:EditWatchlist

There have been a couple recent changes to "View and edit watchlist" that in my view made it less convenient to use:

• No longer shows watches with expiry ordered by expiration dates at the top of each namespace. I have used this to see which watches were expiring soon, and now I have no way to do this except looking through all the entries.
• No longer shows a table of contents linking to the namespaces. Not having these easy jumps means I have to scroll a lot more.

Does anyone have an idea why these seeming downgrades were made? Stefen 𝕋ower_{'s got the power!!1!} ^{Gab • Gruntwerk} 17:43, 28 October 2025 (UTC)

Looks like the sorting change was due to T41510, apparently there was no efficient way to do both pagination and sorting by expiry. Apparently the intent of removing the TOC in the same change was to replace it with a namespace filter, but apparently they screwed it up somehow so it only shows when you add ?paginate=1 to the URL to enable the pagination feature. Anomie⚔ 18:30, 28 October 2025 (UTC)

Interesting. When I use the namespace filter, that doesn't work either. Besides that, is there a setting somewhere that turns pagination on without me manually updating the URL? Stefen 𝕋ower_{'s got the power!!1!} ^{Gab • Gruntwerk} 18:59, 28 October 2025 (UTC)

From reading the phab ticket, it seems per the design that pagination is supposed to be automatically there. Stefen 𝕋ower_{'s got the power!!1!} ^{Gab • Gruntwerk} 19:16, 28 October 2025 (UTC)

My fault, I wrote the pagination patch which included removing the table-of-contents - the pagination is hidden temporarily so we can test it (that's the reason for the ?paginate=1 thing), and the table-of-contents being removed should have been hidden too but I "screwed it up" as @Anomie says. Pagination is being deployed fully on Monday CParle (WMF) (talk) 10:17, 31 October 2025 (UTC)

I would also like to register my strong objection about the change in display order.   ▶ I am Grorp ◀ 05:30, 29 October 2025 (UTC)

@Grorp and @StefenTower I created this wish https://meta.wikimedia.org/wiki/Community_Wishlist/W454 for re-implementing sort-by-expiry, just so we can get some idea of how important it is to people. As it says in the wish we can't re-enable sort-by-expiry as it was because the queries were just too slow, but we might be able to figure out some alternative way of doing it instead

If it's important to you (or to anyone you know), please support the wish! CParle (WMF) (talk) 10:20, 31 October 2025 (UTC)

• I use Special:EditWatchlist a lot for work management so this was a killer for my work flow. Until we have multiple watchlists I use the different watch lengths to group things together. Having the pages and editors I need to keep a close eye on for a while (1 week) separate from long term permanent watches, and other uses between, is important. So, hopefully as a temporary solution, I just knocked up a script to fix it up for now User:KylieTastic/EditWatchlistByExpiry. KylieTastic (talk) 14:07, 31 October 2025 (UTC)

Change in File Page Link Behaviour

Moved from Wikipedia:Administrators' noticeboard/Incidents § Change in File Page Link Behaviour

 – The Bushranger _{One ping only} 21:40, 28 October 2025 (UTC)

Tracked in Phabricator
Task T407807
Invalid

Previously, using the 2010 vector skin, clicking on the Commons icon on the top-right corner of a file page would lead directly to the Commons page for said file. This seems to have changed in the past week or so (most recently checked with File:Gary Robert Dourdan "Mr. Brown" Wet Plate Collodion by Shane Balkowitsch 8-3-2023.jpg), with clicking the Commons logo now leading to File:Commons-logo.svg. I no longer have a mop to restore earlier behaviour, and I'm not really sure where I'd be looking to see what changed. Any way we can restore previous functionality? — Chris Woodrich (talk) 19:04, 28 October 2025 (UTC)

This was reported a week ago with no replies in phab:T407807. PrimeHunter (talk) 19:58, 28 October 2025 (UTC)

Seems to be a deliberate change based on this edit history. Sjoerd de Bruin (talk) 20:18, 28 October 2025 (UTC)

Courtesy ping to Anomie. --Ahecht (TALK
PAGE) 20:33, 28 October 2025 (UTC)

• Ah. I agree with Anomie's edit, at least from a licensing perspective (personally, I hate the change, but the argument is sound). And now, to go beyond the scope of this page... I'm thinking that unfortunately this means Template:Featured article and Template:Featured list will both need similar changes as File:Cscr-featured.svg is under a lesser GNU 2.1 license - which is even more restrictive in terms of attribution/including the license. I'm not going to start any discussion, as I don't have the energy for an RFC, but I think it's worth noting. — Chris Woodrich (talk) 20:50, 28 October 2025 (UTC)

  I'd rather we be able to have the topicon link to the description page too, but the license is what it is until someone manages to get it changed. Or we get a consensus to violate the license-as-written (which RFC I'd oppose).

  There's some discussion at Template talk:Sister project#Delinking icons where Sdkb was contacting the WMF about doing something about how most of the project logos can't be used to link to the projects generally for need of attribution and license notice on the images.

  And yeah, I've been turning a blind eye towards those featured content topicons so far, but those really should be changed too, either linking to the image or replacing them with a different (topicon-specific) image that's public domain or CC0. Unless we want to assert that having two clicks—click topicon → Wikipedia:Featured articles* then click large image at the top of that page → file description page—is sufficient for the LGPL's requirements in this case and then actually use File:Cscr-featured.svg rather than File:Cscr-featured.png on those pages so that works, despite the comment saying not to, sigh. Anomie⚔ 01:34, 29 October 2025 (UTC)

  P.S. It's really annoying that most of the OOUI and Codex icons people are starting to use are listed on Commons as MIT or CC BY-SA licensed, even though many are probably {{PD-shape}} or otherwise {{PD-ineligible}}. If we want to use those from Commons unlinked, someone really needs to go there and relabel them properly. Anomie⚔ 01:48, 29 October 2025 (UTC)

  Do we really need the topicon to redundantly link to the license page when the same icon in the fmbox links to there? 172.97.220.91 (talk) 11:27, 29 October 2025 (UTC)

...one thing that bemuses me about this is I never realised that icon in the top right did that - I always assumed it was just an icon, and clicked on the "Information from its description page there is shown below" link... - The Bushranger _{One ping only} 21:42, 28 October 2025 (UTC)

The Bushranger, I finally see a thing that I knew that you didn't. This makes me feel pretty good. Drmies (talk) 12:48, 29 October 2025 (UTC)

snap. What I've never had, I'll not miss. Nthep (talk) 22:16, 28 October 2025 (UTC)

The Commons logo is just a few arrows and a red circle, I wouldn't have thought that meets the threshold of originality does it? It's no more complex than something like File:Microsoft Office Access (2025-present).svg anyway... As such, we could just treat it as public domain.  — Amakuru (talk) 13:56, 29 October 2025 (UTC)

Get that changed on c:File:Commons-logo.svg and that'd be ok with me. If you're suggesting we ignore the license stated on that page ("just treat it as public domain"), I don't think that's a good way to go. Anomie⚔ 14:16, 29 October 2025 (UTC)

@SManivannan-WMF: do you have any good idea on this? (We would like our readers to be able to click on the logo for commons to go to commons and read the file description there - instead of forcing them to read the file description about the commons logo itself). — xaosflux ^Talk 14:27, 29 October 2025 (UTC)

@Anomie: it looks like it was marked as "PD-shape" for quite some time, from 2014 to 2023, but was for some reason switched back to a Commons licence by Ruthven, for reasons that aren't clear to me. @Ruthven (if you're watching your en-wiki account) it seems pretty clear that the Commons logo is simply geometric shapes, much like the Microsoft Office logos, so can we switch it back to PD-shape please? I don't think we should treat this differently just because it's a WMF logo rather than an external one like Microsoft. Cheers  — Amakuru (talk) 19:11, 29 October 2025 (UTC)

@BChoo (WMF), fyi. Iniquity (talk) 19:27, 30 October 2025 (UTC)

I should have mentioned - like, thirteen hours ago - that I closed phab:T407807 as invalid. Per my closing comment there, this issue is purely a consequence of this edit. The edit was made because c:File:Commons-logo.svg is licensed CC BY-SA 3.0 and therefore requires attribution. It may be resolved here, possibly in consultation with Commons. --Redrose64 🌹 (talk) 20:18, 30 October 2025 (UTC)

IP blocks and hotspotting

Not sure if this goes here or WP:RD/C; tell me to go there if you think that's better.

I always use a laptop to edit, and as an admin, I can edit through IP blocks, so I basically never notice when I'm using a blocked IP. Today, a few minutes after editing via a hotspot produced by my mobile phone, I attempted to edit a page on the phone (it's a flip phone, so this is extremely rare) and found that the IP was affected by a rangeblock. Had I been editing through a normal account, or editing logged out, would my laptop have been blocked because the phone was using a blocked IP? They're two different devices, but on the other hand, if two devices are connected to the same land-based wifi router, a block affecting one device seems to affect the other device as well. Nyttend (talk) 10:33, 29 October 2025 (UTC)

Your mobile phone connects through the mobile network. When you use it as a hotspot for a laptop, that laptop would also use the mobile network and share the same IP (from an external point of view) as the phone is using, and is thus subject to the same blocks. —TheDJ (talk • contribs) 11:13, 29 October 2025 (UTC)

As for whether the block on the IP would have affected you editing through a normal account, it depends on the settings of the block. Anomie⚔ 13:46, 29 October 2025 (UTC)

Has any admins ever been affected by their own range blocks? 159.48.94.70 (talk) 16:22, 29 October 2025 (UTC)

159.48.94.70, admins have Wikipedia:IP block exemption and so are not affected. — Qwerfjkltalk 17:04, 29 October 2025 (UTC)

Not a rangeblock, but a single account block — I have been. See [8] for when I accidentally autoblocked myself; further discussion at Wikipedia:Village pump (technical)/Archive 160#IPBE_and_autoblocks. Nyttend (talk) 19:29, 29 October 2025 (UTC)

I stand corrected. — Qwerfjkltalk 10:55, 30 October 2025 (UTC)

Admins have historically been affected by IP blocks much more than they are today. Before July 2006 all IP blocks were hardblocks, so they affected all logged-in users, including admins. See this archived ANI discussion, this unblock log, and this old proposal. Graham87 (talk) 01:18, 30 October 2025 (UTC)

If an IP block effects a home router all devices on that home network will be blocked from IP editing. As you phone was acting as a router for your phone the same things applies. The router is the only device that has an IP address that can be seen on the internet, all traffic from any device connected to the router appears to be coming from that one IP. I'm guessing that this behaviour will change with temporary accounts. -- LCU ActivelyDisinterested «@» °∆t° 21:18, 30 October 2025 (UTC)

When you search anything on the search bar

When you search anything on the search bar, for example, A, it says A (the letter), Assocciation football, Australia, Animal, Arthropod, Austria, Argentina, Prince Andrew, and Afghanistan. a new thing has happened Typing any letter on the search leads you to a word like searching anything, a page with the first letter NOT being on the search bar the person is searching for, especcialy when it says Prince Andrew on A (as said above) Please remove this update. DiamondCat22 (talk) 14:34, 29 October 2025 (UTC)

It's not "searching any" word. Typing G shows it uses {{DEFAULTSORT}}. 172.97.220.91 (talk) 14:59, 29 October 2025 (UTC)

As the IP address above said, Prince Andrew uses {{DEFAULTSORT:Andrew, Duke Of York, Prince}}, so it's treated as if it began with "A". --Ahecht (TALK
PAGE) 15:25, 29 October 2025 (UTC)

Not for much longer. {{DEFAULTSORT:Mountbatten Windsor, Andrew}}, if Charles has his way. See BBC News. --Redrose64 🌹 (talk) 23:33, 30 October 2025 (UTC)

Some article work for techies here

Apparently, there are 29.8k articles using nested tables. sapphaline (talk) 21:28, 29 October 2025 (UTC)

What is the work that you are suggesting? Nested tables are usually fine. – Jonesey95 (talk) 22:29, 29 October 2025 (UTC)

Most of these are going to be presentational tables which should be avoided in contrast to your "nested tables are usually fine". They should either be removed entirely or replaced with the likes of {{col-start}} or {{div col}} (setting style="display: inline-table" may also be viable in some cases but I understand has caused some mess before with how the skins set display of tables at low resolution). Izno (talk) 00:12, 30 October 2025 (UTC)

Hmm, maybe Wikipedia:Manual of Style/Tables or Help:Table#Nested tables, our main pages that provide guidance on making tables, should have a note about the drawbacks of nested tables. That's where I looked to come up with my assessment. – Jonesey95 (talk) 14:03, 30 October 2025 (UTC)

A table element may be used wherever flow content is permitted; and a table cell (whether td or th) may only contain flow content. The spec says nothing about exceptions for tables; therefore, from a technical point of view, tables may be nested (to any depth). --Redrose64 🌹 (talk) 13:33, 31 October 2025 (UTC)

Explicit images in search autocomplete for "human"

Right now, typing "human" into the search bar helpfully pops up a list of popular pages starting with the word "human": in order, it presently offers Human, Human penis size, Human sexual activity, Human penis, Human body, and Human evolution, all of which show the article's primary image in the search card preview. Three of these images are explicit in nature -- two illustrations, one photograph. The illustrations show up in the top six with "hu" alone, and "hum" is enough to display the photograph.

While Wikipedia is WP:NOTCENSORED, the Human Penis Jump Scare might not be the ideal search experience for people starting to type a search for many other human-related topics, especially at school or work. Although undoubtably popular, perhaps these articles should not be presented as instant results, or the images should be removed from these instant results. I propose a denylist approach, where various terms in an article headline or blurb would suppress the article's image, if not the entire article, from instant search results. I have no idea what measures already exist (if any) to control instant search results and whether this represents a failure of existing controls, or if it's just not something anyone has implemented yet.

I have nothing against the human penis -- I quite appreciate it, myself -- but I feel like this might not be the user experience visitors to Wikipedia expect to encounter so forthrightly. Kistaro Windrider (talk) 23:17, 29 October 2025 (UTC)

You can hide them using the notpageimage class on the file. sapphaline (talk) 10:03, 30 October 2025 (UTC)

Now that I see that the "bad image list" exists, I feel like that should be used as a denylist for images used in cards for autocompleted searches. I'll take a look at the notpageimage thing, thank you! Kistaro Windrider (talk) 03:13, 31 October 2025 (UTC)

Okay, so this images is from the infobox, and template Infobox Anatomy does not allow a way to specify classes with the image. I'm filing a template edit request for that. Meanwhile, the pageimages docs suggest that the "Pageimages-denylist" _does_ exist, but it apparently does not (functionally) transclude the Bad Images List, which it probably should. Kistaro Windrider (talk) 03:47, 31 October 2025 (UTC)

Aren't all of these already drawings for that reason ? —TheDJ (talk • contribs) 12:36, 30 October 2025 (UTC)

A Standard-like thing I made

User:Sapphaline/vector.css. Look at it. Isn't that pretty? sapphaline (talk) 10:30, 30 October 2025 (UTC)

You probably want to clarify that this is for legacy vector. On vector-2022, it breaks the layout. – SD0001 (talk) 11:19, 30 October 2025 (UTC)

Do vector.css styles affect Vector-2022 though? I thought Vector-2022 styles should go to vector-2022.css. sapphaline (talk) 12:23, 30 October 2025 (UTC)

Facepalm I missed reading the page name. – SD0001 (talk) 12:28, 30 October 2025 (UTC)

Introducing SuggestedInvestigations

Over the past several months, checkusers have been collaborating with Wikimedia Foundation staff on a new tool called Special:SuggestedInvestigations, or SI (documented in part at mw:Product Safety and Integrity/Anti-abuse signals/Suggested Investigations). The collaboration was sparked by a mutual understanding between CUs and staff that the CheckUser tool was becoming outclassed due to the decline in usefulness of IP and user agent information. SI is a work in progress and is very much in the beta stages, but it has shown great promise in identifying abuse in a very short period of time.

SuggestedInvestigations works much like the existing abuse filter in log-only mode, except the conditions are managed by WMF rather than by volunteers. SI runs against certain non-public information, and is accessible only to CUs and stewards on a few wikis, including the English Wikipedia. Right now, there are only a very small number of signals in the tool, but staff and volunteers are working together to add additional signals over time, based on our experience investigating abuse. The WMF mentioned in their blog post on hCaptcha that that is one of the signals, but otherwise, like private abuse filters, other signals will stay private for BEANS reasons.

Over the past month since the tool rolled out, the CU team has found it valuable for detecting abuse. The captcha signal has allowed us to respond quickly to semi-automated subtle spambots. Another signal has helped us better detect long-term abuse cases returning to the project.

Since we're talking about private signals, we would like to allay some fears the community may have. SuggestedInvestigations only acts as a sign that a volunteer should take a look at an account’s edits. A signal being tripped is neither, by itself, a valid reason to run a check nor a reason to block an account. Behavioral evidence will continue to be needed for both. SuggestedInvestigations is not fishing – it is raising things to look at that we may not have noticed any other way.

On behalf of the checkuser team,

-- Guerillero ^{Parlez Moi} 19:16, 30 October 2025 (UTC)

Thanks to Guerillero for helping lead this on the functionary side, as well as to the WMF staffers who have worked really hard to develop this fairly quickly after we requested it. This has been quite a useful tool and has proven helpful in hundreds of blocks and global locks already. Best, KevinL (aka L235 · t · c) 20:10, 30 October 2025 (UTC)

comments

Hi, in newest Vector skin the TOC shows the number of comments to each section of talk pages. Can anybody explain how the numbers of comments have been calculated? – Doc Taxon • Talk • 20:46, 30 October 2025 (UTC)

Doc Taxon, I'm not sure I understand the question. It adds up all the comments that are parsed by the reply tool. — Qwerfjkltalk 21:32, 30 October 2025 (UTC)

Number of signatures basically, which is the way that Discussion Tools computes where a comment starts/ends. Izno (talk) 21:32, 30 October 2025 (UTC)

Some information is available at mw:Extension:DiscussionTools/How it works#Parsing algorithm. Matma Rex talk 22:20, 30 October 2025 (UTC)

"Too many requests"

Lately my bot has been getting an API login error containing this text:

Wikimedia Error 
Error 
Too many requests (620f469) 
If you report this error to the Wikimedia System Administrators, please include the details below.   Request served via cp1102 cp1102, Varnish XID 331582734 Upstream caches: cp1102 int Error: 429, Too many requests (620f469) at Fri, 31 Oct 2025 00:43:08 GMT   Sensitive client information IP address: xxx.xxx.xxx.xxx

This appears to have something to do with rate limiting applied to IP addresses. Last night, I was able to reset my router to get a new IP address, and the error went away. But then it happened again tonight, using a completely different subnet. Is this a new rate limit, or did I just unluckily start hitting it? —scs (talk) 00:48, 31 October 2025 (UTC)

Are you setting a proper User-Agent for your bot? WMF has been trying to enforce m:User-Agent policy lately to try to crack down on AI crawlers. Anomie⚔ 01:56, 31 October 2025 (UTC)

Hmm. I'm setting a User-Agent; MediaWiki has been requiring that for years. Whether it's "proper" is another question. Next time I get the error I'll try tinkering with it. —scs (talk) 04:44, 31 October 2025 (UTC)

Change to login screen

I assume the login screen's boxes being...like, twice the width as they were previously is somehow related to the pending rollout of temporary accounts? - The Bushranger _{One ping only} 01:06, 31 October 2025 (UTC)

More specifically, the width of the mw-htmlform class on that page is now 28rem; it was 290px just yesterday. sapphaline (talk) 10:43, 31 October 2025 (UTC)

This isn't related to temporary accounts. It was changed in gerrit:1199266 to fix some issues where longer texts in some languages didn't fit (T355853, T407172) and make it consistent with the Codex style guide. Relatedly a bug where Special:UserLogin and Special:CreateAccount had different page widths has also recently been fixed (T408447). the wub "?!" 12:02, 31 October 2025 (UTC)

Tool

Is there a tool that can merge duplicate references into a single source like <ref name=abc/> Rafael Ronen 12:56, 31 October 2025 (UTC)

Wikipedia:reFill merges duplicate references in addition to its main goal of expanding bare references. Also, if you want to use something much more advanced, look into Wikipedia:AutoWikiBrowser - doing what you need is one of its "general fixes". Stefen 𝕋ower_{'s got the power!!1!} ^{Gab • Gruntwerk} 14:29, 31 October 2025 (UTC)

How do we add usage count at top of an infobox template

How do I add "This template is used on approximately ____ pages" phrasing at the top of Template:Infobox horse breed in the same way it displays on Template:Infobox company? I checked the /doc file, and it uses a template {{Uses Wikidata}} but the whole Wikidata topic is jibberish to me.   ▶ I am Grorp ◀ 15:28, 31 October 2025 (UTC)

That notice is provided by {{High-use}} in the documentation page. For Template:Infobox horse breed, it will not show the number, because numbers are shown when there are 2,000 or more transclusions. It will instead say "many pages" and provide a link to a page that shows a count of the number of transclusions. – Jonesey95 (talk) 15:40, 31 October 2025 (UTC)

Ok. I see that it's used in potentially 1,364 articles, and that's less than 2,000. However, it would be nice to have that link, even if it says "many pages". I'm less interested in the count, and more interested in having that link. (Right now there's a bug in it, see talk page, and I want one to be able to find a few examples to test if the bug is fixed.)   ▶ I am Grorp ◀ 15:51, 31 October 2025 (UTC)