Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

 Policy Technical Proposals Idea lab WMF Miscellaneous 
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.

I think this module is quite useful but I am worried that the module has gotten quite enormous and power and overly complicated to use. So I wanted to discuss splitting up the module's functions into different submodules. This would improve maintainability by allowing each submodule to function independently. There are only 25 uses of this module in other templates (despite the almost 5000 transclusions) and I believe these uses can potentially be changed to use much simpler modules for the same task.

Courtesy ping @Grufo as the sole creator of this module. Aasim (話すはなす) 01:26, 25 May 2026 (UTC)[reply]

Courtesy bump since I am not sure if others are aware, hoped to solicit further discussion as part of WP:DR, since I am not sure if Module talk:Params is closely watched. Aasim (話すはなす) 15:42, 27 May 2026 (UTC)[reply]
I’ve been watching the module for a few years now, and while I admire the work behind it, it’s always felt too large to me. I’d support moving toward a simpler approach — splitting it up where possible and documenting each (sub)module clearly so its purpose is obvious from the first couple of sentences, if not from its very name. Ponor (talk) 16:06, 27 May 2026 (UTC)[reply]
I kind of like the proposed philosophy. I remember once getting criticized for making a "God module", that is a fair critique for certain scenarios. The learning curve for using such a template or module should be very low, as in it should require very little configuration; which right now feels like the opposite. And let's not forget maintainability which this currently is very difficult to maintain. Aasim (話すはなす) 18:55, 28 May 2026 (UTC)[reply]
Seems like not that many people are interested in this topic, bump one more time before it gets archived to solicit more discussion. Aasim (話すはなす) 22:17, 2 June 2026 (UTC)[reply]
As others have pointed out at its talk page, Module:Params adds complexity that would only obfuscate anything that used it. There might be a place for Params if it completely replaced the need to understand template and/or Lua syntax. However, it's never going to do that. Maintaining a template/module that used Params would require a deep understanding of template/Lua syntax, and a deep understanding of Params syntax. It's just not a good idea for Wikipedia. Johnuniq (talk) 03:18, 3 June 2026 (UTC)[reply]
I have been following the discussion and was hoping some specific maintenance or usage issues would emerge. So far, however, most of the concerns seem to be about the general philosophy behind the module. One point that caught my attention was: “There might be a place for Params if it completely replaced the need to understand template and/or Lua syntax”. In fact, that is very close to the purpose for which Module:Params was originally written. The module was created with Latin Wikipedia in mind, where virtually nobody writes Lua modules; several complex templates had therefore been implemented entirely in wikitext and had become extremely long and difficult to maintain. Module:Params was not conceived as a shortcut for Lua programmers or as a general-purpose Lua library; rather, it was conceived as a way to write parameter-processing logic without having to write Lua code. In that sense, it was intended as a wikitext-oriented tool. The module is also more modular internally than its size might suggest. Many of its components perform relatively narrow tasks and can be used independently. As a result, it can be employed in very simple ways—for example, merely to iterate over incoming parameters—or in much more elaborate configurations. On Latin Wikipedia, where Lua itself is not widely understood, this approach has proved useful. On English Wikipedia the situation is obviously different. Here, however, the module seems to occupy a different niche: providing parameter-processing functionality for templates that are more complex than can be conveniently handled in wikitext, but for which creating and maintaining a dedicated Lua module would be disproportionate. Looking at the current usages, that appears to be roughly how it is being used. I am also not sure that maintainers necessarily need a “deep understanding” of Module:Params in addition to Lua and template syntax. In practice, most users only need to understand the subset of functionality employed by the template they are working on, just as editors working with other large modules rarely need to understand every feature those modules provide. If there are specific parts of the module that are difficult to maintain, I would be interested in discussing those cases. At the moment, though, I am not sure that a compelling technical concern has been presented. --Grufo (talk) 22:54, 3 June 2026 (UTC)[reply]
I have made an actionable proposal on Module talk:Params#Proposal to split with the intent to make the module more maintainable. I do not agree with the module being big, I see it more of being a problem of number of functions. The main problem IMO is that mainly the creator would know which global functions would be affected if an local function malfunctions. Snævar (talk) 09:27, 4 June 2026 (UTC)[reply]
As I said in Module talk:Params#Not a sustainable approach to templates: Module:Params is not a good fit for Wikipedia. It introduces a new programming language, but we already have Lua and Wikitext, and adding a third language is not a good idea. Particulary one with such unusual semantics. In a nutshell: No new templates should use this module. Existing templates that use it should be rewritten, probably as separate Lua modules. In the long run, Module:Params should be deleted. — Chrisahn (talk) 08:19, 9 June 2026 (UTC)[reply]
More details: Almost all programming languages have named variables, but as far as I can tell, the language created by Module:Params doesn't. Instead, it seems to depend on stacks and substacks, but I'm not sure how these work. I've been writing code for dozens of years in dozens of languages, and I have a hard time understanding this language. Lua is much simpler (and at the same time much more flexible and powerful). Anyone who manages to understand the Module:Params programming language will also be able to learn Lua. In the long run, using Module:Params instead of Lua is a net negative for Wikipedia. I admire the work that went into Module:Params, but it just isn't a good fit for us. Sorry! — Chrisahn (talk) 08:28, 9 June 2026 (UTC)[reply]
Wikipedia:Templates for discussion is the correct avenue for your deletion nomination, not the technical village pump. Snævar (talk) 01:41, 11 June 2026 (UTC)[reply]

User pages and suggested search results

[edit]

I'm sure this has been discussed before, but maybe someone could at least point me in the right direction. If you type most but not all of my username (e.g., "User:Extraordinary W") into the CirrusSearch search bar at the top of the page, it will suggest lots of my subpages but not the actual User:Extraordinary Writ base page. The same is true searching for some others too (e.g., Sohom Datta, CoconutOctopus, Left guide, Bobby Cohn, SilverLocust, Aoidh). What exactly causes this? Are there any solutions? Extraordinary Writ (talk) 22:09, 30 May 2026 (UTC)[reply]

You could try to delete and restore the page and wait a day to see if it's discovered by search suggestions. PrimeHunter (talk) 23:26, 30 May 2026 (UTC)[reply]
Doesn't seem to have made a difference. Extraordinary Writ (talk) 03:39, 3 June 2026 (UTC)[reply]
It suspect user pages are downranked, while subpages are not. Possibly because user pages are marked as "no index" for external search engines. —TheDJ (talkcontribs) 09:57, 3 June 2026 (UTC)[reply]
That's probably part of it, but it doesn't explain why some user pages are treated differently than others. Extraordinary Writ (talk) 03:40, 5 June 2026 (UTC)[reply]
probably something to do with fuzzy search and normal english words like "extraordinary" ~2026-33675-98 (talk) 17:11, 6 June 2026 (UTC)[reply]

Image Browsing Mobile Beta Launch Reminder

[edit]

Hi everyone,

Pinging Sohom_Datta, TheDJPrototyperspective, Waltercolor, robertsky, SuperHamster, Ponor  who have weighed in on this feature before.

A couple weeks ago we announced that the Reader Growth team would be launching a new beta feature, Image Browsing, to mobile web on all Wikipedias, which you can turn on if you want. We know there is a lot going on right now around Wishlist conversations, so we wanted to share a quick reminder that the beta feature will be happening either late this week or early next week. When we deploy to beta, it means that people who have all beta features on by default will start to see it, as well as anyone who checks the box in the beta page on their preferences.

These screenshots show the carousel experience for Image Browsing

