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

Module:Params

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)

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)

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)

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)

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)

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)

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)

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)

Getting the wrong notifications

Hi again, and this is probably the third and last bug report of May 2026 I have done so far. So, I am a recent changes patroller. And I revert vandalism. And I enjoy my alerts and notifications. However, just a few minutes ago, I got a notification from a talk page I never edited, which looked something like this:

There's also some part of ghost text I nearly added (a "k") while copying the LTA's talk page link into here, just ignore that. Back in track, this seems weird because I never entered the page LGBTQ rights in Russia nor came across the account on recent changes patrol. And this has been going on pretty much since late April 2026. Anything? – SimpleObjects-9ei 🏖️/☀️/🥵 (🌎 CentralAuth) 17:30, 30 May 2026 (UTC)

The notification system goes by the user name and timestamp of the comment creating the section; they did it that way so the section subscriptions are more robust against sections being moved or archived. But it has its edge cases. In this case, it turns out that ClueBot NG created several sections in the same second, as can be seen here: Special:GoToComment/c-ClueBot_NG-20260530161100-May_2026. Your comment at Special:Diff/1356911923 is in one of those, and subscribing (perhaps by default) to that section effectively subscribes to all three duplicates. Anomie⚔ 17:52, 30 May 2026 (UTC)

The three edits were the same minute but not the same second. The last date format at Special:Preferences#mw-prefsection-rendering includes seconds. The bot made six edits [1] that minute, after 0, 4, 20, 22, 32 and 35 seconds. The three talk posts all say data-mw-thread-id="h-May_2026-20260530161100" in the HTML where 202605301611 is year, month, day, hour, minute. I guess the ending 00 is supposed to be seconds but it's always set to 00 in the examples I have examined, also human edits on other pages. This case shows that maybe seconds should be set. PrimeHunter (talk) 11:12, 31 May 2026 (UTC)

Ah, ok. I saw that seconds were included in the format, but didn't realize they were always set to 00. Anomie⚔ 12:24, 31 May 2026 (UTC)

As a test I subscribed to User talk:PrimeHunter/Archive 20#ArbCom 2025 Elections voter message. Special:TopicSubscriptions now shows me subscribed to 218 sections with that title. This is problematic. PrimeHunter (talk) 11:22, 31 May 2026 (UTC)

I'm experiencing the same behavior, where I'm subscribed to multiple sections that match the name and date from one subscription action. However I discovered that timestamp of the comment creating the section is instead "hoisting the first occurrence that matches the format {{User|Example}} 12:34, 12 May 1964 (UTC)". My edit to Talk:NBC10_Boston/GA1 subscribed me to Talk:WEDU/GA1, Talk:NBC10_Boston/GA1, Talk:KUTV/GA1. The sections were created on separate days, but a bot updates the pages to place who/when it was nominated at the top. These three pages were nominated on the same minute. Matthew Yeager (talk) 04:56, 4 June 2026 (UTC)

User pages and suggested search results

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)

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)

Doesn't seem to have made a difference. Extraordinary Writ (talk) 03:39, 3 June 2026 (UTC)

It suspect user pages are downranked, while subpages are not. Possibly because user pages are marked as "no index" for external search engines. —TheDJ (talk • contribs) 09:57, 3 June 2026 (UTC)

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)

probably something to do with fuzzy search and normal english words like "extraordinary" ~2026-33675-98 (talk) 17:11, 6 June 2026 (UTC)

Special:ListFiles

I noticed it seems to list them in a somewhat low resolution... is there any way they could be higher, or, perhaps, use a kind of category slideshow for its output? ~Lofty abyss 23:23, 31 May 2026 (UTC)

@Lofty abyss low resolution or small size ? That's a significant difference. For me, when I click the image, they do show in multimedia viewer slideshow. —TheDJ (talk • contribs) 09:54, 3 June 2026 (UTC)

When they're clicked they're fine, but I was hoping I could go through the list in somewhat of a better resolution... I try to zoom in on them, and it just seems a low resolution, which I presume is due to a rendered small size of the file. ~Lofty abyss 16:55, 3 June 2026 (UTC)

Problem using del tags

