Wikipedia:Village pump (technical)#Proper ECMAScript support

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

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

Shortcuts

• WP:VPTWP:VPT
• WP:VP/TWP:VP/T
• WP:TECHPUMPWP:TECHPUMP
• WP:PUMPTECHWP:PUMPTECH

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 guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for 5 days.

view · edit Frequently asked questions (see also: Wikipedia:FAQ/Technical) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. An offline spellcheck of all articles is run by Wikipedia:Typo Team/moss; human volunteers are needed to resolve potential typos. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228

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

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

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

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

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

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

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

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

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

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

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

If you move content on a page, viewing this using the mobile web differ or the inline desktop differ doesn't display the content move. See Special:Diff/1342472377 - the moved content is duplicated with no indication that a move occurred.  Nixinova  T ⁄ C  03:45, 9 March 2026 (UTC)[reply]

phab:T349335. Izno (talk) 03:55, 9 March 2026 (UTC)[reply]

It can be fixed with local css.  Nixinova  T ⁄ C  04:15, 9 March 2026 (UTC)[reply]

It appears so. I get this CSS when using the inline diff option of the desktop version:

.mw-diff-movedpara-left::after, .rtl .mw-diff-movedpara-right::after {
  content: '↪';
}

.mw-diff-movedpara-right::after, .rtl .mw-diff-movedpara-left::after {
  content: '↩';
}

The curved arrows indicating a moved paragraph are missing in the mobile version. I can produce them by adding the above CSS with !important added:

.mw-diff-movedpara-left::after, .rtl .mw-diff-movedpara-right::after {
  content: '↪' !important;
}

.mw-diff-movedpara-right::after, .rtl .mw-diff-movedpara-left::after {
  content: '↩' !important;
}

PrimeHunter (talk) 04:51, 9 March 2026 (UTC)[reply]

Theres also already css classes present for both inline-moved-source and inline-moved-destination, so they can be styled/coloured distinctly.  Nixinova  T ⁄ C  05:20, 9 March 2026 (UTC)[reply]

@PrimeHunter That ready for MediaWiki:Minerva.css, MediaWiki:Common.css? Ponor (talk) 07:16, 9 March 2026 (UTC)[reply]

@Ponor: It works and you can place it in Special:MyPage/minerva.css for yourself. For sitewide in MediaWiki:Minerva.css, somebody may complain it uses !important or say we should wait for a MediaWiki fix. The page can only be edited by interface administrators , not normal administrators like me. PrimeHunter (talk) 15:10, 9 March 2026 (UTC)[reply]

Oh yes, I was supposed to ping @Izno. Since there’s a toggle for inline diff mode on desktop, it’d be worth adding this to both CSS pages because of the confusion the bug can cause. MediaWiki fix may take another few years. Ponor (talk) 15:31, 9 March 2026 (UTC)[reply]

@Ponor: The inline diff mode on desktop does display the arrows, at least for me in the skins I tried. Are you suggesting we add sitewide CSS preemptively in case it breaks later like mobile? I don't support that. PrimeHunter (talk) 15:41, 9 March 2026 (UTC)[reply]

@PrimeHunter You're right. I only checked the above diff on my phone in desktop mode, I guess the two icons were too small to notice. This is only needed in Minerva.css. Ponor (talk) 16:07, 9 March 2026 (UTC)[reply]

Ah, my task is mostly aimed at what happens on desktop. You are missing the indicators and the solution is an adjustment in CSS on mobile, I would suggest making a new task. It may be seen to sooner rather than later.

And yes, needing to plop importants on it is insufficient. Izno (talk) 16:30, 9 March 2026 (UTC)[reply]

I have made phab:T419530: "Mobile diffs are missing arrows at moved paragraphs". PrimeHunter (talk) 12:44, 10 March 2026 (UTC)[reply]

I see this topic is common: #Mobile diff errors  Nixinova  T ⁄ C  05:24, 9 March 2026 (UTC)[reply]

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

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

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

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

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

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

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

Hi everyone,

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

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

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

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

What did we find?

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

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

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

What are we doing next?

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

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

We’re planning on the following timeline:

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

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

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

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

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

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hello,

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

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

Examples where this occurs:

Files I uploaded:

United States national baseball team

Puerto Rico national baseball team

United States men's national basketball team

Files uploaded by other users:

Cuba national baseball team

Japan national baseball team

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Space bar resetting the search term was recently fixed at phab:T418172. But now there is a new problem. Now the search suggestions are always one step behind the typed term. For example when searching for Trapdoor. Typing T, nothing shows up. At Trap it shows Transnistria while omitting the p letter.

Confirmed affected sites: en.m.wikipedia.org, en.m.wiktionary.org

Phone model: OnePlus 3, operating system: Android 9 / OxygenOS 9.0.6, browser: Firefox 148.0.1

Aloysius Jr (talk) 23:23, 15 March 2026 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://github.com/greencardamom/Wikiurl

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

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

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

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

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

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