Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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

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

« Archives, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231

URL shortener tool

Hello,

I am facing a problem in the English Wikipedia tool to shorten the URL by showing the message:

Blocked users can't make short URLs.

Even though I am not blocked on any wiki, ^Check!, could you please help solve this issue?

Best, SanBonne (talk) 11:30, 16 July 2026 (UTC)

Maybe your IP is blocked at some level and that is causing a problem ? If you open an incognito browser window and you start an edit, do you see a block message for editing ? —TheDJ (talk • contribs) 15:21, 16 July 2026 (UTC)

No at all, nothing from that. Using Chrome without additional add-ons affects the IP, mentioning that I could use the shortener in other wikis, meta, and wiki: fr, es, ar, etc... SanBonne (talk) 20:49, 16 July 2026 (UTC)

I'm confused - changing your extensions changes your public IP? Seems like you are using a VPN/Proxy? All the shortened URL's are actually done on meta, does meta:Special:UrlShortener work for you? Are you still having this issue here? — xaosflux ^Talk 15:48, 22 July 2026 (UTC)

The problem is fixed now, but when I opened the topic, the problem was only on English wikipedia, where the tool works on other wiki projects: meta wiki; fr wikipedia,...etc SanBonne (talk) 09:34, 25 July 2026 (UTC)

The audio progress is unseen in dark mode

Tracked in Phabricator
Task T432793

Hi. I realized that in the dark mode the audio progress line is invisible, while in the light mode it's completely okay.

See this and this screenshot for comparison. Aminabzz (talk) 08:54, 21 July 2026 (UTC)

I'm on a funky hotel wifi that doesn't seem to like your screenshot upload host, so I can't load them. :( Can you file a task on Phabricator and attach them there? Use project tag "TimedMediaHandler".

Then I'll try to take a look over it this week during Wikimania. Dark mode bugs usually are easy CSS fixes that just need something accommodated with an alternate style, so hopefully we can knock out a fix pretty fast. brooke (talk) 09:27, 21 July 2026 (UTC)

Allright, I'll do that. BTW, I edited my post. I meant audio, not video. Aminabzz (talk) 22:18, 21 July 2026 (UTC)

@Brooke Vibber Update: I created the Phabricator task. Aminabzz (talk) 22:36, 21 July 2026 (UTC)

What Brooke asked is to upload the screenshots to Phabricator, not link from there. Nardog (talk) 00:29, 22 July 2026 (UTC)

Thanks, however I still can't reach the links -- can you attach the actual images to the task instead of linking them on an external host? Thanks! brooke (talk) 06:30, 22 July 2026 (UTC)

We never got the screenshots but the task was merged as a dupe to another task which did have screenshots and a reproducible example, so we're all good. :)

I tracked the problem down to Vector 2022-specific dark mode style overrides used on Wikimedia sites, and cobbled together a patch which seems to resolve it and several other bits in the player that were broken in dark mode on Vector 2022 with the Wikimedia style overrides.

Once through code review this should get merged in and roll out within a week or two.

Thanks for the big report! brooke (talk) 11:03, 25 July 2026 (UTC)

The url domain name has .ir as its tld, which might be why your wifi isn't a huge fan, it wouldn't surprise me if their internet service provider has just blocked the whole tld. Or the sight could just be down. It doesn't seem particularly eager to load, either. Mitchsavl (talk) 11:12, 29 July 2026 (UTC)

Is it THURSDAY or is it Firefox

Background: Vector legacy/2010, Firefox Beta (freshly updated to 154.0b1), source editor

Issue: I signed on, edited a page, and thought it weird when I tabbed out of the edit box to add an edit summary, it instead shifted to the "Insert / Wiki markup / Symbols / etc" dropdown just below the edit box. I don't remember this happening this morning when I made a few edits but I also don't remember tabbing to add an edit summary. I definitely know it wasn't happening yesterday.

Is this a THURSDAY thing or is my freshly-updated FF beta not playing nice? Thanks for the thoughts. Primefac (talk) 21:47, 23 July 2026 (UTC)

This might be autosuggest for the source editor which was rolled out earlier this week? Kowal2701 (talk, contribs) 22:26, 23 July 2026 (UTC)