Just now, I made a misclick with Twinkle when notifying a user about an added sentence and had to strikethrough my edit. However, when I did so, the del tag started acting freaky. Here's the diff; the source has the opening del tag at the beginning of the first comment and the closing at the end of the first comment, before my signature. But, somehow, the entire content of the talk page is struck through. This persisted even to new sections.
I've tried looking at the diff in multiple browsers (Firefox, Brave, Edge) but the same thing happens. What's going on? 7amithorn me|talk|stats 06:00, 1 June 2026 (UTC)

Someone will be able to provide the technical details but the reason is that the del tags tried to strike out an image. You should start the del after the image. Re using del, that's not necessary for a case like this. We're supposed to strike out text if it's likely that others have read the comment. For that TA talk page, just delete whatever you want, such as the image, and replace it with a new comment. Johnuniq (talk) 08:18, 1 June 2026 (UTC)

Keep <del>...</del> within one paragraph. This also fails:

<del>
Paragraph 1

Paragraph 2
</del>

PrimeHunter (talk) 11:12, 1 June 2026 (UTC)

Ah okay, I see. Thanks for the help! 7amithorn me|talk|stats 14:21, 1 June 2026 (UTC)

@7amithorn: I suspect two problems here. To begin with, the image has nothing to do with it: the HTML 5.2 spec for the del element shows that its content model is "transparent". This means that when used at block level, it behaves as a block element and may contain pretty much anything; when used at phrasing level, it behaves as an inline element, and may only contain phrasing content. Whichever applies, the closing </del> tag must be at the same HTML nesting level as the opening <del> tag.

• This brings us to the first problem, which is a straight mispositioning of the closing </del> tag - in this case it was part-way through some phrasing content when the opening <del> tag was at block level.
• The second problem is an issue with the MediaWiki parser. The HTML spec mentioned above indicates that the del element should not cross implied paragraph boundaries, but I think that the MediaWiki parser is creating such boundaries by rearranging <p> tags where none were intended.

The fix for both these first problem is to use a redundant <div>...</div> immediately inside the <del>...</del>, neither tag of which is used inline:

<del><div>[[File:Wikipedia-logo-v2-no-text.svg|200px|right]]
Hello, and [[Wikipedia:Introduction|welcome]] to Wikipedia! Thank you for ...

...

Again, welcome! <!-- Template:welcome-unregistered-constructive --><b style="font-family:'Linux Libertine',Georgia,Times,serif">7amithorn <small>[[User:7amithorn|me]]&#124;[[User talk:7amithorn|talk]]&#124;[[Special:Contributions/7amithorn|stats]]</small></b> 05:33, 1 June 2026 (UTC)
</div></del>

The div element fools the MediaWiki software into not messing with the <p>...</p> tags, and also satisfies the requirements of the del element. --Redrose64 🌹 (talk) 08:18, 2 June 2026 (UTC)

Wow okay. That seems way less intuitive than I'd expect for HTML. Is it okay to use <s> instead of <del> in this kind of situation (like I have currently on the page)?

Thanks for all the help, 7amithorn solidarity|talk|stats 23:12, 2 June 2026 (UTC)

@7amithorn: No. The s element may be used where phrasing content is expected and it may only contain phrasing content That is to say, it cannot enclose blocks such as paragraphs or lists. Also, as with any other HTML element, correct nesting must be observed: your closing </s> tag is inside a list. --Redrose64 🌹 (talk) 17:49, 3 June 2026 (UTC)

Sudden severe lag on Wikipedia both signed in and signed out

Example while observing the page history of South Sudan. It took over two minutes for me to scroll down to the bottom of the page.

Hey y'all!

Starting around the 28th, I began to experience some pretty serious lag on my computer. Eventually today, I started thinking that this was a browser (chrome) issue, so I began looking in my Task Manager to see if there was anything unusual, but I didn't find a solution, nor did I find one from troubleshooting or looking online.