Based on promising experiment results and community discussions, we think this feature will be useful to readers (you can click through past Village Pump updates starting here). The feature adds a horizontal image carousel on mobile showing thumbnails of an article’s images at the top of article pages with 3+ images, in addition to continuing to display them in the sections where editors have placed them.

We also built in ways for editors to configure how the carousel shows up on pages, which you can start to use during beta:

  • Controls for editors to exclude specific images from appearing in an article’s carousel. To exclude individual images from an article, editors can add class=notpageimage, which also will exclude that image from use in thumbnails shown in search or link previews, or class=noviewer, which will also exclude that image from being shown in MediaViewer.
  • Controls for editors to exclude specific articles from getting the carousel at all. To remove the image carousel from an article, editors can add the magic word __NOMEDIAVIEWERCAROUSEL__.
  • A setting enabling logged-in users to turn off the image carousel for their account. During beta, this will be found in Preferences → Beta Features. After the beta period, this will be found in mobile settings (the hamburger menu at the top of the page).

As Chaotic Enby shared on Village Pump (policy) earlier, this beta period would be a great time for editors to start discussing and implementing exclusions where needed. We plan to carefully track usage during beta, and make fixes in advance of deploying to all readers a couple weeks down the line. Please let us know any thoughts you have here or at the project page.

Thank you! EBlackorby-WMF (talk) 00:22, 4 June 2026 (UTC)[reply]

Just wanted to note that the beta feature is now live on mobile for anyone who would like to take a look. You can either access this by logging into mobile web, with your user settings beta feature for Image Browsing toggled on, or on desktop scroll down to "mobile view" at the bottom of an article, again with your user settings for Image Browsing beta toggled on. Please let us know your thoughts and ideas as you explore the feature! EBlackorby-WMF (talk) 22:06, 8 June 2026 (UTC)[reply]

Ctrl + F in new code editor

[edit]

Why Ctrl + F finds nothing in new code editor? Eurohunter (talk) 18:16, 4 June 2026 (UTC)[reply]