Well, I just on a hunch turned off the Syntax highlighter and things return to "normal" tab use, so it could be (though I'm not seeing any indication of an autosuggest in my editor). Primefac (talk) 22:38, 23 July 2026 (UTC)

I cannot reproduce it using Firefox 150.0.1, so it is likely to be Firefox.析石父 (talk) 00:55, 24 July 2026 (UTC)

I'm on 155.0a1 and can't reproduce it. Jerod Lycett (talk) 00:12, 26 July 2026 (UTC)

Thumb won't preview, but enjoy. If it doesn't happen in Alpha then I guess they've fixed it... Primefac (talk) 00:53, 26 July 2026 (UTC)

I'm on alpha and can reproduce, but I'm a couple weeks out of date... I'll update and report back. LittlePuppers (talk) 04:26, 26 July 2026 (UTC)

I updated and it's still here. I don't tab to there though, so I have no idea when/why it changed. LittlePuppers (talk) 04:32, 26 July 2026 (UTC)

I do think it's likely a Firefox thing, my laptop only updated yesterday and right after I noticed the change in behaviour. I filed at bugzilla so we'll see how things get on. Primefac (talk) 09:43, 26 July 2026 (UTC)

Yeah, just tried in Edge and it doesn't happen there. Do you have a link to Bugzilla, for the curious? LittlePuppers (talk) 14:59, 26 July 2026 (UTC)

https://bugzilla.mozilla.org/show_bug.cgi?id=2057769 Primefac (talk) 15:36, 26 July 2026 (UTC)

Just to close the loop here, it was a Firefox regression and it looks like it's in the process of being patched. Thanks all for the thoughts. Primefac (talk) 22:19, 29 July 2026 (UTC)

Downscaling File:Erika Kirk & Charlie Kirk, June 2025.jpg

A user commented that File:Erika Kirk & Charlie Kirk, June 2025.jpg is 17 MB and needs to be downscaled. Is there a protocol to follow for this? guninvalid (talk) 22:33, 23 July 2026 (UTC)

No they linked to a zoom in of just Mrs Kirk, and called it obscene. Slatersteven (talk) 09:44, 24 July 2026 (UTC)

@Guninvalid: This is outside our remit. The image is hosted on Commons, where the image policies are significantly different. See in particular c:Commons:Maximum file size. --Redrose64 🌹 (talk) 18:04, 24 July 2026 (UTC)

Italic links

Is there a One True Correct way to italicize a link? In the visual editor, if I select a bit of linked text and do Command-I, it adds makes the piped text italic, as in this diff. I'm sure somebody will come along and turn Soho Weekly News into Soho Weekly News or maybe even SoHo Weekly News. Are any of these actually better than the others, for any reasonable value of "better"? Is VE doing it wrong? Are the gnomes who come along and "fix" it just being obsessive? RoySmith (talk) 23:03, 23 July 2026 (UTC)

From an HTML semantic perspective, it doesn't matter. The italics affect presentation only, and it doesn't matter if they're nested within the hyperlink or the other way around. From the perspective of someone using the wikitext editor, ''[[SoHo Weekly News]]'' is more compact and avoids redundancy. But changing it is a cosmetic change, so generally isn't desirable to do on its own. isaacl (talk) 01:30, 24 July 2026 (UTC)

I believe visual editor only put the italics in the pipe because the link was already piped since you did "Soho" instead of "SoHo". If you had done SoHo Weekly News and linked to SoHo Weekly News or done Soho Weekly News and linked to the redirect Soho Weekly News, per MOS:NOPIPE (I think?), then the italics would've been outside of the brackets. 1brianm7 (talk) 01:46, 24 July 2026 (UTC)

By the way, the real name was Soho Weekly News with lowercase h but many others (indluding our own SoHo Weekly News) write it SoHo because it was named after SoHo, Manhattan, and the newspaper usually stylized it SOHO or SOHO without directly revealing the correct mixed case Soho although SOHO hints at it. PrimeHunter (talk) 09:00, 25 July 2026 (UTC)

"not a valid map data page"

Tracked in Phabricator
Task T433008

Robben Island Marine Protected Area and 926 other articles, at this writing, are displaying messages like mapframe: Title "Robben Island Marine Protected Area.map" is not a valid map data page. They seem to come from {{maplink}}. commons:Data:Robben Island Marine Protected Area.map exists, appears to be working fine, and if I had to guess, was probably working fine at Robben Island Marine Protected Area at some point in the past. I don't see any templates used in this page that have been changed in the last few days. {{Maplink}} was last modified in 2018, and Module:Mapframe was last modified on 1 June 2026.

At the bottom of the article, a series of red error messages is displayed instead of {{Marine protected areas of South Africa map}}, which looks fine on its Template page. The above problem is present in both Parsoid and the legacy parser. – Jonesey95 (talk) 05:21, 24 July 2026 (UTC)

I've noticed that a bunch of other articles with Template:Maplink don't have this problem until the page is purged, then the error message appears and the map disappears. Steelkamp (talk) 05:29, 24 July 2026 (UTC)

This probably means that a WP:THURSDAY MediaWiki code update causes the issue, and pages are showing the error message when they are purged or edited. The count of articles has increased from 926 to 941 just in the last 15 minutes, so it will probably go much higher. [Update: I found T433008.]– Jonesey95 (talk) 05:37, 24 July 2026 (UTC)

The number has gone up to 1,269 Quake1234 (talk) 14:51, 24 July 2026 (UTC)

Yes, and Category:Pages with broken maps has increased to 1,500 pages. I hope the developers work on Fridays. – Jonesey95 (talk) 16:47, 24 July 2026 (UTC)

They don’t —TheDJ (talk • contribs) 18:18, 24 July 2026 (UTC)

Well, it looks like a volunteer developer from de.WP has submitted a patch. We'll see if anyone is willing to test and apply it. Off topic: Then why TF would they deploy new software on Thursdays? When I worked in IT, we NEVER changed anything at the end of the week. I liked having my weekends free and knowing that my systems were working for my customers while I was out rock-climbing or whatever. – Jonesey95 (talk) 21:14, 24 July 2026 (UTC)

To answer the question, the reason we get new software on Thursdays is to allow the WMF to do a staggered rollout: testwikis on Tuesday, non-Wikipedias on Wednesday, Wikipedias on Thursday. No I don't know why they don't move that one-day earlier but there's a trilemma between staggered rollouts, no end-of-week deployments, and a weekly release cadence all of which are good things which are mutually incompatible. * Pppery * _{in solidarity} 23:32, 24 July 2026 (UTC)

IIRC, the Tuesday start was to avoid running into Monday holidays and Monday deploys of fixes for bugs found over the weekend. As for the "no deploys on Fridays" rule, looking through some recent Fridays in wikitech:Server Admin Log I do see some Friday deploys, including some that are things I really wouldn't expect given the strict language on wikitech:Deployments/Emergencies (which does include "Major loss of functionality / appearance", BTW). Anomie⚔ 00:28, 25 July 2026 (UTC)

Feels like one of those products people would naturally discuss on Reddit once more users discover it. ~2026-42024-47 (talk) 11:06, 29 July 2026 (UTC)

Since when don't they? Anomie⚔ 23:02, 24 July 2026 (UTC)

While we are here, can we break out Category:Articles with broken maps??? Ahecht you helped me do this with Category:Articles with script errors perhaps you can assist here? Zackmann (^{Talk to me}/_{What I been doing}) 23:22, 28 July 2026 (UTC)

@Zackmann08: The bug has now been fixed so Category:Pages with broken maps is down to 143 pages and it has a link to search articles so I don't see a big need for a split. The search link currently gives too many articles because search hasn't updated fully after the fix but that's a temporary issue. Category:Pages with script errors and its namespace-specific subcategories have around 1,600 pages in total so a split is more helpful there. If we want to split Category:Pages with broken maps then MediaWiki:Kartographer-broken-category could propbably make similar code to MediaWiki:Scribunto-common-error-category. I say "probably" because some MediaWiki messages don't allow wikitext and it's hard to tell which ones without trying it. PrimeHunter (talk) 12:07, 29 July 2026 (UTC)

So who busted Template:Maplink?

The |from= parameter doesn't work for any given mapdata link, and everything else is intact. ⠀⠀ .n 03:30, 27 July 2026 (UTC)

Related to phab:T433008, perhaps? Staraction (talk · contribs) 03:44, 27 July 2026 (UTC)

hm yeah definitely :sob: ⠀⠀ .n 03:48, 27 July 2026 (UTC)

Map error on M-47 (Michigan highway)

For some reason, the map feature on M-47 (Michigan highway) is displaying the error mapframe: Title "M-47 (Michigan highway).map" is not a valid map data page. Anyone know how to fix this? Ping @Imzadi1979: Ten Pound Hammer (they/them) • ^{(What did I screw up now?)} 04:23, 27 July 2026 (UTC)

@TenPoundHammer Maplink is busted right now. ⠀⠀ .n 07:07, 27 July 2026 (UTC)

Display better error message?

MediaWiki:Kartographer-error-title says: Title "$1" is not a valid map data page . That's a wrong error message at the moment and displayed in thousands of articles where many editors don't know what to do. They shouldn't do anything but just wait for the bug fix. Maybe we should customize the message until a fix is deployed. I suggest: "A bug prevents map display. A fix is underway." I have tested that the message allows wikilinks. PrimeHunter (talk) 03:24, 28 July 2026 (UTC)

this broadly makes sense to me but i would suggest not putting the ticket in. while it may provide some contrete reassurance it also might result in people coming to the ticket to urge the hurring up of a bugfix they're hard at work on.... Morwen (talk) 04:00, 28 July 2026 (UTC)

I agree with Morwen. Please implement this in plain text ASAP. It looks like a fix may be on the way in the next MediaWiki update; it is not clear why they did not roll out a patch more quickly, given the scale of the impact and the potential for editors removing things from pages in error. – Jonesey95 (talk) 14:22, 28 July 2026 (UTC)

I have saved it as plain text. See e.g. the effect in Robben Island Marine Protected Area where the infobox previously said mapframe: Title "Robben Island Marine Protected Area.map" is not a valid map data page. MediaWiki:Kartographer-error-title should be deleted after the bug fix is deployed but first check that the fix has propagated so the searches "not a valid map data page" or "bug prevents map display" don't give results caused by the bug. PrimeHunter (talk) 15:32, 28 July 2026 (UTC)

A bug fix has been deployed and appears to be working. The searches "not a valid map data page" and "bug prevents map display" still give some results but I haven't found any which actually display the eror message so it's just search which hasn't updated. Category:Pages with broken maps previously had 1000+ pages. Now there are only 143 and those I examined have other errors unrelated to the bug. PrimeHunter (talk) 11:48, 29 July 2026 (UTC)

Battle of Cable Street map

Can some of you bright talented people take a look at the map on this article and get it to align right? Right now it's centered and in the Events section. The Events section is where it seems to belong, but I can't figure out how to get it to align right. Thanks, Shearonink (talk) 16:14, 24 July 2026 (UTC)

How's that? Morwen (talk) 16:15, 24 July 2026 (UTC)

It's a beautiful thing. I'll update Talk:Battle of Cable Street#Map. Thanks, Shearonink (talk) 16:17, 24 July 2026 (UTC)

Re: 429 'too many requests' on Media viewer

We talked about this two months ago, and for a while it seemed fixed, but it's been back now for a few days, rendering the media viewer unusable for me. The annoying part is that the desired image shows up for a fraction of a second, and only then is replaced with a broken image symbol. -- Seelefant (talk) Seelefant (talk) 09:32, 26 July 2026 (UTC)

2nd request: Minor edits showing up on watchlist though I've ticked "Hide minor edits"

Hallo, I asked here about this last week but it was archived unanswered; I tried at the Help Desk and a mystified @Michael D. Turnbull recommended me to come here, so I'm trying again.

The problem: I have ticked "Hide minor edits from watchlist" in my preferences, but they aren't hidden. Two recent examples I see on my watchlist, both labelled neatly with "m", are this, someone improving a link, and this, one of the many I see where deprecated infobox parameters are being cleaned up (which is what inspired me to try to hide minor edits).

Any thoughts? I'm using a Windows desktop with Firefox, but I see the same minor edits on my watchlist on my Android phone, both in "desktop view" and in "mobile view". PamD 16:02, 26 July 2026 (UTC)

How are you accessing the watchlist? If it's through a bookmark or something, the option might be fixed in the URL. Nardog (talk) 16:44, 26 July 2026 (UTC)

@Nardog Thanks for taking an interest! I usually click on the "watchlist" icon at top right of the page, so I don't think that can be the problem. Thanks. PamD 17:13, 26 July 2026 (UTC)

Hmm. Do you have a saved filter set as default? Nardog (talk) 17:33, 26 July 2026 (UTC)

@Nardog Not that I know of - where/how would I check? (I'm not very techy: periodically someone says "You ought to do such and such" with jss etc and I follow their guidance but it's all a bit of a blur.) PamD 23:01, 26 July 2026 (UTC)

Click "Saved filters" at the top right of watchlist and see if there's an item with a pin. If so, click the pin and select "Remove as default" or "Delete". Nardog (talk) 00:23, 27 July 2026 (UTC)

@Nardog Thank you, problem solved! I found "Default January 2021" or some such named filter and deleted it, and the minor edits have now disappeared. I don't know whether there will be any other consequences from deleting the filter, as I've no idea why or how I set it in the first place @Michael D. Turnbull for information, with thanks.) PamD 08:06, 27 July 2026 (UTC)