Afterwards, I realized that I wasn't getting lag on non-Wikipedia tabs, and so opened up Microsoft Edge to test and see if I was getting lag. Even when signed out, I would get pretty bad lag on pages of decent size, and, knowing that Wikipedia performs slightly worse for signed-in users than signed-out ones, I signed in on Edge, where I got the same lag on Chrome (actually probably even worse). The lag on Chrome can be seen in the video here. This only started at the end of last week, and I had no real issues beforehand with my computer or browser; this is solely a Wikipedia issue. As demonstrated, it makes even reading pages that aren't super short extremely cumbersome.

Does anyone know what may be the cause and solution for this? Thanks! — Knightoftheswords 05:23, 2 June 2026 (UTC)

@Knightoftheswords281 Have you tried turning it off and on again (reboot your computer). —TheDJ (talk • contribs) 09:50, 3 June 2026 (UTC)

@TheDJ, yup, have rebooted my computer several times. Been happening for around a week now. It mainly seems to be the worse on page history pages when I set the query to 500 revisions, but still occurs with any long page of any sort, though I think it's gotten somewhat better for those. — Knightoftheswords 17:47, 3 June 2026 (UTC)

Chinese-language text popup

Hi all,

Is it possible to somehow hide or remove the annoying tooltip that pops up when mousing over Chinese text for more than a couple of seconds? I was trying to read this poem on East Asian rainy season but it kept covering up my dictionary app. For the record I don't need to know that that text is Chinese when I mouse over. I assume it is an accessbility feature? Maybe I can edit my own CSS to disable it?

Cheers Hwfr (talk) 09:01, 2 June 2026 (UTC)

@Hwfr: The text is wrapped in <span title="Chinese-language text">...</span>. I guess it's "Chinese-language text" you want to remove while the text with yellow backgound is your dictionary app. I don't know a way to remove it. I guess it would require a user script. PrimeHunter (talk) 10:55, 2 June 2026 (UTC)

Thanks for the quick reply !

Is this considered to be "best practise" to always include these span titles in Wikipedia articles? In other words, is this one editor's decision to add in this article specifically or is it automatic and universal?

Cheers

--Hwfr (talk) 05:18, 4 June 2026 (UTC)

@Hwfr: The text is marked with {{lang|zh|...}} which is best practice and this automatically wraps it in <span title="Chinese-language text">...</span>, so this is very common. PrimeHunter (talk) 09:42, 4 June 2026 (UTC)

@Hwfr: Try this in your common JavaScript:

document.body.innerHTML = document.body.innerHTML.replace(/title="Chinese-language text"/g, '')

It also removes the text in my posts so they will look different afterwards. PrimeHunter (talk) 12:50, 2 June 2026 (UTC)

@Hwfr: It might also remove code from itself in the edit window next time you edit your JavaScript so try this instead:

