Wikipedia:Village pump (technical)/Archive 228

Hi everyone,

In November we shared that the Reader Growth team was conducting a test to make it easier for readers to browse and discover images and other multimedia on Wikipedia articles. We are experimenting with potential improvements to the reader experience because of declining pageviews to Wikipedia and fewer readers returning to the site. A top request from readers, as demonstrated in surveys of global internet users, is for “more images/photos” on Wikipedia.

This image browsing experiment, a mobile-only A/B test for 0.1% of readers, went live on English Wikipedia on Nov 17 and ran for four weeks before being turned off. We also ran the experiment on Arabic, Chinese, French, Indonesian, and Vietnamese wikis. Here we want to share results with you and hear your thoughts on the next steps for this work.

The experimental feature included:

• A horizontal image carousel inserted above article content, showing thumbnail previews of article images.
• A detail view overlay that opens when a user taps a carousel image, displaying a larger version with caption, smart cropping, and action buttons (share, download, view on Commons).
• A Visual Table of Contents (VTOC) showing a grid of all article images, followed by images available from across wikis for users interested in seeing them.
• Smart cropping and dominant color extraction for enhanced visual presentation.

What did we find?

Our primary success metric was the clickthrough rate (CTR) on the image carousel element we added to the top of article pages. Clickthrough rate, which measures how often people engage with the feature, tells us whether or not a user is interested in this feature, and we targeted 3% due to typical web CTR being between 1-5%. Our results showed that people were interested. On English Wikipedia, we saw a clickthrough rate of 8.7%, which is quite high relative to other features. On Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias, we saw a CTR of 7.8%.

Because we want readers to return to Wikipedia after their first visit, we also tracked retention, or what percentage of readers who came back to wiki within 21 days. On the non-English wikis we tested, retention improved by ~0.1%. There was no retention change on English Wikipedia. We ran the test on a much smaller group on English Wikipedia so it is possible we didn’t get sufficient data.  

We also found that when readers tapped on an image, they usually wanted to engage more deeply with images. 61% of taps from the detail view were from readers opting to see the full image, 15% were for downloading the image, and 9% were for sharing the image, all higher than the options to explore other images more broadly. These data points suggest that readers’ default preference is to engage further with the image they selected.

What are we doing next?

We plan to proceed with developing this feature, building towards a rollout (tentatively scheduled for this March) given its strong clickthrough rate, which signals new reader benefit. Based on the feature usage data, we currently plan on scaling the following:

1. The image carousel
2. Expanding to the full image by when opened, for mobile web readers on all wikis.
3. Options for editors to remove the carousel from articles as needed on a per-wiki basis
4. The option for logged-in readers to turn off the carousel for themselves across all pages.

For now, we will not scale the ability to see images from other wikis or a visual “Table of Contents,” but we will explore those ideas further to gain more information, likely in future experiments, that we will also communicate here.

Additionally, we want to hear more from you. What do you think of these results? Do you have any other ideas for features based on this information? Please share your thoughts and questions here. For more info, see our project page.

Thank you! EBlackorby-WMF (talk) 17:27, 24 February 2026 (UTC)

@EBlackorby-WMF Using image carousel to increase the retention rate may not work for a knowledge site like Wikipedia as typically readers would consume the knowledge they want within the same visit and return sometime in the future when there are other content that may interest them. The bell and whistle like image carousel may not be the right component for this purpose.

However, the CTR is encouraging. It shows that the readers may be interested in the content at that moment. I would like to know if there were other metrics tracked, i.e. how many more people scrolled through the page after viewing the image carousel as compared to pages with the carousel? or how many more pages viewed per visit? This would help to paint a more complete picture on the uplift of engagement that the image carousel has during the same visit. – robertsky (talk) 18:23, 24 February 2026 (UTC)

@Robertsky Thanks for the note! We're hoping this next phase of the experiment will allow us to learn to what extent the image carousel (and other aspects of the feature) are useful to Wikipedia readers.

Yes, other metrics were tracked, notably interaction with the feature. 23% of readers who tapped into an image interacted with the feature further, with the most frequent of those actions being tap to see the full image. We think this is a pretty strong indicator of further interest once a user is already curious. I like your ideas for other things to track, do other metrics come to mind? I'll ask the team if they're something we can add to our analysis framework. EBlackorby-WMF (talk) 16:24, 25 February 2026 (UTC)

@EBlackorby-WMF The assumption that you have is that if an user is interested in the images, the user will also be interested in the written content. This assumption may or may not be true and should only be determined after pairing with metrics outside of the immediate component itself.

The two metrics that I gave would have been pretty telling on the effectiveness of the image carousel component on the intended outcome to increase the number of page views. To elaborate the two with a third:

• the number of page scrolls through the pages with vs without the image carousel,

The page scrolls metrics would give further indications that the user are interested not only in the images but also the content written in the article. I am not going into average page percentage scrolled as it would be going into the weeds of why individual content is or is not doing well.

• the number of page views per visit after viewing a page with the image carousel vs those that didn't,

This metric would be immediately telling on increasing user retention within the same visit through the image carousel component. However, I recognise that for this metric, a fairer comparison may only be made after the component is fully rolled out to check also if users drop of after not viewing a image carousel in a subsequent page or not.

• the number of visits and pageviews per visitor after viewing the image component, preferably with subsequent visits being direct visits. Is this more than the average number of of visits per visitor in general?

This would indicate that the actual effectiveness of the image component for the intended outcome, increase pageviews and readership.

– robertsky (talk) 06:08, 26 February 2026 (UTC)

There is much potential there, great to see you're onto it. However, showing just the images that are already included in the article is an approach that's quite limited: these are already included and users could already browse them by clicking on the first/any image and then pressing the next button or also simply by scrolling/glancing over/reading the article.

So I think what you're build so far is a great place to start but it would be more useful if the panel showed also media not featured in the article from the Commons category linked to the article. There often are large amounts of very interesting and/or insightful media there (statistics, high-quality photos, etc) but very few people ever know of and go to the Category page to find these (often also requires looking over the subcategories and navigating further).

Showing files from the category would need to surface the likely interesting / useful ones that are not included in the article and this could be done for example via showing the ones set on the Wikidata item, or other language Wikipedia article versions, or being recognized as 'Quality image'/'Featured picture' etc.

When showing the panel at the top, it could be collapsed by default. It could also be shown at the bottom. And there could be a button to load more from the category and/or to go to the category page.

I think this would make articles more informative and much more interesting to lots of readers depending on the article subject, the situation and click purpose, the reader, and other factors.

For an example of good-quality interesting media files, see e.g. this link.

I'll probably add some more feedback after looking into it further at the project page. Thanks for the developments so far. Is there a way to still try the developed/tested things? For example, I'd like to see if you added a way to jump from an image included in the article in the carousel to the place in the article where it's embedded (or how exactly if that's the third image in the image you attached). Maybe displaying the section title where the image is featured in could be a good idea. And regarding more files from the category maybe it would be possible to have some, basically, 'more like this' button that then retrieves files from somewhere underneath the article's linked category that is similar to that file the user would like to see more of. If it's an image from a study, it would show more files from that study and then files from other studies. If it's a chart it would show more charts in the category (and these are often in a subcat). If it's a photo, it would show more photos etc. Prototyperspective (talk) 01:10, 25 February 2026 (UTC)

@Prototyperspective Thank you so much for this thoughtful comment and all the great ideas in it! We definitely plan to keep testing in the space and will keep these ideas in mind as we do so. To make sure I understand correctly, the main ideas posed here are:

- Showing more related images from Commons on a given article

- Showing more related images from Wikidata categories on a given article

- Giving a collapsible option for the panel at the top/bottom or a load more button

- Displaying section title on the image

Is that right?

Right now we don't have a prototype tester link available but we will loop back if that changes. EBlackorby-WMF (talk) 22:11, 25 February 2026 (UTC)

@EBlackorby-WMF @Prototyperspective There's m:View it! Tool, which does something similar. Not sure how it works, maybe @SuperHamster can tell us more. Ponor (talk) 22:29, 25 February 2026 (UTC)

Oh, neat! Thanks for the ping. Glad to see a native image carousel feature moving forward. Also pinging @Dominic and @JamieF, my collaborators on View it!