Over complicated template populating categories

Can somebody technically minded take a look at Template:Conflicts in year category header and adjust it to change all the categories from Category:Conflicts in YYYY to Category:YYYY conflicts please? The categories are being renamed but they all have this on them and it's not obvious how to simply change it over. Thanks in advance. Timrollpickering (talk) 17:48, 26 July 2026 (UTC)

Timrollpickering, I've made the changes in Template:Conflicts in year category header/sandbox. — Qwerfjkltalk 18:41, 26 July 2026 (UTC)

Thanks, it's working fine. Timrollpickering (talk) 18:54, 26 July 2026 (UTC)

Timrollpickering, you may also want to move the template to {{YYYY conflicts category header}} or similar. — Qwerfjkltalk 08:47, 27 July 2026 (UTC)

Moved to Template:Year conflicts category header which matches the category names. Timrollpickering (talk) 09:37, 27 July 2026 (UTC)

For the future, it's usually not worth the time to move a template that is Close Enough to the intended name. Izno (talk) 17:26, 27 July 2026 (UTC)

Amanda Jones (inventor) - Harv warnings in Engineering articles section

I give up. Tried but can't figure out how to fix these 2 Harv warning/no links issues. 2 of the articles are fine, 2 are not. Same ref for each. whhhhhhy. Thanks in advance. - Shearonink (talk) 20:42, 26 July 2026 (UTC)

