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, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230

Question

I'm not sure of the apt forum for this, but why does audio files with captions pop up full screen in mobile without the option to simply play it without captions and not have it pop up every time. Compare UK and Ukraine. One of them full-screens with the subtitles and the other has none so it does not. Can this be avoided? Using Chrome on an iPhone. ~2026-34629-56 (talk) 10:46, 12 June 2026 (UTC)

Because it has no funding and this is easier to maintain. —TheDJ (talk • contribs) 16:15, 12 June 2026 (UTC)

No funding? Really? ~2026-34629-56 (talk) 17:18, 12 June 2026 (UTC)

@~2026-34629-56 I do think it is a good default to display Closed Captions if they are available. While File:Президентський оркестр Гімн.ogg does not have subtitles, while File:United States Navy Band - God Save the Queen.oga does have subtitles.

I do not see an immediate way to disable displaying substitles on a user setting level nor on specific Wikipedia pages. The feature is described at mw:Extension:TimedMediaHandler, which has limited maintenance. I do think it is a good default to display Closed Captaions if they are available. ~ In solidarity 🦝 Shushugah (talk) 13:06, 13 June 2026 (UTC)

It's unusual that they do not let you disable captions. Strange. ~2026-34629-56 (talk) 15:57, 18 June 2026 (UTC)

Avoidwrap shrinks font size on mobile

Currently visible on the front page inside {{In the news}} RD, the name Ciarán Ó Lionáird is wrapped in {{avoid wrap}} which gives <span class="avoidwrap" style="display:inline-block;">. On mobile, this name appears in a smaller font size than the other names following / surrounding. (Not reproduced in desktop browser tools responsive emulation). Chowmein 🥡 (talk) 08:09, 15 June 2026 (UTC)

It looks normal to me in Safari on an iPhone and in the mobile version with Firefox on Windows 11. Does it happen at https://en.wikipedia.org/wiki/Main_Page?safemode=1? PrimeHunter (talk) 09:39, 15 June 2026 (UTC)

Sorry, I should have mentioned: desktop mode on mobile. Chowmein 🥡 (talk) 02:37, 16 June 2026 (UTC)

That also looks normal to me in Safari on an iPhone. PrimeHunter (talk) 10:15, 16 June 2026 (UTC)

Strange, that's what I used originally. I just checked on a second iPhone also using Safari and it appears small there as well. Chowmein 🥡 (talk) 19:47, 16 June 2026 (UTC)

Browsers try to be smart about what they think is important and what is not for web pages that they don't think were designed for mobile resolutions. When you use the desktop website on mobile, that is one such case.

In such cases, content they guess is important will be bigger and content they guess is not will be smaller. I would guess that setting a span to inline-block is one signal they use. Functionally, the only way to fix this is to use a more responsive skin. Izno (talk) 01:40, 18 June 2026 (UTC)

Wow, that's fascinating! I did not know Safari was that opinionated. Great to know, thank you! Chowmein 🥡 (talk) 01:18, 22 June 2026 (UTC)