View it! uses a Commons custommatch search, "depicts_or_linked_from", to pull and display images that are either marked as depicting (or otherwise linked to) the subject (see wikitech:Search/WeightedTags#Known_tag_families).

I support Prototyperspective's proposal for surfacing more than what's shown on the page (there's a ton of quality media on Commons, and Wikipedia articles tend to display a tiny fraction of it). But as a word of caution, we have to be careful about what we surface if we want to display images via querying Commons. View it! does its job for editors and readers who opt-in, but it surfaces images blindly with no curation or control on what gets displayed and can lead to some...interesting results (as an extreme example, I once visited an article on a programming language and View it! surfaced a photo of nude computer science-themed body art because it was marked on Commons as "depicting" that programming language). The link provided above for "Microscopic images relating to biology" returns lovely results, but the same type of search for [NSFW] "Rust (programming language)" returns a featured picture of partially nude anime art (it's included because it's in the category "Pictures formerly showing a librsvg bug" under Rust). There are probably a number of good ways to ensure what is displayed is actually relevant, such as limiting category depth, ignoring hidden categories, filtering out certain category trees, and only including images from Commons if it's known the subject has a rich library of images available (e.g. not programming languages). Another option is to let editors curate what to include in the carousel (could be a property on Wikidata?). Sort of bringing back curated Gallery sections, which used to be more common across articles but have largely been done away with. ~SuperHamster Talk Contribs 23:06, 25 February 2026 (UTC)

Another option is to let editors curate what to include in the carousel I think this should be an option afforded to the local community editors as well, and not just on Wikidata. The images chosen by non-local community editors may not be acceptable to local community editors and vice versa. For example, for contentious topics like the Arab-Israel area, there would invariably be an edit war at Wikidata to determine the images to present on Gaza war and other languages, predominantly between English Wikipedia and Hebrew Wikipedia. – robertsky (talk) 06:19, 26 February 2026 (UTC)

It sounds like these are rather rare cases. Rare controversy about which images to show isn't a big problem. I don't think more participation on Wikidata by Wikimedia contributors from diverse backgrounds is a bad thing. And there is no evidence for what you claimed, 'edit wars' may or may not happen for this or other topics. On a Wikidata item there usually are just few images set (usually just 1) so it would be just that one image and then additional images from elsewhere, which makes it rather likely diverse views are covered. In your example, these three images are included in the item: 1 2 3 and the panel would show all of them (I think these are good) and then additional ones. Nevertheless, ways to adjust which things to show sound like a good idea – one could have the tool load defaults and then allow users to manually add or remove files to it. For articles that already have lots of images, it makes these accessible at the top; caveats would be articles with only very few images on Commons (may be better to then not show the panel). Whitchurch Silk Mill has 2 images in the article and a map but a good image on the Wikidata item and the Commons category (there you can also see the Wikidata item's image via the infobox). A main point of the tool would be to surface the images for articles like that and users are rather unlikely to manually choose or object to the images' display. Prototyperspective (talk) 15:45, 26 February 2026 (UTC)

I haven’t noticed anything NSFW in View it! (it’s enabled as an opt-in gadget on hrwiki). However, there have been complaints that some benign search terms on Commons return many nude images (see the talk page of a NSFW picture: c:Special:Permalink/1165157366). Make sure that the carousel cannot be manipulated by bad actors. Ponor (talk) 17:00, 26 February 2026 (UTC)

A solution to this issue could be adding a structured data statement to all files underneath c:Category:Nudity and then excluding files with that set (and it could be made possible for Wikipedians to deactivate it for articles that are about NSFW topics). However, you're talking about search terms there; things could be retrieved from Commons categories so the source set of files the ones that shown/loaded are drawn from should exclude most of these (the rest could be filtered away as described). Prototyperspective (talk) 18:17, 26 February 2026 (UTC)

Agreed! Though dumping whatever is in the Commons (deep) categories might still not be the best idea, as they can be full of irrelevant junk. Start with the most used media from the top ~50 connected wikis (excluding the bot-generated ones) perhaps? Ponor (talk) 18:48, 26 February 2026 (UTC)

Sure – definitely not dumping; the idea is smart surfacing of the likely best-quality files. Commons would greatly benefit from such too as outlined here which is some further ideas on that. One of these on how to do that is making Wikipedia uses a factor in the ranking. Files would be shown in order of their quality&relevance-ranking. There's various other kinds of things that could be used such as (as named above) whether it's a featured picture. Adding in some extra images and/or altering the ranking further via which images are used in other language versions of a Wikipedia would be great; and one could also first get the images from there; however especially for ENWP there would often (for most articles) be no images that are used in other versions that are not in the article…and when there are, probably usually just 1 or 2. Additionally, things could work differently for categories that are very large (like 'Art' or 'Society') than those that are relatively or very small (like 'c:Category:Copper(II) sulfate'). For example, in large cats, there would probably enough files in the FP & Quality images subcats and these are also the topics for which one could pull more files from other language versions. Prototyperspective (talk) 19:46, 26 February 2026 (UTC)

Thanks for your feedback; I'll reply just to your questions for now and will leave a separate comment later probably also addressing some things SuperHamster and others said.

Yes, those are more or less the main ideas and suggestions there. However,

• no, probably not Wikidata categories (not sure what you mean with this exactly) but the Wikidata item of the article – especially in non-English Wikipedias, article don't have an image even when 1–10 good ones are set on various Wikidata properties of the article's item (that's one item) such image (P18) and schematic (P5555).
• showing more related images from Commons on a given article works by making use of Commons categories, ways that do not extensively use Commons categories do not work and I'd strongly oppose any such efforts and any such changes.
• it's not a button to collapse the panel or a load more button but ideally both. And optimally, there would be a button to load more (or this is done automatically when scrolling further via lazy-loading / infinite scroll) but also a button to open the Commons category in a new tab.
• For the images that are included in the article, a button to jump to where it's used (and maybe the panel could even stay at the top of the page when jumping) would be great and wasn't in your list – don't know if that's best on or next to the image's section title (btw long titles may need to be trimmed and only visible in full when tapping/hovering over the title).

Thanks! Prototyperspective (talk) 15:10, 26 February 2026 (UTC)

Exciting stuff! The engagement metrics are impressive. Do you have stats on the engagement by topic area (biographies, animals, places, etc.)? I imagine some categories of photos would lead to more engagement (e.g. nice photos of a natural park may be more likely to be explored vs. other categories). ~SuperHamster Talk Contribs 23:39, 25 February 2026 (UTC)

How do I create a list of the pages from this what links here result? Need it to bypass the many pages linking to the dab page with AWB/JWB. 8rz (talk) 02:28, 26 February 2026 (UTC)

AWB can make list from what links here. Izno (talk) 02:44, 26 February 2026 (UTC)

Can JWB as well or only AWB and how would I do it via either one? 8rz (talk) 02:50, 26 February 2026 (UTC)

I do not know how JWB functions. I anticipate its user guide would hold that information if it is possible. I know however that the AWB user guide definitely has this information, so you should seek the answer there. Izno (talk) 03:08, 26 February 2026 (UTC)

@8rz: It does. When setting up your list of pages to edit (Setup -> Page list -> Generate), there is a section for "Links to page". ~SuperHamster Talk Contribs 03:32, 26 February 2026 (UTC)

I don't know exactly how to set it up. I did it the old fashioned way, display 500 pages, select all, copy paste in sandbox and remove (links|edit) with a quick regex replacement. Will probably open a separate talk on WP;JWB to get a better explanation on how to use the "generate list" feature for 500+ 50+ pages, and other options.

So, edits should be made to main namespace (articles only), right? Other namespaces should be avoided, archive subpages, especially. 8rz (talk) 10:55, 26 February 2026 (UTC)

@Izno@SuperHamster, can I fire up a BRFA for the setup I have in here (100+ pages), so I don't have to do it manually? 8rz (talk) 11:17, 26 February 2026 (UTC)

You can, but I do not anticipate a BRFA being approved for anything less than multiple thousands of pages. Izno (talk) 19:27, 26 February 2026 (UTC)

Already done at Wikipedia:Bot requests/Archive 88#Fix disambiguate links after page move. 8rz (talk) 00:06, 27 February 2026 (UTC)

@8rz Have you tried User:Polygnotus/Scripts/ListGenerator2.js? Polygnotus (talk) 11:48, 27 February 2026 (UTC)

Hi, in the "Notes" section of Eastern Europe is the giant red error message "Cite error: <ref> tag in <references> has conflicting group attribute """. I think this is caused by the use of an {{excerpt}} from Eastern Front (World War II), but that page doesn't have the message. I can't see how to fix the error message. Any help appreciated. Thank you, DuncanHill (talk) 18:19, 27 February 2026 (UTC)

@DuncanHill fixed by just removing the extra refs= see this edit. KylieTastic (talk) 19:12, 27 February 2026 (UTC)

@KylieTastic: Thank you, I always struggle with things with refs= in. DuncanHill (talk) 19:21, 27 February 2026 (UTC)

"Not found - The URL you have requested, https://afdstats.toolforge.org/afdstats.py?name=Maile66&max=&startdate=&altname=, doesn't seem to actually exist."— Maile (talk) 19:33, 27 February 2026 (UTC)

It's back up. — Maile (talk) 20:09, 27 February 2026 (UTC)

 You are invited to join the discussion at Wikipedia talk:Copyrights § Paste Check feature - coming next week. That post has details about this upcoming feature, which should help to remind editors (especially newcomers) to think carefully about pasting larger quantities of text, thus hopefully helping to reduce the quantity of copyvio problems. Quiddity (WMF) (talk) 22:02, 27 February 2026 (UTC)

Anyone else getting intermittent 503 messages? I'm not the only one but I can't see any replication lag and there's nothing on the status monitor. That last one changed as I was writing. -- LCU ActivelyDisinterested «@» °∆t° 16:43, 25 February 2026 (UTC)

Yeah it was down for 25 minutes or so for me here. (Latvia) Now its good. Timur9008 (talk) 16:46, 25 February 2026 (UTC)

I had the same result when opening Portal:Current events in a new tab on my Firefox. Achmad Rachmani (talk) 13:26, 28 February 2026 (UTC)

Consider these three edits: 1336969113; 1337163789 and 1340643059. They were all made to Talk:North Africa by three different people. Each edit added a <nowiki>...</nowiki> pair that was, quite simply, completely unnecessary. The tags enclose a normal space character (ASCII 32 dec) with no invisible characters of any kind (such as LRM). In each case, the editor concerned was editing one section, and the nowiki tags were added to a different, unrelated section. Exactly what is going on here, and is it widespread? --Redrose64 🌹 (talk) 00:20, 28 February 2026 (UTC)

Something to do with discussion tools? ~2026-68406-1 (talk) 08:26, 28 February 2026 (UTC)

this is interesting -- the <nowiki>s are added to the same spot every time, it appears, which does make it look like something about that context was prompting their insertion, and it looks like each of the comments was made with discussion tools on mobile, based on the tags. Dirty diffs like this are usually visible in the wikitext "review changes" before they are saved. Can this be reproduced with an arbitrary edit at this location? C. Scott Ananian (he/him) (talk) 21:21, 28 February 2026 (UTC)

https://www.mediawiki.org/wiki/Extension:InlineComments - Could this be installed and enabled -- in draft namespace only? It would help with draft review I believe. I opened a discussion here on the talk page of the Draft review wikiproject, it may take a few days, please be patient.

Outside of draft review I believe the proposal would not affect usage of the wiki.

If consensus is reached there will be necessary to overcome some procedure with WMF to show that this extension is well maintained. Please ignore that issue for now and consider that it was solved; please provide your input based on the extension functionality. I hope this is OK.

Thanks a lot! Gryllida 23:23, 24 February 2026 (UTC)

Installing new extensions on Wikimedia wikis requires an almost impossible process to be followed. * Pppery * _{it has begun...} 23:32, 24 February 2026 (UTC)

reminds me of https://phabricator.wikimedia.org/T355150 — DVRTed (Talk) 23:37, 24 February 2026 (UTC)

Yes, I know. I've berated the people in power over it many many times to no avail. * Pppery * _{it has begun...} 00:02, 25 February 2026 (UTC)

Would you want this one though if it magically was successful for WMF paperwork? Gryllida 04:36, 25 February 2026 (UTC)

The extension seems to be backed by a consultancy firm, WikiTeq, according to the Extension page, and as such may not be a volunteer-led/developed Extension. It would be good to put out some feelers to see if the firm is willing to meet the standards/process set as well as their future plans on sponsoring development or maintaining it.

Separately, I did think of doing an inline commenting system, but it might be a janky piece of software having to store the data outside of enwiki database (possibly in toolforge). – robertsky (talk) 10:14, 25 February 2026 (UTC)

Hi, I'm the author of the extension (I wrote it while employed by WikiTeq for a client of WikiTeq, but I'm not currently employed by WikiTeq. Since the original extension was written, other people have contributed to it as well, in particular User:Yaron_K.). I'd be happy to do additional work on the extension towards deployment should there be consensus towards that and buy in from WMF, however keep in mind that extension was not developed with Wikipedia in mind, so additional work would definitely be needed to make it deployable. Bawolff (talk) 21:28, 26 February 2026 (UTC)

P.S. I think a better near term solution (if there was interest) would be to adapt the extension into a user script/gadget as a prototype. Bawolff (talk) 18:52, 27 February 2026 (UTC)

Good idea, I think this writing of a gadget was mentioned in another wiki also. Gryllida 02:51, 1 March 2026 (UTC)

But it would require newbies writing drafts to install that gadget, so in context of Draft review, can be a bit cumbersome. For use between users of a WikiProject editing a draft who are not complete newbies, that could work rather well. Gryllida 02:53, 1 March 2026 (UTC)

It could eventually be made a default gadget. Assuming people like and want it. –Novem Linguae (talk) 07:05, 1 March 2026 (UTC)

@Gryllida Why are the other annotation mediawiki extensions worse? Polygnotus (talk) 10:25, 1 March 2026 (UTC)

IIIF looks overcomplicated, and SmartComments could also work but is marked as in beta. I will compare on my personal wiki and let you know how it suits the task. Gryllida 12:41, 1 March 2026 (UTC)

ex.

not sure what else to add here ehe..Would appreciate if i got an answer though. Thanks! 203N7HN6 (talk) 15:50, 28 February 2026 (UTC)

I guess this is a question about identifying them. here is a search doing so. Izno (talk) 17:45, 28 February 2026 (UTC)

Global Search can also be used similarly, especially if you want to search across all language Wikipedias. ~SuperHamster Talk Contribs 23:34, 28 February 2026 (UTC)

i think you got me confused. I meant makibfg my user scripts able to notify users occasionally. heres an analogy, a user script that notifies the user with random motivational messages occasionally using the wiki notification API (akin to the notification u get when u save an edit) 203N7HN6 (talk) 11:10, 1 March 2026 (UTC)

You can do mw.notify but you can't use Echo without making an actual edit afaik. Polygnotus (talk) 13:17, 1 March 2026 (UTC)

alright thanks! 203N7HN6 (talk) 14:44, 1 March 2026 (UTC)

They will be able to if T58362 gets merged. Nardog (talk) 14:46, 1 March 2026 (UTC)

Hello. I encountered a rather strange bug on Wikipedia when I tried to create padding in tables using NBSPs. So I've created a test template {{Padding bug}} and you can compare the results here:

{| class="wikitable"
|-
| {{{1|}}} 
| {{{2|}}} 
| {{{3|}}} 
|}

{{Padding bug|A|B|C}}

{{Padding bug
|A
|B
|C
}}

Is there any way to fix this? Can you help me solve this mystery? Thanks, Maiō T. (talk) 08:40, 1 March 2026 (UTC)

There is no whitespace trimming of unnamed parameters. For example, the first parameter is two characters: A and a newline. Using 1=A (a named parameter) would trim any whitespace. Johnuniq (talk) 09:49, 1 March 2026 (UTC)

No, Johnuniq. This template is really crazy. Look at this next example:

Code:

{{Padding bug
|1=A
|2=B
|C
}}

Output:

Maiō T. (talk) 10:30, 1 March 2026 (UTC)

C is the first unnamed parameter according to MediaWiki and overwrites 1=A since only the last assignment of the same parameter counts. I would prefer if the counting continued after the explicit numbers and C becomes the third unnamed in your code but that's not how it works. C has an unstripped newline and it only takes one to force a taller row. The B cell only has B since the newline was stripped. The C cell is also vertically centered but has two lines, one with C and one blank. A common scenario is that the first unnamed parameter contains an equals sign so you have to add 1= to avoid it being interpreted as a named parameter. Then all the following unnamed parameters are forced to also use explicit numbers. It's rather annoying. PrimeHunter (talk) 12:05, 1 March 2026 (UTC)

Okay PrimeHunter. In other words, when creating a template, it is forbidden to add anything after the {{{1|}}} to avoid displaying a new line in the cell. Am I right? Maiō T. (talk) 15:46, 1 March 2026 (UTC)

Whitespace handling in MediaWiki is complicated but in a template like {{Padding bug}} I do suggest to omit &nbsp; around the parameters. Use CSS instead (see Help:Table#Cell content indenting and padding) if you want more cellpadding Then MediaWiki's table code will ignore some forms of whitespace in the caller. The two "Code used in article" in your original post will both give the first result. PrimeHunter (talk) 17:49, 1 March 2026 (UTC)

Maiō T.: The template is doing what you tell it to do. In the second example that you have marked "incorrect", you are telling it: parameter 1 should be the letter A and then a new line. If you want the template to trim that new line away, wrap the parameters in {{trim}} in the template, as I have done in the sandbox:

Code:

{{Padding bug/sandbox
|A
|B
|C
}}

Output:

I hope that helps. – Jonesey95 (talk) 18:26, 1 March 2026 (UTC)

Wow!!! Thank you both, PrimeHunter and Jonesey95. You have been a great help. Two great options for fooling that bug. 😉 Maiō T. (talk) 20:20, 1 March 2026 (UTC)

As you may be able to see from my spam blacklist log, I was trying to add a link, djdave [dot] xyz, to a userspace draft. However it kept getting disallowed? It said xyz was the link that was flagged, so I removed it, and it worked, but when I look at the spam blacklist, I can't see an entry for all .xyz sites or just djdave [dot] xyz. I was directed to MediaWiki talk:Spam whitelist but the instructions there are confusing. Could I have some help? TheTechie^[she/they] | talk? 23:21, 1 March 2026 (UTC)

It appears to have been added in Special:Diff/961623463 after MediaWiki talk:Spam-blacklist/archives/June 2020#h-the whole .xyz TLD-.xyz TLD-2020-05-19T18:41:00.000Z. If you want that site whitelisted, MediaWiki talk:Spam-whitelist is the place to request it. Looking at the instructions there and a glance at the history, as long as you include the relevant information (the specific link, the specific articles you want to use the link on, and why you want it whitelisted), it looks like people will engage with it even if you don't get the formatting exactly right. Anomie⚔ 00:20, 2 March 2026 (UTC)

I see Cyberbot is still working, but it hasn't archived WP:RFPP for quite some time - there's getting to be quite the backlog of processed requests, especially in the "Current requests for edits to a protected page" section, despite multiple entries having the "archive immediately" tag added to them. What's up? - The Bushranger _{One ping only} 01:23, 2 March 2026 (UTC)

Hello! i've been making a not so original user script that identifies common spelling errors. Im almost finished with it so im wondering how to upload it for wikipedia to use and if i need approval from someone first. Thanks! 203N7HN6 (talk) 07:57, 27 February 2026 (UTC)

No. See WP:USERSCRIPT for more details on what is or isn't permissible, but a spellchecking script shouldn't be very controversial, assuming it is used intelligently. Headbomb {t · c · p · b} 08:10, 27 February 2026 (UTC)

thanks! 203N7HN6 (talk) 08:22, 27 February 2026 (UTC)

@203N7HN6 See User:Polygnotus/Scripts/SourcerySpell.js for inspiration. It uses Hunspell. Polygnotus (talk) 11:45, 27 February 2026 (UTC)

im actually kind of new to js so im not sure how to implement other sofwtare in my code ehe 203N7HN6 (talk) 16:04, 27 February 2026 (UTC)

By the way, this (User:203N7HN6/Spellchecker.js#L-42) destroys all event listeners on the page content (breaks WP:Popups, WP:Media Viewer, etc.)

var bodyContent = document.getElementById('bodyContent');
// ...
bodyContent.innerHTML = highlightedHTML;

You could do mw.hook('wikipage.content').fire($("#bodyContent"));, but I'm sure this doesn't fix all other side effects that I can't think of right now. Better to just not replace the entirety of bodyContent's html. — DVRTed (Talk) 13:27, 27 February 2026 (UTC)

ill try to fix it when im available and try to contact you. thanks! 203N7HN6 (talk) 14:43, 27 February 2026 (UTC)

im fairly new to writing js in wp and would appreciate it if you could tell me what im doing wrong (PS: im using my current knowledge and inspect element to write stuff alongside with references from other scripts) 203N7HN6 (talk) 20:29, 27 February 2026 (UTC)

Oh, you're supposed to update the html and fire the hook afterwards. Try this (line 41):

bodyContent.innerHTML = highlightedHTML; 
mw.hook('wikipage.content').fire($("#bodyContent"));

— DVRTed (Talk) 20:43, 27 February 2026 (UTC)

ok thanks! 203N7HN6 (talk) 13:49, 28 February 2026 (UTC)

@203N7HN6, @203N7HN6.. no please don't do either. Use DOM manipulation, not replacing all contents by setting innerHTML. It can break all kinds of expectations of the software. .innerHTML should only be used to create NEW content, not to replace content. —TheDJ (talk • contribs) 08:00, 2 March 2026 (UTC)

@TheDJ You pinged 203 twice I think you meant to ping @DVRTed:. Polygnotus (talk) 08:11, 2 March 2026 (UTC)

I'm sure this doesn't fix all other side effects [...] Better to just not replace the entirety of bodyContent's html. I don't see a reason to ping me... lol. — DVRTed (Talk) 09:48, 2 March 2026 (UTC)

TreeWalker and createTreeWalker(). Polygnotus (talk) 09:12, 2 March 2026 (UTC)

MediaWiki message delivery 17:49, 2 March 2026 (UTC)

requesting exceptional access should link to m:Special:MyLanguage/Wikimedia Enterprise#Access. — Qwerfjkltalk 18:56, 2 March 2026 (UTC)

Is there a problem with toolforge? The bots I reply on, like Hale Bot and DreamRimmer Bot II have not been updating their reports. Thanks for checking. Liz ^{Read! Talk!} 19:15, 2 March 2026 (UTC)

Please request assistance from the bot operators. I suspect, like #categorylinks view in enwiki_p on enwiki.analytics.db.svc.wikimedia.cloud, that these bots rely on categorylinks in this way, but you will need to ask them to verify. Izno (talk) 19:48, 2 March 2026 (UTC)

It didn't seem like a bot problem but a system problem. This is where I come with these questions because editors here know how to create tickets reporting bugs or making inquiries. Sorry if it this displays technological ignorance on my part but I really don't understand how these aspects of the project work and you all seem to be able to look into issues more adeptly than I can. I'm just surprised that I'm often the only person reporting problems when they seem like issues that involve the functioning of bots or scripts that many, many editors rely on.

Also, I did post inquirites on the User talk pages of the bot operators. I just also usually come here as well. Liz ^{Read! Talk!} 04:30, 3 March 2026 (UTC)

Hi everyone, some elements in the family tree under the Family and descendants section aren't perfectly centered. If anyone with more experience could help fix the alignment, I would be very grateful. Thanks! RiadS99 (talk) 01:06, 28 February 2026 (UTC)

I'm not very experienced, but it seems like the way you formatted the tables seems a bit messy and overutilizing '|' (vertical bar). Rhinocratt
c 13:51, 3 March 2026 (UTC)

I don't know if this issue is related the InputBox extension or the MediaWiki software, but the prefix parameter is ignored on the mobile web version of Wikipedia when <inputbox> is used to create a search form. When I enter something into the text field and press Enter, the form acts as if I'm doing a search in the article space. This affects the iOS version of Safari on my iPhone, but there are no issues on the iPad. Ixfd64 (talk) 11:53, 3 March 2026 (UTC)

sounds a bit like phab:T402078? Johannnes89 (talk) 13:43, 3 March 2026 (UTC)

Thanks for linking the ticket. So it's a MediaWiki issue, then. Ixfd64 (talk) 18:19, 3 March 2026 (UTC)

I have no idea what's going on here. Even after the nominator withdrew, the AFD for Ellman's was put back on the page by a bot. Ten Pound Hammer • ^{(What did I screw up now?)} 19:12, 3 March 2026 (UTC)

It's because they didn't remove the template that says {{REMOVE THIS TEMPLATE WHEN CLOSING THIS AfD}}. I fixed it. SuperPianoMan9167 (talk) 20:09, 3 March 2026 (UTC)

The article 2022 European Curling Championships doesn't collapse in mobile view. I've tried to figure out why, but with no luck. It seems that this edit somehow is to blame (when I go through the revision history, it's from this revision onwards the collapse function won't work), though the edit looks completely normal. I've used my sandbox to try to find the solution, and it seems to have something to do with adding more nation templates, like {{CZE}}, to the page. Is there an upper limit to how many templates av this type that can be included in an article before problems like this one are caused?

I've earlier tried to get help with this subject on my own talk page, see User talk:Marima#Help me!. I hope someone more tech savvy than I can help me find the solution! Marima (talk) 12:01, 3 March 2026 (UTC)

IIRC, once there are sufficient images on the page, the mobile site turns off its collapsing. Those templates like {{CZE}} each add a flag image. Anomie⚔ 13:35, 3 March 2026 (UTC)

Yes, this would be the cause of it. Izno (talk) 17:57, 3 March 2026 (UTC)

The limit is 1000 images: phab:T232690. 2022 European Curling Championships currently has 1057 so it's not far off. File:Font Awesome 5 solid hammer.svg occurs 183 times so changing this indicator to a character would more than solve it. Maybe men and women should have separate articles anyway for length reasons. PrimeHunter (talk) 18:27, 3 March 2026 (UTC)

I replaced the image with "🔨". --Ahecht (TALK
PAGE) 19:21, 3 March 2026 (UTC)

Big thanks for the explanation and the measure taken! Marima (talk) 22:18, 3 March 2026 (UTC)

Hello there, I'm a mobile editor on Wikipedia. I would like to use twinkle mobile and it isn't working. I currently use a very watered down version of twinkle as a gadget. Thank you for your time. Dafootballguy (talk) 23:28, 3 March 2026 (UTC)

I would suggest leaving a message at User talk:Plantaest/TwinkleMobile. SuperPianoMan9167 (talk) 23:48, 3 March 2026 (UTC)

Is it my imagination or has the cl_to column just vanished from the categorylinks view in the analytics database? It's still there for enwiki.web.db.svc.wikimedia.cloud. Sean.hoyland (talk) 17:37, 2 March 2026 (UTC)

Not your imagination; it had been deprecated for a while. phab:T299951. —Cryptic 17:43, 2 March 2026 (UTC)

Interesting. Thanks. Now I'm realizing that I don't really understand the relationships between page, category and categorylinks in a world without the cl_to column... Sean.hoyland (talk) 18:14, 2 March 2026 (UTC)

The titles that were in cl_to are now in the linktarget table, with cl_target_id as a foreign key to the appropriate row. See Special:Diff/1341322401 for a practical migration example. —Cryptic 18:26, 2 March 2026 (UTC)

Ah. Thanks very much. It also solves the mystery of what cl_target_id was pointing at... Sean.hoyland (talk) 04:08, 3 March 2026 (UTC)

The removal was also announced on the cloud-announce mailing list. Anomie⚔ 03:44, 3 March 2026 (UTC)

I guess over 50 database reports will stop working in the coming days. – DreamRimmer ■ 19:03, 3 March 2026 (UTC)

User:Cryptic has been fixing them. They fixed a few of mine. Thanks, Cryptic! – Jonesey95 (talk) 20:42, 3 March 2026 (UTC)

The {{database report}}-based ones are easy to find, since they show up in Category:SDZeroBot database report failures. I've only been taking care of queries I've worked on before, though, plus actual subpages of WP:Database reports - I figure the ones in userspace will be dealt with by their creators, if their owners are still paying attention to them. What's going to be more problematic are the bespoke bot reports and one-off queries on Quarry and such.

On that note, Jonesey95, could you do something about User:Jonesey95/Polluted categories? It's been the only page in the failures category for a long time now other than the recent flood, and the way it's set up it's basically never going to complete in anywhere near the bot's max time limit. —Cryptic 01:24, 4 March 2026 (UTC)

Blanked. Thanks for the reminder. That was a failed experiment to try to help Bearcat by creating a daily report. – Jonesey95 (talk) 02:21, 4 March 2026 (UTC)

Indeed. If I recall correctly, the regular report broke sometime last year or the year before (don't recall exactly) but its maintainer happened to be away from Wikipedia on vacation, so that report was created as a temporary workaround until they got back and could fix whatever had gone wrong with the regular one. Bearcat (talk) 02:51, 4 March 2026 (UTC)

At least 20 reports from HaleBot will break soon. I have pinged the operators below to see if they have time to fix the queries. I can help update the configuration on the report subpages, but the remote versions will also need to be updated. – DreamRimmer ■ 02:53, 4 March 2026 (UTC)

HaleBot has code that, in theory, keeps it from running when the report page transcludes {{database report}}, but I haven't tried migrating any more queries after it went ahead and overwrote Wikipedia:Database reports/Empty categories. (Though I see now there's a current attempt to steal it back again.) —Cryptic 03:07, 4 March 2026 (UTC)

@Cryptic: sorry! That report is a bit special and was bypassing the skip code. I'm fixing that now, it shouldn't affect any other reports.

Ideally at this point the only reports HaleBot continues to run are those that SDZeroBot can't because they're too complex or take too long. Legoktm (talk) 03:29, 4 March 2026 (UTC)

I had my IP banned for inventing a crawler to download Vital articles level 4 as text files, with the intention to print it and bind books. I have read different opinions on spiders on different pages, from don't use them at all to use them on off-hours with a sleep between queries of 60s. I would be totally fine with doing this and I didn't realise this would be a problem as I didn't see the guidelines before being banned. I'm sorry for any trouble this may have caused and I didn't realise I was doing something wrong. If Wikipedia is 100% against spiders maybe you would release the Vital articles as their own downloadable packages? Nellas Galadhon (talk) 01:54, 4 March 2026 (UTC)

We did not do that. The WMF might have, see mw:Wikimedia APIs/Rate limits. Please correct the issues that are likely present in your downloading script as a result of the change in API rate limits and then if that doesn't fix the problem get in contact with the WMF using phab:. Izno (talk) 02:42, 4 March 2026 (UTC)

@Nellas Galadhon Also see https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access --Ahecht (TALK
PAGE) 17:58, 4 March 2026 (UTC)

@Nellas Galadhon When making automated requests to the web site or APIs, please always make sure to follow the Robot policy. Note in particular the requirement to set a compliant User-Agent header to help avoid being blocked. It's not clear from your message what the error is, but I suspect it might just be that.

@Izno The API rate limits have not yet gone into affect, the first phase will be rolled out end of next week. JTweed-WMF (talk) 14:46, 5 March 2026 (UTC)

Thanks for your help.I only really discovered the robotic agreement once I started having error by then.It may have been too late.I'll try to implement what you suggested ~2026-14281-92 (talk) 14:52, 5 March 2026 (UTC)

@JTweed-WMF Ok, I linked the wrong help page and I know the other exists. Maybe you should ensure those are well connected. Izno (talk) 17:18, 5 March 2026 (UTC)

If somebody understands how to, can you please fix the "MAGA Inc." not to appear as link in this section (I tried using the {{#section}} template but didn't get it to not self-link that): Make America Great Again Inc. # "Pay-for-Access" Or does use of Template:No self link make sense here? D4n2016 AMD  RYZEN  ZEN 3 user Talk 03:02, 6 March 2026 (UTC)

{{No self link|MAGA Inc}} fixed it. PrimeHunter (talk) 03:28, 6 March 2026 (UTC)

I feel certain that there have been discussions at Turkish Roma of the terminology used to discuss the group that's the article's topic, and possibly even a prior move discussion. Following a move war that I hope I just put an end to, the article's back at Turkish Roma, where it has been since September 2022, but the talk page has nothing but WikiProject banners on it. Did something get lost somewhere during or before the move war? I can't figure out where to look. Largoplazo (talk) 23:22, 5 March 2026 (UTC)

Are you sure there were in fact any such discussions? DS (talk) 00:48, 6 March 2026 (UTC)

OK, never mind, I found what I'd been thinking of. It did include discussion of naming with respect to Turkish Roma in particular, but it was an overall more general discussion, a move discussion that's now at Talk:Romani people/Archive 13. Largoplazo (talk) 01:11, 6 March 2026 (UTC)

I'm not sure if this is what you were looking for: Talk:Turkish Romani. I used the Special:PrefixIndex/Talk:<page> on existing redirects in case some archive subpage was not moved and I didn't locate one, but have noticed this. ~2026-10830-00 (talk) 01:19, 6 March 2026 (UTC)

It appears there was a WP:HISTMERGE given the oldest revision is a move from Turkish Romanian to Turks of Romania yet the next is a move from Turkish Romanian to Turkish Romani 14 years later. Nardog (talk) 03:51, 6 March 2026 (UTC)

I noticed those long-ago moves while going through this but didn't take the time to investigate. The move from "Romanian" to "Romani" seems suspicious, unless the situation was that the article was written by someone who didn't the difference in English between Romanians and Romani and had used the wrong term, followed by someone fixing it. I'll try to take a look later if curiosity gets the better of me. Largoplazo (talk) 13:19, 6 March 2026 (UTC)

Hello. I'm testing something with templates and subtemplates, #switches and #ifs, (not on en:wiki, sorry) and then when I use a parameter like this |color=#ccffcc in an article, it doesn't appear as the lightgreen cell background, but as follows:
style="background:

1. ccffcc;"

I think my code is pretty good because when I use, for example |color=green, everything is fine. Parameter |color=#ccffcc also works, but that's not the solution I want. Do you know of any trick to fool that strange hashtag? Thanks, Maiō T. (talk) 17:44, 6 March 2026 (UTC)

@Maiō T.: You didn't name the wiki but here we have {{Encodefirst}}. PrimeHunter (talk) 17:52, 6 March 2026 (UTC)

Thank you very much PrimeHunter. I've created an Asturian version of the Module:MultiReplace and use it directly as such. Maiō T. (talk) 21:54, 6 March 2026 (UTC)

Hi! Why is this in the URL, when I visit an article from the Wikipedia-Search? E.g. https://en.wikipedia.org/wiki/Wikipedia?wprov=srpw1_0. Habitator terrae (talk) 18:03, 6 March 2026 (UTC)

@Habitator terrae: It's a tracking parameter so MediaWiki knows how you came to the article. It can for example be used to make statistics about how articles are reached. I don't get it in my searches so maybe you are in a group selected for an experiment. Thanks for deactivating the link. It may tarnish an experiment if many people follow the link without coming from search. PrimeHunter (talk) 18:20, 6 March 2026 (UTC)

See Provenance for the technical details of the tracking and what the values mean. Legoktm (talk) 22:02, 6 March 2026 (UTC)

I have custom user styles that decorates the interface with images hosted elsewhere. However, even after user scripts were re-enabled after the incident, the images are still not loading. What can be done? My user styles' code can be accessed at User:PrincessPandaWiki/common.css and User:PrincessPandaWiki/vector.css. ❤︎PrincessPandaWiki (talk | contribs) 17:06, 6 March 2026 (UTC)

Yes, these are due to the CSP that has been enabled as a result of yesterday (but which was coming regardless). Your only recourse is to request these websites be allow-listed on phab:. I do not anticipate your success given the specific domains of interest. Izno (talk) 17:11, 6 March 2026 (UTC)

Cursors, "wavei", logo and other small images can be converted data: URIs. There are multiple online tools to do so, e.g. https://onlinetools.com/image/convert-image-to-data-uri. sapphaline (talk) 21:03, 6 March 2026 (UTC)

Or you can load the stylesheet through a browser extension (Stylus, Greasemonkey, etc.). sapphaline (talk) 19:04, 6 March 2026 (UTC)

Redacted the above examples of encoded images because they made the page unnecessarily long. Check history if you're interested. --SarekOfVulcan (talk) 19:27, 6 March 2026 (UTC)

Can't check history, they were revdelled. --SarekOfVulcan (talk) 20:59, 6 March 2026 (UTC)

Are those images copyvios? Probably should be revdelled. If they really are freely licensed, they can be uploaded to Commons instead. Suffusion of Yellow (talk) 19:29, 6 March 2026 (UTC)

There are no images in my message. sapphaline (talk) 19:37, 6 March 2026 (UTC)

Are you kidding? You literally posted over 50KB of base64-encoded images. --Redrose64 🌹 (talk) 19:51, 6 March 2026 (UTC)

Yes, there are. A data:image/png; URI is not a link to an image, it is an image. There's little use for a data: URI except perhaps to speed up page loads. Just upload the image, then point your CSS to upload.wikimedia.org. If uploading isn't allowed for copyright reasons, then base64 encoding obviously won't make it freely licensed. Suffusion of Yellow (talk) 19:52, 6 March 2026 (UTC)

I recently had to convert images in several of my user scripts/css to data URIs after WMF restricted the sizes of thumbnails they would serve. Seemed better than uploading "same image but 10px" copies of things. Anomie⚔ 08:23, 7 March 2026 (UTC)

Fixed. sapphaline (talk) 19:37, 6 March 2026 (UTC)

I've removed the likely copyvios from your sandbox and revdelled them. Other admins have revdelled the previous postings to this page. SarekOfVulcan (talk) 20:58, 6 March 2026 (UTC)

Has anyone bothered search all Wikipedia's for more naughty scripts, e.g. scripts that contain the string "nuke" or "action=delete"? Also scripts with obfuscated stuff like percent encoded stuff. Polygnotus (talk) 16:35, 6 March 2026 (UTC)

There are about 40 such scripts on English Wikipedia containing the word nuke. You may consider global search if you want to review others. Izno (talk) 17:15, 6 March 2026 (UTC)

@Izno Thanks! But it looks like I can't use global search to detect percent encoded Javascript by searching for the percent encoded versions of strings commonly found in Javascript (like var and let). Do you happen to know how to do that? SQL? Looping over each endpoint using insource:? Polygnotus (talk) 17:29, 6 March 2026 (UTC)

If it is well-obfuscated I doubt any straightforward search will find it. — Qwerfjkltalk 12:14, 7 March 2026 (UTC)

@Qwerfjkl True, but in this case it wasn't. This wasn't very sophisticated. Polygnotus (talk) 12:15, 7 March 2026 (UTC)

I've noticed on several sidebar templates that black text becomes white in dark mode, even if the template has color:black set in its style parameters. Adding the class skin-invert inverts everything except the text, which stays white. Adding class mw-no-invert instead has no effect, and the text is still white. Adding {{black}} directly to the title/heading makes it black, but adds a white background because for some reason that template also uses background: white.

An example of such a template is {{Tibetan Buddhism sidebar}}, where the white headings are difficult to read in dark mode because the background is light.

Is there a way to fix this without throwing out their styles and making every sidebar use dark background or stripping it down to the default so dark mode works as intended? Given {{black}} somehow accomplishes making the text black when the background is white, surely this is possible? Or does it only work with white? Would this require changing something about how dark mode itself is implemented to fix? – Scyrme (talk) 08:40, 6 March 2026 (UTC)

The mw-no-invert class isn't part of the dark mode that is available in the default skins, as indicated on top of the page of the extension that uses that class. I would recommend to follow-up the instructions on mw:Recommendations for night mode compatibility on Wikimedia wikis instead. Sjoerd de Bruin (talk) 08:44, 6 March 2026 (UTC)

@Sjoerddebruin: Copying pane notheme mw-no-invert from the "good example" listed there seemed to work. However, I also found that notheme by itself worked. Do you happen to know why the other two classes are included? I'm particularly unsure what pane is for. – Scyrme (talk) 09:09, 6 March 2026 (UTC)

Using color:var(--color-base,#202122); instead of color:black often has the desired effect. – Jonesey95 (talk) 14:25, 6 March 2026 (UTC)

Thanks for the suggestion. Unfortunatey, I gave it at try in an older revision of {{Tibetan Buddhism sidebar}} from before I changed its class to override dark mode, and it had no effect on the list title headings. They were still white on yellow and hard to read. I replaced every copy of color:black in every parameter just to be sure, but it still didn't do anything. I also then tried changing #202122 to #000000, in case setting it to pure black made a difference somehow. Still no luck. – Scyrme (talk) 02:00, 7 March 2026 (UTC)

I don't understand the magic that happens that sometimes makes the above code do the right thing and sometimes not, apparently depending on the lightness or darkness of the background color. color:var(--color-base-fixed,#202122); is sometimes necessary to prevent text from turning white in dark mode. I don't know if the developers just didn't create enough test cases, or if there is something I don't understand (probably both, with the emphasis on the latter). – Jonesey95 (talk) 13:28, 7 March 2026 (UTC)

In addition to the styles you see in various places over here, there are styles sitting on top of everything that come with the software itself, see here. Ponor (talk) 10:30, 6 March 2026 (UTC)

Sidebars are unaffected by anything in the relevant CSS. Izno (talk) 17:19, 6 March 2026 (UTC)

{{sidebar}}s support |templatestyles= and should use that as a solution if you want to guarantee them to appear a certain way. (There is a category for someone who wants to convert styles to TemplateStyles but personally it is the lowest of any low priorities.) Izno (talk) 17:18, 6 March 2026 (UTC)

I had wondered if converting would help, but I'm not familiar enough with .css to be comfortable attempting a conversion. I'm also not sure if it'd be effective. It looked like it the styles.css approach would still just use color:black. Is it processed differently in some way? Has anyone attempt it who can confirm the conversion works for fixing this issue? – Scyrme (talk) 02:10, 7 March 2026 (UTC)

en:Pozzato and it:Pozzato are essentially the same. The overlap isn't complate, but they're both surname pages. On attempting to create an Interwiki link in either direction, I get the error messge "Could not link pages: failed to merge corresponding Items on Wikidata. Attempted modification of the Item failed." in the en:it direction and "The save has failed. The link enwiki:Pozzato is already used by Item Q56245816. You may remove it from Q56245816 if it does not belong there or merge the Items if they are about the exact same topic. If the situation is more complex, please see Help:Sitelinks." Can anyone resolve this silly problem? I have zero interest in learning how to do this trivial piece of useful housekeeping.Narky Blert (talk) 19:44, 5 March 2026 (UTC)

I added it manually. No issue reared its head. BD2412 T 20:04, 5 March 2026 (UTC)

Thanks, BD! A rant may follow. Narky Blert (talk) 17:21, 7 March 2026 (UTC)

@Narky Blert: The English article is linked to the Wikidata item for the family name, whereas the Italian is linked to the one for the disambiguation page. Per the "different from" statement, "family name has to use a different item than disambiguation page". This mutually exclusive criterion is probably why the merge failed.

Per WP:SETNOTDAB, the English article should not be moved to the Wikidata item for the disambiguation page. The Italian article is categorised as Pagine di disambiguazione, so also seems to be at the right item. I'm unsure if the Italian Wikipedia has the same distinction between set indices and disambiguation pages. Wikipedia:Set index articles and {{Set index article}} don't appear to have versions on the Italian Wikipedia (or if they exist, they don't share a Wikidata item). – Scyrme (talk) 20:15, 5 March 2026 (UTC)

The incident has been resolved. It is now safe to access MetaWiki. User scripts have been re-enabled.

Meta-Wiki is compromised. DO NOT ACCESS it with JavaScript enabled or without [?&]safemode=1. Nardog (talk) 15:31, 5 March 2026 (UTC)

The issue is being looked into. See the status page for updates. ~Oshwah~^{(talk) (contribs)} 17:10, 5 March 2026 (UTC)

Wikimedia sites were in read-only mode after the incident. Editing is back but user scripts appear to be disabled. A hacker apparently used a compromised account to load sitewide JavaScript at meta. The script made malicious edits with the accounts of users who visited meta with JavaScript enabled. PrimeHunter (talk) 17:12, 5 March 2026 (UTC)

Another hacker with Russian as their language of choice, I see. Cremastra (talk · contribs) 17:17, 5 March 2026 (UTC)

I can confirm that the user scripts that I load in my personal .js file appear to be disabled here on the English Wikipedia. This seems like an outage that would merit a sitewide notice of some kind. Maybe it's enough to have a topic here on VPT. – Jonesey95 (talk) 17:18, 5 March 2026 (UTC)

Yeah, it seems as if someone force-enabled safe mode for all sites when this happened. SuperPianoMan9167 (talk) 17:21, 5 March 2026 (UTC)

I'd say they're rightfully more concerned about the attack than user experience at the moment. FaviFake (talk) 17:22, 5 March 2026 (UTC)

+5,000,000,000 Security is way more important than me being able to look at WP:VPT with #F0FFF0 as the background color. mdm.bla 17:23, 5 March 2026 (UTC)

Someone added a watchlist notice in the meantime. --Joy (talk) 18:15, 5 March 2026 (UTC)

Cremastra, Another hacker with Russian as their language of choice, I see. That strongly suggests it wasn't the Russians. — Alexis Jazz (talk or ping me) 21:29, 6 March 2026 (UTC)

And did I say anything about the actual origin of the malicious script? No. I certainly don't think the Russians are bothering to hack Wikipedia. Cremastra (talk · contribs) 21:44, 6 March 2026 (UTC)

And did I say anything about you saying anything about the actual origin of the script? No. — Alexis Jazz (talk or ping me) 04:34, 7 March 2026 (UTC)

It does make me think that custom JavaScript should go through some approval process like device drivers for operating systems, and anything not on a whitelist of verified, tested and approved code doesn't run at all. Ritchie333 ^{(talk) (cont)} 17:14, 5 March 2026 (UTC)

I think a maybe simpler intervention would be that code from someone's userspace cannot take any actions that author could not take. For example, if a page mover writes a userscript in their userspace and I install it, and their script is then compromised, they might be able to mess with my page-moving ability, but they couldn't do anything worse. If someone wants a script to be exempt from these requirement, get an intadmin to move it into MediaWiki space and then it'll only be editable by intadmins. theleekycauldron (talk • she/her) 21:29, 5 March 2026 (UTC)

That would be impossible to enforce technically. Socially, we could have a rule like "admins are prohibited from importing scripts from non-admins" but I suspect that would lead to a lot of copy-pasting, which, for the reasons discussed here, might be worse. Suffusion of Yellow (talk) 21:51, 5 March 2026 (UTC)

I think it's not unreasonable to want a software change ot get a workable solution here, but hopefully there's a workable solution that doesn't require that. theleekycauldron (talk • she/her) 22:09, 5 March 2026 (UTC)

There isn't a software change that can "selectively" control what a script can and cannot do. As far as the browser knows, a "user" script is just another part of the site, and can do whatever it wants. You either import it or you don't. I suppose you could run the script in an iframe sandbox, but then it would live in its own little world, unable to even interact with the page. Suffusion of Yellow (talk) 22:24, 5 March 2026 (UTC)

The software can disallow editing site-wide javascript without reauthenticating, which should prevent a script from doing so non-interactively (especially since intadmins have 2FA enabled). --Ahecht (TALK
PAGE) 23:11, 5 March 2026 (UTC)

Yeah, but there's no way to say "Scripts from User:Trusted are allowed to do this, but scripts from User:LessTrusted can only do that..." Suffusion of Yellow (talk) 23:29, 5 March 2026 (UTC)

I mean, my understanding is that the browser knows the source of the import, and has to make an API call to take an action on behalf of the user; can't the API backend do a permissions check based on the permissions of the author of the source (i.e. whichever user is hosting the subpage of the userscript)? theleekycauldron (talk • she/her) 23:13, 5 March 2026 (UTC)

The API backend has no idea which script is performing the request, unless it provides that information voluntarily (e.g. with Api-User-Agent). Which is good practice in case of an accidental DoS, but obviously a malicious script can just provide fake information. Suffusion of Yellow (talk) 23:35, 5 March 2026 (UTC)

(this would not extend to blocks, but an intadmin should have an option to disable all userscripts a person has authored in blocking them.) theleekycauldron (talk • she/her) 21:31, 5 March 2026 (UTC)

See also MEGATHREAD Wikimedia wikis locked / Accounts compromised FaviFake (talk) 17:19, 5 March 2026 (UTC)

The malicious code has since been deleted. Some discussion at T419143. According to @MBH, @SBassett (WMF) added the script, causing this whole thing.

I have a copy of the code, if someone wants to take a look I can send it their way. JayCubby 17:25, 5 March 2026 (UTC)

Wait. What exactly happened? Did someone hack Meta-Wiki? VidanaliK (talk to me) (contributions) 17:25, 5 March 2026 (UTC)

we have to send someone to the WP:STOCKS for this, but who? ltbdl (operate) 17:25, 5 March 2026 (UTC)

Are you sure it was a well-intentioned Wikipedian that accidentally inserted "malicious code"? VidanaliK (talk to me) (contributions) 17:27, 5 March 2026 (UTC)

It seems more likely the account was hacked. It loaded a malware script stored at the Russian Wikipedia. There was no apparent reason to think it would be a good idea to load the script sitewide at meta. I don't know how the account was compromised but being hacked (even with a high-permission account) is not usually grounds for the stocks. Maybe if they had a ridiculously easy password. PrimeHunter (talk) 17:41, 5 March 2026 (UTC)

Actually, they may have loaded the script deliberately in their personal js and then the script used the account to change sitewide js. PrimeHunter (talk) 17:44, 5 March 2026 (UTC)

Nope, it seems he was testing userjs loads and he just imported a ton of random scripts, see FaviFake (talk) 17:49, 5 March 2026 (UTC)

I'm definitely glad the wiki was in read-only mode by the time I logged on. Wait, if I had the "Keep me logged in for one year" might something have happened? What did the code even do? VidanaliK (talk to me) (contributions) 17:47, 5 March 2026 (UTC)

"What did the code even do?" - here's the user script and here's what was inserted into hacked users' common.js. Unfortunately I can't fully explain the user script, but in the second script the only relevant lines are 1-5, everything other than that is just a filler. sapphaline (talk) 18:00, 5 March 2026 (UTC)

Ahecht responded here. VidanaliK (talk to me) (contributions) 18:02, 5 March 2026 (UTC)

Scott Bassett (User:SBassett (WMF), the WMF's "Staff Security Engineer" JayCubby 17:27, 5 March 2026 (UTC)

 Done, see Wikipedia:Village stocks#Scott Bassett for the Закрываем проект award mdm.bla 17:51, 5 March 2026 (UTC)

So this is why I was logged out? Οἶδα (talk) 17:29, 5 March 2026 (UTC)

In 2023, vandal attacks was made against two Russian-language alternative wiki projects, Wikireality and Cyclopedia. In 2024, ruwiki user Ololoshka562 created a page ru:user:Ololoshka562/test.js documenting the script used in these attacks. It was inactive next 1.5 years. Today, sbassett massively loaded other users' scripts into his global.js on meta, maybe for testing global API limits: . In one edit, he loaded Ololoshka's script: and ran it. Source: https://phabricator.wikimedia.org/T419143 FaviFake (talk) 17:31, 5 March 2026 (UTC)

More info about previous attack is on n:ru:Википедия по ошибке сотрудников фонда Викимедиа была взломана хакерами MBH (talk) 17:36, 5 March 2026 (UTC)

So it was basically putting "Cyclopedia" onto every page on Wikipedia? What was Cyclopedia? How did they get access to SBassets account? VidanaliK (talk to me) (contributions) 17:57, 5 March 2026 (UTC)

It was a complete accident. SBasset was randomly importing user scripts, probably for testing, and just so happened to load a malicious one. SuperPianoMan9167 (talk) 17:59, 5 March 2026 (UTC)

• Wait.. was this a Chernobyl where the testing of a potential fault caused it to go critical? -- GreenC 17:54, 5 March 2026 (UTC)

FWIW that page has now been oversighted and the account globally locked. JavaHurricane 18:52, 5 March 2026 (UTC)

I linked to the scripts' source codes earlier in this discussion, if anyone is interested. sapphaline (talk) 18:57, 5 March 2026 (UTC)

@FaviFake I don't buy that Ololoshka562 was just documenting the script used in these attacks, as the script had a hardcoded check to not run from accounts with the username "Ololoshka562". --Ahecht (TALK
PAGE) 19:37, 5 March 2026 (UTC)

How would they know that this would be the end result? Did they know their script would be loaded? I'm not too sure. It feels more like a coincidence that script ended up being run rather than an intentional attack. Cutlass^Ciera 19:43, 5 March 2026 (UTC)

Maybe, but the script was modified so that if it were run, it would never run on the account that uploaded it. It wasn't a simple "here's a script someone else wrote on another wiki" situation. --Ahecht (TALK
PAGE) 23:13, 5 March 2026 (UTC)

So this is why it was in "read-only mode"? VidanaliK (talk to me) (contributions) 17:32, 5 March 2026 (UTC)

Yes, they shut wikipedia down to prevent the malicious javascript from spreading. FaviFake (talk) 17:35, 5 March 2026 (UTC)

The malicious code would also WP:NUKE all of the user's contributions as many pages as possible on each page load, so it was set to read-only to prevent further damage. --Ahecht (TALK
PAGE) 17:58, 5 March 2026 (UTC)

Possibly useful context: User:NYKevin/Interface administrators and trusting trust. --NYKevin 17:39, 5 March 2026 (UTC)

However, you can put arbitrary JavaScript code on that page, and it will run on every page load when you are logged in. Since the attacker can force you to take actions without being aware of it, they can install malicious JavaScript on your personal common.js page, and continue to manipulate your account even after the attack has been removed from the sitewide JavaScript. There's nothing stopping an attacker from doing this to literally everyone who has ever been impersonated. Or, if that's too obvious, they could do it to a very small selection of high-privilege accounts, and hope that the community does not notice.

concerning... Οἶδα (talk) 17:47, 5 March 2026 (UTC)

Does this factor into why I cannot load external images for my user styles? I liked browsing Wikipedia with Sonic Riders images in the background. ❤︎PrincessPandaWiki (talk | contribs) 17:49, 5 March 2026 (UTC)

Yup, see https://www.wikimediastatus.net/. Monitoring - A fix has been implemented and we are monitoring the results. Some editing functionality will still be disabled. FaviFake (talk) 17:51, 5 March 2026 (UTC)

Can someone explain what the Scott Bassett-uploaded code was doing? Wait, was that the code that shut down editing for an hour? VidanaliK (talk to me) (contributions) 17:54, 5 March 2026 (UTC)

@VidanaliK It would install itself in both the user's common.js as well as the site-wide common.js, and then WP:NUKE the user's contributions. This means that all users visiting the site would get infected, and any attempts to remove it from the site's common.js would automatically get reverted by users that still have it in their personal common.js. --Ahecht (TALK
PAGE) 18:01, 5 March 2026 (UTC)

So it would basically delete every single person's contributions if they logged on with JS enabled, and make it impossible to remove the script? Is that why the edit summaries were Закрываем проект (Closing the project)? VidanaliK (talk to me) (contributions) 18:04, 5 March 2026 (UTC)

@VidanaliK: Actually, I read it wrong. It would just do a blank Nuke in namespaces 0, 1, 2, and 3 on every page load, which would delete 500 random pages from each namespace. --Ahecht (TALK
PAGE) 18:11, 5 March 2026 (UTC)

So would it do that over and over again for a bunch of admins? VidanaliK (talk to me) (contributions) 18:11, 5 March 2026 (UTC)

Wait, what are namespaces 1 and 3? I don't see that on WP:NAMESPACE. VidanaliK (talk to me) (contributions) 18:12, 5 March 2026 (UTC)

They're in the floating table (1 = "Talk", 3 = "User talk"). sapphaline (talk) 18:13, 5 March 2026 (UTC)

Odd-numbered namespaces are for talk pages. 1 is Talk: and 3 is User talk:. mdm.bla 18:14, 5 March 2026 (UTC)

Wait, so after only 15,000 page loads every page on the English Wikipedia would be gone... VidanaliK (talk to me) (contributions) 18:15, 5 March 2026 (UTC)

The code as dormant for 1.5 years until he started massively adding userscripts to his global.js page to test its limits. One of these edits imported the malicious code and it worked because he had enough privileges. See Wikipedia:Village stocks § Scott Bassett for the Закрываем проект award FaviFake (talk) 18:03, 5 March 2026 (UTC)

The meta version of MediaWiki:Common.js was edited to load a malicious script which made bad edits from the accounts of innocent users. MediaWiki:Common.js automatically runs for all users of the wiki with JavaScript enabled which is nearly all users. All wikis were put in read-only mode by the Wikimedia Foundation to prevent spreading and investigate what was happening. MediaWiki:Common.js can be edited by a limited number of trusted users, some with global permissions for all Wikimedia wikis, and local Wikipedia:Interface administrators (we have 15). Normal administrators cannot edit it (they could years ago). PrimeHunter (talk) 18:07, 5 March 2026 (UTC)

A good argument for the next "please enable Javascript" debate, it seems... ~2026-10830-00 (talk) 17:57, 5 March 2026 (UTC)

For the time being, I'd recommend to install Greasemonkey and import everything there. Unfortunately scripts which rely on jquery won't work with this approach. sapphaline (talk) 18:17, 5 March 2026 (UTC)

I was wondering why the gadgets like DYK Check, Cite Unseen, etc. are not working. Just came to know this, sad! M. Billoo 18:23, 5 March 2026 (UTC)

Can't wait for the mainstream media to mention the incident. Ahri Boy (talk) 18:26, 5 March 2026 (UTC)

"Wikipedia gets hacked by administrator!" Pretty much every outlet criticising Wikipedia for all the world's problems (plus the teachers for which it is heresy to even say the word "Wikipedia") is going to have a field day with this. The question is, how do they get their reports? Do they go to a page called Village pump (technical) searching for the tiniest incident of something weird happening with Media-Wiki? VidanaliK (talk to me) (contributions) 18:31, 5 March 2026 (UTC)

Yes, they do. They also do it with all other village pumps, ANI, Wikipedia:Requests for comment/All, etc. sapphaline (talk) 18:34, 5 March 2026 (UTC)

They'll find out when the WMF puts out a statement, which I'm sure they will do. Most media doesn't troll projectspace. voorts (talk/contributions) 18:35, 5 March 2026 (UTC)

At least Reddit thread covered the incident. I guess only time will tell mainstream media will disseminate statement from the WMF. Ahri Boy (talk) 03:09, 6 March 2026 (UTC)

tiniest incident

? This was a major outage! FaviFake (talk) 18:35, 5 March 2026 (UTC)

It could be a fun story for the general public. The media may omit some details like the WMF/Wikipedia/meta distinction: A security engineer working for Wikipedia decided to run a large number of random unexamined scripts to see what would happen. He found out. He did it with his high-permission account which could infect every user if a single of the random scripts was bad. It was. PrimeHunter (talk) 18:46, 5 March 2026 (UTC)

This is better:

On Thursday a Wikimedia security engineer ran several scripts on the Wikimedia server without examining the code to check for malware. One of the scripts was a malicious program originating on the Russian-language Wikipedia, which when installed caused the accounts of all administrators on Wikipedia, Wikisource, Wiktionary, and several other projects to mass-delete pages. This resulted in Wikipedia being frozen for several hours as other security engineers tried to patch the issue. VidanaliK (talk to me) (contributions) 20:06, 5 March 2026 (UTC)

Any post to WMF or the media should have arguments with it like best practices for whitehat testing. Snævar (talk) 21:54, 5 March 2026 (UTC)

FYI phab:T419154 for the site scripts disabled thing, it's being tracked - plan is to get it back soon. — xaosflux ^Talk 18:37, 5 March 2026 (UTC)

We really need something like bot passwords for the web interface. You don't stay logged in to your machine as root all the time, do you? Yet there's no choice but to do that here. Suffusion of Yellow (talk) 18:55, 5 March 2026 (UTC)

Yeah, I'm also baffled by how Scott Bassett just ran these scripts on their main account with all rights without any second thought. sapphaline (talk) 18:57, 5 March 2026 (UTC)

Perhaps highly-privileged accounts with interface administrator permissions should have mandatory Always Safe Mode enabled.

I personally have a few userscripts that I use (and I've made sure to copy them to my own userspace now). But it doesn't seem unreasonable to encourage using a separate account for those routine tasks where scripts can save a lot of time. If today is a day where you do need to juggle chainsaws and other scary tools, it would seem wise to use a safe mode account. Mlkj (talk) 19:16, 5 March 2026 (UTC)

and I've made sure to copy them to my own userspace now: That only protects you if the script's owner is the compromised account. Doesn't help if an intadmin (or crat or steward ...) is compromised. But if there's an unintentional security problem with script (XSS, etc.), your copy won't get fixed if it's discovered. If the script has only one component (e.g. foo.js doesn't load foo-core.js) you can use a Subresource Integrity check instead of copying it. Suffusion of Yellow (talk) 19:26, 5 March 2026 (UTC)

Oh, looked at your userspace, I see the script in question is just a few lines long. Yeah, then it's probably better to just review and copy it. Suffusion of Yellow (talk) 19:28, 5 March 2026 (UTC)

The problem with forced safemode for intadmins is that they would no longer be able to run admin scripts like these because you are not permitted to have more than one account with admin permissions. SuperPianoMan9167 (talk) 19:30, 5 March 2026 (UTC)

I like scripts, so I'm sympathetic to that. But I see there's already an exception for WMF, how about another one for the baker's dozen of interface admins out there? Mlkj (talk) 19:45, 5 March 2026 (UTC)

See T419152 RoySmith (talk) 19:00, 5 March 2026 (UTC)

Cool, another feature request that can be ignored for the next 8 years. --Ahecht (TALK
PAGE) 19:09, 5 March 2026 (UTC)

I assume this is why my .js are not loading? - FlightTime (open channel) 19:24, 5 March 2026 (UTC)

Yes. RoySmith (talk) 19:28, 5 March 2026 (UTC)

And stop testing in prod. OhanaUnited^{Talk page} 19:26, 5 March 2026 (UTC)

It's not correct to say attack scripts was created in 2023. As written on wikireality.ru/wiki/РАОрг, they (or their earlier versions) more likely created in 2013. Also, their author, wikireality.ru/wiki/Скрипты_WikiUserFS, is still not blocked: https://ru.wikipedia.org/wiki/special:CentralAuth/WikiUserFS. MBH (talk) 20:00, 5 March 2026 (UTC)

• Noting that @Rhododendrites has started a discussion at the BLP noticeboard: WP:BLPN#Wikipedia:Village stocks and this morning's incident SuperPianoMan9167 (talk) 20:06, 5 March 2026 (UTC)

Post from WMF staff member on Discord:

Hey all - as some of you have seen, we (WMF) were doing a security review of the behavior of user scripts, and unintentionally activated one that turned out to be malicious. That is what caused the page deletions you saw on the Meta log, which are getting cleaned up. We have no reason to believe any third-party entity was actively attacking us today, or that any permanent damage occurred or any breach of personal information.

We were doing this security review as part of an effort to limit the risks of exactly this kind of attack. The irony of us triggering this script while doing so is not lost on us, and we are sorry about the disruption. But the risks in this system are real. We are going to continue working on security protections for user scripts – in close consultation with the community, of course – to make this sort of thing much harder to happen in the future. FaviFake (talk) 20:14, 5 March 2026 (UTC)

That still doesn't explain why they were running random scripts from an account with intadmin permissions. --Ahecht (TALK
PAGE) 23:15, 5 March 2026 (UTC)

huh?? Weren't they doing that just to test the limit of script imports, i.e., how many mw.loader.load()s they can do before something breaks? That's not a security review as part of an effort to limit the risks of exactly this kind of attack. Sure, call it a "security review," whatever, but how exactly is that relevant to limiting "exactly this kind of attack"? — DVRTed (Talk) 02:57, 6 March 2026 (UTC)

Surely not; there is no limit to how many mw.loader.load()s you can do, other than what your computer can handle. I think the review was to see how the scripts would handle changes to the Content Security Policy that would disallow loading some external scripts, which would indeed limit this kind of attack, and which were indeed deployed today as part of the response. Matma Rex talk 03:28, 6 March 2026 (UTC)

@Matma Rex Sure. Thx. Is there a phab ticket related to these changes to CSP? meta:Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident is way too vague and says pretty much close to nothing as to why this incident occurred, so I'm just going off of whatever random thing I find people saying about it online. — DVRTed (Talk) 04:23, 6 March 2026 (UTC)

@DVRTed There doesn't seem to be one. I'm just going by the configuration changes I saw, e.g. . Matma Rex talk 14:42, 6 March 2026 (UTC)

@DVRTed See phab:T419237 and its various parent tasks. --Ahecht (TALK
PAGE) 15:37, 6 March 2026 (UTC)

limit this kind of attack – But the malicious code used in this attack was local, wasn't it? Janhrach (talk) 21:33, 6 March 2026 (UTC)

@Janhrach That is basically irrelevant because to an attacker a local attack is easier than dealing with CSP. This wasn't an attacker, this was just some script someone had laying around. Polygnotus (talk) 22:13, 6 March 2026 (UTC)

@FaviFake Thanks for that description of what happened. But... testing in prod?? David10244 (talk) 04:03, 7 March 2026 (UTC)

@OhanaUnited, Oshwah, PrimeHunter, and Ritchie333: Pinging a few random admins from this thread. Could someone please update the watchlist notice to link to this discussion? The notice currently reads Userscripts are temporarily disabled for security reasons but does not link to anywhere to provide context. I'm sure many users will be unaware of this thread unless it's linked in the notice. Zeibgeist (talk) 21:10, 5 March 2026 (UTC)

A link from the watchlist notice would be nice, but this thread (especially at the top) is a lot of people trying to figure out what's happening rather than a concise summary of what happened and what editors might need to know. Sdkb ^talk 21:12, 5 March 2026 (UTC)

Well we've pretty much already figured out everything. Ideally there should be a link pointing to the summary of the incident, but that's been deleted from the village stocks. FaviFake (talk) 21:15, 5 March 2026 (UTC)

The watchlist notice definitely needs to link somewhere. There are already threads at WT:NPP/R and the Teahouse with people confused about their userscripts being disabled. Linking to a centralized thread where that is being discussed is better than no info at all. Adding a couple more admins @Xaosflux and Ahecht: to get an opinion on this. Zeibgeist (talk) 21:19, 5 March 2026 (UTC)

@Zeibgeist Would linking to phab:T419154 be enough? — xaosflux ^Talk 21:59, 5 March 2026 (UTC)

Thanks for the prompt response. It looks like Oshwah has it handled. Zeibgeist (talk) 22:06, 5 March 2026 (UTC)

That doesn't seem unreasonable at all; stand by... ~Oshwah~^{(talk) (contribs)} 21:49, 5 March 2026 (UTC)

Zeibgeist -  Done. ~Oshwah~^{(talk) (contribs)} 22:04, 5 March 2026 (UTC)

Excellent, thank you! That will hopefully clear up some of the confusion. Zeibgeist (talk) 22:06, 5 March 2026 (UTC)

Wait, I have an idea for patching! An edit filter preventing pages from being deleted using automatic scripts. VidanaliK (talk to me) (contributions) 22:03, 5 March 2026 (UTC)

This would be a drastic overhaul of administrator workflow. It would also only address one type of action a malicious script can take -- I would think a solution to this problem should address the root issue of a script taking control, not just preventing damage in one or more ways. Giraffer (talk) 22:14, 5 March 2026 (UTC)

Or maybe requiring administrator approval for high-stakes tasks performed by automatic scripts? VidanaliK (talk to me) (contributions) 22:15, 5 March 2026 (UTC)

On a technical level once you have a script running it's hard to know whether the user or the script took the action. It's different from the bot API, because a script just uses your own web browser on your behalf. It can silently submit any form and click any button that the user has access to, and it'll look like the user did it. Mlkj (talk) 22:32, 5 March 2026 (UTC)

You can force people to reauthenticate through a page loaded in safemode, though, and a script cannot hijack that (if implemented properly). This would probably be a bit annoying (like it'd make intadmins put in their password every time they edit a sitewide js page), but perhaps worth it. Elli (talk | contribs) 22:36, 5 March 2026 (UTC)

Yeah, it's better that people have a slight inconvenience when performing automatic actions than a malware script from Russian Wikipedia in 2013 take over the Wiki and delete thousands of pages en masse. Restoring such pages is probably going to take even longer. VidanaliK (talk to me) (contributions) 22:39, 5 March 2026 (UTC)

I assume initadmins editing a sitewide JS page is an infrequent enough event that requiring a re-authentication would not be an excessive burden.

The trick with these sorts of things is to make them painless enough that people don't invest effort to find ways around them. In the command-line world, there's the "sudo" command which requires a reauth before allowing somebody to do dangerous things. A well-configured setup will make doing the right thing easy enough that people don't mind doing it. If you make it really painful, they'll start doing things like "sudo bash" and live in that shell all day (and when you disallow that, they'll find more creative ways around it). RoySmith (talk) 22:43, 5 March 2026 (UTC)

Yes. The best attack I can see against that is the risk of reauth/2FA fatigue. Wait until the user is about to click a button that will send them to the safemode reauth page and hijack the action to be "edit common.js" instead of whatever it was, or show a phishing reauth page (e.g. steal credentials, show a fake error, then display the real reauth page).

I like this idea though. I hope it's not too much work, I feel like we really need something more around sensitive actions like these. Mlkj (talk) 22:45, 5 March 2026 (UTC)

Noting that there is a statement about this incident on Meta, see Meta:Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident. 45dogs (they/them) (talk page) (contributions) 00:30, 6 March 2026 (UTC)

Which strikes me as corporate-speak that explains much less than is explained on this thread. - Jmabel | Talk 01:14, 6 March 2026 (UTC)

True, true. I was pissed that Reftoolbar wasn't working, and reading this live thread (before the resolution) I could bear the pain.;-) Carlstak (talk) 02:28, 6 March 2026 (UTC)

@Jmabel and Carlstak: Well, anyone can edit it, but I wouldn't go any further with it than I just did. Graham87 (talk) 03:32, 6 March 2026 (UTC)

Well, that's not very far. It may be accurate as far as it goes, but it sounds like boilerplate. Needs one of those people who love to add plots to WP movie articles to write up a summation of the thread. Carlstak (talk) 07:02, 6 March 2026 (UTC)

I subsequently got reverted anyway. Meh ... there was an edit button there. Graham87 (talk) 08:09, 6 March 2026 (UTC)

@Jmabel: It's called "need-to-know". If you need to know exactly what happened, they will have told you already. If they've not told you, you don't need to know. As with any security issue, the fewer details that are public, the less likely it is to occur again. See also WP:BEANS. --Redrose64 🌹 (talk) 09:15, 6 March 2026 (UTC)

@Redrose64: sorry, I'm not buying it. The discussion here is totally public, and black-hat types will find it and absorb it. There is no security advantage in failing to say that a "bomb" script lay around, visible, for over a year, no one in the community noticed it, and a WMF employee (one involved in security, no less) accidentally triggered it. - Jmabel | Talk 16:29, 6 March 2026 (UTC)

Yes, the discussion here is public, but parts of it perhaps should not be. I also see a number of comments that are factually incorrect: people not in possession of the facts should not be offering opinion on what might have happened. I have made previous posts on a similar theme, they may be found in the archives at Archive 163 (12 February 2018) and Archive 206 (31 May 2023). --Redrose64 🌹 (talk) 18:59, 6 March 2026 (UTC)

Talking about beans when the top post of hacker news was exactly what happened seems a little silly. Cats out of the bag. Bawolff (talk) 01:01, 7 March 2026 (UTC)

In the need to know essay you link to, it states If you have concerns about the reasoning for something, there are procedures for questioning a decision without publicizing private information. This does not appear to be the case. Instead, the details of what happened appear to be hidden without any recourse for challenging the decision to hide these details. Instead of claiming a security issue over every issue in existence, perhaps a more transparent approach would be a better path forward. EggRoll97 ^(talk) 06:04, 7 March 2026 (UTC)

The incident arose on meta, so meta is the place to ask; indeed, there is a discussion page at m:Talk:Wikimedia Foundation/Product and Technology/Product Safety and Integrity/March 2026 User Script Incident; in that, there is a thread "Explanation Request" which I think sums it all up nicely. By there are procedures for questioning a decision, it means asking "why was action taken in the manner that we have experienced, it has led to significant inconvenience" and awaiting the response of those who have full access to the facts. What we do not do is fire off uninformed guesswork at every dramahboard on the planet. --Redrose64 🌹 (talk) 10:18, 7 March 2026 (UTC)

Hi, I've asked about this over on WP:MILHIST but possibly folk here can give a better answer, particularly as the OpenStreetMap project appears to be dead.

At some point in the last year or so OpenStreetMaps appeared in all of the battle-infoboxes. You can see an example of this at Battle of Jutland, and it's very typical - totally uniformative and useless since what it shows is a close-up map of an empty stretch of sea. The land versions are little better since the maps are modern (with modern location-names and boundaries) and always at the wrong scale to give you any idea of what the battle was. Most of these pages have far more informative maps on them already.

However, the maps were not added through ordinary editing. They appear to be added automatically by some kind of plug-in or gadget. There is nothing in the page that can be edited to remove them without removing the co-ordinates that they are based on. The only solution appears to be just deleting the co-ordinates from the infobox.

Is there no way of opting pages out of this without just removing the co-ordinates?

It is also passing strange that, were anyone to propose adding that map to the infobox in the Battle of Jutland article, editors would rebel against the whole idea, but that map and tens of thousands more just as uninformative could be added to tens of thousands of articles with (as far as I am aware, correct me if I am wrong) little or no discussion. FOARP (talk) 11:39, 4 March 2026 (UTC)

These map frames are causing issues in other places as well. See Template talk:Infobox civilian attack#Mapframe appearing by default, Wikipedia:Village pump (miscellaneous)/Archive 86#Automatic map generation from Wikidata, Template talk:Infobox settlement#Unreliable maps automatically imported from OpenStreetMap. I don't know when they started being added and what discussions led to it. CMD (talk) 12:28, 4 March 2026 (UTC)

From the look of it: not discussed at all? And 95%+ of the time they're useless, but taking up prime real-estate on the page.

I've tried looking at Template:Infobox military conflict, and if I've understood it correctly showing the mapframe should be default no? That's how I read the documentation anyway. Adding |mapframe= no to Battle of Jutland's infobox removes the silly map.

But it's defaulting to yes across tens of thousands of articles and that should end ASAP. FOARP (talk) 13:37, 4 March 2026 (UTC)

Pinging @Joy (on a completely no-blame basis) as it looks like it might be their edits to Module:Infobox military conflict last October which have generated the |mapframe=onbydefault behaviour. Nthep (talk) 14:03, 4 March 2026 (UTC)

Yes, if you're talking about Module talk:Infobox military conflict#mapframe implementation. We had a similar discussion about the default zoom on sea locations already, and I actually tried to fix it already in this template, but because of this specific Lua implementation in that particular template, I didn't figure out how to do it. I'll attend to the article mentioned above now.

Is there a Lua-related noticeboard where one could ask for help? --Joy (talk) 14:09, 4 March 2026 (UTC)

Hmm, on a more general note, this template and this use case is actually pretty odd from the get-go. Usually the infobox templates have an image parameter for descriptive pictures, and a map parameter for maps. In this case, however, a map is attached as an image, so the code that autodetects whether to make a mapframe thumbnail from coordinates can't detect that. We should implement a map_image (or similar) parameter to improve this situation. This should be discussed at Template talk:Infobox military conflict. In the meantime I see FOARP has found that talk page 15 minutes ago, so I'll move over there. --Joy (talk) 14:15, 4 March 2026 (UTC)

Joy, this feature needs to be switched off by default ASAP until a consensus in favour of including them is decided. Not just for Battle of Jutland, but for all military conflict articles because in very, very few cases are these maps actually helpful. The zoom-level is only one of the many problems with them. FOARP (talk) 14:16, 4 March 2026 (UTC)

We can certainly revert the addition.

At the same, we could also observe that the feature has been live since October 2025, and you found 1 bad example after 4.5 months. Maybe the insistence that something needs to be done as soon as possible is not necessarily the best course of action. We could also try to analyze the available information further, and find more examples that actually demonstrate the extent of the issue, which should help us assess the risks here better.

For example, at https://bambots.brucemyers.com/TemplateParam.php?wiki=enwiki&template=Infobox+military+conflict we can currently see:

• 5,795 detected mapframe-coordinates parameters - this is mapped from coordinates automatically, so that sounds like the overall usage right now
• 34 detected mapframe parameters - usually interventions to enable or disable, where we further see:
  • CEM-36-Huguang-2433.jpg (1) - random bug?
  • This victory had the effect of breaking up the Hindu confederation (1) - random bug?
  • Yes (1) - explicit enabling
  • n0 (1) - attempt to disable that went awry?
  • no (12) - explicit disabling
  • yes (18) - explicit enabling
• 8 mapframe-marker (7 monument, 1 battle)
• 7 mapframe-zoom
• 7 mapframe-area_km2 - this can also be zoom/scale tuning
• 2 mapframe-caption
• 2 mapframe-frame-height (=250)
• 2 mapframe-frame-width (=180)
• 1 mapframe-wikidata (=yes)

So comparing 34 to 5795, we've had about 0.5% intervention rate of some sort. This could mean that nobody knows how to edit these things so we don't see much (iceberg effect), or it could mean that there wasn't a pressing need for interventions, or something inbetween.

The use of other options being comparable to the 34 seems to indicate that at least some editors have used these options for good. The ratio of explicitly disabled to explicitly enabled ones (13 vs 19) is not really in favor of the idea of there being a huge issue that requires urgent mass disabling. Of course, likewise there's the possibility of the iceberg effect as mentioned above.

I recommend we continue analyzing this in more depth at the infobox talk page, and really try to figure it out. --Joy (talk) 14:44, 4 March 2026 (UTC)

I found out about this because of an editor complaining in a comment that was posted soon after this feature went live. What people lacked was sufficient knowledge to know where even to complain about the issue - it's the iceberg effect. FOARP (talk) 14:51, 4 March 2026 (UTC)

I don't think this is straightforward evidence for that, both because that complaint indicated a variety of other issues (slow to display? Apple products?), and was by @Malchemist, an editor of fifteen years here. While we can and should appreciate others like ourselves :) we are not necessarily indicative of the general readership by default. A hundred thousand readers were there since, so even if iceberg ratio is 1000 : 1 this could well still be fine.

Likewise, if the solution was to actually remove the coordinates, not just the mapframe, because the location just wasn't right, then the mapframe merely made an existing issue more obvious, it didn't really introduce a fresh one. In that sense, mapframe thumbnails can be a useful tool to keep the base information proper.

At the same time, there's possibly a bit more nuance still - maybe if we better honored the resolution implied by the formatting of those coordinates, 49°1′N 3°23′E, (WP:OPCOORD), with a derived mapframe zoom that would better match that precision, maybe the context wouldn't be so bad by default. Comparison below:

For the average reader who doesn't really know where the Marne river valley might be, this basic illustration of it being east of Paris seems like a generally useful default. Unlike with Chateau-Thierry, which isn't even mentioned in the battle article, only in another map caption. --Joy (talk) 16:13, 4 March 2026 (UTC)

Hi Joy, I hope you don’t mind me saying this, but I am getting the strong impression that neither my concerns nor those my fellow editors in the Milhist space are entirely being listened to. Multiple editors here and at the template page have now told you that we don’t want these maps, that were added without discussion to thousands of articles, against what the documentation in the template says.

Please revert this addition ASAP. FOARP (talk) 21:37, 4 March 2026 (UTC)

I'm listening, but you're not apparently listening to me (at least I'm not seeing much other than blanket assertions in response), and seem to be intent on insisting something is done ASAP (Likewise here) Are you upset about this? What is the reason for this apparent urgency? Besides, you have the same permissions as I do, why wouldn't you just undo the change yourself, instead of poking me in the eye about it like this? --Joy (talk) 08:14, 5 March 2026 (UTC)

Could you please explain how exactly to do it? I honestly don't know how, otherwise I wouldn't be asking you. FOARP (talk) 09:06, 5 March 2026 (UTC)

The changes are in the history of Module Infobox military conflict, I had added a single block of code, it should be safe to just take it out. You can also test it first in Module:Infobox military conflict/sandbox. --Joy (talk) 09:20, 5 March 2026 (UTC)

Many thanks. Hopefully my inexpert deletion has not caused any problems.

As a word of advice, making sweeping changes to many thousands of pages is not something that should be done lightly and if I were you I would definitely at least drop a comment on to the relevant talk-page discussing what it is you want to do, and wait to see what the response is, before doing something like this again. FOARP (talk) 10:13, 5 March 2026 (UTC)

I think that's an issue also exacerbated by the weird division of talk between the two namespaces in that case. --Joy (talk) 13:09, 5 March 2026 (UTC)

Would a merge fix that? FOARP (talk) 13:19, 5 March 2026 (UTC)

I think we should do that, I can't imagine that there'd ever be a huge amount of discussions that would be so annoying to either audience to make it not worth it. --Joy (talk) 13:28, 5 March 2026 (UTC)

I should also mention one more thing with regard to iceberg effect - mapframes are much more common these days, and more and more readers are accustomed to them, and are aware of the fact one can click them, and then zoom in and zoom out (either by clicking, or by scrolling, or by pinching). Even in the worst case scenario where a reader encounters an ugly bland blue or white box, they might be aware that they can fiddle with the box, get in, zoom out, and get the geographical context information, which may or may not be useful, but it's typically not harmful. That is also why I would tend not to be alarmed in this situation. --Joy (talk) 14:51, 4 March 2026 (UTC)

Barely any mapframe maps in the first 50 at Special:WhatLinksHere/Template:Infobox_military_conflict. In 2026, I'd rather see people complain about unzoomable location maps or other static maps with tiny unreadable labels. Ponor (talk) 15:00, 4 March 2026 (UTC)

I found 10 mapframe maps in those 50. The infobox is used in 23,810 articles so that's an estimated 5,000 maps. PrimeHunter (talk) 22:18, 4 March 2026 (UTC)

I didn't find any mapframe maps improperly used in my sample. I thought there should be a few more, where there were no maps shown at all: I would like to see where the main battle of the Morean War was (maybe there's a museum), zoom in and out to see what towns are around today, etc. Ponor (talk) 10:05, 5 March 2026 (UTC)

I have no objection to adding mapframes where helpful. I believe this can still be achieved by changing the mapframe attribute to “yes”.

But in this case there was already a long-standing consensus that they should not be on by default documented in the template documentation. That consensus still appears to be valid based on the feed back here, at WP:MILHIST, and on the template talk-page. FOARP (talk) 12:00, 5 March 2026 (UTC)

These modern maps are confusing and misleading in historic articles and should not be used, IMO. Donner60 (talk) 03:37, 5 March 2026 (UTC)

I have also run into this issue in infoboxes that I use, where the map is inserted automatically. There is no obvious way to prevent the map from appearing, even if the editors of the page don't think the page is value-added. Yes, in some cases, a map may be helpful, but in other cases it may not be. That should be a decision made by the editors of that page, not by a hidden technical function that is not explained anywhere for the average non-tech editor. Mr Serjeant Buzfuz (talk) 17:42, 7 March 2026 (UTC)

Do you use the source editor or the visual editor? Most templates supply the data to the visual editor that makes these sorts of things much more obvious. Sadly the source editor doesn't seem to make use of this. --Joy (talk) 17:50, 7 March 2026 (UTC)

Hi, there is a template for the infobox for decisions of the Supreme Court of Canada: Template:Infobox SCC. We're having a discussion on Wikipedia talk:Canadian Wikipedians' notice board about making changes to it, to eliminate terminology that is actually US based and substitute Canadian legal terminology. How would we go about getting changes made? The template is used on 500+ articles, so we would want to be careful about making any changes. Any help would be appreciated. Mr Serjeant Buzfuz (talk) 17:22, 7 March 2026 (UTC)

Mr Serjeant Buzfuz, you can use the /sandbox and /testcases subpages for that; see Wikipedia:Template sandbox and test cases. — Qwerfjkltalk 13:21, 9 March 2026 (UTC)

I'm on a Chromebook and can't figure out how to get the desktop version of Wikipedia. It won't let me change skins, and all my edits are tagged with "mobile edit". --FishOnSkates 17:17, 6 March 2026 (UTC)

@FishOnSkates: Click "Desktop view" at the bottom of a page. In some browsers you may have to scroll to the bottom of the page a second time to see it. PrimeHunter (talk) 17:24, 6 March 2026 (UTC)

@FishOnSkates also if you want to make it permanent on all devices detected as mobile see User:Þjarkur/NeverUseMobileVersion as an option. Cheers KylieTastic (talk) 17:36, 6 March 2026 (UTC)

Thank you, this worked. FishOnSkates 14:46, 9 March 2026 (UTC)

I've found an image on Wikimedia commons that I want to use on Wikipedia, but this image is on page 92 of a pdf and File:Transactions of the Cumberland & Westmorland Antiquarian & Archaeological Society (IA transactionsofcu08cumb).pdf&page=92 doesn't display that page. I'm assuming I could download the pdf, edit it and upload individual pages to commons. But is there a way to display the pdf at page 92 rather than the default of displaying page 1? ϢereSpielChequers 08:33, 7 March 2026 (UTC)

@WereSpielChequers:

See Help:Extended_image_syntax#Page. -- John of Reading (talk) 08:48, 7 March 2026 (UTC)

Thanks John, that works! ϢereSpielChequers 08:52, 7 March 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 18:14, 9 March 2026 (UTC)

MediaWiki message delivery 18:50, 9 March 2026 (UTC)

"synthesizer-idle-light.webp" is randomly appearing in a new right-hand pane of some pages, knocking about 20% off the window width available for content. It's where one of the UI menus had been until I hid it a long time ago. There were many discussions, resulting in consensus that we should allow articles to fill the full screen-width by collapsing or hiding various panes and the TOC. This thing has no close button or explanation what it is, and clicking on it also does nothing useful except change it to a slightly different image. Please make it go away (or a simple "[x hide]" button on it). DMacks (talk) 03:04, 24 February 2026 (UTC)

Does it always appear on the same random pages? Or does it randomly appear and disappear even on the same page/article? – Scyrme (talk) 03:12, 24 February 2026 (UTC)

DMacks, please link to example pages. Take a screen shot if you can. Let us know what browser, skin, and view (mobile or desktop) you are using. Does it happen when you are logged out? Does it happen in a different browser? – Jonesey95 (talk) 03:18, 24 February 2026 (UTC)

if I am not mistaken, the initial idea was to have the globe appear really at random, but it apparently was a performance issue so it is now limited to just 2,500 articles at the most. The WMF team has narrowed down to a predefined list of 2,100+ articles leaving 300+ slots for local projects to determine which other articles to put up. Of course, we can also override the predefined list in whole or in part and curate the full 2,500 articles to show. – robertsky (talk) 16:13, 24 February 2026 (UTC)

@DMacks: If it's always appearing on the same pages, it may be related to "birthday mode". Does it still appear after toggling birthday mode off in your preferences? Or did you already do that? – Scyrme (talk) 03:18, 24 February 2026 (UTC)

I'm fairly certain it's just birthday mode now. I was confused because you quoted .webp (static image) instead of .webm (animation). You can toggle it off in the "Appearance" tab of your user preferences. – Scyrme (talk) 03:30, 24 February 2026 (UTC)

It seems consistently on Ney but consistently not on other pages I've visited lately. Desktop-mode on a desktop computer running firefox, vector 2022 skin. Does not appear when I'm in private-browsing non-logged-in mode. Looks like it is indeed birthday mode, and the pref toggle turns it off. Given that clicking on it does nothing useful, the only way I could even see what to call the image was by browser right-clicking "open image in new tab" and copying the filename. So now I merely emphasize that it's a problem there's no way to know what it means (why doesn't it link somewhere?) or where to turn it off (contrary to closure statement at Wikipedia:Village pump (proposals)#requests for comment on enabling the 25th anniversary birthday mode). DMacks (talk) 03:35, 24 February 2026 (UTC)

There's also a toggle to enable/disable it on Wikipedia's welcoming portal. It would probably be a good idea if the mascot animations linked somewhere, like the link I posted earlier as that page explains why it's there and how to toggle it off if you'd rather not have it. Doing it that way would likely be easier to implement than adding a toggle switch to every page it appears. – Scyrme (talk) 03:47, 24 February 2026 (UTC)

Sure. Anything that lets me know something about it would be an improvement. DMacks (talk) 03:54, 24 February 2026 (UTC)

I just noticed it can also be disabled from any page just from the same menu/sidebar that controls light/dark mode, so there actually is a toggle on every page already. – Scyrme (talk) 03:54, 24 February 2026 (UTC)

There's also a "Learn more about Birthday mode" link under the toggle in the same menu/sidebar. Still a bit confusing if you have the settings hidden as a menu rather than docked to the sidebar. I didn't immediately think to look there. – Scyrme (talk) 03:58, 24 February 2026 (UTC)

I see just an empty sidebar. IIRC Birthday mode is on. ~2026-12471-74 (talk) 08:34, 25 February 2026 (UTC)

Many images display a “broken file” symbol instead, but that is something else (and might be why I can’t see it) ~2026-12471-74 (talk) 08:40, 25 February 2026 (UTC)

If anyone needs articles for testing where the baby globe appears: Animal, Paul Thomas Anderson, Chloé Zhao, 79th British Academy Film Awards, Sun, Venus, Earth, Mars, Computer science, Ney, Music, The arts, Journalism. —⁠andrybak (talk) 04:39, 24 February 2026 (UTC)

@DMacks: meta:Wikipedia 25/Easter egg experiments. You can turn it off for yourself Special:Preferences#mw-prefsection-rendering by unchecking the cryptic "Birthday mode (Baby Globe)". The list of pages it appears on is configured at Special:CommunityConfiguration/WP25EasterEggs.

Any admin could turn off the "Enable by default" option, and while I don't want to be the one to throw that switch, we shouldn't be enabling it by default unless those annoying animations also included a link to the preferences section to turn them off, and the preference was clearly labeled as something like "Display animated globe mascots on select pages". --Ahecht (TALK
PAGE) 15:11, 24 February 2026 (UTC)

Note that S Marshall's close at Wikipedia:Village pump (proposals)#requests for comment on enabling the 25th anniversary birthday mode was that there was consensus to enable this feature by default if there is a prominent button to disable it, preferably on every page where birthday mode affects the user experience. Since the latter didn't happen (just a cryptic checkbox buried in preferences), we should consider not enabling it by default. --Ahecht (TALK
PAGE) 15:24, 24 February 2026 (UTC)

Also pinging @Robertsky who implemented Special:Diff/1338834608/1340087942. --Ahecht (TALK
PAGE) 15:27, 24 February 2026 (UTC)

If there's no button to switch it off then this should be disabled instantly.—S Marshall T/C 15:29, 24 February 2026 (UTC)

The button to disable it is on every page, in the Appearance menu. – robertsky (talk) 15:51, 24 February 2026 (UTC)

A key is that it's if you have such a menu. And if you don't, you don't know you need to find it for this situation. DMacks (talk) 17:35, 24 February 2026 (UTC)

The menu is there. On Vector 2022 skin, the Appearance menu accessible from the glasses/eyewear icon next to your username in the top menu bar by default, unless you have the Appearance menu already opened in the sidebar. – robertsky (talk) 18:34, 24 February 2026 (UTC)

Right. I know I have that menu hidden there, but we're still in "you don't know you need to find it". Is this a site appearance thing? A new functional feature in general? Something specific to the one page where I see it? DMacks (talk) 18:57, 24 February 2026 (UTC)

I would say that off the bat, most readers (as there are many more anon readers than power users like us) would know where to look for the button to hide the baby globe and the learn more page as well as the Appearance menu is in the sidebar by default, and that's immediate below the baby globe image in the sidebar if it is appearing. It can't get anymore prominent than that.

Your personal experience indicates otherwise, which is why my ping below supporting the idea of have [x hide] button. To further refine that idea, the [x hide] or even a learn more link button should be around the baby globe only when the Appearance menu is hidden. – robertsky (talk) 19:17, 24 February 2026 (UTC)

I have more than twenty years of Wikipedia experience, and it took me about me about ten minutes to find it. Until presented with very convincing evidence to the contrary, such as a design research with multiple diverse people who aren't experienced editors, and who were able to easily find how to disable it, I will assume that it is hard for most people to find how to hide it.

The current situation is nowhere near the consensus of "place a reasonably prominent button to disable it".

It's unreasonable to place an unrelated (!) and animated (!!!) thingie on lots of articles in the first place, but if anyone at the WMF really wanted to put it there, it should at least be easy to hide. It isn't. Amir E. Aharoni (talk) 00:16, 26 February 2026 (UTC)

"I did find the notice...It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard'"

This needs to be removed immediately until a solution that clearly tells the user how to disable it is part of it. Masem (t) 02:02, 26 February 2026 (UTC)

@Robertsky Ahh yes, the button labeled "Birthday mode (Baby Globe)", which in no way says "Turn off this distracting animated cartoon that's taking up a large portion of my page". If I hadn't seen this conversation, there's no way I'd know what the heck that means. --Ahecht (TALK
PAGE) 15:56, 25 February 2026 (UTC)

The [x hide] idea might be a good thing to implement though. Pinging @CDekock-WMF. – robertsky (talk) 16:02, 24 February 2026 (UTC)

Why isn't the video even clickable? It should have linked to a landing page somewhere. When I saw the video there on its own, I thought my computer was hacked. ~2026-12306-86 (talk) 02:35, 25 February 2026 (UTC)

Hello @Robertsky, thanks for the ping! Unfortunately, changes to Birthday mode aren't possible due to the limited-time nature of the feature. Since Baby Globe will only be visible on a small number of pages for one month, it’s not something we can prioritize for any further iterations. CDekock-WMF (talk) 12:15, 25 February 2026 (UTC)

@CDekock-WMF Maybe a minor modification could fix the concerns voiced here. Here's what I get in mobile view with Vector 2022:

There's a bold blue link to the settings where I can turn off the globe with one click. Nice! As far as I can tell, everyone here would be happy with this.

But here's what I get in desktop view with Vector 2022:

No link, no indication how I can turn this off. :-(

Anyway, that's what I got a few minutes ago. Now I don't see the globe anymore, just empty space. What happened?

— Chrisahn (talk) 13:01, 25 February 2026 (UTC)

Now I see the globe again. Maybe my network was flaky. — Chrisahn (talk) 13:05, 25 February 2026 (UTC)

Mobile view is Minerva, not Vector 2022. The link to turn it off in Vector 2022 is under the "Appearence" menu, which is uncollapsed by default but is collapsed in your view (under the glasses icon). There's a switch that lets you disable birthday mode directly on the page without having to open preferences. SuperPianoMan9167 (talk) 13:21, 25 February 2026 (UTC)

I know how to turn it off. That's not the point. The RFC that decided to enable this on the English Wikipedia said it should only be enabled if there is a prominent button to turn it off. That hasn't been done. That's the point. — Chrisahn (talk) 17:05, 25 February 2026 (UTC)

@CDekock-WMF any qualms from the development team if a volunteer steps in and muck around the extension to bring the idea using with phab:T418428 then? I don't mind rolling up my sleeves over the weekend on this. – robertsky (talk) 06:46, 26 February 2026 (UTC)

Wow, @Robertsky, what an offer! Thank you! Let me check in with the team on whether there are any reasons not to do things this way around. I'll get back to you later today. CDekock-WMF (talk) 10:06, 26 February 2026 (UTC)

Hello again @Robertsky, apologies for our delay in responding here. Thank you again for the offer to collaborate on this and improve the feature! We have been doing some work in the background to make sure we can support any code contributions from editors on this. We now have an engineer on standby to help review tweaks you may want to make. CDekock-WMF (talk) 16:03, 3 March 2026 (UTC)

• Turn this off. Please disable this feature until there's a reasonably prominent button to disable it on every page where it affects the user experience. Not hidden in a menu. On the page. Turn it off. Please turn it off.—S Marshall T/C 12:02, 25 February 2026 (UTC)

  I'd like to apologise wholeheartedly to the community for my role in this. :( I'm appalled.—S Marshall T/C 12:27, 25 February 2026 (UTC)

  @S Marshall: Perhaps you can go to Special:CommunityConfiguration/WP25EasterEggs and turn it off ("Default state for Birthday mode" to "Disabled") directly? (I thought only intadmins could, but now I see Robertsky is not one.) Nardog (talk) 13:20, 25 February 2026 (UTC)

  @Nardog It's any admin, not just intadmins, but S Marshall is not an admin. --Ahecht (TALK
  PAGE) 15:57, 25 February 2026 (UTC)

  The button to turn it off is only hidden in a menu if you have the "Appearance" menu collapsed. Otherwise, it's very prominent. SuperPianoMan9167 (talk) 14:10, 25 February 2026 (UTC)

  The cryptically labeled "Birthday mode (Baby Globe)", which I'd have to follow a link to find out what it means? It should be, at the very minimum, indicate that "Baby Globe" is an animated figure -- I'd have no idea what that means otherwise. --Ahecht (TALK
  PAGE) 15:59, 25 February 2026 (UTC)

This thing is completely unacceptable. It's extremely distracting. It's literal torture for me to see an unrelated animated thing and try to read something at the same time.

It took me about ten minutes to find how to disable it deep in the sidebar, and I've been writing on Wikipedia for more than twenty years, and programming MediaWiki for fifteen. I cannot imagine what do less experienced readers go through.

I've just reported https://phabricator.wikimedia.org/T418428 . If it's not addressed by tomorrow, I plan to use my sysop rigts to force-disable it for everyone in Common.css. Can anyone give me a reason not to do it? --Amir E. Aharoni (talk) 23:53, 25 February 2026 (UTC)

Yes. Force-disabling it for everyone would violate the explicit consensus of the Wikipedia community to have the feature on by default. SuperPianoMan9167 (talk) 00:47, 26 February 2026 (UTC)

The consensus summary says that there must be a "reasonably prominent button to disable it". There is no such button. There is a button, but it's nowhere near being "reasonably prominent". So the consensus was violated by whoever enabled the button, not by who will disable it. Amir E. Aharoni (talk) 01:17, 26 February 2026 (UTC)

Every logged out user who views it (who are the vast majority of users) has a prominent button to remove it by default, and they are the 99%. That it took you 10 minutes to remove it is, accordingly, not going to be the average experience, even if it took that long for every logged in editor to find the "goodbye" button.

I'm not a fan of someone who has sysop rights threatening to remove it by CSS when there is a plausible consensus quite established that says it should be enabled.

Moreover, for someone who has been a MediaWiki developer for 15 years, it is shocking to find you entirely missed the deployment of the interface administrator user right close to a decade ago, which you do not hold. I would oppose your stated reason for requesting that right, should you choose to do so in the meantime.

If you are so firmly against it, you should instead use your knowledge as a developer to submit a patch to disable it and see if you can convince another developer to +2 that patch. Izno (talk) 01:52, 26 February 2026 (UTC)

Also, would it be possible to hack in a more prominent button to disable the feature by editing common.js and common.css? SuperPianoMan9167 (talk) 00:53, 26 February 2026 (UTC)

Definitely possible, but the time and the effort to do this should be invested by the people who want to show the animation and not by the people who don't want to see it. Amir E. Aharoni (talk) 01:18, 26 February 2026 (UTC)

A good reason might be that abusing admin tools to overrule consensus would probably get you desysopped, but don't let that stop you. -- asilvering (talk) 02:22, 26 February 2026 (UTC)

The editor who closed the discussion establishing the consensus has clearly stated that this feature is not implemented according to consensus (the close was "implement if X..." but the situation is "not X"). A good-faith read is that whoever enabled it did not realize that the effect would be against consensus, since they just turned on what someone else had implemented. WMF has stated that they will not change the implementation so that it "is X". Therefore we currently have a situation that is not consensus (it even looks contrary to consensus), and turning it off would not contravene the close statement. DMacks (talk) 02:57, 26 February 2026 (UTC)

A good-faith read is that whoever enabled it did not realize that the effect would be against consensus, since they just turned on what someone else had implemented. For what's it is worth, the effect in my opinion remains within the consensus, the button is prominent for most readers. My ask for enhancement was a request for enhancement for what I frankly think are edge cases like your experience. I thought that was pretty telling with my refinement of your [x hide] idea. I am of course miffed at the idea not being taken up by WMF staff, but they have priorities and also as what Izno alluded to, any volunteer developer can also submit a patch, and I would be one of the first to help clear and deploy it as long as the patch works within expectations.

A telling sign that most readers are not experiencing what you are experiencing is to look at WP:Help desk and WP:Teahouse where non-registered readers asks for help mostly, where the only two threads about the baby globe by TAs thus far were apparently, "Where can I find the baby globe?" (sic 1, sic 2). In previous major roll outs, like Vector 2022, going off from my recollection, the two venues got significantly way more complaints and queries about the change from anons than at this village pump, so much so that there was/were template reply/replies by experienced editors tending to the two venues. – robertsky (talk) 06:43, 26 February 2026 (UTC)

@Amire80, @DMacks To a non-logged in user on basically any non-tablet device there is a large toggle directly below to turn it off. This is very much consistent with community consensus. (See this image of how it looks to non-logged in users) On mobile there is a link to the appropriate section in settings to turn of the globe. The fact that we have a million tools and have reorganized our interfaces in different ways is not necessarily "WMF implemented something in a manner not in consensus", but rather "in a few cases logged in editors have the link to disable farther away than expected". Sohom (talk) 16:44, 2 March 2026 (UTC)

I have to disagree. I don’t think that is consistent with the consensus condition. It took me a long time to get rid of the damn thing. I am not a power user by any means. I was poking at random before it finally went away. Mr Serjeant Buzfuz (talk) 16:05, 8 March 2026 (UTC)

ETA: I think it would have been consistent with consensus if, for editors who had clicked that option, it meant that both the globe and the turn-off button did not show. But by splitting it, so the globe always showed, but not the turn-off button, it failed to meet the consensus, in my opinion. Mr Serjeant Buzfuz (talk) 16:43, 8 March 2026 (UTC)

It's a time limited function that can be switched off by users (yes, it did take me some time because I hid the appearances menu some time ago). As as it's only going to be around for 7–8 weeks then let's just let it run it's course but people can offer whatever feedback they want to the developers about waht features and/or the associated documentation should contain. Nthep (talk) 09:06, 26 February 2026 (UTC)

• Baby globe is cute, a great PR campaign, and easily turned off. Open up Ursula K. Le Guin in a private/incognito browser (so that you're logged out) and you'll see how prominent and easy it is to turn it off as a reader (which is who this campaign is targeting and who Wikipedia is for). If you've hidden that menu, or didn't pay attention to the discussions about turning it on, I don't see how that's the dev's fault. With that said, I do think it would have been nice if the baby globe images themselves were clickable and linked to ; as that would not only explain the point, but also how to turn it on/off. If we can iron out the details a bit, I'd like to see baby globe used in the future, perhaps for other anniversaries, so I'd hate to see baby globe entirely fall by the wayside. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:35, 8 March 2026 (UTC)

  Note that some of the baby globes (like the sightseeing one at Rome and Singapore) have easter eggs when clicking/tapping on them. —⁠andrybak (talk) 20:21, 8 March 2026 (UTC)

  They are cute indeed. Unfortunately they do not move, at least on some browsers, I think, until you turn them off and on again on every current page. IKhitron (talk) 09:17, 9 March 2026 (UTC)

  In response to this statement by Captain Eek:

  Open up Ursula K. Le Guin in a private/incognito browser (so that you're logged out) and you'll see how prominent and easy it is to turn it off as a reader (which is who this campaign is targeting and who Wikipedia is for). If you've hidden that menu, or didn't pay attention to the discussions about turning it on, I don't see how that's the dev's fault.

  But here's the closure statement, which I would say sets out the instructions to the developers:

  in deference to the opposition to this idea, please place a reasonably prominent button to disable it. To the maximum extent possible this button should appear on every page where birthday mode affects the user experience

  In my opinion, the developers have not complied with the instruction to have a reasonably prominent disable button "on every page where birthday mode affects the user experience". Mr Serjeant Buzfuz (talk) 01:26, 10 March 2026 (UTC)

What's the spinning globe on Ursula K. Le Guin?

I see a gif of a spinning wiki globe in the top right corner (above "Tools" menu) on Ursula K. Le Guin article. What is that and where is it from? Renata•3 04:44, 8 March 2026 (UTC)

Presumably it's mw:Wikipedia 25/Easter egg experiments. It can be disabled by the toggle at the top of the tools menu. CMD (talk) 04:50, 8 March 2026 (UTC)

See also #Un-hidable(?) new UI decoration taking up lots of screenspace. The figure appears to be in a space suit to illustrate an article about a science fiction author. PrimeHunter (talk) 04:54, 8 March 2026 (UTC)

Resolved

Yup, that's it. Thank you! Renata•3 07:16, 8 March 2026 (UTC)

I recently tried to add archived sources to locations where the Wayback Machine couldn't archive them automatically, but I was prevented from finishing the edit. Is there any way to do this? Svartner (talk) 16:15, 8 March 2026 (UTC)

See Wikipedia:Archive.today guidance. Anomie⚔ 16:18, 8 March 2026 (UTC)

See this notice:

Wikipedia:Archive.today guidance Mr Serjeant Buzfuz (talk) 16:18, 8 March 2026 (UTC)

What were the sources? If they were news articles, sometimes you get lucky and the same articles have been widely distributed via a news agency like Reuters. Those can often be archivable via the Wayback Machine on another news website. – Scyrme (talk) 02:49, 10 March 2026 (UTC)

This may have begun about a week ago or so. It's not always, but I see it regularly: in any page with images some thumbnails load, others fail to. Refreshing the page usually causes them to load, or requesting the browser to reload one that failed. I've been checking VPT from time to time for someone reporting the same problem but failed to identify a related thread, so thought I'd post this one. Thanks, ~2026-10830-00 (talk) 13:44, 4 March 2026 (UTC)

Please could you link to an example article where you are seeing a problem? I tried checking a few articles which have many images, e.g. List of paintings by Thomas Cole, but I cannot reproduce this bug. [Examples/links almost always help in bug-reports!] Thanks. Quiddity (WMF) (talk) 21:07, 4 March 2026 (UTC)

This could be the same problem as T418323. Matma Rex talk 22:40, 4 March 2026 (UTC)

This has been happening for at least a week. In articles but also in CentralNotice banners. Here's an example from 2026 Winter Olympics just now: <https://i.imgur.com/li1042k.png>. It's HTTP 429 Too Many Requests errors from URL such as <https://upload.wikimedia.org/wikipedia/commons/thumb/2/29/Flag_of_Eritrea.svg/60px-Flag_of_Eritrea.svg.png>. I'm running Google Chrome Version 144.0.7559.110, but this is almost certainly not a browser or ISP issue. This is some change that Wikimedia Foundation Inc. made to its media server configuration. Possibly related to phabricator:T414805. --MZMcBride (talk) 22:50, 4 March 2026 (UTC)

Yes, I would expect it to be 414805. Izno (talk) 23:32, 4 March 2026 (UTC)

But 60px is a standard thumbnail width, so it can't be that. Ladsgroup, who's been working on that task, also says that's not it. Matma Rex talk 10:11, 5 March 2026 (UTC)

It would be really helpful if someone could get a trending graph of HTTP 429s from upload.wikimedia.org over the past X days. --MZMcBride (talk) 22:58, 4 March 2026 (UTC)

I figured out where to find this, and added it to this dashboard: https://grafana.wikimedia.org/d/000000034/media. The number of 429s has been increasing over the last 3 weeks or so; note that the lines on this graph have different scales, so it's a steady 40k/sec of HTTP 200 responses, and recently up to 8k/sec of HTTP 429 responses. Looks like some tweaks are being made (T418323#11677204). Matma Rex talk 12:15, 5 March 2026 (UTC)

I had assumed that it was a slow connection. In the last month, I've used Wikipedia on three different devices using at least five different ISPs with widely varying load times. --Redrose64 🌹 (talk) 23:33, 4 March 2026 (UTC)

Thanks for looking into this, I'm glad that the source of the issue was found. ~2026-10830-00 (talk) 18:01, 5 March 2026 (UTC)

Update: I don't seem to encounter the issue anymore. ~2026-10830-00 (talk) 04:57, 10 March 2026 (UTC)

900km
559miles

Divisions

Eastern Division

Western Division

   

Original

900km
559miles

100px45px5px

Eastern Division

Western Division

   

After removing the title

How do I remove the title from a legendbox in {{OSM Location map}}? In its documentation, a "centred title line" which I presume refers to this, is described as "optional". Simply removing <b>Divisions</b>, from |legendBox=, in the examples at right, breaks it. — AFC Vixen 🦊 07:35, 10 March 2026 (UTC)

@AFC Vixen as the syntax for |legendBox= appears to be text, size, position [,background, text color, options] with each parameter delimited by a comma, try leaving text out but leave the delimiting comma in; so your entry would start |legendBox=, 100px ... Nthep (talk) 08:20, 10 March 2026 (UTC)

This does the trick! Thank you very much! — AFC Vixen 🦊 08:25, 10 March 2026 (UTC)

Say I want template:centralized discussion to appear on the main page every time I go here. I could do this via javascript by loading the page fully, putting it into an iframe and then hiding everything except the template through CSS, but this is definitely not a bandwidth-efficient way of doing what I want. Can I instead just load https://en.wikipedia.org/wiki/Template:Centralized_discussion?action=raw&ctype=text/x-wiki and let MediaWiki convert it to HTML for me? sapphaline (talk) 18:26, 10 March 2026 (UTC)

Try action=parse. Suffusion of Yellow (talk) 18:31, 10 March 2026 (UTC)

https://en.wikipedia.org/w/api.php?action=parse&page=template:centralized%20discussion doesn't output just the template and nothing else. sapphaline (talk) 18:35, 10 March 2026 (UTC)

Use prop=text to filter out other stuff. parse.text is the template HTML. – SD0001 (talk) 18:48, 10 March 2026 (UTC)

Also might want to use text={{centralized_discussion}} instead of page=template:centralized_discussion to make the documentation go away. And if you really the want the response to just be the HTML with no JSON wrapping, use the REST API instead: https://en.wikipedia.org/w/index.php?api=mw-extra&title=Special%3ARestSandbox#/default/post_v1_transform_wikitext_to_html. – SD0001 (talk) 18:55, 10 March 2026 (UTC)

This is not a thing AFAIK. Izno (talk) 18:38, 10 March 2026 (UTC)

Done, though not with MediaWiki API. sapphaline (talk) 19:27, 10 March 2026 (UTC)

They seem to have removed the "p-namespaces" portlet menu from the legacy Vector skin; when and why? I noticed this when I realized that one of my scripts was broken because addPortletLink failed.

This is what $('.mw-portlet').toArray().map((el) => el.id); returns: (12) ['p-personal', 'p-associated-pages', 'p-variants', 'p-views', 'p-cactions', 'p-navigation', 'p-interaction', 'p-tb', 'p-coll-print_export', 'p-wikibase-otherprojects', 'p-lang', 'p-dock-bottom'] — DVRTed (Talk) 17:43, 7 March 2026 (UTC)

@DVRTed: I don't know why you mention "p-namespaces". It doesn't occur in your userspace. Your addPortletLink code is:

  mw.util.addPortletLink(
    "p-navigation",
    "#",
    "Zen",
    "ca-zenmode",
    "Enter distraction-free reading mode"
  );

That works for me in Vector legacy, e.g. when previewed alone in your common JavaScript. PrimeHunter (talk) 20:47, 7 March 2026 (UTC)

I now see you changed p-namespaces to p-navigation today. p-namespaces was apparently deprecated and has been removed. See phab:T409774 and phab:T414246. Use p-associated-pages instead if you really want to add a link there. WP:PORTLET doesn't recommend it. PrimeHunter (talk) 21:10, 7 March 2026 (UTC)

Oh, I forgot to put the permalink and edited the script after posting here, but thanks for the links! I think "p-associated-pages" is not supported on all skins either because the docs linked above says (For namespaces and special page tabs on supported skins), so I guess it's better to use another one. Seems like quite a few userscripts that'll silently stop working on legacy Vector now: regex search (not accounting for querySelector and dynamic id). — DVRTed (Talk) 21:30, 7 March 2026 (UTC)

DVRTed, or insource:/p-namespaces/ intitle:/\.js$/ (127, some false positives). — Qwerfjkltalk 13:19, 9 March 2026 (UTC)

Arrrggghhh. Thanks. That does explain why several of my user scripts are misbehaving — GhostInTheMachine ^{talk to me} 07:38, 11 March 2026 (UTC)

I want to search for edits which added a specific phrase to a given page. The problem is, the page has periodically been renamed (it's the user talk page of somebody who uses a bizarre manual archiving process). What I want is edits that were done to whatever was their user talk page at the time the edit was made. RoySmith (talk) 12:13, 11 March 2026 (UTC)

Link please? It is a bit hard to follow. Is the desired content still part of original edit history or was it copy/pasted and the original edit was lost somewhere else? In the latter case, it may be necessary to manually find the old revisions of the source and target pages in the history tab... Gryllida 12:52, 11 March 2026 (UTC)

Have you tried the "Find addition/removal" tool in the "View history" page? Its options can take a little practice to work with, but it may help. – Jonesey95 (talk) 13:56, 11 March 2026 (UTC)

I guess the user has repeatedly archived their talk page by moving it to different subpages. Help:Archiving a talk page/Details#Other procedures says: "The page move method is generally discouraged, as it breaks up page history". But it's not disallowed. You will probably have to search each page history separately. PrimeHunter (talk) 15:07, 11 March 2026 (UTC)

That is indeed what they've done. I've written a little python script to fetch the contents of all the individual pages to local disk files and I'm attacking it with grep and friends. RoySmith (talk) 15:12, 11 March 2026 (UTC)

The current content of the pages can be searched like notability prefix:User talk:RoySmith/, but it doesn't say how many hits there are on a page or which edit added it (there will usually be a signature). Most browsers have a way to search a viewed page for a string, e.g. Ctrl+f in Windows browsers. PrimeHunter (talk) 15:41, 11 March 2026 (UTC)

Hello. How do I make my list of archives into two side-by-side lists? GoodDay (talk) 16:31, 11 March 2026 (UTC)

@GoodDay {{Archive box|style=width:25em|1={{columns-list|colwidth=10em| ... }}}}, where ... is your list of archive pages. --Ahecht (TALK
PAGE) 17:36, 11 March 2026 (UTC)

It's at my talkpage. GoodDay (talk) 17:38, 11 March 2026 (UTC)

I have done the direct version of the suggestion above. It needed conversion to use a list format from the br format that you had on the page. Izno (talk) 17:45, 11 March 2026 (UTC)

Much appreciated, thanks. GoodDay (talk) 17:48, 11 March 2026 (UTC)

Is anyone else having problems with being logged out when they go to new pages? It's happened three times so far in about 10 pages visited this early afternoon, plus once on Commons, and just had uploading an image there get "loss of session data"-'d. Anything going on on the back end? - The Bushranger _{One ping only} 16:57, 11 March 2026 (UTC)

Yes, in addition I cannot log out, it claims a bad token. NightWolf1223 <Howl at me•My hunts> 17:06, 11 March 2026 (UTC)

I'm experiencing this one this morning. Izno (talk) 17:31, 11 March 2026 (UTC)

Yes, this is happening constantly to me right now. My session is restored after I refresh a couple of times or click "Log in", though. — Newslinger talk 17:57, 11 March 2026 (UTC)

Reload the page works for me, this can be as simple as returning to the previous page and clicking again. --Redrose64 🌹 (talk) 19:53, 11 March 2026 (UTC)

Is this something that started happening today? (I'd have some educated guesses if it started happening a week ago, not sure what changed this week.) Tgr (WMF) (talk) 20:01, 11 March 2026 (UTC)

Yes, today. The session issues seem to have slowed or disappeared now for me. Izno (talk) 20:02, 11 March 2026 (UTC)

Seems like this might have been a hardware issue (more details in T419764). Tgr (WMF) (talk) 20:31, 11 March 2026 (UTC)

I had assumed a dodgy connection where the login cookie was (a) not being sent; (b) corrupted en route; (c) not being interpreted correctly on arrival. --Redrose64 🌹 (talk) 20:50, 11 March 2026 (UTC)

Hi all,

The article Neatsville, Kentucky has racked up 3.1 million pageviews within 30 days. The issue on phab (from a year ago, when the issue wasn't as pronounced) theorized that there was some newsletter advertisement, but this seems insane for just a single/group of adverts.

I know next to nothing about the more technical side of Wiki, so I figured I would raise this to the attention of people who know what they're doing.

here are view statistics (2022 to present), and here is the issue on phabricator from a year ago. EatingCarBatteries _{(contribs | talk)} 01:39, 11 March 2026 (UTC)

I logged the Phab issue nearly two years ago but the theory you refer to was added last August. My current hunch is what's happening is similar to the Archive.today issue, where some pernicious code has been injected in websites, but this time, possibly via a trojan/virus (although it can still be determined individuals). Someone or some group may be testing a way to harm the Wikipedia with a DDOS-like access that grows so gradually that nobody figures it out to stop it before metastasizing into a real, massive problem that defies solution. Of course, as of today, whatever's been happening continues to be seemingly well-absorbed. By the way, if anyone thinks I'm being overly imaginative, who could have imagined what happened with Archive.today? I'm really just trying to apply Occam's razor. These cannot be real visitors for the most part - if they were, they would be editing the article way more! Stefen 𝕋ower ^{Huddle • Handiwerk} 02:23, 11 March 2026 (UTC)

Honestly, I'm not sure what else it might be other than what you mentioned. There is genuinely no point in bombarding Wikipedia with illegitimate traffic traffic other than to either test its network capacity (somehow) or to DDOS it (this is a far stretch from doing actual damage, so I'm more leaning towards the testing point). At least with archive.today, the guy had a bone to pick with the person publishing the blog, which makes sense (but still completely unjustified) why he would go after the guy.

The only other cause I could think of is some random really loves Neatsville, and he wants it to get to the top of the pageview statistics. But that is more unlikely than the former. EatingCarBatteries _{(contribs | talk)} 03:10, 11 March 2026 (UTC)

That or some piece of code is using that page to test internet connectivity (I seem to recall this happening in the past for an article about a tiny train station). --Ahecht (TALK
PAGE) 12:53, 11 March 2026 (UTC)

If this was about more or less the same degree of extra hits over time, I could see it's a test like that. But the recent tremendous spikes seems to defy this possibility, unless there has been a similar spike in some sort of Internet-accessing device. Stefen 𝕋ower ^{Huddle • Handiwerk} 21:26, 11 March 2026 (UTC)

I’ve always assumed that it’s not out of malice, but just incompetence. Somebody wrote some piece of code that just keeps scraping Neatsville because it was badly written. I vaguely recall that there is some other place name in Kentucky or Tennessee that gets visits because it is linked in an Imgur ad campaign, or something like that, for some reason. My assumption with the reason ChatGPT is routinely one of the most-visited articles is that ChatGPT is stupid and so sometimes has to look up why it is when it is queried. I've also seen Google Chrome be one of the most visited articles and I’ve just assumed that some scraper forgot to change the "example" part on their code and keeps running it. Hanlon's razor instead of Occam's. 1brianm7 (talk) 07:42, 11 March 2026 (UTC)

I considered whether this could be an uncaught test. But the long-term aspect of the problem along with the recent insane amplification of the views makes me return to the malice side. To test all our hunches, perhaps we should blow this up into a big media story, which would include a demand that whoever is doing this, whether accidentally or intentionally, needs to fix it or cut it out. Maybe I'll do a comedy podcast about it. :) Stefen 𝕋ower ^{Huddle • Handiwerk} 21:20, 11 March 2026 (UTC)

Just typical modern bot/crawler stuff. sapphaline (talk) 08:15, 11 March 2026 (UTC)

I guess so, but it still seems insane that all of this traffic would focus onto this one obscure article. EatingCarBatteries _{(contribs | talk)} 20:58, 11 March 2026 (UTC)

Vastly overcrawling one article while almost all others get normal views doesn't quite fit "typical" to me. Stefen 𝕋ower ^{Huddle • Handiwerk} 21:15, 11 March 2026 (UTC)

I distinctly remember a similar problem at Mount Takahe a few years ago. Jo-Jo Eumerus (talk) 12:04, 11 March 2026 (UTC)

This is the second time within a week that I've misjudged someone's edit because the diff in mobile view was wrong. Take a look at this edit to Malaysian Malay in both desktop and mobile views. Desktop view clearly shows that one ancestor2 infobox parameter was replaced by another, and the source code at the revision created by that edit confirms that there's only one ancestor2 parameter.

But I was reviewing my watchlist on my phone, and what the mobile view of the diff showed was an extra ancestor2 parameter being added while leaving the one that was already there in place. Based on that, I reverted the edit as an error, explained in my edit summary along with a suggestion that the other editor might want to "Try again?" But right after that it occurred to me to check what the actual source code had been and I found that the diff lied to me and that the edit had been fine, so I restored it. Largoplazo (talk) 23:10, 2 March 2026 (UTC)

This is some flavor of phab:T349335. Izno (talk) 23:15, 2 March 2026 (UTC)

@Largoplazo: The mobile diff is supposed to show an indicator that a paragraph was moved. It's an inline diff and shows the paragraph at both the before and after location. So does a two-column desktop diff but there it's shown in a before and after column. I can see hover text "Paragraph was moved. Click to jump to new location." for the indicator on a blank line and click it but not see the actual indicator. I think the only error is that the indicator is invisible. I can toggle "Inline" in the desktop diff to see an inline diff where an indicator is visible as arrows. wikEdDiff at Special:Preferences#mw-prefsection-gadgets gives a better diff. Sometimes it gives a worse diff but the normal diff is still shown and wikEdDiff just adds an option to see an alternative diff. I recommend it. PrimeHunter (talk) 19:02, 3 March 2026 (UTC)

Or w:de:Benutzer:Schnark/js/diff (for alternative diff). — Qwerfjkltalk 12:31, 4 March 2026 (UTC)

@PrimeHunter Are you talking about hover text in mobile view? (That only works if your mobile has a mouse, or of course if you're in mobile view on a desktop.) David10244 (talk) 04:33, 7 March 2026 (UTC)

No. Largoplazo (talk) 05:21, 7 March 2026 (UTC)

@David10244 and Largoplazo: Yes, I meant hover text in mobile view. If you don't have a way to display hover text then try holding for a second on the blank line above | script. I get a box with a url ending with #movedpara_5_0_rhs. This indicates a paragraph was moved. Tapping on the blank line jumps to the new location of the paragraph (where colored backgrounds show that ancestor2 was changed to ancestor3). It's annoying that the indicator is missing on the blank line so you have to guess there may be something there. PrimeHunter (talk) 10:13, 7 March 2026 (UTC)

@PrimeHunter Oh, I didn't know how to "hover" on a phone. Thanks! David10244 (talk) 02:58, 11 March 2026 (UTC)

@David10244: It's not a hover. It's a way to see where a link goes. The hover text for the link is "Paragraph was moved. Click to jump to new location." PrimeHunter (talk) 03:39, 11 March 2026 (UTC)

@PrimeHunter Thanks, that makes sense. David10244 (talk) 13:12, 12 March 2026 (UTC)

The cite template feature in the default toolbar of the source editor is broken. I have reported it at Wikipedia talk:RefToolbar#RefToolbar is broken. PrimeHunter (talk) 20:39, 12 March 2026 (UTC)

Fixed by Pppery. PrimeHunter (talk) 20:51, 12 March 2026 (UTC)

The link Rhoticity in English § /ɔː/–/ɔr/ merger (meant to be the target of Caught-court merger) takes me to /oʊ/–/ʊər/ merger instead. That link takes me to Effect of non-rhotic dialects on orthography, the link to which sends me straight to the references section. If this isn't apparent for you, try using these section links with the legacy Vector skin on a maximized Firefox window on Windows 10 on a 1920x1080p monitor, if all of those are available to you. – MrPersonHumanGuy (talk) 20:03, 13 March 2026 (UTC)

@MrPersonHumanGuy: The page jumps around for me very quickly and ends in the right place but it can vary by browser and circumstances. It's a common issue when there is collapsible content earlier in the page. The browser first jumps to where the anchor (section heading) is positioned at the time but then collapses or uncollapses something earlier in the page so it should no longer be the same distance from the top. The browser may or may not adjust the position after this. PrimeHunter (talk) 20:32, 13 March 2026 (UTC)

Seconding PrimeHunter. I believe this is entirely because of the collapsed tables within the article-sections above those link-targets. I.e. The links initially scroll to the correct place, but then the tables collapse afterwards [IIUC, this is because of how JavaScript runs after the browser has completed the HTML rendering?] which means the content gets moved. I think we probably need some kind of clearer warnings/explanations within MOS:DONTHIDE about this? I wrote a related essay years ago at mw:User:Quiddity/Collapsing and hiding that might be useful if anyone wants to document it formally (or improve/adapt the essay). HTH. Quiddity (talk) 20:34, 13 March 2026 (UTC)

If you click in the address bar and press enter then your browser probably jumps to the right place. It jumps to the section again and this time the collapsing is done. PrimeHunter (talk) 21:34, 13 March 2026 (UTC)

I am trying to run off statistics on pages views for Category:History of the Paralympic movement in Australia articles but the massviews tool but I am getting "An unknown error occurred when querying" Anybody know what is going on? Hawkeye7 (discuss) 23:19, 14 March 2026 (UTC)

@Hawkeye7: It's discussed at meta:Talk:Pageviews Analysis#Massviews not returning any results. PrimeHunter (talk) 23:57, 14 March 2026 (UTC)

Thanks for that! I will keep an eye on it. Hawkeye7 (discuss) 00:24, 15 March 2026 (UTC)

Is there an easy way (such as a bot) to fix "spaghettified" discussions such as has occured at Talk:Canadian Indian residential school system? IOHANNVSVERVS (talk) 09:37, 14 March 2026 (UTC)

Probably possible, but such things are quite controversial; see Wikipedia:Bots/Requests for approval/IndentBot for an example. — Qwerfjkltalk 15:25, 14 March 2026 (UTC)

The default toolbar of the source editor has search and replace on a magnifying glass icon to the right. It can be used to replace a large number of colons with nothing. PrimeHunter (talk) 16:52, 14 March 2026 (UTC)

@Sapphaline, can I ask what method you used in your edit fixing the indentation? And thank you for doing so. IOHANNVSVERVS (talk) 22:25, 14 March 2026 (UTC)

Manual copy-paste and comparing between page's code and rendered output. sapphaline (talk) 09:23, 15 March 2026 (UTC)

I see. Too bad there's not an easier way. Thanks again. IOHANNVSVERVS (talk) 11:27, 15 March 2026 (UTC)

Recently a parameter was added to {{Sidebar person}} to allow the "a series" text to link to the main category for the person, much as it's linked in sidebars like {{Shinto}} or {{Liberalism sidebar}}. Unfortunately the link remains blue, ignoring the font colour which is applied elsewhere. I've tried various things in the template sandbox, but none worked. Could someone better at programming templates take a look and see if there's a way for the link to use |font_color= when |series_category=yes is set? – Scyrme (talk) 00:01, 15 March 2026 (UTC)

@Scyrme: Link colors can only be changed inside a piped link. Special:ExpandTemplates shows {{Shinto}} produces [[:Category:Shinto| <span style="color:White;">a series</span>]] — Preceding unsigned comment added by PrimeHunter (talk • contribs) 01:26, 15 March 2026 (UTC)

Redoing ping to @Scyrme: for @PrimeHunter:. Graham87 (talk) 05:54, 15 March 2026 (UTC)

Or by changing the color with WP:TemplateStyles. Izno (talk) 06:12, 15 March 2026 (UTC)

OK, that's possible but too much work. If you want to use a template then just use {{Colored link}} which uses the piped link method. PrimeHunter (talk) 13:07, 15 March 2026 (UTC)

Thanks for the answers, though it turned out my mistake was using {{colored link}} around a link including the brackets rather than replacing the brackets with the template. Seems to work now. – Scyrme (talk) 17:07, 15 March 2026 (UTC)

Is there a way to search for edit summaries (e.g., all edit summaries in the mainspace during the last month)? I'd like to have a list of diffs in which the edit summary mentions WP:ONUS (the shortcut). WhatamIdoing (talk) 03:15, 10 March 2026 (UTC)

No easy or fast way. quarry:query/102943. A similar search in all namespaces is fairly badly polluted by instances of "REVISIONUSER". —Cryptic 03:35, 10 March 2026 (UTC)

Maybe REPLACE(comment_text, 'REVISIONUSER', '') LIKE '%ONUS%'. Legoktm (talk) 01:47, 11 March 2026 (UTC)

comment_text RLIKE '\\bONUS\\b' would've done it, but the query took close to ten minutes the first time - the copy on Quarry only seems fast because it was cached - so it didn't seem worth running again. —Cryptic 02:11, 11 March 2026 (UTC)

If you're into command-line stuff, there is a denormalized dump of every edit, broken down by month. See wikitech:Data Platform/Data Lake/Edits/MediaWiki history. It's not trivial to get your head around the data organization, and you need a cloud account to access, but it's good for things like this. I ran bzgrep ONUS 2026-02.enwiki.2026-0* which took a little under 5 minutes and found 1169 lines. If you want, I could email you a copy. RoySmith (talk) 12:05, 11 March 2026 (UTC)

If "a copy" means a human-readable text file, then I'd be very happy to have that in e-mail. WhatamIdoing (talk) 04:36, 14 March 2026 (UTC)

Thanks. In case anyone's curious, after removing false positives (mostly REVISIONUSER, but also words like bonus) and discussions where we are talking about WP:ONUS but not invoking it, there were ~353 uses left (during the first two months of this year). WhatamIdoing (talk) 22:37, 15 March 2026 (UTC)

MediaWiki message delivery 19:33, 16 March 2026 (UTC)

I fixed a missing bracket in a failed verification template with the weird result that the article text included [[Category:Articles with failed verification from March 2026}]]. I can't spot anything that I have done wrong (doesn't mean that hasn't happened), but I am guessing something else caused this. ThoughtIdRetired _TIR 09:52, 12 March 2026 (UTC)

@ThoughtIdRetired see the subsequent edit by AnomieBOT, I think that will explain it for you. Nthep (talk) 10:36, 12 March 2026 (UTC)

@ThoughtIdRetired: Or even the previous edit, which shows the |reason= parameter being dropped between the two closing braces instead of before them. --Redrose64 🌹 (talk) 22:18, 12 March 2026 (UTC)

Yes, that was my fat fingers on the keyboard, followed by a complete inability to spot the problem. I'll just slink away in embarrassment. ThoughtIdRetired _TIR 23:07, 12 March 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:52, 16 March 2026 (UTC)

Not sure what happened exactly, but all transparent PNG images on wikipedia are now showing up blurry. You can see this particularly with Kratos (God of War), where both the infobox and lower image are blurry, despite previously being perfectly fine. Kung Fu Man (talk) 01:32, 13 March 2026 (UTC)

Seems to be effecting "png" formats as well beyond transparent ones. BGC OVA.png for example is blurry even on its preview page. It is also happening with some jpegs. Like this file (heads up, this file has some uhh imagery that is "unfortunate" to put it lightly.) here which is a jpeg which is also compressed on its own article and the preview page, but on clicking on it, it retains its quality. Andrzejbanas (talk) 14:24, 13 March 2026 (UTC)

This affects, from what I've seen, every jpg file whose width is less than 250 px. ภץאคгöร 23:24, 13 March 2026 (UTC)

Ah. Perhaps it's due to the recent change to allow only certain image widths to be served, instead of anything-you-like. See Wikipedia:Village pump (technical)/Archive 226#Tech News: 2026-05, bullet beginning Image thumbnails that are requested in non-standard sizes. --Redrose64 🌹 (talk) 23:41, 13 March 2026 (UTC)

Blurry thumbnails on sports uniform / kit template images

Hello,

I noticed that many uniform template images used in sports infoboxes (such as Template:Baseball uniform and Template:Basketball kit) recently started appearing blurry on article pages, even though the original files on Commons have not changed.

This affects files uploaded by multiple users, not just my own, and the issue seems to only occur in the thumbnails. When clicking the file and viewing it on Commons, the image appears sharp.

Examples where this occurs:

Files I uploaded:

United States national baseball team

Puerto Rico national baseball team

United States men's national basketball team

Files uploaded by other users:

Cuba national baseball team

Japan national baseball team

There are many more examples all related to this kit templates, and possibly to other types of images and templates in lower resolution.

The ones I noticed though are images are used in Template:Baseball uniform, Template:Basketball kit, and similar templates.

Since the originals are unchanged and only the thumbnails look blurry, this may be related to thumbnail rendering or a recent MediaWiki change.

Is this a known issue, and is there a way to restore the previous thumbnail quality? ANTbook365 (talk) 13:34, 13 March 2026 (UTC)

ANTbook365, see the post directly above. Regards KylieTastic (talk) 13:40, 13 March 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:53, 16 March 2026 (UTC)

Doubt

Why do the images look very blurry when viewed in an article and as a file page, but they actually look HQ when the file is viewed like this ? Is this a new optimisation to improve performance or to tackle copyright restrictions? What is the reason behind images turning this blurry? Manick22 (talk) 12:35, 14 March 2026 (UTC)

@Manick22: It's a recent bug. See #Transparent PNGs appear broken on wikipedia. PrimeHunter (talk) 12:39, 14 March 2026 (UTC)

When will this be fixed? This one looks very blurry! Manick22 (talk) 12:46, 14 March 2026 (UTC)

After the weekend. —TheDJ (talk • contribs) 13:40, 14 March 2026 (UTC)

@TheDJ Oh, okay. Thanks for the reply! Manick22 (talk) 13:49, 14 March 2026 (UTC)

@TheDJ and PrimeHunter: It seems that not only png, the others file include jpg, jpeg, webp also have the same problem (the images look very blurry) and not only happen in english wikipedia, the chinese wikipedia have the same problems. Thanks. Stevencocoboy (talk) 07:28, 16 March 2026 (UTC)

Appears to now be fixed, though you may need to purge the page to force the image to get unstuck. --PresN 21:11, 16 March 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 23:52, 16 March 2026 (UTC)

I'm trying to run a Quarry search for pjge titles that mix Devanagari with other scripts, but I can't figure out why it doesn't match anything. In particular, it should have found the deletion log entry for भोजपुरी language. Replacing with a different regex seems to work, but prepending "\b" fails.

SET @pat1='\P{L}*\p{Devanagari}.*[^\p{Devanagari}\P{L}].*';
SET @pat2='\P{L}*[^\p{Devanagari}\P{L}].*\p{Devanagari}.*';

WITH ns(ns_n, ns_s) AS (VALUES (-2, 'Media:'), (-1, 'Special:'), (0, ''), (1, 'Talk:'), (2, 'User:'), (3, 'User talk:'), (4,
  'Wikipedia:'), (5, 'Wikipedia talk:'), (6, ':File:'), (7, 'File talk:'), (8, 'MediaWiki:'), (9, 'MediaWiki talk:'), (10, 'Template:'),
  (11, 'Template talk:'), (12, 'Help:'), (13, 'Help talk:'), (14, ':Category:'), (15, 'Category talk:'), (100, 'Portal:'), (101,
  'Portal talk:'), (118, 'Draft:'), (119, 'Draft talk:'), (126, 'MOS:'), (127, 'MOS talk:'), (710, 'TimedText:'), (711, 'TimedText talk:'),
  (828, 'Module:'), (829, 'Module talk:'))
SELECT CONCAT('[[',
              COALESCE(ns_s, CONCAT('{{ns:', page_namespace, '}}:')),
              REPLACE(page_title, '_', ' '),
              ']]') AS title,
       EXISTS (SELECT 1
               FROM page p2
               WHERE p2.page_namespace = sq.page_namespace
                 AND p2.page_title = sq.page_title) AS existing,
       COUNT(log_namespace) AS `times deleted`,
       GROUP_CONCAT(log_timestamp SEPARATOR ' // ') AS `deletion timestamps`,
       GROUP_CONCAT(comment_text SEPARATOR ' // ') AS `deletion comments`,
       (SELECT GROUP_CONCAT(comment_text SEPARATOR ' // ')
        FROM logging_logindex
        JOIN comment_logging ON comment_id = log_comment_id
        WHERE log_namespace = page_namespace
          AND log_title = page_title
          AND log_type = 'protect'
          AND log_action = 'protect'
          AND log_params LIKE '%create=%') AS `salt comments`
FROM (SELECT page_namespace, page_title
      FROM page
      WHERE (REPLACE(page_title, '_', ' ') RLIKE @pat1
             OR REPLACE(page_title, '_', ' ') RLIKE @pat2)
         AND page_namespace NOT IN (1,2,3,4,5,6,7)
      
      UNION DISTINCT

      SELECT ar_namespace, ar_title
      FROM archive
      WHERE (REPLACE(ar_title, '_', ' ') RLIKE @pat1
             OR REPLACE(ar_title, '_', ' ') RLIKE @pat2)
         AND ar_namespace NOT IN (1,2,3,4,5,6,7)) sq
LEFT JOIN logging_logindex
       ON log_namespace = page_namespace
      AND log_title = page_title
      AND log_action = 'delete'
      AND log_type = 'delete'
LEFT JOIN comment_logging ON comment_id = log_comment_id
LEFT JOIN ns ON ns_n = page_namespace
GROUP BY page_namespace, page_title
ORDER BY `existing` DESC, page_namespace ASC, page_title ASC;

–LaundryPizza03 (dc̄) 05:12, 17 March 2026 (UTC)

Your backslashes aren't escaped. —Cryptic 05:24, 17 March 2026 (UTC)

Fixing this caused a lengthy delay and a replication lag, and still returned no results. Do I need to escape any characters other than the backslash? –LaundryPizza03 (dc̄) 06:31, 17 March 2026 (UTC)

No. The reason you're not getting results is that you forked from one of the versions of this query where the pattern I was matching didn't have to worry about non-Latin characters - which is admittedly most of them - so you'll have to explicitly convert page_title and ar_title to utf8. quarry:query/84985 was the first I found that does that, though most of the rest of it is outdated. And of course it was slow; not only does it have to do full table scans of both page and archive, both your regexes are catastrophically slow - the ending .* will be optimized away, but the initial \P{L}* likely won't be, and removing both won't change what they match. —Cryptic 07:05, 17 March 2026 (UTC)

Also, if you just want mainspace matches, or mainspace and category and template or whatever, say so - page_namespace = 0 or page_namespace IN (0, 10, 14) will be (partially) indexed, page_namespace NOT IN (1,2,3,4,5,6,7) tends not to be; and while a single blacklist regex has to match a candidate by itself, which is why they're written in pairs like (Devanagari character eventually followed by non-Devanagari letter) or (non-Devanagari letter eventually followed by Devanagari character), these queries don't: you're way better off with matching both "Devanagari character" and "non-Devanagari letter". SELECT COUNT(*) FROM page WHERE page_namespace=0 AND CONVERT(page_title USING utf8) RLIKE '\\p{Devanagari}' AND CONVERT(page_title USING utf8) RLIKE '[^\\p{Devanagari}\\P{L}]'; completed in 20 seconds, and the version for archive in 39. —Cryptic 07:42, 17 March 2026 (UTC)

This returned lots of false positives with U+02BC ʼ MODIFIER LETTER APOSTROPHE, which is used in the Boro and Dogri languages, so I had to exclude that as well. The completed query for article and draft space can be found at quarry:query/103274. –LaundryPizza03 (dc̄) 08:07, 17 March 2026 (UTC)

WikiBlame seems to be broken. I almost always get "Your search term was not found at all. Check the settings and try again." I tried different search terms, different pages, different wikis, searching for wikitext or full text. Always the same result. It's been like this for a couple of days now, maybe a week. (Half an hour ago, it seemed to be working for a few minutes, but now it's broken again.) I also opened a GitHub issue. — Chrisahn (talk) 23:39, 15 March 2026 (UTC)

An example article and search text that failed would be useful. Johnuniq (talk) 06:48, 16 March 2026 (UTC)

I just visited John Draper and clicked "Find addition/removal" in history, then entered software engineer in 'Search for' and pressed Enter. In under a minute it found the addition on 02 March 2025. That is, it works for me. Johnuniq (talk) 06:53, 16 March 2026 (UTC)

Thanks for your response! There's been an overlap, @Flominator fixed the issue about an hour before you tested it. Thanks! — Chrisahn (talk) 09:02, 16 March 2026 (UTC)

 Done Fixed, see GitHub issue. — Chrisahn (talk) 09:03, 16 March 2026 (UTC)

Thanks for reporting that and getting it fixed. Apparently the fix was to set the newly required user agent. Johnuniq (talk) 10:08, 16 March 2026 (UTC)

I'm surprised anybody is still using WikiBlame. I recommend installing the Who Wrote That? extension instead, it's so much better and saves a lot of time. Am I right, Johnuniq? Bishonen | tålk 20:23, 16 March 2026 (UTC).

WWT does not work outside of mainspace last I checked. Wikiblame, and User:Daniel Quinlan/Scripts/Blame, do not have this limitation. Izno (talk) 21:15, 16 March 2026 (UTC)

I've been using w:de:Benutzer:Schnark/js/wikiblame which appears to be similar to that Blame script. — Qwerfjkltalk 22:27, 16 March 2026 (UTC)

@Bishonen: My life is sufficiently exciting without trying new things! But maybe later I'll have a look. Johnuniq (talk) 00:08, 17 March 2026 (UTC)

@Izno:, you're right, but I suppose you and I live different lives; I can't remember ever wanting to know when something was added except in mainspace. A problem for others, though, may be that Who Wrote That? only works (or is only optimized for, whatever) Chrome and Firefox. @Johnuniq:, once you've tried WWT, you'll find digging through WikiBlame almost intolerably unexciting. Bishonen | tålk 10:44, 17 March 2026 (UTC).

Most times I open wikipedia I log in and go to my watchlist to see what changes have been made to the watched pages. I will then look at those changes. If there have been a lot of changes to a page I might look at a few and leave the rest til later. Until recently the watchlist would still show that page with a black dot to show there were changes I hadn't seen. Recently the list has shown a white (unfilled) dot and I haven't found a way to alter it. Is there anything I can do? Is this a universal change, or have I made a change to "preferences" or something inadvertantly? Spinney Hill (talk) 09:27, 11 March 2026 (UTC)

@Spinney Hill Hi. I think I understand what you're describing, but I want to verify before I file a bug (or encourage you to file a bug, if you'd like). Please confirm this is an accurate description: In phab:F72822789, I'm showing two screenshots, where I've clicked on "1", and where you would expect that only "2" is marked as "seen". is that right? Also, do you (or anyone) have a more specific sense of when this behaviour changed (this week, last week, or longer)? With those clues, it should be sufficient to file a useful bug-report. [I searched, and can't see any existing tasks that precisely match.] Cheers, Quiddity (WMF) (talk) 18:33, 12 March 2026 (UTC)

I'm not sure if I understand you -If the list is the history of an article I have looked at 1628 1641 and 1649 and then done something else. What should happen when I go back to that history is the entries for 1653 and 1659 are shown as not looked at but recently they have been shown as looked at so its difficult to see where I have got to in the history. Does that make sense. It happened in the last week I think. Spinney Hill (talk) 18:50, 12 March 2026 (UTC)

I think I'm probably out of my depth here so I would rather you logged the bug. Spinney Hill (talk) 18:52, 12 March 2026 (UTC)

In the mean time the watchlst shows the article is shown as looked at instead of not looked at. I first noticed this on Haymarket Theatre Leicester when a large number of edits were made on the same day and I had only looked at ten of them. The sytem showed I had looked at them all Spinney Hill (talk) 20:23, 12 March 2026 (UTC)

@Spinney Hill: They shouldn't be a black dot, they should be green, per the message

Pages that have been changed since you last visited them are shown in bold with a green marker.

Black dots are for the diffs that you've visited.

I had the opposite - normally, diffs not looked at are bolded/green-dotted until I refresh the watchlist; today I found that some edits remained bold/green-dotted even though I had visited the diff. One page that this happened with was Wikipedia:Village pump (technical). --Redrose64 🌹 (talk) 22:02, 12 March 2026 (UTC)

@Redrose64 I believe that what we each see by default will vary, because there's a default gadget (but that is "(unavailable with the improved Watchlist user interface)") that adjusts those aspects.

@Spinney Hill & Redrose64: I've filed phab:T419918 with what I think is the most broadly-applicable description. I don't recall how exactly it worked before today, but hopefully that task will provide enough clues to unearth whatever is causing the change. Hope that helps. Quiddity (WMF) (talk) 22:59, 12 March 2026 (UTC)

Thanks for the above. I've never seen any green marker --green text yes. Spinney Hill (talk) 09:16, 13 March 2026 (UTC)

Was it one of Parkinson's Laws that "Improvement = deterioration)? Spinney Hill (talk) 09:20, 13 March 2026 (UTC)

Re: The bug: it has been identified and patched (thanks to matmarex), and will be fixed onwiki next week. (Details in the task on Phabricator)

Informal addendum, re: Parkinson's Laws: I'm not sure, but you've reminded me of this hacker-laws compilation that I recently found interesting/amusing (and it primarily links here to Wikipedia, which is nice). [Caveat that it's also rife with oversimplifications, of course!]. Closely related to our List of eponymous laws, but topically-focused and expanded. Quiddity (WMF) (talk) 18:47, 13 March 2026 (UTC)

Hutber's Law is the closest according to the Wp list. Thanks to everybody Spinney Hill (talk) 11:25, 17 March 2026 (UTC)

Hey folks. For a line break in an article -- in the infobox, or in the body of the article -- is it better to use an HTML break tag (i.e. <br> or <br />) or a break template (i.e. {{break}}), and why? Or does it not make any difference? — Mudwater ^(Talk) 17:14, 16 March 2026 (UTC)

Depends. WP:NOBR is relevant if what you're making is a list. Otherwise, HTML br is fine generally. Izno (talk) 17:41, 16 March 2026 (UTC)

<br> is preferable. <br /> is unnecessary XHTML syntax, and {{break}} is intended only for cases where you can't use the tag directly. sapphaline (talk) 17:57, 16 March 2026 (UTC)

Note that this markup shouldn't be used to create unbulleted lists; use one of the list templates. sapphaline (talk) 18:01, 16 March 2026 (UTC)

@Sapphaline: <br> is fine with me, but why do you say that it's preferable to the template? — Mudwater ^(Talk) 18:14, 16 March 2026 (UTC)

or
<br /> is preferable. <br> generates syntax highlighting errors in the editor. . In many cases, it is better to use a list template, such as {{UBL}} or {{hlist}} — GhostInTheMachine ^{talk to me} 20:51, 16 March 2026 (UTC)

Which editor? Do you mean the old syntax highlighting gadget? Jack who built the house (talk) 20:53, 16 March 2026 (UTC)

The editor that I use seems to be called the "2010 wikitext editor". It does get quite upset by plain <br> tags — GhostInTheMachine ^{talk to me} 21:05, 16 March 2026 (UTC)

You are likely using Dot's syntax highlighter. It is an issue in this way. Izno (talk) 21:13, 16 March 2026 (UTC)

And if not Dot, then potentially WP:WIKED. Either way, my opinion is that neither of these are necessary today, the tools one might use with them are available in what MediaWiki supports now. You should consider trying those and ditching whatever you do have installed. Izno (talk) 21:19, 16 March 2026 (UTC)

No explicitly loaded external stuff, just the standard "2010 wikitext editor" plus the alternative Syntax highlighter via enabling the gadget in Preferences. i.e. "Dot's". Turning off the gadget reverts to the "standrd" highlighter, which does not care about <br> vs. <br />, but (after using the gadget version for a while) now looks rather horrible </digression> — GhostInTheMachine ^{talk to me} 09:14, 17 March 2026 (UTC)

@Mudwater: To return to the original question: as far as our readers are concerned it makes not one scrap of difference. The <br> tag was introduced in HTML 2.0 way back in 1995, and is valid in all subsequent versions of HTML, but not XHTML (unless followed directly by the closing </br> tag). The <br /> tag first appeared in XHTML 1 (2000) and is also valid in HTML 5 (2014) as an optional variant of <br>. The {{break}} template emits one or more <br /> tags, and browsers simply do not care (or know) whether these tags were typed directly or emitted by a template, function, macro or other typing aid. The MediaWiki software serves HTML 5, and normalises <br /> tags (however produced) to the <br> form.

The missing question - that others are attempting to answer - is this: where are you using these tags? Is it to emit a cosmetic newline, or to make a list? If the former, that's OK; but if the latter, MOS:NOBR applies everywhere - in infoboxes, prose and talk page discussions. --Redrose64 🌹 (talk) 22:29, 16 March 2026 (UTC)

Yes, Redrose64, and everyone else, I should have stated this clearly before now. I would not use breaks to make a list, I would use a template such as {{plainlist}}, or just use asterisks or pound signs to create bulleted or numbered lists, respectively, with regular Wikipedia markup. — Mudwater ^(Talk) 23:09, 16 March 2026 (UTC)

Here's a bit more background: I saw this edit, and started to wonder if there's a reason to prefer either the HTML or the break template. The readers can't see the difference, and I haven't heard any technical reasons either way, so perhaps it's just a matter of editorial preference. But if so, some editors might be able to explain why they have a preference. I'd be interested in hearing any. Otherwise I won't worry about it too much. — Mudwater ^(Talk) 23:15, 16 March 2026 (UTC)

This is a cosmetic newline between two parts of an address. I would say that <br /> is fine to use in this instance. --Redrose64 🌹 (talk) 23:34, 16 March 2026 (UTC)

If people find bare HTML upsetting, then using the {{break}} template (or the {{br}} alias) is fine too. I really do not see any need for an edit that switches between tags and templates (or the other way) — GhostInTheMachine ^{talk to me} 11:52, 17 March 2026 (UTC)

The Mobile Apps team is exploring what should happen when an app user taps "Edit" on an article, and input from your community would be valuable. The context is summarized below, and full information can be found on the Future of Editing on the Mobile Apps page. The plan is to make sure app users edit in the mobile web editor from within the app, where we have better editing tools.

Problem definition

The Wikipedia mobile apps were originally built as reading tools. Reading features and native app capabilities are the primary motivation for users to download them, and remain the driving factor for high reader retention. In the last several years native editing experiences were added to the Wikipedia apps to meet user requests. A challenge has been the absence of VisualEditor in the apps, which is the result of technical constraints; it would take several years to build a functional native WSYWIG editor. The lack of VisualEditor has meant anyone who opens an article to edit is immediately confronted with raw wikitext, which resembles code and leads many newcomers to assume editing requires technical knowledge. Research confirms that despite investments in improvements to the native editor, the lack of VisualEditor creates a barrier to editing articles in the absence of structured tasks like Suggested Edits. Additionally, community spaces like the Teahouse and Help Desk are difficult to access from within the apps due to it being outside of the main namespace.

Context: the reader strategy

The Wikimedia Foundation is placing more emphasis on improving reading experiences alongside editing, with the goal of supporting readership, attracting new users and retaining them. We can’t rely on readers finding us through search engines the way we have been used to, and have to find new ways to attract readers who keep coming back to the wikis – some of whom might become editors in the future.

As part of this direction, the apps are being developed primarily as a strong reading experience for active readers, with more emphasis on features such as personalized discovery using local device data, daily reader engagement opportunities, and deeper connections to content.

At the same time, improvements to editing tools are increasingly being made on the web. This includes features such as Edit Check in the VisualEditor, Suggested Edits, and the Newcomer homepage, which aim to make editing more accessible and supportive for contributors.

This context matters for editor recruitment. The apps attract new readers every year, do a good job at retaining them, and there are plans to increase app visibility. Many editors make their first contributions by correcting small errors while casually reading — if those moments of impulse happen inside the app and a newcomer encounters wikitext without the option of VisualEditor, it may discourage them before they establish a foothold. The Reader and Contributor teams at the Wikimedia Foundation are working together on this, and introducing editing is particularly important on the apps, where a large share of users visit daily, and daily users are most likely to try editing – for example, 3% of readers became new editors with unreverted edits after they learned they could edit through the new app Activity Tab feature.

What's being considered

The team is exploring ways for users to continue editing in mobile web from within the app, where VisualEditor and other more fully-featured tools are available. There are open questions about how to do this effectively.

Questions the team would especially like input on

• What are the most critical editing workflows or community spaces that need to be accessible (even via redirect) from within the app?
• If the mobile web editor was accessible from the app, should the Mobile Apps eliminate the native source editor and suggested edits altogether?
• For editors who have tried editing on the app: at what point did the experience fall short, and would access to VisualEditor / mobile web have changed that?
• Are there aspects of the handoff from app to mobile web editor that would be most important to get right?
• What should that transition feel like? A prompt, a redirect, a wrapped in web experience? What should the tone of the redirect take if we are sending people out of the app to provide the least jarring experience?
• For editors who guide newcomers: how often does the app come up as a first editing environment, and what problems follow from that?

The full discussion page is at mw:Talk:Wikimedia Apps/Team/Future of Editing on the Mobile Apps. Feedback on this post is also welcome.

--ARamadan-WMF (talk) 12:37, 17 March 2026 (UTC)

Something odd is going on when searching for pages in the Wikipedia:Project namespace using VisualEditor. The word Wikipedia is showing up with a lowercase w and the search results are displaying results for the project page's name if it was in mainspace, as seen to the right. mdm.bla 21:56, 16 March 2026 (UTC)

It looks like the search field wants to interpreted the input as an interproject link to Wikipedia, despite being on Wikipedia already. For example, on Wikimedia Commons, the wikitext to produce a link to this Village pump page is [[wikipedia:Wikipedia:Village pump (technical)]] (note the repetition of the word "Wikipedia"). —⁠andrybak (talk) 22:16, 16 March 2026 (UTC)

Filed as phab:T420288. Thanks both for the details. Quiddity (WMF) (talk) 23:45, 16 March 2026 (UTC)

As a workaround you can use the namespace aliases WP or Project instead of Wikipedia. PrimeHunter (talk) 00:25, 17 March 2026 (UTC)

This has been fixed and deployed. ESanders (WMF) (talk) 14:40, 17 March 2026 (UTC)

Thank you very much! mdm.bla 14:55, 17 March 2026 (UTC)

https://github.com/greencardamom/Wikiurl

wikiurl is a high-performance, multi-engine command-line tool for extracting URLs from Wikimedia projects. It allows you to search on specific domains across various wikis and output the results in multiple formats (TSV, JSONL, raw SQL, or article title list). At maximum, you could download all URLS across all 800+ wikis.

Notable for being written in Nim, it compiles to Linux, Mac or Windows binaries, and uses GitHub to do the compilation step, so users have safety downloading the executable. Being Nim it compiles to highly optimized C code which is then compiled to binary by GCC. It provides 4 options how to retrieve the URLs: API, SQL, Dump Download and Dump Streaming - each engine has pros and cons depending on nature of request. -- GreenC 21:11, 16 March 2026 (UTC)

Very interesting, and well documented at github. Thanks! Johnuniq (talk) 00:41, 18 March 2026 (UTC)

Hi everyone,

Back in November we shared that the Reader Experience team was conducting an experiment to bring reading lists to the desktop and mobile web browser experience. We are back with updates and next steps.

We are experimenting with potential improvements to the reader experience because of declining pageviews to Wikipedia and fewer readers returning to the site. We think by strengthening the connection between existing readers and Wikipedia, we can help reverse these trends and help engage potential future editors. One way to build that relationship is by giving readers more ways to shape their reading experience. Reading lists will allow for that participation by giving logged-in readers the option to save articles they want to come back to later in a list accessible in their account. The feature is already highly utilized on the Apps, where it has contributed to improved reader retention.

The experiment went live on Arabic, Chinese, English, French, Indonesian, and Vietnamese wikis in November, where we collected data for eight weeks on mobile and desktop. The experimental feature included:

• Options for logged-in readers to save articles to a private list for reading later.
• Ability for logged-in readers to access their list and delete articles that are no longer relevant.

What did we find?

The feature had good engagement. Our primary success metric was the clickthrough rate (CTR) on the save article icon. CTR measures how often readers engage with the feature, helping us understand whether people notice it and choose to use it. Typical web CTR is between 1-5%, but can be much lower for features which require an active or participatory action from the user. On English Wikipedia, we observed a clickthrough rate of 0.88% for the “save” button in the reading list experiment. This aligned with our expectations for the feature. Because saving an article reflects a specific intent through participation — returning to that article later — we did not expect engagement rates comparable to more general navigation actions.

Readers create accounts, but need reading focused features to sustain them. Our experiment was intentionally limited to a fraction of all readers who are not editors so we wouldn’t interfere with existing editing and moderation workflows. As a result, very few people saw the feature, making the exposure rate of the experimental feature too low to give conclusive evidence on how reading lists on web affect user retention. This was a helpful finding for us: currently, readers who do not edit do not have much reason to have an account, since most logged-in features on Wikipedia are designed for editors. The test helped us better understand how reader-focused features may reach a distinct audience of account holders who engage with Wikipedia differently than editors. For this reason, we are trying out a beta feature before full rollout so we can learn more about user retention with this feature with a larger audience.

Reading list users are active readers. Additionally, we found that readers that engaged with the feature had much higher rates of internal referrals – that is, that is, they more frequently navigated to other pages on Wikipedia. While this relationship is correlational rather than causal, it suggests that readers who already tend to spend more time exploring Wikipedia find particular value in this feature.

What are we doing next?

Based on the results above, we believe that reading lists is a feature readers are interested in and would like to collect more data on how people use it. To do this, we are planning on releasing reading lists on the desktop and mobile websites as a beta feature for logged-in readers.

To increase exposure among readers we will enable the beta feature for all new accounts. Existing users will be able to turn reading lists on manually in the beta section of their user preferences. We will be collecting feedback via QuickSurveys on whether beta users find it to be useful.

We’re planning on the following timeline:

• Week of April 6: Release the feature on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias.
• April 6 - April 20: Monitor and fix any bugs.
• Week of April 20: Release to all other Wikipedias.

We encourage you to try out the beta feature and give us feedback on-wiki or via the survey. Additionally, we want to hear more from you. Do you have any other ideas for reading lists based on this information? Please share your thoughts and questions here. For more info, see our project page.

Thank you. EBlackorby-WMF (talk) 21:05, 10 March 2026 (UTC)

To support current active readers on the wikis in their goals of learning from Wikipedia, we want to experiment with allowing readers to save articles to a list for reading later, helping them organize their knowledge while also building a practice of content curation that could pave the way for future contributions to Wikipedia.

Back in the day, this would be called "browser bookmarks". sapphaline (talk) 21:31, 10 March 2026 (UTC)

Plenty of other websites have features to save posts or articles, perhaps because bookmarks are deemphasised in modern web browsers and people tend to use them less IME. In any case, I personally think anything that increases new editor intake is a good thing.  novov talk edits 00:48, 11 March 2026 (UTC)

@Mir Novov "People tend to use them less". How do you know that? I think bookmarks are great and I use them frequently, David10244 (talk) 02:21, 11 March 2026 (UTC)

Anecdotally, I notice a lot of younger browser users don't use bookmarks apart from a few generic favourited sites, and mainly rely on tabs or other functionality for content they wish to revisit.  novov talk edits 02:39, 11 March 2026 (UTC)

@Mir Novov I think a lot of that comes from the fact that so much browsing is done on mobile, and mobile bookmarks generally suck. --Ahecht (TALK
PAGE) 19:54, 11 March 2026 (UTC)

I don't even have bookmarks in the mobile browser I use (Firefox Focus). Prototyperspective (talk) 21:13, 11 March 2026 (UTC)

@Mir Novov From a statistician: "Anecdotes are not data".  :-) David10244 (talk) 16:31, 15 March 2026 (UTC)

Hello!! Hsuanwei from the WMF Reader Experience team here :) This feature is definitely akin to browser bookmarks! We’re framing this as a first step toward readers participating more on Wikipedia by personalizing their experience, which we hope will eventually lead some of them to become interested in editing. To the tabs point, one tendency we’ve noticed in our user research is that some readers want to be able to “hoard” their information in one easily accessible spot, even though they may not revisit or organize it later, similar to how some people keep 100 tabs open. Do you have any suggestions for how to build on this work to make it more engaging or interactive? HFan-WMF (talk) 23:49, 17 March 2026 (UTC)

Great news, thanks. However, I'm more interested in the Recommended Reading List which can recommend articles one may be interested in based on these saved lists or on specified interests/articles-of-interest. Please get them to desktop too. See Wish505: Show recommended articles on Wikipedia Main page on desktop & mobile web, not just in app. and give us feedback on-wiki or… I'm using the saved reading list during distraction-free book-reading-like Wikipedia reading during commute or similar occasions where I save articles when there's something in it I'd like to look at later or select from articles saved earlier when it's an article I'm interested in reading but eg it's long and not of importance (ie not for editing or any immediate info-need and just for curiosity). Far more users use mobile Web than the app so they should be able to use this feature too if they'd like to. On desktop, it can be an alternative to watching articles. Do you have any other ideas for reading lists based on this information I wonder whether some could be created dynamically based on some inputs like one's configured interests and a category. Enabling notes for these would be very useful too, similar to watchlisted pages. Prototyperspective (talk) 00:09, 11 March 2026 (UTC)

Excellent note, recommendations for articles to read based on what you’ve already saved is definitely something our team is interested in bringing to the web experience in the future. We’re also thinking about it as another way for editors to potentially organize articles for themselves, and for readers, as an easy entry point to starting to see Wikipedia as a place for participation. Readers are interested in collecting, organizing, and sharing information, so we see this work as a step toward providing that option to them. We’re starting with just “saving” articles for now, but we definitely envision a future where categories and interests can help shape the reading experience, allowing readers to feel a more personal connection to their reading. If reading lists could support recommendations, what kinds of signals would you want them to use: articles you’ve saved, categories, topics you follow, or something else? Also curious what the ideal experience would look like for you, like where you would want to see it and how often it should update? HFan-WMF (talk) 23:51, 17 March 2026 (UTC)

Thanks for the feedback. I think it would be best if articles saved would be used until the input for recommendations have been configured more explicitly by the user. As for using categories, see phab:T181157 which is about exactly that. It would be great if articles and categories would be used for the recommendations. I don't know if there is a way for topics other than categories except for WikiProjects (their tags on articles' talk pages). As for what I think an ideal experience would be and how often I'd like them to update, see wish W506. Basically in a feed that updates when, and only then, I open the feed page and scroll/swipe down. Prototyperspective (talk) 13:29, 18 March 2026 (UTC)

Hi all. I propose defuncting this template, {{PKRConvert}}, and instead relying on footnotes for relying on currency exchange using a live external link for that exact timeline.

The reason is inflation and currency unstability. The template may not reflect the recent changes, and it is nearly impossible to update it daily or on monthly basis.

Please see this footnote as a reference, and a recent concern raised over here. I am available to take any queries and suggstions. Thank you! M. Billoo 13:00, 18 March 2026 (UTC)

@M.Billoo2000 This should probably be discussed at Template talk:PKRConvert or WP:TfD. Is Pakistan significantly different from the 50 other countries supported by Template:Inflation? --Ahecht (TALK
PAGE) 14:23, 18 March 2026 (UTC)

I do not understand how this template works, Template:Inflation/PK/dataset, and that it is not edited in about four years. The inflation history can be seen here and any other similar website. I intentionally came on the village pump instead of TfD or Template talk, only because I want to specifically address this one currency, PKR only, to a wider PoV, and not any other currency. Also, that the template has been stale for years, so I felt useless in leaving a message there. I have seen multiple editors trying to use PKRConvert in Pakistan-related pages, which eventually generates a false value due to not reflecting that particular timeline. And that is why I have linked two of my PoVs above, and I can present more. Thank you. M. Billoo 14:40, 18 March 2026 (UTC)

We often have to ask people which editor they are using, which can be confusing for them and long-winded for us to explain.

I have made Wikipedia:Which editor? to which we can refer such people. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:03, 18 March 2026 (UTC)

@Pigsonthewing You might want to merge this into Wikipedia:Glossary/User interface. See also mw:Editor and Help:Edit toolbar. --Ahecht (TALK
PAGE) 14:31, 18 March 2026 (UTC)

Thank you; I don't. None of those pages are suitable for the purpose, especially when addressing novice editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:54, 18 March 2026 (UTC)

There's mw:Editor already. Nardog (talk) 14:49, 18 March 2026 (UTC)

^ Izno (talk) 15:55, 18 March 2026 (UTC)

See e.g. https://en.wikipedia.org/w/index.php?title=Wikipedia%3ASandbox&date-range-to=2026-03-17&tagfilter=&action=history&useskin=cologneblue or https://en.wikipedia.org/w/index.php?title=Wikipedia%3ASandbox&date-range-to=2026-03-17&tagfilter=&action=history&useskin=modern (if you have "Temporary account IP viewer" right).

Is there any way I can debug this? sapphaline (talk) 10:53, 18 March 2026 (UTC)

These are community supported skins (aka, not supported), so some functionality is expected to be missing —TheDJ (talk • contribs) 11:02, 18 March 2026 (UTC)

I want to fix this only for my account. sapphaline (talk) 11:03, 18 March 2026 (UTC)

User:PrimeHunter/Vector 2022 reload.js may be of interest. PrimeHunter (talk) 13:40, 18 March 2026 (UTC)

Note that required modules do load (as can be seen from browser's debugger), but they seem to error out, though I can't confirm this because there's nothing in the console. sapphaline (talk) 11:03, 18 March 2026 (UTC)

Both Cologne Blue and Modern are legacy skins (they were removed from Preferences → Appearance when Timeless was added in mid 2021, see mw:MediaWiki 1.31#Skins), and are no longer maintained. New features are not necessarily going to work with them. --Redrose64 🌹 (talk) 18:59, 18 March 2026 (UTC)

The reason it's not loading is that it is not finding the #bodyContent ID it requires to run. * Pppery * _{it has begun...} 19:06, 18 March 2026 (UTC)

The following incredibly dumb and brittle line of JS appears to work in both Cologne Blue and modern:

mw.loader.moduleRegistry["ext.checkUser.tempAccounts"].packageExports["ipReveal.js"].addIpRevealButtons($("#content"))

. Probably someone who knows more than me about how ResourceLoader works could find a less stupid way of writing that. * Pppery * _{it has begun...} 19:13, 18 March 2026 (UTC)

This needs to be executed after "ipReveal.js" was loaded, though. sapphaline (talk) 19:36, 18 March 2026 (UTC)

A way to do this without timeouts is by changing "mw-content-text" ID to "bodyContent":

if (mw.config.get("skin") == "modern" || mw.config.get("skin") == "cologneblue") {
	var mw_content_text = document.getElementById("mw-content-text");
	mw_content_text.setAttribute("id", "bodyContent");
}

sapphaline (talk) 19:54, 18 March 2026 (UTC)

I've been trying for ten minutes to fix the coordinates at Kirtland Community College. The campus was moved in 2016, but the dot still shows the old location, and even updating the coordinates is still showing the old location. What am I doing wrong? The current coordinates are 44.60180007265286, -84.70585794585037 Ten Pound Hammer • ^{(What did I screw up now?)} 14:53, 18 March 2026 (UTC)

Five decimal points gives a precision of around 1 metre. 14 is sub-atomic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:59, 18 March 2026 (UTC)

@Pigsonthewing: I tried shortening it to four decimal points and it still shows the old location. What am I doing wrong? Ten Pound Hammer • ^{(What did I screw up now?)} 15:08, 18 March 2026 (UTC)

Click "Wikidata item" under "Tools" and update the coordinates at Wikidata. PrimeHunter (talk) 15:15, 18 March 2026 (UTC)

I don't see either of those options anywhere. Ten Pound Hammer • ^{(What did I screw up now?)} 15:19, 18 March 2026 (UTC)

"Tools" is in the interface. In the default skin Vector 2022 it's a drop-down menu at the top right. In other skins it's a menu in the left pane but "Wikidata item" is a little further down under "In other projects". PrimeHunter (talk) 15:25, 18 March 2026 (UTC)

I have no clue what you're talking about. I'm using the default skin and I don't see anything called "Tools" anywhere on the page. Can you show me a screenshot? Ten Pound Hammer • ^{(What did I screw up now?)} 15:29, 18 March 2026 (UTC)

File:Commons "Tools" menu as of July 2024.png. "Tools" may also be in a sidebar to the right with a "hide" link next to it which would place it like the screenshot. In many browsers you can search a viewed page for a string with Ctrl+f. PrimeHunter (talk) 16:18, 18 March 2026 (UTC)

That area on the page is completely blank. I don't even see a "hide" anywhere. What page specifically do I need to be on to see it and therefore change it? Because it sure as shit isn't Kirtland's article, where the upper right is completely blank. Ten Pound Hammer • ^{(What did I screw up now?)} 16:23, 18 March 2026 (UTC)

Just go to https://www.wikidata.org/wiki/Q6416228. Scroll down to "coordinate location". Schazjmd (talk) 16:33, 18 March 2026 (UTC)

How did you get to that from the article, though? Ten Pound Hammer • ^{(What did I screw up now?)} 16:35, 18 March 2026 (UTC)

I'm using Vector Legacy. The associated Wikidata link is in the left-side menu at the very bottom. I don't know where it is shown in the default skin, sorry. Schazjmd (talk) 16:47, 18 March 2026 (UTC)

I take that back: I just opened the article in an incognito window so I could see it in the default skin. Along the top of the center pane is "Read - Edit - View history - Tools". The Tools dropdown menu shows "Wikidata item" at the bottom of the list. Schazjmd (talk) 16:50, 18 March 2026 (UTC)

The Tools menu is on every wiki page. Do you really have Vector 2022 at Special:Preferences#mw-prefsection-rendering? Do you see "Tools" near the top right here or if you log out? Try to bypass your cache with Ctrl+F5 if you have a Windows browser, or what do you use? If none of this works then your browser may have a serious problem, or are you using some app instead of a browser. "What links here" is also in the Tools menu. Do you know that feature? PrimeHunter (talk) 16:51, 18 March 2026 (UTC)

Ah, it's on the side for me and not the bottom. I see "what links here". Ten Pound Hammer • ^{(What did I screw up now?)} 17:03, 18 March 2026 (UTC)

Hammer's been around for far longer than I have, so like me probably still uses a pre-Vector skin (Cologne Blue, Modern or MonoBook): for each of these, it's in the left sidebar, below the "In other projects" subheading, titled "Wikidata item". If that is absent on an article, it means that there is no page at Wikidata. --Redrose64 🌹 (talk) 21:30, 18 March 2026 (UTC)

Obligatory xkcd Qwerfjkltalk 19:12, 18 March 2026 (UTC)

See your 2170 and raise you 2168. --Redrose64 🌹 (talk) 21:39, 18 March 2026 (UTC)

Does anyone know if there is a way to add a button to the WikiEditor toolbar using the built in functionality of that extension? I know I can hack it by inserting HTML after a certain element, but looking at mw:Extension:WikiEditor/Toolbar customization it looks like there should be a way to do it better IF the PHP settings are enabled. The question is... are they? Basically I would like to add a button that runs a certain javascript function... Any help appreciated as always! Zackmann (^{Talk to me}/_{What I been doing}) 04:11, 19 March 2026 (UTC)

They are. The examples on that page work on WMF wikis. Nardog (talk) 04:19, 19 March 2026 (UTC)

Was having a hard time getting it to work, I think I figured it out though. Zackmann (^{Talk to me}/_{What I been doing}) 04:22, 19 March 2026 (UTC)

Is it must me or is there a more general problem with the way that "the system" is applying signatures?

If I edit an existing section at a talk page, then use the signature icon on the top of the editing box:

B I 🔗 etc

not only do I get my sig attached to the end of my post, but another sig is attached to the section title. What gives? 𝕁𝕄𝔽 (talk) 12:53, 18 March 2026 (UTC)

Not happening for me. That is mostly an "insert text here" button - are you in the "section header" input box when using it? Also it looks like you are trying to do an infinite loop on the second line of User:JMF/common.js. — xaosflux ^Talk 13:54, 18 March 2026 (UTC)

If it happens when you edit an existing section then I guess you see the heading on the first line and not in a box. Does it happen systematically like in with the signature at the end of the heading? Does it happen in safemode? PrimeHunter (talk) 14:04, 18 March 2026 (UTC)

No, not in the section header box. Just editing routinely [as in this case, using the explicit 'edit' function rather than ' reply'. I get a sig at the end of what I have written (as expected) and another gets tagged on to end of the section title. As it has just now, I will leave it for a moment as evidence and then correct it before responding to rest of your questions. --𝕁𝕄𝔽 (talk) 17:17, 18 March 2026 (UTC)

Doesn't happen in safemode! (https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=edit&section=22&safemode=1). I don't know for how long it has been going on.

Anyway, as it does not appear to be a general problem, best close the discussion in this forum and I would appreciate any suggestions at user talk:JMF#Wildcat signatures. Thank you. --𝕁𝕄𝔽 (talk) 17:29, 18 March 2026 (UTC)

If it doesn't happen in safemode, turn off all your userscripts and try again. See mw:Help:Locating broken scripts. — xaosflux ^Talk 10:28, 19 March 2026 (UTC)

It was a wikEd bug which has been reported and fixed at User talk:Cacycle/wikEd#Double insert on default toolbar icons. PrimeHunter (talk) 12:42, 19 March 2026 (UTC)

Hi, I’m Johannes from Wikimedia Deutschland’s Technical Wishes team. We are considering to work on Community Wishlist/W17: Improve VE references' automatic names and reuse. This has been a long-term issue for wikitext editors (see e.g. WP:VisualEditor/Named references) which has been among the top-voted wishes in several Community Wishlist Surveys, e.g. 2017, 2019, 2022 or 2023.

We would like your input on the solutions proposed on our project page. We are considering several options, which can be combined if desired by the community.

• Changing the default pattern for automatically generated reference names (currently ":n", e.g. ":0", ":1"...) to use the reference type instead (e.g. "book_reference-1").
• Providing a simple mechanism for communities to configure a different default name.
• Generating automatic reference names based on the domain name (if it’s a web citation).
• Generating automatic reference names based on template parameters (e.g. "title" or "last"+"first") – defined by the community.