As of this time stamp, that article is not in any reference-related error categories. It looks like you fixed everything. – Jonesey95 (talk) 22:23, 26 July 2026 (UTC)

Thanks Jonesey95. - Shearonink (talk) 23:45, 26 July 2026 (UTC)

Adding |ref=none to {{cite magazine}} solved "There is no link pointing to this citation." I suspect the reason only two of them had the error has something to do with the fact having multiple citations with the same author surname and year results in duplicate IDs (which is a lint error in and of itself). Nardog (talk) 22:45, 26 July 2026 (UTC)

I know about ref=none but tried to find the specific Why of It & specifically How To Fix It & was unsuccessful. I was thinking there was some code or parameter or whatever that I was missing. The Why of the 2 refs seemingly not working and not knowing the reason...I guess it's nothing to be concerned about? Thanks for the fix. - Shearonink (talk) 23:45, 26 July 2026 (UTC)

The error is generated by User:Trappist the monk/HarvErrors.js. Since there were two items each with the ID "CITEREFJones1904" or "CITEREFJones1905", which is not supposed to happen, the selector #CITEREFJones1904 or #CITEREFJones1905 returned only the first item. That's the why. Nardog (talk) 00:29, 27 July 2026 (UTC)

I tried adjusting the years to 1904a & 1904b but that didn't work. - Shearonink (talk) 04:14, 27 July 2026 (UTC)

Depends on what you mean by "work". That should make the error appear for both 1904 Jones citations, and since there indeed "is no link pointing to this citation", I would consider that "working". Nardog (talk) 04:30, 27 July 2026 (UTC)

Why doesn't the archive button show up for me anymore...

I have "User:Elli/OneClickArchiver.js" installed & was going to do some manual archiving on a talk page but my "Archive" button - for talk pages - is not showing up for everything. All I am seeing now is "Subscribe" at Talk:Woodlawn (Alexandria, Virginia) & at Talk:Mount Vernon but I can see "Archive" at Talk:Wilmington massacre. - Shearonink (talk) 04:28, 27 July 2026 (UTC)

@Shearonink: Have you asked at User talk:Elli/OneClickArchiver? Elli was replying to threads there as recently as 22 July. --Redrose64 🌹 (talk) 07:28, 27 July 2026 (UTC)

@Shearonink: I don't use the script but it was updated 17 July and the documentation added "This script requires archiving be setup on a page to work".[1] This is consistent with your examples where only Talk:Wilmington massacre has set up archiving. PrimeHunter (talk) 08:38, 27 July 2026 (UTC)

Sheesh...so in order for it to work now someone (like me) has to go set up the talk archive page. It used to do that automatically... oh well, thanks for letting me know. I hadn't asked at User talk:Elli/OneClickArchiver, I always ask about this kind of stuff here first. I'll ask Elli whhhhhy. Thanks, Shearonink (talk) 16:34, 27 July 2026 (UTC)

For anyone in a similar boat, there are some ongoing discussions about this change at User talk:Elli/OneClickArchiver, including User talk:Elli/OneClickArchiver#Update broke the tool (plus User talk:Elli/OneClickArchiver#Discussion format breaks tool). - Shearonink (talk) 18:22, 27 July 2026 (UTC)

Generally speaking, if there is a problem with a script that's in somebody's user space, and that user is active, it's best to ask that user first. They might not have VPT on their watchlist. Also, although several VPT regulars are JavaScript coders, very few of theme have WP:INTADMIN rights. --Redrose64 🌹 (talk) 19:12, 27 July 2026 (UTC)

Bug: template causes bullet point to shift far left