See the Mozilla Developer Network (MDN) page on the text-size-adjust CSS property for an overview of how some mobile browser engines will adjust font sizes for legibility. (In short, pages are rendered on a canvas larger than the device's actual width (unless the page specifies otherwise), scaled down to fit the screen, and the font size adjustments are made for legibility.) The MDN page links to really old (thus possibly out-of-date) pages describing the behaviour for mobile Safari, Chrome, and Gecko (Firefox). (HTML pages using modern responsive designs explicitly tell the browser to use the device width and an initial scaling factor of 1, which disables the font adjustment algorithm.) You could try setting the text-size-adjust / -webkit-text-size-adjust property for specific elements in your your common.css file, but to be honest, I think that'll just lead to a lot of pain trying to fight the font adjustment algorithm, so I don't recommend it. isaacl (talk) 14:15, 18 June 2026 (UTC)

Very interesting. I wonder if long term the maintainers of Vector would be interested in disabling this behavior. Fascinating to learn it's Safari trying to be helpful. Thank you! Chowmein 🥡 (talk) 01:20, 22 June 2026 (UTC)

As I understand it, the Vector2022 skin was designed following modern responsive design principles, but it's disabled (so the old style render-on-a-larger-canvas-and-resize approach is used by the device) pending a community consensus to enable it. I suspect the design team would rather work with the community on improving the responsive design to the point where it gains community support to be enabled.

Note it's not just Safari. All small-screen browsers follow some procedure to render pages that were never designed to fit on a small screen in a way that keeps them as legible as possible. isaacl (talk) 01:38, 22 June 2026 (UTC)

Red dots

What are these red dots seen on source editor in this article section? I didn't add the text containing the dots and I cannot delete the dots. TurboSuperA+_[talk] 18:10, 16 June 2026 (UTC)

@TurboSuperA+ what browser are you using? Where the red dots are unicode characters that aren't the basic U+20 space character but are U+200B (zero width space) or U+20260 (word joiner), so I'm guessing your browser is highlighting these to you. Nthep (talk) 18:51, 16 June 2026 (UTC)

Double backspace erased it (when a single wouldn't). I've never seen it before. I wanted to make sure I know what it was before I break something. Thank you! TurboSuperA+_[talk] 18:57, 16 June 2026 (UTC)

You have CodeMirror syntax highlighting enabled, which by default highlights special characters. You can hover over the character itself and it will tell what it is. In this case it was a zero-width space. I don't know why you weren't able to delete it with a single ← Backspace, however. — MusikAnimal ^talk 02:16, 17 June 2026 (UTC)

You're right. I didn't think of the dot as a highlight, but it makes sense, like those reverse Ps and dots in word processors. TurboSuperA+_[talk] 05:41, 17 June 2026 (UTC)

Those reverse Ps are called pilcrows. A Wondrous Raven (talk) 00:58, 19 June 2026 (UTC) ¶

Upcoming migration to Parsoid

Hello everyone, I'm following up on the April announcement about the Parsoid migration as a heads-up about the completion of this work ahead of next week.

Parsoid has been the default parser on the English Wikipedia mobile web for the past month, serving nearly two-thirds of traffic, and many users have opted in since the April announcement. That, combined with our confidence framework, makes us confident that Parsoid is ready for the next phase for English Wikipedia and will be generally available soon.

Before we complete the transition to Parsoid for desktop, we encourage you to opt in, if you haven't already, and test your workflows to raise your concerns or issues you might have found that haven't surfaced in our tests and previous user feedback. To report bugs and issues, please look at our known issues documentation, and if you found a new bug, please report it through the "Report Visual Bug" link in the right sidebar, or create a Phabricator ticket and tag the Content Transform Team in Phabricator.

The documented known issues were considered non-blockers to the rollout due to their severity or impact and are being prioritized by our team for resolution as soon as possible once rollouts are complete.

There are also known differences between Parsoid and the legacy parser, and we have compiled instructions to help editors navigate these changes. MSantos (WMF) (talk) 09:29, 18 June 2026 (UTC)

I think PageAssessments which is primarily used on enwiki, isn't compatible with Parsoid. You might want to have that fixed first. – SD0001 (talk) 16:07, 18 June 2026 (UTC)

Thanks for pointing that out. We are reviewing that extension behavior with/without Parsoid. If you have any test cases identified that point to an error, please let us know. After an initial analysis, the code represented by the comment does work with Parsoid in its current state but would prevent features we are planning for the future. Also, that type of issue would surface in the visual diff test so it doesn't seem to be a blocker to the roll-out. If it's a quick fix, though, we will do it before the roll-out. MSantos (WMF) (talk) 07:10, 23 June 2026 (UTC)

I find it strange that phab:T221028 is not even mentioned in the known issues list or in the instructions page even though it's a change that breaks the links to many pages (like /) outside the main namespace. To me, such an issue should be enough to delay the migration until it is fixed but I guess we move fast and break things in these parts. Warudo (talk) 10:38, 19 June 2026 (UTC)

I was confused by your "outside the main namespace". Apparently what this breaks is links to mainspace articles like //Khara Hais Local Municipality or /dev/zero, when the link appears in a space that allows subpages, like Wikipedia: or User talk: . —David Eppstein (talk) 19:40, 19 June 2026 (UTC)

Thanks for pointing that out. We lost track of it over the years, and it's a very subtle change that can be tricky on visual diff testing. An initial analysis identified that this is not broken on the main namespace, so our sample didn't catch this type of behavior in the other namespaces. Either way, we are prioritizing this, but considering it not a blocker to the roll-out.

Our curated list of known issues is based on severity and impact that surfaced over visual diff testing in the past year or so. In case you believe this list is missing an important issue, please let us know. MSantos (WMF) (talk) 07:15, 23 June 2026 (UTC)

Yes, I agree with SD0001 that extensions in use on Wikipedia need to get a review for support in Parsoid (PageAssessments may not be the only one).

Section editing transcluded things is one of the biggest pain points remaining. There are some other bad display things as well, like how on mobile captions are display flex. There are existing tasks for these. English Wikipedia could use a round or two of visual delta testing for the N most-popular pages.

As I think I have said elsewhere, please make a dedicated location for English Wikipedia feedback when this goes live. We tend to be very noisy and I don't want VPT being swamped with all the potential issues.... Izno (talk) 23:29, 19 June 2026 (UTC)

The dedicated location for English Wikipedia feedback is a great idea and I haven't seen it before. I'll soon let you know where we can transfer that discussion to. Thanks for the suggestions and feedback.

Regarding the extension support audit: we have this tracking task for extensions support on Parsoid. However, Parsoid support legacy extensions as well and for some extensions we are working around the parser hooks and re-targeting the legacy parser while the extension doesn't use the Parsoid extension API, that means that these extensions, despite not converted to Parsoid yet will work normally with Parsoid during the roll-out.

That being said, the visual diff testing is another way we validate there's not something broken with the extensions. Of the test sample, 5% come from top-ranked pages, 10% come from the RC stream, 85% from the dump. For enwiki, we have run tests multiple times over the last year. The most recent run tested against about 39K titles across all namespaces. About ~14K from article namespace, and ~25K from everywhere else (10K user talk, ~5.5K talk, 2.5K user, and so on).

These tests would have surfaced issues with extensions, global gadgets, and scripts. What we can't test is specific user workflows with personal gadgets, scripts, etc. MSantos (WMF) (talk) 07:25, 23 June 2026 (UTC)

Maybe advertise at WP:VPM too. I think I also suggested requesting a WP:Watchlist notice (and maybe WP:CENT but it's not a conversation right now I suppose). Izno (talk) 21:04, 23 June 2026 (UTC)

Category changes in watchlist

How do I stop seeing Category removal/copying/addition in my watchlist? I have Category changes unchecked in my Type of change filter. Am I misunderstanding? Masato.harada (talk) 17:01, 18 June 2026 (UTC)

@Masato.harada: Are you watching the category page or the categorized pages? The setting only applies to the former. If you watch an article then there is no way to hide edits which only change the categories. PrimeHunter (talk) 17:12, 18 June 2026 (UTC)

Ah, that explains it. Thanks. Masato.harada (talk) 17:15, 18 June 2026 (UTC)

New Codex icons

Sorry if I place this here, but I've just noticed this a few minutes ago; all the icons have been updated. They are making Wikipedia new again. Any thoughts? – SimpleObjects-9ei 🏖️/☀️/🥵 (🌎 CentralAuth) 19:01, 18 June 2026 (UTC)

This is phab:T399175, which has received quite a lot of negative reviews. – SD0001 (talk) 19:23, 18 June 2026 (UTC)

As that comment-thread is long, I'll highlight the comment at phab:T399175#12035047 which gives a summary of how the constructive/precise feedback is welcome, and that there will soon be more iterations to many of the icons based on everyone's feedback. There's another task at phab:T427868 ("Icon refinement follow ups") collecting those quick follow up changes. HTH. Quiddity (WMF) (talk) 20:01, 18 June 2026 (UTC)

As someone who agrees with the many users who have expressed disappointment at the phab discussion, I'm especially interested in whether there could be a way for editors to opt-out of the recent changes (going back to what it was yesterday, in other words), until further improvements are made. I saw at the phab discussion that someone has created this: [1], [2], which didn't work for me. If there could just be an opt-in/opt-out button added to user preferences (either Appearance or Gadgets), that would be very helpful. --Tryptofish (talk) 21:26, 18 June 2026 (UTC)

I doubt they would commit to having two different versions of the icons for eternity, which is what you'd need for a preference. However someone has created User:Pattersonuwu/OldIcons.css which can be installed as a workaround. One way to install it would be to add this to your common.js file: importStylesheet('User:Pattersonuwu/OldIcons.css');. There might also be a way to @import it into your common.css file, but I haven't tested that. –Novem Linguae (talk) 00:37, 19 June 2026 (UTC)

Heyo, the documentation at User:Pattersonuwu/OldIcons shows how to add this to your common.css :3 pattersonuwu ^njz (talk) 14:22, 19 June 2026 (UTC)

Thanks, both of you. That's what I linked to in my comment. Doing it with the common.js file worked for me, and I'm happy now. --Tryptofish (talk) 20:58, 19 June 2026 (UTC)

I would recommend the common.css method since it should prevent a brief visual flash of the new icons. But anyway, glad this was helpful :) –Novem Linguae (talk) 08:02, 20 June 2026 (UTC)

I tried that just now, and the css approach doesn't work for me. I switched back to the js approach, and while I do notice that brief flash, it doesn't bother me particularly. I don't know why putting it in css has no effect for me, while js does (current version of Firefox, Legacy Vector skin), but I'm satisfied. --Tryptofish (talk) 19:52, 20 June 2026 (UTC)

@Tryptofish: You added the @import rule after the existing rules, this will not work: any @import rules must be first in the stylesheet (only blank lines and comments are allowed beforehand). See CSS Cascading and Inheritance Level 3 section 2 Importing Style Sheets. --Redrose64 🌹 (talk) 22:21, 20 June 2026 (UTC)

Thanks so much for explaining that. I simply used the "copy" button in the documentation to copy what I then pasted into my css file, so that should be corrected. It looked a bit "off" to me at the time. Maybe I'll try it again if the brief flash at the beginning starts to annoy me. --Tryptofish (talk) 23:38, 20 June 2026 (UTC)

done --Redrose64 🌹 (talk) 00:13, 21 June 2026 (UTC)

Works, thanks. --Tryptofish (talk) 17:53, 21 June 2026 (UTC)

Does anyone know why the URLs are base64 encoded? TurboSuperA+_[talk] 05:33, 20 June 2026 (UTC)

They're data URLs, so the actual image data is contained within them, rather than pointing to a location on the web. There are pros and cons to this approach. isaacl (talk) 05:51, 20 June 2026 (UTC)

That's what I thought, but why are they wrapped in url() ? TurboSuperA+_[talk] 05:54, 20 June 2026 (UTC)

That's the syntax in CSS. isaacl (talk) 07:10, 20 June 2026 (UTC)

Thanks. I actually didn't know that was possible. Very cool and useful (for some use cases). TurboSuperA+_[talk] 07:15, 20 June 2026 (UTC)

The new "DownTriangle" is terrible; it's so small now on my watchlist that's it's barely even visible. Some1 (talk) 23:09, 18 June 2026 (UTC)

Yes, everything looks to me like it was drawn, crudely, with a very thick-tip magic marker. --Tryptofish (talk) 23:13, 18 June 2026 (UTC)

Yeah, DownTriangle now looks like some Windows Vista/7/8/8.1 (RT) & Windows Server 2012/2012 R2 shenanigans (the dropdown button which you would see on the bottom right of the desktop). It looks EXACTLY like that, just that the Wikipedia version is black. I do not use Watchlist, but why they would resize downTriangle like x0.5 times tinier? And, even better, who asked for this? There shall be justice if any user is upset with the new icon update. – SimpleObjects-9ei 🏖️/☀️/🥵 (🌎 CentralAuth) 23:33, 18 June 2026 (UTC)

This sounds like phab:T429642, which is a bug and has a patch written that will be merged and deployed shortly. –Novem Linguae (talk) 00:38, 19 June 2026 (UTC)

Also, just occasionally to let you guys know, the release notes for MedaWiki 1.47/wmf.7 (first deployed 16 June 2026) shows the following line which I'll show below:

git #4c4f84d9 - Update Codex from v2.5.1 to v2.6.0 (T328496) (T361508) (T399175) (T404328) (T426193) by Roan Kattouw

The git commit must say anything about what we got for Thursday. Also, Codex actually had versions (see MediaWiki 1.38/wmf.23's release notes for a prototype version v0.1.0-alpha.3 of Codex from 2022, as an example) Just make sure to check out the rest of the Phabricator links to see what else is going on this mayhem. The one who is doing the changes is User:Roan Kattouw (WMF). He is a Wikimedia Foundation employee, so should we head over to Wikipedia:Village pump (WMF) to continue this chit-chat or what? – SimpleObjects-9ei 🏖️/☀️/🥵 (🌎 CentralAuth) 15:14, 20 June 2026 (UTC)

The person you mentioned is just the deployer. Someone else is the one redrawing the icons. More info in this ticket.

They do seem to be responding to our feedback and willing to adjust the icons that we don't like. So we may not want to make too big of a stink about this. Front end changes will always be more controversial and subjective than back end changes. –Novem Linguae (talk) 14:44, 21 June 2026 (UTC)

Just restating this here for anyone finding this thread, you can (mostly) revert this change yourself with User:Pattersonuwu/OldIcons. pattersonuwu ^njz (talk) 14:25, 19 June 2026 (UTC)

What's the performance impact of loading an 418kb css file? Sjoerd de Bruin (talk) 14:42, 19 June 2026 (UTC)

I dunno, but we shouldn't be having this conversation here anyways pattersonuwu ^njz (talk) 14:49, 19 June 2026 (UTC)

Izno, I don't see how you can deny that this (and the other two below) are ITSTHURSDAY issues. They all appeared with the latest MediaWiki revision. I have a fourth issue to report. For many years now, on category pages, the entries under the "Subcategories" heading (if one exists) are preceded by a little triangle, which normally points right, but points down when a parent cat is expanded to show its children. As of the new MediaWiki, this triangle has got much smaller, and is now too small to distinguish the right-pointing triangle from the down-pointing one. I'm not going to moan and wait while phab tickets are ignored, I'll do something about it. This CSS rule will restore the previous size:

/* restore triangles in category pages to previous size */
@supports (-webkit-mask-image:none) or (mask-image:none) {
  .CategoryTreeToggle,
  .CategoryTreeEmptyBullet {
    -webkit-mask-image: url("data:image/svg+xml;utf8,<svg xmlns=\"http://www.w3.org/2000/svg\" width=\"20\" height=\"20\" viewBox=\"0 0 20 20\" fill=\"black\"><path d=\"M10 15 2 5h16z\"/></svg>");
    mask-image: url("data:image/svg+xml;utf8,<svg xmlns=\"http://www.w3.org/2000/svg\" width=\"20\" height=\"20\" viewBox=\"0 0 20 20\" fill=\"black\"><path d=\"M10 15 2 5h16z\"/></svg>");
  }
}

It goes in meta:Special:MyPage/global.css. For those interested, and who understand SVG, the significant bit is the path M10 15 2 5h16z which overrides the path M14 7H6v2.5l4 3.5 4-3.5z used by the newest MediaWiki. --Redrose64 🌹 (talk) 20:43, 19 June 2026 (UTC)

I did not deny that it was a Thursday issue. I disagreed that it made sense to group all of these sections together strictly on the basis that they are Thursday issues. They are all more-or-less distinct issues that are coincidentally appearing at the same time and as such will have naturally different resolution paths, which we should allow to archive at the usual arbitrary rate individually.

Your icon issue seems fine to put in this section. I do think it is a mistake not to report this upstream. The issue pertaining to the watchlist reported above is already soon-to-be-resolved. Izno (talk) 21:09, 19 June 2026 (UTC)

The inbox icon has changed

Is there a place where we can read the "changelog" to find out why things were changed? I'm not opposed to change, it'd just be nice to have a heads-up/explanation. TurboSuperA+_[talk] 05:19, 20 June 2026 (UTC)

Here! Also being discussed above at #New Codex icons. Chaotic Enby (in solidarity · talk · contribs) 05:25, 20 June 2026 (UTC)

Thank you! TurboSuperA+_[talk] 05:28, 20 June 2026 (UTC)

Why not let us choose the icon pack?

We can choose from a bunch of different themes, why not choose the icons, too? People are using custom javascript and css to change the icons to the old ones, but it doesn't have to be that hacky. Give us a radio button in theme settings, and Robert is your mum's brother. TurboSuperA+_[talk] 09:47, 22 June 2026 (UTC)

We can already pick our skin, so that should be technically feasible, although the worry is that both packs will have to be maintained and considered for any future tools being developed. Chaotic Enby (in solidarity · talk · contribs) 23:06, 22 June 2026 (UTC)

I think problem is the technical debt and maintenance cost that will be associated with keeping multiple version of different icons around is significantly higher compared to the upside of we avoid a bit of bikeshedding discussion every five or so years. Sohom (talk) 23:22, 22 June 2026 (UTC)

Is there any issue with keeping old icons (and making them available via a user preference), but simply not updating them and using new icons when an old one isn't available? Technically speaking, that would just be loading one additional CSS file. sapphaline (talk) 06:31, 23 June 2026 (UTC)

It's technical debt, now every single developer making frontend changes will need to test two different versions to make sure their code works (make that X more versions every time icons change). On top of that these CSS files must be updated to keep in line with modern web standards. None of this applies to a userscript. And maintaining this is a significant overhead compared to bikeshed icons a bit every few years or so. Sohom (talk) 07:29, 23 June 2026 (UTC)

"CSS files must be updated to keep in line with modern web standards" - like what standards? Monobook still works despite not changing its layout (and the way this layout works) since 2004. sapphaline (talk) 07:39, 23 June 2026 (UTC)

There have been a great many patches to Monbook since its creation. https://gerrit.wikimedia.org/r/q/repo:mediawiki/skins/MonoBook+is:merged+branch:master Software has a constant maintenance cost that isn't always super obvious. –Novem Linguae (talk) 07:46, 23 June 2026 (UTC)

The CSS standard is the standard I was referencing. The best practices surrounding CSS keep evolving as the standard evolves almost all the time. Monobook still works despite not changing its layout (and the way this layout works) since 2004. -- Right, you do realize that is not because "somebody wrote it and it kept working", but rather developers have had to go out of their way to keep it working by fixing bugs/maintaining compatibility with the rest of the interface and in general spending a significant amount of time maintaining it, trying to preserve compatibility with the older layout. (what Novem points to is the tip of that iceberg). To give you a example, the way the gradient on top bar in classic Vector looks has been rewritten atleast 3-4 times to keep up the with the CSS standards of the times since I joined despite remaining looking the same over time. Sohom (talk) 07:53, 23 June 2026 (UTC)

cjkv template error

As visible in Gando Convention—an additional semicolon is erroneously added. TE(æ)A,ea. (talk) 19:12, 18 June 2026 (UTC)

Looks like it was fixed in the sandbox a few months ago, if someone wants to run through the testcases and verify before moving it over. SarekOfVulcan (talk) 19:19, 18 June 2026 (UTC)

Edit button is wonky

The "view | edit | history | purge" links on template documentation look incorrect, like [ | history ]. See Template:Template link for an example. It persists across Vector 2022, Vector legacy, and Monobook, but looks fine in Timeless. I'm guessing this is a WP:THURSDAY issue? Any help would be appreciated :) Best, HouseBlaster (talk • he/they) 20:10, 18 June 2026 (UTC)

Yes, it's a Thursday issue, and one that I am to be blamed for (at least for requesting it, I didn't do the work). Izno (talk) 20:15, 18 June 2026 (UTC)

The relevant implementation task is phab:T268900. We will need to adjust onwiki. Izno (talk) 20:17, 18 June 2026 (UTC)

Which actually doesn't have that many adjustment points, modulo whatever is happening in user space. [3] Izno (talk) 20:27, 18 June 2026 (UTC)

Is the change from T268900 stable-ish? As in, should I start updating the userscripts that were affected, or would you recommend waiting a bit? I don't see any linked tickets/tasks on Phabricator and nothing pointing to future changes in comments, but maybe there's relevant discussion elsewhere that you know about. —⁠andrybak (talk) 10:49, 23 June 2026 (UTC)

phab:T268900#12045614. I suppose you can read the bit of chatter about list elements as potentially interesting. Izno (talk) 19:11, 23 June 2026 (UTC)

Made an update to Module:Documentation that should fix the immediate impact for page-related actions for docs. (Personally I think it would look more consistent like this, too.) stjn 22:41, 18 June 2026 (UTC)

Images being massive

Resolved

I've noticed that, starting today, images using upright instead of thumb, are massive. An example of this is the images in the table on Mandurah line. The images were normal size yesterday. What's up with that? Steelkamp (talk) 08:05, 19 June 2026 (UTC)

I also see huge images in the Stations section. Certes (talk) 08:29, 19 June 2026 (UTC)

Is this part of the #"Upright" parameter in image embedding broken? problem? DMacks (talk) 08:36, 19 June 2026 (UTC)

Hmm, not sure Yesterday I was told I should convert images using px to using upright, and it was working properly then. Steelkamp (talk) 08:38, 19 June 2026 (UTC)

That timing does feel like WP:THURSDAY. CMD (talk) 09:32, 19 June 2026 (UTC)

I'm seeing the same problem with a copy of that table, plus a few more examples, at my sandbox. The upright option does not appear to be applied unless thumb is present. – Jonesey95 (talk) 14:55, 19 June 2026 (UTC)

@DMacks: It's definitely a different problem. The earlier one did not affect Firefox 152; this new problem does. --Redrose64 🌹 (talk) 17:12, 19 June 2026 (UTC)

Looks like the fix from phab:T429551phab:T424596 broke things. The parser is now outputting width: calc(@{@calc-standard}) which is invalid CSS. --Ahecht (TALK
PAGE) 15:51, 19 June 2026 (UTC)

Pinging @Jdlrobson. --Ahecht (TALK
PAGE) 15:57, 19 June 2026 (UTC)

The patch in phab:T429551 hasn't been deployed yet. From the looks of phab:T67889, "upright" has never applied to inline images unless the "frameless" format is used. ABreault (WMF) (talk) 16:00, 19 June 2026 (UTC)

@ABreault (WMF) Sorry, I meant phab:T424596, which was responsible for that invalid CSS (that's what I get for having too many tabs open at once). I think there is a stray "@" character in the patch that was rolled out, but I put more details in the task. --Ahecht (TALK
PAGE) 16:22, 19 June 2026 (UTC)

I replied on ticket. While it is true there is invalid CSS here, I am now wondering if this rule should be deleted and making this the default behaviour. We should not be making users download large megabytes images and hiding that fact by scaling them down in CSS. Jdlrobson (talk) 17:23, 19 June 2026 (UTC)

ABreault (WMF) is right. I forgot about mw:Help:Images#Rendering a single image, which says of upright, "Requires either thumb or frameless." That is not intuitive and was apparently undocumented until three years ago. Steelkamp appears to have caused these giant images in Mandurah line to render by changing px values to upright values without adding "frameless". – Jonesey95 (talk) 23:16, 19 June 2026 (UTC)

Thanks everyone for your help! Steelkamp (talk) 23:50, 19 June 2026 (UTC)

@Jonesey95: It's been documented for far longer than three years; something similar was added to WP:EIS over seventeen years ago. The earliest mention that I can find was added at 21:15, 14 June 2009 (UTC), the text at that time being "must be used along with the 'thumb' or 'thumbnail' parameter". It's been amended a few times since, such as to add frameless - which wasn't a valid option until later that year. --Redrose64 🌹 (talk) 00:04, 20 June 2026 (UTC)

Giving permanent ban to non-registered editor

While reviewing the edit history of the Wikipedia page below, I noticed that user "Singasigmaskibdiboi" added a large amount of nonsensical content and then reverted the page about a minute later: https://en.wikipedia.org/w/index.php?title=Sv%C3%A4t%C3%BD_Jur&diff=1359211049&oldid=1359210978 Could an administrator please review this behavior and consider appropriate action, including a possible indefinite block of the account (or associated IP address)? Thank you for your time and assistance.Tbartovic (talk) 17:18, 19 June 2026 (UTC)

@Tbartovic Your request would be more appropriate on WP:ANI. Izno (talk) 17:48, 19 June 2026 (UTC)

'Preview page with this template' no longer works when editing a module

Tracked in Phabricator
Task T429710
Invalid

I use that functionality a lot and now it doesn't work. I've reported this at phabricator for whatever that's worth and am posting this here as a general notification.

—Trappist the monk (talk) 22:49, 19 June 2026 (UTC)

@Trappist the monk: You changed Template:Current leader to invoke Module:Current leader/sandbox instead of Module:Current leader.[4] Was that an accident? It means Template:Current leader/testcases uses Module:Current leader/data/sandbox instead of Module:Current leader/data. If you edit Module:Current leader/data/sandbox, enter Module:Current leader/data/sandbox in the "Template name" box and Template:Current leader/testcases in the "Page title" box, then it works as expected for me. PrimeHunter (talk) 01:50, 20 June 2026 (UTC)

Thank you. Mea culpa.

—Trappist the monk (talk) 12:56, 20 June 2026 (UTC)

Quarry help

Looking for some Quarry assistance... Trying to write a query that list every Infobox template AND the number of transclusions that each has. Doesn't seem to be working... Any help apprecaited!

SELECT 
    p.page_title AS template_name,
    COUNT(tl.tl_from) AS transclusion_count
FROM page p
LEFT JOIN templatelinks tl 
    ON p.page_id = tl.tl_target_id
WHERE p.page_namespace = 10                  
  AND p.page_title LIKE 'Infobox%'          -- Starts with "Infobox"
  AND p.page_title NOT LIKE '%/%'           -- Excludes any title containing a slash "/"
  AND p.page_is_redirect = 0                -- Exclude redirect templates
GROUP BY p.page_id, p.page_title
ORDER BY transclusion_count DESC;

Zackmann (^{Talk to me}/_{What I been doing}) 04:43, 20 June 2026 (UTC)

WP:RAQ for the future. Izno (talk) 05:08, 20 June 2026 (UTC)

Posted there and will take questions there instead in the future. Didn't know that even existed! Zackmann (^{Talk to me}/_{What I been doing}) 05:16, 20 June 2026 (UTC)

Help with a template

Please see Template talk:WikiProject Ice Hockey#Main category. AIUI it's a simple change but needs a template editor or admin. This is related to Wikipedia:Bots/Requests for approval/PhuzBot 10. WhatamIdoing (talk) 17:57, 20 June 2026 (UTC)

Skip to top and bottom covering content

{{Skip to top and bottom}} covers content in the bottom right corner on Vector 2022, as can be seen at the help desk. This is bad, as it can make text hard to read, and obstruct links. I propose either A: moving the button to the bottom left corner (demoed in the sandbox), or B: hiding it entirely in Vector 2022. I understand Matrix originally moved the buttons into the content area to stop them covering links, but that doesn't seem to happen for me. My first preference is A, but if it does cover links, then I would support B instead. Danski454 (talk) 02:58, 21 June 2026 (UTC)

An easier solution is simply removing the template. Izno (talk) 03:26, 21 June 2026 (UTC)

This matter comes up occasionally at Template talk:Skip to top and bottom, and as seen in the most recent thread there, has also come up on this page in the past. The problem is that we don't know (we cannot know) what might be behind the buttons, so we cannot position the buttons into some blank space or otherwise harmless area.

As Izno says, you can remove the template; the problem with doing that is that somebody else might restore it. Alternatively, you can hide them for yourself, leaving them visible for everybody else, as described at Template:Skip to top and bottom#Example. --Redrose64 🌹 (talk) 07:01, 21 June 2026 (UTC)

I still think that, rather than making everyone else hide it on a small random set of pages, people who want this should make a user script or gadget that would add it for themselves to every page. Or maybe even a browser extension to add it on every website. Anomie⚔ 12:23, 21 June 2026 (UTC)

I've removed the template from WP:HD (partly as a test to see if anyone objects). If we can't find somewhere harmless to put it, then I would support removing it from other pages, and marking the template deprecated. Danski454 (talk) 14:07, 21 June 2026 (UTC)

Can we please require a space after a URL in a template parameter?

I work with reference templates quite a lot, and in quick succession, and it is a minor but persistent annoyance to me that sometimes it is not easy to see exactly where a URL ends and the next parameter begins because there is no space before the next pipe. I think it would be trivially easy to have a rule that a URL in a template with parameters separated by pipes should have a space before the pipe, and have a bot go around and add those spaces. BD2412 T 03:02, 21 June 2026 (UTC)

This is not a technical question. You will want to ask this at WP:VPPRO or WT:MOS. Izno (talk) 03:27, 21 June 2026 (UTC)

@BD2412: "space before pipe" would be an excellent rule in all citation templates. DuncanHill (talk) 21:42, 21 June 2026 (UTC)

@DuncanHill and Izno: Posting this at WP:VPPR now. BD2412 T 21:48, 21 June 2026 (UTC)

Harv duplicate target error

There is a Harv error: duplicate target for CITEREFPollard2006 in History of fascism. It has to do with two chapters by the same author in a book edited by someone else. I can't see how to fix it. Can anyone help? Thanks, DuncanHill (talk) 21:40, 21 June 2026 (UTC)

Add |anchor-year=2006a or |anchor-year=2006b to the appropriate {{harvc}} templates. Change the matching {{sfnp}} templates to use those disambiguated anchor years.

—Trappist the monk (talk) 21:51, 21 June 2026 (UTC)

@Trappist the monk: Many thanks, worked straight out of the box. DuncanHill (talk) 21:56, 21 June 2026 (UTC)

Cross-wiki transclusion?

Is that even possible? Like {{meta:User:ABx11}}? --ABx11 (she/they | formerly TheAuroraBorealis | In solidarity) 22:46, 21 June 2026 (UTC)

No. User pages created at Meta do have a cross-wiki display, but transclusion of arbitrary pages or templates does not work. Izno (talk) 23:27, 21 June 2026 (UTC)

See also mw:Manual:$wgEnableScaryTranscluding. Johannnes89 (talk) 13:56, 22 June 2026 (UTC)

I believe it was a community wishlist thing. But in view of recent events, is probably now dead. --Redrose64 🌹 (talk) 15:26, 22 June 2026 (UTC)

Is it normal for Wikipedia edits to take a long time to save?

I have a Dell XPS 13 9380 (2019 model) running Windows 11. My problem is that when I click "Publish changes" after making an edit, it takes like 15-20 seconds for my edits to go through. I'm not sure if this is a normal amount of time to be waiting before my changes go live. When I browse and click links, including the edit button, it loads pretty quickly. The only problem is with saving my edits. I am using source editor. My browser is Google Chrome. I have 8 GB of RAM, my CPU is an Intel Core i5-8265U, and my storage is 238 GB. My question is whether this is normal for a computer and if it is not, what I should do about it. Interstellarity (talk) 23:10, 21 June 2026 (UTC)

Save time is not a function of your computer. It is a function of the network between your computer and the WMF's computers, and a function of the WMF's computers. Izno (talk) 23:28, 21 June 2026 (UTC)

Also, when I was editing this page compared to Wikipedia talk:Vital articles/Level 4, the save time was longer on the latter page compared to this page. What's the deal with that and can it be fixed? Interstellarity (talk) 23:39, 21 June 2026 (UTC)

That page is 350k. Page size is another factor in save time. Izno (talk) 23:42, 21 June 2026 (UTC)

The biggest time of a save is spend in parsing and converting the new version to HTML. The bigger the page the longer the save will take, because it has to spend more time converting saving, understanding and validating the wikitext and then converting it to HTML and caching it. The next person seeing the article will then (most of the time) get a shorter page rendering time as some of the time has already been spent by you. Anonymous users get their results from an even faster cache, because it doesn't have to take into account user specific things like account name, preferences, etc. The solution is either massive changes to how wikitext works (we really should, but there is no way people would ever agree to it), or showing you the old version after you save, or simply make the page smaller. While the speed of your computer and your internet is a factor in submitting and rendering the new page, and also scales with the size of the article, the time spent at the serverside is generally a larger ratio of the total time. —TheDJ (talk • contribs) 14:40, 22 June 2026 (UTC)

PDF not working

I uploaded a PDF file to Commons, File:Is Lindbergh a Nazi?.pdf, and I tried to follow the advice at Help:Extended_image_syntax#Page, but it is not working when I add it to the article Leon Milton Birkhead. I just see the file name on PC. I checked on IOS and I just see the error file that happens when I click on the page here. Everything seems to be working fine on the Commons file itself, Commons:File:Is Lindbergh a Nazi?.pdf. 1brianm7 (talk) 03:20, 22 June 2026 (UTC)

@1brianm7 for some reason the file isn't pulling through from Commons as you can see with the 0 x 0 size. I've tried purging the file but with no luck. Nthep (talk) 07:32, 23 June 2026 (UTC)

I just tried reuploading the file with a normal PDF, as I wondered if it had been caused by me uploading the PDF with text, but it appears to have broken the file anymore. Before I did that, the front page of the file had started appearing in the article, no longer appearing as File:Is Lindbergh a Nazi?.pdf in article text, but the PDF feature was still broken. Since reuploading it, it is back to appearing as File:Is Lindbergh a Nazi?.pdf 1brianm7 (talk) 07:43, 23 June 2026 (UTC)

You could upload just the cover as a jpg or png if you just want to illustrate the pamphlet. Nthep (talk) 07:46, 23 June 2026 (UTC)

Failed to fetch notifications

Tracked in Phabricator
Task T428198
Resolved

The alerts icon next to my username at the top right of the screen shows that I have one notification, but it is greyed out. When I click on it, it reports "failed to fetch notifications". Please assist me in getting rid of this, thank you. --Viennese Waltz 06:48, 22 June 2026 (UTC)

It was a software bug: T428198 and it should be fixed as of a few minutes ago. Matma Rex talk 15:41, 22 June 2026 (UTC)

Odd behaviour of tm:Reflist

I don't know if this is just me, but over the last week or so {{reflist}} doesn't put references into columns. The odd behaviour is that setting a column width of 30em causes the references to be in columns, but 30em is meant to be the default so it shouldn't cause a change. This is a problem that used to plague the use of references/ tags but I thought that was fixed. -- LCU ActivelyDisinterested «@» °∆t° 10:10, 22 June 2026 (UTC)

I just checked a few random articles and see no issues. Can you give an example of where you see it, also what skin do you use? KylieTastic (talk) 10:16, 22 June 2026 (UTC)

I use the desktop site on mobile (Chrome on Android), using the vector 2010 skin. The odd part is the split behaviour, setting the default shouldn't change how it works. -- LCU ActivelyDisinterested «@» °∆t° 10:28, 22 June 2026 (UTC)

I checked on desktop site on mobile Chrome on iPhone with vector 2010 skin and I don't get the issue. I guess wait and see if anyone else is experiencing the same issue. KylieTastic (talk) 13:34, 22 June 2026 (UTC)

Im wondering if something upstream has made a change that is checking my screen aspect ratio when formatting the references in the page, and is overriding my request for the desktop site when it comes to how references are displayed. I know they've been working in that area. -- LCU ActivelyDisinterested «@» °∆t° 13:39, 22 June 2026 (UTC)

Are there more than 10 references in the reference list you're looking at? The default behavior doesn't add columns until after that. Otherwise, giving specific details as to what page you're looking at, and any other details that might be relevant, would help people look. Anomie⚔ 11:11, 22 June 2026 (UTC)

Thousands of reference, I'm well aware of the default behaviour. Any, and all, pages. This isn't an isolated incidence but every page I've look at over the last week or so. -- LCU ActivelyDisinterested «@» °∆t° 12:25, 22 June 2026 (UTC)

Hmm. You said that {{reflist|30em}} makes columns for you, but how about {{reflist|33.3333em}}? For hysterical raisins, the column width passed to {{reflist}} is multiplied by 0.9. OTOH, if you're using Vector 2022 in "Standard" width or Minerva, the default column width is actually 27em (gerrit:1185300→gerrit:1238682→gerrit:1238683) which does correspond to {{reflist|30em}}. Anomie⚔ 12:56, 22 June 2026 (UTC)

Yes {{reflist|30em}} makes columns but {{reflist}} doesn't. I was expecting these to have the same behaviour. I remember a discussion about the use of <reference>...</reference> and that it doesn't apply sizing using the same method as {{reflist}}, but I think that was fixed. That used to produce the same inability to produce columns correctly. -- LCU ActivelyDisinterested «@» °∆t° 13:37, 22 June 2026 (UTC)

You are probably thinking of WP:Village pump (proposals)/Archive 223#c-DLynch (WMF)-20250907014600-Anomie-20250904114700 / phab:T334941 (which got fixed indeed). Johannes Richter (WMDE) (talk) 13:46, 22 June 2026 (UTC)

Thanks, you have a much memory (or searching skills) than me. -- LCU ActivelyDisinterested «@» °∆t° 13:50, 22 June 2026 (UTC)

phab:T334941 got fixed by having Vector 2022 set 27em rather than 30em. Later, {{reflist}} was changed to apply the font size in the same way that <references /> does, but it intentionally handles specified widths like {{reflist|30em}} in a way that gives the same column width that it did previously. That's in part to not break 2-columns on Vector 2022 where {{reflist|30em}} had worked before but wouldn't with the new method (i.e. the same reason that phab:T334941 was fixed by lowering it to 27em for Vector 2022). Anomie⚔ 00:02, 23 June 2026 (UTC)

So reflist was changed to match reference tags rather than the other way round, and then only vector 2022 was changed to fix the issue? -- LCU ActivelyDisinterested «@» °∆t° 10:27, 23 June 2026 (UTC)

I think you have that backwards, Vector 2022 was changed first. Anomie⚔ 11:52, 23 June 2026 (UTC)

But still why was Vector 2022 changed and not the incorrect behaviour of reflist, it seems like a weird bodge. Any chance this can be fixed by some personal CSS? -- LCU ActivelyDisinterested «@» °∆t° 21:29, 23 June 2026 (UTC)

In Vector 2022 with its default settings, <references /> would display only one column when people expected two. That's why things were changed for that skin. {{reflist}} was changed because people were complaining about differences between it and <references /> that were holding up implementation of this RFC; reducing the differences was a way to resolve that. As for personal CSS, you might try something along the lines of .mw-references-columns { column-width: 27em !important; }. Anomie⚔ 23:15, 23 June 2026 (UTC)

Template-generated redlinked category, again

The latest run of Special:WantedCategories features a redlinked Category:2nd-millennium disestablishments in the Dutch East Indies, which got deleted at CFD yesterday but has failed to get emptied out — and it's being autogenerated and transcluded by the use of {{Disestablishment category in country by century}} on its contents, but I'm struggling to figure out how to eliminate it myself since it isn't directly coded in that template. So could somebody with more expertise in the template coding sphere make that category go away? Thanks. Bearcat (talk) 12:39, 22 June 2026 (UTC)

I think I've fixed it - I just removed the 2nd (not 2nd|) from the {{Disestablishment category in country by century}} in the 2 categories it was used on. KylieTastic (talk) 13:47, 22 June 2026 (UTC)

Finding the expensiveness in new template calls

According to a recent API query (matching title and timestamp), Special:Diff/1357030472 caused List of state roads in Malaysia to exceed the WP:EXPENSIVE limit. But I am completely paralyzed as to how one would go about resolving it. I can see that there are new calls to {{Flag}}, {{JKR}}, {{JKR(T)}}, but going down the transclude-chain to the modules that ultimately implement them, I do not see any of the obvious tells for expensiveness. So what's going on here? Artoria2e5 🌉 13:57, 22 June 2026 (UTC)

Also: what's expensive in Module:Citation/CS1? Oh nevermind, I see the REVISIONID likely responsible. Bit silly to die for this. --Artoria2e5 🌉 14:03, 22 June 2026 (UTC)

Oddly, testing in a sandbox the {{JKR(x)}} functions are incrementing the expense count by 1 but {{JKR}} does not. So that accounts for 521 out of the 526. As for why, I can't see a reason as they look be be pretty much the same. KylieTastic (talk) 14:40, 22 June 2026 (UTC)

{{JKR}}, {{JKR(T)}} and similar templates say: "If the proper image does not exist on this wiki or Wikimedia Commons, the template will display the route number in italics until the image is uploaded". Some images are assumed to exist with code in Module:Road data/strings/MYS, probably for efficiency after somebody saw they do exist. Others use 1 expensive parser function of 500 allowed to test for existence. The JKR templates call {{jct}} which accepts a |noshield=yes parameter to not display an image and omit the ifexist check on the image. The JKR templates don't pass on such a parameter so it cannot be used now but it could be added with |noshield={{{noshield|}}} in the jct calls. Then List of state roads in Malaysia could say |noshield=yes in some of the JKR calls where no shield is currently displayed. It would mean a shield is not automatically added later if an image is uploaded. PrimeHunter (talk) 15:13, 22 June 2026 (UTC)

I have implemented my above suggestion for {{JKR(J)}} which has 218 calls in List of state roads in Malaysia, much more than any of the other JKR templates.[5][6] None of the 218 displayed a shield before. Now the article only has 288 of 500 allowed expensive parser functions and renders fine. PrimeHunter (talk) 15:33, 22 June 2026 (UTC)

@PrimeHunter: Thanks. Although Module:Jct does not have any of the existence checks any more (there are some vestigial variables), the Module:Road_data/parser still has one and that is what's causing the expensive count. Artoria2e5 🌉 05:03, 23 June 2026 (UTC)

Proposal to refactor the way Template:Location map works in Infoboxes

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Moved to Module talk:Location map § Proposal to refactor the way Template:Location map works in Infoboxes

 – Zackmann (^{Talk to me}/_{What I been doing}) 19:56, 23 June 2026 (UTC)

I have long been kicking around the idea of refactoring the way that Template:Location map works specifically in infoboxes and want to solicit some feedback on the idea.

The problem

Every implementation of pushpin maps in an Infobox is different. There are numerous different parameters used to define the base map including: |map=, |pushpin_map=, |location_map=, |locmapin= and |map_type=. This makes it very difficult to go from one Infobox to another as you never know what parameters to use. The same issue applies to other aspects of the pushpin map such as the label, caption, label position, relief, etc. If you compare this to Template:Infobox mapframe, every single Infobox that uses a mapframe uses the exact same parameter names. Want to change the marker? That will always be set via |maprame-marker=. The zoom? Always |mapframe-zoom=. Doesn't matter what Infobox you are on.

A solution

What I would like to do is create a new entry point to Module:Location map, probably {{#invoke:Location map|infobox_location_map}}, that would allow for calling the location map (aka the pushpin map) in an Infobox and keeping the parameter names the same across every Infobox. That way, whether you are using {{Infobox settlement}}, {{Infobox airport}} or {{Infobox military installation}} the parameter names would all be the same. Just like Template:Infobox mapframe, I would also create a template for documentation (see {{Infobox mapframe/doc/parameters}}) so that documentation would be consistent across Infoboxes as well.

Implementation

Make no mistake, this would be a HUGE undertaking. It would involve refactoring close to 100 templates and then doing bot runs to clean up the hundreds of thousands of transclusions of those templates. Setting aside how much work it will be for a moment (and I am happy to undertake these clean ups...) my question is: "Is it worth it"? Is achieving consistency across Infoboxes and making it easier to go from one Infobox to another worth the effort here? I would argue it absolutely is, but I want to hear other inputs.

Courtesy pings: Joy, JMF, Jonesey95, Hike395, Primefac, Gonnym, Jessicapierce, GreenLipstickLesbian, Johnuniq, Phuzion, Plastikspork who I feel may have opinions on this, but of course ALL inputs welcome!! --Zackmann (^{Talk to me}/_{What I been doing}) 17:39, 22 June 2026 (UTC)

On the subject of whether it's worth it: Templates are a tool to ensure that we have consistency between articles. There's a reason we have a standardized infobox module that we use. There's a reason we use {{cite web}} when referencing web sources. I think it makes sense to have consistency between similar templates, especially when those templates are doing the exact same thing. An editor should not need to know 10 different ways to invoke a map just because they work across multiple areas of expertise on the project. As an example, if I'm working on the infobox of a racetrack and then a church later in the day, I shouldn't have to know that the racetrack infobox uses {{{track_map}}} and the church infobox uses {{{monastery map}}}.

Based on a few recent instances of negative reactions to some template changes, I can safely predict that there will be at least some opposition to some of these changes. I think that the burden will be on us as template editors to prove why the new standardized map systems will be better. We should prove to them why it's worth re-learning how to use the templates that they're accustomed to, and why they should support the cleanup effort that will ensue after said template change occurs.

If this is implemented, I think something that will ease the maintenance burden moving forward is very clear wording in previews that says "You have used {{{old parameter}}}, which is no longer supported, please use {{{other parameter}}} instead." The current wording of "deprecated parameters" is somewhat unclear to an amateur editing an infobox. In unknown parameter cleanup, we see this somewhat often. Someone sees a parameter named {{{foobar}}} and wants the label on it to read Foobars, not realizing that the {{{label}}} has {{Pluralize from text}} applied to it. They change {{{foobar}}} to {{{foobars}}} and the article gets chucked into an "unknown parameters" maintenance category.

As always, I'm here to offer my bot in support of any cleanup work that needs to be done after the fact. phuzion (talk) 18:10, 22 June 2026 (UTC)

Well as one of the editors who has had suffered a right royal pain in the ass every time I have tried to make what seemed a trivial change to the mapping in an infobox, I totally endorse this proposal. 𝕁𝕄𝔽 (talk) 18:40, 22 June 2026 (UTC)

@JMF: this one is for you Zackmann (^{Talk to me}/_{What I been doing}) 18:52, 22 June 2026 (UTC)

Can't argue with the logic here, happy to do bot runs as needed. I'll keep an eye on this discussion. Primefac (talk) 21:03, 22 June 2026 (UTC)

I think this makes sense, but I feel like I'm missing something about the implementation. Why does this require a new entry point to Module:Location map? Isn't this just a matter of editing the templates to use consistent parameter names?

Also, separate from that question, template parameters have aliases sometimes, right? To ease the transition, would it make sense to set it up so that editors using each infobox template can use either the old parameter names or the new standardized parameter names? Justin Kunimune (talk) 22:12, 22 June 2026 (UTC)

@Justinkunimune: I have not yet dived into the code so a new entry point may ultimately not be needed. The tricky part is how to make this new idea work without breaking anything else. That is why I might opt for a new entry point so that I can use the existing code but also customize it to fit. Gotta make sure that uses of {{Location map}} that are not in an Infobox continue to work when this is all done. Not 100% certain as to the how just yet, but I have a number of ideas.

As to your second question about aliases, that is 100% accurate and exactly how this will work. If we move forward with this, once the coding is done and we start the roll it out, we will deprecate the old parameter names in favor of the new names that are decided upon. Then we will do a bot run to clean them all up and only then will the old existing aliases be removed. Translation: at NO POINT should any pages be affected for the reader. This is all backend code refactoring that would only be a noticeable different if you are editing. Zackmann (^{Talk to me}/_{What I been doing}) 22:18, 22 June 2026 (UTC)

What about removing pixel map size while you are at it? MOS (manual of style) already says that images are supposed to be default size.

Images could be under 250px size. (250px is the default image width) An sub 250px image would be more likely as an non-free image.

I do not see an map being smaller than 250px wide. I ran an SQL query for an sub 250px image on commons with "map" in the name, and gave up once it had ran for 15 minutes. Mapframe would not be smaller than 250px as it uses maptiles. You would want to support countries like Norway and Vietnam that are thin and long, but that is what upright is for. See also Module_talk:InfoboxImage/Archive_2#Help_with_improving_default_image_sizes for an previous discussion. Snævar (talk) 23:35, 22 June 2026 (UTC)

@Snævar: I'm wary of removing functionality as part of this changeover. In my experience, when you mix a refactor with actual substantial changes, the project collapses. Someone objects to the change and so the refactor never occurs. While I don't disagree with your point about size vs upright, I would note that almost every Infobox has a |image_size= still.

That all being said, this changeover will make the eventual removal of |pushpin_map_size= much easier as all we have to do is remove support from the new entry point for this and poof, all transclusions no longer use it. I just think that removal warrants further discussion. Zackmann (^{Talk to me}/_{What I been doing}) 23:43, 22 June 2026 (UTC)

The technical details here are a bit over my head, but I'm extremely in favor of standardizing and simplifying things like this. Sounds like it would take some work up-front, resulting in things being more streamlined in the future. I'm all for it. Jessicapierce (talk) 01:42, 23 June 2026 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Email??

Why are we getting a 'email confirmation notice', for signing in? GoodDay (talk) 19:05, 22 June 2026 (UTC)

Was it because it was a "Login from an unfamiliar device" which is a notification option Special:Preferences#mw-prefsection-echo which you can turn off if you want. KylieTastic (talk) 19:20, 22 June 2026 (UTC)

It's a message for setting up your account. GoodDay (talk) 19:27, 22 June 2026 (UTC)

You may be seeing a banner we recently added that specifically shows to users who have not confirmed the email address on their account. If that's what you are seeing, then it means you likely never clicked on the link to confirm your email address that was sent when you first created your account. In that case, you should follow the link to confirm your email address.

Wikipedia has a high rate of users in this situation, as we haven't historically required users to complete email confirmation before allowing them to edit. But it's not a good situation for those users to be in, since they're going to be more likely to get locked out of their account if the email isn't something they actually control, and the day ever comes where they lose their credentials or get challenged to paste in a code from their email to log in. EMill-WMF (talk) 02:32, 23 June 2026 (UTC)

A little background in case you are still unsure what it's about: At some time you gave an email address which is stored at Special:Preferences. At the time Wikipedia automatically sent a mail to that address and asked you to click a link to confirm you have access to mail sent to the address, but the link was never clicked. If you don't receive a mail after using Special:ConfirmEmail then try setting another address at Special:Preferences. It's optional to set an email address. PrimeHunter (talk) 08:20, 23 June 2026 (UTC)

I don't use my email at all & never have. Just want the banner removed. GoodDay (talk) 09:09, 23 June 2026 (UTC)

@GoodDay: Either confirm or remove the email address to get the banner removed. PrimeHunter (talk) 09:20, 23 June 2026 (UTC)

Tried to remove email, but all I get is "verify your identity". GoodDay (talk) 18:48, 23 June 2026 (UTC)

@GoodDay: Doesn't it ask you to log in when it says that? I get a login page saying "You must log in again to verify that you are PrimeHunter." PrimeHunter (talk) 20:02, 23 June 2026 (UTC)

I haven't logged out, in days. GoodDay (talk) 20:10, 23 June 2026 (UTC)

@GoodDay: You aren't asked to log out and it doesn't work if you do. Just enter your username and password to confirm you are GoodDay. It's a security measure so somebody else cannot change your email address if they get access to a device where you are logged in. PrimeHunter (talk) 20:30, 23 June 2026 (UTC)

I think I got it. Left blank & submitted. The banner is now gone. GoodDay (talk) 20:38, 23 June 2026 (UTC)

I'm glad you resolved it for yourself. I do at least want to be on record here for the thread, that we strongly recommend you add a confirmed email, rather than remove it.

I mentioned above that accounts are at higher risk of lockout with an unconfirmed email. The risk is way, way higher with no email at all, as there's not even a way to reset your password. We also can't use email challenges to protect your account from takeover. So you are free to remove your email, but just know that there are risks and it is not recommended for most accounts. EMill-WMF (talk) 22:09, 23 June 2026 (UTC)

Sloppy bot archival at Talk:Vatican City

See item posted to the help desk --> Wikipedia:Help desk#Sloppy bot archival at Talk:Vatican City. --User:Ceyockey (talk to me) 22:31, 22 June 2026 (UTC)

Sometimes visual editor will undo my changes and other errors

See item posted to help desk --> Wikipedia:Help desk#Sometimes visual editor will undo my changes and other errors . --User:Ceyockey (talk to me) 03:40, 23 June 2026 (UTC)

Thanks! Should also add this mainly happens when I'm using something like Quillbot to make ONLY changes to spelling and grammar. I NEVER use its generative AI. I tested it with a non-AI extension called Harper and had the same thing happen. Wolfcolallc (talk) 03:53, 23 June 2026 (UTC)

@Wolfcolallc those kinds of tools are known to work very badly with editable HTML (which is what Visual Editor is). There's a lot of browser dependent magic that is needed in these things and then on top of that there's even more magic needed to keep wikitext and html in sync. —TheDJ (talk • contribs) 09:26, 23 June 2026 (UTC)

The top right of VisualEditor has a pencil icon which can switch to the source editor where some tools work better. I suggest to use both "Show preview" and "Show changes" before saving. The latter can reveal unwanted source code changes. PrimeHunter (talk) 09:39, 23 June 2026 (UTC)

I’ll try that! I’m also just not using the auto-fix features anymore and noticed that I’m not having the same issue. Wish it worked but it is what it is. Wolfcolallc (talk) 20:03, 23 June 2026 (UTC)

Template usage

Hi, I've posted these questions in the Wikibooks Reading Room and after about 24 hr received no response.

(1) A template declared in my account namespace works. Declared in the book namespace it doesn't work. Both cases are demonstrated in my User:PeterEasthope/sandbox. Declaration in the book is more direct; better not to depend upon an individual account. Ideas? Thx.

(2) If the desktop browser window is narrowed or the sandbox is viewed on a smartphone, the display is as illustrated here. How can the black perimeter frame be shrunk automatically to fit the background color boxes?

Thanks, ... PeterEasthope (talk) 04:16, 23 June 2026 (UTC)

Hi @PeterEasthope, each Wikimedia wiki is independent and templates are specific to their own wiki (though some common templates get cloned on multiple wikis). And the Books namespace exists only on Wikibooks sites (I think). Unless there are Wikibooks regulars also watching this page, I think you just have to wait patiently for help at the Wikibooks page. —In solidarity with Wiki Workers United · ClaudineChionh (she/her · talk · email) 05:10, 23 June 2026 (UTC)

Wikibooks has no namespace called "Book" or "Books". I guess it's an unofficial name for their main namespace. If you transclude from mainspace then you need a colon in front to avoid transcluding from the template namespace. Somebody fixed it in [7]. I don't know whether wikibooks:Oberon/ThreeBoxes is considered appropriate use of mainspace at Wikibooks. Wikipedia wouldn't use mainspace for that. PrimeHunter (talk) 07:55, 23 June 2026 (UTC)

Chaotic template populating categories

Can somebody have a look at Template:Cathead English people by place and make it work better with category redirects? It keeps populating the wrong categories for no clear reason other than misassumptions about the names and excessive suffices. Category:People from Central Bedfordshire District and Category:People from Central Bedfordshire (district) are current examples; it should be populating Category:People from Central Bedfordshire. Thanks in advance. Timrollpickering (talk) 11:46, 23 June 2026 (UTC)

The problem is that the categories are getting speedy moved from their existing names that largely had the word district in them, without any corollary effort to update the template accordingly. So it's not that it's making incorrect assumptions about the names, it's that it's generating and transcluding exactly the names it's coded to use, but somebody moved the category within the past couple of days before one of these appears, so the old name stays a populated redlink. But since not all of the "People from X District" or "People from X (district)" categories have been moved yet, there's a high risk of breaking other unmoved categories in the process, which is why I'm not generally prepared to try to muck with the template coding myself and keep having to recreate the non-empty redlinks as categoryredirects pending other fixes by people with more expertise. Bearcat (talk) 12:09, 23 June 2026 (UTC)

@Timrollpickering: {{Resolve category redirect}} expects the category name alone and not a wikilinked category so [8] should fix some issues. Category:People from Central Bedfordshire (district) only contained Category:People from Ampthill which says district= Central Bedfordshire and now correctly adds Category:People from Central Bedfordshire instead. Category:People from Central Bedfordshire District has many pages like Category:People from Arlesey which say district= Central Bedfordshire District. This isn't covered by the current uses of {{Resolve category redirect}} in {{Cathead English people by place}} so you either have to add another use for this or change the categories to only say district= Central Bedfordshire. PrimeHunter (talk) 12:52, 23 June 2026 (UTC)

Tech News: 2026-26

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

Weekly highlight

• Growth features are now available at Wikidata. This update enables access to Mentorship (if configured), Impact module, the Help Panel, and a simplified Newcomer Homepage (without Suggested Edits). Wikidata administrators are still configuring the features through Community Configuration.

Updates for editors

• The special page Special:RangeCalculator has been created. It allows users to find an IP range without needing to rely on external tools. Until now, this tool was only available to CheckUsers. [9]
• Sub-referencing is a new MediaWiki feature that allows editors to reuse references with different details. It will be deployed to most small and medium-sized Wikipedia language versions on June 23. The FAQ lists possible actions to take on your wiki to support the deployment. Check the rollout plan for the next deployment steps. [10]
• Starting next week, users will get a notification when they are blocked or unblocked from editing, or if this block changes. [11]
• View all 32 community-submitted tasks that were resolved last week.

Updates for technical contributors

• Starting next week, abuse filters that are set to "require CAPTCHA verification" will begin to also affect users with the skipcaptcha right, which includes most autoconfirmed users. Bots are exempted. This change only affects edits that trigger an abuse filter. The skipcaptcha right will continue to exempt users from having to solve CAPTCHAs in the ordinary course of using the wikis. [12]
• Reference documentation for the Lift Wing API has moved from the API Portal to the interactive REST Sandbox.
• The API Portal wiki is now closed. For API documentation, see Wikimedia APIs on mediawiki.org. All API Portal wiki URLs (https://api.wikimedia.org/wiki/) will redirect to the mediawiki.org page starting June 22. [13]
• Detailed code updates later this week: MediaWiki

Meetings and events

• Join an online call on 25 June at 2:30pm UTC to meet the current Wikimedia interns for Google Summer of Code and Outreachy. Interns will provide an overview of their projects and a brief demo of their work so far. Attendees are encouraged to share ideas and connections in their community.

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

MediaWiki message delivery 13:03, 23 June 2026 (UTC)

My recent deleted contributions

On June 22 I marked some pages with speedy because I needed the respective titles to be cleared out for other pages to be moved to them. I didn't note down the pages where I added speedy. Would anyone be so kid to give me their list? Thanks! (Please ping.) Gikü (talk) 18:19, 23 June 2026 (UTC)

@Gikü: Your recent deleted contributions appear to be speedy tags on Nădăștia, Haiducești, and Pușcașu. —David Eppstein (talk) 18:41, 23 June 2026 (UTC)

Thank you @David Eppstein! And I am grateful to @KylieTastic for acting on my proposed rename operations. All the best! Gikü (talk) 18:53, 23 June 2026 (UTC)