@Eurohunter: If you click outside the editing area Ctrl+F will search the whole page, but will only find uses within the section the editing area is currently scrolled to. You have to click within the editing area, where using Ctrl+F will open the in-built search tool which can search the entire article/template/module/etc.
The benefit with this is that you won't get false positive results when a word you're searching for appears outside the editing area on the editing page, and the in-built search tool also has a find-and-replace function.
However, if you turn off the syntax highlighter which parses and highlights the source code, using Ctrl+F will search everything on the page, including the whole editing area, just as it used to before the editor was updated. – Scyrme (talk/solidarity) 18:55, 4 June 2026 (UTC)[reply]
As someone who needs the syntax highlighter and frequently searches wikitext or code for strings, this change has been a downgrade to my workflow, requiring extra clicks. It's not the end of the world, but it would be nice if it could be fixed. – Jonesey95 (talk) 19:40, 4 June 2026 (UTC)[reply]
If using keyboard shortcuts is not a problem – there is a workaround – a shortcut (via HTML accesskey attribute) for focusing the editor (i.e. the same as clicking into it to place the cursor there). It is Alt+⇧ Shift+, (comma) or Alt+, (comma) or other modifier keys+, (comma), depending on the browser. After the cursor is moved into the editor Ctrl+F opens the editor's own search. —⁠andrybak (talk) 20:17, 4 June 2026 (UTC)[reply]
@Scyrme: Browser's Ctrl+F works now only outside editing area, while I has to use another Ctrl+F again inside editing area. This is unthinkable. Eurohunter (talk) 17:16, 6 June 2026 (UTC)[reply]
As I said earlier, if you turn off the syntax highlighter Ctrl+F works the same way it always did, if you would prefer to search inside and outside the editing area at the same time for some reason. (Though I'm honestly not sure what the use case for that would be.)
If you don't need to search both at the same time, you only need to use Ctrl+F once; simply click somewhere within the editing area first or use the shortcuts andrybak described above to save yourself the click. Maybe it's not as smooth an experience as clicking "edit" and immediately hitting Ctrl+F, but it's not a catastrophe and it's not as though the change was made without reason. – Scyrme (talk/solidarity) 17:31, 6 June 2026 (UTC)[reply]
My use case is when I'm making a set of sequential changes that I want to make as one edit, and I want to do intermediate previews of my changes. I will search on a unique phrase at the start of the passage that I'm changing within the edit box, make some changes that may scroll the edit box downwards through the text, then preview the changes. I'll search again with the same unique phrase already cached in my browser to find the corresponding location in the preview and check my changes. Then I'll scroll the preview to the next location that I want to change, and search on a unique phrase again for that location. The search will continue from the preview section to inside the edit box, placing me in the right place to make my next set of changes. Repeat until all changes are done.
I appreciate learning about the shortcut to set focus to the edit box; thanks to Andrybak and those who implemented it! isaacl (talk) 17:58, 6 June 2026 (UTC)[reply]
@Eurohunter: If it really bothers you, I think you can opt out of the new parser. Scroll to the bottom of Special:Preferences#mw-prefsection-editing to the section titled Developer tools. There's a drop-down menu for Use the new Parsoid wikitext parser. Select "Never (opt out)" and save. – Scyrme (talk/solidarity) 17:41, 6 June 2026 (UTC)[reply]
@Scyrme: How I can turn off the syntax highlighter globally? Two separate Ctrl+F and situation where Ctrl+F in editing area has to be enabled everytime you click preview is something extra wrong. Eurohunter (talk) 17:56, 6 June 2026 (UTC)[reply]
@Eurohunter: Special:GlobalPreferences#mw-prefsection-editing then it's under "Syntax highlighting". I gave it a week's trial (which is about six and a half days more than I usually permit for a new feature) and then I turned it off. One killer for me was that once in the edit box, you can't use the tab key to get out again, which is an accessibility problem. --Redrose64 🌹 (talk) 22:36, 6 June 2026 (UTC)[reply]
By pressing Escape before Tab, you will be able to move the focus out of the editor. 析石父 (talk) 01:12, 7 June 2026 (UTC)[reply]
@Redrose64 To be clear, the old code editor (Ace) also didn't allow you to tab out of the edit box, but perhaps you weren't using that highlighter either. As 析石父 mentions, CodeMirror has an escape hatch by pressing Escape followed by Tab ↹.
That said, I suspect @Eurohunter is referring to editing wikitext, not code. In the older Ace version, the browser's Ctrl+F feature didn't search within the editor, either.
It's also worth noting that by default (for both wikitext and code), focus is put on the editor when first loading it, so Ctrl+F should already search the editor contents. If you need to search outside the editor, simply press Ctrl+F again to open the browser's search. MusikAnimal talk 00:57, 8 June 2026 (UTC)[reply]
CodeMirror has an escape hatch by pressing Escape followed by Tab ↹. – the first Tab ↹ moves the cursor into the "Edit summary" text field. The same can be achieved via the accesskey B (e.g. Alt+⇧ Shift+B or Alt+B or other, depending on the browser). —⁠andrybak (talk) 01:30, 8 June 2026 (UTC)[reply]
@Scyrme I don't believe what's being discussed here has anything to do with Parsoid. MusikAnimal talk 00:44, 8 June 2026 (UTC)[reply]

Log-in issue

[edit]

VP tekkies, I'm bringing this conversation here at the suggestion of the Help Desk, where I started off with this issue. I thought it would be easier on both you and me just to copy the conversation in its entirety from there, so here goes ...

Me: Over the past week or so, I'm getting notices in the morning when I go to a page and try to do something like writing a message, asking me to log in because — for some unknown reason — I'm logged out even though the previous day I got a similar statement about being logged out and accordingly logged in as requested. So again I log in, only for the same thing to reoccur the following day.

I've never had this happen before and I can't think of anything unusual going on that might account for it. Help, please. Augnablik (talk) 12:45, 4 June 2026 (UTC)

Help Desk:It may be the browser. At the time of a web login, you are asked if you want to stay logged in for up to a year, and this sets a HTTP cookie. This should prevent login requests every time you visit the site. Try different browsers, and check that they are not clearing cookies when you close the browser.--♦IanMacM♦ (talk to me) 13:04, 4 June 2026 (UTC)
Me: I have replied every time that I'm asked that I do want to stay logged in up to a year. That's what seemed particularly odd about this situation.
The browser I'm using is Chrome, but it's the same one I've been using for quite some time when I work in Wikipedia. Although I use other browsers, I'd really prefer to reserve Chrome just for my Wikipedia work for several reasons. Any other possible remedies? Augnablik (talk) 13:29, 4 June 2026 (UTC)
Help Desk: If you try replicating the fault with different devices and browsers, it may be possible to narrow down the fault to a particular device or browser. Then you could try uninstalling and reinstalling the browser that causes the problem.--♦IanMacM♦ (talk to me) 13:52, 4 June 2026 (UTC)
MeThe plot thickens. On the two other browsers I use, DuckDuckGo and Safari, I got mixed results: DuckDuckGo, fine—worked correctly as Chrome used to, with me logged in; Safari, same issue as Chrome recently, with me not logged in.
Now, if I follow step 2 of your advice and uninstall/reinstall Chrome, won’t I lose all my history, bookmarks, settings, and tab groupings? Augnablik (talk) 16:19, 4 June 2026 (UTC)
Help DeskPossibly, but it is often possible to export bookmarks and passwords and import them after reinstalling the app, eg with Chrome here.--♦IanMacM♦ (talk to me) 16:29, 4 June 2026 (UTC)
MeAll right, I’ll give it a try if I can get up enough nerve. But why did this happen in the first place is what I’d like to understand … and is there anything I can do to prevent if from happening again? Augnablik (talk) 04:24, 5 June 2026 (UTC)
Help Desk@Augnablik- Hmm, I would try asking at WP:VPT? They will probably know more about what's going on/can point you on how to make a bug report. Sarsenet•he/they•(talk) 04:54, 5 June 2026 (UTC)

Augnablik (talk) 06:10, 5 June 2026 (UTC)[reply]

@Augnablik check your extensions? It sounds like something is interfering either with the cookies being set or communications to auth.wikimedia.org being interrupted. The user authentication for Wikimedia projects go through this domain. My feel is that the login cookie might be seen as a third party cookie. If you are on en.wikipedia.org, auth.wikimedia.org may be seen as a third party domain due to the different domain names. Also check if you are blocking third party cookies in your browser settings in Chrome. If so, either disable that option, or add auth.wikimedia.org to the exception for the block. You should be able to set a similar exception for Safari (I don't use MacOS enough to figure out where). – robertsky (talk) 13:10, 5 June 2026 (UTC)[reply]
@Robertsky, I'm not sure I have any extensions. It took me a little while to figure out how to check for them in Chrome, but when I did, the Manage Extensions page didn't show any to manage. As for blocking third-party cookies, no cookies were blocked.
I didn't plan to use Safari for my Wikipedia work, no need to do anything there. What do you suggest next? Augnablik (talk) 09:12, 7 June 2026 (UTC)[reply]
In theory, when you log in on en.wikipedia.org and get sent to auth.wikimedia.org, the cookie is set after user interaction (you typing into the auth.wikimedia.org form) which exempts you from third-party cookie blocking (some browsers still reduce the cookie lifetime, but to something more reasonable, like 30 days).
If you go to a different domain, say Wikidata, and it tries to fetch your auth.wikimedia.org cookies, *that* will be categorized as third-party cookie acces (or more precisely, as bounce tracking, since the cookie is accessed via top-level redirects) which might result in the cookie lifetime getting shortened to a day. But AIUI it shouldn't affect the wiki where you manually logged in the last time.
Also, Chrome doesn't do third-party cookie blocking by default (except in Incognito mode). Maybe you enabled it manually? You can check under Settings > Privacy and Security > Third-party cookies. Tgr (WMF) (talk) 20:09, 8 June 2026 (UTC)[reply]
Tgr, I got a little lost trying to understand the first two paragraphs of your message, but AIUI (thanks for teaching me a new piece of computer jargon that will come in handy!), the only action item in your message is the third one. So I tried to check if I'd enabled third-party cookie blocking manually, as you suggested ... but when I go to Settings>Privacy & Security, I just don't see "Third-party cookies." Does it matter that I'm on a Macintosh? Augnablik (talk) 11:38, 10 June 2026 (UTC)[reply]

Section editing through two-layer transclusion

[edit]

At no.wiki, we have run into a problem on our featured article candidates page, no:Wikipedia:Kandidatsider. On this page, there is a template, no:Mal:Forslag (forslag means "suggestion" or "proposal"), which transcludes a candidate page, e.g. no:Wikipedia:Kandidatsider/Raphael Lemkin, and adds some links. But the section edit links next to the headings in the transcluded page don't work on the root page (Wikipedia:Kandidatsider). The links lead to https://no.wikipedia.org/w/index.php?title=Mal:Forslag&action=edit&section=T-1&uselang=en

and with T-2 and T-3 and so on for subsequent sections. The error returned in the original language is this (I added uselang=en to the link just above, so that should show in English):

Finner ikke avsnittet
Fra Wikipedia, den frie encyklopedi
Du prøvde å redigere et avsnitt som ikke eksisterer. Det kan ha blitt flyttet eller slettet mens du så på siden.
Tilbake til Mal:Forslag.

This corresponds to the message returned when clicking a link such as https://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&action=edit&section=999, though it is not a direct translation.

A workaround is to substitute the template Mal:Forslag, but the drawback is more text in the editing window at no:Wikipedia:Kandidatsider.

How can we solve this so that we can just click a section edit link and go? Utfor (talk) 20:22, 5 June 2026 (UTC)[reply]

Your page is being rendered by Parsoid. This is a currently known issue with Parsoid. Izno (talk) 20:36, 5 June 2026 (UTC)[reply]
User:Izno Thank you for your answer. Are there any efforts on solving this? Utfor (talk) 20:45, 5 June 2026 (UTC)[reply]
Judging by phab:T422291 (task about this bug), currently no. stjn 22:49, 6 June 2026 (UTC)[reply]

"Upright" parameter in image embedding broken?

[edit]

I was editing an image-heavy page and as part of my edit, wanted to shrink the beside-text images, but both the old "upright" parameter (already present, in fact) and the preferred "upright=" parameter failed to change their displayed size. I went to Help:Pictures and it has the same issue: the 3 versions of File:Amun.svg intended to illustrate the use of the resizing parameter are all displaying at the same default size. Has somebody broken something or is there a temporary problem with the Mediawiki code that's being worked on as we speak? Yngvadottir (talk) 22:53, 5 June 2026 (UTC)[reply]

The three Amun.svg images are different sizes for me. The first one (thumb only) is the largest, the next one (with thumb and upright, equivalent to upright=0.75) is smaller, and the third one (with upright=0.56) is smaller still. When responding, please read the edit notice that appears at the top of this page in edit mode. Provide us with the information requested. Also try the same edit in a different browser, while logged out. – Jonesey95 (talk) 01:15, 6 June 2026 (UTC)[reply]
I hadn't seen that, sorry. I'm using Win 7, and I normally edit using Firefox, which just updated, in Monobook. But the 3 Amun images at Help:Pictures are also appearing for me at the identical size in Chrome, where I'm not logged in and therefore using the nasty default neo-Vector (had to get to the page via the browser address bar because I forgot where search is). The edit I was referring to was this one; I was trying to reduce the size of files such as File:Health and efficiency 1925 03 cover.png, but they're still hogging the right side of the page. (And now I remember it's a search so it's the magnifying glass, I checked that page logged out in Chrome too—same, overly large images.) Yngvadottir (talk) 04:33, 6 June 2026 (UTC)[reply]
In Firefox, Alt-H brings up the Help menu. On there, About Firefox reveals the version number. Mine is 151.0.3 but I don't think that works on older operating systems. I read that the 140.11.0 ESR version works with Windows 7 but haven't tested it. Certes (talk) 07:57, 6 June 2026 (UTC)[reply]
Firefox 115 (currently 115.36.0esr, with minor updates about every 2 weeks) is the last version that works on Windows 7. [1]. Alt-H, About still works - I'm using that version (on Win 7) as I write this. Mitch Ames (talk) 08:26, 6 June 2026 (UTC)[reply]
Alt+HA is a standard Windows key sequence to get the "About" box and hence version number for whatever application currently has the focus. It's worked for everything that I've tried it in over the last twenty years or more - I've just verified that it works in Windows for Playgroups 3.11 (the oldest for which I have an installed working copy [somewhere I have install disks for MS-DOS 3 and Windows 2, but I'm not in the mood to set up a test partition just to verify a key sequence]). It should continue to work for the foreseeable future. What I don't know is how to get the Safari version number in an iPad Air 2. --Redrose64 🌹 (talk) 09:41, 6 June 2026 (UTC)[reply]
In that edit, Yngvadottir changed "upright" to "upright=.75", which should yield no change in the image size, by design. This is explained at Help:Pictures: The exact width is computed by starting with the default thumbnail width, multiplying it by 0.75, and rounding to the nearest multiple of 10. The upright and upright=.75 images are correctly displaying at about 75% of my thumbnail size preference of "Regular" (Regular is 250 pixels), about 190 pixels wide.
I can't explain the three Amun images displaying at the same size for Yngvadottir. – Jonesey95 (talk) 12:14, 6 June 2026 (UTC)[reply]
I'm aware that .75 is the value for the formerly used bare "upright"; I changed the parameter from the bare "upright" to the preferred "upright=.75" thinking that "upright" without a specified percentage of default width no longer worked. When I saw in preview that the images on the right still displayed standard-sized, I inserted a clear line below one that was pushing against a gallery, and otherwise left that aspect of my edit for when the "upright" parameter started working again. I've just tried reducing only File:Health and efficiency 1925 03 cover.png, the first in the series, to .6; in preview, it still shows as the identical width as the image below it. So as indicated by what I see on the Help page, it's not my eyes, it's something in my computer setup. Possibly the software no longer fully supports Win 7??? (Mitch Ames, Redrose64, thanks, can confirm, Firefox 115.36.0esr.) Yngvadottir (talk) 20:39, 6 June 2026 (UTC)[reply]
FWIW, I'm seeing this also, Pale Moon 34.3.0 on Windows 10 (in, yes, a private browsing window, so it's not the fault of either Cologne Blue nor my very badly broken user scripts). Inspecting the second Amun - the one in the Help:Pictures#Upright images section - shows me the rules .mw-parser-output .mw-default-size img.mw-file-upright { height: auto; width: calc(250px * var(--mw-file-upright,1)); width: calc(round(250px * var(--mw-file-upright,1),10px)); } with the first two struck through; disabling the second width rule (with rounding) enables the first width, and this properly resizes both this version of the image and the third one in Help:Pictures#Shrinking upright images further. —Cryptic 00:07, 7 June 2026 (UTC)[reply]
That's a good lead. Checking https://caniuse.com/wf-round-mod-rem, I see that round() isn't supported in Firefox 115. Yngvadottir's test with Chrome was likely using 109 (the latest compatible with Windows 7), which also does not support round(). Apparently the developers who tried to fix phab:T424596 thought that CSS would fall back to the first width property when it couldn't calculate the value in the second due to lacking round(), but I guess they didn't actually test it in failing browsers. It turns out that the use of var() in there causes late evaluation, resulting in it being treated as width: unset, same as how something simpler like width: 50%; width: var( --bogus ); doesn't fall back. The width: unset overrides even the width="140" in the HTML, so it winds up falling back to the intrinsic size of the image, which since other recent changes is one of a few large steps. Anomie 01:18, 7 June 2026 (UTC)[reply]
The mention of the round() function has enabled me to connect this with Template talk:Infobox station#Image sizes. On Tuesday (when I next have access to this machine with an older Firefox) I shall check the issue above. --Redrose64 🌹 (talk) 11:25, 7 June 2026 (UTC)[reply]
Aha! So there was indeed a known issue with Win 7 (and a fix that hasn't worked). Redrose64, can confirm: I see a humongous infobox at Cardiff Bay railway station. Yngvadottir (talk) 21:31, 7 June 2026 (UTC)[reply]
The machine where the issue shows is Microsoft Windows 7 Home Premium version 6.1.7601 SP1 build 7601. Browser is Firefox 115.36.0esr, and I believe that's the most recent available for Win 7. Using Sunderland station for my test, and the browser's "Instect" feature, the problem rule appears to be:
.mw-parser-output .mw-default-size img.mw-file-upright {
  height: auto;
  width: calc(250px * var(--mw-file-upright,1));
  width: calc(round(250px * var(--mw-file-upright,1),10px));
}
With that rule in place the image is 480px wide. Disabling the third declaration reduces it to 337.5px; disabling both second and third makes the image 340px wide. It seems to go against CSS Syntax and basic data types section 4.3.8 Unsupported Values. --Redrose64 🌹 (talk) 11:34, 9 June 2026 (UTC)[reply]
It's following https://www.w3.org/TR/css-variables-1/#invalid-variables. See in particular example 15. Anomie 16:24, 9 June 2026 (UTC)[reply]
My reading of example 15 is that both the width: declarations should be ignored, meaning that it should pick up the width="340" attribute from the <img /> tag. So where is the 480px coming from? --Redrose64 🌹 (talk) 21:39, 9 June 2026 (UTC)[reply]
It's ignoring both width: declarations and the width="340" attribute. The 480px comes from the intrinsic size of the image, now that WMF changed things to serve only a limited set of sizes and rely on the browser to scale them. You must be on a high-DPI display, so you're getting the 960px version at 2× which results in a 480px display. Anomie 00:15, 10 June 2026 (UTC)[reply]

Hi, I have created en:wikisource:Module:Soroban, but I am having difficulty uploading it to Wikipedia and creating the documentation. If anyone can help with this, I would be very grateful.

It looks better than this Soroban

Representation of digits 0 - 9 on the soroban
0 1 2 3 4 5 6 7 8 9

Also, I am working on wikisource:jp:Index:WUL-ni02 00069 算盤早伝授.pdf so this module would make the work easier.

~2026-31538-15 (talk) 04:36, 6 June 2026 (UTC)[reply]

done – robertsky (talk) 17:26, 6 June 2026 (UTC)[reply]
Thanks a lot. ~2026-31538-15 (talk) 01:13, 8 June 2026 (UTC)[reply]

The Third Man at the TCM Movie Database (archived) TCMDb title|92904|The Third Man

Fix is:

https://www.tcm.com/watchtcm/titles/92904

https://web.archive.org/web/20180916100223/http://www.tcm.com/tcmdb/title/92904/The-Third-Man/articles.html

Xo4v (talk) 08:18, 6 June 2026 (UTC)[reply]

Xo4v, did you mean to post this here on the village pump? It looks like a comment that was meant for Template talk:TCMDb title#TCMDb links are no longer active. —⁠andrybak (talk) 23:29, 6 June 2026 (UTC)[reply]

need some help with a conditional template

[edit]

Hello, I've been developing an improvement to Template:infobox legislature that will mean you can just pass in a list of parties and seats and it will take care of the seat diagram and formatting a list nicely with party colours etc: I have all the bits, but I could really do with some help tying it all together, which requires altering a non-lua conditional template, which is unfortunately a bit out of my wheelhouse. I've been working on it at User:Morwen/legislature so please see User talk:Morwen/legislature for more specific details, and also see User:Morwen/dudley for my testcase. Morwen (talk) 19:49, 6 June 2026 (UTC)[reply]

Strange edits from a "Renamed user" account

[edit]

Hello, I've noticed some strange edits on Louis Antoine de Saint-Just from an account that is prefixed "Renamed user" (which, as I understand, means someone renamed themselves & the account is no longer in use?)

For the last two years, this account has had bursts of edits on the page where they repeatedly change one character (heading wiki markup) & then immediately revert the change. Here's their edit history on the article: [2] They make the same 12 edits in a 3 minute time frame (one time, 14 edits) during these edit bursts. The behavior seems scripted.

Do you all think this is worthy of further investigation? And if so, what are the next steps? I'm unfamiliar with these types of situations. I thought about posting on the their talk page... but isn't a "Renamed user" account meant to be inactive? Chao Garden 🌱 ~ say hello 17:01, 7 June 2026 (UTC)[reply]

That's odd. It's the sort of behaviour we see from someone eager to become autoconfirmed or EC (not always for benevolent reasons) but this account already has plenty of edits. Could it be compromised? Certes (talk) 17:12, 7 June 2026 (UTC)[reply]
They won't become EC (at least not automatically), since the group was manually removed from this account. —Cryptic 17:44, 7 June 2026 (UTC)[reply]
I'd start by asking them what they are doing, on their talk page. If they don't give a satisfactory explanation, take it to WP:ANI, as it is clearly disruptive to anyone who has the Saint-Just article on their watchlist. AndyTheGrump (talk) 17:26, 7 June 2026 (UTC)[reply]
WP:Courtesy vanishing is the guideline here. This account should have been globally locked when it was renamed, absent some unusual extenuating circumstance in the request (which I'm unable to view). —Cryptic 17:42, 7 June 2026 (UTC)[reply]
Oh interesting. I posted on their talk page a moment ago, asking them to explain the behavior & also to please stop. But given that this a "vanished" account, do you think I should post about this elsewhere as well? Or proceed with AndyTheGrump's advice above (i.e., wait for a response and then post in WP:ANI if the answer is unsatisfactory)? Chao Garden 🌱 ~ say hello 17:49, 7 June 2026 (UTC)[reply]
User appears to have been renamed three times:
  1. 16:50, 16 July 2013 (UTC) by Xeno (talk · contribs)
  2. 09:50, 1 May 2019 (UTC) by Litlok (talk · contribs)
  3. 12:19, 14 December 2022 (UTC) by Cabayi (talk · contribs)
so they were no strangers to the rename process. Perhaps the last one was a normal rename, and not a "vanish" rename? --Redrose64 🌹 (talk) 18:28, 7 June 2026 (UTC)[reply]
The modern concept of vanishing, which automatically globally locks an account and scrambles its password and email, wasn't invented until about a year ago, long after this user vanished. * Pppery * in solidarity 18:35, 7 June 2026 (UTC)[reply]
This is the page about Vanishing at the time of the last rename. Note "When you request a courtesy vanishing, it is understood that you will not be returning ... If you make a request to vanish, and then start over with a new account, and are then discovered, the vanishing procedure may be reversed, and your old and new accounts may be linked." This user has returned so should be unvanished. DuncanHill (talk) 18:47, 7 June 2026 (UTC)[reply]
the request was made in 2022, and was a manual rename request. The automatic account lock on vanish request came in only about two years ago. Either the account be locked or renamed back to last username might be in order. – robertsky (talk) 02:01, 8 June 2026 (UTC)[reply]
@Cryptic There are no comments or notes attached to that request. It is a generic request to vanish. --Ahecht (TALK
PAGE
)
19:05, 8 June 2026 (UTC)[reply]
I left a warning and will indef them if they continue. Please let me know if I miss a problem. Johnuniq (talk) 01:59, 8 June 2026 (UTC)[reply]
[edit]

The gadget that says "Redirect image links to Commons for files hosted there" seems to have stopped working for me. This probably happened months ago. Is it me, or is it broken for everyone? WhatamIdoing (talk) 02:26, 8 June 2026 (UTC)[reply]

Me too. Mediaviewer is back and in charge. CMD (talk) 02:31, 8 June 2026 (UTC)[reply]
For me, it's intermittent. Sometimes I get straight to commons, sometimes I get the en.wp mirror. But whichever happens, I don't get mediaviewer. --Redrose64 🌹 (talk) 14:02, 8 June 2026 (UTC)[reply]
I have MediaViewer disabled here, so I always get the enwiki mirror page. WhatamIdoing (talk) 18:57, 8 June 2026 (UTC)[reply]
I did need to update the gadget for Parsoid output in Russian Wikipedia, so if you have Parsoid enabled, that could cause the gadget to no longer work. Checking Parsoid and non-Parsoid versions of the pages, it does fail to change any links on Parsoid version, but I wasn’t sure if this would happen on Latin script wikis (apparently it does) since the problem in Russian Wikipedia was that mw.util.getUrl returns /wiki/%D0%A4%D0%B0%D0%B9%D0%BB: but Parsoid renders URLs as /wiki/Файл:. stjn 20:47, 8 June 2026 (UTC)[reply]
That's probably the explanation. This probably needs to be done at all the wikis that have this gadget. Does anyone know how to find all of the copies? WhatamIdoing (talk) 22:50, 8 June 2026 (UTC)[reply]
@WhatamIdoing: Here you go. NguoiDungKhongDinhDanh 23:00, 8 June 2026 (UTC)[reply]
Thanks. That's 102 results. Well, congratulations to @Krinkle for writing another popular gadget.
AIUI these will have to be updated by IAs. That means posting a request at m:Steward requests/Miscellaneous. I've got the diff from @Stjn that shows the changes that need to be made, plus the list from @NguoiDungKhongDinhDanh of all the gadgets that need to be fixed. Is there anything else I need to know? WhatamIdoing (talk) 23:21, 8 June 2026 (UTC)[reply]
I should note that my diff does the job but it is pretty hacky (and is only supposed to work for users with Parsoid, which is eventually going to be everyone), so maybe someone should write and test a version that’s less so. stjn 23:27, 8 June 2026 (UTC)[reply]
@Stjn @WhatamIdoing: Fixed in edit.
I believe this was not related to Parsoid. The canonical version at mw:Snippets/Direct_imagelinks_to_Commons works fine for me on a random enwiki article with useparsoid=1, and afaik this did not have any Parsoid-specific changes applied. The local version at MediaWiki:Gadget-imagelinks.js seems last updated ten years ago. When I try it on a random enwiki article, I see it fail on absolute URLs (e.g. <a href="//en.wikipedia.org/wiki/File: instead of <a href="/wiki/File:). This was fixed back in October 2025 by NguoiDungKhongDinhDanh on mediawiki.org with this edit. I've now synced the gadget with the mediawiki.org version to fix this and anything else we fixed since then. Krinkle (talk) 00:34, 9 June 2026 (UTC)[reply]

Punctuation on separate lines

[edit]

When I look at Soviet Civil Administration in mobile web mode, the native names at the top of the infobox look quite weird.

They are supposed to look more or less like this:

Soviet Civil Administration
Korean: 소비에트 민정청
Russian: Советская зона оккупации Кореи, romanized: Sovetskaya zona okkupatsii Korei

But I actually see them like this:

Soviet Civil Administration
Korean
:

소비에트 민정청
Russian
:
Советская зона оккупации Кореи
,
romanized: Sovetskaya zona okkupatsii Korei

Most importantly, the colons (:) and the comma (,) are supposed to be together with the preceding word, but they appear as if they are on a separate line. Also, it looks like there are two line breaks before the Korean text, but I'd expect at most one.

This is possibly something with the CSS that comes with the {{langx}} or {{Korean}} templates, or perhaps something with {{Infobox government}} template, but I cannot understand what is it exactly. Amir E. Aharoni (talk) 10:02, 8 June 2026 (UTC)[reply]

I have filed phab:T428472 as a result. Izno (talk) 16:08, 8 June 2026 (UTC)[reply]
Thanks! Amir E. Aharoni (talk) 16:16, 8 June 2026 (UTC)[reply]
@Amire80: The infobox was using <br> pseudolists which I've converted to use {{ubl}} per MOS:LIST. Could you check to see if this makes a difference? It seems to have fixed the issue on my end when toggling between mobile view and desktop view. – Scyrme (talk/solidarity) 16:26, 8 June 2026 (UTC)[reply]
Yes, that is one workaround. Izno (talk) 17:01, 8 June 2026 (UTC)[reply]
Yes, it looks correct now. Thank you. But I'd say that the issue is still a bug that should be fixed. A <br> in a different place shouldn't cause punctuation to break like this, even if <br> is not used optimally. Amir E. Aharoni (talk) 17:04, 8 June 2026 (UTC)[reply]

insource: searching; AWB

[edit]
  1. If I search for insource:BHL] or insource:"BHL]", I get results including just BHL. How may I specify that the closing square bracket is required?
  2. I wish to search for strings like [http://www.biodiversitylibrary.org/item/80026#6 BHL], regardless of what is between the /item/ and BHL] stings. What wildcard or regex should I use?

Also, what should I use in AWB as a search and replace string for replacing the latter links with (for example) {{BHL|item/80026#6}}? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 8 June 2026 (UTC)[reply]

  1. Try this
  2. In search&replace use the regex search pattern \[https?:\/\/www\.biodiversitylibrary\.org\/(item\/[^ ]+) BHL\], replace with {{BHL|$1}}
Ponor (talk) 10:51, 8 June 2026 (UTC)[reply]
See more at Help:Searching#insource: and note the part about including another parameter. That's why Ponor included a normal insource:BHL which reduces the search to 8,414 pages before applying the expensive regex on them. PrimeHunter (talk) 11:05, 8 June 2026 (UTC)[reply]
@Pigsonthewing I remembered that people get creative with these links, so you'll find a few more cases with more than one space inserted after the url: here Ponor (talk) 15:16, 8 June 2026 (UTC)[reply]
Only one on Wikispecies, now resolved :) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 8 June 2026 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. Thank you, all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 8 June 2026 (UTC)[reply]

Emboldening in caption

[edit]

I noticed a circular wikilink was placed in caption in this 2025 change which has defaulted to bold face, still extant. Is this a known phenomenon, intended to be an alert? Not encountered before (13+ years ); rather than just de-linking to de-Embolden, I'm looking at it as a learning opportunity first. Thanks.-- ~2026-21006-91 (talk) 15:08, 8 June 2026 (UTC)[reply]

@~2026-21006-91: Yes, it is a feature. See WP:SELFLINK. NguoiDungKhongDinhDanh 15:19, 8 June 2026 (UTC)[reply]
It's a feature that a selflink becomes bold text but I see no reason to activate the feature by making a selflink in that edit. PrimeHunter (talk) 15:27, 8 June 2026 (UTC)[reply]
Many thanks; inadvertent use of brackets, IMO, rather than a desired effect. I have a small amount of expansion to add to the article.--~2026-21006-91 (talk) 19:03, 8 June 2026 (UTC)[reply]

Multiple image template is still broken in preview

[edit]

I brought this up a couple of weeks ago, and it was discussed in phab:T424687. Looking at the phab ticket it says this should be corrected, but previews are still broken. The {{multiple image}} template isn't the only one effected, for instance when previewing the section Administrative divisions of Krasnoyarsk Krai#Administrative and municipal divisions he map at the top aligns left even though it should align right. -- LCU ActivelyDisinterested «@» °∆t° 16:32, 8 June 2026 (UTC)[reply]

Looks like this is going to take some time. The issues have been reported, but I don't know if anyone is working on fixing them: phab:T427699 & phab:T427709. Ponor (talk) 16:54, 8 June 2026 (UTC)[reply]
Thanks Ponor. It's an annoying bug, especially when working on image placement, as it's impossible to know exactly what the result will be. -- LCU ActivelyDisinterested «@» °∆t° 16:58, 8 June 2026 (UTC)[reply]
Subscribe or leave a comment at phabricator. Two weeks from now no one will remember these tickets. Ponor (talk) 17:06, 8 June 2026 (UTC)[reply]

Tech News: 2026-24

[edit]

MediaWiki message delivery 21:28, 8 June 2026 (UTC)[reply]

Re-enroll

[edit]

Hi
At login this morning there was a notice that I should re-enroll. Meaning I should create a new ID and password? Something else? Thanks, ... PeterEasthope (talk) 12:30, 9 June 2026 (UTC)[reply]

@PeterEasthope: I don't recognise the term "re-enroll". It certainly isn't asking you to create a new Wikipedia account – your old one is working fine. If it's in a banner at the top of the screen then one of Wikipedia's projects is encouraging you to do something ­– edit on a particular topic, provide a photo or even attend a physical get-together – but all of that is strictly optional and you can just click the X on the banner to dismiss it. Otherwise, something outside Wikipedia may be producing the message. If you're using a device provided by your work or college, they may be asking you to enroll in some local scheme which has nothing to do with Wikipedia. Certes (talk) 12:42, 9 June 2026 (UTC)[reply]
@PeterEasthope: Do you have two-factor authentication? It sounds like MediaWiki:Notification-header-oathauth-recoverycodes-count. translatewiki:MediaWiki:Notification-header-oathauth-recoverycodes-count/qqq says: "Notification header for when the user is getting low on the number of recovery tokens left on their account." See meta:Help:Two-factor authentication#Manage your recovery codes and try Special:AccountSecurity. PrimeHunter (talk) 12:45, 9 June 2026 (UTC)[reply]
Good answer; thank you. That sounds more likely than my explanation. I forgot about 2FA. Certes (talk) 12:50, 9 June 2026 (UTC)[reply]
Yes, 2FA is working on my account. It was recommended or imposed weeks ago. Can a recovery code be used only once? I don't recall seeing that mentioned. 2FA is a good idea but usage should be evident. Thx, ... PeterEasthope (talk) 13:01, 9 June 2026 (UTC)[reply]
@PeterEasthope: meta:Help:Two-factor authentication#Manage your recovery codes says: "Each recovery code is single use: after you use it once, it is no longer valid." That's part of the security. Somebody might gain access to your use of a recovery code. PrimeHunter (talk) 13:13, 9 June 2026 (UTC)[reply]
Now that you mention it, single use makes perfect sense. So my new workflow: use the code at top of my list and delete after use. Workflow could be suggested when 2FA is activated. Still haven't found how a fresh list of codes is obtained. Thanks, ... PeterEasthope (talk) 13:37, 9 June 2026 (UTC)[reply]
@PeterEasthope: Doesn't Special:AccountSecurity work for that? PrimeHunter (talk) 13:41, 9 June 2026 (UTC)[reply]
@PeterEasthope Per meta:Help:Two-factor authentication#Manage your recovery codes: If you use a code, go to Special:AccountSecurity and generate a new set of codes, so you don't run out. --Ahecht (TALK
PAGE
)
13:43, 9 June 2026 (UTC)[reply]
OK, now I have a fresh password and fresh list of recovery codes.
For interest, I have Open Authenticator on a phone and used it today. It involves a third party, Apple in this case. An appeal of recovery codes is avoidance of a third party. A misconception?
Incidental observation: in the security page, the passphrase button is greyed out, inactive. What is needed to create a passphrase? Thx, ... PeterEasthope (talk) 14:26, 9 June 2026 (UTC)[reply]
@PeterEasthope Open Authenticator is NOT by Apple. It is an open source project by another 3rd party (or an even older project, that I'm not sure it being updated any longer) distributed via Apple's App Store (I can see two apps with this name in my Appstore).
There are MANY authenticator apps out there that support TOTP (which is the type of 2 factor authentication that is used). You are advised to choose wisely. You can choose one that saves everything fully locally. Having everything locally comes with the downside that you should really understand what you are doing in terms of backups etc. It is better to go with one that saves encrypted backups in iCloud or Google/Samsung storage. Especially if you have activated Passkeys, which normal users should probably simply do via Apple's Password application (the default). Basically anything that is popular and used by lots of people is better than choosing something esoteric. —TheDJ (talkcontribs) 10:19, 10 June 2026 (UTC)[reply]
"Open Authenticator is NOT by Apple."
Well, yah, I get that. It's an app running on my Apple phone. I referred to Apple as third party. Thx, ... PeterEasthope (talk) 15:01, 10 June 2026 (UTC)[reply]
I didn't know the message either but searched an offline copy of Allmessages from the API (9 MB). I once added this link to Help:MediaWiki namespace#Finding system messages (WP:QQX). PrimeHunter (talk) 13:08, 9 June 2026 (UTC)[reply]

Weird issue with both visual and source editors

[edit]

Hi!

I've been trying to edit my global userpage, but a few characters after I insert a character using my Linux compose key, VEdit and Source edit keep inserting random Unicode characters. I'm on Arch Linux, Librewolf, if that helps.

Example: here, go to the Español section. --ABx11 (she/they | formerly TheAuroraBorealis | In solidarity) 18:07, 9 June 2026 (UTC)[reply]

@ABx11 Does the behavior occur if you start up the browser without extensions ? Does it reproduce in a different browser ? —TheDJ (talkcontribs) 10:04, 10 June 2026 (UTC)[reply]
[edit]

We are trying to nicely display three {{maplink}} maps at Poecilia velifera#Range. The maps uses marker coordinates from Commons Data pages, showing the locations of fish populations.

The first attempt (oldid) / (diff) used {{switcher}} but the alignment of elements is weird (due to using class=infobox to make it thumbnaily).

The second attempt (oldid) / (diff) uses raw div classes borrowed from Module:Mapframe, but as the switching text is long and not wrapping and forcing huge whitespace.

Perhaps switch functionality for this use-case can be built into {{maplink}} (if not already), or {{switcher}} can be improved.

Note: Show preview does not work with the switch radio buttons on the wikitext editor, so experimenting requires saves. Commander Keane (talk) 01:09, 10 June 2026 (UTC)[reply]

Mapframes have JS functionality and extension specific parser behavior attached to them. Wrapping them in anything is probably gonna be rather complex. —TheDJ (talkcontribs) 10:03, 10 June 2026 (UTC)[reply]
I removed the space, do check it is acceptable cheers. Regs, The Equalizer (talk) 23:44, 10 June 2026 (UTC)[reply]
Thanks, the spacing is fixed and looks good to me. I was hoping to wrap the whole thing in box, like regular images, so that radio buttons are visually separated from the article text. Commander Keane (talk) 00:48, 11 June 2026 (UTC)[reply]
I put a box around it all, see if that's what you are looking for, regs, The Equalizer (talk) 06:14, 12 June 2026 (UTC)[reply]
Thanks. Commander Keane (talk) 06:32, 12 June 2026 (UTC)[reply]

Blank line removal

[edit]

User:LateNightCoffee makes many single-digit edits every day like this one, removing a blank line between every pair of CfD discussions. If it is better to have that line removed (which I do not know) couldn't this be automated? Marcocapelle (talk) 03:02, 10 June 2026 (UTC)[reply]

Two blank lines cause extra unwanted whitespace so it's correct to remove one of them. The second line should be avoided in the first place. Based on [7] it's made with User:Qwerfjkl/scripts/CFDlister.js by Qwerfjkl. PrimeHunter (talk) 09:35, 10 June 2026 (UTC)[reply]
Special:Diff/1358709880 should fix that. — Qwerfjkltalk 12:39, 10 June 2026 (UTC)[reply]

Old deletion sorting page from 2018 failing to auto-archive

[edit]

Wikipedia:WikiProject Deletion sorting/Bhutan has 4 un-archived closed discussions from 2018. GabeIglesia and I recently rediscovered it and added to the delsort lists, but it has not been automatically archived.

I also opened an AN at Wikipedia:Administrators'_noticeboard#Wikipedia:Articles_for_deletion/Mornflake regarding an AfD that was courtesy blanked, causing problems with archival, but no admins or oversighters are responding. –LaundryPizza03 (d) 16:36, 10 June 2026 (UTC)[reply]

You should report the issue to the bot operator. Izno (talk) 17:48, 10 June 2026 (UTC)[reply]
This usually means that there is a formatting error. Not necessarily in one of the four threads, it could be anywhere on the page. --Redrose64 🌹 (talk) 12:53, 11 June 2026 (UTC)[reply]
Compared to a couple of delsort pages for other countries, and did this: Special:Diff/1358881958. The categorization wikitext seems to be inconsequential, because Wikipedia:WikiProject Deletion sorting/Germany (Special:Diff/1358881958/1358850067) also has it at the bottom and archiving works there. Another possibility (from just comparing with other similar pages) could have been absence or presence of section === Others ===, but Wikipedia:WikiProject Deletion sorting/Nepal (Special:Diff/1358881958/1358731129) doesn't have it and archiving works there. —⁠andrybak (talk) 16:00, 11 June 2026 (UTC)[reply]
I discovered that the comment beneath the header was misspelled; it needs to be an exact phrase. –LaundryPizza03 (d) 20:26, 11 June 2026 (UTC)[reply]
The operator of the bot thought that it had to do with the old AfD header format, so I archived it manually. –LaundryPizza03 (d) 20:27, 11 June 2026 (UTC)[reply]
More specifically, the bot looks in the wikitext for the <div class="...xfd-closed..."> produced by templates like {{subst:afd top}} to know if the discussion is closed. The AFDs that were listed there had been edited to use an unsubsted {{afd top/old}} instead, so no <div> was present. It's not worth updating the bot to account for that, since normally any old AFD would have long since been archived before the close-header was broken. Anomie 22:36, 11 June 2026 (UTC)[reply]

Question regarding technical burden of template usage

[edit]

 You are invited to join the discussion at Wikipedia talk:AutoWikiBrowser § Usage of JWB/AWB for reducing phonetics links with templates. This regards usage of the {{lcons}} and {{lvow}} templates. The specific question relevant to VPT is 2. Does using the templates over wikilinks result in any performance impact (technical burden) on page rendering? ~ oklopfer (💬) 17:22, 10 June 2026 (UTC)[reply]

[edit]

My sandbox, PeterEasthope/sandbox, shows a link to a Youtube page; the link being viable. Below that are two instances of a template. The first shows characters A, B and C in the three boxes. The second template instance has the Youtube link in the third box where it fails to be effective. Can the template definition be fixed? Is there a better way to include the link?
Thanks, ... PeterEasthope (talk) 18:00, 10 June 2026 (UTC)[reply]

The URL has an equals sign in it. You cannot use positional parameters as such because |some text= is interpreted as a parameter value. Izno (talk) 18:46, 10 June 2026 (UTC)[reply]
See more at the second bullet at Help:Template#Hints and workarounds. PrimeHunter (talk) 19:00, 10 June 2026 (UTC)[reply]
A puzzling difficulty with simple solution. Thanks! ... PeterEasthope (talk) 19:35, 10 June 2026 (UTC)[reply]
It's a common problem and usually caused by url's like your example where the code was the innocent looking | [https://www.youtube.com/watch?v=Do2O1yFrnos Oberon Tutorials at YouTube]. Nobody would deliberately choose a parameter name like [https://www.youtube.com/watch?v. It's an allowed name but maybe MediaWiki should say that if an apparent parameter name in a template call contains http(s):// (or other strings in mw:Manual:$wgUrlProtocols to make it general) then it should be treated as an unnamed parameter. PrimeHunter (talk) 22:28, 10 June 2026 (UTC)[reply]
Or just disallow / in parameter names. — Qwerfjkltalk 16:58, 11 June 2026 (UTC)[reply]
That would certainly be simpler but maybe too drastic. I don't recall seeing parameter names with a slash but I could imagine it, e.g. something like km/h = 180 in a car template or b/w = yes in a film template. PrimeHunter (talk) 18:54, 11 June 2026 (UTC)[reply]
PrimeHunter, as a general rule I think parameter names should be kept to just [a-z_], so those would become km_h and b_w. — Qwerfjkltalk 09:43, 12 June 2026 (UTC)[reply]
I'm not suggesting to use those names but I'm thinking of a MediaWiki change which would apply to numerous wikis. https://www.fandom.com/explore alone says 385,000+ (most are tiny). We don't know how many templates would break if slash was disallowed everywhere. Disallowed parameter names could also be a configuration setting which defaults to something like mw:Manual:$wgUrlProtocols. Then the English Wikipedia could choose to disallow all slashes. PrimeHunter (talk) 10:05, 12 June 2026 (UTC)[reply]
User:John of Reading/Sandbox lists 91 templates that accept a parameter name that includes a slash. -- John of Reading (talk) 10:32, 12 June 2026 (UTC)[reply]
Thanks. This indicates to me that disallowing slash in general is going too far. It could have been OK if MediaWiki had done it from the beginning but it would break too much to suddenly start now. PrimeHunter (talk) 13:09, 12 June 2026 (UTC)[reply]
OTOH, adding special cases makes the code more complex, and may wind up confusing if someone tries to use parameter names like matrix:x and matrix:y for a math template, or tel:home and tel:work on a wiki where a template with contact information might be appropriate. Anomie 22:57, 11 June 2026 (UTC)[reply]

The multiref2 refs at the 0 article are giving me grief

[edit]

I was correcting various cites at this article but 9 Harv warnings remain because of multiref2 issues:

  • Ref #1: 2 Harv warnings
  • Ref #2: 2 Harv warnings
  • Ref #63: 2 Harv warnings
  • Ref #70: 3 Harv warnings

I am stumped as to how to get all those multiref2 cites to work correctly. Article still in Category:Harv and Sfn no-target errors because of the 9 remaining Harv warning-issues in the multiref2 cites: #1, #2, #63, & #70. I also posted about this at Wikipedia talk:WikiProject Mathematics. If someone here could fix these refs, that would be great because I just can't see what's wrong. Thanks. - Shearonink (talk) 17:19, 11 June 2026 (UTC)[reply]

Article still in Category:Harv and Sfn no-target errors... Umm, no it's not. Harv warning: ... messages created by script do not add articles to the category.
If you wish to suppress the Harv warning: ... messages, adding |ref=none to the offending citation templates should be all that needs doing.
Trappist the monk (talk) 17:52, 11 June 2026 (UTC)[reply]
Ok, my mistake re:the warnings. But those refs aren't really ref=nones, they are being used. So why am I getting these invalid Harv warnings? Thanks - Shearonink (talk) 18:30, 11 June 2026 (UTC)[reply]
Sure, they are used, but there are no short-form templates ({{sfn}}, etc) linking to them. When there are no short-form templates linking to a long-form template, the script emits that message. The script neither knows nor cares about {{multiref2}}. The primary purpose of that warning message is to notify concerned editors that the short-to-long link is missing. Most often, that means that the long-form template is in the wrong section and should be in §Further reading or should be removed altogether.
|ref=none tells Module:Citation/CS1 to suppress the creation of an anchor ID (CITEREFHarper2011, from ref 1 (permalink) for example). When a long-form template does not have an anchor ID, the script does not look for a short-form link to that long-form template so does not emit the Harv warning: ... message. Granted, |ref= is probably not the best parameter name, but it has been with us for as long as cs1|2 templates have been with us so replacing it with a better-named parameter would be a battle up a hill I don't care to die on.
Trappist the monk (talk) 18:52, 11 June 2026 (UTC)[reply]

Passing raw code to Template:textdiff

[edit]

Is there a way to use {{textdiff}} while passing in a block of template code, such as <syntaxhighlight>...</syntaxhighlight> code? Cannot figure out how to make that work... Only work around is to manually escape everything with {{!}} and {{(}}, etc. Zackmann (Talk to me/What I been doing) 19:07, 11 June 2026 (UTC)[reply]

Looks like it works to wrap the parameter with <nowiki>...</nowiki>, e.g. {{textdiff|1=<nowiki>{{foo | bar }}</nowiki>|2=<nowiki>{{foo | baz }}</nowiki>}}
{{foo | bar }}
+
{{foo | baz }}
Anomie 23:08, 11 June 2026 (UTC)[reply]
Facepalm Facepalm Wowwww. I'm embarrassed. Thanks! Zackmann (Talk to me/What I been doing) 23:32, 11 June 2026 (UTC)[reply]

Watchlist not filtering out category changes?

[edit]

Help:Watchlist said to post about technical problems here, so... As far as I can tell, I have set my watchlist to exclude category changes: in my preferences "Hide categorization of pages" is checked, and in the "Filters" section on my watchlist "Category changes" is unchecked. And yet, I frequently notice that a helpful gnome's category work absolutely drowns my watchlist in things I don't want to be watching. Is something not working as intended? Can the filter not exclude HotCat-based category changes? Is there anything else I can do to filter these out? Thank you! ~ le 🌸 valyn (talk) 22:36, 11 June 2026 (UTC)[reply]

Are you watching the category page, or the categorized page? —Cryptic 22:53, 11 June 2026 (UTC)[reply]
The categorized page, such as Hubert de Sevrac. Have I simply misunderstood what these filters were for? ~ le 🌸 valyn (talk) 23:08, 11 June 2026 (UTC)[reply]
Yes. If you uncheck that option in your preferences, and you add a category to your watchlist, you'll see it on your watchlist if any page is added to or removed from that category. --rchard2scout (talk) 23:21, 11 June 2026 (UTC)[reply]
Gotcha, makes sense. Thanks for the explanations, though now I'm sad that the feature I made up isn't real! ~ le 🌸 valyn (talk) 00:34, 12 June 2026 (UTC)[reply]

Question

[edit]

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)[reply]