document.body.innerHTML = document.body.innerHTML.replace(/title=\"Chinese-language text\"/g, '')

PrimeHunter (talk) 13:09, 2 June 2026 (UTC)

This looks like it would only help if the intention is to suppress tooltips only for Chinese text. However, {{lang}} (and other related templates) also add tooltips to other uses of non-English text. For example, porque no los dos would have the same clash with the dictionary app, as it produces a tooltip for "Spanish-language text". I'm not sure if it's possible to suppress all language related tooltips. You could probably find a way to suppress all tooltips in general, but that may be undesirable since tooltips are also used for other purposes including expanding abbreviations or providing additional information about automatic archival by bots in the Talk page header. – Scyrme (talk/solidarity) 17:25, 2 June 2026 (UTC)

@PrimeHunter: Please don't use regex to (essentially) parse HTML. Also, the second regex is exactly the same as the first; quotes are not special characters in regex, so escaping them does nothing. A better version looks something like this:

document.querySelectorAll('[title="Chinese-language text"]').forEach(element => element.removeAttribute('title'))

The preferred way to go about this, however, is to check how that dictionary app is injecting the popup, then figure out why that popup is shown under and not over the (presumably) native browser tooltip for HTML titles. This can prove to be difficult, especially if that app's source is not publicly available. NguoiDungKhongDinhDanh 17:56, 2 June 2026 (UTC)

@NguoiDungKhongDinhDanh: I only suggested it to a single user who asked for help and would probably prefer it over nothing but great that you know a better way. The point of the quotes was explained in my post: Without them my original JavaScript recognizes title="Chinese-language text" in the edit box when the user js is edited and then it modifies its own code. You can test it with preview in your common JavaScript. The quotes was one of many potential ways to avoid this problem. Your code doesn't have the issue. PrimeHunter (talk) 20:11, 2 June 2026 (UTC)

You are right: Escaping the quotes does have the effect of making the textarea's content unmatchable by the regex itself, even when the regexes are semantically the exact same. Still, the code is unnecessarily hacky. NguoiDungKhongDinhDanh 00:01, 3 June 2026 (UTC)

Why is this?

I go to the "page information" option for any redirect and I see

This redirect is being considered for deletion in accordance with Wikipedia's deletion policy.

Please discuss the matter at this page's entry on the Miscellany for deletion page.

You are welcome to edit this page, but please do not blank, merge, or move it, or remove this notice, while the discussion is in progress. For more information, see the Guide to deletion.

What's going on? Canadachick (talk) 16:09, 2 June 2026 (UTC)

If I understand correctly, there was an old manually-created TableOfContents at the top of those pages (see this revision of the page MediaWiki:Pageinfo-header), but it was fixed in the core-code, and the page was blanked, and the page is now being considered for deletion (nomination: Wikipedia:Miscellany for deletion/MediaWiki:Pageinfo-header). HTH. Quiddity (WMF) (talk) 16:27, 2 June 2026 (UTC)

@Canadachick: Thanks for pointing this out. Asukite used the normal code for templates to try to hide it but MediaWiki messages are different. Fixed by [2]. PrimeHunter (talk) 16:37, 2 June 2026 (UTC)

Oof. Thank you for that, I will be more careful next time. ASUKITE 16:53, 2 June 2026 (UTC)

@Asukite: It's fine, I wasn't aware of this either. My method still displays on page information for the message itself [3] but I guess we can live with that. PrimeHunter (talk) 17:00, 2 June 2026 (UTC)

Broken timelines

Tracked in Phabricator
Task T428063

The timeline graphic is broken / breaks when a user makes any current modification to it, throwing out the following error:

Timeline error. Could not store output files.

Timelines that haven’t been edited today seem okay and I suspect it has something to do with the cache stored for it that gets overwritten when it’s edited, and thus ends up breaking. This affects several projects, most notably WikiProject Tropical Cyclones on tropical cyclone season pages. However I’m aware other projects use the timeline graphic so I’ve posted this here in request of a possible fix. MarioProtIV (^talk/_contribs) 23:56, 2 June 2026 (UTC)

That is an easytimeline error. EasyTimelines are created on the server. Report it on phabricator. Snævar (talk) 10:46, 3 June 2026 (UTC)

 Done, filed as new bug report for EasyTimeline. Hopefully it’s an easy fix considering how widespread it’s used on the wiki. MarioProtIV (^talk/_contribs) 14:46, 3 June 2026 (UTC)

Another instance of the error exists on List of justices of the Supreme Court of Canada. Reverting the page to have timeline syntax consistent with the previously-generated version of the timeline will load that cached version, like this. Purging the page when error is shown has no effect. TheFeds 19:16, 5 June 2026 (UTC)

Invisible Closed Nominations at MFD

I am looking at Miscellany for Deletion at about 0430 GMT, 3 June 2026, and am confused. The Table of Contents shows four entries for June 2, 2026. However, the full listing below the Table of Contents shows only two MFD pages. If I look below the date heading, I see templates that should transclude four MFD pages. I see that two of them, Wikipedia:Miscellany for deletion/Draft:EzatAlnajm and Wikipedia:Miscellany for deletion/Draft:Finger paint (sex act) have been closed. My issue does not have to do with the closures. My question is what is suppressing the transclusion of the XFD pages but allowing the XFD pages to appear in the Table of Contents. Robert McClenon (talk) 04:38, 3 June 2026 (UTC)

@Robert McClenon: Closed discussions can be hidden by "XFDcloser" at Special:Preferences#mw-prefsection-gadgets. There should be a "Show closed discussions" link a the bottom right of the page. PrimeHunter (talk) 04:43, 3 June 2026 (UTC)

Thank you, User:PrimeHunter. That seems familiar, so someone probably explained that to me in the past, but I had forgotten it, and now I remember it again. I think that omitting the display of the closed nominations is a misfeature, but that is only my opinion. Robert McClenon (talk) 22:28, 3 June 2026 (UTC)

og:image metadata outside of mainspace

Mainspace articles include some Open Graph protocol metadata to specify representative images for pages, but it looks like other (maybe all other) spaces don't. If I share an image-featuring user page or project essay on a social media service that supports OGP, it doesn't get a preview image. (The case that led me to look at this was WP:PICYOU, an essay that we'd want people to be sharing on social media.)

I can see some archive discussion of adding OGP support in the first place, but not on which spaces to apply it to. Is limiting it to article space a deliberate design choice? Belbury (talk) 11:47, 3 June 2026 (UTC)

@Belbury: The image is selected by mw:Extension:PageImages which only selects a page image in mainspace, the default value of $wgPageImagesNamespaces. Other namespaces could be added by setting wgPageImagesNamespaces in https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php but I suspect the Wikimedia Foundation would dislike it. They are concerned about copyright violations and page images are used in places which only allow free images. Other namespaces are less checked for copyright violations and having a page image is less important there. PrimeHunter (talk) 14:03, 3 June 2026 (UTC)

Re other namespaces being less checked for copyright violations: on the English Wikipedia, JJMC89 bot removes non-free images added outside of the main namespace. Graham87 (talk) 07:07, 4 June 2026 (UTC)

Image Browsing Mobile Beta Launch Reminder

Hi everyone,

Pinging Sohom_Datta, TheDJ,  Prototyperspective, 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)

remove/hide the "person icons" in the watchlist etc

Is there a way to remove/hide the "person icons" that have appeared in the watchlist, history pages etc (MonoBook skin) in the last few days? They are visually distracting and add no significant value to me. "Preferences" setting would be best, but I can edit my .js or .css files if someone can provide the specifics. Mitch Ames (talk) 10:31, 4 June 2026 (UTC)

Preferences → Appearance → Advanced options → Enable the user info card. Nardog (talk) 10:47, 4 June 2026 (UTC)

@Mitch Ames: You can also add this to your CSS to make them less distracting with instead of the person icon:

.ext-checkuser-userinfocard-button__icon--userAvatar {
  mask-image:url("https://upload.wikimedia.org/wikipedia/commons/thumb/e/e4/Infobox_info_icon.svg/20px-Infobox_info_icon.svg.png");
}

PrimeHunter (talk) 12:42, 4 June 2026 (UTC)

That's fixed it. Thank you. Mitch Ames (talk) 12:46, 4 June 2026 (UTC)

Ctrl + F in new code editor

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

@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)

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)

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)