I noticed a visual bug on Wikipedia:Manual of Style/Titles of works#See also – the last bullet point (MOS:TMRULES) is shifted way to the left, outside the usual "box" within which text is placed. This seems to be caused by the preceding template Wikipedia:Manual of Style/titles hatnote include, when it is followed by the * in the next line. It can be fixed by simply adding an additional line between the template and the bullet point, but I guess it's better to report the bug here so someone can look into it and correct it properly.

The bug occurs on Firefox with MonoBook skin and Edge with Vector 2022. It does not occur on the mobile version of the site or in the mobile app.

— Phazd (talk|contribs) 14:37, 27 July 2026 (UTC)

I believe that I have fixed this bug. It was a subtle thing that happens when a div tag is opened on a normal line and closed on a bulleted or indented line. This sometimes causes a Linter error; I don't know why that didn't happen in this case. – Jonesey95 (talk) 15:45, 27 July 2026 (UTC)

Indeed, it looks good to me now. Thank you! — Phazd (talk|contribs) 15:48, 27 July 2026 (UTC)

Broken template

Hello. Please see the results of matches with a gray background here: 2026 FIBA U18 EuroBasket Division C. Today, eight hours ago, everything was working properly. But then someone messed something up, and I can't figure out what... Thanks, Maiō T. (talk) 15:57, 27 July 2026 (UTC)

That's to do with an edit request I handled recently. Someone beat me to the punch on reverting it, so I'm gonna start looking at trynna fix it now. Thanks for the notice. Aidan9382 _(talk) 16:11, 27 July 2026 (UTC)

Tech News: 2026-31

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

Updates for editors

• Content Translation now supports dark mode, fulfilling a Community Wishlist request. This brings the tool in line with the accessibility features available in the Vector 2022 and Minerva skins, helping reduce visual fatigue for users translating content. [2]
• DiscussionTools' source mode and the 2017 wikitext editor will now offer autocomplete for links ([[), templates ({{), HTML and parser tags (<), and magic words (__), making it quicker and easier to insert links, templates, and other wiki markup while editing. [3]
• The Readers Growth team has concluded its experiment with mobile page previews and will not roll out the feature. Page Previews are a pop-up bottom sheet that appears when readers tap a blue link, showing a thumbnail, lead paragraph, and an option to open the article. The experiment showed flat retention and negative indicator metrics, suggesting that mobile web readers preferred navigating directly to linked articles rather than using page previews.
• The Reader Experience team has seen encouraging early results from the Reading Lists feature, with 93% of participating users reporting that it was useful. Reading Lists help active readers save articles for future reading and support their learning goals on Wikimedia projects. The team plans further improvements before expanding the feature to more users.
• The Explore Feed Refresh initiative was tested with new and casual Wikipedia app readers. The refreshed feed helps readers discover new and relevant content. After a 10.5% increase in engagement with the feed, Wikimedia Apps team has decided to scale the Home Feed redesign to iOS with the learnings from the Android release applied.
• View all 23 community-submitted tasks that were resolved last week. For example, an issue where subject names in the Article Guidance feature were displayed with incorrect capitalization on French Wikipedia, has now been fixed. Subject names will now follow the correct capitalization rules for the language. [4]

Updates for technical contributors

