This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
No longer getting mobile version by default when on mobile?
Has some setting changed? Or is there something in preferences that I’ve accidentally switched or something? Or is this just a problem for me? Am on iPhone 14 latest iOS version using Chrome. FOARP (talk) 16:51, 22 October 2025 (UTC)
Yeah, I can force it to serve the mobile version by adding the “m” to the URL but otherwise I get the desktop version by default. My browser settings are set to preferring the mobile version but I’m not getting that. FOARP (talk) 17:41, 23 October 2025 (UTC)
I uploaded a new image and immediately sent it to Wikipedia:Graphics Lab/Illustration workshop because it contains some problems. And for this reason, I don't want to use it in the article yet. Now I'm waiting for the fixed version so that I can use it in the article and fill in the file parameters with {{Non-free use rationale logo}}, however, a bot has already tagged that image with {{untagged}} - this means that it should be deleted after seven days. Can you advise me what to do in such a situation? Thanks, Maiō T. (talk) 19:23, 23 October 2025 (UTC)
@Maiō T. Looks like this particular issue was resolved, but in the future when posting to the illustration workshop you can just link to where the file exists on the web instead of uploading it first. --Ahecht (TALK PAGE)19:12, 24 October 2025 (UTC)
Two galleries in an article make images in the second one unclickable
So in Le_Touquet#The_peak_years_(1902–1940) there are two galleries created using an HTML-esque gallery tag. The first one works fine, but on desktop (not tested on mobile) the subsequent ones are not clickable and the images are skipped when you go through preview of all images. The behaviour is replicated across major browsers. All tags are appropriately closed.
ETA: The twelfth image in the first gallery also doesn't work for whatever reason.
It's not because there's two galleries. It's because all the images in the second gallery are specifically set unclickable, by including |link=|. Fixed. —Cryptic21:47, 25 October 2025 (UTC)
I'm Swedish, which means I'm obsessed with comparing anything Swedish to other countries, especially other Scandinavian countries. Recently I started to look into who are the translators of Swedish literature into Ukrainian. The article Swedish literature on Ukrainian Wikipedia (uk:Шведська література, 72 kbyte) is very long and detailed, so I immediately compared it to the corresponding articles for Norwegian and Danish literature. The Norwegian (uk:Норвезька література, 108 kbyte) is also detailed, but the Danish (uk:Данська література, 3.7 kbyte) is a joke. It turns out, Swedish Wikipedia's article about Danish literature (sv:Dansk litteratur, 2.7 kbyte) is also really short and poor. Here's where I want to create a matrix or table with columns for Swedish, Norwegian, Danish, etc. literature, and rows for the articles in Ukrainian, Swedish, English, German, etc. Wikipedia. Is there already some tool that will generate this table for me? You'd guess that WP:WikiProject Literature has done something like this, and that they would already have designed or requested a tool for it? But maybe not. But the need for such a tool is not limited to literature. Maybe friends of sports or music have already done this? Could Wikidata help me? LA2 (talk) 20:46, 20 October 2025 (UTC)
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. [3]
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. [4]
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. [5]
"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:
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)
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 Contribs18: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)
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)
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: RichFarmbrough22:08, 27 October 2025 (UTC).
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)
Thanks Rummskartoffel, you're right. The timing threw me off, but disabling chrome://flags#force-off-text-autosizing (as originally suggested by Srapoj[6]) solves the problem so it's an issue with Android Chrome. -- LCU ActivelyDisinterested«@» °∆t°01:55, 29 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: RichFarmbrough21:09, 25 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:
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: RichFarmbrough22: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 Rextalk13: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: RichFarmbrough10:52, 29 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.
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)
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.
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).
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)
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)
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. [7]
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. [8]
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. [9]
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)
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)
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.
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. — Qwerfjkltalk21:05, 27 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)
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)
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)
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.
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)
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)
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)
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.
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?
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)
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)
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)
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)
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)
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)
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)
How do we add usage count at top of an infobox template
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)
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 edits21:36, 22 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)
I'm on Firefox 144.0.2 on mobile (I think it has updated since I first posted about this, but the issue persists), under Android 12. I have automatic font sizing selected,
I use Vector. I don't see the issue if I open a page in a private window (so not logged in).
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)
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)
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, Miniapolis21:10, 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)
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)
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, Miniapolis19:33, 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, Miniapolis22: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, Miniapolis13:52, 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. Miniapolis20: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, Miniapolis00:52, 30 October 2025 (UTC)
We've had this particular LTA show up here before. They need a little more than a onetime filter setup as they have previously evaded our filters. Izno (talk) 19:16, 3 November 2025 (UTC)
Scam website
Every time I click a link on Wikipedia, it redirects me to a fake website called gmagicinstll instead. What should I do, it's Indian and I can't escape it. It's just a scam faking ticket booking website that I am angry with. PlutoTheCardinal (talk) 09:04, 2 November 2025 (UTC)
@PlutoTheCardinal: Make sure you are viewing the real Wikipedia at wikipedia.org and not a mirror at another domain. If you are here at wikipedia.org then it does sound like malware. It might be a browser extension with a hidden malicious feature. PrimeHunter (talk) 01:18, 3 November 2025 (UTC)
There are websites that rate anti-virus software on windows, mac and android. Find a good one and a time slot where you are not using your device for 1-2 hours. Then do a full scan in that time slot. Once that is done schedule a full system scan when you are not using your device preferrably weekly, but at least monthly. Snævar (talk) 20:24, 3 November 2025 (UTC)
Anyone else noticed the way the mw-changeslist-last class is applied on Watchlist/RecentChanges has changed? It used to be on the last edit to the page, but now it's the opposite; it's on all non-last edits. This has broken some of my scripts and Twinkle. Nardog (talk) 15:46, 1 November 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)
...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 BushrangerOne ping only21:42, 28 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). — xaosfluxTalk14: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)
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)
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)
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.
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)
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'm not familiar with the features you mention, but I have large watchlist that I have not been able to edit for several years now. That part of the change is very welcome. older ≠ wiser12:02, 4 November 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
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)
@CParle (WMF) This is exactly how I also used Watchlist in my workflow- different types of content gets different watch lengths. It's really frustrating this change was implemented with no apparent discussion beforehand? qcne(talk)21:35, 2 November 2025 (UTC)
Hello. I noticed the map at the bottom of the Infobox for the University of Georgia article does not center on the largest and main campus in Athens, Georgia. All this is quite beyond me and I have no clue about coding. If you look at the map at the bottom of the Infobox it shows an area in the middle of nowhere. As I see the map in its present configuration, if a reader repeatedly expands the map to cover the whole state, the reader will finally see the main Athens location. Please excuse my ignorance, but since the small university locations (Tifton, Atlanta, Griffin, Lawrenceville, Washington, D.C., Trinity College of Oxford University, and Cortona, Italy) probably should be ignored for map purposes, can the map be oriented to center on the main Athens campus in the Infobox without having to continually expand the map? Or maybe get a different map? See, also,https://en.wikipedia.org/w/index.php?title=User_talk:Quaerens-veritatem&action=edit§ion=38. Thanks for your help. Quaerens-veritatem (talk) 05:47, 4 November 2025 (UTC)
I tried messing around with this earlier, and I can’t for the life of me see why the map is positioned wrong. The coordinates are correct in the infobox and in Wikidata, and the OpenStreetMap relation data looks correct, but the map still stores the wrong coordinates. Tagging @Joy: as they recently implemented the map in the infobox. cyberdog958Talk09:44, 4 November 2025 (UTC)
Thanks for the ping!
The immediate problem seems to be that there's two shapes connected to this wikidata item, the Athens location and the Tifton location. For some reason the automatic zoom facility didn't figure this out well, and just zoomed too much into the midpoint. I helped it out manually as a start.
The second matter is do we actually want this to happen? If not, for example if we want to remove the Tifton location from that map, we need to unhook it from the same Wikidata entry.
Notice how it also has a link to wikidata d:Q761534. If we remove this, or replace it with a more specific wikidata ID for that particular campus, Kartographer will stop showing it on Wikipedia for the main university article. --Joy (talk) 09:55, 4 November 2025 (UTC)
@Joy This happens because of inconsistency of OpenStreetMaps and Wikipedia. So you can apply the same solution for other mapframes. For example Wudongde Dam has the same problem and we can apply the same solution. Hooman Mallahzadeh (talk) 10:25, 4 November 2025 (UTC)
@Joy Updates of OSM needs about 1 days and Wikipedia cannot tolerate such delay. Additionally, working with OpenStreetMaps needs expertise. So this solution is very fast and convenient. Hooman Mallahzadeh (talk) 10:30, 4 November 2025 (UTC)
Why can't we tolerate a delay again? Because we're so impatient about... an encyclopedia? :D
I mean it's fine to have one workaround or another. But adding more and more workaround code, like the turning off of mapframe-shape and whatnot, creates a risk that the point gets lost in translation and we create pointless side effects. In this case, we could easily forget to revert that workarounds for a long time, during which time we would continue to deprive readers of the ability to see the shape. --Joy (talk) 10:36, 4 November 2025 (UTC)
@TheDJ I think deadline mentioned in Wikipedia:There is no deadline is about a different subject. Yes, Wikipedia can tolerate "delayed articles", but I think "Wikipedia cannot tolerate a software bug" not only on Wikipedia but also in any other website and software. Software bugs should be corrected as soon as possible without any delay.
It definitely can. It has 60000 of them at any time. When people then try to workaround stuff for something that is fixed within a week, the likelihood is larger they break long term maintainability, then that they are helping actual people. A weeks long problem would be a different thing, but this is a day. We have plenty vandalism that takes longer to be detected. —TheDJ (talk • contribs) 12:31, 4 November 2025 (UTC)
@TheDJ The problem with OSM is that correcting such bugs need expertise. My idea is this:
BTW, I've applied that change, as soon as it propagates to Wikimedia maps the zoom workaround can be removed. --Joy (talk) 10:28, 4 November 2025 (UTC)
Once the duplicate relationship from OSM to Wikidata is removed at OSM, it needs to get into the data set that Kartographer renders. After that happens, Kartographer will see only one shape and will be able to zoom based on that, hopefully correctly. --Joy (talk) 10:38, 4 November 2025 (UTC)
To be honest, even though I am a software engineer, correcting OSM item for, for example Wudongde Dam, is very time-consuming for me. So please pay attention that this solution is not so bad and can be helpful. Hooman Mallahzadeh (talk) 10:44, 4 November 2025 (UTC)
In Firefox and Microsoft Edge, the sticky header covers up any anchor links that I visit. Safari on iOS does not have this problem. I have created an example for others to test. See Crafty Apes. Viriditas (talk) 22:41, 3 November 2025 (UTC)
Apologies, I'm referring to the sticky header layout at the top of every page in the vector interface (vector-sticky-header-start). Viriditas (talk) 21:23, 4 November 2025 (UTC)
Updating anon editnotices for temp accounts
I'm not an expert on where all the MediaWiki interface message editnotices live, but there are at least two more that should be updated for temp accounts:
There's at least one more that's used on this page when editing in incognito which was updated with the following language: "You are not logged in. Once you make an edit, your IP address will be hidden behind a temporary account, but can be viewed by other editors to prevent abuse." Ed[talk][OMT]15:24, 4 November 2025 (UTC)
The welcome templates for unregistered users (Template:Welcome-unregistered and the like) should also have their wording slightly altered to remove mentions of "IP addresses being visible". I don't have the time to start a separate RFC on that right now, but someone else should if they are able. I haven't seen any clarification from the admins on what will happen to those templates, and I think it would be better to just slightly change the wording rather than completely retiring them, since temporary accounts are still technically unregistered. ApexParagon (talk) 16:22, 4 November 2025 (UTC)
The two messages you mention are not used when temp accounts are enabled, they are replaced by these instead:
Interesting. I posted here after testing the edit screen in incognito mode and those popped up. Perhaps the deployment was still in progress. Thanks for the info! Ed[talk][OMT]22:06, 4 November 2025 (UTC)
Is the unblock wizard ready for widespread testing/deployment?
Sort of continuing discussion from MediaWiki talk:Blockedtext, and following on the advice of Pppery, I want to discuss if the unblock wizard is ready to be mentioned more widely in documentation. I already boldly updated a few pages to mention the unblock wizard to encourage some use (see Special:WhatLinksHere/Project:Unblock wizard).
There are a couple of oversights and bugs that are yet to be fixed, including in one of the messages it still links to the original GitHub repository but should link to the instance on GitLab so that users can launch a pull request to fix it. If the wizard is also ready for more widespread use we can template protect the entire unblock wizard and insert a protection editnotice on each of the unblock wizard pages. Aasim (話す) 02:16, 5 November 2025 (UTC)
When I click "Create new sandbox TemplateStyles page", I get Bad title Did you mean: ~~~, an EP by Ana Roxanne? The requested page title contains an invalid magic tilde sequence (~~~).. VectorWorld (talk) 13:43, 5 November 2025 (UTC)
I think it's because triple tildes only work in WikiText, not in URLs which is what's happening. Also even if it did work, it would expand to your signature not your username.
Hi. It seems this wiki does not index pages in the User namespace by default. The questions is, if another wiki also want to do so, they have to get community consensus and file a ticket on Phabricator, as mentioned in m:Requesting wiki configuration changes, or just having to edit a specific page, eg. MediaWiki:Robots.txt? If this wiki use none of method I mentioned for noindexing userpages, then which method is this wiki currently using? Thanks. Nvdtn19 (talk) 19:09, 5 November 2025 (UTC)
Still confused after reading WP:BLOCK: If an account is hard-blocked indefinitely, does that mean the underlying IP is also blocked from editing or account creation indefinitely? Catalk to me!00:07, 6 November 2025 (UTC)
@Ca If autoblocking is not enabled on the particular block an indef block doesn't affect the IP at all. If autoblocking is enabled, the IP would only be blocked for 24 hours after the last edit attempt by the blocked account. --Ahecht (TALK PAGE)00:14, 6 November 2025 (UTC)
Thanks for clarification. I was confused because it seemed to conflict with the policy that IPs shouldn't be blocked indefinitely. Catalk to me!00:20, 6 November 2025 (UTC)
Find articles that have recently had a specific word added?
I understand that the search function allows me to find all articles containing a word and sort them by the creation date or the last edited date. However, this isn't what I'm looking for, as it includes articles that already had that word before being edited. I only want to identify articles where a specific word has been newly added. Is there any way to do this? Frap (talk) 00:25, 4 November 2025 (UTC)
@Frap You could submit a request for an edit filter to log additions of that word, although that would only catch the word being added after the filter was created. Otherwise, you may be able to set up a query at Quarry. --Ahecht (TALK PAGE)19:13, 4 November 2025 (UTC)
Such an edit filter would likely be rejected unless it was specifically about watching for abuse (because we have a technical limit to filter operations). Arbitrary addition of "catamaran" doesn't fit into that set.
I am not sure how Quarry would be useful here. It does not have access to the revision text table and I am pretty sure it does not have access to diff text for the same reason.
I am pretty sure the answer to the original question is no, there is no existing tool for what Frap wants. Building such a tool that doesn't rely on an edit filter is in the realm of feasible for someone technical (watch the RecentChanges stream, check each diff a la edit filters, see if the word of interest shows up), which it kind of looks like Frap could be described as one such. Izno (talk) 19:42, 4 November 2025 (UTC)
@Inzo, would I have to make a new request for every diff? Sounds like it would be very heavy to make thousands of requests. Frap (talk) 20:40, 4 November 2025 (UTC)
Which is why this doesn't exist right now. Because it is expensive to gather that information and keep it up to date in a way that you can use it to look for something again. —TheDJ (talk • contribs) 14:30, 5 November 2025 (UTC)
I don't know about "up to date", but I do think it would be expensive. I would guess requests for diffs can be batched.
I took a lot at that page but was not able to figure out how that would be useful. It presents me with a live stream but I want to look back at the history of lets say pages modified in the last 7 days or so. It would stream everything to me, then I would have to filter it on my side which would lead it to send me much data, but I would want it filtered on the server side then sent to me so it sends me less data. It sends me data from all Wikipedia languages but I only want data from the English language Wikipedia. It sends me data from all namespaces, but I only want changes to articles. Frap (talk) 00:24, 6 November 2025 (UTC)
Another approach: Search, save the results, wait, search again, compare. The internal search at Special:Search might be adequate if the word you're interested in appears on comparatively few pages; downloading a database dump and searching it locally will probably be necessary if it appears on many. —Cryptic06:50, 6 November 2025 (UTC)
Special:Search is not so good because then it doesn't show pages which already had the word but to which the word was added again. Downloading the database dump seems like it would be pretty large and inconvenient due to its sheer size. Frap (talk) 12:56, 6 November 2025 (UTC)
A patch implemented as part of phab:T247432 seems to have changed how interwiki links to toolforge tools work. Previously, a link such as [[toolforge:foo/bar?param=value]] would go to https://foo.toolforge.org/bar?param=value, but it's now getting URL encoded and goes to https://foo.toolforge.org/bar%3Fparam%3Dvalue, which many toolforge tools may not be able to accept. Please check on any toolforge links you may be using, and you may need to swap them with an external link until this is resolved. --Ahecht (TALK PAGE)15:54, 6 November 2025 (UTC)
Advice regarding potential Range Block on the Icelandic language Wikipedia
Hi,
I would like to ask for help regarding a potential range block against a contributor on the Icelandic language Wikipedia. The contributor in question was permanently banned by unanimous decision several months ago due to repeated breaches of policies and guidelines and constant uses of sockpuppetry. However, he has persistently continued to make similar edits using either sockpuppet accounts or numerous different IP addresses. His IP addresses typically share a range of numbers.
I wanted to ask firstly if a range block is appropriate in this situation and secondly, if anyone could then give instructions on how to perform the range block? TKSnaevarr (talk) 04:54, 7 November 2025 (UTC)
|style="background:;" | {{collapsible list|
| title = ABC
| titlestyle = background:transparent;text-align:center;font-weight:normal;font-size: 105%|
*HGB
}} in title = ABC dark mode text not showing, how to fix it? Rafael Ronen03:53, 7 November 2025 (UTC)
Remove the empty background assignment in the table cell and the transparent background from the titlestyle, or set the foreground color explicitly. hgzh11:57, 7 November 2025 (UTC)
I got a rednotice on my JS page about this script I was installing and said scripts on those pages can compromise accounts and it told me if I had doubts to ask here about it was safe so I wanted to ask is this safe User:Qwerfjkl/scripts/CFDlister(and if it is safe do I need to do anything about the red warning notice or just leave it.) GothicGolem29(Talk)17:35, 7 November 2025 (UTC)
I do not like the temporary account thing, I do not mind my IP being public. I don't want this forced temp account. I'm just used to what it used to be before. ~2025-31874-31 (talk) 13:23, 7 November 2025 (UTC)
Some notes: Your temporary account's IP information remains visible for users with sufficient permissions. If you don't change your IP address and don't clear your cookies, your temporary account also won't change. Izno (talk) 18:11, 7 November 2025 (UTC)
It’s not quite that simple. If you edit from different devices (eg an iPad and a laptop) the edits from each device will have a different temporary account because each device has its own set of cookies. Also, temporary accounts expire after 90 days so the next time you edit after then, you’ll get a new temporary account. Neiltonks (talk) 18:55, 7 November 2025 (UTC)
Short answer: no. Why not? Because to make that calculation - say, converting 50% into n pixels, you first need to know the width of the space that you're fitting it into. But that depends upon many factors - for instance, what is the width of somebody else's screen? Nobody knows for sure, except the person actually viewing that screen. I could go on, but I won't. I've made this point so many times that I really should make it into a userspace essay. --Redrose64 🌹 (talk) 19:39, 7 November 2025 (UTC)
Page creation disabled in DRAFTspace for temp accounts?
Has Wikipedia disabled draft article creation for what were IP users, now temp users? I'm unable to use the article wizard to create a new draft, nor is directly accessing the DRAFTspace page and trying to create it that way possible, as the [CREATE] button is missing. And adding a ?action=edit results in the Permission Error page, the same error page that results in trying to make an ARTICLEspace page -- ~2025-31118-76 (talk) 22:00, 5 November 2025 (UTC)
I can edit an existing page in draft space, I cannot create a new draft in draftspace. So this would pertain to the Page Creation permission bit, I would assume. -- ~2025-31118-76 (talk) 22:29, 5 November 2025 (UTC)
@Izno I'm seeing the same thing when I try to create an account a draft while logged out. I get a "You do not have permission to edit this page" message that tells me to log in or create an account and be autoconfirmed. --Ahecht (TALK PAGE)22:27, 5 November 2025 (UTC)
@Ahecht Do you mean "when I try to create a page" instead of "create an account"? If so, that is expected, as logged out (or temp) users do not have the permission to create pages outside of the 'Draft:' namespace here. If you really see that message while trying to create an account, that's weird, please share more details (ideally a screenshot). Matma Rextalk22:36, 5 November 2025 (UTC)
@~2025-31118-76 Thanks for reporting. I can reproduce this, it seems like a bug in the configuration. To be clear, I clicked through Wikipedia:Article wizard and ended up on this URL: [11]. While logged out (not using a temp account), I see a page with instructions and an edit field (F69919483). While using a temp account, I see "You do not have permission to edit this page…" (F69919486). Matma Rextalk22:34, 5 November 2025 (UTC)
Looks like this should be fixed within the next few hours if I am reading things correctly. Is there a draft article location that you would prefer someone create for you in the meantime or not? --Super Goku V (talk) 07:05, 6 November 2025 (UTC)
Having trouble looking at articles, histories, and edits are not saving. Multiple browsers. Also wmcloud and maybe toolforge have been slow for days. Anybody in the know care to share what's going on? Abductive (reasoning)20:58, 7 November 2025 (UTC)
It seems that, at the moment, most of the values outputted by the template is "-1". See the article Wikipedia's infobox. The {{format price}} template as used on the infobox cannot parse the output of numberof because it is negative. The data sources as listed at the template's documentation seem to be intact. Anyone know what is going on here? Justjourney (talk | contribs) 03:22, 8 November 2025 (UTC)
No idea what happened because some debugging seemed to show the data was at enwiki while the problem persisted. For the record, {{NUMBEROF|articles|fr}} was giving -1 here (that's the error return if frwiki is not found in the data). Anyway, the problem has gone away. The data comes from Commons (c:Data:Wikipedia_statistics/data.tab) so some kind of caching problem. Johnuniq (talk) 04:11, 8 November 2025 (UTC)
Again for the record, the problem was that the data was corrupted at the Commons link above due to some kind of problem with the bot that updates the data. The corruption was then fixed. Johnuniq (talk) 04:16, 8 November 2025 (UTC)
Thanks, John. I suspect the corruption originated with the MW API (can't replicate). Possibly API:SiteMatrix returned missing sites. I just added a sanity check on the JSON size, which will skip and log if this happens again. -- GreenC05:12, 8 November 2025 (UTC)
In case you didn't notice, the statistics data had entries with, for example, "fr" in the first column. The fix restored "fr.wikipedia". Johnuniq (talk) 05:46, 8 November 2025 (UTC)
This is one of the more strange bugs I've come across. There are fingerprints in multiple places and logs that show what happened, but they make no sense, impossibilities. Everything has an explanation, this one is a mystery. I don't think it's the bot code but something on the MW side, like GIGO or backend with editing. I've added additional logging in case it happens again. -- GreenC16:24, 8 November 2025 (UTC)
Section links with [square brackets] in edit summaries
This turns out to be caused by a mitigation for a different security issue. Your bug report has already been noted there, perhaps we can find a better solution. Matma Rextalk17:54, 3 November 2025 (UTC)
Hello. Since temporary accounts are now forced on users, a default skin is also applied that's problematic to me: the "Tools" bar at right should be at the left and cannot be folded without scripts enabled, for instance. TAs apparently don't have skin preferences. I could use special browser-side tools to alter the skin, but considering that useskin as part of a URL corrects those issues, I thought that if there was a cookie equivalent I could configure, it would be ideal. Searching the VPT archives I found nothing related. Does this feature exist, if not, would it be a good suggestion candidate? Thanks. ~2025-31363-35 (talk) 20:30, 7 November 2025 (UTC)
IPs also don't have skin preferences, so this has not changed with TAs. There is no supported technical way to change the skin. I know of at least one browser extension lying around that will forcibly add useskin to your URL which you may seek for yourself.
Thanks, there was no such issue with IP editing before November 4, though. There was a working "..." menu at the top-right that could be clicked to get access to "contributions", etc. I suspect that the default skin was changed, possibly to accomodate a new TA-specific feature... (edit): Oh I did use custom local CSS to hide the right bar which apparently had buttons to resize text, but then the now absent working menu provided what was needed (I have disabled my Stylus entry for now to have access to those options, so the "Tools" bar is now "in the way"). ~2025-31363-35 (talk) 20:53, 7 November 2025 (UTC)
With a virgin profile, without having edited yet, so not under a TA profile, what I see is what I used to, the bar at right is an "appearance" one (the one my custom CSS was meant to hide, I found it useless to me and to limit the text width, considering that I use multiple vertical windows in a 16:9 screen rather than a fullscreen one, the article text was now cramped between two bars). The table of contents is in a "contents" bar at left. The "..." menu is gone because legacy IP editing now being disabled, there's no "my contributions", etc. So then I did a test edit in the sandbox to create a TA profile. The appearence changes a little, there's now a menu at top for the notifications and contributions, a bar with the name of the TA, as expected (the same as above). There also is now both "appearance" and "tools" in the bar at right, which are suboptimal there as above. But the virgin profile also has scripts enabled and so I can optionally manually hide each away, then the right bar disappears. While that's nice, it won't be my common use case. This means that I'll still need to use custom CSS (or a DOM altering local script) to move the right bar away. For now I've also noticed that if I zoom the text a bit the bar floats away falling somewhere at the left, that's some sort of compromise as well. Thanks again, ~2025-31363-35 (talk) 22:56, 9 November 2025 (UTC)
Scripts and gadgets sometimes not loading
Context: I'm using Firefox on Linux, and the Vector legacy skin.
Sometimes, for no apparent reason, my scripts and gadgets just don't load, or only partially load. For example, I have the personal toolbar clock gadget enabled, and often it'll clear the space that the clock is meant to be in but doesn't show the clock itself, so it's just a blank space next to "log out". Other times, a couple of my toolbox scripts will load, but not others. Now the RefToolbar gadget has started to sometimes stop working (which is a huge blow to me, it's by far one of my most-used gadgets), and while most of these problems are solved by hard refreshing the page, RefToolbar seems to be stubborn and only fixed itself randomly after many refreshes, purges, and opening and closing tabs. This also comes a few months after the disambiguation warning pop-up stopped appearing for me, which was (and still is) a big annoyance.
When on an edit page, where most things loaded but not RefToolbar: (In this case there were also three "this ResourceLoader module is deprecated" warnings, for jquery.ui, mediawiki.ui.button, and moment.)
Uncaught SyntaxError: missing ) after argument list
n index.php:1
jQuery 2
mightThrow
process
index.php:23:132
When reading an article, where the vast majority of my toolbox scripts and those in the "More" dropdown didn't load: zero errors, just two deprecated module warnings (the first two of the ones I listed above).
When editing another article, where I again didn't notice anything missing except for RefToolbar: a lot of HTML HTTP 429 errors for different scripts, with one example here -
If there's a way to show these without it taking up lots of vertical space, please let me know, this feels like it's taking up far too much space as it is. Suntooooth, it/he (talk | contribs) 17:03, 9 November 2025 (UTC)
One more error that I forgot to add: I don't have the exact error in my clipboard anymore and since this problem is random it's hard to recreate, but when the clock gadget failed to load in the way that I described above, there was a cross-domain error (IIRC) relating to the link to that gadget's JS page. Suntooooth, it/he (talk | contribs) 17:17, 9 November 2025 (UTC)
I tried a bunch of things (copying your common.js, testing in Firefox on both Vector skins with different "Tracking Protection" settings, etc.), but I couldn't reproduce the issue of scripts failing to load or show up in the toolbar.
The 429 errors probably showed up because you refreshed the page too many times. The syntax error comes from Macaw*'s User:Macaw*/noRefListAlert.js#L-23 (line 23) where it's missing a ')': rawHTML.indexOf('{{reflist}}');. That doesn't resolve the issue you described, though. — DVRTed (Talk) 20:53, 9 November 2025 (UTC)
Thank you for testing. Because you couldn't recreate it, I was thinking it might be a browser issue, but I just tested on Degoogled Chromium and I'm having the same issues. Here's the error relating to the clock gadget, since it happened again:
I also got a lot of 429 errors, despite not refreshing at all - I'm using a proxy (as I'm IP block exempt) and I wonder if there's a crawler using the same node and causing me to get these 429s. Not sure if that explains my problems though, considering there weren't any console errors in the second example I posted above. Suntooooth, it/he (talk | contribs) 21:38, 9 November 2025 (UTC)
Hey All. We have rolled out one method of interactive visualization for OWID based on an all Commons svg approach. You can see the integration of these graphs here.
With this technique we are able to bring over limited functionality of the OWID "grapher visualizations", we however are unable to support their newer and more complex explorer visualizations which one can see here MDWiki:WikiProjectMed:OWID_popup#Explorer.
Wikimedia Foundation and Our World in Data technical staff are interested in meeting with interested Wikipedians to pitch possible usage to this community. We do not have a date set as first I am wanting to collect interest for such a discussion / plus concerns folks have. The WMF supports its use and has a signed MOU and are happy from a security perspective and license perspective.
If I edit via the API, how does that interact with temporary accounts? There's (probably) no cookie management going on, so does a new TA get created on every API call? RoySmith(talk)13:44, 9 November 2025 (UTC)
Not on every API call. But if the API process isn't handling cookies (and isn't logged in with OAuth or the like), then yes, they'd get a new TA created on every edit or other action that triggers creation of a temp account. And probably quickly hit the daily temp-account creation rate limit. Anomie⚔15:27, 9 November 2025 (UTC)
I know that most client-side HTTP libraries have the ability to handle cookies, but many real-world application don't set that up. For example, the popular requests package for python only handles cookies if you go to the trouble to create a session and people often don't bother. And even if you did, if your client is multi-threaded (or multi-process), each thread will have its own session and thus its own cookie jar.
Do API calls just start failing? I'd think so, but I haven't tested it. 🤷 But really, any API-using thing that's making logged actions shouldn't be doing it while logged out anyway, and could probably be blocked per WP:Bot policy even if it is properly managing sessions. Anomie⚔16:06, 9 November 2025 (UTC)
Hmmm, that doesn't appear to be true. Experimenting a bit, it does indeed look like the TA only gets created when I make an edit. RoySmith(talk)18:20, 9 November 2025 (UTC)
@RoySmith I haven't tested it, but I believe that temp account are only created on their home wiki on first edit, but are created on subsequent wikis on read requests. --Ahecht (TALK PAGE)15:04, 10 November 2025 (UTC)
Yes, but that's not a true account creation, just an autocreate, same as with named accounts. And you'd need to have cookies to do that anyway. There are some actions that can cause MediaWiki to reserve a temporary account name (like previewing an edit) but not fully create the temporary account, but I'm not sure any of those apply to the API. Unless you use the acquiretempusername API, of course. AntiCompositeNumber (they/them) (talk) 00:41, 11 November 2025 (UTC)
A few hours ago, trying to view a page, I received a message: Sorry! This site is experiencing technical difficulties, in large letters.
It then displayed, in medium-size letters, "Try waiting a few minutes and refreshing", and,
(Cannot access the database: Cannot access the database: Database servers in cluster31 are overloaded. In order to protect
application servers, the circuit breaking to databases of this section have been activated. Please try again a few seconds.)
I waited a few minutes, as advised, and then was able to view the pages normally.
My question is whether this is any cause for special concern, or whether the system is responding as designed to a maximum load. If this is a normal response to a peak load, I will ignore it.
@Robert McClenon This morning we had a massive network outage leading to loss of a whole row which overloaded practically everything and triggered our circuit breakers (they intentionally kill a certain subset of requests to try to keep the services up in general). It did recover in ten minutes. We are still investigating the root cause of that network incident and I will try to update here later. Thanks to theDJ for the ping. Ladsgroupoverleg11:48, 11 November 2025 (UTC)
Help with admin highlighter script, please?
Hello techies. I'm using User:Amalthea/userhighlighter.js, in a way that leaves the background color of admins' names transparent and instead adds a little crown symbol after them. Please see my User:Bishonen/common.css, right at the top. I love that silly effect, but the script seems to have just stopped working, and Amalthea has left the project. On the script's page, near the top, I find the advice "Consider using User:Theopolisme/Scripts/adminhighlighter.js instead, a better version of this script". Maybe I should do just that, but I have no idea how to modify it to get my desired effect, i. e. the effect that Amalthea's script used to give. (Theopolisme has also left the project.) Should I uninstall Amalthea's script, install Theopolisme's, and attempt to give it the same specifications as Amalthea's script now has for me? I'm a little scared of fiddling with it and making a mess, incompetent as I am. Any help, please? And might there be a third script, more up-to-date and actively maintained, that does what I want? Bishonen | tålk03:52, 11 November 2025 (UTC).
Installing Theo's script and using this in your common.css:
Thanks, Writ! I see that the little crown is back now. Should I still do it, do you think? (On the principle that Theopolisme's script is supposed to be better?) Or leave well enough alone? Bishonen | tålk07:40, 11 November 2025 (UTC).
Eh. Switching over isn't a bad idea, but honestly, I'm of the "if it ain't (currently) broken, don't fix it" opinion. Might be useful to keep this CSS in 'zilla's back pocket, in case of future need. Writ Keeper⚇♔13:47, 11 November 2025 (UTC)
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
Administrators will now find that Special:MergeHistory is now significantly more flexible about what it can merge. It can now merge sections taken from the middle of the history of the source (rather than only the start) and insert revisions anywhere in the history of the destination page (rather than only the start). [12]
For users with "Automatically subscribe to topics" enabled in their preferences, starting a new topic or adding a reply to an existing topic will now subscribe them to replies to that topic. Previously, this would only happen if the DiscussionTools "Add topic" or "Reply" widgets were used. When DiscussionTools was originally launched existing accounts were not opted in to automatic topic subscriptions, so this change should primarily affect newer accounts and users who have deliberately changed their preferences since that time. [13]
Scribunto modules can now be used to generate SVG images. This can be used to build charts, graphics and other visualizations dynamically through Lua, reducing the need to compose them externally and upload them as files. [14]
Wikimedia sites now provide all anonymous users with the option to enable a dark mode color scheme, featuring light-colored text on a dark background. This enhancement aims to deliver a more enjoyable reading experience, especially in dimly lit environments. [15]
Users with large watchlists have long faced timeouts when editing Special:EditWatchlist. The page now loads entries in smaller sections instead of all at once due to a paging update, allowing everyone to edit their watchlists smoothly. As part of the database update, sorting by expiry has been removed because it was over 100× slower than sorting by title. A community wish has been created to explore alternative ways to restore sort-by-expiry. If this feature is important to you, please support the wish! [16]
View all 31 community-submitted tasks that were resolved last week. For example, the fixing of the persisting highlighting when using VisualEditor find and replace during a query. [17]
Updates for technical contributors
Since 2019 the Wikimedia URL Shortener at https://w.wiki is available for all Wikimedia wikis to create short links to articles, permalinks, diffs, etc. It is available in the sidebar as "Get shortened URL". There are 30 wikis that also install an older "ShortUrl" extension. The old extension will soon be removed. This means /s/ URLs will not be advertised under article titles via HTML class="title-shortlink". The /s/ URLs will keep working. [18]
On Thursday, October 30, the MediaWiki Interfaces and SRE Service Operations teams began rerouting Action API traffic through a common API gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the Service Ops team board.
MediaWiki Train deployments will pause for the final two weeks of 2025: 22 December and 29 December. Backport windows will also pause between Monday, 22 December 2025 and Thursday, 2 January 2026. A backport window is a scheduled time to add things like bug fixes and configuration changes. There are seven deployment trains remaining for 2025. [19]
In 2025, the Wikimedia Foundation reported that AI systems and search engines increasingly use Wikipedia content without driving users to the site, contributing to an 8% drop in human pageviews compared to 2024. After detecting bots disguised as humans, Wikimedia updated its traffic data to reflect this shift. Read more about current user trends on Wikipedia in a Diff blog post.
HTML is a very bad tool to try to communicate the relationships in a graph. SVG isn't much better emitted-wise but would be significantly cleaner for the programmer. I agree with Sapphaline that some of these are clear and obvious rewrite targets ({{climate chart}} is another one). Izno (talk) 19:33, 4 November 2025 (UTC)
aesthetic - no. accessibility - yes, considering that some of these pseudo-graph templates are still hacking <table>s (I'm talking about template:clade and template:cladogram). include size - I think <img alt="..." src="data:image/svg+xml;base64,..."> is less HTML output than something like
Another reason to prefer SVGs is that they are "real" images that can be copied, exported, downloaded and indexed by search engines. It also contributes almost nothing to PEIS. The <img> tag isn't actually part of post-expand output – it's replaced by a strip marker which adds just about 26-30 bytes to PEIS (regardless of SVG size). – SD0001 (talk) 09:21, 7 November 2025 (UTC)
From the accessibility point of view, the SVG images don't do anything by themselves. You should think of them like any other image, so they should come with alt text and/or a caption. Often it may be helpful to display the same data in another format elsewhere on the page, e.g. the Climate chart template could generate a SVG chart with a simple HTML/wikitext table below it, perhaps collapsed.
Redoing the existing templates as SVG images without also adding alt text or other alternative presentation would probably be an accessibility regression; although I couldn't make sense of something like the Clade template using a screen reader, I imagine a more experienced user could, and at the very least it's possible to copy and read the text from it (which is no longer possible when the text is inside an image). Redoing them with some alternative presentation would definitely be an improvement. Matma Rextalk21:26, 4 November 2025 (UTC)
There are two reasons for why SVG text is not selectable, and neither is the fault of SVG itself. One reason is that some people use text that is actually just paths and thus not selectable. People should instead use the fonts at meta:SVG_fonts. The other reason is that SVG thumbnails are not shown as SVG´s, but PNG´s. As for proof that SVG can have selectable text see for example https://upload.wikimedia.org/wikipedia/commons/d/d0/IsisPapyrus.svg . There has been some progress on sending SVG´s to the browser in the subtasks of phab:T5593. Snævar (talk) 23:32, 4 November 2025 (UTC)
The Scribunto modules that we're talking about emit SVGs in <img> tags, so the text in them is not selectable anyway. Making them interactive (including text selection) would be covered by T407783, but doing this securely is difficult. Matma Rextalk19:40, 5 November 2025 (UTC)
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
Example of a talk page with the new design, in French.
MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community request. [21]
Using the "Show preview" or "Show changes" buttons in the wikitext editor will now carry over certain URL parameters like 'useskin', 'uselang' and 'section'. This update also fixes an issue where, if the browser crashed while previewing an edit to a single section, saving this edit could overwrite the entire page with just that section’s content. [22][23][24]
Wikivoyage wikis can use colored map markers in the article text. The text of these markers will now be shown in contrasting black or white color, instead of always being white. Local workarounds for the problem can be removed. [25]
The Activity tab in the Wikipedia Android app is now available for all users. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging. [26]
The Reader Growth team is launching an experiment called "Image browsing" to test how to make it easier for readers to browse and discover images on Wikipedia articles. This experiment, a mobile-only A/B test, will go live on English Wikipedia in the week of November 17 and will run for four weeks, affecting 0.05% of users on English wiki. The test launched on November 3 on Arabic, Chinese, French, Indonesian, and Vietnamese wikis, affecting up to 10% of users on those wikis. [27]
View all 27 community-submitted tasks that were resolved last week. For example the inability to lock accounts on mobile sites has been fixed. [28]
The JWT subject field in OAuth 2 access tokens will soon change from <user id> to mw:<identity type>:<user id>, where <identity type> is typically CentralAuth: (for SUL wikis) or local:<wiki id> (for other wikis). This is to avoid conflicts between different user ID types, and to make OAuth 2 access tokens and the sessionJwt cookie more similar. Old access tokens will still work. [30]
A REL1_45 branch for MediaWiki core and each of the extensions and skins in Wikimedia git has been created. This is the first step in the release process for MediaWiki 1.45.0, scheduled for late November 2025. If you are working on a critical bug fix or working on a new feature, you may need to take note of this change. [32]
The process for generating CirrusSearch dumps has been updated due to slowing performance. If you encounter any issues migrating to the replacement dumps, please contact the Search Platform Team for support. [33][34]
MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community request.
@Malcolmxl5 Enwiki already has a pretty extensive version of this of its own. It might be possible to convert that, but we first need to analyze how much functional overlap there is (or not). It’s not a very high priority, it is especially useful for wikis that don’t want to make and maintain their own version of a protection indicator. —TheDJ (talk • contribs) 07:25, 11 November 2025 (UTC)
That sounds like an easy and useful enhancement, assuming you have some use-cases in mind. It would be analogous to a long-standing feature of {{yesno}}. DMacks (talk) 17:38, 6 November 2025 (UTC)
Or we could avoid adding complexity to a simple module when {{yesno}} already exists:
{{yesno|{{#invoke:If any equal|main|a|b|c|d|value=c}}|yes=output for yes|no=output for no}} → output for yes
{{yesno|{{#invoke:If any equal|main|a|b|c|d|value=r}}|yes=output for yes|no=output for no}} → output for no
Newly added hatnote doesn't appear in mobile website
I just added a hatnote to Lexiphanes, and found that no hatnote appears on the page when viewed in mobile form through a mobile browser (I tried it on iOS through both the Safari and Firefox apps; Firefox showed it only with the "desktop site" option enabled), though it shows up normally on a regular computer (in my case Firefox 144.0 on Windows 10). I have no idea what is causing this problem. - LaetusStudiis (talk) 23:17, 12 November 2025 (UTC) This was the result of my own mistake in placing the note, as User:PrimeHunter said. - LaetusStudiis (talk) 03:00, 13 November 2025 (UTC)
@LaetusStudiis: I looked again and it actually happened because you placed the hatnote after the taxobox in the code. The mobile version didn't do anything wrong. I have moved the hatnote to the top where it belongs per MOS:ORDER. PrimeHunter (talk) 00:37, 13 November 2025 (UTC)
Does Wikipedia support inline prefers-color-scheme?
I've moved this here as suggested by WhatamIdoing:
Exactly what the question says. Does wikitext support this for CSS? My userpage uses a lot of custom CSS and has a bunch of contrast issues depending on which colour mode a user is on which I need to fix by creating overprecise CSS.
Wikitext has little support for CSS that requires media queries (though I note the existence of CSS light-dark() which might work?). What can be done regardless is for you to make a Template:TemplateStyles sandbox (see WP:TemplateStyles) and then move it to a subpage of your user page and then you have access to all the media queries you might like. Izno (talk) 05:28, 12 November 2025 (UTC)
You can make dark mode-specific styles using html.skin-theme-clientpref-night, e.g.
#mw-content-text{--discussion-threads-style-border-colour1:rgb(85%,85%,100%);/* left border colour */}/* dark mode */@mediascreen{:where(html.skin-theme-clientpref-night)#mw-content-text{--discussion-threads-style-border-colour1:rgb(5%,5%,30%);}}/* user-selected dark colour scheme */@mediascreenand(prefers-color-scheme:dark){:where(html.skin-theme-clientpref-os)#mw-content-text{--discussion-threads-style-border-colour1:rgb(5%,5%,30%);}}/* OS-selected dark colour scheme */#mw-content-text/* ... other selectors ... */{border-left:5pxsolidvar(--discussion-threads-style-border-colour1);}
Thanks; I forgot about phab:T320322. Unfortunately that means rules have to be duplicated three times to set different CSS property values for different viewing modes. isaacl (talk) 18:31, 12 November 2025 (UTC)
Reading list test: entering phase 1
Hi everyone,
This is Eliza from the Reader Experience team at the Wikimedia Foundation. The team’s focus is on making Wikipedia a more engaging and valuable place for our existing readers, encouraging them to come back to explore and learn more. We see this work as a part of addressing the decline in pageviews on Wikipedia we’ve talked about in the past. You may have recently seen my post about the Reader Growth team’s image browsing experiment. This is a separate idea focused on a different part of the reading experience.
As part of our explorations into ways to encourage readers to be more active in their experience and return to Wikipedia more frequently, next week the team will be launching a test of an early-stage version of what could become a “reading list” feature on the desktop and mobile web browser experience. This feature, which is already on the Wikipedia mobile apps, would allow readers to save articles they want to come back to later. Articles would be organized in a list that will be accessible in the top-right navigation for logged-in readers.
Why are we working on this?
We think that when readers are more active in their reading experience, they could become closer to making their first edit. We first want to explore the simplest approach to curation – allowing readers to save an article for reading later. Reading lists and saved tabs are a couple of the most popular features on the Wikipedia Android and iOS apps. Readers who use them frequently ask to sync their saved articles to their desktop reading experience.
The test is designed to help us understand if readers are interested in saving articles to read later, and whether they use these articles after they’ve saved them. The feature will be available to a small portion of randomly selected readers who have accounts with zero edits and nothing saved to their watchlists on English, Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias, accounting for about 15% of all logged-in users on these wikis.
What stage is this project in?
We are currently in Phase 1: launching a small test with an early version of these ideas. It’s not yet clear whether this feature will be an improvement for readers, so we want to test it to determine whether to proceed into Phase 2, building a feature. After the A/B test, we’ll come back here to discuss the results with you and decide together whether to proceed.
Because reading lists are an established feature on the Apps, we used learnings from the Apps team as well as informal conversations at in-person events and on Discord to serve as our research and background for Phase 0.
This is an example of what a user in the reading lists desktop experiment would see when they go to save the "Dog" article.
What is the timeline?
We will test the prototype starting the week of November 17. The test will run for 4 weeks and we will stop collecting data on December 17; however, the feature will still be accessible to the users who received it, so that they don’t lose their saved articles.
This is an example of how the reading list feature, current looks in the mobile app, where it is already deployed.
What are we testing?
The main capabilities that will be in the feature are:
Informing readers that the feature is available and indicating where to click to save an article and where to click to view the list of saved articles
Allowing readers to save articles to a private list for reading later
Allowing readers to access their list and remove articles that are no longer relevant to them
We will measure how often people are using the new feature and whether this has any positive effect on the number of pages readers open per session. If this test shows positive results on these two metrics, we will then discuss adding additional functionality, such as the ability to sync lists with the apps, creating multiple custom lists, and more.
What input are we looking for from you?
Would you as an editor find reading lists personally useful, either for your reading or editing work? If so, how?
If the experiment is successful, we will need to ensure designs avoid confusion between reading lists and watch lists. For this test, we’re only including logged-in users who don’t use the watchstar. However, if we decide to proceed with this idea in the future, we want editors as well as readers to be able to use both reading lists and watchlists.
Icons: The icons for reading lists and watchlists are similar. What is your opinion on the current icon for watchlist? Do you think it could be improved and if yes, how?
Placement: In the experiment, users don’t see the buttons for reading lists and watchlist next to each other, but instead the watchlist button is in the tools menu. Do you have any thoughts about that placement?
Have you used reading list/saved pages/playlist type features before, whether on the Wikimedia app or on other websites? If so, what types of functionality do you think could be useful for readers?
The coordinates at A3055 road were wrong, so I corrected them here, as far as it is possible to locate a road by single coordinates. When I click through from the new numeric coordinates at the top right of the article to the Google map, the location is OK. However, the pin in the "infobox" does not seem to have changed correspondingly. So where is the "infobox" getting its coordinates? I can't see where else in the article they are coming from. ITookSomePhotos (talk) 23:27, 12 November 2025 (UTC)
@ITookSomePhotos: The coordinates are pulled from Wikidata. Look for "Wikidata item" on the article. The location depends on your skin. It may be in the left pane under "In other projcets" or on a dropdown "Tools" menu at the top right. The link goes to A3055 road (Q4649116). PrimeHunter (talk) 00:41, 13 November 2025 (UTC)
I don't understand, why ClueBot does not switch to a new archive at my talk page, despite maxarchsize being exceeded. Any idea? Anyone is invited to fix it directly. Leyo16:49, 14 November 2025 (UTC)
Thank you. I changed it. BTW: There are currently 69 talk pages and user talk pages that use insource:/maxarchsize=10000[^0]/. --Leyo17:21, 14 November 2025 (UTC)
There appears to be a bug on the Minerva skin where the first click on the archives search input instead focuses the "main" search input that searches all of Wikipedia. This happens on both Chrome (Android) and Firefox (Linux)—logged in and out.
To reproduce:
Scroll down to "Noticeboard archives" and click on "Search noticeboard archives" input box
The focus should stay there but it jumps to the main search input at the top
This is extra annoying on mobile devices (smaller viewport) where the search display covers up the entire screen. Is this a known issue? — DVRTed (Talk) 12:50, 16 November 2025 (UTC)
@Vastmajority20025 When you publish in the browser, you get priority to immediately have you see the result of your edit. Then a chain of 'cache invalidations' start, which make sure that everyone else also sees the up to date version. Depending on how many other edits are happening around that time, how many templates have been modified and need to trickle down and how deep in the chain you are, this will take some time to process at all the various layers of the system. —TheDJ (talk • contribs) 11:42, 16 November 2025 (UTC)
Everything is bound by the job queue and the cache. Things are only immediate, when either your (content) options are varying on your user profile, or if you made the edit on that device (and on mobile, even the latter might not hold up. i never checked that, but it has a lot more layers in between, so i wouldn't be surprised). Note the user never said he EDITED on the app. —TheDJ (talk • contribs) 12:52, 16 November 2025 (UTC)
@TheDJ Yeah, but most of the time it’s okay. It’s not that much of an issue, but I’ve been dealing with it for the last 1–2 weeks. The issue shows up in edits I publish on the app—in articles and in my sandbox. Vastmajority20025 (talk) 13:28, 16 November 2025 (UTC)
@Vastmajority20025 To be clear: You have the app, you are logged in, and then make an edit in an article via the app. Then the app returns you to the same article to view it and it did NOT update ? Is this your problem ? —TheDJ (talk • contribs) 12:03, 17 November 2025 (UTC)
Only anonymous page views use the CDN caches which can be stale. Logged-in page views only use parser cache, which updates immediately on edits. Special pages are never cached. – SD0001 (talk) 11:24, 17 November 2025 (UTC)
But even that normally gets updated pretty much immediately unless you're talking about pages that transclude the one you've edited, no? Nardog (talk) 14:50, 17 November 2025 (UTC)
Expanding all username section
Hi. I don't know is this a right place for asking about it. Why all the username section is expanded/opened in this page? Can you please guide me in solving it? Note: I didn't enable expand all sections in my settings. Fade258 (talk) 13:15, 17 November 2025 (UTC)
@Fade258: Collapsible sections is a feature of the mobile version. It's disabled on pages with more than 1000 images. All the checkmarks are images. There are currently 1147 images. PrimeHunter (talk) 13:25, 17 November 2025 (UTC)
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 Reader Experience team is experimenting with reading lists on mobile web, allowing logged-in readers with no edits to save private lists of articles for later. The experiment is running on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias since the week of 10 November, and will begin on English Wikipedia the week of 17 November.
Users who can’t receive their email verification code during login can now get help by submitting a form on a new special page. This update is part of the Account Security initiative. If your account has an email address, please make sure you still have access to it. When logging in from a new device or location without 2FA, you may be asked to enter a 6-digit code sent by email to finish logging in. Learn more.
As part of the Parser Unification project, the Content Transform Team rolled out Parsoid as the default parser to many low-traffic Wikipedias and is preparing the next step to high traffic ones. This message is an invitation for you to opt-in to Parsoid, as described in the Extension:ParserMigration documentation, and identify any issues you might encounter with your own workflow using bots, gadgets, or user scripts. Please, let us know through the "Report Visual Bug" link in the Tools sidebar or create a phab ticket and tag the Content Transform Team in Phabricator.
Unsupported Tools: Several issues with Video2Commons have been fixed, including filename-related upload failures, black-video imports, and retry handling. AV1 support has also been added. Ongoing work focuses on backend stability, ffmpeg errors, subtitle imports, metadata handling, and playlist uploads. To track specific tasks, check the Phabricator board.
Save the date for the next Wikimedia Hackathon happening in Milan, Italy from May 1–3, 2026. Registration will open in January 2026. Scholarship applications are currently open, and will close on November 28, 2025. If you have any questions, please email hackathon@wikimedia.org.
Someone WP:THANKed me today for this RevDel, on en-wiki of course. The email notification I got for this was partly in Japanese: "Extraordinary Writ がページ「Yakama Legends Casino」の3件の版の閲覧レベルを変更しました: 内容の不可視化". Is this a known problem? It sounds like the system is using the thanking user's Special:Preferences language rather than the recipient's. Extraordinary Writ (talk) 16:15, 17 November 2025 (UTC)
I think that's a different bug. That one is only about the watchlist emails, and the complaint is that they are always in the site language. But this complaint is about a thanks notification email, and how it is partially in one user's language and partially in the other's. I can reproduce this, and I filed a separate one with more details: T410339. Matma Rextalk23:48, 17 November 2025 (UTC)
Authorship percentages no longer showing up in navbox page history
Percentage of navbox authorship has been a longtime feature of page histories, but disappeared about a week ago. Can we get this back please? Thanks. Randy Kryn (talk) 16:01, 17 November 2025 (UTC)
@Randy Kryn I'm not aware of authorship percentages being available anywhere other than at xtools (which you can get to by clicking "Page statistics" from the page history). Was this a mobile app thing or some custom script you were running? --Ahecht (TALK PAGE)19:49, 17 November 2025 (UTC)
This is generally good CSS for things that have a background color since that's the main use of the property in inline wikitext, but bad when someone does something with another background property that isn't a color, which this template does. That wikitext in this case is emitted at vi:Mô đun:Vertical header#L-34.
The best way to fix it is probably just to update to the latest version from English Wikipedia, which employs TemplateStyles instead which gets around this issue. Izno (talk) 00:32, 18 November 2025 (UTC)
Using the template preview function appears to show the text appropriately vertical in the version of the module that is from enwiki. You may have been seeing the cache or something. Izno (talk) 01:33, 18 November 2025 (UTC)
Ironically I'm asking about something in the FAQ above, but hear me out. We have a self-reference hatnote at search telling people to go to special:search. Would there be a way to embed one of those javascript scripts in that specific hatnote to be able to append "or [use the search box]" there, with the link just switching their cursor focus to the search box? (In the population of users who somehow manage to land at the "search" page while looking for the internal search, I'm guessing this might be helpful.) --Joy (talk) 15:33, 15 November 2025 (UTC)
I'm not entirely sure i get exactly what you mean... do you want to place a link after "Go to special:search" that would activate the skin's search field ? —TheDJ (talk • contribs) 11:45, 16 November 2025 (UTC)
@Joy The problem is that any custom functionality for a single page is pretty expensive. It always requires something to be added to ALL pages. Either as just the script to implement that functionality or as a custom module for which the name needs to be known to all pages. So generally we don't do that. Of course many things are possible but are we solving an actual problem or a theoretical problem ? —TheDJ (talk • contribs) 13:20, 18 November 2025 (UTC)
Template-generated category assistance
The most recent run of Special:WantedCategories featured a redlinked Category:Taxon listed on CITES Appendix II that was being autogenerated and transcluded by the {{Population taxobox}} template on Scottish wildcat. I can't find any other "Taxon listed on X" categories at all (nothing exists at the plural "taxons" either), so I suspect this is most likely a misgeneration of a category that's supposed to exist at a completely different naming format, or possibly even a straight-up error that isn't supposed to exist at all under any naming format — but the template itself doesn't actually contain any code that would generate that category organically, and is instead calling out other modules that are smuggling the category in.
But that meant that I don't know how to find and fix where that category is coming from, and had no choice but to create it as a hidden category to get it out of the reds — and even worse, with no clues as to what parent category to file that category under due to the lack of any locatable siblings, I had to create it as an uncategorized hidden category.
So could somebody with more knowledge of this stuff find where the category is coming from, and either fix the naming format if it's being named incorrectly or just make it go away if it's not supposed to exist at all? Thanks. Bearcat (talk) 15:08, 15 November 2025 (UTC)
Yes, it uses the colour to determine the kingdom. This is determined from the taxonomy template hierarchy and using the colour for the conservation status avoids traversing the taxonomy template hierarchy more than once. I'd overlooked some of the front end taxonomy templates which weren't passing colour correctly. It should all be fine now. — Jts1882 | talk16:01, 18 November 2025 (UTC)
Well, regardless of what the expected plural form is, why's the template even passing through a singular instead of plural form here in the first place? But also, there's still no category for Category:Taxa listed on CITES Appendix II, so this still isn't a thing that should be getting passed through at that form either. Bearcat (talk) 16:22, 15 November 2025 (UTC)
I'm assuming this is your own personal css, that you want applied to you on all projects? That would go to meta:Special:MyPage/global.css (where the mention PrimeHunter above sent you). Be warry, this will go to all projects, so you should then remove duplicate entries on local css projects. Also, you may have unexpected behavior on projects types you don't usually use (such as wikisources) that use other kinds of customization. — xaosfluxTalk19:24, 18 November 2025 (UTC)
When I paste a ct alert on an editor's talk page it adds several nowiki templates which I have to delete
@Doug Weller: The "New topic" tag in the diffs (a good example of why to ALWAYS link an example) shows you have "Enable quick topic adding" selected at Special:Preferences#mw-prefsection-editing and used the new topic tool. If you paste template source code in the tool then first select "Source" at the top right of the box, not "Visual". PrimeHunter (talk) 20:10, 18 November 2025 (UTC)
I uploaded a new version of this fair-use file to match Moderna Tider - Album by Gyllene Tider | Spotify but the image looks exactly the same on description page. However, I previewed it on another page and in preview it shows the new image. On the article, it also shows the new image. I tried purging the description page but it didn't do anything. Is this a normal delay or is something not working? Myrealnamm (💬Let's talk · 📜My work) 00:31, 19 November 2025 (UTC)
I have created a draft template, as User:Pigsonthewing/sandbox4, that will render {{User:Pigsonthewing/sandbox4|ca|Viquipèdia}}, for example, as User:Pigsonthewing/sandbox4, including {{Lang}} to mark up the language of the displayed text.
@Pigsonthewing That's because the parameter format should be {{ill|Viquipèdia|ca}}, which renders as Viquipèdia [ca]. The formatting is different, but that's because the intent is that in mainspace we should always be linking to a local article wherever possible. --Ahecht (TALK PAGE)19:46, 17 November 2025 (UTC)
The template's documentation, such as it is, does not say anything about namespace limitations. If not for mainspace use, you might want to emit an error message when the template does get used in mainspace:
{{#ifeq:{{NAMESPACENUMBER}}|0|{{error|<error message>}}|<make interwiki link here>}}
I have been struggling to understand how one creates a link to a specific paragraph or block of text within a Talk page thread (e.g., this is what I'm trying to do: "blunt-force objectivity is the defining feature of TIMEOUT"). I'm well versed at using {{oldid}} to accomplish something similar, but the above example is clearer, more direct, and a much more elegant solution for what I'm trying to do. I can't figure out how the specific #c-AirshipJungleman29-20251117224500-Cl3phact0-20251117215400 part is derived/generated. Any hints or steers welcome. Cheers, Cl3phact0 (talk) 16:49, 20 November 2025 (UTC)
That's linking to a specific reply on a talk page, rather than a completely arbitrary block-of-text. You can pick up the link from the timestamp on a comment -- either copy its link or just click on it and it'll be copied to your clipboard for you.
Technically you could also investigate the generated HTML on the page and find the span with a data-mw-comment-start for that reply and grab its id attribute, but that's overkill unless you're doing this in some sort of automated fashion. DLynch (WMF) (talk) 17:18, 20 November 2025 (UTC)
What I am specifically trying to achieve is exactly what was done in the example above (i.e., easily direct the reader to a specific comment within a thread so that they can read context without distractions or having to search through other passages). I think I understand now. The 20251117 part is obviously the date, but I hadn't connected the dots that 224500 and 215400 was just a timestamp interval. This should work. Thanks! -- Cl3phact0 (talk) 17:40, 20 November 2025 (UTC)
Note if you click on the timestamp of the post to get the link, you don't have to know about any of the details regarding what the numbers mean. Before the timestamp link feature was enabled, I wrote my own script to copy the appropriate link (see User:Isaacl/script/copy-comment-link-to-clipboard). I changed it so now it generates a link with a "Special:GoToComment/" prefix. If the comment was moved to another page, as is done when a discussion thread is archived, the usual link you get from the timestamp will bring to the original page and display a popup showing to where the comment was moved. With the Special:GoToComment prefix, you'll be taken directly to the current location of the comment. (My script also copies links for headings, and you can choose if you want it in the format used by table of contents listings, or the permalink format.) isaacl (talk) 17:55, 20 November 2025 (UTC)
Unable to log in due to request for verification code via email
Hello - I was sent here by someone on the wikipedia help channel on IRC to try to get help -
My account (User:Alohawolf) seems to be stuck in a login loop that I cant seem to break out of my account is alohawolf - I've been an active editor since 2005, however I cant seem to login, it redirects me to verify my account, and its either sending that to an email I no longer have access to, or the email never comes.
To be clear, if I log in with an intentional bad password, I do get a bad password message - so I know the password is correct, I've also never enabled any kind of 2fa/mfa on my account. ~2025-34613-54 (talk) 15:21, 20 November 2025 (UTC)
Maybe a long shot and you've probably already done this, but have you checked your spam/junk folders of whatever email accounts you have access to? --DB1729talk15:33, 20 November 2025 (UTC)
A recent Reddit thread has informed me that if you type "Obama" into the search box, the Monkey article is listed among the dropdown results, even though the word Obama appears nowhere in it. Looking for a quick explanation, I asked on the Wikipedia Discord server, but to no avail. Apparently, the exact algorithm by which these dropdown results are selected is shrouded in mystery. It seems to me that vandals have found a way to artificially game this algorithm, akin to Google bombing. I am concerned that we apparently have no way to detect, understand, and revert this kind of vandalism, so I'm posting here to seek further insight. Please let me know if there is a better suited venue for this discussion. –CopperyMarrow15(talk⋅edits)06:35, 20 November 2025 (UTC)
Thank you! But what (and who) caused it in the first place? I didn't know it was even possible for a page to have a custom defaultsort without using the magic word. –CopperyMarrow15(talk⋅edits)07:09, 20 November 2025 (UTC)
When a defaultsort directive is removed, the overridden value is still stored inside the CirrusSearch metadata. See [39], where you can still see World, Hello as the defaultsort even after I removed it. I wouldn't call this a serious vulnerability, but definitely something that should be fixed. ChildrenWillListen (🐄 talk, 🫘 contribs) 07:49, 20 November 2025 (UTC)
Maybe the algorithm that chooses what search results show up is delayed, and the day banana did the vandalism just so happened to be near when the algorithm updates? Perhaps every month? No matter what happened though, that must have been quite the shock for anyone searching up Obama at that time.
@Oak lod: What happened is that if you override the defaultsort parameter and later remove the override, the CirrusSearch (Wikipedia search engine) metadata still persists the old value. In April, a vandal pasted the contents of Barack Obama into Monkey, including the defaultsort override, which got persisted even after that edit was reverted. Normally, this doesn't pose any issues, but the WMF recently enabled an experimental feature which fetches search completions based on the defaultsort value stored by CirrusSearch. To their credit, they tried to implement a failsafe function (isRelevantDefaultSort) to prevent such vandalism, but it was broken so that wasn't of much help. One of the bugs has been fixed a few hours ago and the patch will be deployed to prod next Thursday, and since I overrode the defaultsort for Monkey back to "Monkey", it no longer appears in the search results when you look up Obama. ChildrenWillListen (🐄 talk, 🫘 contribs) 16:22, 20 November 2025 (UTC)
Thanks! Guess I didn't read the message thread as well as I thought, as I got next to none of that info when I first read it.
Hi all — Peter from the Wikimedia Foundation Search team here.
Thanks to everyone who investigated and surfaced the underlying cause. Here's a concise summary from the Search side, with the full technical breakdown available in the Phabricator task.
What happened technically
In April, a vandal copied the entire Barack Obama article into Monkey, including its DEFAULTSORT.
Even after the vandalism was reverted, CirrusSearch kept the old defaultsort value in its page-level metadata. That persistence is how CirrusSearch currently works and is typically harmless.
Recently, we enabled an experimental search-completion feature that uses this metadata to improve suggestions.
A safeguard function (isRelevantDefaultSort) was supposed to prevent irrelevant or abusive defaultsort values from influencing completions — but that check wasn't working correctly.
The combination of stale metadata + broken safeguard caused Monkey to appear when searching for "Obama".
Fix status
The bug in the safeguard has been fixed and backported; it is already live in production.
As a result, stale defaultsort metadata should no longer influence search completions in this way.
The underlying issue — CirrusSearch retaining old defaultsort values after an override is removed — still exists, but without the safeguard bug, it is no longer a practical vector for this type of search result corruption. We’re tracking that separately.
On the broader concern
This wasn’t a new form of vandalism or someone “gaming” an opaque algorithm. It was an interaction between cached metadata and a newly enabled feature, amplified by a broken relevance check. The community debugging here was spot-on, and your reports helped us fix this quickly.
I know it's late in the day, but I have a watchlist backlog. If something like this happens again, the thing to do is to set an explicit {{DEFAULTSORT:Monkey}}, let that work its way through caches, and then remove it again. --Redrose64 🌹 (talk) 12:11, 21 November 2025 (UTC)
Spur webinar recording available
Spur (the company from which we source IP Proxy information used by various tools) gave a webinar yesterday. The recording is available on-line It's a little bit promotional, but I found lots of good information about how the residential proxy ecosystem works that I didn't know before, so if you do anything with blocking of IPs, it's probably worth watching. RoySmith(talk)15:35, 21 November 2025 (UTC)
Old talk page discussions left behind during multiple page moves
Hi all, the article Al-Marwani (current title at time of writing) was created in September, initially as a draft. The draft was then moved to mainspace by its creator and has been moved again over a dozen times since. Along the way, at least two different talk page discussions have been left behind with former page titles instead of following the article's moves to the most recent titles; specifically, here at the draft talk and here at one of the former titles. I'm not sure how this happened, but in any case I'm wondering if there's a way to move/restore those talk page discussions to the article's current talk page? Is there a better way to do this now other than just copy-pasting the discussions? Thanks, R Prazeres (talk) 07:30, 22 November 2025 (UTC)
@R Prazeres: Done in an administrator-only way which preserves the page history on the same talk page. There were 25 redirects to the article. I checked that only the two mentioned had other talk page content than redirects. PrimeHunter (talk) 11:31, 22 November 2025 (UTC)
I came across the Otago article at this version and noticed that the extended footnote after the first word of the lead, which addresses pronunciation and the name of the area in Maori, wasn't appearing at the bottom of the article. I noticed that there wasn't a {{notelist}} tag at the bottom, so I added one but, when I previewed the result, the list still didn't appear. Investigating, I found that there was a {{notelist}} tag at the end of the first table of the Population section, evidently meant for displaying an extended footnote for the first data row, Dunedin, so both notes were being displayed there. I tried to solve the problem by setting distinct |group= parameters for each of the {{efn}}s, and setting the corresponding |group= parameters for the {{notelist}}s. But that didn't work: the two notes still both appear under the table, and the {{notelist}} in the Notes section I created at the bottom, above the References section, is empty. I saved my work under this diff. Can someone see what's preventing the breakdown by group from occurring? Largoplazo (talk) 18:55, 21 November 2025 (UTC)
{{efn}} only recognizes the following values for |group=: note, upper-alpha, upper-roman, lower-alpha, lower-greek, and lower-roman. Anything else defaults to lower-alpha. You tried to use "main" and "pop". Anomie⚔22:55, 21 November 2025 (UTC)
Ahhhh. I hadn't grasped that the distinction had to be based on the numbering scheme. That's a little bizarre, actually, seems to me they should be independent dimensions, say, if you have 15 tables and want each to list its own set of notes at the bottom—and have them styled consistently, each starting from the beginning. But that's beside the point here. Thanks. Largoplazo (talk) 03:25, 22 November 2025 (UTC)
@Largoplazo: You can have multiple notelists, each using the same style and each with its own sequence, provided that where there are two in parallel, they use different styles. Consider this:
Text in article lead.{{efn|Note relevant to text in the lead}}==Section one==
Table row 1{{efn|group=lower-roman|Note for section one, table row 1}}
Table row 2{{efn|group=lower-roman|Note for section one, table row 2}}{{notelist|group=lower-roman}}==Section two==
Table row 1{{efn|group=lower-roman|Note for section two, table row 1}}
Table row 2{{efn|group=lower-roman|Note for section two, table row 2}}{{notelist|group=lower-roman}}==Notes=={{notelist}}
You can see a fuller version in action here. Notice how the lower-roman counter resets after each notelist, but doesn't affect the lower-alpha one. --Redrose64 🌹 (talk) 23:39, 22 November 2025 (UTC)
Now I see—in my version, both were consumed by the first notelist because everything was being treated as lower-alpha, so both footnotes got captured there. Cool, thanks! Largoplazo (talk) 01:12, 23 November 2025 (UTC)
There were a lot of recent undiscussed changes to Template:Merge, Template:Merge from and Template:Merge to, mostly by FaviFake (talk·contribs), who made insufficient prototyping in the template sandboxes, and did not use the testcases pages at all. I've reverted the template changes, and raised the protection to Template-protected. Honestly, I could have blocked FaviFake outright for breaching a final warning not to mess about in highly-visible pages without discussion. I might still do that. --Redrose64 🌹 (talk) 10:58, 23 November 2025 (UTC)
{{{case: ~ }}} would mean the value of the template parameter named case: ~. {{{case: {{{1|}}}}}} would mean the value of a template parameter whose name is based on the value of parameter 1.That very old template was intended to be used something like {{switch| value | case: a = something | case: b = something else | case: c = etc | default = a default value }}, and the {{{case: {{{1|}}}|{{{default|}}}}}} handled selecting the appropriate named parameter based on the passed in value. These days we have mw:Extension:ParserFunctions that lets the same thing be done more efficiently (and with slightly different syntax) using #switch. Anomie⚔16:08, 23 November 2025 (UTC)
Minerva not showing edit count and user groups for certain users (?)
I didn't know this mobile feature which was poorly described. Compare Special:Diff/1323787535 by Izno and Special:Diff/1323780893 by Theknoledgeableperson in the mobile version in a narrow window. The bottom of the Izno diff has an up-arrow which displays "148,425 edits | 3 user groups" and a circled "i" icon to show the groups. The Theknoledgeableperson doesn't show any of this. Tests with other users show that you only get the info if the user has at least one user group (which may be extended confirmed). It makes some sense to not write "0 user groups". I don't know why the edit count is omitted in that case but it may be deliberate. PrimeHunter (talk) 20:38, 23 November 2025 (UTC)
@Timrollpickering It looks like it was that recent edit, you just needed to wait a bit for the category to clear (there was a recent Tech News item about some backend changes that result in delayed category updates). {{User x}} checks if the category exists before placing the template there, so if Category:User en-gb-3 were deleted it wouldn't be a problem. That being said, the real solution would be to not have different capitalization between the template and the category, and I would suggest doing a mass-move on the en- templates to capitalize them. --Ahecht (TALK PAGE)14:15, 20 November 2025 (UTC)
Unfortunately it's still there; I don't know if this is because of another user making a needless edit about whitespace. These language categories are a total pain in the backside with a lot of inconsistency (only en-GB and en-CA seem to be capitalised) and some off site stuff that isn't maintained well. Is there a simple way to zap the problems once and for all? Timrollpickering (talk) 22:00, 20 November 2025 (UTC)
{{MusicBrainz meta}} (should that really be used in the article? – meta templates generally aren't suitable for mainspace) doesn't support |ref=. You might rewrite that reference as:
{{wikicite|ref={{SfnRef|Master Cutting Room}}|reference={{MusicBrainz meta|type=place |mbid=f97bd920-fe68-440f-b515-e078e7894f97 |name=Master Cutting Room}} at [[MusicBrainz]].}}
or convert {{MusicBrainz meta}} to a {{cite web}} template ...
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
Last week, the Wikimedia Search Team recreated the "DWIM" (Do What I Mean) gadget functionality server-side, for Russian and Hebrew Wikipedias. This feature adds cross-keyboard suggestions to the standard search-box suggestions. For example, searching for cxfcnmt on Russian Wikipedia will now add suggestions for счастье ("happiness") that the user probably intended. They plan to enable this feature for other Russian and Hebrew wikis this week. [40]
Later this week, users of the "⧼codemirror-beta-feature-title⧽" beta feature will have syntax highlighting available in DiscussionTools. This requires that the "Enable editing tools in source mode" preference be set. [41]
Campaign events extension – the set of tools for coordinating events and other on-wiki collaborations has now been deployed to all Wikimedia wikis. A new feature known as Collaborative contribution to help organizers and participants see the impact of activities has also been added. Join the upcoming learning session to see the new feature in action and share your feedback.
View all 24 community-submitted tasks that were resolved last week. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [42]
Updates for technical contributors
Users of Wikimedia API can join a usability study to help validate the new design of Wikimedia REST API sandboxes. Interested participants should fill the recruitment survey. [43]
The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for format=xml&xlst={stylesheet} will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). [44]
The WDQS legacy endpoint (query-legacy-full.wikidata.org) will be decommissioned at the end of December 2025, and finally closed down on 7th January 2026. After this date, users should expect requests to query.wikidata.org that require the full graph to fail or return invalid results if they are not rewritten to use SPARQL federation. The team encourages users to ensure that tools and workflows use the supported WDQS endpoints (https://query.wikidata.org/ - Main graph or https://query-scholarly.wikidata.org/ - Scholarly graph). For support with migrating use cases, please review the Data Access and Request a Query pages for details and assistance on alternative access methods.
I’m Eliza Blackorby from the WMF’s Reader Growth team. A few weeks ago, WMF posted here about declining pageviews to Wikipedia – that’s what our team is working to address. We want both new and existing readers to return to Wikipedia because they find it a compelling place to learn. Over and over, a top request from readers is that they wish for “more images/photos” on Wikipedia, as demonstrated in surveys of global internet users. As a result, we want to show readers more images and display images in a more enriching way. Our hypothesis is that by making it easier to explore images already in articles, readers may find Wikipedia more engaging and return more frequently, with some of them eventually becoming editors.
What idea are we testing?
A few weeks ago we shared how we were considering a test of a sliding gallery view of all an article’s images at the top of the article that readers can then click to jump to that part of an article, inspired by Community Wishlist requests for improved discovery of media. We’ve since built a prototype, called Image browsing, that takes your feedback into account. You can try it by adding the url parameter ?imageBrowsing=1 to the end of any URL on the mobile view for enwiki. For example: https://en.wikipedia.org/wiki/Hummingbird?useskin=minerva&useformat=mobile&imageBrowsing=1
What stage is this project in?
Our initial discussions with you constituted phase 0 of our reader experiment phases. We now want to enter phase 1: launching a small test with an early version of these ideas. It’s not yet clear whether this feature will be an improvement for readers, so we want to test it to determine whether to proceed into Phase 2: building a feature.
What is the timeline?
We will A/B test this version with 0.05% of mobile readers on English Wikipedia starting the week of November 17 and ending four weeks later on December 17.
What does the experiment include?
This test will include a gallery at the top of an article that shows all the article’s images. The feature will be available for any article that has three or more images. Tapping on any image will open a browsing experience with the image enlarged, its caption, and options to view it on Commons (if available). Readers will see images and paragraph-excerpts from the article itself in the gallery and will be able to switch back to where the image appears within the article. At the bottom of this experience, readers will be able to view images selected by editors for the same article in other Wikipedias.
Screenshots:
Below are three separate screenshots of the test's different aspects to demonstrate the experience when a user clicks through and scrolls.
What input are we looking for from you?
While this round of the experiment is focused on simply testing if readers are interested in image browsing, there are still issues that would need to be resolved before developing this into a feature, including those around bad images and cross-wiki images as it relates to conflicting policies or cultural sensitivities. We invite you to help us continue to identify concerns like this. In the collapsed box you'll find a summary of the feedback and risks we heard from you in September, along with how we're thinking through them.
Feedback from Phase 0
Mixed feelings on showing images from other projects
Commons: Some editors liked the idea of pulling more images from Commons, while others felt there was too much risk to showing Commons images without editor oversight. For this test, we have decided to only use images that have been added to at least one Wikipedia.
Images from other wikis: Some editors felt that allowing readers to click to see images from other wikis for the same article could pose a risk to editor oversight. For the purposes of gathering information in this test, we are including the ability to view images from other wikis, and will carefully observe and share the results with you for future conversations.
Risk of showing inappropriate images
We’ve set up this first A/B test so that you can exclude page images by adding the tag for exclusion, but we agree there’s still some risk. If we decide to proceed with this idea after the test, we’ll review ways we can expand this list to include further editorial oversight.
Risk of showing irrelevant images
Here, we’ll be using the same classes as MediaViewer. Instructions on how to add these classes are available on this page. Images already excluded from Media Viewer will not appear in the experience.
We agree this is a risk when displaying images from across wikis since not all wikis have the same level of moderation. We’ll be reviewing this piece with our legal team and current policy to make sure everything is aligned.
The guidelines in the Manual of Style for images focus on how images are presented within article content. Since this experience is more like a navigation or browsing experience outside the main content space, similar to how images appear in Media Viewer, we’re not sure how or whether to apply the MOS here, so let’s keep talking about that.
Since this work is still experimental, we expect to refine and adjust this idea based on your feedback. We’d love for you to try the feature on a few articles using the url parameter above. Your input will help us decide how to improve it if we move forward after the test. Also, stay tuned for the test results. We’ll share them with you and discuss together whether it makes sense to continue with this idea into Phase 2, and if so, what additional changes we will need to make before proceeding. Please share your thoughts and questions here, and for more info, see our project page.
When I go to the hummingbird page and click on the article image that has the caption "Adult male bee hummingbird, Cuba", I am taken to a page that contains the image, along with credit and a link to the license information. It is my understanding that CC licenses require that information to be linked to and displayed when the image is clicked. When I click on the same image in the slide show, I do not see any licensing information. This may be a problem.
The other obvious issue, of course, is that the images are displayed without their captions until you click them individually. As User:DarthVader might have said, I find your lack of context disturbing. – Jonesey95 (talk) 01:21, 7 November 2025 (UTC)
Hi @Jonesey95, thanks so much for flagging. You raise some important points. We've taken them into conversation with colleagues in the Legal department, and agree that we would need to address them if we end up building a future feature out of this experiment. I'll follow up more here if/when that happens. EBlackorby-WMF (talk) 22:31, 7 November 2025 (UTC)
Is it really OK with the legal department to knowingly violate the terms of CC-BY-SA, even on an experimental basis? I'm not a lawyer, so I don't know if it really is a violation, but it doesn't seem like something that would normally be allowed here at en.WP. If someone tried to roll out a template that behaved in this way, I think it might get some license-related pushback. – Jonesey95 (talk) 00:15, 8 November 2025 (UTC)
@Jonesey95 I disagree that there is any semblance of a violation here. There is a prominently displayed link to commons off to the side, which imo counts as attribution. I also disagree that if a editor made a similar choice, they would get any license related pushback. The practice of using images as background and then overlaying attribtuion text is pretty common across userpages (a example of this would be Sigma's userpage) Sohom (talk) 13:30, 11 November 2025 (UTC)
The Creative Commons licences do not require a specific method for providing attribution. The licence states that it may be reasonable to meet the attribution requirement by providing a link to a page that has all the required information. Since clicking on a gallery image displays an expanded image with an overlaid link to the attribution information, personally I feel this is a reasonable approach to provide attribution. isaacl (talk) 06:02, 8 November 2025 (UTC)
I find the workflow to jump to the section where the image is located to be awkward. After swiping through the gallery at the top of the article, I select an image, and see an expanded image at the top of the page, but there's no link to the section. I have to scroll down through the list of images (with the little summaries) until I reach the image I originally selected, and then I can select "View in article". I think it would be better if the little summary and "View in article" link appeared directly below the expanded image, so the context and jump link would be immediately available. (I think it should still appear within the comprehensive list as well.) isaacl (talk) 06:11, 8 November 2025 (UTC)
Hi @Isaacl, thanks for this feedback! It's helpful to hear your thoughts and ideas around page navigation. We're still figuring out the best way for anchor links to behave on the page in a way that more seamlessly connects images with context via their summary and their place in the article. Our design team will take a closer look with this in mind. Do you think the summary and "view in article" link would work best overlaid on top of the expanded image, underneath where the caption currently is? Or do you have something different in mind? EBlackorby-WMF (talk) 20:48, 13 November 2025 (UTC)
Due to the length of the blurb (I guess it's an excerpt, not a summary), I think it would be better to appear below the image, as I suggested. From a UI perspective, since the "view in article" link will bring you to the text in the excerpt, I think it would be better for the link to appear floated to the right at the top of the excerpt. I suggest leaving a bit of extra space at the bottom so the top of the excerpt and the link is visible without scrolling. I think it is better for the text to appear distinct from the caption, so prefer the text not to appear as though it is floating over the image. isaacl (talk) 22:43, 13 November 2025 (UTC)
I think the general idea here is good. If we can increase the visibility of media in a way that enhances the usefulness of Wikipedia to readers, then I'm all for it. The current implementation also seems to be decent, although some kinks may have to be worked out as pointed out above.
Even if directly pulling images from Commons is ruled out, what about simply providing a link to the Commons category? We already have {{Commonscat}}, so I don't see how this would be controversial. The link could look something like this:
Hi @~2025-32228-23, thanks for the note, glad you like the idea so far. Potential connections with Commons is something we are thinking about a lot, and this idea you've posed is a good one for future investigation. How do you feel about offering a link to view media from other projects besides Commons (like other language wikis)? EBlackorby-WMF (talk) 21:01, 13 November 2025 (UTC)
@EBlackorby-WMF: I think the way this feature currently works in the demo is mostly reasonable.If editors on another language edition have decided to include a photo, then it is probably at least somewhat illustrative and useful. On the other hand, Commons categories sometimes include low-quality / low-relevance media, which makes including photos from Commons more problematic.
I do see some risk of cross-wiki vandalism. For example, if a troll wants to deface a protected English Wikipedia article on a popular or contentious topic, then they could instead add an inappropriate image to the equivalent article on a different language edition that has barely any eyes on it (e.g., Udmurt Wikipedia). It might take a while for editors to catch this kind of thing.
what about simply providing a link to the Commons category?Support. I think there should be some load more button on the right of the images panel to load more images from the Commons category (e.g. first files that in a deepcategory: scan of the category have most uses in mainspaces) and/or a button there to go to the category. The best may be to have both but usually subcategorization of the Commons category is important where one can't just show random files only directly in the category and when using subcategories too some less-related or less-useful files may show up and it would be difficult to sort them. Thus, ideally the user navigates to the category page by opening it in a new tab or via some integrated Commons category browser that could be added into the Image browsing panel.
Moreover, I like that proposed button design – however not for the Image browsing panel but what would best be added to the See also section (not buried underneath the long References section) and labeled "More media on Wikimedia Commons". Most Wikipedia users aren't really aware of Commons and don't see the Commons category link at the bottom. It needs a modern and well visible button like this and I'm sure readers would find it useful. Prototyperspective (talk) 00:03, 24 November 2025 (UTC)
Just a quick thing, but I think it would be better if the gallery layout was closer to the one used on Commons for category slideshows. It would provide more context to users. Also, on my mobile device (tablet, using a Chromium browser), the photos were ever so slightly cut off on the sides and I think that having margins/a border like in slideshows would help prevent this. postleft on mobile!19:07, 24 November 2025 (UTC)
FAQs at the top of pages don't show as FAQs when viewed on mobile
On the BLP noticeboard, people are sometimes directed to the FAQs at the top of talk pages. However, on mobile view, this is all hidden behind a non-obvious sign saying "more about this page". Is there anyway of making that clearer? Red Fiona (talk) 21:46, 23 November 2025 (UTC)
Is there a tool that scans new talk message for keywords?
The problem I have is the decentralised nature of technical help questions in Wikimedia. For example, if a user has a problem with inserting OpenStreetMap (OSM) data into an article they might post on the article's talk page, the Help desk, a related WikiProject, the graphics lab, mediawiki, meta or Commons.
Is there a tool that scans talk page comments for keywords, to connect helpers with questions? To reduce the amount of work it needs perform it could work on a defined list (like "OSM", "OpenStreetMap", etc), only scan once per day, limit to lingua franca English wikis and only look at new section creations. Would this sort of thing be feasible on Toolforge? The defined keyword list would need some thought, but things like "OSM", "{convert}", and "copyright" are some of the things I would look out for. Commander Keane (talk) 07:39, 25 November 2025 (UTC)
How to get a specific property of an wikidata object, in Lua.
Hello everyone, i am trying to modernise the imdb name module of a version of wikipedia in an other language (that supports lua), to use lua, and i cannot understand how can i get the property P345 of a an actor wikidata object. What do i have to do, do i need to get the wikidata object of the wikipedia page and using mw.wikibase.getEntity(), to get all the properties of the person/object and then from the extracted wikibase entity somehow query the P345 property.
Note: I have also noticed when i try to run functions on the entity object that got returned, by assigning the wikibase.getEntity() result to a local "a" variable and then executing a.getEntity(l it fails, with an error along the lines of "You cannot run operations on a local variable defined wikibase entity".
Over on ang:, the Main Page has an issue: it has daily features like en:, using {{CURRENTDAY}} {{CURRENTMONTHNAME}}, but does not tick over to the next day: it can be stuck on one date for ages. It updates if we amend the page, or actively purge the cache: the main page is called 'Heafodtramet', so the clicking a 'Special:Purge/Heafodtramet' brings it to the current date. I did that again this evening.
Is there another way to write it so that {{CURRENTDAY}} etc reflects the current date without intervention?
The NewPP limit report in the HTML of the main page at ang: says "Cache expiry: 2592000". That's in seconds and equals 30 days which is indeed far too much for a main page using {{CURRENTDAY}}. phab:T119366#6407916 by Krinkle in 2020 sounds like it should have been set to an hour. I don't know whether that still applies and I don't know a way to control it. PrimeHunter (talk) 21:01, 20 November 2025 (UTC)
Thanks for the ping. I recall in the past Parsoid did not yet support reduced cache expiries (e.g. T329067), but that was fixed two years ago and these days Parsoid is enabled by default on several Wikivoyage and Wiktionary wikis. Searching on Phabricator, I don't see any known issues that would explain this. Ping @Cscott. Krinkle (talk) 15:37, 21 November 2025 (UTC)
Hi all, yes, this is a bug in Parsoid we discovered recently. The same issue as tracked in T408741 which we've been working through and looks like there is something in Parsoid's metadata collection itself we may need to address to fix this. SSastry (WMF) (talk) 15:54, 21 November 2025 (UTC)
@Hogweard it's not an ideal term solution, but I have an old script to trigger page purging which I wrote for Wikidata - I could set it up to run on the ang mainpage once a day at midnight as a stopgap, if that would help? Andrew Gray (talk) 12:47, 21 November 2025 (UTC)
@Hogweard okay, set up - it will run at one minute past midnight UK time (so 1.01 UTC in the summer, if it's still going) and purge ang:Heafodtramet. (It will also purge ang:user:AGbot which uses CURRENTTIME, so I have a test to make sure it's working - I guess we find out in half an hour.) The bot won't actually edit anything on the site. Happy to leave it running as long as is needed. Andrew Gray (talk) 23:30, 21 November 2025 (UTC)
On a Wikipedia file page like File:Example.png, where it's a file from Commons, if you click the Commons icon in the top right, it currently takes you to the Wikipedia page for that icon, File:Commons-logo.svg. It used to take you to the Commons version of the file you were looking at.
This is possibly a very recent change to a template or the backend, as I only started encountering it yesterday, presumably it being my muscle memory way of navigating to Commons from a Wikipedia file page. archive.org shows that it changed less than a month ago.
Worth changing back, if this is a simple template issue? Few users would want or expect to be taken to the logo SVG page when clicking the icon. Belbury (talk) 10:07, 26 November 2025 (UTC)
It's a change made for licensing reasons. It has been recently discussed and I'm trying to find the previous discussion. Nthep (talk) 11:22, 26 November 2025 (UTC)
The table below was taken from Hexadecimal clock and truncated by way of showing the hex triplet colors. The nine used (#0000, 0100, #0200, #0400, #0800, #1000, #8000, #F000, and #8000) are upon review, however, all zeroed out, i.e. the numerals are all zero. Get back into editing, and lo! they are all back. Most curious!
Are Page Previews on by default for new logged-in users?
mw:Page Previews § FAQ says "Is this enabled by default for logged-in users? No." Is that correct for the English Wikipedia? I'm asking because at Help talk:Link § "The tooltip does not show the page one will arrive at." some logged-in users say Page Previews were on by default for them. They're on for me, but I don't remember whether that was by default or I turned them on, and I don't know how to check. I could create a new account just to test this, but that seems a bit wasteful. :-) Ideally, an answer would point to somewhere in the MediaWiki source code, or on Phabricator, or a configuration here on enwiki, or an official announcement. That would be awesome. Thanks! — Chrisahn (talk) 04:11, 26 November 2025 (UTC)
P.S. I checked my account on a couple of other Wikimedia projects. Page Previews are off for them, and I don't think I turned them off, so it looks like the claim "Is this enabled by default for logged-in users? No." is correct for most other projects. P.P.S. I think I recall that Page Previews were enabled by default on the German Wikipedia a few years ago, but I didn't like them at first and turned them off. Maybe the claim in question is correct for most (all?) projects except enwiki and dewiki? — Chrisahn (talk) 04:18, 26 November 2025 (UTC)if
Thanks! Another question: The answer below says Page Previews is enabled by default for users registered after 16 August 2017. Was your alternative account registered before this date? Then it would make sense that reset disables Page Previews. I guess it resets the preferences to the original settings for the account, not to the settings a new account would get. Thanks a lot for your answer! — Chrisahn (talk) 15:08, 26 November 2025 (UTC)
The FAQ seems a bit out of date. The actual configuration can be found here: [45] which says:
Users registered after Popups launch on 16th August 2017 will get page previews and references previews enabled by default. Any user registered before this date will get the value defined in $wgPopupsOptInDefaultState (defaults to "0").
The per-wiki values for $wgPopupsOptInDefaultState can be found here: [46] (on for a few Wikivoyages, off elsewhere)
So to answer your question directly, Page Previews are on by default for new logged-in users (and for many "old" logged-in users too). Matma Rextalk13:34, 26 November 2025 (UTC)
I came across an article where another editor had changed various geographical wikilinks from complete wikilinks to piped wikilinks:
[[Roanoke, Virginia]] to [[Roanoke, Virginia|Roanoke]],Virginia and
[[Halifax County, Virginia]] to [[Halifax County, Virginia|Halifax County]], Virginia.
The editor cited WP:GEOLINK as the reason. I know that Geolink states "For a geographical location expressed as a consecutive comma-separated sequence of two or more territorial units, link only the first unit." but the changes just look like a lot of unnecessary piping to me... - Shearonink (talk) 03:53, 27 November 2025 (UTC)
Recently, all international sports federations have been using the names Czechia and Türkyie, instead of the official names Czech Republic and Turkey. That's quite weird. And even weirder, many Wikipedia editors use these names as an additional parameter in sports templates:
And that really annoys me. It would be nice to write an essay on this topic; how to use/not use these name parameters. Alternatively, we could start thinking about modifying the country-data templates. Maiō T. (talk) 13:35, 26 November 2025 (UTC)
If you do encounter "Türkyie", please change it to "Türkiye", as that's the correct spelling. :-) I'd not recommend changing "Türkiye" to "Turkey" though, at least not where "Türkiye" is the name recognized by the respective sport's main international organization. Before you make such changes, you should discuss them. — Chrisahn (talk) 12:08, 27 November 2025 (UTC)
Skin Change sticks
I want to change my skin to Vector legacy (2010) but I can't save it at all. All the time the skin is stuck on Vector (2022), even Monobook or other skins don't work. What is the problem? Demigorgen (talk) 09:19, 27 November 2025 (UTC)
Given your edit is tagged with "Mobile web edit", what you think is Vector 2022 might be Minerva, the mobile skin. If you see "Desktop" at the bottom of the page, click it. Nardog (talk) 09:25, 27 November 2025 (UTC)
Please describe any preferences you may have set (or not set) on the relevant tab(s; RC options can also impact WL) in Special:Preferences. Also ensure that it is(n't) an issue with ?safemode=1 appended. Izno (talk) 18:47, 27 November 2025 (UTC)
Weird shit on Vector save
Saving on Vector appears to display the previous section, with the header hidden under the top bar. It looks like someone has tried to correct the old problem where the section header was just too high to be visible, and made it worse, by displaying the wrong header, also too high to be visible. This has been going on a couple of days now. I thought they would notice that it does not work and revert, but it is still happening. It is more annoying than the original problem and something of a time waster. Cheers, · · · Peter Southwood(talk): 06:49, 27 November 2025 (UTC)
Can you reproduce this bug consistently on a sandbox page? I've been trying to reproduce it in my own sandbox but I cannot reproduce exactly what you're describing. I can only reproduce a different bug, whereby if two section-headings use identical text, and I edit from the second section-heading, then after saving it will show me the first heading (unexpectedly), but correctly located beneath the window-top (Vector) or the sticky header (Vector-2022).
P.s. Example locations/diffs almost always help a lot, in bug-reports! E.g. I tried looking at your contributions to try to identify where exactly you had encountered the bug, so that I could attempt to reproduce, and because I suspected it might be caused by collapsible templates/tables; however it doesn't seem to be from that, as I see you'd edited freediving before writing this post, and I can't see any obvious causes for scrolling-misalignment (or duplicate headings) in that article. Quiddity (WMF) (talk) 20:37, 27 November 2025 (UTC)
The edit does exactly what is supposed to do, it is the screen display that comes up on save that is offset. I can't see how I can show you the result that I get if it doesn't happen for you, but I will give it a go. The sticky header on Vector-2022 covers the section header. · · · Peter Southwood(talk): 04:17, 28 November 2025 (UTC)
I was getting the bug with every edit previous to the report that changed the content of a section without removing the whole section (I think). · · · Peter Southwood(talk): 04:21, 28 November 2025 (UTC)
No idea how long this has been going on but {{page needed}} is displaying some odd behaviour. Rather than displaying correctly it display as [, page needed], potentially effecting of tens of thousands of pages[47] -- LCU ActivelyDisinterested«@» °∆t°11:51, 29 November 2025 (UTC)
Enforce the rule. Right at the top of the {{page needed}} template doc is a message box that tells editors that they should not use {{page needed}} in citation templates. This because {{page needed}} creates this mix of html and wiki markup:
<supclass="noprint Inline-Template "style="white-space:nowrap;">[<i>[[Wikipedia:Citing sources|<spantitle="This citation requires a reference to the specific page or range of pages in which the material appears.">page needed</span>]]</i>]</sup>
Nothing in that mess is a page number or a range of page numbers. Don't corrupt the citation's metadata.
@Trappist the monk: Thanks. The report linked a search with 31,320 results but it doesn't have quotation marks and search ignores special characters so it's the same search as 91 page needed 93 which finds all articles with those words and numbers anywhere. "91 page needed 93" with quotation marks only gives 48 results which could easily be fixed manually. Any volunteer? PrimeHunter (talk) 15:52, 29 November 2025 (UTC)
Providing the ability of modifying "Edit summary" for its publisher after publishing Wikipedia edits
Hi, after publishing an edit, its "Edit summary" text is locked and is not modifiable, even for the publisher. This is not good, because publisher may have some typo or forgot some text ideas. I propose to correct the scenario so that only the publisher of an edit would have the ability of modifying an edit's "Edit summary" after publishing that. For example, in this history of article Tehran which is this page, edit summaries are not modifiable. Thanks, Hooman Mallahzadeh (talk) 11:53, 28 November 2025 (UTC)
@Chipmunkdavis Hi and thanks for your comment. I think this ability improves the "quality of an edit" significantly. A good "Edit summary" is one of the main aspects of an edit (in addition to time, editor name, byte size difference). In addition, I propose that ordinary editors have the ability of modifying "edit summaries" so that if the edit publisher is novice, other editors provide a good summary for that edit. Maybe such edit summary modifications should be logged into a database with a unique id to avoid related confusions. Even though it "has never gained support" I really propose to implement that. Thanks again. Hooman Mallahzadeh (talk) 14:25, 28 November 2025 (UTC)
but then we have a history of a history, and you you would have to explain the change you mad in another edit summary.. in which you can make a mistake that you need to correct again. —TheDJ (talk • contribs) 14:28, 28 November 2025 (UTC)
No! In fact, "Edit Summary Modifications" data should be kept in another Table, named "Edit Metadata Modification Table" and each "Edit Table" item should have a pointer which points to "Edit Metadata Modification Table". Then, modifications to edit summary are logged in that "Edit Metadata Modification Table". Hooman Mallahzadeh (talk) 14:34, 28 November 2025 (UTC)
I also propose a dropdown list for "classification of edit", including items such as "Infobox correction", "Reference correction", "Lead sentence", etc. Hooman Mallahzadeh (talk) 14:35, 28 November 2025 (UTC)
@Hooman Mallahzadeh: If edit summary modifications were to be implemented (which it probably won't, per below) it could lead to amendment after amendment, potentially without limit. We presently permit this with normal page editing, but it can get out of hand, such as with these two replies and their thirteen amendments. For this reason, we provide a WP:PREVIEW feature, which previews both the text and its edit summary. As for the dropdown list idea, we already have this, it's at Preferences → Gadgets as "Add two new dropdown boxes below the edit summary box with some useful default summaries". --Redrose64 🌹 (talk) 11:11, 30 November 2025 (UTC)
@Redrose64 OK. We can lock "Edit Summary", but we can provide a new item named "Edit category" which is editable after publishing. Then "edit page" provides an HTML check element for determining possibly multiple categories of an edit. Because I think "Edit category" is very helpful both for humans and non-human users (e.g. robots and data-analyzers) which review edits. Hooman Mallahzadeh (talk) 13:36, 30 November 2025 (UTC)
I am working on getting 1st Maine Cavalry Regiment out of Category:Harv and Sfn no-target errors and have run into a problem with cite books. As I have been going editing the article I am getting new error messages of "Script warning: One or more {{cite book}} templates have errors; messages may be hidden (help).", one more every time I have fixed a harv cite issue. I apparently do not have a script installed to see what these issues are. Can someone look in on the article and tell me the error? And maybe also what I need to install so I can see the cite book errors as well? Thanks, Shearonink (talk) 18:28, 29 November 2025 (UTC)
You don't need a script. cs1|2 error messages are visible to everyone unless you have explicitly set your css to hide them (you haven't; at least not in your common.css). The easiest way to find those sorts of errors is to use your browser's find function (ctrl+f in windows) to look to the string (help.
I want to translate and create articles from Persian (Persian Wikipedia) to English. How do I activate the toen wiki tool? What are the article translation tools and how do I activate them? AndisheyAzad (talk) 23:12, 27 November 2025 (UTC)
You have hidden the two sidebars that can end up in that space. One of them is the goggles at the top right. One of them is the tools dropdown below the languages dropdown. Izno (talk) 21:46, 29 November 2025 (UTC)
No, it is by design. Reporting it will simply cause it to be closed immediately. You have been provided the two supported ways to deal with the layout of the page. Izno (talk) 22:02, 29 November 2025 (UTC)
Yes, and part of their objection was fixed by providing the goggle dropdown. (I don't know if it solved all of their objection.) Izno (talk) 22:33, 29 November 2025 (UTC)
.mw-userlink now applied to non-interface parts (edit summaries)
The mw-userlink class is now applied to links to user in edit summaries and the like, making it impossible for gadgets and scripts to rely on the class being only in core interface parts. This potentially affects dozens of scripts. Nardog (talk) 14:41, 27 November 2025 (UTC)
They apparently wanted to be able to grey-background links to temporary accounts wherever those might appear, and usurped the "mw-userlink" class to do so. It may be worth filing a Phabricator task requesting they bring back a way to find the performing user in a watchlist or Special:RecentChanges row now that mw-userlink can also be applied to the page affected, the diff and history links, and links inside the edit summary. Anomie⚔15:09, 27 November 2025 (UTC)
Hello! I'm sorry to have caused this issue... Extending the set of cases where mw-userlinks is applied definitely wasn't planned nor needed for the task I was working on (which is adding gray backgrounds to selected temp. user links in content area). For that, we had to change the code that's responsible for adding the user-related classes to the links, and alas, we didn't catch the unwanted change to the scope of mw-userlinks.
The patch to fix the behavior has already been prepared and waits for CI and review. Given that this issue probably isn't a reason for emergency backport (which is the only kind of deployment allowed on Fridays), I expect the fix can be deployed to production on Monday morning.
Again, I'm sorry that this happened. As a person, who's part of the wiki communities, I feel how it is when gadgets break and require fixing. Unfortunately, this time, I'm at the more bitter side of things and I can't help immediately. I'll ensure, though, that the fix lands on production as soon as possible (which is unlikely to be today). MSzwarc-WMF (talk) 08:35, 28 November 2025 (UTC)
Well, don't be so hard on yourself. In fact I'm pleasantly surprised you're reverting it—most of the time devs are like "tough luck" when this kind of thing happens. Nardog (talk) 13:15, 28 November 2025 (UTC)
The fix is deployed now. It's possible that some pages still have these extra mw-userlink classes added, but forcing reload (or ?action=purge) should resolve that. MSzwarc-WMF (talk) 08:35, 1 December 2025 (UTC)
It seems to have been resolved. Thank you. I hope this incident wasn't too stressful for you; accidents happen. — DVRTed (Talk) 08:48, 1 December 2025 (UTC)
No, it wasn't that stressful (in fact, probably less that my original message implies). I primarily wanted to communicate what were the cause and expectations from the WMF side around the issue, so that the community didn't need to panick over the weekend :) MSzwarc-WMF (talk) 12:50, 1 December 2025 (UTC)
Why are my span.mw-usertoollinks modifier user scripts all messed up suddenly?
Basically, they modify the user tool links "(talk | contribs | block)" next to each user listed on the specific special page or area, and add more links to them to make performing actions much quicker.
Since the end of yesterday, suddenly, they're all completely messing up! They're now adding links to the wrong account or user from someone further up the list, and the scripts are now starting to set the "current_user" to "contribs" instead of the username of the current user to add user look links next to.
I'm stumped! I did make some code improvements to some of the scripts, but all four of them are having problems despite me only updating three of them. Rolling back all of my changes and clearing browser cache, the whole works, made no difference. What's going on? Can someone look at these scripts and maybe tell me if something has changed? They were all working perfectly fine up until when the user cards feature was deployed.
PLEASE HELP! I'd be forever in your debt and eternally grateful for any help, input, or guidance.... :-) (Please ping me in your responses, as I'm currently working on cleaning out my watchlist for being way too full...) ~Oshwah~(talk)(contribs)17:06, 27 November 2025 (UTC)
DVRTed - Oh, trust me... I'm absolutely not saying that the script I wrote is the best thing in the world code-wise. I happened to see the discussion made right above mine, and it looks like others have already beat me to it with their observations as well. Okay, cool! I'm just really happy to know that it wasn't me that overlooked something and caused these scripts scripts to mess up. My thanks to Izno for nesting my cry for help under the discussion located above this one, and my sincere thanks to you, DVRTed, for taking the time to look through my really shitty JS code... :-) ~Oshwah~(talk)(contribs)19:25, 27 November 2025 (UTC)
DVRTed - Thank you so much! Ugh... I was educated in C++ when I went to college, which is what I actually have my bachelor's degree in (whether you believe it or not, based off how awful my code is here...). What I need to do is find a resource that will help me to learn and get more familiar with JS and how it all works on the web vs my object-oriented programming mindset that's engraved into my brain. I wish there was something out there that could help me sharpen my skills with JS and with the MediaWiki libraries and built-in variables and functions... Thanks again; I owe you one... :-) ~Oshwah~(talk)(contribs)19:52, 27 November 2025 (UTC)
@Oshwah Re: I wish there was something out there that could help me sharpen my skills with JS and with the MediaWiki libraries and built-in variables and functions. I found it all very overwhelming when I first started working with MW components, APIs, etc. I learned a lot simply by looking at existing userscripts. I've rewritten your History-Log-Links from scratch with way too many comments, which might be useful for maintaining or debugging this script (and other related ones.) See User:DVRTed/sandbox/temp.js. PS: I hope this gesture doesn't come off as patronizing—this is me genuinely trying to be helpful because it seemed like you could use some pointers. PPS: Happy coding! — DVRTed (Talk) 01:58, 28 November 2025 (UTC)
DVRTed - Oh hell yes! Thank you for doing this! What you described and what you did for me is exactly what I needed! Looking at existing user scripts, forking some scripts and changing the code in order to customize them to my personal preference, and (at least attempting to) create some of my own scripts is exactly how I've managed to learn some of the MediaWiki libraries and (if anything) just how different JS is than the object-oriented programming mindset that I'm so used to. No, you're not coming off as patronizing or anything like that at all! This is really awesome and extremely helpful to me, and I seriously appreciate it a lot! Thank you. Now I just need to fix the other .mw-usertoollink scripts I wrote (such as this one) so that they work properly as well. If I had working examples of these scripts performing exactly what I intent, it would provide me a lot of good information and learning. I hope this response doesn't come off as me requesting you to spend more time and fix these other scripts as well. Either way, I'll eventually figure it out. Thanks again! :-) ~Oshwah~(talk)(contribs)02:10, 28 November 2025 (UTC)
DVRTed - Ohhh, SWEET JESUS... You have absolutely no idea how awesome this is and how happy you made me. I almost shook my computer monitor violently in excitement when I looked through that code. I obviously have a shit ton to learn with JS vs C++ (as I've been saying), such as how the value assignment works on line 20 with your constant var declaration, why you put publiclog_link into an array format [publiclog_link] on line 44, what ${variable} does vs just entering variable, how the different built-in tools and functions work, and many many more things. Ugh, I just need to find a resource that can just teach me JS from the very beginning... You made me very happy, and I thank you very much! :-) ~Oshwah~(talk)(contribs)02:29, 28 November 2025 (UTC)
C++ is generally harder to learn, but understanding certain basics about Javascript makes it much easier to follow, and also certain basics about Javascript running in a browser environment. So I agree with your assessment about finding a good introductory resource :-). (Some key differences off the top of my head: Javascript is garbage collected, and much like Java and other newer languages, its variables can only hold values of a specific set of types or the equivalent of a C++ reference to an object. Thus an object isn't copied when one variable is assigned to another; both variables point to the same object. Although ECMAscript version 5 does introduce the concept of classes, and thus ways to scope symbols within a class, the older versions do not have classes, and the only way to scope symbols is to declare them locally within a function. That's why you'll see Javascript code do things like declare an anonymous function and invoke it immediately, in order to avoid introducing symbols into the global namespace. Javascript does have an interesting inheritance mechanism where each object can hold an object reference to a prototype object that gets searched for a matching property if none exists in the current object. (The prototype object can have its own prototype property; the search will go up the chain until a match is found or there are no more prototypes to search.) I don't believe Wikipedia supports ECMAScript 5 in user scripts so only prototype-based inheritance can be used. In a browser environment, there is a pre-defined window object, and all global variables are properties of the window object.) isaacl (talk) 03:16, 28 November 2025 (UTC)
I don't believe Wikipedia supports ECMAScript 5 in user scripts so only prototype-based inheritance can be used.: User scripts run on your browser JS engine, and pretty much every modern browser has support for the class keyword. ChildrenWillListen (🐄 talk, 🫘 contribs) 03:27, 28 November 2025 (UTC)
As I recall, user scripts are validated before being served by the MediaWiki server, and the validator being used doesn't support ECMAscript 5. isaacl (talk) 03:31, 28 November 2025 (UTC)
Well, I should start using classes, too then :-). As I recall, there was a Phabricator ticket about updating the validator; perhaps it has been resolved. (Or maybe I've confused it with a ticket for ECMAscript 6 support.) isaacl (talk) 03:44, 28 November 2025 (UTC)
Thanks for the update. Last time I suggested to someone to use "let" they told me it was unsupported, which was the last time I looked into it. isaacl (talk) 04:01, 28 November 2025 (UTC)
Oh, and $(something) is functionality added by the jQuery library, so you can add reading a basic jQuery tutorial to the list. Nowadays, there is equivalent functionality in the Document Object Model API provided by the browser for a lot (most?) of the jQuery API, but some may still prefer the syntactic sugar of using something like $(".someParentClass .someChildClass") to fetch all matching elements. isaacl (talk) 03:27, 28 November 2025 (UTC)
It's checking if special_pagename is a truthy value (it would be false on a non-Special page) ANDif the current page name is included in the list of names; if both of these conditions are met, it is a "supported page." (MDN)
const new_links = [publiclog_link]; is so that the publiclog_link is added before anything else; this is to maintain the order from your original script: talk, contribs, publiclog, [ip related links], [other links, i.e, block]. With template literals, instead of something like "Hello " + name + "!", you can simply write `Hello ${name}!`. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals that explains it very well. Regards, — DVRTed (Talk) 03:52, 28 November 2025 (UTC)
Category does not appear in administrative backlog
A null edit usually fixes issues like this. Otherwise, you need to wait for the job queue to get to it, which can take days or weeks. – Jonesey95 (talk) 03:48, 1 December 2025 (UTC)
It has the code {{Admin backlog|5}} which adds Category:Administrative backlog if there are at least 5 category members, so it can go in and out of the parent category. I don't think a job is added to the job queue when the number of category members changes so it can take a long time to update. Some actions like a purge cause the category page itself to be updated but not the link tables which control the listings in the parent category so things can be out of sync. A null edit of Category:Requested RD1 redactions (not of the parent category) will update everything quickly. PrimeHunter (talk) 15:06, 1 December 2025 (UTC)
In short, if you want that Admin backlog template to categorize its category pages in a timely fashion, you'll need a bot to periodically null edit the pages that you care about. – Jonesey95 (talk) 15:37, 1 December 2025 (UTC)
Dark mode glitch
Hey, I wanted to let you experienced editors know about a common glitch I keep encountering. Some text inside collapsible lists in infoboxes becomes invisible when using dark mode. I'm not sure how to fix it, but I've seen it quite often. The last three examples I noticed were Territories of the United States, Ataturk, and George Washington.
Maybe someone else can reproduce. I can't on Firefox or in Chrome, even after actually checking on my mobile device. Are you using the Wikipedia official dark mode or some extension? Reader mode? Izno (talk) 17:49, 1 December 2025 (UTC)
Tech News: 2025-49
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 Year in Review 2025 will be available on December 2 for users of iOS and Android Wikipedia apps, featuring new personalized insights, updated reading highlights, and refreshed designs. Learn more on the review's project page.
The Growth team is working on improving the text and presentation of the Verification Email sent to new users to make them more welcoming, useful and informative. Some new text have been drafted for A/B testing and you can help by translating them. See Phabricator.
Add a link will now be deployed at Japanese, Urdu and Chinese Wikipedias on December 2. Add a link is based on a prediction model that suggests links to be added to articles. While this feature has already been available on most Wikipedias, the prediction model could not support certain languages. A new model has now been developed to handle these languages, and it will be gradually rolled out to other Wikipedias over time. If you would like to know more, please contact Trizek (WMF).
View all 34 community-submitted tasks that were resolved last week. For example, the issue where search boxes on some Commons pages showed no results due to switch from SpecialSearch to MediaSearch, has now been fixed. [48]
The Wikimedia Foundation is in the early stages of exploring approaches to Article guidance. The initiative aims to identify interventions that could help new editors easily understand and apply existing Wikipedia practices and policies when creating an article. The project is in the exploration and early experimental design phase. All community members are encouraged to learn more about the project, and share their thoughts on the talk page.
When I'm viewing the preview of my edit(s) on my sandbox (when the User sandbox template is there, this message appears), it shows this message at the top:
“This sandbox is in the article namespace. Either move this page into your userspace, or remove the User sandbox template”.
However, when the NAMESPACE template is up there instead, the preview shows nothing — the dialog is gone — but after saving the page, it just displays User.
This started at Wikipedia:Help desk#Sandbox. I don't have an Android device for testing but apparently, if a userspace edit is previewed in the Android app then the magic word {{NAMESPACE}} returns blank which indicates mainspace and fools namespace-dependent templates. Other namespaces and magic words at mw:Help:Magic words#Namespaces may be affected but I cannot test it. It works in the iOS app and a browser. Can somebody with an Android device make some tests and report it at Phabricator if they confirm the bug? PrimeHunter (talk) 12:48, 30 November 2025 (UTC)
Hello, I'm writing on behalf of the Wikimedia Foundation Product Safety and Integrity team. Over the past few months, we have been working on the User Info card. When you tap or click on the "user avatar" icon button next to a username, it displays data related to the user account. It helps access key information that can be helpful while patrolling. The feature is available for all users in preferences as well as global preferences ("User Info" under "Advanced options").
We released the feature on all wikis, saw good feedback and at this point, we believe that we can go further. Enabling it by default for some user groups will make their workflows simpler and more efficient, especially in the temporary accounts world. Specifically in relation to temporary accounts, the User Info card highlights if another user has turned on the ability to view temporary account IPs and provides an estimated number of temporary accounts from associated IP addresses.
We are planning to enable this feature by default for admins, checkusers, rollbackers and Temporary accounts IP viewers (TAIVs). The feature can be easily disabled in preferences.
What does by default mean? Will it be enabled for me too even though I enabled/disabled it in the past? (because popups felt superior, and it doesn't require an extra click!) — DVRTed (Talk) 22:40, 26 November 2025 (UTC)
Hey, I'm guessing that it'd appear for each user with any of these rights, regardless of whether they've enabled or disabled the preference before or not. But I will ask my colleagues to confirm this. SGrabarczuk (WMF) (talk) 22:52, 26 November 2025 (UTC)
Oh. I'm sorry, that is unexpected. When I tested that behavior a few months ago, I recall that conditional defaults would not override a locally or globally set preference. KHarlan (WMF) (talk) 11:59, 27 November 2025 (UTC)
So even greater display of info on registered users, and more secrecy for drive-by anons? Is that really a good direction to be pushing internet social projects? Andy Dingley (talk) 15:48, 27 November 2025 (UTC)
Hiding IP has made dealing with vandalism and especially political bias (Persistent PoV pushing that's not actionable single-edit vandalism) much harder. Who benefitted from that? Andy Dingley (talk) 16:12, 27 November 2025 (UTC)
You must have misunderstood the feature being enabled here. It's about providing more info about unregistered editors, and it is providing that info to the listed roles above.
If you are annoyed by temporary accounts, there is plenty of consternation at WP:VPWMF where you may provide feedback. You should move on if you have nothing to say about the specific feature in this announcement. Izno (talk) 16:23, 27 November 2025 (UTC)
I would like to publicly thank SGrabarczuk (WMF) and the other WMF developers who worked on this feature for listening to the feedback that early testers provided and making changes to the cards in order to make them more accurate. Good work. – Jonesey95 (talk) 17:48, 27 November 2025 (UTC)
Is there a way to get rid of the million tiny heads that are now cluttering almost every page that has usernames? It's visually utterly useless. --jpgordon𝄢𝄆𝄐𝄇20:05, 27 November 2025 (UTC)
@Quiddity (WMF): It's pretty bugged at the moment—likely due to the recent changes to .mw-userlink, I assume. Screenshot showing too many user account icons in my watchlist. This is with ?safemode=1. — DVRTed (Talk) 20:23, 27 November 2025 (UTC)
Perfect, thanks - but in future, can such changes be announced so people can opt in, rather than forcing us all to have it and then try and turn it off? GiantSnowman21:44, 27 November 2025 (UTC)
I found that the heads are clickable; clicking produces a pop-up box; near the top of that box is a three-dot icon, clicking that generates a menu which has "Turn off this feature", a direct link to the above setting. --Redrose64 🌹 (talk) 22:08, 27 November 2025 (UTC)
I turned mine off too, via this route. I do use most of the info provided by the box on a regular basis perhaps once or twice a day. If the head icon wasn't so overwhelmingly distracting I might have left them there, but the distraction far far overwhelms the utility of the function. - WalterEgo10:06, 28 November 2025 (UTC)
That, for me, would be much better. I see somebody posted a screenshot there that amply demonstrates the problem!! - WalterEgo10:37, 28 November 2025 (UTC)
fwiw, I found that making the icons a bit lighter helped make them less distracting. I'm using
I added that to my common.css file, and it changed the heads from black to gray, which I find helpful. I agree with other editors that the heads are a bit intrusive, but I also like to access the information I get by clicking on them, and so, for me, making them gray is an improvement. --Tryptofish (talk) 01:24, 2 December 2025 (UTC)
How can I bypass Cloudflare to archive a site? I can’t archive it because of Cloudflare’s verification issue. (Sorry if this isn’t the right place for technical questions, I don’t know where else to discuss this.) Rafael Ronen08:07, 29 November 2025 (UTC)
In general, sure, but this question clearly involves someone unable to archive a page due to an obscure problem with their device (a crippled browser) which can't be resolved here. The solution is to get someone else to archive the page which has already been offered at the Teahouse. Johnuniq (talk) 01:55, 1 December 2025 (UTC)
It's clearly not about a problem with their device. It's about the Wayback Machine inhibited by Cloudflare Turnstile. Nardog (talk) 02:35, 1 December 2025 (UTC)
due to an obscure problem with their device (a crippled browser) Do you think archive sites take raw HTML from the client to store on their server? — DVRTed (Talk) 10:09, 1 December 2025 (UTC)
Some actually operate that way! From Rhizome_(organization)#Web_archiving: "The "symmetrical web archiving" (browser-based) approach, meaning the same software is used to both record and play back the website.[24] While other web archiving tools run a web crawler to capture sites, Webrecorder.io took a different method, recording network traffic while a user browsed the site to capture its interactive features." This approach later developed into Conifer, which stores the capture at a central archive site. If Wikipedia ever created its own archive site, this is the software to use, it has the highest fidelity. With that said, John may have been thinking the user could not access web.archive.org, due to a block or something wrong with their browser. -- GreenC05:23, 2 December 2025 (UTC)
Rafael Ronen, unfortunately I tried 4 sites and none work (WaybackMachine, Archive.is, Conifer, Ghostarchive). CloudFlare makes it impossible to archive because the sites have a high level of security enabled (human check). Sometimes sites will reduce the level in the future, because CloudFlare interferes with normal users trying to access the site. Maybe they are having a bad time right now with AI scrapers or hackers, check back with them in the future to try again. -- GreenC03:08, 1 December 2025 (UTC)
Request: Move userspace draft to Draft namespace
Hello! I kindly request technical assistance to move the following draft out of my userspace and into the Draft namespace, per COI and AfC guidelines.
Current location:**
User:Associació Òpera Popular de Barcelona/sandbox
Requested destination:**
Draft:Opera Popular of Barcelona
Reason: As the subject of the draft is related to the organization associated with my username, I am following Wikipedia’s conflict of interest policies and the AfC process. Editors advised that the page should be placed in the Draft namespace for proper review by independent reviewers. I do not have the permissions to move the page myself.
Pel que fa al conflicte d’interès: sí, tinc relació amb l’entitat, i per això no estic editant l’article directament. Només he preparat un text neutre al meu espai de proves, tal com indiquen les polítiques de COI, i demano que un editor independent valori si pot ser traslladat a l’espai principal.
Si ho consideres inadequat igualment, ho respecto totalment. Però si creus que el text és neutral i referenciat, i que compleix els criteris mínims, t’agrairé moltíssim qualsevol orientació sobre el pas correcte a seguir.
Caret color CSS change? (Affecting "Reply" textarea only)
I'm using the Vector 2010 skin in dark mode. Since returning from a few weeks away, I'm finding the caret in "reply" widgets is very dark grey (or maybe just very transparent) on black, making it nearly invisible. Which in turn makes it extremely difficult to make edits after typing. (Selection highlights in those textareas are also difficult to see, being navy or very transparent blue on black) In regular edit areas (such as my sandbox), it appears as its usual bright white, and selections the shade of green that I've configured. Has there been a CSS change recently? Though I can't find any caret-color rules using developer tools. I haven't edited my own user CSS lately, either. Using the latest Firefox on Mac (Sequoia), if that makes a difference. -- Avocado (talk) 16:43, 2 December 2025 (UTC)
Might be the syntax highligter. However, vector 2010 has no official dark mode support, so it is expected to vreak every once in a while and then you have to wait for a community memebrr to fix it (or not). —TheDJ (talk • contribs) 18:08, 2 December 2025 (UTC)
Malformed URLs
Starting in October, WaybackMachine URLs are being added malformed a specific way:
Unless someone is cleaning ones as they show up, I don't see any that were added after the end of October, and none before mid-September ish. Izno (talk) 18:41, 30 November 2025 (UTC)
This also hits a timeout but is probably marginally better since it dodges some obvious false positives. According to Help:Linksearch the externallinks table is available on Quarry. You can probably rustle up some SQL to find these (WP:RAQ can help if you don't know it).
The source isn't VE from what I can see. I suppose it's possible to use Citoid via the toolbar rather than via VE so that is a possible cause. Otherwise, I suspect this is or was some copy-paste bug introduced by some browser or browser extension. Izno (talk) 17:44, 1 December 2025 (UTC)
I posted a query with Wayback Machine engineers to see if anyone recognizes it as a known problem. -- GreenC03:41, 2 December 2025 (UTC)
Confirmed bug: according to Wayback engineers:
We had an issue from ~September 15th to ~October 5th related to the date URLs at the top adding an additional /web/timestamp
Izno posted some diffs above that post-date October 5, but the one's I checked appear be wikitext copied from other pages, or other parts of the article. -- GreenC04:17, 2 December 2025 (UTC)
I believe this is now repaired. The URLs were in over 100 articles, and probably over 400 links. If any new ones show up it will be from old diffs, such as a revert to an old version of the page. -- GreenC19:50, 2 December 2025 (UTC)
I have a recurring problem where I nominate an article for deletion, and then don't get any notifications when comments are made or the discussion is closed. This would be a lot handier than bookmarking and coming back later, which is what I do now, as I often need to follow up with other cleanup, or sometimes there are questions that I could have answered. For example, on Wikipedia:Articles for deletion/강수연, there's no option to subscribe for new comments. If I go to Tools -> Subscribe, it seems that only subscribes me for new topics, but new topics are never created on AFD pages. Is there a good workaround for this, or is a feature request needed? -- Beland (talk) 03:14, 2 December 2025 (UTC)
Hmm, it looks like level 3 headers are being used on each AFD page. It would actually be useful to also be able to subscribe or unsubscribe from level 3 sections, maybe? Sometimes a long discussion will split into multiple subthreads. -- Beland (talk) 08:44, 2 December 2025 (UTC)
Aha, that's what I was thinking was out there somewhere. Added myself as a supporter!
Theoretically if we changed XFD level 2 headers to level 1 and then level 3 to level 2, we'd work around this, but that might create a compatibility and re-templating nightmare? -- Beland (talk) 10:03, 2 December 2025 (UTC)
@Beland: Since every AfD is on its own individual page, you can do what I did: at Preferences → Watchlist, enable "Add pages I create and files I upload to my watchlist". This also works for MfD, but not CfD, FfD, RfD or TfD, on all of which several separate nominations share one daily page. For these, you would need to enable "Add pages and files I edit to my watchlist". --Redrose64 🌹 (talk) 21:44, 2 December 2025 (UTC)
Unfortunately, my watchlist has over 1400 pages and I almost never check it. (When I do, it's to purge the list of followup items from years ago.) -- Beland (talk) 21:48, 2 December 2025 (UTC)
Ah, but if I restrict viewing my watchlist to the Wikipedia namespace, it does actually produce a useful list of AFD pages I recently created. Thanks for the suggestion. -- Beland (talk) 22:31, 2 December 2025 (UTC)
The landing page after a successful page deletion, e.g.: https://en.wikipedia.org/w/index.php?title=User:Beland/Comparison_of_circulating_currencies&action=delete (which unfortunately only works once unless you recreate the page) has dark mode problems. It's title "Action complete" and then there's a box titled "Maintenance links" which has text like "Depending on the reason for deletion, you may want to remove any links to this page (articles | redirects)." All the body text in this box (except for blue links) is nearly impossible to read grey-on-grey in dark mode. I'm not sure where this text is controlled from. -- Beland (talk) 22:18, 2 December 2025 (UTC)
Ah, it looks like I tried to fix those before. The problem only shows up when the content is displayed in context after deletion, not when viewing the content on a standalone page. I tested this time and I seem to have actually fixed the first two. Your changes to the third page make it much better standalone; not sure how to test that as a sequence. -- Beland (talk) 23:20, 2 December 2025 (UTC)
1. Not really sure how you fix but it’s desktop centric to use a first letter lowercase captcha when most phones default to capitalizing first letter. Proper English and all that. Anyway adds a level of friction on mobile
“Who’s the captcha stopping” the dumbest stuff, what is still a complete waterfall of bad faith contributions. But we might be switching to a invisble hcaptcha soon, so lets hope for that. —TheDJ (talk • contribs) 18:06, 2 December 2025 (UTC)
@Redrose64, The Bushranger: Looks like something was changed in the software to force the top margin to 2px, so the CSS-only tweak doesn't work. That being said, having it set to 2px instead of 12px likely makes the tweak unnecessary anyway. --Ahecht (TALK PAGE)16:46, 1 December 2025 (UTC)
Dr. Blofeld - those messages are automatic created when I do a PROD (for articles without sources), and go to the article creator. Thanks for the feedback. Regards, JoeNMLC (talk) 19:40, 29 November 2025 (UTC)
I think it's time then we allowed the option to opt out of Twinkle messages. To mute users should mean the ability to stop talk page messages from people. I have nothing against Joe and don't have an issue with him prodding articles which genuinely don't have adequate sourcing online, but I don't want to receive the prod notices. ♦ Dr. Blofeld20:41, 29 November 2025 (UTC)
Twinkle is used for many things, e.g. escalating warnings. Disruptive users shouldn't be able to opt out of that. Others might opt out of Twinkle to avoid one type of post and then miss other types. PrimeHunter (talk) 21:05, 29 November 2025 (UTC)
@Dr. Blofeld: I certainly didn't imply that. I just think there are too many problems with allowing users to opt out of Twinkle messages when Twinkle is used by so many users for so many different messages. We might allow a limited opt out like allowing users to opt out of prod messages but it sounds like significant work for a system very few would probably use. How bad is it to just remove or ignore the messages, and do you really never want to be notified about any article you have created? PrimeHunter (talk) 21:10, 2 December 2025 (UTC)
That's a fine system for bots. For gadget/user scripts, it's useful to have something that's easily detected client-side if the page is open ($('a.external[href*=optout\\.twinkle]')) or with an API call that has a small response (prop=extlinks with elquery param). Maybe the template could be made non-Twinkle specific, but if there's interest that can be done later as the advantage of not relying on the wikitext is that we can rename the template later, modify the external link it uses, etc. – SD0001 (talk) 11:28, 3 December 2025 (UTC)
It's not really the greatest system for bots either, but it's what we have. It works fairly well as a check when you're making an edit without using the "append a new section" feature, and it has both the advantage and disadvantage that it can't be (accidentally) transcluded from some other page. Anomie⚔12:48, 3 December 2025 (UTC)
Looks like you did create the page at one point: you created the redirect (in Special:PermaLink/852535838) by renaming the old version of the page to Glynis Jones (disambiguation). The history doesn't look like it because someone later did some history merging and splitting, which resulted in some of the disambiguation page edits you had moved to be merged with the redirect.Apparently xtools identifies a "creation" by looking for the rev_parent_id field to be 0. I don't know of any straightforward way to reset this (since T183375 fixed preservation across deletion and undeletion). Anomie⚔02:34, 30 November 2025 (UTC)
Greetings, The long-standing PetScan I've run like for months, is now showing error: Io(Io(Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" })). Against "Category - All articles lacking sources". If an expert here can investigate, that would be great. I know from in the past, sometimes, PetScan "magically" recovers, so I will try again tomorrow. (not urgent) Thanks. JoeNMLC (talk) 20:52, 3 December 2025 (UTC)
Can't remember if I posted this here, but exactly what the question says. Does wikitext support this for CSS? My userpage previously used a lot of custom CSS and had a bunch of contrast issues depending on which colour mode a user is on, which I need to fix by creating overprecise CSS. thetechie@enwiki (she/they | talk) 22:30, 3 December 2025 (UTC)
Producing a tag with an attribute is easy: {{#tag:foo|txt|bar=baz}} generates <foo bar="baz">txt</foo>. But I'm writing a template where the attribute should be optional: depending on a template parameter, there should either be the attribute with a value or no attribute at all. I thought code like this should work (using a dummy condition here): {{#tag:foo|txt|{{#if:true|bar=baz}}}}. But it doesn't, the attribute is ignored: <foo>txt</foo>. It looks like {{#tag}} only recognizes attributes if the = character occurs directly in the value, even {{#tag:foo|txt|bar{{=}}baz}} doesn't work. So far, I can only think of two ways to make this work:
Wrap the whole code in an {{#if}} clause that contains two separate invocations of {{#tag}}. Of course, that leads to a lot of code duplication, since the invocations are identical except for the attribute.
Always generate an attribute, but give it a dummy name (and value, maybe) in the case where I don't actually want it: {{#tag:foo|txt|{{#if:true|bar|dummy}}=baz}}. This works in my case (the next parser phase seems to simply ignore the unknown attribute), but it feels a bit dirty.
Unfortunately there isn't. I usually do #2 if I am calling a template, but I prefer #1 if I am calling parser function or anything that is a black box. P.S. The way I do #2 is usually by adding a hash: {{my template|txt|{{#if:true||#}}bar=baz}}. --Grufo (talk) 00:12, 4 December 2025 (UTC)
I've started making a game log for the 1996–97 Golden State Warriors season unfortunately it's not formatting the way it should and has some inexplicable | in it and I want those gone, can someone assist me with the game log formatting?
Well, Trappist, I did basically post that I'm no expert... Thank you, I'm toddling off to fix it now. Always appreciate your expertise & advice. - Shearonink (talk) 15:16, 4 December 2025 (UTC)
The XTools gadget I think. it adds a link to the users contribs for the user who most recently edited that page Best wishes, Macaw*!20:00, 4 December 2025 (UTC)
Macaw*, I can't see any links like that in XTools, but there's a link at the bottom of xtools for reporting an issue. If you do so, make sure to include where the link is. — Qwerfjkltalk20:34, 4 December 2025 (UTC)
@Macaw*: Please say from the beginning where you see a reported problem. The contributions link works in all places I have tested but you load 68 scripts in User:Macaw*/common.js. I tracked it down to this script by Opencooper:
I have adjusted the code above to possibly do what you want. You can also use "transparent" instead of white, but it can cause problems in dark mode. – Jonesey95 (talk) 15:33, 5 December 2025 (UTC)
Userbox group not working
Not sure if this is the right place to post this, but I have an issue on my user page in which the userbox group does not work. If you expand it, it simply says {{{userboxes}}}. How do I fix this? thetechie@enwiki (she/they | talk) 22:31, 3 December 2025 (UTC)
@TheTechie:{{Userbox group}} recognises five named parameters: |collapse=|style=|title=|userboxes= and |footer= (it also recognises one positional parameter as an alias for |userboxes=). You're trying to use |title= (which is valid), |collapsed= and |content= (which are not). --Redrose64 🌹 (talk) 22:54, 3 December 2025 (UTC)
Why are there two templates with such similar names but different syntax that a typo of not hitting space could cause massive issues that aren't easily solvable? Should they be merged? ~212.70~ ~2025-31733-18 (talk) 04:58, 5 December 2025 (UTC)
When I'm logged in, I get a sticky header overlapping the top of the browser window as I scroll down.
If I click a link to a subsection within an article that's derived from the title of that article- in this case Prince_Rupert's_cube#Noperthedron_and_non-Rupert_polyhedra- the start of the section I want to read appears just below the sticky header, as one would want. (In other words, it makes an allowance for the sticky header and offsets the anchored section from the top of the window).
However, if I click a link to a link defined via {{anchor}}- in this case, {{anchor|nopert}} and Prince_Rupert's_cube#nopert- the subsection title and content immediately following it are obscured by the sticky header (i.e. allowance is *not* made for the sticky header in this case).
This applies even when the {{anchor}} is placed between the opening and closing "==" (or whatever) in the section title.
This is annoying, particularly as links to section titles are prone to breaking whenever they are changed and anchors are less likely to be broken in this way.
This behaviour happens both with my usual browser, Firefox 145, and using Microsoft Edge. (Since the latter is now Chrome-based, I assume it happens with Chrome too, though I haven't checked that as I don't have it installed).
What is a good way to query all abuse logs (also known as edit filter log) of a user on all wikis on which they have created a local account? I know I can use mw.ForeignApi, but I was wondering if there's a better way. NguoiDungKhongDinhDanh06:27, 6 December 2025 (UTC)
In one place, no. You would need to first fetch all their attached accounts, then query each project's abuselog individually. — xaosfluxTalk20:42, 7 December 2025 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
Anybody who wishes to secure their user account can now use two-factor authentication (2FA). This is available to all registered users of all Wikimedia projects. This is part of the Account Security initiative. Later, 2FA will be required for all users who can take security- or privacy-sensitive actions.
Updates for editors
Following last week's deployments, the Add a link feature, which allows editors to add suggested links during editing, will be available to an additional 33 Wikipedias starting on 9 December. This expansion is possible thanks to the new prediction model that now supports all languages, including those that were previously not covered. While the feature has been available on most Wikipedias for some time, this rollout brings us closer to using the improved model everywhere. If you have any questions or would like more details please contact Trizek (WMF).
Last week, the Search Platform team added transliterated as-you-type search suggestions to Georgian wikis. If there are only a few regular search suggestions, then queries in Latin or Cyrillic script are now rewritten into Georgian script to look for more matches. For example, searching for either bedniereba or бедниереба will now suggest the existing article about ბედნიერება ("happiness"). You can recommend other languages where transliterated suggestions would be useful on Phabricator for future development.
Later this week, a controlled experiment will begin for editors on the 100 largest Wikipedias who are editing a section in the mobile web visual editor. 50% of these editors will notice a new "Edit full page" button that will enable them to expand their editing session to the whole page. This feature is intended to make it easier for people on mobile web to edit any article section, regardless of which section-edit icon they tapped to begin. The experiment will last ~4 weeks. You can find more details about the project.
Later this week, the Reader Growth team will launch a mobile web experiment to expand all article sections by default (currently they are collapsed by default) and pin the section header the user is currently reading to the top of the page. The experiment will affect 10% of users on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias. [57]
The Wikipedia Year in Review 2025, a feature in the Wikipedia mobile apps (iOS and Android) that provides users with a personalised summary of their engagement with Wikipedia over the year, is now available on the iOS and Android apps. This edition includes expanded personalised insights, improved reading highlights, new donor messaging, and updated designs. Open the app to view your Year in Review and explore your reading journey from 2025.
A recent software bug caused edits made with VisualEditor to make unintended changes to wikitext, including removing whitespace and replacing spaces with underscores in wikilinks inside citations. This was partially fixed last week, and further fixes are in progress. Editors who used VisualEditor between November 28 and December 2 should review their edits for unexpected modifications. [58]
View all 23 community-submitted tasks that were resolved last week. For example, the incorrect handling of URLs copied from the address bar of Microsoft Edge users, has been resolved. [59]
Updates for technical contributors
Starting this week, users of the "⧼codemirror-beta-feature-title⧽" beta feature will have CodeMirror as the editor for Lua, JavaScript, CSS, JSON and Vue content models, instead of CodeEditor. With this, the linters will be upgraded. This is part of a larger effort to eventually replace CodeEditor and provide a consistent code editing experience. [60]
Developers are encouraged to take the 2025 Developer Satisfaction Survey, which remains open until 5 January 2026. If you build software for the Wikimedia ecosystem and would like to share your experiences or feedback, your participation is greatly appreciated. [61]
@Sapphaline: If there are no corresponding parameters then the numbered headers should be blank and not even have empty cells or rows. If you saw autoheaders = y and thought it was enough to have empty data fields below the headers then no, the non-blank headers are not parameters to {{Infobox}} but to {{Infobox3cols}} which doesn't even have an autoheaders parameter. PrimeHunter (talk) 18:58, 8 December 2025 (UTC).
Issue with content translation
Hello. I am having an issue with content translation: I want to translate the page ƛ̓ from French to English (link), but it keeps saying something similar to this:
Critical error: Content translation failed to load due to internal error.Close
When using a temporary account, Wikipedia does not remember the "hide" status of the Tools and the Main menu. This is extremely annoying. Every time I load a page, I need to rehide the Tools and Main menu. --~2025-39616-28 (talk) 11:00, 9 December 2025 (UTC)
Items not removing from watchlist if not full articles
Minor quibble, but I was sprucing up my watchlist because it was too long, due to the amount of files, templates, categories and user talk pages I had created. When I am on the tab "view and edit watchlist", I tick the relevant boxes to remove entries, then the red box "remove titles", but they are not removed. In the event of removing articles AND miscellaneous from the watchlist, only the articles are removed. This is a minor issue but I'm interested to see if other people have this and what could be causing it. Unknown Temptation (talk) 11:32, 9 December 2025 (UTC)
In all three cases, what's happening is that the template coding is failing to generate or include the actual category specified by category1= in the template coding, and is instead basing the category name on the contents of tempsort1= — for example, the Airport category is being generated on {{NewBrunswick-airport-stub}} by the code
| category1 = New Brunswick building and structure stubs | tempsort1 = Airport
In each case, this is only affecting category1= and tempsort1=. But if I try to fix it by removing tempsort1=, it restores category1= but then suddenly starts whiffing category2= and tempsort2= instead. And it also warrants note that none of these are new stub templates, either: they're all long-standing ones that weren't doing this nonsense at all before now. It also, in each case, appears to only be affecting the categorization of the template itself as a template, and does not appear to be transcluding the wrong categories onto articles, as Bathurst Airport (New Brunswick) is still in Category:New Brunswick building and structure stubs, and has not been smuggled into Category:Airport.
So since this is absolutely beyond my abilities to figure out or fix, could somebody try to determine what the heck's going on? Thanks. Bearcat (talk) 16:04, 7 December 2025 (UTC)
As far as I can tell, there's some weird garbage collection going on with respect to Module:Buffer. At one point Module:Article stub box does (v[1]andBuffer(v[1])orattention):_in(v.k):_(v.t):_str(2,nil,nil,'|'). The :_in(v.k) only weakly references the Buffer(v[1]), so if garbage collection happens to occur sometime before :_str(2,nil,nil,'|') stringifies the whole thing then the category name gets lost, the joining gets confused into losing the |, and we wind up with just [[Category: Airport]] rather than [[Category:New Brunswick building and structure stubs| Airport]]. If garbage collection doesn't happen to occur, it works fine. Which also makes it very hard to determine whether an attempted fix really fixed it or just happened to avoid triggering a GC at the wrong time. Anomie⚔17:11, 7 December 2025 (UTC)
If it did, I suspect it's only indirectly, by changing the details of how much memory is used when and therefore when the garbage collection is triggered. Same for the flag thing. When I was trying to debug it in Module:Article stub box, I found that simply inserting (literally) mw.log( "???" ) in the right place would make the TemplateSandbox preview stop showing the problem. Anomie⚔18:01, 7 December 2025 (UTC)
Truly amazing and way over my pay grade. There could be something clever going on that I don't understand, but these global variables may be a problem: alt build s shift unbuild. Johnuniq (talk) 03:51, 8 December 2025 (UTC)
Now, back to the main topic. I've made some edits to Module:Article stub box/sandbox which, if I've understood what is going on correctly, should make the bad GC impossible, and tested by changing the broken revisions of the stub templates to use the sandbox version instead and previewing. Does that code make sense to you, Anomie? * Pppery *it has begun...16:42, 9 December 2025 (UTC)
That should work. The important part is assigning buf=Buffer(v[1]). If you want to shorten it up a little you should be able to get away with localbuf=(v[1]andBuffer(v[1])orattention) instead of the if. Anomie⚔17:00, 9 December 2025 (UTC)
I know, but I figured since I was editing the page anyway the ternary operator syntax was kind of hard to parse and writing it out as if statements should be clearer. * Pppery *it has begun...17:28, 9 December 2025 (UTC)
Why does the "Contentious politics" article show up as transcluding "Thomas Paine"?
When viewing Thomas Paine and using the "What links here" feature, it lists Contentious politics as an entry, transcluding Thomas Paine. (see, e.g., here). But there is no such transclusion (as expected; it would be an odd thing to transclude).
Hello, I just tried to edit a page and added a new reference, however when I hit "publish changes", it said "Your edit includes new external links. To protect the wiki against automated spam, we kindly ask you to solve the following hCaptcha:
This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.", which is to be expected. However, I can't complete the CAPTCHA as it is not appearing at all on my screen. I am using a 5th Gen iPad (2017) on iOS 14.6. Many websites don't work due to my outdated iOS, however this is the first time I have had an issue with Wikipedia, and I published changes successfully only a month or two ago. ~2025-38416-80 (talk) 15:00, 6 December 2025 (UTC)
Have you tried submitting the form even without the hCaptcha showing, and seeing if it publishes your edit?
This might be falling into an uncommon situation that we're aware is possible, but will go away next week when we tighten the configuration slightly. EMill-WMF (talk) 17:36, 6 December 2025 (UTC)
I've just tried again and still no luck. Every time I hit "publish changes", it just refreshes the page. No error code or anything. I do all my browsing in "private" mode (Apple's version of incognito), I'm assuming that's not relevant, but maybe that could have something to do with it? Thanks for your reply anyway. ~2025-38416-80 (talk) 18:29, 6 December 2025 (UTC)
UPDATE: I managed to find a workaround! If I use the mobile layout, the CAPTCHA is visible and I can publish changes as usual. They're a few visual glitches with text in mobile mode, but it mostly functions normally. Still doesn't answer why I had this problem in the first place, but maybe it can provide some clues. ~2025-38416-80 (talk) 19:54, 6 December 2025 (UTC)
Still having CAPTCHA issue even though it's supposed to be fixed
Hello again, I posted this query 2 days ago (on a different temp account due to browsing on private mode). Supposedly, this issue has been fixed, however I am still having the same problem. I think the issue I'm having has been misidentified, as the support ticket reads "Upon clicking Publish changes again, the hCaptcha appears.", however this doesn't work in my case.
(Re-iterating info from the first query for convenience:
5th Gen iPad (2017), iOS 14.6., website version (Safari). Every time I hit "publish changes" refreshes the page. Works as intended if I switch to mobile layout) ~2025-39254-71 (talk) 12:54, 8 December 2025 (UTC)
A fix for the captcha not loading was rolled out yesterday, are you still having the issue? What version of Safari are you using? (as additional page refresh issues could be if you are using an unsupported browser). — xaosfluxTalk10:57, 9 December 2025 (UTC)
Just tried again, still not working. Safari version matches iOS version so it should be 14.6.
I keep seeing an issue of people using the android app inserting an image where either the |image= or |image_caption= are not properly defined. It appears to be an issue with the android app. Can someone point me to where I need to post to raise this issue? I'm lost... Zackmann (Talk to me/What I been doing) 22:11, 8 December 2025 (UTC)
@PrimeHunter: not the best example, but here is the most recent one. There is no |caption= defined for that infobox. That is the only diff I have at the moment. Saw this issue a lot when I was cleaning up Infoboxes last month but that was tens of thousands of edits ago. :-\ Zackmann (Talk to me/What I been doing) 22:46, 8 December 2025 (UTC)
@Zackmann08: Thanks. A preview of that edit in the iOS app says: Preview warning: Page using Template:Infobox official post with unknown parameter "caption". I don't have an Android device. Can somebody say whether the Android app also says it? If it does then it doesn't look like there is an app issue but just a user making a wrong guess about a parameter name. It it doesn't say it then it appears Module:If preview isn't working in the app. PrimeHunter (talk) 23:27, 8 December 2025 (UTC)
I tried a test in the iOS app [62] but it added the image below the infobox with the tag "image add top", and that was an article with {{Infobox film}} which actually has image and caption parameters. If it sometimes adds the image to the infobox then I can certainly see it going wrong for other infoboxes if it just guesses there is a caption parameter. PrimeHunter (talk) 00:07, 9 December 2025 (UTC)
Template:Infobox official post has a TemplateData section in its documentation, so no app should ever be guessing about valid parameters for that template. Either the app or the human put in the wrong parameter; if it was the app and the problem can be reproduced, a bug should be filed. If it was the human, a message-style bug should be filed on the editor's user talk page. – Jonesey95 (talk) 02:15, 9 December 2025 (UTC)
I couldn't find an existing bug report about the issue. phab:T369677 indicates that in July 2024, only the Android app tried to insert images in infoboxes. phab:T355326#9507847 (about the iOS app) mentions the challenge: "Infoboxes have parameters, one parameter is called image, but not all the time, different types of infoboxes have different names for the parameter, and different names for the image caption field." It also links the Android code [63] which does mention different parameter names but I'm not examining the details. PrimeHunter (talk) 12:14, 9 December 2025 (UTC)
Hi everyone,
Thank you for raising this and for providing examples and testing across different devices. I’ve created a Phabricator ticket so the Android team can investigate the issue.
I got a notification that my email was disabled due to repeated delivery failures(a vandal was repeatedly emailing me, that may have been the trigger) and that I need to reconfirm my email; it sends me a code, but when I click the link it tells me the code that it just sent is invalid. 331dot (talk) 09:45, 8 December 2025 (UTC)
This is likely hitting a throttle, if it is still happening after 24 hours we can start a bug track on it. You may want to temporarily remove the ability for others to send you wikimail to stop the spam in the interim. — xaosfluxTalk10:54, 9 December 2025 (UTC)
Just today, I noticed that a few noticeboards, ANI and VPT, were appearing strangely formatted. No horizontal menu at the top of the page, at the bottom of the page were a lot of links. I posted about this at WT:AN but only got the suggestion to change my skin in my Preferences so that's what I've done but I don't care for other features that came with it. Has there been any system-wide changes to noticeboards which are transcluded? I feel odd that I'm the only one noticing a change. LizRead!Talk!02:20, 11 December 2025 (UTC)
Piñanana I think the question here is whether a bot can change the tcmdb template so that instead of hitting a redirect at tcm, that it goes to the page at catalog.afi.com . A note has been added to Template talk:TCMDb title about something that may be similar, but I am not sure.Naraht (talk) 18:30, 29 November 2025 (UTC)
As far as I can tell, the TCMdb family of templates are hopelessly broken. I have tried to contact TCM a couple of times for help, but I have never received a response. – Jonesey95 (talk) 01:30, 30 November 2025 (UTC)
Also Template:Screenonline nameTemplate:Screenonline titleTemplate:Screenonline TV title:
Any special magic to getting transparency to work for WebP images? I was uploading some images of the Omega penny that were auctioned off in the past 24 hours, and midway through I had the wild idea to see how much smaller WebP could get the images. It seemed to produce good results (even at 100% / Lossless, which ought to line up well with the PNG I had intended to upload) and on the file description page you can see the transparency works when you hover your cursor over the image. But when I used it in an article, it has a white background. See the gallery above. Is this a known issue, is there a phab ticket, is there a workaround? =) —Locke Cole • t • c • b06:55, 12 December 2025 (UTC)
In the gallery above, I see the gold coin with a transparent/checkerboard background, and the other one with a white background. Looking at the PNG previews generated by the server, I see that the original-size one (i.e. the 2000x2000 PNG) has a grey background (which I assume is Chrome's way of rendering a transparent background), and the smaller ones have a white background. Looks like this might be T283646? --rchard2scout (talk) 08:50, 12 December 2025 (UTC)
Oooh, that looks like it could be the issue. Guess that means I should stick to PNG for now until that gets resolved. Pity. —Locke Cole • t • c • b10:41, 12 December 2025 (UTC)
Usually I am only notified of a discussion if it occurs within a thread I have started or participated in. This usually excluded comments that aren't a response to mine in most of the noticeboards. Lately though, I have begun to be notified whenever an edit is made to any of these threads I have edited (e.g. WP:AIV or WP:UAA), meaning I basically get a notification every couple minutes about an admin responding to a completely unrelated report, or to someone making a new post. Worse, this also affects talk pages, so I get notified whenever someone I warned gets blocked or warned again. Was this intentional, or is this a mistake/bug? Aside from being annoying, it also gets confusing to repeatedly get notifications saying "You have been blocked indefinitely", or similar. Lynch4402:44, 10 December 2025 (UTC)
@Lynch44 It looks like this problem is occurring via Twinkle usage. I.e. From a glance at your contribs, I'd guess that you got notified from the subsequent edit at The Oneeeeeee's talkpage because Twinkle is re-using the ==December 2025== section header, and similarly Twinkle is adding entries to the single ==section== at UAA. Context: As Izno noted, the change is coming from phab:T290778 (as announced in the 2nd entry in m:Tech/News/2025/45, but deployed late, this week). The Editing team devs will talk to the Twinkle devs to see how we can make Twinkle not auto-subscribe (which might require changes in the Extension, and/or just in the Gadget. TBD.). Sorry for the noise in the meantime, or, you may wish to temporarily unset the preference noted above. I hope that helps, Quiddity (WMF) (talk) 20:07, 10 December 2025 (UTC)
It'll probably be something that tools will need to adapt to -- like the existing watchlist parameter for edits, where it defaults to "respect the user's preference" but where you can explicitly set it to override that behavior. DLynch (WMF) (talk) 21:02, 11 December 2025 (UTC)
TM:Convert and TM:Convert abbreviated have different docs, but the doc of the latter is basically just one sentence pointing to TM:Convert/doc and noting that the difference that the abbr parameter is prefilled.
However, some editors raised concerns that this was not the right procedure. The tutorial seems to be outdated, as this method is no longer preferred for TM:Collapse top for example. There seems to be a preference to include the TemplateData on the doc subpages directly rather than transcluding a dedicated subpage. I also found this TfD, where consensus was to keep a bunch of TemplateData subpages (at least for those that have to be transcluded on shared docs), but this was 8 years ago.
So, for TM:Convert and TM:Convert abbreviated, is it now best to have the TemplateData on a dedicated subpage and transclude it on both docs, like how I did it now? Or should the same TemplateData be defined twice locally, for TM:Convert/doc and TM:Convert abbreviated/doc each? Or is it better to merge the entire documentation (thus making a dedicated TemplateData subpage no longer necessary) and transclude that on both template docs? YuniToumei (talk) 09:55, 12 December 2025 (UTC)
Where have "some editors raised concerns"? The last option above (duplicate the docs) is a very ugly idea. That makes people who encounter {{cvt}} wonder how it is different from {{convert}}. The current situation (where cvt has just a few words stating what it is) is best. Johnuniq (talk) 10:06, 12 December 2025 (UTC)
The transcluded documentation looks right to me. It's an elegant solution. I don't see any editors complaining at the templates' talk pages. – Jonesey95 (talk) 15:50, 12 December 2025 (UTC)
There is no link to modify an editnotice if a page has an existing default BLP editnotice
I noticed this when attempting to add {{BLPCRIME editnotice}} to an existing WP:BLP, and found there was no link to actually do this because instead of the "Page Notice" redlink there was a bluelink to {{BLP_editnotice}}. Choosing a random example, you can see on this edit page, there is no link to add a manual edit notice, whereas on this page there is a redlink to add a Page Notice, and on this page which has both a default BLP edit notice and a manual one, the edit link is visible. RunningOnBrains(talk)19:46, 13 December 2025 (UTC)
Page notices are always in the same place, [[Template:Editnotices/Page/{{FULLPAGENAME}}]], so you can still add one even if the module didn't make a link for you. Those links all come out of Template:Editnotice load though, so if you have an improvement to add, that is where to do it. — xaosfluxTalk20:44, 13 December 2025 (UTC)
Getting notified of replies when an AfD is added to a deletion sorting list
For some strange reason, I have sometimes been notified of replies in deletion sorting lists. On all 4 occasions, this has happened when someone added an AfD to a deletion sorting list. Since I, at present, have no involvement in those AfDs, I should not be notified of replies, especially considering the edits to those lists aren't even supposed to be replies to begin with. Unless someone is actually able to see the notifications I get, my only evidence of this is a series of e-mails that I refuse to publicize. Is someone here able to fix this, or should I take it to the Phabricator? JHD0919 (talk) 23:12, 13 December 2025 (UTC)
@JHD0919: Please give an example so we can see why you were notified. You can obviously leave out your email address but if you aren't willing to quote any part of the mail or reveal any of the edits then it's hard to help. Do not post such a vague report to Phabricator. PrimeHunter (talk) 23:46, 13 December 2025 (UTC)
How to get 'Maintenance reports' in 'Special pages' reports fixed
Looking for something to do, I went to the maintenance reports on Special:SpecialPages . Unfortunately I find that many of the reports contain many pages that in my opinion shouldn't be included. For example Special:ShortPages includes redirects and set index articles, and while they are indeed short pages, they do not require maintenance. Similarly Special:LonelyPages contains a lot of Soft redirect to Wiktionary pages. I'm not sure why these would even exist (i.e. At any rate) and again they don't need maintenance, other than perhaps deleting.
Looking at the associated talk pages, it seems like issues such as these are mostly ignored and unfixed. Is there a better place to bring these issues to the attention of someone who can address them? Derek Andrews (talk) 22:09, 13 December 2025 (UTC)
I think that ShortPages report, like many Special: pages that are effectively uneditable, is abandoned. See its talk page at Wikipedia talk:Special:ShortPages, and that page's archives. Anomie is right; find a corresponding database report that sees active use and maintenance, or ask for one to be created. – Jonesey95 (talk) 07:03, 14 December 2025 (UTC)
Searching the Wikipedia namespace without discussion pages
Over time, I have found searching the Wikipedia namespace more and more difficult as the results are increasingly discussion pages in the Wikipedia namespace. Is there an easy way to omit these?
For example, of the first 20 search results for "talk header cruft", 12 are AFD, TFD, and RFD pages, 3 are peer review discussions, and 3 are featured candidate discussions. That leaves only two of twenty pages that are not obviously discussion pages. Is there a way to do a search query of the Wikipedia namespace that will omit most discussion pages?
Perhaps due to poor search terms, the most relevant pages for my query did not appear. These are:
@Daask You can exclude some titles or some words and phrases: example. I'm not sure what you're looking for in these pages (talk? header?), maybe your search terms need some improvement too. See Help:Search. Ponor (talk) 15:59, 10 December 2025 (UTC)
I suppose I can create a custom search box with -intitle:"Articles for deletion" as you suggest. However, I thought this was likely a common problem that others have experienced and thought perhaps there was a common solution. Daask (talk) 16:22, 10 December 2025 (UTC)
You're most definitely not the only one. I have a browser shortcut to use google to search wikipedia when I want to actually find something in project or template space, because the SERP here are so frustrating. -- Avocado (talk) 15:57, 14 December 2025 (UTC)
Adding a -UTC will get rid of pages with signed comments, and it's unlikely that much baby will go out with the bathwater. Unfortunately, there's no clean way to do this, and it would probably be a better system if we had projectspace split into a place for policy/guideline/information/essays and a place for project-wide discussions. Firefangledfeathers (talk / contribs) 22:53, 10 December 2025 (UTC)
Yeah, I wish we had something like -hasmagicword:NEWSECTIONLINK -hasmagicword:NOEDITSECTION, which would work for this use case. Nardog (talk) 16:05, 14 December 2025 (UTC)
Thinking of filing a bug but want to make sure I'm not the only one here.... Looking at Burbank, California (for example) on my iPhone using the Wikipedia app. The Mapframe won't load. Just seeing an empty square with a blue question mark. Can anyone else confirm this issue? Zackmann (Talk to me/What I been doing) 00:22, 14 December 2025 (UTC)
No, this is because the apps use Parsoid, and support for maps in Parsoid is not yet working. There is work happening on this problem for the last couple of weeks, but the mapimage generation is a complex process and the adaptations need to happen at multiple levels, so its a slow process. —TheDJ (talk • contribs) 17:26, 15 December 2025 (UTC)
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
View all 18 community-submitted tasks that were resolved last week. For example, one of the fixes addressed an issue for temporary accounts adding an external URL, which triggered an hCaptcha request in more cases than intended, and did not display the required popup on the first attempt to publish the edit. [66]
Updates for technical contributors
To improve database and site performance, external links to Wikimedia projects will no longer be stored in the database. This means they will not be searchable in Special:LinkSearch, will not be checked by the Spam Blacklist or AbuseFilter as new links, and will not be in the externallinks table on database replicas. In the future this may be extended to other highly-linked trusted websites on a per-wiki basis, such as Creative Commons links on Wikimedia Commons. [67]