@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)

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)

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)

@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)

@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)

@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)

By pressing Escape before Tab, you will be able to move the focus out of the editor. 析石父 (talk) 01:12, 7 June 2026 (UTC)

@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)

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)

@Scyrme I don't believe what's being discussed here has anything to do with Parsoid. — MusikAnimal ^talk 00:44, 8 June 2026 (UTC)

Tm:tq v tm:tpq

I added a comment here[4], during the preview the text inside {{tq}} was displayed as green without quote marks, but when I saved it was black with quote marks (causing my comment to have duplicate quote marks). Changing the template to {{tpq}} restored the output to what I expected, but both of those templates are just redirects to tm:Talk quote inline. I'm sure when I've previously used {{tq}} it created green text without quote marks. -- LCU ActivelyDisinterested «@» °∆t° 21:02, 4 June 2026 (UTC)

Ignore this, I'm completely lost as to why it happened but the display is correct for both redirects now. -- LCU ActivelyDisinterested «@» °∆t° 21:08, 4 June 2026 (UTC)

I've now just had weird transient formatting of an articles talk page header, with the header appearing as stacked text with no background rather than the normal orange boxes. Both this and the odd {{tq}} behaviour survived being refreshed, but ultimately self corrected. -- LCU ActivelyDisinterested «@» °∆t° 21:41, 4 June 2026 (UTC)