• After running several Account Creation Experiments to improve registration completion rates, a new version of the username field on Create Account has been rolled out. It includes a popover summarizing the username policy to provide clearer guidance during account creation. As part of this change, the messages createacct-helpusername and createacct-username-help that several communities have configured will no longer be used. If communities want to customize the guidance shown in the new popover, they can instead edit the following messages: createacct-username-policy-popover-bullet1, createacct-username-policy-popover-bullet2, and createacct-username-policy-popover-bullet3. [5]
• Later this week, the CodeMirror syntax highlighter will offer themes. The themes can be picked from a dropdown menu in the full CodeMirror preferences dialog. For wikitext, available themes are default, colorblind-friendly (previously the colorblind preference option on Special:Preferences#mw-prefsection-editing) and no-highlighting. For code languages (i.e., CSS/JavaScript/JSON/Vue/Lua), there are several themes available. These same themes will eventually be available for wikitext, too. [6]
• From now on, wikis can restrict editing in the "User" namespace to only the page owner and certain user groups. Read the configuration documentation to learn more.
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 18:47, 27 July 2026 (UTC)

Re "From now on, wikis can restrict editing in the "User" namespace to only the page owner and certain user groups": If anyone here sees a proposal to make this happen on the English Wikipedia, please post a link to the discussion here at VPT. There would be significant technical ramifications to making this change on this site, so technically minded editors should be involved in any such discussion. – Jonesey95 (talk) 22:07, 27 July 2026 (UTC)

no longer possible to have pipe characters in wikilink fragments (section headers)?

In the cs1|2 update notice at Help talk:Citation Style 1/Archive 100 § module suite update 30–31 August 2025, I wrote this wikilink which, at the time, produced a working wikilink:

[[Help_talk:Citation_Style_1/Archive_99#{{pipe}}page=_same_value_as_last_n-digits_of_{{pipe}}doi=|discussion]]

That no longer works there (rendered by parsoid) but apparently does work here (edit preview not rendered by parsoid):

discussion

It used to be that {{pipe}} and | were not treated as wiki markup. Is this going to be a permanent breakage caused by parsoid? or merely teething pains that we must suffer through until someone decides to allow html numeric entities to represent wiki markup characters as just characters?

—Trappist the monk (talk) 21:20, 27 July 2026 (UTC)

Definitely a difference between Parsoid and the legacy parser. Submitted as T433320. (One quick troubleshooting method is to click "Switch to legacy parser", which appears in my right sidebar in Vector 2022, under "General".) – Jonesey95 (talk) 22:18, 27 July 2026 (UTC)

@Trappist the monk As a workaround, using %7C in place of {{pipe}} does appear to work, e.g. [[Help_talk:Citation_Style_1/Archive_99#%7Cpage=_same_value_as_last_n-digits_of_%7Cdoi=|discussion]] → discussion (rendered with parsoid here). --Ahecht (TALK
PAGE) 13:59, 28 July 2026 (UTC)

Of course, I should have thought of that. Thanks. The question still remains however, will parsoid forever treat html numeric entities as wiki markup?

—Trappist the monk (talk) 14:16, 28 July 2026 (UTC)

That is not information anyone but the content transform team has access to, so you will need to wait for the Phab task to reach completion or a decline. Izno (talk) 16:33, 28 July 2026 (UTC)

Discussion+, a script for opening various types of discussions

I've created Discussion+, a script that can be used to open various types of discussions. It currently supports the following:

• RfC
  • Open RfC
  • Appeal RfC
• RM
  • Open RM
  • Review RM Closure
• User conduct
  • ANI Report
  • AE Report
  • AE Appeal
• Content promotions
  • In the news
  • GA nomination

I intend to expand it to:

• User conduct
  • AE quick report
  • AN3 report
• Content promotions
  • GA reassessment
  • FA nomination
  • FA reassessment
  • DYK

Are there other forms of discussions that editors would appreciate this handling?

Further in the future, I intend to make it possible to use it to notify editors of already-open discussions, as well as to close discussions. BilledMammal (talk) 10:53, 28 July 2026 (UTC)

This seems very useful, perhaps add the feature for starting and closing discussions for other things such as split proposals, merge proposals, etc? Fortek67 (talk) 12:47, 28 July 2026 (UTC)

Rename article

Could someone help me move the contents of Estrella, Goodyear to Estrella, Arizona. Every time I've ever tried something like this I've messed it up. Thank you for your help! Magnolia677 (talk) 14:36, 28 July 2026 (UTC)

I have moved it to Estrella, Goodyear, Arizona, to match the pattern of other neighborhood articles like Arbor Lodge, Portland, Oregon. It could also be merged into Goodyear, Arizona; the neighborhood may not be independently notable. – Jonesey95 (talk) 15:05, 28 July 2026 (UTC)

And then Ahecht moved it to Estrella, Arizona. Consistency is not Wikipedia's strongest suit. – Jonesey95 (talk) 15:06, 28 July 2026 (UTC)

@Jonesey95 WP:USPLACE says to use "Placename, State" unless additional disambiguation is needed. There's only one Estrella in Arizona, so no additional disambiguation is needed. --Ahecht (TALK
PAGE) 15:09, 28 July 2026 (UTC)

Thank you both! Magnolia677 (talk) 15:27, 28 July 2026 (UTC)

Overzealous edit filter prevents linking to talk page archives

At Wikipedia:Archiving a source#Perma.cc there's a link to an RfC described as "recent" which isn't (2016). It's also been archived so the link is stale. I can't fix either problem because whenever I try, an edit filter blocks the edit "because it adds a link to archive.today or a related domain". But it doesn't! The section doesn't contain any such links. It does contain the string "archive.is" but that's in the title of the page with the RfC on it. The edit filter should not prevent us linking to any page on Wikipedia. Hairy Dude (talk) 18:47, 28 July 2026 (UTC)

Fixed the wording and the link to the talk archive, thanks for pointing that out. Someone else will need to see if the edit filter needs to/can be fixed. SarekOfVulcan (talk) 18:56, 28 July 2026 (UTC)

Pinging @Daniel Quinlan. --Ahecht (TALK
PAGE) 19:41, 28 July 2026 (UTC)

@SarekOfVulcan and Ahecht: I will update the filter to avoid this one. @Hairy Dude: Thanks for the report. If you ever run into similar issues with any filter in the future, please report the false positive to WP:EFFPR. Thanks! Daniel Quinlan (talk) 19:53, 28 July 2026 (UTC)

Thanks for the pointer. Hairy Dude (talk) 00:46, 29 July 2026 (UTC)

Broken bot spamming my talk page with the same message

See [7], [8], and [9]. Probably broken AI. Ricky the Dinosaur (talk) 05:18, 29 July 2026 (UTC)

This does appear to be inadvisably rapid tool use. That said, I would advice you to heed the advice of the message, even if it does link to an essay. CMD (talk) 05:41, 29 July 2026 (UTC)

Link notifications

When you create an article, and another editor links that article at another page, you receive a "link notification" in your inbox, unless you opted out of it.

Now my question is, it is possible to receive these "link notifications" for any article, your perhaps interested in? Watching it doesn't seem to do anything. Fortek67 (talk) 11:09, 29 July 2026 (UTC)

No, not possible. Izno (talk) 15:42, 29 July 2026 (UTC)

Blocked username is sometimes struck, sometimes not

Recently Edittttor was blocked. I'm now seeing their username in strikeout style in many places, but not all. For example, in the attached screenshot from Template:Did you know nominations/Abdul El-Sayed, their username is not struck, but the corresponding talk link is. What's going on here? RoySmith (talk) 11:16, 29 July 2026 (UTC)

Looks like the redlink uses <a href="https://en.wikipedia.org/wiki/User:Edittttor?action=edit&redlink=1">, which isn't properly detected by the markblocked gadget. If I switch from Parsoid to the legacy parser, the link becomes <a href="/w/index.php?title=User:Edittttor&action=edit&redlink=1"> instead, which is detected properly. So either Parsoid needs to be changed to emit /w/index.php links for redlinks, or the gadget needs to be updated to remove URL parameters from /wiki/ links. --rchard2scout (talk) 11:41, 29 July 2026 (UTC)

I think this is a bug in the markblocked gadget. Since User:Edittttor is a red link, MediaWiki adds ?action=edit&redlink=1 to the URL. The gadget's regex doesn't stop at ?, so it ends up trying to parse Edittttor?action=edit&redlink=1 as the username, which fails, and the link gets skipped. The talk page link isn't a red link, so it doesn't get the extra query string and works fine. Changing const articleRegex = new RegExp( mw.config.get( 'wgArticlePath' ).replace( '$1', '' ) + '([^#]+)' ); to const articleRegex = new RegExp( mw.config.get( 'wgArticlePath' ).replace( '$1', '' ) + '([^#?]+)' ); should fix this. – DreamRimmer ■ 11:41, 29 July 2026 (UTC)

That can't be the whole story because the redlink is struck in the block log, and in edit histories, and in Wikipedia:Peer review/Abdul El-Sayed/archive1. RoySmith (talk) 11:49, 29 July 2026 (UTC)

@MSantos (WMF): could you take a look at this? Is this a parsoid issue? RoySmith (talk) 11:54, 29 July 2026 (UTC)

Red links starting with /w/index.php? are handled correctly, but links starting with /wiki/ are not. Wikipedia:Peer review/Abdul El-Sayed/archive1 renders links in the former format, which is why this happens. The change above should fix the issue for /wiki/ links. – DreamRimmer ■ 12:05, 29 July 2026 (UTC)

But why is parsoid producing different output for these two cases when the old parser did not? RoySmith-Mobile (talk) 17:00, 29 July 2026 (UTC)

@RoySmith It's not. Parsoid is enabled in the Template: namespace, which is why your first link doesn't work, but not in the Wikipedia: namespace, which is why your second link does (see Wikipedia:Village pump (technical)/Parsoid#Timeline). You can check at the bottom of the page: if it used Parsoid, it will say something like "This page was last edited on 29 July 2026, at 14:31. Page was rendered with Parsoid." --Ahecht (TALK
PAGE) 18:29, 29 July 2026 (UTC)

What??? Why are we running different parsers in different namespaces? RoySmith (talk) 18:31, 29 July 2026 (UTC)

Parsoid is being rolled out over a period of weeks or maybe months to namespaces on the English Wikipedia. It is causing a bit of confusion and difficulty in troubleshooting. In addition, some back-end processes like categorization are being handled by either the new parser or the legacy parser, causing some pages to work fine when viewed but still show up in a category that is not listed on the page, or similar weirdness. See this technical page for some information(?) about testing that the developers are doing to see if pages look different in Parsoid and the legacy parser. It appears that they are using this output to schedule the rollout to other namespaces, although it is unclear how. Diligent editors at VPT and other places have noticed and reported bugs in Parsoid, some of which have been fixed since it started being the default parser for some pages about a month ago. – Jonesey95 (talk) 19:51, 29 July 2026 (UTC)

Ugh. I knew it was being rolled out incrementally, but I wasn't paying attention to the details and assumed that meant wiki-by-wiki, not namespace-by-namespace. I guess there will be some pain for a while until this all stabilizes. Thanks for the explanation. RoySmith (talk) 20:07, 29 July 2026 (UTC)

Grey out Minor edit tick box for TAs

Moved from Wikipedia:Village pump (proposals)

I have been editing as a TA for months, and using the Minor Edit tick box when it seemed appropriate. I have only recently realised that this setting is ignored for TAs. This is misleading, for people who are less likely to be familiar with editing Wikipedia. Could this box be greyed out for users for whom it will be ineffective? ~2026-42114-05 (talk) 04:09, 29 July 2026 (UTC)

I seem to be missing something, the "minor" interface selector doesn't normally appear for logged out users. Can you describe all the steps you are taking that lead to that element showing? — xaosflux ^Talk 13:33, 29 July 2026 (UTC)

Perhaps this is in one of the installed mobile apps? If so, which one? — xaosflux ^Talk 13:34, 29 July 2026 (UTC)

@~2026-42114-05: This post is the only edit by your current TA. If you make an edit where you see and tick minor edit then we may be able to tell how you made the edit. PrimeHunter (talk) 14:11, 29 July 2026 (UTC)

Check the related temporary accounts and you can see they all appear to be "Android app edit". Looking at the code, https://github.com/wikimedia/apps-android-wikipedia the minorEditCheckBox does not appear to have any conditional code to disable for TAs. A bug would need filling at https://phabricator.wikimedia.org KylieTastic (talk) 14:28, 29 July 2026 (UTC)

A previous issue was raise as T123876 but is was merged into another task T296952 and I assume got lost. KylieTastic (talk) 14:31, 29 July 2026 (UTC)

Birthday problem

Trying to get a decent interactive widget for the birthday problem article and had a thought: rather than just generating a bunch of random valid month-day combinations, wouldn't it be more fun to populate an experiment with real people? So fetching birthdays of random notable people. Is there any way this is doable in an article? I could prepopulate a list to randomly select from, but in addition to that being less convincing of randomness, a good-sized list is going to seriously bloat the size of the page. I know there are strict limitations on what can be fetched within an article, and something like scanning for random biographies and then parsing the dates in articles is not realistic, but I feel like I've seen wikidata templates/tools that might of use? Looking for help brainstorming wikidata possibilities, basically. — Rhododendrites ^talk \\ 15:00, 29 July 2026 (UTC)

Wow, I didn't know you could do stuff like that.

Maybe some combination of {{Random_page_in_category}} and {{Wikidata}}? I'm not sure how you'd check that they have birthday years listed, though. (Does your calculator gadget allow loops?) I'm also not sure what the performance/server load cost of that is. But at this point, if you come back in a couple hours I might have rabbit-holed myself into finding an answer for you.... LittlePuppers (talk) 15:48, 29 July 2026 (UTC)

Never mind, Random_page_in_category just provides a link... the wikidata template should be useful though. LittlePuppers (talk) 15:58, 29 July 2026 (UTC)

Yeah, probably best to just have a list of a few hundred popular people—that'll also make it more likely that people recognize them. LittlePuppers (talk) 16:44, 29 July 2026 (UTC)

I'm not really seeing anything in the wikibase API that would let you do this. :( Morwen (talk) 16:06, 29 July 2026 (UTC)

I think in terms of performance, it would be much better to work with a pre-calculated list (it could be stored on-wiki (with maybe a set of them that is rotated through) and be updated from time to time, perhaps using a bot). To find birthdays of notable people, I suggest using the day of the year articles (for example, July 1). isaacl (talk) 16:35, 29 July 2026 (UTC)

To be honest it would probably be better to curate the list anyway. You don't really want war criminals or serial killers appearing there do you? Morwen (talk) 16:39, 29 July 2026 (UTC)

Ha. It's a good point. I was thinking about all the controversy we saw years ago over the Monty Hall problem. That's why there's something like a "transparency" feature built into that widget -- I'm assuming that at least some of the people who use it might think it's rigged. So I'm carrying that mindset over to the birthday problem, and figure that a skeptical reader would be skeptical about a prepopulated list. Might be overthinking it, though. Maybe the way around that is to do an academic move of deferring to an existing list or category. I'll look around for a candidate. — Rhododendrites ^talk \\ 16:49, 29 July 2026 (UTC)

The names of the people aren't what generate skepticism, though: it's the randomness of selecting the birthdays. Since Wikipedia biographies are already a selected set from the general population, I don't think trying to make a random selection out of Wikipedia biographies will help much with that concern. I don't think there's any good way around the assumption that birthdays are randomly distributed. It may be instructive to provide a way to bias the selection, to show how the result is dependent on the assumption. For example, you could simulate the likelihood of duplication during the monthly birthday celebration for a large group of acquaintances. isaacl (talk) 17:15, 29 July 2026 (UTC)

I'm just talking about numbers. Seems easy to imagine a skeptical person not buying a random selection of 30 people from a curated list of 40, but assuaged by a random selection of 30 people from all million+ biographies on the project. Getting into biases in the widget is a fun idea, but it's already getting quite big as-is. :) — Rhododendrites ^talk \\ 17:26, 29 July 2026 (UTC)

And another thought - 99% of our biographies are people who might as well just have randomly generated names for all the name recognition they have. Try doing Special:RandomInCategory/Living people 20 times in a row some time and see how long many of them you've heard of. (I just did this myself and got one, although curiously that one was someone I've met in real life so go figure.) Morwen (talk) 17:32, 29 July 2026 (UTC)

Yep, I got 0 for 20. My methodology would probably be take the top few hundred biographies (probably doesn't have to be living people) by page views, sort out those without listed birthdays or with war crimes, and go from there. That's probably much more interesting for the general audience, even if it doesn't assuage the skeptics. LittlePuppers (talk) 17:49, 29 July 2026 (UTC)

I realized I was thinking about the problem from the other direction – finding representative names for the randomly selected birthdays – while you are thinking of gathering a set of names and then choosing randomly from them. I agree that it would be better to find lists of names for some suitably large categories where there shouldn't be any unnatural bias.(*) (There could be an option to choose between the different categories.) I still think not querying the database dynamically for names or birth dates is better for performance.

(*) For example, as I recall I've read that the birth dates for NHL hockey players are biased by the way players are sorted into age groups during their youth, as the oldest players within an age group generally perform better against the others in the same group. isaacl (talk) 17:44, 29 July 2026 (UTC)

If you only need to select a relatively small number of names from a larger list, and you are ok with the selection only changing each time the page is parsed, you can put the list in lua. I did something similar once with a template on commons to show a random selection of quality images. Only the items selected go into the page, but its a different selection every time the page gets parsed. Bawolff (talk) 18:28, 29 July 2026 (UTC)

I made a demo of what I mean at Module:Sandbox/bawolff/Birthday. It gives results like: Victor Hess was born on Jun 24. Benjamin Netanyahu was born on Oct 21. Niels Bohr was born on Oct 7. Bawolff (talk) 21:01, 29 July 2026 (UTC)

Try Category:2025 deaths (11,880). There are plenty to pick from and their birth dates should be truly random. --Redrose64 🌹 (talk) 18:45, 29 July 2026 (UTC)

User:Mathbot needs a new owner

Crossposting at Wikipedia:Bots/Noticeboard#User:Mathbot needs a new owner for best coverage. User:Oleg Alexandrov has asked in a recent discussion:

Are there any poeple willing to maintain this bot? Last time I worked with Dreamrimmer who is listed as co-owner at https://toolsadmin.wikimedia.org/tools/id/mathbot. If he is around, or somebody else is willing to help adopt the bot, that would be great. It has been too long and I don't visit much or remember how things work anymore.

Note that Mathbot is a fairly important bot, as it cues up the new pages for AfD and maintains other aspects of AfD. BD2412 T 15:09, 29 July 2026 (UTC)

Mathbot co-maintainer here. I'm around if you need anything. – DreamRimmer ■ 15:37, 29 July 2026 (UTC)

@DreamRimmer: Mathbot's instructions currently say for questions to be asked on Oleg's talk page. Would you be okay with that instruction being changed to your talk page? BD2412 T 19:08, 29 July 2026 (UTC)

VE made default on mobile web following RfC

Hi all! To implement the result of a recent CENT-listed RfC, we have made VisualEditor the default for new editors on mobile web. Further information about our current and planned work on VE can be found in the discussion there. Please let us know if you spot any issues, and thanks as always for your collaboration! Cheers, Sdkb‑WMF ^talk 15:45, 29 July 2026 (UTC)