This sounds like FOUC, which is often a symptom of a slow/dodgy connection. --Redrose64 🌹 (talk) 21:50, 4 June 2026 (UTC)

Thanks I did wonder if it was a local issue. -- LCU ActivelyDisinterested «@» °∆t° 22:00, 4 June 2026 (UTC)

Getting around 5000 page limit on Special:Export

Hi guys,

What's the best way to export a large category to XML? I'm trying to run some regex expressions to find pages to run AutoWikiBrowser on.

Category:CS1 errors: generic name is ~23,600 pages long. After fiddling around for an hour, it seems like Special:Export caps category exports at 5000 pages max, which is insufficient for what I'm doing. I know I could probably get the page sources via the API, but I figure there has to be a more "official" way to do this without putting as much of a strain on the servers.

I know I could export the entire enwiki, but, yknow, that's probably not necessary. EatingCarBatteries _{(contribs | talk)} 03:06, 5 June 2026 (UTC)

Yeah, 5000 is the max. How about getting the list of pages, feeding Special:Export 5000 at a time, and merging the resulting XML dumps? Ponor (talk) 03:55, 5 June 2026 (UTC)

If you specify exactly what you are trying to achieve, people here may have a better solution. It seems unlikely that examining the wikitext for 23,600 pages would be worthwhile. Johnuniq (talk) 05:14, 5 June 2026 (UTC)

Based on the category, I'm guessing something like desk. Which is probably how I'd approach the problem: generate the list from a reasonable search and then refine that list instead. Izno (talk) 05:53, 5 June 2026 (UTC)

I am trying to determine what the most common first and last name combinations are that are causing generic name errors. I was planning to write a script to go through them, and then remove them from the references using AWB. Inefficient, I know.

If you have any suggestions, I'm all ears. I'm aware that database queries don't contain wikitext, so that's off the table. EatingCarBatteries _{(contribs | talk)} 07:39, 5 June 2026 (UTC)

Use the search in Izno's post, make a sample from a few hundred examples, and work from that. Johnuniq (talk) 00:24, 6 June 2026 (UTC)

Log-in issue

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)

@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)

@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)

Section editing through two-layer transclusion

Tracked in Phabricator
Task T422291

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)

Your page is being rendered by Parsoid. This is a currently known issue with Parsoid. Izno (talk) 20:36, 5 June 2026 (UTC)

User:Izno Thank you for your answer. Are there any efforts on solving this? Utfor (talk) 20:45, 5 June 2026 (UTC)

Judging by phab:T422291 (task about this bug), currently no. stjn 22:49, 6 June 2026 (UTC)

"Upright" parameter in image embedding broken?

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)

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)

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)

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)

Firefox 115 (currently 115.36.0esr, with minor updates about every 2 weeks) is the last version that works on Windows 7. [5]. 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)

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)

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)

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)

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)

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)

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)

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)

en:wikisource:Module:Soroban

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)

done – robertsky (talk) 17:26, 6 June 2026 (UTC)

Thanks a lot. ~2026-31538-15 (talk) 01:13, 8 June 2026 (UTC)

Template:TCMDb title

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)

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)

What have I done wrong?

Hello, I have been adding some infoboxes to a few athletes that do not have one. I have added sports links to the bottoms of their pages but there seems to be some sort of glitch that has messed up the pages: when adding the sports links, the authority panels and stubs (which a few are) show up the view and edit template options and squish up their nav boxes in the bottom of the pages - I have no idea what has gone wrong or whether there has been some sort of glitch with adding these links. If anybody has a solution, please help me as this is the first time that this has happened to me and I do not know what has gone wrong. Thanks, SarahTHunter (talk) 09:09, 6 June 2026 (UTC)

@SarahTHunter: Examples please. --Redrose64 🌹 (talk) 09:44, 6 June 2026 (UTC)

Apologies, it has sorted itself out - I assume it was an unfortunate glitch. SarahTHunter (talk) 13:32, 6 June 2026 (UTC)

need some help with a conditional template

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)

Strange edits from a "Renamed user" account

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: [6] 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)

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)

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)

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)

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)

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)

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)

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)

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)