Wikipedia:Village pump (technical)/Archive 229

With Vector 2022 skin on desktop, panorama-width images, such as File:五星二十八宿神形图.jpg, to render if the image width is greater than the browser's page width and less than half the original size. Attempting to render as a thumbnail or a standalone image also fails. See Special:Permalink/1350086502 for test cases, based on an instance observed at Liang Lingzan (current revision). –LaundryPizza03 (dc̄) 04:44, 20 April 2026 (UTC)

@LaundryPizza03: I think your first sentence meant to say "fail to render". They all render for me but me but I can see it may fail for others. For example, [[File:五星二十八宿神形图.jpg|thumb|x200px|Thumbnail with height 200 px (width 3268 px)]] produces this HTML for the image:

<img src="//upload.wikimedia.org/wikipedia/commons/thumb/d/d2/%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg/3840px-%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg" decoding="async" width="3268" height="200" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/d/d2/%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg/6536px-%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg 2x" data-file-width="16273" data-file-height="996">

srcset means there are two versions of the image with different resolutions and the browser picks one of them depending on local circumstances:

• https://upload.wikimedia.org/wikipedia/commons/thumb/d/d2/%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg/3840px-%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg
• https://upload.wikimedia.org/wikipedia/commons/thumb/d/d2/%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg/6536px-%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg

Such a srcset is normal for MediaWIki but in this case the second image was broken for me a few minutes ago and gave the below error message. It works now. I didn't try anything like a purge to fix it.

Error

Use thumbnail steps listed on https://w.wiki/GHai. Please contact noc@wikimedia.org for further information (92dd0a1)

If you report this error to the Wikimedia System Administrators, please include the details below.

Request served via cp3077 cp3077, Varnish XID 922585737
Upstream caches: cp3077 int
Error: 429, Use thumbnail steps listed on https://w.wiki/GHai. Please contact noc@wikimedia.org for further information (92dd0a1) at Mon, 20 Apr 2026 12:25:27 GMT

PrimeHunter (talk) 12:49, 20 April 2026 (UTC)

Seems like it's worth a report in Phabricator, pointing out that the various wikitexts you've found produce <img> tags with sizes that their "wgThumbnailSteps" setting rejects. Anomie⚔ 13:13, 20 April 2026 (UTC)

File:五星二十八宿神形图.jpg is 16,273 × 996 pixels. commons:commons:Maximum file size#Maximum size for thumbnails says:

Since December 17, 2021 the servers have no size limit for generating thumbnails. Instead, a timeout of 59 seconds for generating thumbnails was configured by using the new Thumbor service.^[1]

Could the 59-second limit have broken the image at first but later work? PrimeHunter (talk) 14:11, 20 April 2026 (UTC)

No, it's that they changed the servers to reject any sizes other than the ones they expect (T414805) and didn't consider what happens for very large images like these. See the link to https://w.wiki/GHai in the message. Anomie⚔ 14:25, 20 April 2026 (UTC)

The 6536px image works now as I said. It was broken earlier. I have downloaded it and confirmed the size. PrimeHunter (talk) 15:25, 20 April 2026 (UTC)

Opened at phab:T423895. @PrimeHunter: Which browser and operating system are you using? –LaundryPizza03 (dc̄) 15:43, 20 April 2026 (UTC)

I have also proceeded to Talk:Liang_Lingzan#Software_bug to discuss options on how to remediate this on the affected article. –LaundryPizza03 (dc̄) 15:49, 20 April 2026 (UTC)

@LaundryPizza03: Firefox 149.0.2 (64-bit), Windows 11 Home version 25H2. The browser's srcset choice may also depend on things like window size, screen resolution, browser zoom. PrimeHunter (talk) 15:56, 20 April 2026 (UTC)

@LaundryPizza03: I only failed to reproduce it because my browser chose the smaller srcset image. I knew srcset was a possible reason for it to fail for some and work for others so I tested the larger srcset image for the x200px code and it failed at the time but works now. If it still fails for you then try to bypass your cache by holding down Ctrl and pressing the reload button. PrimeHunter (talk) 16:11, 20 April 2026 (UTC)

The 6536px image linked above is still failing for me. 🤷 Anomie⚔ 17:35, 20 April 2026 (UTC)

Now it fails for me again with a similar error message as before. It's public domain so I guess it's OK to make a copy. This is the file I got when it worked: http://primerecords.dk/Wikipedia/6536px-%E4%BA%94%E6%98%9F%E4%BA%8C%E5%8D%81%E5%85%AB%E5%AE%BF%E7%A5%9E%E5%BD%A2%E5%9B%BE.jpg. PrimeHunter (talk) 19:36, 20 April 2026 (UTC)

It looks like the (one person at) WMF response was "no one should ever need images wider than 4000px, so I'm going to just serve the 3840px thumbnail for any wikitext that would want a wider image". Be prepared for your currently-broken wide panoramas to come back but blurry next Thursday. 🙄 Anomie⚔ 12:08, 22 April 2026 (UTC)

Hi, everyone! Who can help me make Czechoslovakia-Hungary locator map as modelled on Czech Republic-Hungary locator map? Slovolyub (talk) 14:59, 21 April 2026 (UTC)

@Slovolyub commons:Commons:Graphic Lab/Illustration workshop --Ahecht (TALK
PAGE) 14:14, 22 April 2026 (UTC)

Some talk pages of redirects have WikiProject tags. Example: Talk:ATA Spec 100/iSpec 2200 has the WikiProject Science tag (probably shouldn't have it).

Could somebody clean up talk pages of redirects from these tags?

• They are not visible on the actual talk page so people can't see these and also can't fix inappropriate ones
• Some tools use WikiProject tags for various things and this problem can put articles (covertly/inappropriately and maybe duplicatively) into them – I found out about this when ATA 100 was showing up in this new visualization of WikiProject Science tagged articles: Visualizing Impact tool – Science

A topic for another day is that probably most WikiProject tags miss lots of articles that belong to the WikiProject/tag topic, e.g. lots of articles in Category:Science do not have the WikiProject Science tag on their talk pages (not all because there are some miscategorizations which also need fixing [where btw deepcategory scans/petscans combined with this proposed tool/feature are one way to find&fix these]). Prototyperspective (talk) 14:06, 16 April 2026 (UTC)

It is more or less desirable to tag redirects with WikiProjects, for identifying future stubs with potential and so on. Are you asking a question specifically about some specific WikiProjects?

They are not visible on the actual talk page so people can't see these and also can't fix inappropriate ones I do not understand what you are saying here. I suppose the question that would resolve any confusion would be "What do you mean by actual talk page?" Yes, they are not visible from the talk page of the redirect target's talk page.

Mistagged WikiProjects are normal. Just remove/replace when you find one that you think doesn't make enough sense (like I've done on the example talk page). Izno (talk) 16:23, 16 April 2026 (UTC)

Don't see why one tag the redirect instead of the article itself. No, this is not about a particular WikiProject. WikiProjects have other pages/lists with requested articles and if a redirect points to an article that does not have info on the subject of the redirect, then the redirect should not point to it. If it does have the information, then the article itself should get the tag.

Yes, with 'actual talk page' I meant, as you correctly suspected, the page where the actual discussion is (still) taking place which is the talk page of the article the redirect points to. I was not asking whether they are visible from the talk page and if a problem is normal/common, that does not mean a question/request about addressing that issue isn't due, quite the opposite. Prototyperspective (talk) 16:31, 16 April 2026 (UTC)

Redirects to lists are the most common reason to tag redirects separately e.g. specific character pages which redirect to a list currently (but which a WikiProject may wish to be notified of if that should change for some reason). Cross-topic redirects are similar e.g. characters that redirect to articles on the work in which they appear. {{WikiProject Fictional characters}} is appropriate for one talk page but not the other. Izno (talk) 16:47, 16 April 2026 (UTC)

Interesting; then one could exclude this WikiProject and see if there's more where tags on redirects are intended. However, even for this it seems more reasonable to have the tag at whatever page has the info about the fictional character, not the redirect page. For finding out if there's more WikiProjects that like to have tags on redirect pages and not get them moved to the actual article's talk page, one could first create a list of which WikiProjects have the most of these kinds of tags. Prototyperspective (talk) 16:57, 16 April 2026 (UTC)

It's up to the WikiProjects themselves to decide what pages they want to include. If they want to include an article and redirects that point to it, they can tag them all, if they so desire. They may want to track what happens to these redirect pages that fit within their subject area. See WP:PROJSCOPE. the Stefen 𝕋ower 18:04, 16 April 2026 (UTC)

@Prototyperspective: See Category:Redirect-Class pages; it has 1,473 subcategories as I write this, and some of those cats have hundreds or even thousands of members - for example Category:Redirect-Class biography pages (59,958). You'll need to convince lots of WikiProjects to give up the idea. --Redrose64 🌹 (talk) 20:04, 16 April 2026 (UTC)

Okay well, I'll use a negative category in the petscan to exclude pages in Category:Redirect-Class science pages. While I doubt that for most WikiProject it's a good idea to have WikiProject tags on redirects but not the pages they're redirecting to, this solves the problem I had. Thanks all. Prototyperspective (talk) 21:25, 16 April 2026 (UTC)

WikiProjects can tag whatever pages they think fit into their subject area, and redirects are pages. WikiProjects don't just cover articles, but also templates, categories, redirects, files, etc. the Stefen 𝕋ower 17:57, 16 April 2026 (UTC)

Prototyperspective, for a start you should filter out cases where the redirect has Category:Redirects with possibilities. — Qwerfjkltalk 12:32, 19 April 2026 (UTC)

Also, Prototyperspective, sometimes the redirects are of interest to a project, even when the target mostly isn't of interest and the redirect doesn't have possibilities. Imagine Tinysmalltown Fire being redirected to Tinysmalltown#Fire, and the Fires Wikiproject tags it because they care about fires, and kind-of care about the fire section of the Tinysmalltown article, even though Tinysmalltown in general is out of their scope. Nyttend (talk) 07:26, 22 April 2026 (UTC)

I see the point but think that's a case where the WikiProject should be on the article itself. It's of interest there, should be visible there, and what if the fire info is removed. If the article is put for deletion, including the fire section the wikiproject doesn't learn about it and probably various other issues. No need to hide it on a redirect. There's one advantage though and it's that the subject/content is clearer from the page included in the linked category.

The proper way I thought would be to add the project tag to the article talk page and eg specify the section in the tag (via parameter). One could also specify a redirect to the given article in the template parameter and/or put WikiProjects where only a part of the article is of relevance in some section of the {{WikiProject banner shell}} or in some separate template that informs that these are only about a part of the article (incl to prevent it from being removed) and maybe displays them in a smaller way. Probably many such redirect-class tag categories need cleanup (eg articles being tagged twice and being far more likely to have offtopic tags because nobody watches/sees these).

My immediate problem was solved by just excluding redirects for the topic visualization tool input csv so I don't care if things are kept as is and it's not of high importance. Fine with it. May be a subject for another day, especially since a good change of the state of things may need some development (like being able to see/fetch the redirect/section when an article has that specified directly on the category page and query tools using it and a template parameter for specifying such). Prototyperspective (talk) 10:44, 22 April 2026 (UTC)

Prototyperspective, consider an article about a typical town. Ideally, it will have a section or subsection on the town's climate. Should every properly filled-out article about towns everywhere in the world be in the scope of Wikipedia:WikiProject Weather? Note that its climate task force specifically concentrates on big templates for use in articles about towns. Nyttend (talk) 19:37, 22 April 2026 (UTC)

Do (nearly) all articles with such sections have the tag set on a redirect and does a redirect to the section exist for (nearly) all such pages?

Maybe somebody else picks up this topic at another time, I don't care about it and see no urgency to address this but I'm not convinced it's a good idea to have the tags on a small fraction of redirects instead of on the article talk page for reasons that I outlined. Btw, a concrete application for having it on the town talk page is that one could then maybe scan for the largest town articles without that tag set so that info on the weather is added albeit I don't know if that's desirable. City articles are somewhat special case anyway – they have info on content in scope of lots of WikiProjects. However, it appears usually neither the city nor the redirect pages to the sections are tagged with things like WikiProject Sports, WikiProject Culture, etc. Maybe it would be all cities (above a certain size? with certain criteria? all?) are in scope of several such WikiProjects. Makes little sense to have such tags on some city talk pages, some redirect talk page, but not on >70% of large city articles like Hamburg.

In any case, the context of my problem was the usefulness of these tags to identify articles in scope of a certain topic; the problems introduced by having the tag set on redirect pages was in my case and can be solved by simply putting the redirect-class category in the negative categories in a query tool like petscan. However, WikiProject taggers should be aware that when this is done, the articles that were correctly identified as within the project / project topic scope that do not also have the tag on the actual article talk page won't be included in tools/visualizations/analysis like the one I linked. Not really a significant problem. Tags so far are usually quite gappy anyway already so for a more complete view, one would also have to somehow include articles via other means such as category-scans (and the linked site also has a tool for that). Prototyperspective (talk) 21:26, 22 April 2026 (UTC)

For a few weeks now, if I use the {{find}} template and try to search for books, I get a Google error message "We're sorry... ... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now."

Is this a Wikipedia problem, or something specific to me? I am working from home. Masato.harada (talk) 07:09, 21 April 2026 (UTC)

It's because it is trying to go directly to the book section with the tbs=bks option. Apparently that is no longer supported it seems by Google. Not sure it there is a replacement. They don't really tend to document these options all that well.. —TheDJ (talk • contribs) 09:22, 21 April 2026 (UTC)

Looks like tbs=bks:1 doesn't work, but tbs=bks does work, and redirects to udm=36, the same as if you manually click the "Books" tab in the search results. Another option is tbm=bks. Those two options seem to generate identical results, just with minor layout differences. --rchard2scout (talk) 10:16, 21 April 2026 (UTC)

Notified Module talk:Find sources. Mathglot (talk) 03:07, 23 April 2026 (UTC)

What's going on with the earliest entries in Special:Contributions/Larry Sanger? There's a clear error in MediaWiki:Contributions-account-creation-date, since it says that his account was created on 30 January 2002, but User:Larry Sanger was one of the founders of the project a year earlier, and his earliest surviving edits are from March 2001. Graham87 does enough wikiarchaeology that he might know, but as he's blind and uses a screenreader, I don't know whether he's able to handle this kind of question. Nyttend (talk) 09:53, 22 April 2026 (UTC)

The Larry Sanger situation is a particularly odd one, because his earliest edits listed under an account name (not counting the LarrySanger account) are/were listed under the username Larry_Sanger, therefore being affected by T2323. The account creation database fields for early acounts were pre-filled in around 2006 (se the links from this discussion). This was before the introduction of edit imports in 2009, particularly from the Nostalgia Wikipedia, a copy of the Wikipedia database from December 2001 (imports from around this time go under the username "Larry Sanger", making the 2001 edits that were subsequently imported visible under his contributions page). Also see User:Nemo bis/Bug 323 revisions, particularly the last two subpages listed there, and more tangentially this thread on Larry Sanger's user talk page. Graham87 (talk) 10:19, 22 April 2026 (UTC)

Graham87, I guess you were able to access more data than I expected :-) Sorry to discount your screen reader. Is there a significance to the underscore, distinguishing "Larry_Sanger" from "Larry Sanger"? I don't understand the technical details, but it sounds as if there were some significance years ago; has anything changed in the last decade? Nyttend (talk) 20:36, 22 April 2026 (UTC)

@Nyttend: No worries re the screen reader. I don't know for certain but I believe that in UseModWiki and the Phase II software, "Larry Sanger" and "Larry_Sanger" were distinct usernames whereas MediaWiki has always reacted oddly in various ways to the underline version ever since it was installed here in July 2002 (hence the very old Phabricator task). But also, it seems like login was by user ID number in the UseModWiki days, per the relevant enttry in the Wikipedia FAQ on the Nostalgia Wikipedia. In MediaWiki, username text could be stored separately from user ID numbers for each edit, but this is not the case now (see mw:Manual:revision table#rev_user_text). Graham87 (talk) 03:43, 23 April 2026 (UTC)

It would be nice for all of this to be properly researched and corrected. The trouble is that Bomis did a poor job of backing up data, hence we do not have all the data we need. Larry Sanger (talk) 21:12, 22 April 2026 (UTC)

The latest run of Special:WantedCategories features several redlinked "Terrorism in the [Decade]" categories that were recently deleted at WP:CFD, but remain populated because the categories are being artificially autogenerated and transcluded by {{Terrorist incidents in YYYY category header}}. However, there are several other decade categories for the 1910s, 2000s, 2010s and 2020s that have not been deleted, so I can't just yank that category-generation code out of the template since that would also depopulate the undeleted categories — but every time I've ever tried to #ifexist category code in a template by myself without soliciting outside help from template coding experts, I've broken things in the process, so I'm reluctant to try again myself.

But I've already posted a request at Wikipedia talk:WikiProject Templates, which has remained unanswered with the redlinks still unemptied ten hours later. So could somebody who's more knowledgeable than I am about template coding quickly slap an #ifexist on the "Terrorism in the [Decade]" code so that the redlinked categories go away while the bluelinked ones don't? Thanks. Bearcat (talk) 00:44, 23 April 2026 (UTC)

Fixed. There was already an ifexist check but someone screwed up the polarity so it was adding the category only if it didn't exist. * Pppery * _{it has begun...} 02:19, 23 April 2026 (UTC)

That sounds like exactly the kind of thing that would have happened if I'd tried it myself, so I'm glad I didn't attempt it. Thanks! Bearcat (talk) 10:17, 23 April 2026 (UTC)

Hello. Apologies if this is the wrong place, but my guess is that this is a technical issue, hence why I'm posting it here. I recived this mentorship question, but I am not a mentor, although I was one in the past (dunno how to prove this, but I went to Special:MentorDashboard to double check and it redirected me to the mentorship enrollment page). Any ideas on why this happened? I don't mind answering the questions, in fact I might rejoin mentorship soon, I just found it a bit odd, and would also prefer to not have unexpected questions appearing on my talk page. Thanks in advance for the help! GrayStorm^{(Talk to me|My Contribs.)} 15:29, 21 April 2026 (UTC)

@GrayStorm Wikipedia talk:Growth Team features might be the place to ask if nobody here knows. Gråbergs Gråa Sång (talk) 18:39, 21 April 2026 (UTC)

Was the account created before you quit mentorship? If so, it's possible that they were assigned a mentor before you quit, and they were not re-assigned one. BSH (talk) - (they/them) 19:44, 21 April 2026 (UTC)

So I was assigned you as a mentor when I joined and I can confirm you still show up as my mentor when I log in. ExtantRotations (talk) 20:12, 21 April 2026 (UTC)

@GrayStorm - Sorry for the confusion, and thank you for reporting this. When you left the mentorship program, your existing mentees should have been reassigned to other active mentors. It appears that this did not happen as expected in your case.

I have filed a bug report so the Growth team can investigate: T424099 Growth Mentorship: Former mentor continues receiving mentorship questions after unenrolling

We appreciate the time you previously spent supporting newcomers. It is great to hear you may consider rejoining as a Mentor in the future, and hopefully we can fix some of the quirks in the meantime... so thanks again for reporting this issue! - KStoller-WMF (talk) 21:41, 21 April 2026 (UTC)

{{#mentor:Oliversamson1}} and {{#mentor:ExtantRotations}} produce and VortexPhantom. Both say "GrayStorm" at the time of writing, confirming the bug. PrimeHunter (talk) 22:17, 21 April 2026 (UTC)

@GrayStorm and Gråbergs Gråa Sång: There is Wikipedia talk:Mentorship. --Redrose64 🌹 (talk) 19:48, 22 April 2026 (UTC)

Yes, or even better, mw:Talk:Growth. New section § I am still receiving mentee messages although I am not a mentor anymore has been added to help users who find the WP:Mentorship page. Adding Trizek. Mathglot (talk) 03:00, 23 April 2026 (UTC)

Thank you for the ping, @Mathglot. You pinged my volunteer account.

The Growth team is aware of this as KStoller-WMF filled T424099. Thank you for your patience! Trizek_(WMF) (talk) 12:24, 23 April 2026 (UTC)

So I was attempting to protect two attack pages in Wikipedia:Requests for page protection/Increase. I sent both at once, but only one ever registered, as Twinkle just changed the "3" to "4" and needed to report it again, and I needed to urgently report the first attack page before the second one got protected. Why is this...? - SimpleObjects-9ei 🌸/🌻/🌞 01:25, 23 April 2026 (UTC)

Twinkle now sends requests for protection increases directly to Wikipedia Requests for page protection/Increase rather than the main RFPP page. When you click submit on a Twinkle protection request, the script fetches the current version of the page, appends your request, and saves it. If you trigger a second request while the first is still processing, the second instance might fetch the "old" version of the page (before the first edit finished) or fail because the page's "Edit Token" changed the moment the first request was saved. Always wait for the first Twinkle popup to confirm the edit was successful before initiating a second request for a different page. For large groups of pages, there is a P-batch feature in Twinkle, though it is generally for administrators to apply protection rather than for users to request it. ~2026-24893-61 (talk) 13:38, 23 April 2026 (UTC)

Update outdated advice in this technical page and the category redlinks note in the Help:Category page in creating category pages, e.g., "To start a page called Category:Cultural conflict, type in the box below. When you are done, preview the page to check for errors and then publish it" because it is less accessible compared to "To list a page in this category, do not edit this category page. Instead, edit the page you want to list." This would better fulfill the policy of accepting category redlinks and avoid bias against less-studied topics. Lumbering in thought (talk) 13:39, 23 April 2026 (UTC)

I was convinced there is a structural bias against less-studied topics. This is not a discussion for here. However I still think the hurdle for the category creator should at least be made as accessible and coherent as possible, which it currently isn't. Lumbering in thought (talk) 16:47, 23 April 2026 (UTC)

I cannot directly click on my watchlist anymore, because it is replaced by Special:ReadingLists/Shushugah my menu in Vector 22 skin. How can I get it back? ~ 🦝 Shushugah (he/him • talk) 21:35, 23 April 2026 (UTC)

Fixed by adding

html body header .vector-user-links #pt-readinglists-2 ~ #pt-watchlist-2 { display: block !important; } to Special:Mypage/vector-2022.css per instructions at mediawikiwiki:Talk:Readers/Reader Experience/Reading lists ~ 🦝 Shushugah (he/him • talk) 22:02, 23 April 2026 (UTC)

You can also disable "Saved pages" at Special:Preferences#mw-prefsection-betafeatures if you don't want to use the Saved pages feature which takes over both the watchlist and watch/unwatch positions. PrimeHunter (talk) 22:21, 23 April 2026 (UTC)

I've been around for just almost 20 years, and I have almost 300,000 edits. I think I'm over the EC threshold :-) My user rights log shows the right first appearing in 2023, an automatic grant, probably when the right was created. It was removed in 2024 when my admin rights were restored, since it's redundant to admin rights.

I just ran across {{Extended confirmed restriction}} for the first time. To my surprise, it said Your account is not extended confirmed, but you are an administrator, so your account is extended confirmed by default. Why does the template have this setting? And why, technically, is EC-normal different from EC-admin?

I just granted myself EC, and as expected, now the template says Your account is extended confirmed, so I know there's not some weirdness going on. Nyttend (talk) 02:18, 20 April 2026 (UTC)

I'm not an expert in templates, but from looking at the code it seems to check if the viewer is extended confirmed using {{If extended confirmed}}, which, as the documentation notes, doesn't register admins. The {{If extended confirmed}} always say "not extended confirmed" in this template if the user isn't a part of the user group extended confirmed. However, there is an additional template in the template, {{If administrator}}, which tacks on the "you are an admin blah blah blah" note to catch the overlap of not being in the user group but having the rights that occurs with the removal of extended confirmation upon gaining adminship. GrayStorm^{(Talk to me|My Contribs.)} 03:34, 20 April 2026 (UTC)

In short: that template is using a css hack to change the text, and is looking at "are you in this group", not "do you have this permission". — xaosflux ^Talk 13:20, 20 April 2026 (UTC)

This (at least as far as I know) is governed by the group css in the Media Wiki namespace that get applied to all accounts that are in a certain group. The applicable one can be found here: MediaWiki:Group-extendedconfirmed.css, they toggle the extendedconfirmed-show css class for a account on the entire wiki. Afaik if you add the content of that to your own css you will show up as extended confirmed. (Without having to be in the group) There's also one for the sysop group if you are interested: MediaWiki:Group-sysop.css. (technically the extendedconfirmed-show could be added to that but I suppose this was not done for a particular reason I am not aware of) Squawk7700 (talk) 19:20, 20 April 2026 (UTC)

@Nyttend For very WP:BEANS reasons, it would be very bad if there were a way to hide text only for administrators but show it to everyone else. That is one of the reasons why extended confirmed is removed when someone is granted admin rights, since there is CSS in place that can hide text from extended-confirmed users. The workaround is showing the second half of the sentence only to administrators. --Ahecht (TALK
PAGE) 13:55, 21 April 2026 (UTC)

You misunderstand me, or I didn't express myself well. Why shouldn't the template just check for the account's ability to edit the page, and say "your account is extended confirmed" if it is? It just seems a bit complicated, and confusing because what matters in this situation is your ability/inability to edit a page, not the combination of user rights that affects that ability/inability. Nyttend (talk) 20:35, 21 April 2026 (UTC)

Templates do not have access to that information. Izno (talk) 20:53, 21 April 2026 (UTC)

Hmm, okay, can't argue with that. Thanks! Nyttend (talk) 00:02, 22 April 2026 (UTC)

@Nyttend, @Izno Why do we remove EC when an editor gains admin? It seems pointless to remove that, and as described here, it makes other things more complex. David10244 (talk) 04:52, 22 April 2026 (UTC)

David10244, that's not a matter for the technical village pump. See WP:VP/Pr#Removing XC rights as redundant, which I began two days ago, asking that we stop doing this. Nyttend (talk) 07:22, 22 April 2026 (UTC)

@Nyttend Right, thanks. David10244 (talk) 06:46, 24 April 2026 (UTC)

Good day. Please assist me. I uploaded the logo for the South African Department of Small Business Development using WP:Upload under fair use, since it isn't available under a free license for Commons. However, the logo does not display, on the article page and the upload page. I've added it to the article's infobox, but it appears transparent. The file page itself also shows the image as blank. Though when I click through to view the file directly, the logo displays correctly (see here). This is the second time I've uploaded the file. The same issue happened before, and I requested it to be deleted. The file is not blank as seen by the wikimedia link. Is there any reason for why this may be happening, and is there any solution for it? Thanks! beegskin • 🖂 • 🖉 • 13:14, 24 April 2026 (UTC)

@Beegskin It appears to be working find for me. Might be a WP:REFRESH issue. --Ahecht (TALK
PAGE) 13:58, 24 April 2026 (UTC)

The generated HTML for the infobox offers two versions to the browser:

• src=https://upload.wikimedia.org/wikipedia/en/thumb/7/77/Department_of_Small_Business_Development_Logo.svg/250px-Department_of_Small_Business_Development_Logo.svg.png
• srcset=https://upload.wikimedia.org/wikipedia/en/thumb/7/77/Department_of_Small_Business_Development_Logo.svg/500px-Department_of_Small_Business_Development_Logo.svg.png

The first 250px version works for me but not the second 500px version. My browser picks the first when the infobox is viewed but other browsers wil pick the second depending on circumstances. PrimeHunter (talk) 14:33, 24 April 2026 (UTC)

I see the small png rendered in the infobox fine, but viewing the raw svg or the larger renders fail. Looking at the actual svg code, it appears that this is not just the logo but the first page of the pdf source with all the other images etc and it just has a viewbox over the logo. I don't know how you created this but it appears to have a lot of junk that needs cleaning up. I tried using Inkscape to load the pdf and export just the logo, but it then just shows in the browser as black and white due to using icc colours and I don't have the time to find a fix for that. KylieTastic (talk) 16:31, 24 April 2026 (UTC)

Actually I just worked out how to do it (I think) so I have uploaded a new version. I thought it had failed at first, but it just needed the browser cache cleared. KylieTastic (talk) 16:54, 24 April 2026 (UTC)

I have been able to add ref ideas to other pages, and this is the first time an error like this has happened to me.

When I attempt to edit the source, and then try to submit my changes, NOTHING happens and the edit is not accepted. The page does not refresh, nothing happens. It just sits there almost as if I never hit the "Publish changes" button.

However, after waiting many minutes the following pops up — "There was an error while loading the form. To continue, you will need to reload the page." The error message is contained within a red rectangular box with a stop sign next to it, and is displayed below the "Edit summary" and above the "Publish changes", "Show preview", and "Show changes" buttons.

Similarly, I opened a new topic on that talk page, titled can't edit the ref ideas for some reason?, and after posting the thread using the "Add topic" link at the top of the page, I am now unable to go back in and edit my comment manually.

I also tried to manually "edit source" for another comment that I have posted on a different talk page, and the same error occurs.

I have used multiple different web browsers, but no luck. Any ideas? ~2026-24524-49 (talk) 05:14, 22 April 2026 (UTC)

Feel free to ignore the above message. Perhaps this has something to do with the Opera web browser, or a plug-in that I have running, because I have been able to edit from source just fine on Chrome. Sorry for the bother. ~2026-24524-49 (talk) 07:39, 22 April 2026 (UTC)

This comment by Helpful Raccoon seems to clarify the situation: ... this is because your edit triggered Wikipedia's hCaptcha, an anti-abuse measure. I don't think Javascript is required in most other cases. Well dang, that's annoying. I would prefer to be able to block as much Javascript as possible, while still being able to edit Wikipedia. Bummer. ~2026-24524-49 (talk) 08:11, 22 April 2026 (UTC)

A way around the Captcha is to register and log in. Graeme Bartlett (talk) 02:00, 25 April 2026 (UTC)

I imported a template on Wikispecies earlier today, and one of the modules on which it is dependent (either Module:Wikidata or a child module of that) appears to have been broken, which has in turn broken two highly used image templates. Please can someone assist, at species:Template talk:Image#Error?

If necessary, feel free to roll back all the imports I made there today (I can't find the mechanism to do so; and it's bedtime here). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 20 April 2026 (UTC)

@Pigsonthewing: Imports can't be rolled back as such. The only way to undo the effects of an import is to delete the resulting edits (by either straight deletions/undeletions or using the history-merging special page, whichever works best). Graham87 (talk) 03:06, 21 April 2026 (UTC)

What two templates would I be history-merging? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:44, 21 April 2026 (UTC)

@Pigsonthewing: Oops, I wasn't clear. You'd be history-merging (or really history-splitting in this case) the edits you didn't want to import to a temporary page you'd create as a holding cell (like "template:Templatename/temp", that you'd then delete. Graham87 (talk) 14:45, 21 April 2026 (UTC)

I tried that; no luck, I've had to delete and re-import the module.

The image issue persists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:55, 21 April 2026 (UTC)

This is pressing. Many pages are affected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:24, 22 April 2026 (UTC)

 This section is resolved and can be archived. If you disagree, replace this template with your comment. Seems to be fixed now. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:49, 25 April 2026 (UTC)

In Pashto Wikipedia, when we use a template in other templates, it gives a problem that the first letter of the template is not included, due to which the template does not work either. I am providing an example here as a link

For example, on this page we have used کينډۍ:پرځول which is replaced by کينډۍ:رځول شاه زمان پټان (talk) 04:29, 25 April 2026 (UTC)

Hi. I tried to solve this, but couldn't. Maybe it's too much for me, maybe it's because of letters I can't read, maybe it's a Phabricator issue. Looks like you need somebody better than me. But at least I could fix the page you've provided, see ps:special:diff/363367, and make sure I didn't break anything. IKhitron (talk) 07:56, 25 April 2026 (UTC)

No thanks, I can redirect this page, but that doesn't solve the problem. This is a major problem that has affected almost all templates and needs to be fixed. شاه زمان پټان (talk) 11:23, 25 April 2026 (UTC)

What I did wasn't redirect, it was a change in a call way. And also, did you try to fix the noinclude bug in "کينډۍ:پرځول", last character missing? I do not see how this can help, but may I'm just wrong. IKhitron (talk) 11:29, 25 April 2026 (UTC)

I'm presenting you with another page here, this problem is everywhere. شاه زمان پټان (talk) 11:32, 25 April 2026 (UTC)

I don't know Pashto and cannot tell which problem you are reporting. I just see a page in an unreadable language with five red links which may or may not be what you want fixed. If you think there is a general MediaWiki issue then can you make a simple example with English template names? PrimeHunter (talk) 15:10, 25 April 2026 (UTC)

this problem is in alot of templates
for example win we use Template:Collapse bottom it is change to Template:ollapse bottom
I think there is a problem with a module, but I dont know which one is this. شاه زمان پټان (talk) 05:22, 26 April 2026 (UTC)

@شاه زمان پټان on the page you linked just above, ps:لارښود:پېژند, I see a redlink to ps:لارښود:پېژند/پايله at the bottom of the box. Is that the problem you have? Everything else looks like it's working properly. ~2026-25404-28 (talk) 08:08, 26 April 2026 (UTC)

when we use a template for example Template:Collapse bottom it give us a result Template:ollapse bottom, there is missing in template name the first letter of template and result is an errore.
I think there is a proble in Module:Protection banner, but i am not sure شاه زمان پټان (talk) 09:33, 26 April 2026 (UTC)

None of your linked examples use "Template:Collapse bottom" and the wiki has no pages which attempt to transclude "Template:Ollapse bottom". I still haven't seen the reported problem and give up trying to help. PrimeHunter (talk) 11:00, 26 April 2026 (UTC)

In First Cathedral of Saint Paul (Minnesota) the mapframe in the infobox has hairlines above and below it. In Big Duck, the hairlines are missing. I imagine the difference is buried in the details of how the infoboxes are built, but the amount of template magic in those is way beyond my fu. What can I do to get Big Duck to have the same hairlines First Cathedral has? RoySmith (talk) 02:01, 26 April 2026 (UTC)

@RoySmith: These "hairlines", as you call them, are in the code of Template:Infobox church, specifically the line

| imagestyle = {{#if:{{{pushpin map|}}}||border-bottom:1px #aaa solid}}

There is no corresponding code in Template:Infobox NRHP. --Redrose64 🌹 (talk) 10:03, 26 April 2026 (UTC)

Thanks, that got me pointed in the right direction. BTW, hairline is a standard term in the printing industry, although this might not meet the strict definition. RoySmith (talk) 16:46, 26 April 2026 (UTC)

Moved from Wikipedia:Administrators' noticeboard § New sitewide requirement to enable Javascript to edit

 – — Newslinger talk 10:44, 16 April 2026 (UTC)

I'm not even 100% sure if this is where this belongs. If it should be moved elsewhere please let me know.

I have edited Wikipedia on and off, sporadically, for probably well over a decade. Infrequently and mostly just to fix typos and similar copyediting rather than to add a lot of new information. Those edits, while unglamorous, have also been uncontroversial.

I went to fix another such typo today and discovered something quite alarming, and unwelcome: apparently you no longer permit anyone to edit anything here unless they first permit scripts from Wikipedia itself and several Wikimedia subdomains to run. This would appear to violate WP:ACCESS, particularly MOS:PRECOLLAPSE, and I don't recall ever seeing any announcement or discussion of such a major, profound shift in policy.

I consider demands to enable scripting to be invasive and, quite frankly, rude. It is a demand that end users compromise their machines' security for, at best, your machines' security, and more likely just your convenience. In many other cases (though I don't believe Wikipedia would do such a thing) the motive is blatantly commercial: to track users, obtain personal data about users, advertise to users, and/or coerce additional things from users, e.g. by using nag popups or other such tactics to harass users who won't subscribe/create an account/etc. which invariably entails filling in forms with more such saleable data, or using popups, distracting attention-grabbing animations, and similar nuisance elements to try to upsell the user.

Whereas I doubt Wikipedia has such commercial motives, it still is a demand that the user increase their potential exposure to hacks and worms, for little or no benefit to the encyclopedia given that it functioned for literally decades without any such invasive demands on editors. Regardless that you would not exploit your script access to foist malware on users, you are now making it so that any breach of your own security could potentially turn into a breach also of millions of editors' security; also, how many people have the ability to create or edit scripts that might be run on the machines of any editors who visit a) an article they've edited, b) their talk page, or c) other pages here? Allowing Wikipedia/Wikimedia to run scripts on my machine means allowing all of those users to also run scripts on my machine, and it only takes one of them having nefarious intent and slipping past your vetting process to ruin my entire week with lost work and hours spent on restoring backups and whatever other labor it might end up taking to clean up their mess.

Besides the increase in attack surface (the barrier for a malicious editor, or someone who has breached your servers, to breach my machine has lowered from "find a Firefox vuln that can be exploited with just specially crafted HTML and CSS" to "find a Firefox vuln that can be exploited with a malicious script" -- in the past year, Firefox has patched 0 zero-days meeting the former criteria and umpteen meeting the latter), there is an additional matter of moral hazard. Now that you have enforced script whitelisting, at least for editors, you will undoubtedly be tempted to abuse that permission. You will tell yourself that it is in a good cause; even that the very survival of Wikipedia depends on it (though, again, it got on fine for 20+ years before all this); and you will do something like, say, interrupting everyone with nag popups imploring them to donate. You will of course make those popups easily dismissed without donating, but you will end up stealing several million seconds of other people's valuable time in your undoubtedly well-meaning attempt to boost donations. There are other ways you will also no doubt be tempted to misuse scripts in the name of, say, preventing vandalism or identifying sockpuppets. A little harmless information gathering and device fingerprinting that of course will never be shared with any third parties, say. Or adding nuisance UI behaviors that HTTP POST don't make possible to try to rate-limit ... something. Or etc. And, of course, once you have taken that step, you will then have strong motivation to force everyone else to whitelist your scripts by rendering the site not even readable without Javascript. And so it goes, each individual step seeming reasonable by itself but leading, in the end, to the same kind of enshittification that is steadily corrupting the rest of the web these days, albeit in your case with the best of intentions.

All of that is leaving aside the reason for the MOS:PRECOLLAPSE policy that is being flagrantly violated here, which is that people with older or unusual devices, unusual security needs, and similarly have the same right to read and edit the encyclopedia as does everybody else.

In light of the above, I believe that demanding to run code on everyone else's computers is a very big ask and not one that should have been undertaken without a very long and thorough discussion first. I am asking that the changes that were made to the edit submission form that a) demand users enable scripting and b) cause submission to fail if they have not complied be reverted at least temporarily until such discussion has been had.

Again I am uncertain if this is the best place to post this; there does not seem to be a separate, specific forum for debating fundamental and site-wide UI changes, let alone disputing them. Perhaps there should be. In any event feel free to move it to a more appropriate venue, if necessary, while of course notifying me of any such move.

~2026-23303-64 (talk) 03:35, 16 April 2026 (UTC)

If you got the message "JavaScript is required to continue. Turn on JavaScript in your browser settings and refresh the page.", this is because your edit triggered Wikipedia's hCaptcha, an anti-abuse measure. I don't think Javascript is required in most other cases. Helpful Raccoon (talk) 05:24, 16 April 2026 (UTC)

Just to confirm the above, I made this edit with javascript completely disabled. I would also say, this post seems a bit uncharitable to the devs. Wikipedia is one of the few hold outs on the Internet that doesn't require Javascript to have a functional website, and does it's best to fail gracefully when Javascript isn't enabled. --Chris 06:20, 16 April 2026 (UTC)

I think it just works because you are logged in. It appears that Javascript is needed for the CAPTCHA that I guess TAs are required to do. I tried an edit on a logged out browser and it failed, but nothing noted in the editfilter suggested it was deemed dubious. KylieTastic (talk) 09:32, 16 April 2026 (UTC)

Not all TA edits require it — this one didn’t, for instance. ~2026-86111-3 (talk) 10:08, 16 April 2026 (UTC)

That's because you hit "Reply" rather than editing from source. ~2026-24524-49 (talk) 08:06, 22 April 2026 (UTC)

a) Why would some edits trigger such a thing but not others?

b) Would not the triggering edits be those that added significant material, were large deletions, or contained words likely to be used by shock jock vandals, for instance slurs? The edit at issue was a one-character capitalization fix. (I would have checked the "this is a minor edit" box but couldn't find it for some reason, another anomaly.)

c) When I enabled JS and resubmitted it I was not presented with any captcha. It went through. So it is definitely doing the JS-required thing in additional cases than just the ones that trigger a captcha. (And I did try to submit it without JS first, without success. It gave a message claiming I had not solved a captcha! This is very odd in light of the fact that when I reluctantly enabled JS and resubmitted it, no captcha was shown, thus I did not solve a captcha (again), and yet that time it went through without issue.)~2026-23303-64 (talk) 08:14, 23 April 2026 (UTC)

I misspoke a bit when I said "edit", when I tested this it triggered for me before I started editing, likely based on IP address and other technical factors that are unlikely to be public. Helpful Raccoon (talk) 08:42, 23 April 2026 (UTC)

Editing from source will also trigger the hCaptcha, thus blocking such edits if Javascript is disabled. ~2026-24524-49 (talk) 00:47, 24 April 2026 (UTC)

You don't have to use Javascript. You just won't be able to edit from some places in the world if you do not have it enabled. Few are enthusiastic about this, and yes "it functioned for literally decades", but the world is not standing still WITH us and the way that world around us changes does AFFECT us. We experience way more automated roaming ip attacks than we had 25 years ago. The way I see it, we are 15 years behind the curve of most websites and highly conservative, but there are boundaries to that. And lastly, MOS PRECOLLAPSE is a community guideline, it does not een apply to the overall software implementation —TheDJ (talk • contribs) 11:41, 16 April 2026 (UTC)

So, you're also discriminating against editors on the basis of nationality. Wonderful. And whatever system you're using to do that is misfiring, thinking I'm in Russia or some place like that that has acquired a reputation, deservedly or otherwise, for harboring lots of hackers, rather than where I actually am?

What are these "automated roaming ip attacks" trying to do? Vandalize pages? Delete unfavorable information about businesses or wealthy individuals? Is there no way of fingerprinting these more narrowly than "is from country X"? I could see treating large deletions on biographies and businesses' articles as suspicious, any addition of slurs to a biography, or "search and replace" edits that change or remove every occurrence of some specific word, as those could all be automated reputation sullying/whitewashing attacks. Or is it spammers trying to insert ads? Almost every case of that will include a link to a page that is a) a for-profit business entity and b) not already linked from the same page (vs. adding another link to company X on a page related to company X's area of business, or company X itself, that already links to other such pages, say citing a new press release or a new product's spec sheet or suchlike, which is likely a good faith edit).

I would suggest dropping the geo-quasi-blocking and narrowing the scope of this new and unwelcome "feature" to only trigger on edits in mainspace that have one or more of the following features:

- Pure deletion of a full paragraph or more and/or over 10% of the page (potential vandalism or whitewashing)

- Removal of a template, such as "needs attention from an expert" or "contains unsourced claims", used to track potentially questionable claims, or of a "[citation needed]" without either replacing it with a citation or the deletion being the whole thing to which "[citation needed]" applied, obviating its need (potential whitewashing or paid POV-pushing)

- Added material contains slurs, or at least a significant percentage of added material consists of slurs (likely shock-value vandalism or far-right POV-pushing)

- Added external link, either as citation or otherwise, to a commercial website that was not already linked from the article (commercial spam)

- Removal of many links (whitewashing)

- Removal of links to fact-checking sites (whitewashing)

- Added material appears to be nonsense, or is not in the same language as the article (e.g. predominantly French on an en.wikipedia.org page, or Chinese on fr.wikipedia.org, etc.) (vandalism and/or disguised ad for SEO)

- Edited article is a biography and terms that are fraught in some way (words that connote strong value judgments, such as "murderer" or "laudatory") have been added or removed (potential whitewashing, vandalism, or POV-pushing)

- Edit is a page move or creation

- Images added/removed (anything can be hidden in there and automation can't see it!)

- Adds enough material to make the article over double its previous length, and the article was not newly created, a stub, or shorter than 20 lines (could be good faith fleshing out, but the exceptions should eliminate most such cases)

- Adds one or more names of prominent, controversial figures (e.g. Elon Musk) to an article that a) is not that person's biography and b) does not already mention them. (potential whitewashing/POV-pushing/SEO)

As well as, maybe, talk page edits that add slurs.

Or, perhaps better: study suspected automated edits from before this odious new policy was introduced and look for patterns. There's sure to be some pattern to any well-resourced automated attack, because there will be someone with deep pockets who is trying to gain something specific from it in some way. But it's a good bet that the vast majority are direct spam, SEO, or whitewashing efforts.

Certainly you can whitelist edits that change very little and do not impact either a fraught word (see above) or a name of a public figure or a business (by adding, removing, or changing any such). I'm sure there might be a vandal out there who will want to do some WeIRd cAPItalIZatIon or replace "some" with "blarglefish" or etc. just for the lulz, but that vandal is probably coming from a small IP range and not using automation, so normal methods like warnings and blocks administered manually and after-the-fact should suffice to deal with such cases. No one with that type of motivation is going to splurge to rent a botnet to have a vast range of IPs to vandalize from and splurge some more on automation. The people who will splurge on these things are the sorts who will want a return on their investment, and they will mention or link to a business (to promote it, directly or via SEO), mention someone's name (their own or a rival), delete one of these, or add, change, or remove fraught words being used to describe that business or person.~2026-23303-64 (talk) 08:46, 23 April 2026 (UTC)

Further to all of this: None of this requires Javascript whatsoever. The flow for not depending on client side scripting is as follows:

- Edit gets sent to server

- Server evaluates edit for suspiciousness according to criteria such as I suggested

- If non-suspicious, server accepts edit and everything seems as before to the end-user; form submission redirect is to reload the article page with the edits now included

- If suspicious, server does not immediately accept edit and form submission redirect is to a captcha page, with a generated image and an input form and a submit button, generated on the server side

- Server evaluates captcha form submission

- If correct, server accepts edit and proceeds as in the non-suspicious case

- If incorrect, server sends new copy of captcha page, with new captcha

This does involve some server-side processing. The only reason I can see for using Javascript instead of something like the above is to offload some or all of that processing onto the client, which has two fatal flaws:

1. It requires trusting the client to mark its own homework -- automated attackers will figure out how to short-circuit your client-side code, substituting their own version that just skips to the "the user correctly solved the captcha" part, or even simpler, changes "is_suspicious = (condition OR other-condition OR...)" to "is_suspicious = false". (I, by the way, know how to do this kind of thing using uBlock Origin custom filters. I won't use that knowledge for evil. But what I know how to do, your adversaries know or can easily find out, and they will.)

2. It requires people to let you run code on their computers, which is invasive.~2026-23303-64 (talk) 08:57, 23 April 2026 (UTC)

Allowing a CAPTCHA without client-side JS was considered and declined in phab:T378194. Wikipedia already has public and private edit filters that check for abusive editing patterns, a few of which trigger the CAPTCHA, but apparently this is not enough to prevent abuse (the details of which probably aren't going to be made public, but what do I know). Helpful Raccoon (talk) 09:28, 23 April 2026 (UTC)

It doesn't need to be enough to prevent abuse, it just needs to be enough to detect automated abuse. Manual moderation scales well vs. manual abuse. And client-side JS gains you nothing*, but gains attackers more attack surface and likely the ability to mod the client to cheat when it's marking its own homework.

• Unless you use it abusively to break into the client's computer and go snooping for known automated abuse toolbinaries or other evidence ... you certainly aren't doing anything like that though ... are you? And even if you are, an attacker can figure out the sandbox escape or RCE you're using, plug the hole, and mod their client to send your exploit-injected code's "all clear" signal back to your server. They'll easily be able to obtain a sample of that code (you sent it to them!) and study it to figure out how it computes your "all clear" signal even if you make it variable by having it computed based on variable things the server sends and/or the current time. They can just remove all the parts that scan their machine and decide whether to send the "all clear" signal and replace them with just setting "send_all_clear" to "true", then put that in their modded client to be triggered a short time after submitting a malicious edit.

Oh, and if you did that your "captcha" will break on normal editors' computers as soon as their browser is patched to lock your poxy JS back in its sandbox where it belongs.

There is nothing you can do with client-side JS that a modded client can't spoof. Whether it escapes the browser sandbox or not. Whether it bootstraps other kinds of executable code or not after doing so. Whatever exactly you put in it, it will do something to decide whether it's in a human-piloted browser or a bot, and then it will combine that verdict with some (or no) information also from the server and send it back. If you encrypt it, the client-side code you're running has to contain the encryption key, and you've handed it to your attacker on a platter. Anything it does to sniff around for bot-sign can be snipped out and replaced with "false" literals. Any test it attempts to put the allegedly human and allegedly present operator to can be snipped out and replaced with "just skip to the conditional branch for if the user answered correctly". Nothing the JS -- or anything bundled with it -- sends back is trustworthy. The only way to make it attack-proof is if the challenge to the user is generated on the server and served to the client already opaque to code, along with a one way hash of the right answer if you don't want to keep state on the server for each not-yet-solved captcha, and the verification that it was the right answer happens on the server again.~2026-23303-64 (talk) 10:12, 23 April 2026 (UTC)

I did some further research. The captcha service you are claiming you now require users to use when editing is a for-profit, non-FOSS product, with the potential to inject arbitrary scripts into Wikipedia articles. If someone breaches them, they can then breach all editors. Perhaps you (well, Wikimedia) will have some recourse via contract law for redress of any damages caused if this happens, or they wreak havoc with a poorly-tested and cack-handed update to their code, but editors will not. We will simply be screwed.

Again, there is no need for a third-party service or even for JS. It's been done before, and it's easy to do it.

1. Server generates a random six (or such) digit number using a crytographically strong PRNG, e.g. 588302

2. Server warps and filters the image to defeat OCR.

3. Server generates a one-way hash of the number and a timestamp, e.g. SHA256:33a21f38823671b827b6393488257e5d2ba5e577a2fa8888d37ad5d66a25f57c

4. Server responds to original form submission with a new form with captcha image, input field, submit button, hidden field with hash, hidden field with timestamp, and hidden fields with all contents of original form submission

5. When server receives a captcha form submission POST, server hashes user input from visible field plus timestamp from hidden field and compares to stored hash in hidden field

6. If match, server processes hidden fields with original form submission and applies edit/logs you in/etc.

7. If mismatch, go back to step 1.

This is time-tested. The client can't mark its own homework unless it can reverse a SHA256 (without the timestamp component, an attacker could enumerate all one million SHA256s of possible inputs, but with the timestamp...). The server doesn't have to keep any state while waiting for the captcha response, so aborted interactions where a user bails on getting a captcha won't slowly consume memory or disk and allow for a denial of service attack. No client side scripting is necessary. The main server side resource suck is the image filtering. But given modern disk storage capacities it's likely feasible to precompute images for all one million six-digit numbers a single time and just serve one of these. (Just don't name the image with 588302 "588302.jpg" or anything like that! Use random filenames, from the same CPRNG, and keep an association table of number to filename on the server, with these files readable only by root, the usergroup trusted to maintain this subsystem, and a small captcha-verification oracle binary that runs sudo that usergroup and that the httpd invokes -- so a code execution vuln in the server still doesn't breach the captcha files without chaining a LPE.)

The best thing about this is that its very simplicity means it exposes minimal attack surface. For mass automated solving you must either reverse a SHA256 or use some kind of super-OCR that probably requires AI, and AI is about to get hella expensive just as soon as price-per-token rises to commensurate with cost-per-token (or the AI companies all go bankrupt, which is what will happen very soon if price-per-token doesn't rise).

It's also not hard to see how to modify this to add machine-generated audio wavs for accessibility, either ginned up on the fly or precomputed.~2026-23303-64 (talk) 09:52, 23 April 2026 (UTC)

Hmm, the stateless version has a potential attack by manually solving one captcha, capturing the form being POSTed, and then responding to subsequent captcha forms automatically with the hidden timestamp and hash fields, as well as the input field, filled in from the captured form and the remaining hidden fields unaltered. However there is an obvious mitigation -- reject if the timestamp hidden field is too far in the past (e.g. five minutes) -- and an obvious complete fix -- include the edit itself (or login/pass, etc.) into the hash, both when generating and when verifying it. The latter limits a replay attack to an exact replay, so, changing the article to the same content again and again, which is idempotent, giving no gain to the attacker above making the edit, with manual captcha solve, once. Every distinct edit requires a new manual captcha solve. (What, mass page blankings/replacement wholesale with an ad? Include the article URL into the hash as well, and in a hidden field in the captcha form for the verifier to see...you need it again anyway to know which page to apply the edit to.)~2026-23303-64 (talk) 10:24, 23 April 2026 (UTC)

Client-side JS is used to detect human-specific behaviors to process server-side, which are possible to emulate but not as simple as "return the all-clear signal". OCR programs have been able to handle warping and filtering for many years at this point even before LLMs. In fact, the Wikimedia Foundation switched away from a simpler image-based CAPTCHA due to ineffectiveness and low accessibility. I recommend reading the Wikimedia Foundation's announcement and mw:Product Safety and Integrity/Anti-abuse signals/hCaptcha. Helpful Raccoon (talk) 23:24, 23 April 2026 (UTC)

That is, again, trivial to defeat. You can just prerecord some of these "human-specific behaviors" and have your bot send a copy of the recording back with every POST. The only way you can detect this is to keep a record of every such on the server (or a hash of same, sufficiently long as to make a happenstance collision astronomically unlikely) forever so that you can detect duplicates. That takes serious storage space. It might be workable for some smaller site, like a blog wanting to allow comments without a login but needing to block spambots, but Wikipedia receives literally millions of edits daily. To avoid false positives would require a hash table that can store *trillions* of these recordings, so that the actual tens of billions that will be generated in the next N years for a reasonably large N won't have any collisions. Assuming a decently strong hash like SHA256 that's a petabyte on the spot. There is also the need for the "human-specific behaviors" you are monitoring (which sounds like creepy surveillance from where I'm sitting) to be very unlikely to themselves be duplicated by normal users doing normal editing. That means monitoring them for a sufficiently long time, each time, while giving them a sufficiently complex captcha task. Making the captcha task more complex impacts accessibility negatively and monitoring for longer times ups the creepy-surveillance factor. Both slow down the user's workflow and increase annoyance, also. The longer sequences of monitoring data then increase bandwidth requirements. What happens to users still on DSL or, God forbid, dial-up?! Will they be sitting for literal minutes watching their browser throbber waiting for a response after submitting their captcha answer? Intolerable. At your end the significant jump in bandwidth is going to cost actual money, as will the petabyte of added storage.

And when all of that is said and done, attackers will proceed to trivially defeat it by creating a database of a few thousand recordings of your "human-specific behaviors" from genuine humans and then coding up a bot that frankensteins random pieces of these recordings together into a unique new response for every captcha. The only way to defeat that is to go beyond "is human-like signal" and "is not a duplicate" and start fingerprinting individual humans, requiring accounts, and using the fingerprints to prove the account signup and a subsequent edit while logged in as that account is the same person, and also to detect sockpuppets. And at that point you're so far into creepy-surveillance territory that Peter Thiel will be ringing you up and offering you zillions to buy out your patents for Palantir.

To reiterate:

There is nothing you can do with client-side JS that a modded client can't spoof. Nothing the JS -- or anything bundled with it -- sends back is trustworthy. In the end, the only way you can actually be sure a live human is submitting an edit is if there's a camera in their room that you control and they cannot tamper with. Which is literally 1984. Short of that, you generate a novel challenge a bot can't solve without human assistance on the server, and verify the user solved it on the server again. Aka a plain old ordinary no-JS-required captcha.~2026-23303-64 (talk) 03:43, 24 April 2026 (UTC)

• It seems these issues are being considered in phab:T422222, interested contributors may subscribe and comment there. — xaosflux ^Talk 11:58, 16 April 2026 (UTC)

You asked how many people have the ability to create or edit scripts that might be run on the machines of any editors. They can actually also make JavaScript run for readers. The English Wikipedia currently has 14 (list) interface administrators who can edit sitewide JavaScript. Two of them are bots run by two of the 12 human accounts. There are also users with global rights for all Wikimedia wikis. Many of them work for the Wikimedia Foundation which runs Wikipedia. Some JavaScript like CAPTCHA is part of the MediaWiki software we use. There is an approval process for making changes to it. PrimeHunter (talk) 12:13, 16 April 2026 (UTC)

I certainly understand the sentiment. I can currently generally edit as a TA with a scriptless-captcha being provided (I see it now and if this post does not make it I won't bother). It's not only the site's own official scripts, but also every gadget one depends on that could suddenly change, meaning that you'd at least require a tool to track changes and audit+whitelist them, adding a burden. I could fortunately read and edit WP without scripts since ~2005. On the other hand, it's already an annoyance that the default skin needs custom local scripts to look decent. ~2026-10830-00 (talk) 22:46, 20 April 2026 (UTC)

"I certainly understand the sentiment. I can currently generally edit as a TA with a scriptless-captcha being provided"

Why can you, but not I? The nationality-based discrimination someone alluded to earlier?~2026-23303-64 (talk) 03:50, 24 April 2026 (UTC)

My understanding of the above is an address range specific limitation due to persistent recent enough abuse from it, more a technical measure than discrimination. ~2026-10830-00 (talk) 06:03, 26 April 2026 (UTC)

Interesting distinction. And one without (so far as I can see) a difference.~2026-23303-64 (talk) 01:44, 27 April 2026 (UTC)

Implementation of pretty much exactly what I've been suggesting, along with independent reiteration of exactly what I've been saying:

https://medium.com/@EDBCBlog/surviving-the-shadows-creating-a-captchat-without-javascript-1bdda8435fc3

~2026-23303-64 (talk) 04:32, 25 April 2026 (UTC)

I've implemented some myself in the past, they could require updates to better cope with today's more fancy character/image recognition though. But when typing this, I'm offered a captcha by the mediawiki software that does work without scripts. ~2026-10830-00 (talk) 06:03, 26 April 2026 (UTC)

That is as it should be. I am not objecting to the captcha. I'm objecting to invasive scripts that, per their own admission, do some kind of fingerprinting and behavioral profiling, and which moreover come from outside the peer-reviewed, FOSS, trustworthy code ecosystem. Fact is anyone could buy out this "hCaptcha" business tomorrow and quietly add (more overtly) malicious functionality to their scripts.

It's one thing if Wikimedia uses third-party proprietary code (or hardware, or etc.) internally where it could some day bite them in the butt. (And even that potentially exposes the association between user accounts or particular edits with IPs, which Wikimedia seems to want to take pains to keep as confidential as possible otherwise.) It's quite another if they start demanding that everyone who wants to contribute so much as a typo fix also must trust that third-party proprietary code. That's a bridge too far and goes against the long-standing spirit of the entire project.~2026-23303-64 (talk) 01:41, 27 April 2026 (UTC)

It occurs to me also that this new policy also creates a new pressure point, increasing Wikipedia's attack surface vis-a-vis far-right governments and similar threat actors. Every OTA-updatable or, especially, cloud-based third-party proprietary widget that's used server-side or client-side is a potential pressure point, hCaptcha included.

What happens if, say, Trump leans on hCaptcha ("nice business you have there, it would be a shame if it lost profitability due to some new tariff or if ICE raided it or the IRS kept auditing it ... and all those H1B visas, my voting base would love it if those suddenly got revoked!") to refuse service to (or even actively sabotage) Wikipedia until Wikipedia removed unfavorable facts about Trump from his bio? Or similarly? Wikimedia would have to either cave (and game over: credibility forever lost, Wikipedia becomes the next archive.ph) or else quickly pivot to an in-house nonproprietary solution anyway. Might as well get ahead of the ball and do that now. (It can be third-party, as long as Wikimedia can host a copy internally that runs independently of its original vendor. But nothing that is remotely killswitchable or cloud-hosted.)

In these turbulent political times it behooves Wikimedia to shrink its "political attack surface" to the bare minimum that's possible, which means rooting out all proprietary network-facing code (could have backdoors), all over-the-air updatable stuff (or disabling the auto-updates at minimum), and all cloud dependencies feasible (but cloud hosting of its own data is likely being used and may not be feasible to move from). Reducing that attack surface to zero might be impractical but the smaller it is the more resilient we are to political attacks of that sort.~2026-23303-64 (talk) 01:58, 27 April 2026 (UTC)

Hi there, is there a way to search for a specific piped link on Wikipedia?

I just made the new article Oxford History of Music (OHM). This was previously a redirect to a small section in the Oxford History of Western Music (OHWM). But instead of articles having a red link no link or the redirect, most mentions I've found simply link to the OHWM with a piped link.

So basically, can I search somewhere for instances of the following?

• [[Oxford History of Western Music|Oxford History of Music]]
• [[Oxford History of Western Music#Oxford History of Music|Oxford History of Music]]

Thanks in advanced – Aza24 (talk) 18:41, 24 April 2026 (UTC)

@Aza24: There are no hits on linksto:"Oxford History of Western Music" insource:"Oxford History of Western Music Oxford History of Music". Maybe linksto:"Oxford History of Western Music" insource:"Oxford History of Music" is of interest. See more at Help:Searching#Parameters. PrimeHunter (talk) 19:40, 24 April 2026 (UTC)

This search finds eight such wikilinks.

—Trappist the monk (talk) 20:02, 24 April 2026 (UTC)

Thank you both! All helpful since I intend to create a stand alone New Oxford History of Music article at some point. Best – Aza24 (talk) 20:42, 24 April 2026 (UTC)

Aza24, this search is essentially the same as Trappist's, but it bolds the whole piped link so it's easier on the eye, and also sorts the results alphabetically. Mathglot (talk) 05:18, 27 April 2026 (UTC)

Could someone check if an old version of the 2026 White House Correspondents' dinner shooting article appears on the Wikipedia mobile app? I am using the Wikipedia app on a Samsung Galaxy S20 and the version of that article that comes up looks extremely outdated from what's on the main site. I tried purging the article and restarting the app but it didn't help. -- Veggies (talk) 21:12, 26 April 2026 (UTC)

It's up to date for me. But the mobile app sometimes seems to get its on-device cache stuck. Generally won't last more than a few hours though. —TheDJ (talk • contribs) 09:28, 27 April 2026 (UTC)

How can I remove the Open Street Map from Trinity (nuclear test)? Hawkeye7 (discuss) 00:44, 25 April 2026 (UTC)

@Hawkeye7 It's the | locmapin = New Mexico#USA line in {{Infobox NRHP}}. --Ahecht (TALK
PAGE) 14:54, 27 April 2026 (UTC)

That map is fine. It is the unwanted Open Street Map in the {{Infobox nuclear weapons test}} template that is the problem. I've suppressed it with |mapframe=no but it should be off by default. I don't know why we allow Open Street Map on Wikipedia at all. All it is giving us is a world map showing the location of the United States. If you zoom in enough, there will be streets that were not there in 1945. (But on the other hand, looking at my own neighbourhood shows unnamed and unmarked streets.) It seems to be a violation of WP:USERGENERATED. Hawkeye7 (discuss) 18:52, 27 April 2026 (UTC)

(Not to mention the in-image copyright credits, which we don't tolerate there (WP:WATERMARK) or in the caption (MOS:CREDITS) from anyone else remotely comparable. —Cryptic 23:38, 27 April 2026 (UTC))

MediaWiki message delivery 18:04, 27 April 2026 (UTC)

That first bullet about autoconfirmed users is a pretty significant shift in how things work. I wonder if a wider distribution beyond just WP:VPT would be wise. --Ahecht (TALK
PAGE) 20:42, 27 April 2026 (UTC)

I'll be surprised if the change has much of any significant effect. Working around the change seems pretty trivial. Anomie⚔ 00:44, 28 April 2026 (UTC)

Will this affect how extended confirmed is granted too? Nardog (talk) 08:02, 28 April 2026 (UTC)

From reading phab:T418484, I don't think so, because autoconfirmed and extended confirmed actually work completely different in the software. IIUC, "autoconfirmed" isn't actually a user group you can be assigned to, it's just something the software checks on every page read: "is your account older than X days, and have you made more than X edits?" And the "older than X days" will now count from first edit instead of from account creation. Extended confirmed, however, uses the "AutopromoteOnce" mechanism, which actually causes your account to gain an additional user right. That's why it shows up in the user rights log, and why it can be revoked and re-granted by admins.

It is technically possible to also use time since first edit for extended confirmed, and it looks the Indonesian and Japanese wikis have that configuration. --rchard2scout (talk) 08:39, 28 April 2026 (UTC)

Why MonoBook skin I had set up on each language Wikipedia recently changed to Vektor especially in non-Latin languages? I had to restore it to MonoBook. Eurohunter (talk) 20:50, 27 April 2026 (UTC)

@Eurohunter: Have you set MonoBook at Special:GlobalPreferences#mw-prefsection-rendering? PrimeHunter (talk) 21:05, 27 April 2026 (UTC)

@PrimeHunter: I did not change anything recently there and it is set at MonoBook beside settings are greyed out. Eurohunter (talk) 21:08, 27 April 2026 (UTC)

@Eurohunter: I don't know why something changed for you but if the skins are greyed out and you want MonoBook everyhwere unless you make a local exception then enable the square under "Skin", select MonoBook and Save. PrimeHunter (talk) 21:16, 27 April 2026 (UTC)

@PrimeHunter: I did now, but it's still interesting what actually happened. Eurohunter (talk) 21:58, 27 April 2026 (UTC)

Probably because some WMF busybody decided that "oh noes slightly large database tables" was more important than users. Anomie⚔ 00:47, 28 April 2026 (UTC)

@Eurohunter: This was announced some months ago, see Wikipedia:Village pump (technical)/Archive 225#Tech News: 2025-43, first bullet. --Redrose64 🌹 (talk) 07:01, 28 April 2026 (UTC)

@Redrose64: @Anomie: Good to know, but it has anything to do with central login? Eurohunter (talk) 09:59, 28 April 2026 (UTC)

@Eurohunter: You didn't name the affected wikis but phab:T406724#11293209 indicates preferences at a specific wiki may be deleted if you haven't logged in there for five years. Does that sound like what happened? Special:CentralAuth/Eurohunter shows hundreds of accounts older than five years but doesn't say when you last did something. If you set something at Special:GlobalPreferences then I assume it remains in effect at all wikis. PrimeHunter (talk) 13:10, 28 April 2026 (UTC)

@PrimeHunter: It's impossible that I did not log in to some versions of Wikipedia for more than 4 years. I'm sure I was log in with central login and visit these Wikipedia versions while login. Eurohunter (talk) 13:51, 28 April 2026 (UTC)

I don't know whether a visit counts if you logged in elsewhere. PrimeHunter (talk) 17:07, 28 April 2026 (UTC)

Wikipedia needs a better search engine. I typed in a song I remembered from the 60s: "Cause That's the Way Boys Are" by Leslie Gore. My memory of the title is incorrect. The word "Cause" is not part of the title. My search for the incorrect title produced 500 hits, none of which was the song or Leslie Gore. I then asked Google why Wikipedia's search engine is not as good as Google's. Google explained that Wikipedia's search engine is more literal, etc., etc. Google suggested placing the word "Wikipedia" in front of a Google search term for better results. And lo and behold I found the song and Leslie Gore in Wikipedia in the search results. Ifyoucrydon'tlose (talk) 10:18, 28 April 2026 (UTC)

WMF wants to improve searching on Wikipedia, see e.g. mw:Readers/Information Retrieval or Semantic search: making it easier to find the information readers want. Johannnes89 (talk) 13:11, 28 April 2026 (UTC)

@Ifyoucrydon'tlose: Wikipedia's search only finds pages containg all the searched words. "cause" does not appear in That's the Way Boys Are. Google can include pages missing a word. They have FAR more resources than us and do some things better, but there are also things we do better (maybe because we only have to search one site). PrimeHunter (talk) 13:20, 28 April 2026 (UTC)

I sometimes use Wikipedia as a search history precisely because it doesn't have as many hallucinations as google. When google acquired Deja News ז״ל, google had options to narrow the search, but they haven't worked in ages. Remember that you are not the customer, you're the product. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:09, 28 April 2026 (UTC)

Wikipedia is the world's largest reference website. It seems to me that a little bit of artificial intelligence in the search algorithm would help the search bar produce much better results. Ifyoucrydon'tlose (talk) 20:13, 28 April 2026 (UTC)

I'm all for improving the search engine, but making it more like google would be a step backwards. Instead, provide syntax for explicitly requesting a fuzzy search. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:16, 28 April 2026 (UTC)

How would making the Wikipedia search engine more like Google be a step backward? Ifyoucrydon'tlose (talk) 10:01, 29 April 2026 (UTC)

I wanted to check whether Clover, Roane County, West Virginia was the only Clover in WV (making the dab Clover, West Virginia unnecessary). I tried a Cirrus search but was surprised to see no results. I repeated this logged out in case my scripts were doing something unhelpful – still no results. A few variants worked but many didn't. Here's what I tried, together with whether each produced the expected results Y or none N.

1. intitle:/Clover.*West Virginia/ prefix:Clover N I expected to see at least both pages linked above
2. intitle:/Clover.*West Virginia/ N so it's not because I messed up the prefix
3. intitle:/Clover[ -z]*West Virginia/ prefix:Clover Y so character sets and repetition work but maybe not .*
4. intitle:/Clover, W.*t Virginia/ prefix:Clover Y so .* sometimes works
5. intitle:/C.* West Virginia/ prefix:Clover Y surely . can't exclude spaces
6. intitle:/C(.| )*West Virginia/ prefix:Clover N not so simple
7. intitle:/C(.| )*West Virginia/ without the prefix: returns Crystal Lake (West Virginia) but no Clover results

mw:Help:CirrusSearch says that Regular expression searches are supported for intitle and The dot . metacharacter stands for any character, and I've used both successfully many times.

These features have been working perfectly for years so I suspect I'm making a really basic error. Please, what am I doing wrong? If what I'm doing looks right, can anyone else reproduce or explain these results? Certes (talk) 20:24, 26 April 2026 (UTC)

It seems that intitle:/Clover.* West Virginia/ prefix:Clover works, while intitle:/Clover.*West Virginia/ prefix:Clover doesn't. Some other character sets like intitle:/Clover[^<]*West Virginia/ prefix:Clover also work. Seems like a bug in the search. Anomie⚔ 23:07, 26 April 2026 (UTC)

Let's ping @GLederrey (WMF) from Search Platform Team Maybe they can tell what's going on. Ponor (talk) 04:24, 27 April 2026 (UTC)

This gets you what you want (no comment why the others don't):

intitle:/^Clover,/ intitle:/West Virginia$/

Mathglot (talk) 04:36, 27 April 2026 (UTC)

More like yours: even jamming up the dot against the Clover works without blank before West, if you give it a long-enough repetition: might be a clue:

intitle:/Clover.{1,20}West Virginia/

the star will also match newline, so maybe it goes too far and gets lost, without the end-rep limit? Mathglot (talk) 04:44, 27 April 2026 (UTC)

Thanks, everyone. I'd be surprised to see a bug in such a widely used feature (but relieved that I'm not being totally stupid here). You've added several useful workarounds, but I can still see other people who've not read this thread trying the naive syntax I used and going away with a mistaken impression that the pages they're seeking don't exist. I suspect Mathglot may be right that CirrusSearch (or even OpenSearch) doesn't backtrack .* in exactly the way we'd expect. However, I just tried using .*? in the hope of doing less backtracking; this misbehaves just like .* (though perhaps more efficiently). Certes (talk) 08:29, 27 April 2026 (UTC)

One more clue: intitle:/Clover.*West / prefix:Clover works (with or without the space after West) but intitle:/Clover.*West V/ prefix:Clover doesn't. (Adding ^ has no effect; nor does removing prefix: other than to make the search noticeably slower.) Certes (talk) 08:36, 27 April 2026 (UTC)

I could be wrong, but I seem to remember that star is always greedy and *? doesn't do what we PCRErs^{[pronunciation needed]} might expect. Can't find that at mw:Help:CirrusSearch#Regular expression searches (one irrelevant occ. of greedy on the page), so maybe I was dreaming? Otoh, no occ's of *? either, so maybe it was a lucid dream? Mathglot (talk) 18:05, 27 April 2026 (UTC)

intitle:/Clover.*? West Virginia/ prefix:Clover (space before W) works, so I think *? behaves like in PCRE even if it's not a documented feature. But we can replicate the unexpected behaviour without using ?, so that's not the problem. It's certainly not trying to match a literal "?", as might be expected if non-greedy search were not implemented. Certes (talk) 19:46, 27 April 2026 (UTC)

At this point it's probably just throwing stuff against the wall to find something surprising that might be a clue, so nothing dramatic here, but compare these:

1. intitle:/Clover.*\s+West Virginia/ prefix:Clover 6 results
2. intitle:/Clover.*\s*West Virginia/ prefix:Clover 0 results
3. intitle:/Clover.*\s*\sWest Virginia/ prefix:Clover 6 results
4. intitle:/Clover.*\s*\s*West Virginia/ prefix:Clover 0 results
5. intitle:/Clover.*\s*\s+West Virginia/ prefix:Clover 6 results

It seems to want an unstarred space before the W, so not surprised anymore that #2 and #4 fail, but no clue as to why. I wish I could see the um, pattern here, but I can't and every new result prompts two new questions I want to try out and I'm running out of wheat. Anything jump out at you here? I think I'm going to have to stop and wait for the experts. Mathglot (talk) 03:03, 28 April 2026 (UTC)

Let's try @EBernhardson (WMF) this time. Ponor (talk) 03:20, 28 April 2026 (UTC)

Digression: Greedy and non-greedy search give the same binary pass/fail result. Cirrus is thus free to interpret .* (and .*?) as greedy or non-greedy, whichever is likely to be more efficient, though I don't know whether it takes advantage of that opportunity. Certes (talk) 09:50, 29 April 2026 (UTC)

I've filed a bug report at phab:T424820. Ponor (talk) 10:34, 29 April 2026 (UTC)

 You are invited to join the discussion at Wikipedia:Village pump (miscellaneous) § Seeking input on editing in the mobile apps. Sdkb‑WMF ^talk 17:08, 29 April 2026 (UTC)

Do any sysadmins watch this page? Why do I encounter this error when trying to view files from my home IP? sapphaline (talk) 22:21, 27 April 2026 (UTC)

retry-after is 600 sapphaline (talk) 22:23, 27 April 2026 (UTC)

Probably related to how WMF is trying to roll out rate limits on requests to combat AI scrapers, and people keep screwing it up and blocking legitimate traffic too. I wouldn't count on the relevant people reading this page; you'd probably do better to file a task in Phabricator. Anomie⚔ 00:52, 28 April 2026 (UTC)

Hi. Sorry to hear that you're being affected by our attempts to reduce the impact of scrapers. Some of these scrapers actively try to evade detection, including widespread use of residential proxy networks, in an effort to make themselves look as indistinguishable as possible from legitimate traffic. If this is still happening, please copy the details on the error page and email them to bot-traffic@wikimedia.org so that we can investigate further. JTweed-WMF (talk) 12:28, 28 April 2026 (UTC)

"including widespread use of residential proxy networks" - my network isn't compromised. The problem solved itself, by the way. sapphaline (talk) 13:50, 28 April 2026 (UTC)

@Sapphaline No one said it was. The implication is that someone who was assigned your IP in the past was also running VPN software that allowed their computer to be used as an exit node. --Ahecht (TALK
PAGE) 13:54, 28 April 2026 (UTC)

I count this as "compromised". sapphaline (talk) 13:55, 28 April 2026 (UTC)

That's great to hear. It certainly wasn't my intent to suggest that your network is compromised. I was using residential proxies as just an example of why it's not easy to clearly separate legitimate traffic from abuse. They're used precisely because they're hard to block without unintentionally impacting real people. JTweed-WMF (talk) 16:31, 28 April 2026 (UTC)

In that case, impacting real people should not be an acceptable loss for these anti-abuse mechanisms. Chaotic Enby (talk · contribs) 16:36, 28 April 2026 (UTC)

The problem is at a scale where doing nothing is not an option. We are trying to do this in a privacy-preserving way, which makes it even harder. The CDN limits, which I believe are the limits that have been hit in this case, are set very high precisely for this reason. Without some further information it's hard for us to know why, but these reports are seen and acted on. We don't want to stop anyone from reading the site. Indeed, we also have a responsibility to protect our infrastructure so that people are able to do so without being impacted by high levels of automated traffic. JTweed-WMF (talk) 16:45, 28 April 2026 (UTC)

Happy to hear more about the issue. Is it possible to have concrete data on how this rise in automated traffic has impacted readers until now? While it is certainly undesirable, I haven't seen any previous reports of it directly affecting readers, which the current mechanism does (e.g. this thread or #Some thing is DDOSing Wikipedia IMAGES). It could also be great to have feedback regarding how these reports are being acted on, to avoid us from providing suggestions based on incomplete information. Chaotic Enby (talk · contribs) 17:20, 28 April 2026 (UTC)

Thanks for the reply, and I hope this can be solved as quickly as possible! In the meantime, until the issue is fixed, it could be helpful to roll back the existing rate limits in order to prevent future readers from encountering these issues. The email you provide is for bot operators to request higher rate limits, and I do not believe that legitimate readers should be required to go through this process just to continue reading. As readers are our priority, if a compromise has to be made, accepting some amount of scraping should be preferable to preventing some readers from accessing Wikipedia. Chaotic Enby (talk · contribs) 15:50, 28 April 2026 (UTC)

@JTweed-WMF: I've also been getting 429 errors randomly for the past few days, mostly on thumbnails I think. Is there another method than email to get the error details to you? Miles Wagner (talk) 22:44, 28 April 2026 (UTC)

This is kind of breaking Media Viewer, where often the desired image appears for a fraction of a second, then is replaced with an unspecific error message ("Sorry, the file cannot be displayed; there seems to be a technical issue (...) could not load image from...) ; clicking the included link for the scaled image version gives the aforementioned error message. -- Seelefant (talk) — Preceding undated comment added 23:06, 28 April 2026 (UTC)

Whenever i visit any page, the image at infobox can't load and the alt text appear. I tried to open that in commons, the preview at top was not available but a small massege appeared: Too many requests, try again.––KEmel49(📝,📋) 07:47, 29 April 2026 (UTC)

Thanks, I'm trying to find out more about this internally. It's related to media limits, rather than the API limits that I am more directly involved with. Sorry for those experiencing issues, we are looking into it. JTweed-WMF (talk) 10:41, 29 April 2026 (UTC)

Hi @KEmel49, @Seelefant and @Miles Wagner. We have had a couple of incidents caused by scrapers putting too much pressure on the images infrastructure. It's very likely that one of the bans or rate limits that was put in place in the past couple of days had an unintended consequences blocking legitimate user traffic too but we can't check which rule is causing it without having more information since the logs is filled with scrapers getting blocked (and pretending to be human traffic). I'd need some more information to narrow it down. So if you can send us any information, it'd help us immensely (your IP for example, the exact error message that would have the hash, the request id which is in the x-request-id header, etc.). You can create a private phabricator ticket or simply send the information to asarabadaniwikimedia.org. Thank you and sorry for this. We are investigating. ASarabadani (WMF) (talk) 12:54, 29 April 2026 (UTC)

Thank you so much and good luck! Chaotic Enby (talk · contribs) 13:04, 29 April 2026 (UTC)

Okay, we made progress and changed some rules to reduce the blocks, it should be better now. ASarabadani (WMF) (talk) 18:06, 29 April 2026 (UTC)

Quite a few templates currently call upon many moving parts, most often indirectly, and it can be hard to keep track of all these parts and appropriately protect them. The best example of this comes from the Template:Taxonomy subtemplates, that call each other in a nested chain so that editing one obscure high-level taxon can directly affect thousands or tens of thousands of pages. Because of that, page protection must be adjusted with each change in taxonomy to avoid vulnerabilities. Cascading template protection provides an elegant solution to this issue: by cascade-protecting a few high-visibility templates, we would not have to keep track of all their call stack for additional protection. This would also allow us to avoid hacks such as using the title blacklist.

We know that cascading semi-protection was a fundamentally flawed idea: it allowed any autoconfirmed user to protect pages by transcluding them, which in the hands of the wrong users could be a recipe for disruption. Template editor is a specialized user right already requiring a high level of trust, meaning there shouldn't be similar risks of it being abused for disruption. Other necessary key differences in the current proposal are:

• That transcluded pages should also be template-protected, instead of being fully protected
• That content transcluded in <includeonly> tags should be protected; and conversely that content in non-transcluded pages (e.g. documentation) shouldn't

Demonstrating some level of preliminary consensus here could be a good first step for the implementation to be worked on, to avoid a chicken-and-egg situation of the implementation needing to be ready to evaluate consensus and vice-versa. Chaotic Enby (talk · contribs) 16:00, 28 April 2026 (UTC)

You cannot cascade protect templates, as it will protect the documentation pages. This is noted at WP:CASCADE. Izno (talk) 16:05, 28 April 2026 (UTC)

Yes, which is exactly why I noted that such an implementation would need to be coded slightly differently to avoid this edge case. Chaotic Enby (talk · contribs) 16:07, 28 April 2026 (UTC)

It would be good to ensure a precis at the beginning of a comment that you are thinking about implementing Something. :)

I think you will find you will have trouble with meeting the requirement of That content transcluded in <includeonly> tags should be protected; and conversely that content in non-transcluded pages (e.g. documentation) shouldn't in the way that wikitext works today. There were discussions when the WMF developed mw:MCR that documentation would be a good use case, but consider phab:T200687 which has some thoughts about transclusion of specific slots.

Also, something about your OP doesn't come across right. Cascade protection, despite its sound, is about protecting one page where other pages are transcluded. Template cascade-protecting Template:Taxonomy won't fix the issue that all of its children aren't protected, even ignoring the documentation issue, because they aren't transcluded on that page. Izno (talk) 16:14, 28 April 2026 (UTC)

I mentioned that this could be a good first step for the implementation to be worked on, as we don't have this ready to activate right now and it would take some technical work.

Regarding Template:Taxonomy, I wasn't thinking of cascade-protecting that literal template, but highly visible subtemplates with many lesser-known parents (such as Template:Taxonomy/Mammalia), which would provide an alternative to protecting every single subtemplate. Sorry for not being clear about it. Chaotic Enby (talk · contribs) 16:34, 28 April 2026 (UTC)

So you're trying to protect the parents of Mammalia? Izno (talk) 16:57, 28 April 2026 (UTC)

In that case, yes. That might have been a bad example since it uses a /skip template, but a better example could be Template:Taxonomy/Tetrapoda, since it means we wouldn't have to separately template-protect the taxonomy templates for Rhipidistia, Tetrapodomorpha, Eotetrapodiformes, Elpistostegalia, Stegocephali, as we run the risk of failing to keep all the protections in sync. Chaotic Enby (talk · contribs) 17:11, 28 April 2026 (UTC)

Speaking of, /skip templates are a good workaround for Template:Taxonomy subtemplates, but they're still a workaround, and having a system that does it automatically and isn't limited to these templates could save a lot of volunteer time. Chaotic Enby (talk · contribs) 17:13, 28 April 2026 (UTC)

It sounds like you're not really clear on what you want. All the talk about taxonomy templates sounds like you actually want TitleBlacklist-style "protect any page under this prefix". Or if what you're worried about is that people keep changing the details of which subtemplates something like Template:Taxonomy/Mammalia transcludes, I suppose you could get it listed on something like Wikipedia:Cascade-protected items, or make a clear specification as to what exactly an adminbot should apply protection to. Due to the way that cascade protection works, something like That content transcluded in <includeonly> tags should be protected; and conversely that content in non-transcluded pages (e.g. documentation) shouldn't is not likely to happen, as it would need new database tables populated with a separate parser pass and so on, just to achieve the same result as Wikipedia:Cascade-protected items. Anomie⚔ 01:57, 29 April 2026 (UTC)

All the talk about taxonomy templates sounds like you actually want TitleBlacklist-style "protect any page under this prefix". Sorry if I wasn't clear enough, that wasn't what I meant. My proposal was to cascade-protect a few visible pages (such as Template:Taxonomy/Mammalia for example) so that all the parents in their call stack are protected without requiring individual work on each page. Listing it at Wikipedia:Cascade-protected items isn't ideal (as it would prevent template editors from editing it), and an adminbot wouldn't solve the problem of redundant edits each time the main template's call stack is updated.

However, that separate functionality can be replicated without separate database tables, specifically by cascade-template-protecting a single page (e.g. Wikipedia:Cascade-template-protected items) and listing any template to be cascade-protected there. Chaotic Enby (talk · contribs) 02:03, 29 April 2026 (UTC)

Hmm. Now that I think about template-protection specifically, I don't think a Wikipedia:Cascade-template-protected items would really work. Technically it would, but editing any cascade-protected page also requires the protect right, meaning with the current rights configuration it would be effectively equivalent to full protection (since only admins have protect). The same restriction would likely apply to your hypothetical new kind of cascading protection too, BTW. Anomie⚔ 02:14, 29 April 2026 (UTC)

If I understand it correctly, that could work better, actually? This way, protecting pages by editing that list would remain limited to admins, while all the listed pages and their call stacks (the page we want to have template-protected) would be template-protected as intended. Hopefully I didn't get them in reverse! Chaotic Enby (talk · contribs) 02:22, 29 April 2026 (UTC)

You didn't understand it correctly. Both the page directly cascade-protected and any pages affected by that cascading protection would require the protect right to edit. It was the fix for the "cascading semi-protection allows anyone to semi-protect by adding a transclusion" problem you mentioned earlier. Anomie⚔ 12:22, 29 April 2026 (UTC)

But that is for the regular cascade-protect, right? I'm talking about a hypothetical cascade template-protect, on the basis that template editors would be trusted enough for that not to be a problem in this specific case. Sorry for the confusion! Chaotic Enby (talk · contribs) 12:27, 29 April 2026 (UTC)

It applies to any level of protection when the protection is cascading. It would also very likely be applied to your hypothetical new different kind of protection, for the same reason it applies to normal cascading protection, assuming WMF agreed to implement it at all. Anomie⚔ 12:48, 29 April 2026 (UTC)

@Chaotic Enby For the most part, isn't this handled by the TemplateProtector bot that regularly protects any templates with more than a certain number of transclusions (250 for semi, 2500 for XC, 5000 for TE)? That would cover any of the templates in the "nested chain", and the only reason it hasn't applied to the Taxonomy templates is that they are specifically excluded in User:MusikBot II/TemplateProtector/config. MusikAnimal added the Taxononmy templates to the skip list "temporarily" in 2021, so it may be time to revisit that. --Ahecht (TALK
PAGE) 14:52, 29 April 2026 (UTC)

This could work (and be a much more elegant alternative), I didn't realize that the bot checked for indirect transclusions! Does it also handle unprotection if some templates change their dependencies (and the latter fall below that number)? Chaotic Enby (talk · contribs) 15:08, 29 April 2026 (UTC)

No, it doesn't handle unprotection, that would still need to go through WP:RFPU. --Ahecht (TALK
PAGE) 19:37, 29 April 2026 (UTC)

Could someone please tell me whether it's feasible to use grep to split the lengthy List of suicides by date (suggested groups: BC, 1-999 AD, 1000-1899, 1900–1999, and 2000+)?

The ideal answer sounds like "check your new sandbox", but "yes, here's the code" would also work. The alternative we're discussing is to use some sort of LLM, but just sorting it and not messing with it seems to be a difficult task. WhatamIdoing (talk) 19:00, 28 April 2026 (UTC)

I only scrolled through the first couple of sections before that page started to cause my iPad to slow down, but yes, if every entry follows the same pattern, then they can be sorted and split into different sections or separate pages using grep and other command line tools that use regular expression matching, or a small script. No LLM necessary, though I suppose this is the sort of task that an LLM could handle without messing up too badly.

If I were doing this, I would first copy the content of the page into a text file for processing on my computer, rather than try to fiddle with the sorting on wiki. There are a couple of scripts to copy a page's content to your clipboard with one click: my copyPageContent, and User:Anne drew/CopyPlainText. ClaudineChionh (she/her · talk · email · global) 22:22, 28 April 2026 (UTC)

Regex could work well? In order of the suggested groups: (.*)\((.*)BC\)(.*)\n, (.*)\(\D*\d{1,3}(| AD)\)(.*)\n, (.*)\(\D*1[0-8]\d\d\)(.*)\n, (.*)\(\D*19\d\d\)(.*)\n, (.*)\(\D*20\d\d\)(.*)\n. Copy the page into Regex101's substitution tool, put all the groups except the one you want to keep in the top field separated by |, and the entry should appear in the bottom field. Chaotic Enby (talk · contribs) 23:04, 28 April 2026 (UTC)

I haven't been able to figure out how to get what I want from this.

Goal: Get a list that just has the "BC" list entries.

Steps to reproduce:

1. Open https://regex101.com/substitution
2. Paste wikitext from part of the article into second box ("Test string")
3. Put all the groups except the one I want to keep (I'm trying to filter out BC first) in the top field separated by | (specifically: (.*)\(\D*\d{1,3}(| AD)\)(.*)\n | (.*)\(\D*1[0-8]\d\d\)(.*)\n | (.*)\(\D*19\d\d\)(.*)\n |(.*)\(\D*20\d\d\)(.*)\n )

Result:

First it complained that the text is too big, so it timed out. When I reduced it to a very small section of the text (see below) it correctly removed one out of five lines, but it should have removed four of the five lines.

Input:

==Confirmed==
===A===
* [[Adrastus (son of Gordias)|Adrastus]] (c. 550s BC), exiled son of [[Gordias#Gordias (Herodotus)|Gordias]], king of [[Phrygia]]
* [[Vibulenus Agrippa]] (36 AD), Roman [[Equites|equestrian]], poison
* [[Ahn Jae-hwan]] (2008), South Korean actor, [[carbon monoxide poisoning]]
* [[Emperor Aizong of Jin|Aizong of Jin]] (1234), Chinese emperor of the [[Jin dynasty (1115–1234)|Jin dynasty]]
* [[Chantal Akerman]] (2015), Belgian film director

Actual result:

== Confirmed ==
=== A ===
* [[Adrastus (son of Gordias)|Adrastus]] (c. 550s BC), exiled son of [[Gordias#Gordias (Herodotus)|Gordias]], king of [[Phrygia]]
* [[Vibulenus Agrippa]] (36 AD), Roman [[equites|equestrian]], poison
* [[Emperor Aizong of Jin|Aizong of Jin]] (1234), Chinese emperor of the [[Jin dynasty (1115–1234)|Jin dynasty]]
* [[Chantal Akerman]] (2015), Belgian film director

Expected result:

== Confirmed ==
=== A ===
* [[Adrastus (son of Gordias)|Adrastus]] (c. 550s BC), exiled son of [[Gordias#Gordias (Herodotus)|Gordias]], king of [[Phrygia]]

WhatamIdoing (talk) 00:53, 29 April 2026 (UTC)

Looks like:

• The regexes should not have spaces between them and the |
• Regex is wonky and \D includes linebreaks even when . doesn't
• Since you're doing it chunk by chunk, there should be a trailing newline at the end of each line (as the code needs a linebreak to remove each time), but that's not a big issue

I'm trying to go for a simpler approach and providing a regex that will eliminate all undesirable entries each time:

1. \n.*\d(| AD)\).* eliminates all non-BC ones
2. \n.*( BC|\d{4})\).* for all except those between 1 AD and 999
3. \n.*( BC|(\D\d{1,3}(| AD))|(19|20)\d\d)\).* for all except those between 1000 and 1899
4. \n.*( BC|(\D\d{1,3}(| AD))|(1{0,8}|20)\d\d)\).* for all except those between 1900 and 1999
5. \n.*( BC|(\D1?\d{1,3}(| AD)))\).* for all those before 2000

Chaotic Enby (talk · contribs) 01:16, 29 April 2026 (UTC)

And it's done! (with some minor modifications to the regexes)

• Draft:List of suicides (BC)
• Draft:List of suicides (1–999 AD)
• Draft:List of suicides (1000–1899)
• Draft:List of suicides (1900–1999)
• Draft:List of suicides (2000–present)

There's still a little bit of cleanup to do (such as a few lines that weren't parsed correctly since they were in a nonstandard format) but that should be relatively easy cleanup! Chaotic Enby (talk · contribs) 03:56, 29 April 2026 (UTC)

Noting that a merge with List of suicides in the 21st century can be considered for the last one. Chaotic Enby (talk · contribs) 03:59, 29 April 2026 (UTC)

Since each item in a wikitext list ends in a newline, personally I'd use a scripting language such as Perl to parse each line, extract out the date with a regexp, and sort the lines. But I don't want to duplicate effort, so if Chaotic Enby is on the case, I'll leave it to them. isaacl (talk) 03:06, 29 April 2026 (UTC)

I tend to fall back to javascript in these cases, since I can paste it into the browser console and have it read the source of the page directly from the edit window. --Ahecht (TALK
PAGE) 14:26, 29 April 2026 (UTC)

Sure; I also considered writing a Lua module, but making it flexible enough to handle future cases and easy enough for a non-Lua programmer to use seemed daunting. (Anyone comfortable with writing the key extraction code would probably be comfortable writing the delimiter parsing and sorting.) isaacl (talk) 17:26, 29 April 2026 (UTC)

AI might have done it in 30 seconds: "Below is a Wikipedia list of article that I want to split into separate articles suggested groups: BC, 1-999 AD, 1000-1899, 1900–1999, and 2000+. Print the new wikitext for each article." -- GreenC 18:03, 29 April 2026 (UTC)

Yes, however, I tried it as a sample with Copilot (as mentioned on the article's talk page), and yes it works very well. However, the input and output size limits precluded doing the entire A-Z in one go, and even done piecemeal (loading the input in batches, and getting the LLM to output in batches) the LLM coughed and sputtered and started to run in circles after a successful and strong start. It's possible that some other AI, or someone with a paid subscription to an AI/LLM, could achieve it. I have the prompt already set up. (Such are the hazards of letting this list-article get so large that no one or thing can deal with it.)   ▶ I am Grorp ◀ 18:40, 29 April 2026 (UTC)

I have Gemini subscription it could without breaking a sweat. The other way is provide sample data and request a script that can parse it. But looks like you already built it with craftmanship, that is best, you learn new things which is invaluable. -- GreenC 02:47, 30 April 2026 (UTC)

Please see Wikipedia:Administrators' noticeboard#Protecting Afghan ethnicity articles WhatamIdoing (talk) 03:17, 30 April 2026 (UTC)

For some reason, every page is currently using visual editor mode, even though I have it turned off. What's causing this? Ten Pound Hammer (they/them) • ^{(What did I screw up now?)} 01:20, 29 April 2026 (UTC)

You can switch editor at edit window.––KEmel49(📝,📋) 07:43, 29 April 2026 (UTC)

@KEmel49:? Where? I don't see the option to do so. Ten Pound Hammer (they/them) • ^{(What did I screw up now?)} 15:33, 29 April 2026 (UTC)

In Special:Preferences#mw-prefsection-editing, I presume you have "Enable the visual editor" turned off? Can you try turning it on, saving, and then selecting "Always give me the source editor" below in "Editing mode"? Not sure if it will help, but hopefully it can be tried at least! Chaotic Enby (talk · contribs) 18:05, 29 April 2026 (UTC)

I don't remember what I clicked on earlier, but visual editor is gone for me now. Ten Pound Hammer (they/them) • ^{(What did I screw up now?)} 02:32, 30 April 2026 (UTC)

Manually editing the URL to say ?action=submit will always give you a non-VE wikitext editor. WhatamIdoing (talk) 07:51, 30 April 2026 (UTC)

I edited the page Abducens nucleus, which shows a conflicting parameter error in the preview in source mode and is therefore placed in the appropriate maintenance category. However, there is no width2 parameter like the error says there is. Only width. Both visual and source mode say there is no width2, and purging and bypassing the cache did not work. I was on Google Chrome version 147.0.7727.55, and updating to version 147.0.7727.117 did not help either. The error also incorrectly shows in Edge version 146.0.3856.109. Please help. Thanks. BlaqWiedow (talk) 16:24, 24 April 2026 (UTC)

I decided to look at the next article in that category. And then the next one. And the one after that. They all have the same issue. I'm starting to think this is why there are 100+ articles in the category as opposed to <10 for most of the others. BlaqWiedow (talk) 16:39, 24 April 2026 (UTC)

@BlaqWiedow It's Template:Infobox brain that's using both. I'm not sure why those are conflicting parameters, it seems like you'd never use width2 without also using width. Pinging Zackmann08, who implemented the check in this diff. --Ahecht (TALK
PAGE) 18:17, 24 April 2026 (UTC)

@BlaqWiedow, @Zackmann08 Looking at it further, it seems the conflicting parameters check was done by a script, and that script doesn't properly account for cases like this where the infobox uses width2 for the second image but falls back to using width for both if the second one isn't specified. I'll modify it so that those aren't seen as conflicting, but feel free to revert if this assessment isn't correct. In the future, that script may need a little more work. --Ahecht (TALK
PAGE) 18:20, 24 April 2026 (UTC)

@Ahecht Thank you for responding! The issue appears to be fixed, since I don't see the error anymore when I go into source mode. That bug looks like it was responsible for populating the entire category, since that is now empty. BlaqWiedow (talk) 22:24, 24 April 2026 (UTC)

Sorry, been offline all day... Playing catchup. Sorry for my error! Can someone confirm it is fixed? If not I will address.... Zackmann (^{Talk to me}/_{What I been doing}) 02:33, 25 April 2026 (UTC)

The issue was fixed in Special:Diff/1350899381. —⁠andrybak (talk) 10:46, 30 April 2026 (UTC)

Template:Tree list has been broken for quite a while now and previous attempts at getting help fixing it haven't succeeded so I'm going here. The problem is that the template breaks in a very visible way when used for lists that exceed a certain length. This can be seen on multiple mainspace articles (such as Semitic languages#Detailed list and 2026 Iran war order of battle) and there doesn't seem to be any way for users to fix this. There is more information, including some technical details, on the template's talk page. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 12:38, 27 April 2026 (UTC)

This template uses images to draw lines. These image can only be so long. Move the template away from relying on images to draw lines. —TheDJ (talk • contribs) 15:05, 27 April 2026 (UTC)

Yes, I know the template uses images to draw lines. Yes, moving the template away from relying on images to draw lines is a solution. I am here because I don't know how to do that. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 15:25, 27 April 2026 (UTC)

"I am here because I don't know how to do that." - CSS. sapphaline (talk) 22:05, 27 April 2026 (UTC)

Yes, that is what I do not have sufficient experience in to solve this myself (except for a brute force method that might be what we end up doing, but considering someone with actual CSS experience tried to do a CSS fix of this before and couldn't get it to work I didn't exactly feel like trying my luck at it). ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 22:34, 27 April 2026 (UTC)

This is Template talk:Tree list#A problem with long Tree list, Template talk:Tree list#Template only extends down to 145 entries? and Template talk:Tree list#The issue with long lists. At least one of those should have been linked in Maltazarian's original post. --Redrose64 🌹 (talk) 20:45, 27 April 2026 (UTC)

I linked the template and said there is more information on the talk page but alright. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 20:56, 27 April 2026 (UTC)

It uses images hosted on commons to draw the lines??? I'll take a look to see if I can remove the references to images from the css entirely in the sandbox version, no promises though. I can't figure it out, seems like there's an issue with the way it handles child branches (specifically I think the {{Tree list/branching}} use case might be part of the issue). If there's a way we could support something like the forest library of LaTeX it might be easier, but getting that supported might be even more trouble. ScrubbedFalcon (talk) 22:32, 27 April 2026 (UTC)

Another option is SD0001's mw:Extension:Scribunto/Lua_reference_manual#SVG_library. Snævar (talk) 23:00, 28 April 2026 (UTC)

Yet another option is doing something similar to Module:Outdent, which uses CSS borders to draw long-ish lines. —⁠andrybak (talk) 10:35, 30 April 2026 (UTC)

The outdent module works because it is given an argument telling it how far to outdent and I suspect that most editors won't count the number of lines in lists this long. What might work is a Lua module that counts the number of list entries and generates a line based on that length. The problem is that would probably require altering all of the existing {{tree list}} transculsions because of the way that modules are invoked within templates. As I understand it, #invoke: only works within the template and the current syntax of of the template calls for {{tree list}} list content here {{tree list/end}} so the module would only be invoked within the template and wouldn't actually parse the list that comes after it. We would need to replace all of the iterations with something more like {{tree list|* item one **item two}} which is far less intuitive and clear when editing. ScrubbedFalcon (talk) 11:55, 30 April 2026 (UTC)

So the syntax would end up being something more like that of {{Tree chart}} and its module. ScrubbedFalcon (talk) 11:57, 30 April 2026 (UTC)

Note that a solution is being worked on and discussed at Template talk:Tree list#The issue with long lists.

@Ahecht has been working on a CSS solution and for the most part has got it working, and is currently working out some details.
⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 15:18, 30 April 2026 (UTC)

Is there a way to have global skin CSS/JS pages? I have a modern.js on Meta, but that isn't applying here. How do I make it apply on all wikis? TheAuroraBorealis (u/t/c) 21:33, 29 April 2026 (UTC)

@TheAuroraBorealis: There are no skin-specific global CSS/JS pages but you can test for the skin with something like this in meta:Special:MyPage/global.js:

mw.loader.using("mediawiki.user", function() {
  if ( mw.user.options.get('skin') == 'modern') {
    mw.loader.load('//en.wikipedia.org/w/index.php?title=User:TheAuroraBorealis/modern.js&action=raw&ctype=text/javascript');
  }
});

PrimeHunter (talk) 21:59, 29 April 2026 (UTC)

Thank you @PrimeHunter! I ended up doing this instead. TheAuroraBorealis (u/t/c) 22:02, 29 April 2026 (UTC)

Is there any way to do this for CSS though? TheAuroraBorealis (u/t/c) 14:54, 30 April 2026 (UTC)

Could be, but header is not an element used in Modern skin. Izno (talk) 16:36, 30 April 2026 (UTC)

It's used in the contribs page and causes a layout issue, which is why I wrote that script. TheAuroraBorealis (u/t/c) 16:52, 30 April 2026 (UTC)

Ctrl + U in Firefox finds no element named header, nor does Firefox console in my contribs page running querySelector as in your script. Please verify that the cause of your issue is not related to a gadget that doesn't properly support Modern by checking in safemode. Izno (talk) 16:59, 30 April 2026 (UTC)

Nope, does it in safe mode, but doesn't with my script. TheAuroraBorealis (u/t/c) 17:03, 30 April 2026 (UTC)

Sorry if I wasn't clear. I meant a separate CSS page like modern.css but global, not re-implementing my userscript in CSS. Apologies for the confusion. TheAuroraBorealis (u/t/c) 17:04, 30 April 2026 (UTC)

This use-case is documented on mediawiki.org. Legoktm (talk) 17:10, 30 April 2026 (UTC)

User talk:King Logo is protected, yet when I pressed "add topic", then I somehow edited it. How did that bypass the full protection of the page? User97104 (t•c•r) 21:12, 29 April 2026 (UTC)

It's not protected. Presumably the protection that had been applied in 2007 was automatically removed when the page was deleted later that year. Anomie⚔ 22:44, 29 April 2026 (UTC)

Yes, that's correct. Graham87 (talk) 02:59, 30 April 2026 (UTC)

@User97104 and Anomie: When a page is deleted, all protection is lifted at the same time. If create protection is desired, that must be carried out as a separate action. If the deleted page is subsequently undeleted, any create protection is removed at the same time, but previous protections are not restored. --Redrose64 🌹 (talk) 17:57, 30 April 2026 (UTC)

Both infobox images and thumbnails are showing up as unusually small on Vector mobile after the regular Thursday update. Is this intentional? — Goszei (talk) 23:59, 30 April 2026 (UTC)

Resolved

At the top of the article: Cite error: There are <ref> tags on this page without content in them (see the help page).

Same error exists in revisions going back at least two weeks, but it wasn't present when those revisions were current (obviously, as the page gets lots of editor attention). This suggests the problem is external to the article. ―Mandruss ☎ 2¢. IMO. 02:17, 1 May 2026 (UTC)

Same error exists in current revisions of most Trump-related articles, suggesting the culprit is something Trump-related that they all have in common, such as a particular template call. ―Mandruss ☎ 2¢. IMO. 02:27, 1 May 2026 (UTC)

Errors are now gone without explanation. Possible never mind. ―Mandruss ☎ 2¢. IMO. 02:35, 1 May 2026 (UTC)

It appears there were stray <ref></ref> tags at Template:Donald Trump series, which has now been fixed by Keivan.f here. 45dogs (they/them) (talk page) (contributions) 02:48, 1 May 2026 (UTC)

Thank you. ―Mandruss ☎ 2¢. IMO. 02:58, 1 May 2026 (UTC)

Hi, I put this script on my common.js, and did not see any change on the recent changes page. Is it effective? Thank you, _Dgw|Talk 00:39, 1 May 2026 (UTC)

Add &action=purge at the end of url of recent changes page to purge the page, this might help you.––KEmel49(📝,📋) 06:48, 1 May 2026 (UTC)

@Dorian Gray Wild You can just use the original Twinkle here instead of importing a fork from Meta; see Wikipedia:Twinkle § Quick info. If not, what changes were you expecting to see on the recent changes page? AFAIK, it doesn't add buttons there unless you modify your preferences here: meta:User:Xiplus/TwinkleGlobal/Preferences ("Show "Vandalism rollback" link"). Note that preferences won't show up unless you import the script on metawiki or globally. — DVRTed (Talk) 07:22, 1 May 2026 (UTC)

Thank you a lot, I fixed the buttons. _Dgw|Talk 16:47, 1 May 2026 (UTC)

I import a lot of files to Commons, and (because I'm an enwiki admin) the import process has an option to automatically delete files in my name. However, lately this has been giving me an error message: "The file could not be deleted automatically on en.wikipedia.org. Please return to the original file and delete it manually."

This happens regardless of whether I change the filename during importing, and regardless of whether I'm using Firefox or Chrome. How might this be fixed? Thanks. DS (talk) 17:01, 30 April 2026 (UTC)

phab:T423076 * Pppery * _{it has begun...} 17:02, 1 May 2026 (UTC)

I am trying to mediate a dispute at DRN, in particular at Wikipedia:Dispute_resolution_noticeboard#Pakistan , which may be actually about the behavior of Visual Editor. So I have one personnel question and some technical questions. The personnel question is:

• Is there an editor here who is technically knowledgeable about the Visual Editor and can assist in mediating a dispute at DRN (or take over mediation)?

The technical questions are:

• Does a small edit with the Visual Editor sometimes cause the reformatting of the page, causing a large change in the number of bytes?
• Does the Visual Editor add whitespace to citations?
• Can edits with the Visual Editor be sectioned, or do all Visual Editor edits replace the entire page?

Robert McClenon (talk) 05:56, 29 April 2026 (UTC)

I see this back and forth (way too) often: a user script adds its own infobox indentation (Special:Diff/1340948855) then someone edits in VisualEditor, which applies some other indentation, according to the TemplateData setting it found for the infobox (this is my mobile test edit Special:Diff/1351662292, where I only added the height value). Some of this could be avoided if people agreed on the template default indentation and applied it consistently. People should not revert other people's edits and accuse them of any wrongdoing just because an automated tool reformated a page. Ponor (talk) 11:02, 29 April 2026 (UTC)

I will stay away from the dispute, but I can answer the technical questions.

• Yes, but the reformatting changes are normally limited to the elements of the page that the person has edited.

  For example, if you change a template parameter, then the whitespace in the template will be reformatted; if you change the text of a paragraph, then markup like [[...]] and ''' may be tweaked in that paragraph. If the entire page is reformatted, that means that VisualEditor has not been able to keep track of which parts of the page were touched; for example, it could happen if you cut-and-paste the whole article into your sandbox and then back during your edit.

  On the Pakistan page, it looks like making any edit to a citation causes all citations to be reformatted. I'm not sure if this is a bug or expected behavior, but it probably happens because the article uses list-defined references.

• The visual editor will add or remove whitespace in citations that were edited (see previous point) according to their TemplateData, same as in Ponor's example with the infobox.

  For example, the definition for Template:Cite book is here: with a custom format {{_ |_=_}}, which indicates that there should be 1 space before the | introducing a template parameter, and no spaces otherwise. Other tools should ideally respect TemplateData as well. And, while we can't expect people to mechanistically follow that exact style, they shouldn't complain when the tools do (or they should start a discussion to change that custom format).

• Not really.

  VisualEditor has a mode where it only opens one section of the page for editing (it's enabled on the mobile site), but even in that mode, changes can happen in other sections of the page (e.g. if a citation from another section is reused in the section you open, you can still edit that citation, unlike in wikitext editor).

Matma Rex talk 12:21, 29 April 2026 (UTC)

I believe it would be more accurate to say that |reformatting changes are normally limited to the elements of the page that the person has "interacted with", which I believe can sometimes include something as small as opening a dialog box for a template and clicking on something. But this kind of wholesale adjustment of templates is very unusual, and it makes me wonder whether there is something odd about the page. WhatamIdoing (talk) 08:04, 30 April 2026 (UTC)

@Robert McClenon: I did some testing in my sandbox (which is where test edits should be made, not in mainspace like @SheriffIsInTown has been doing) and found that both section editing and full article editing in VE will sometimes, but not always, end up reformatting all of the citations. This is clearly a VE bug, but I can't figure out what exactly triggers it to happen. I strongly suspect it has something to do with the excessive length (and number of citations) of the article since sometimes the article wouldn't even open properly in VE. Jay8g [V•T•E] 03:45, 30 April 2026 (UTC)

@Jay8g, did you do enough testing to determine if there's an element on the page that, if removed, the reformatting doesn't get triggered? WhatamIdoing (talk) 08:05, 30 April 2026 (UTC)

I'm specifically curious whether Template:Multiple image is the culprit, as I think that uses table formatting,and a malformatted table sometimes causes the rest of the article to be re-parsed. WhatamIdoing (talk) 17:32, 30 April 2026 (UTC)

@WhatamIdoing: Without making any changes to the article, sometimes it reformatted everything and sometimes it didn't. It really seems to be a random occurrence. Jay8g [V•T•E] 02:38, 1 May 2026 (UTC)

Did you do the same thing each time, to make it possible to save the page? WhatamIdoing (talk) 05:13, 1 May 2026 (UTC)

@Jay8g What I noticed from your sandbox history is that whenever you added a dot immediately after a template or between two templates, it reformatted the entire article. However, when you entered a dot within normal text, it did not trigger reformatting. This suggests that making any change to an existing template, adding punctuation between templates, or adding a new template causes the entire article to reformat. Sheriff | ☎ 911 | 16:36, 1 May 2026 (UTC)

@Jay8g When I performed the testing, the “Advanced mobile edit” tag appeared next to my edits. However, edits by others that reformat citations do not have this tag. I am therefore unsure why some editors can perform advanced mobile edits versus normal mobile edits; I do not recall enabling anything. There is also no element within the article that would trigger this behavior, as it would have occurred when I performed the test edits. Sheriff | ☎ 911 | 13:28, 30 April 2026 (UTC)

It's a prefs setting. Your first edit tagged as "Advanced mobile edit" was in 2019, so you must have opted in back then. WhatamIdoing (talk) 17:31, 30 April 2026 (UTC)

Since apparently this problem has no clear solutions, can you please drop the insistence on this issue? Sutyarashi (talk) 21:21, 2 May 2026 (UTC)

At German Figure Skating Championships, sources no. 46 and 47: archived links are included in the coding, but not appearing in the link. Any suggestions? Bgsu98 (Talk) 20:53, 2 May 2026 (UTC)

WP:Archive.is is deprecated. Izno (talk) 21:48, 2 May 2026 (UTC)

(edit conflict)

See WP:ATODAY.

—Trappist the monk (talk) 21:49, 2 May 2026 (UTC)

Okay, I did not realize it was a different archiver. I'll swap them over; thank you! Bgsu98 (Talk) 22:04, 2 May 2026 (UTC)

It's weird, I believe this works in the past: When you are on an image page where it is from Commons in the en space (example), and you click on the Commons logo on the top right, it should redirect to the corresponding Commons page. But instead it just redirect to the logo itself. Is this intended? Syn73 (talk) 10:31, 1 May 2026 (UTC)

Yes it is due to licencing requirements. There's an old discussion that explains why but I can't find it just at the moment. Nthep (talk) 10:40, 1 May 2026 (UTC)

I suppose it's because the CC license requires appropriate attribution, so hyperlinking the image is necessary. — Qwerfjkltalk 15:56, 1 May 2026 (UTC)

That's what I remember from the previous discussion. Nthep (talk) 16:00, 1 May 2026 (UTC)

Found it: Wikipedia:Village pump (technical)/Archive 225#Change in File Page Link Behaviour. Nthep (talk) 16:07, 1 May 2026 (UTC)

I seriously doubt it would be necessary considering the logo is simple to the point of it being hard to see how it would meet the threshold of originality required for a copyright. In other words, the template WMF has put on the the image saying that a CC-SA license applies is likely incorrect. This point was made back in that discussion that took place when it was changed, but nobody followed up on it. I'm guessing that's due to nobody having the will to go fight with WMF over something so trivial. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 17:02, 1 May 2026 (UTC)

Looked for some other examples and found the Wikivoyage logo and the Wikidata logo , which can't possibly be meeting the threshold of originality yet are tagged as being CC-SA licensed. You know what, I'm going to go be a bit annoying and start a discussion on Commons about it. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 17:09, 1 May 2026 (UTC)

The Wikidata logo is public domain. SuperPianoMan9167 (talk) 17:15, 1 May 2026 (UTC)

Oh, my bad, I had a mix-up it seems. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 17:27, 1 May 2026 (UTC)

You know what, I'm going to go be a bit annoying and start a discussion on Commons about it. Do it! If the license is changed on Commons, I'm happy for that topicon to follow the new license. BTW, there was also some relevant discussion at Template talk:Sister project#Delinking icons a while back; User:Sdkb said they asked someone at WMF about it, but I don't see that they reported a response. Anomie⚔ 19:30, 1 May 2026 (UTC)

Yes, I'm aware of that discussion, found a link to it by checking the talk page (on EnWiki) of the Commons logo. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 19:47, 1 May 2026 (UTC)

The discussion is at c:Commons:Village pump/Copyright#Simplistic WMF logos. Also, please note there is no longer any such license as CC-SA - most of these images are licensed CC BY-SA 3.0. It's the BY part that is crucial to the matter at hand, it is this right that requires attribution. The CC SA 1.0 license did not require attribution, which is the reason that it was withdrawn from 25 May 2004. If these images really were licensed CC SA 1.0, there would be no problem with suppressing the link. --Redrose64 🌹 (talk) 17:11, 2 May 2026 (UTC)

You're of course right; I mixed up the ShareAlike part of the license with the attribution part. BY is the relevant bit here. ⹃Maltazarian ^{ᚾparley${\displaystyle \lor }$investigateᛅ} 18:19, 2 May 2026 (UTC)

While BY is the part that requires attribution, even the CC SA 1.0 license requires that you also provide the text of, or a URI or link to, the license itself along with the covered work. We'd still need the link to satisfy that. Anomie⚔ 22:28, 2 May 2026 (UTC)

This seems like somewhat overzealous interpretation of the requirements… The sites use their own logos in the top-left corner, and if that's okay, then the use in this template surely should be okay as well.

@Anomie's original edit: asks for a reference to an exception for the link requirement for Wikimedia logos. I think I found one: (elaborated further here: ). Is that good enough to reverse this annoyance? Matma Rex talk 18:41, 1 May 2026 (UTC)

What WMF does with its own images in the interface is separate from what we do in the content of the wiki, which might be mirrored on non-WMF-hosted sites.

Those links seem to address use of trademarks, not the copyright restrictions on the files. Also, I don't think a permission to use the images without copyright attribution only "on Wikipedia" (or similar) would be acceptable for the same reasons we don't accept grants of permission to use non-free content "on Wikipedia". I'd be satisfied with a permission to use the copyrighted images without attribution or notice of the CC license for linking to the corresponding Wikimedia wikis (from anywhere on the Internet). Anomie⚔ 19:40, 1 May 2026 (UTC)

Section renamed from Template editing changed

From the Tech News above: After two years of development, ⧼codemirror-beta-feature-title⧽, also known as CodeMirror 6, is to be promoted out of beta on Tuesday, April 21. It brings better code and wikitext readability, reduction in typing errors, and other benefits to all users of the standard syntax highlighter. A huge thank you to volunteer Bhsd who developed many of the new features, including code folding, autocompletion, and linting.

This is the change which, I presume has radically changed my template-editing experience. Now I have line numbers in my edit window, browser search doesn't work anymore, and making any of the typical changes I make (bypassing redirects) has become more time-consuming and tedious. I hope there's a good solution for this or I can revert to my previous experience. I've experimented with syntax highlighting in templates before, and have yet to find any solution there that's an improvement for me. wbm1058 (talk) 23:35, 21 April 2026 (UTC)

I think the code-folding feature of codemirror should be highlighted as a tremendous advantage, especially on technical articles with many citations. Try it Johnjbarton (talk) 18:07, 23 April 2026 (UTC)

Oh, I just realized this effects all my editing, including even this page. – wbm1058 (talk) 23:44, 21 April 2026 (UTC)

If you want to get back the old CodeMirror 5, no, that's gone. But if you just want a plain old-fashioned textarea click the "Syntax" button in the toolbar. Alternatively, click the gear icon in the upper right to toggle specific CodeMirror features, e.g. line numbers and linting. Suffusion of Yellow (talk) 00:28, 22 April 2026 (UTC)

I am surprised you don't like the line numbering! That was one that nearly everyone wanted. Anyway, you can disable it along with any other features you don't want in your CodeMirror preferences. You can use Alt+⇧ Shift+, to quickly access the preferences dialog.

As for browser search, it doesn't work as is required for performance reasons, but focus should be placed in the editor when first starting an editing session – meaning Ctrl+F will search within the editor. With focus in the editor, if you want to use browser search on the rest of the page, you can simply hit Ctrl+F twice.

Hope this helps, — MusikAnimal ^talk 00:44, 22 April 2026 (UTC)

So yes, I just checked my editing preferences and yes, "Enable syntax highlighting" is checked to enable it.

The main reason for that is viewing my PHP code pages, e.g. User:RMCD bot/botclasses.php. I enabled line numbers for that with this edit – I do find the line numbers useful for linking to a particular line in the code. I don't think I was using syntax highlighting anywhere else except my PHP code pages.

No, I do not have "Enable the editing toolbar (This is sometimes called the '2010 wikitext editor') checked so I haven't been using that. Though I believe I am using the 2010 wikitext editor, but with a different toolbar that I prefer. – wbm1058 (talk) 01:38, 22 April 2026 (UTC)

Thanks for letting me know about the preferences. I also do not like the new changes, especially the code folding. Brad (talk) 04:57, 22 April 2026 (UTC)

Code folding is indeed a bit of an advanced concept, and probably more useful in the Template namespace. I do however think many of you will appreciate "Fold all <ref> tags by default" feature, based on what we've heard so far. That is dependent on "Code folding" being enabled. (I realize the concept of "dependent preferences" isn't visually conveyed, yet; We'll fix that!)

Also while we're on the topic, every wiki gets to decide for themselves what the default preferences are. The debate for enwiki should probably come with a reboot of the discussion around phab:T288161. Consensus for enabling syntax highlighting for all is now ~5 years old, and was also prior to all the new features being added. — MusikAnimal ^talk 05:32, 22 April 2026 (UTC)

@MusikAnimal: Oddly, highlighting doesn't seem to be the default for new and unregistered users anymore. I tried resetting all global and local preferences for Suffusion of Yellow alt 13, and got no syntax highlighting until I clicked the syntax button. The same when logged out, though I didn't try creating a temporary account. Suffusion of Yellow (talk) 18:25, 22 April 2026 (UTC)

@Suffusion of Yellow You mean for non-wikitext? It was never default on for wikitext, though that is subject to change (phab:T288161).

Anyway I'm working on phab:T418352 now, which will allow us to enable syntax highlighting for non-wikitext by default (separately from wikitext). — MusikAnimal ^talk 19:42, 22 April 2026 (UTC)

I could have sworn I mis-clicked "edit" a few times while logged out, and saw syntax highlighting. Was there some sort of A/B testing at some point, maybe? Perhaps I'm remembering wrong. Suffusion of Yellow (talk) 20:14, 22 April 2026 (UTC)

No, but if you enabled it while logged out it would stick so long as you used the same browser/device (via localStorage). — MusikAnimal ^talk 20:40, 22 April 2026 (UTC)

Is it possible to change the text in the CodeMirror Find/Replace box? I think it might help if Find -> "Find in edit panel" to reduce surprise. I think the double control F is a big win, but discovery is hard. Johnjbarton (talk) 01:48, 26 April 2026 (UTC)

Perhaps "Find in editor"? The panel refers to the type of UI element that the search form uses.

Glad to hear Ctrl-F × 2 helps. We can document it in the keyboard shortcuts dialog (accessible via Ctrl+⇧ Shift+/).

Thanks for the feedback! — MusikAnimal ^talk 08:26, 27 April 2026 (UTC)

Another issue with the "Find" feature: one can no longer leave the mouse on the "next" button and pay attention the finds as you click through. The mouse gets ejected somehow and you have to move it back. Very annoying. Johnjbarton (talk) 22:47, 2 May 2026 (UTC)

Sigh. How do I get the text editor to remember that I want the syntax highlighting when editing lua, javascript, css, etc but do not want syntax highlighting when editing wikitext (this talk page, articles, templates, sandboxen, testcases, etc)? I should not have to click the syntax icon on the toolbar when switching between 'code' and 'wikitext'.

Does it not seem odd that the icon requires bold Syntax to identify what it means? Is that not a classic example of failed user interface design?

—Trappist the monk (talk) 01:11, 22 April 2026 (UTC)

We're going to make "no syntax highlighting" a theme soon (phab:T419339, phab:T163533). Until then you'll have to toggle it manually, I'm afraid. The "Syntax" label for the button was following a contentious 8+ year debate at phab:T174145. Too many users couldn't make sense of the old icon (you can search the archives here), and while the new icon is seen as an improvement, the label was still deemed necessary. Opinions to change it are most welcome but I can't promise anything given how much bike shedding there's been leading up to this point. — MusikAnimal ^talk 01:38, 22 April 2026 (UTC)

I'm confused. I thought I was getting syntax highlighting from mw:Extension:SyntaxHighlight. Now you're telling me that mw:Help:Extension:CodeMirror does my syntax highlighting. What's the difference? – wbm1058 (talk) 01:46, 22 April 2026 (UTC)

The former is for reading static pages and in-wikitext code examples with the <syntaxhighlight>...</syntaxhighlight> tag. CodeMirror meanwhile is an editor providing syntax highlighting among other editing features. — MusikAnimal ^talk 01:50, 22 April 2026 (UTC)

OK, I just unchecked "Enable syntax highlighting" and found that it had no effect on my PHP code page viewing. I guess it's not necessary to check any boxes to enable the <syntaxhighlight>...</syntaxhighlight> tag. And my editing experience on this page is back to normal, so I'm happy. If I was using the old CodeMirror 5 before, I have no idea what it was doing for me. – wbm1058 (talk) 02:01, 22 April 2026 (UTC)

Eventually we may provide syntax highlighting for PHP, but there are no "PHP pages" in MediaWiki so it is a narrow use-case. However there's phab:T400014 where we'll want syntax highlighting for a large number of languages (to be on-par with mw:Extension:CodeEditor), and following that it might be feasible to provide syntax highlighting within the <syntaxhighlight>...</syntaxhighlight> tag while editing wiktiext. So in other words, one day you may be able to edit User:RMCD bot/botclasses.php and you'll have a similar experience as that when viewing output of <syntaxhighlight lang=php>...</syntaxhighlight>. Hopefully that makes sense :) — MusikAnimal ^talk 02:17, 22 April 2026 (UTC)

Suggestion: Make the settings easier to find. Consider phab:T362813 Ctrl+, was broken on AbuseFilter's CodeEditor for a full month and not a single person other than me complained or even subscribed to the task. It looks like no one even knew that CodeEditor was configurable! Now the gear icon is an improvement, but you have to click "advanced" for it to even show up. Suffusion of Yellow (talk) 18:31, 22 April 2026 (UTC)

Another suggestion: Turn on the linter by default. It's the most immediately user-visible improvement, IMO, and most people will probably never find it. The first time someone is saved from breaking half of AN/I with a misnested tag, they'll be hooked for life! Also, I understand the idea is to make it locally configurable at some point, e.g. to warn about unreliable sources, etc. There won't be much motivation to do that, if almost no one will see the warnings. Suffusion of Yellow (talk) 18:44, 22 April 2026 (UTC)

We were asked by the Editing team to obscure the settings button at phab:T404543, but perhaps opinions have changed given how much the product has grown. Re-reading that task, what you're asking for I think is solution 4A, where the settings icon will be directly adjacent to the "Syntax" button.

We were not asked to have linting off by default, but I assumed that was the desire with respect to newbies. The status bar and such may make the experience look a bit intimidating, especially if there were already pre-existing errors.

Regardless, we as a community are at full authority to set whatever we want as the default preferences. I hope to make all of this available at Special:CommunityConfiguration eventually. — MusikAnimal ^talk 19:06, 22 April 2026 (UTC)

Yes, 4a looks better. It might also help to have the same settings at Special:Preferences#mw-prefsection-editing-syntax-highlighting. Suffusion of Yellow (talk) 22:14, 22 April 2026 (UTC)

I was editing the 2026 May Day protests to remove some bare URLs, and this is what Zotero (the tool behind the automatic citation system) suggested: Imgur link. This is the link to the website I was trying to fill.

I've never actually used Zotero, knowing that it half the time is inaccurate or flat out rejects the page. But the fact that it is throwing CS1 generic name errors is something else. Why isn't there a failsafe to reject a website if it causes a failure? This is just something that will cause the ever-growing Category:CS1 errors: generic name to expand (up to 24,000 pages!). Kind of ridiculous that we are suggesting, in a tool meant for newer users, to throw errors in articles. EatingCarBatteries _{(contribs | talk)} 01:45, 2 May 2026 (UTC)

Zotero is a system completely outside our control, so it doesn't know about CS1 errors. What can be done is for someone to build a Zotero translator for that website so that it outputs good data to us. Izno (talk) 02:15, 2 May 2026 (UTC)

I understand that, I'm not expecting for the tool itself to be fixed, but couldn't Wikipedia detect if it ultimately outputs a CS1 error?
To my understanding, Zotero is the tool that detects the bibliographic data and Wikipedia converts that data into arguments in templates. If an error is thrown, why can't it just abort? EatingCarBatteries _{(contribs | talk)} 03:15, 2 May 2026 (UTC)

Citoid/VisualEditor's support for it also does not know about CS1 errors. At the end of the day, the user on the other end of the keyboard is responsible for the citations that end up in the source. Izno (talk) 03:30, 2 May 2026 (UTC)

I'm trying to understand here. In the citation that is generated in the screenshot, using inspect element shows:

<cite id="CITEREFThisFacebookXThreads2026" class="citation web cs1" about="#mwt1">

This is the same kind of fragment, (<cite> with a class of "citation web cs1"), that any normal citation shows in any article. What this tells me, combined with the fact that the outputted citation does include that visible error, is that it's being processed by Wikipedia before being presented to the user. If it shows me an error, it sure knows that it is an error. What I'm asking is why doesn't Wikipedia, if it detects this error, say the reference couldn't be expanded?

I agree that ultimately the user is responsible for their edits, but newer users who have no idea what CS1 is may be under the assumption that what Wikipedia's own tool suggested them will work. 99.99% of all people have no idea what a CS1 error is, and they'll probably go along with it. I suspect that a large portion of generic name errors are due to this reason. EatingCarBatteries _{(contribs | talk)} 03:58, 2 May 2026 (UTC)

If it shows me an error, it sure knows that it is an error. No. There are multiple different systems at work here. Citoid goes and gets the Zotero output. VisualEditor and/or Citoid provides that data to the module known as Module:Citation/CS1. That module turns the data into a displayed citation. The error in this chain is identified only by the last element. Citoid, VE, and Zotero have no knowledge that the module has decided that the output has an error of some sort. Citoid and VE are developed by WMF, Zotero by some set of contributors out and about in the world, and the module by English Wikipedia technical contributors. Three separate systems, mostly developed by three different sets of people, each with separate concerns (mostly) today. Parts of the software like VE/Zotero, are developed to be more, rather than less, generic. CS1 is different in that it's assumed mostly to be English Wikipedia-specific.

As DLynch says below, it is possible to add support for some sort of "the template didn't like what it got, give the user some other opportunity to do something". isaacl suggests a more general solution. But either way, that would be some quantity of (significant) work to add. There are a few tasks on Phabricator about the creation of citations with errors in them. Previously the solution has been "create a Zotero translator" since that generalizes outside of this forum. (My impression is that it's really not that successful a solution, as it does require a bit of technical knowledge to do so.) Izno (talk) 18:33, 2 May 2026 (UTC)

Thanks for letting me know all of this! EatingCarBatteries _{(contribs | talk)} 03:54, 3 May 2026 (UTC)

Note from the MediaWiki software's point of view, a template just replaces one text string with another. There is no concept of a template succeeding or failing – that meaning is only understood by the editors reading the replacement string. isaacl (talk) 04:05, 2 May 2026 (UTC)

For the specific link, the issue is that the output from citoid/zotero has detected a bunch of share links as "authors". Citoid then faithfully passed those authors into cite_web, and CS1 complained. The issue here is that to Citoid/VisualEditor the citation template looks the same whether CS1 had issues with it or not, because either way it's successfully outputting some HTML.

We'd need to write some enwiki-specific (well, CS1 is copied between wikis a lot, so it'd generalize, but not perfectly...) code that interrogates the returned HTML and looks for an element with the class cs1-visible-error, then raises that as an error to VisualEditor. DLynch (WMF) (talk) 09:03, 2 May 2026 (UTC)

The example fills out many cite web parameters and the only CS1 error is |last2=Facebook. I would rather fix that manually than make the whole citation manually. (In this case there are other incorrect author parameters which don't give CS1 errors.) PrimeHunter (talk) 10:49, 2 May 2026 (UTC)

I agree with fixing the error. Snævar (talk) 00:10, 3 May 2026 (UTC)

Assuming the dev team wants to do this in an extensible manner for any MediaWiki installation, I think it would be desirable to introduce a generic concept of template failure. It could be a specific CSS class or data attribute on an HTML element. isaacl (talk) 17:17, 2 May 2026 (UTC)

We'll have it ready to go in only ten years or so. — Qwerfjkltalk 19:22, 2 May 2026 (UTC)

You mean like how {{#iferror:}} looks for any HTML element with class="error"? Anomie⚔ 22:51, 2 May 2026 (UTC)

Thanks for that link – I didn't know about that standard used by parser functions. Yes, and it would be good to use the same error CSS class. (It should be feasible as long as no one is using it for other styling purposes than displaying a parser function or template error.) isaacl (talk) 23:07, 2 May 2026 (UTC)

The class carries styling in multiple skins which may not be desirable specifically with CS1 (particularly the presence of bold in the more modern skins). Izno (talk) 23:38, 2 May 2026 (UTC)

It might have been nice to have consistent styling of errors across parser functions and templates, but I appreciate that it may be a difficult transition after so many years. In that case, should a new CSS class or HTML data attribute be introduced for template errors, it would be nice if {{#iferror:}} were enhanced to look for it as well, so template errors could be caught. isaacl (talk) 23:54, 2 May 2026 (UTC)

In lua, error('message') makes an script error that has an error class, I think. The template would not show anything else. Newbies would either leave the citation or remove it. Snævar (talk) 00:03, 3 May 2026 (UTC)

(This is a bit of an aside, since it relates to how templates can be implemented, rather than how Visual Editor might be enhanced to support the concept of template failure.) As I understand it, the Lua error() function throws an exception. Perhaps someone knows if the Scribunto extension provides any default catchall handling for it? isaacl (talk) 00:15, 3 May 2026 (UTC)

Yes, as Snævar described: the invoke produces an error message as its output, including the error class. There's also some JS that lets you click the error message to get a stack trace. Anomie⚔ 01:52, 3 May 2026 (UTC)

Go to any talk page archive, say Talk:Denis Kapustin (militant)/Archive 1, and you can see that the link to the article in the sticky header goes to the nonexistent Denis Kapustin (militant)/Archive 1, instead of the correct Denis Kapustin (militant). Helpful Cat🐈(talk) 04:57, 3 May 2026 (UTC)

Yep, that's a known system limitation with how subpages are handled between a namespace that has subpages enabled (talk) and one that doesn't (article). It's hard to fix that in the software without accidentally having, say, Talk:AC/DC point to AC. Chaotic Enby (talk · contribs) 05:07, 3 May 2026 (UTC)

Thanks! From the AC/DC example, I see why this can't be fixed easily. Helpful Cat🐈(talk) 05:33, 3 May 2026 (UTC)

I’ve noticed that some pages (though not all) scroll horizontally to the right when viewed on mobile web, which makes it difficult to read citations. I suspect this is caused by tables with many columns. Can someone knowledgeable with it help fix or prevent this issue? Sutyarashi (talk) 21:18, 2 May 2026 (UTC)

There is no general solution: when content overflows a browser window's width, either content gets truncated, or horizontal scrollbars are needed. Each page where this is an issue has to be examined. You can raise it on the associated talk page for each page in question. isaacl (talk) 21:51, 2 May 2026 (UTC)

@Sutyarashi: Do you mean a page automatically scrolls right without the user doing anything? If so then please link an example page and name your device/browser. PrimeHunter (talk) 23:17, 2 May 2026 (UTC)

Not automatically, but to view citations I have to scroll towards right. Sutyarashi (talk) 09:56, 3 May 2026 (UTC)

There are several images such as File:Damage in Gaza Strip during the October 2023 - 36.jpg and File:Damage in Gaza Strip during the October 2023 - 18.jpg which are used at Gaza genocide and licensed under CC BY-SA 3.0. However, the media previewer marks the images as public domain. The structured data, categories, and templates all seem to be correct on the Commons side. This seems to affect Wiki Palestine images; see Qadura Fares and Ehab Bessaiso. Anyone know why this is happening? Based5290 :3 (talk) 10:19, 3 May 2026 (UTC)

Michel Bakni created commons:Template:Wiki Palestine/layout with transclusion of commons:Template:PD-Layout. PrimeHunter (talk) 11:24, 3 May 2026 (UTC)

Based5290 has replaced PD-Layout so Media Viewer no longer displays the wrong license. PrimeHunter (talk) 12:29, 3 May 2026 (UTC)

After Wikipedia:Administrators'_noticeboard#Redirect_creation_request, I attempted a regex search for existing titles like the one that was requested, Yei éek kwa néix. However, I couldn't find this new page in quarry:query/105001. –LaundryPizza03 (dc̄) 16:57, 3 May 2026 (UTC)

Underscores aren't word boundaries. —Cryptic 17:41, 3 May 2026 (UTC)

Thanks, rerunning with _ replaced by space uncovered 7 additional titles. –LaundryPizza03 (dc̄) 18:15, 3 May 2026 (UTC)

I don't find Wikipedia's feature of adding closed and open access symbols (the green and red round locks) to citations useful, and it's interfering with a web extension I use that interacts with DOIs. Is there any way to turn it off? ꧁Zanahary꧂ 15:29, 3 May 2026 (UTC)

This happens both in Vector 2010 signed in and Vector 2022 signed out ꧁Zanahary꧂ 15:29, 3 May 2026 (UTC)

Looks like it's targeting links inside the class .id-lock-free and changing their default background image. Brain is a bit too tired to fix this in CSS right now, sorry! Chaotic Enby (talk · contribs) 15:41, 3 May 2026 (UTC)

Tell us a bit more about the extension. There is CSS that is pretty easy to override (see Module:Citation/CS1/styles.css) but not necessarily unset to using the standard external link icon (without replicating what is already loading). Employing that CSS may not help however. Izno (talk) 16:55, 3 May 2026 (UTC)

The extension is ScholarKey, which renders Wikipedia citation statistics and institutional access links next to DOIs everywhere on the web, including on Wikipedia, which is where it's most useful to me. The problem is that the lock icons pop up next to every access link that ScholarKey generates, creating a big visual mess all for the sake of showing me something I don't really need to know. ꧁Zanahary꧂ 17:16, 3 May 2026 (UTC)

The source for which is ezrai/ScholarKe it seems.

What do you see when you use it? Izno (talk) 19:00, 3 May 2026 (UTC)

I see one lock icon to the right of the source URL in the rendered citation, then the extension-rendered citation search badge, then a string of access links represented by favicons and emojis, and to the right of each of these sources (I have five) is that same lock icon repeated. ꧁Zanahary꧂ 19:44, 3 May 2026 (UTC)

Here is how it looks ꧁Zanahary꧂ 19:48, 3 May 2026 (UTC)

@Zanahary: Wikipedia only makes one link with one lock icon. The link is wrapped in a span with class="id-lock-subscription". The background image for links with the class is added at Module:Citation/CS1/styles.css#L-54. You can remove it with this code in your CSS (and similar for the other lock icons):

.id-lock-subscription.id-lock-subscription a {
	background: none !important;
}

I don't know which effect it has on your extension. PrimeHunter (talk) 22:03, 3 May 2026 (UTC)

Thank you! That fix retains the space and padding for the lock icons though.

Does anyone else feel like this should be configurable? ꧁Zanahary꧂ 22:06, 3 May 2026 (UTC)

I have fixed it with this in my CSS:

.id-lock-free.id-lock-free a,
.id-lock-limited.id-lock-limited a,
.id-lock-registration.id-lock-registration a,
.id-lock-subscription.id-lock-subscription a {
    background: none !important;
    padding: 0 !important;
}

꧁Zanahary꧂ 22:13, 3 May 2026 (UTC)

Help:External link icons also has code for customization. PrimeHunter (talk) 22:21, 3 May 2026 (UTC)

Hi (and apologies if this is not the right place to report) – in the last two days I have noticed a change in the behaviour of the visual editor. When inserting a new <ref>...</ref>, the ref does not immediately show up in the {{reflist}}, as it used to. Switch to source edit and back to visual again, and the ref appears. This on Mac Chrome 146.0.7680.178 and Fox 148.0.2. Thanks! Tobyhoward (talk) 18:15, 1 May 2026 (UTC)

Thanks for reporting, we'll look into it. Johannes Richter (WMDE) (talk) 18:42, 1 May 2026 (UTC)

Were you editing any particular section while this happened? while editing a section in visual editor, if you switch to source edit and switch back to visual editor, it will load entire article (while you were editing a section only) this means also load the References section with {{reflist}}. This is an old Visual Editor bug.––KEmel49(📝,📋) 18:57, 1 May 2026 (UTC)

No, I always edit the whole article, not on a per-section basis. Tobyhoward (talk) 19:24, 1 May 2026 (UTC)

Our investigation suggests that there are two issues: This change to {{Reflist}} in December 2025 apparently doesn't work with the way VisualEditor recognizes the template as a substitute for <references />.

Looking at a simplified example: VisualEditor expects something like this

<templatestyles src="Reflist/styles.css" /><div>{{#tag:references}}</div>

while the change introduced a line break which VE cannot deal with

<templatestyles src="Reflist/styles.css" />
<div>{{#tag:references}}</div>

The line break doesn't lead to visible differences for readers, so we suggest reverting that part of the edit (@User:Anomie fyi). But there seems to be an additional issue: Recent changes to VE apparently broke the exising way of recognizing {{Reflist}} which means that removing the line break wouldn't even fix the bug as of now (but it would have fixed it in previous MediaWiki versions). We've notified the WMF Content Transform Team. --Johannes Richter (WMDE) (talk) 11:26, 2 May 2026 (UTC)

Thanks for your efforts in pursuing this! Tobyhoward (talk) 11:50, 2 May 2026 (UTC)

VE seemed to work back when the edit was made, after Special:Diff/1328019882 fixed that VE apparently needed a wrapping <div>. Anyway, I made a possible edit to Template:Reflist/sandbox, but since you say there's another bug I can't really verify it. Anomie⚔ 13:22, 2 May 2026 (UTC)

Greetings, The template "Ramon Magsaysay Award Winners" has 7 sections, and only one section links to Eva Maamo. Changing template to contain those collapsible sections is way beyond me, so I am asking for expert help here. Details are at the article's Talk. Regards, JoeNMLC (talk) 13:28, 4 May 2026 (UTC)

@JoeNMLC: Maybe {{Ramon Magsaysay Award Winners}} should be split into 7 separate navboxes but I have added code to automatically expand the Community Leadership group when the template is used in those articles. The same could be done for the 6 other groups. It's also possible to let the state be controlled by a parameter in the call but then all the calls have to be updated. PrimeHunter (talk) 14:04, 4 May 2026 (UTC)

@PrimeHunter - Thank you for this solution.

 Done - Cheers! JoeNMLC (talk) 14:15, 4 May 2026 (UTC)

Could someone please move User:Iuri Bertie/sandbox to Draft:Herman Zeekaf? I submitted it for AfC review, but I am not autoconfirmed and cannot move pages myself. The draft page itself recommends moving it to Draft space.

Thank you. Iuri Bertie (talk) 14:58, 4 May 2026 (UTC)

Iuri Bertie,  Done. KylieTastic (talk) 15:02, 4 May 2026 (UTC)

I am going to assume these are probably related to the Parsoid rollout. As of a few days ago, I've noticed three separate issues with the mobile web interface (I have documented all three in my sandbox). Switching to the desktop interface shows none of these issues occurring.

1. As was already reported above, visited pages do not highlight purple anymore. However, they still do highlight correctly in edit preview mode. Perhaps redundant to be reporting this, but it showed up at the same time as the other issues I mention below.
2. Colon prefixing does not seem to be working correctly. For example, /æ/ raising is a page which starts with a forward slash, so it must be colon prefixed in order to link correctly, but the prefix does not appear to be doing its job; it instead interprets as if the colon is not there, linking to a subpage of wherever it is placed. This issue also does not occur in edit preview mode.
3. (Sub)sections within collapsed boxes do not show an edit option anymore. That is, placing a section within {{cot}}…{{cob}} used to have the edit pencil next to the header, but now they do not. Regular subsections still work fine, it is only collapsed ones.

~ oklopfer (💬) 06:05, 4 May 2026 (UTC)

A fourth issue: Template:IPA vowels/table (or its sandbox page) does not render the same in standard mobile web display as it does in edit preview mode or desktop interface. The class tag is displaying at the top as plaintext and not properly applying to the table. Again, this is very recent breakage. ~ oklopfer (💬) 06:24, 4 May 2026 (UTC)

I'm seeing your second, third, and fourth issues on desktop (tested in Monobook and Vector2022 skins) as well when visiting and to force Parsoid. Anomie⚔ 11:50, 4 May 2026 (UTC)

The second one seems to be reported as T422161, The fourth one seems to already be reported as T418268. Anomie⚔ 12:46, 4 May 2026 (UTC)

Thanks for finding those, I've created a tracking table. Not seeing anything directly about the third issue in Phabricator. T411601 appears to be quite similar, but looks like the connected diffs only apply to mobile view, so not sure it is the same thing; I'm guessing "collapsed sections" refers to the typical mobile sections, rather than my "hack" to have recursively collapsing subsections. ~ oklopfer (💬) 15:59, 4 May 2026 (UTC)

It seems like the issue doesn't occur when substituting the collapses. Based on the larger tracking collection at T391624, I think I can identify it as T387374. ~ oklopfer (💬) 16:51, 4 May 2026 (UTC)

I have fixed that fourth issue onwiki but have no issue with the general task needing fixing. Izno (talk) 17:20, 4 May 2026 (UTC)

Background info: I have Navigation pop-ups enabled in Preferences -> Gadgets. I have Monobook set globally. I use Edge on Win11. Problem: I point my mouse at Fine Gael. I see the text "Fine Gael ⋅ actions ⋅ popups 119kB, 592 wikiLinks, 4 images, 10 categories, 1 day 14 hours old, Q247135" and a picture of Garret Fitzgerald from half-way down the page (it's not even the first picture on the page), and no text from the article at all. I seem to recall similar problems in the past were caused by things in the infobox. Help appreciated. Thank you, DuncanHill (talk) 12:37, 4 May 2026 (UTC)

@DuncanHill: Wikipedia:Tools/Navigation popups#Options has 600 as default for popupMaxPreviewCharacters: "The maximum number of characters to extract from something approximating the beginning of an article for the preview." Popups doesn't process template calls and references. The only other content in the first 600 characters of the opening paragraph of Fine Gael is "Fine Gael". I have window.popupMaxPreviewCharacters = 10000; in my personal js so I see a lead text in the preview. Navigation pop-ups is an opt-in gadget for registered users and we don't generally design articles for it. PrimeHunter (talk) 14:34, 4 May 2026 (UTC)

PrimeHunter, I tried copying that line, but it didn't work. How are you implementing this? I couldn't find a script with the string 'Preview' or 'popup' in your common.js either. Mathglot (talk) 18:28, 4 May 2026 (UTC)

@Mathglot: I have it in User:PrimeHunter/vector.js. Your code looks right. Have you tried to bypass your cache? Use Ctrl+F5 in Windows browsers, not F5 or the reload button alone. If it still fails then maybe something in your common.js is broken earlier in the page. Try moving the code to the top. PrimeHunter (talk) 19:15, 4 May 2026 (UTC)

Hi everyone,

The Reader Growth team is launching an experiment to test the usefulness of a share feature that gives readers options to create a visually compelling card about an article (or portion of an article) they are reading. They can share this card to a friend or post it on their social media. The card will then link the viewer or recipient directly back to that article or even portion of the article when clicked.

This experiment, a mobile-only A/B test for 10% of logged-out readers on Arabic, Chinese, French, and Vietnamese Wikipedias and 0.1% of readers on English Wikipedia, will go live the week of May 18 and will run for four weeks. This will only be on mobile and will use the user’s phone’s native sharing function – that is, when a user goes to share a link and their device automatically offers sharing options based on previously granted permissions.

Why are we working on this?

The percentage of the world that visits Wikipedia is decreasing, visible in the drop in the number of readers, and in turn, impacting the number of accounts created and contributions to our sites. The vast majority of internet users today default to mobile-first experiences, where they are accustomed to being able to easily share links and content with friends and family.

What idea are we testing?

We want to test 1) whether logged-out readers who are enjoying what they’re reading on Wikipedia want to share that content with others off-platform and 2) whether the flow we’ve designed makes it easy for them to do so.

What is the timeline?

We will A/B test this version starting the week of May 18 and end it four weeks later. We’ll measure whether readers engage with the feature and whether they visit Wikipedia more often. We’d also like to understand how often people who received the share links from experiment participants end up using the links to visit Wikipedia. If we see positive results, we’ll share the results of this A/B test and decide together whether to proceed and what changes to make if we do.

What does the experiment include?

This feature will appear in two places: (1) a new Share button that will always show in the toolbelt on article pages, and (2) upon highlighting article text, which will trigger a pop-up share card experience with the relevant article excerpt. The reader will also see options to download the image or just copy a link to the article/excerpt.

We are also optimistic that these Share cards may help subtly educate people about proper attribution. The Share card includes links back to the Wikipedia article, as well as image attribution, where relevant, and license icons.

Since this work is still experimental, we expect to refine and adjust the design based on your feedback and experiment results.

Please share your thoughts and questions here!

For more info on our research, mock-ups, and other details, see our project page. Thank you.EBlackorby-WMF (talk) 20:08, 4 May 2026 (UTC)

Hello all. I'm asking something for the Egyptian Arabic Wikipedia.

We can't use the template:DISPLAYTITLE^(arz) to change characters in the the title, specifically three chosen ones: ب to پ;‎ ج to چ;‎ ف to ڤ.

Why the aforementioned three characters and for which purpose?

1. In the Egyptian Arabic language, we often need to write loanwords which contain common foreign phones not existing on basic Arabic keyboards.
2. Search engines don't index pages if they have non-basic characters in their titles, so we are forced to awkwardly title them with the basic characters and throughout the article spell the word properly.
3. We don't need this template to change the whole title or display another title instead of how the page is actually titled, only optionally change the three corresponding characters as needed: e.g. اسبانيا to be displayed with the title اسپانيا;‎ جاكسون to be چاكسون.

These characters have been used already in print books for over a century and children are already familiar with them.

Can someone help? --Esperfulmo (talk) 18:43, 4 May 2026 (UTC)

@Esperfulmo: DISPLAYTITLE cannot change characters except lowercasing the initial character and characters in the namespace. You would have to get a developer to change mw:Manual:$wgRestrictDisplayTitle to false for the Arabic Wikipedia, but then any title could be changed to anything and you may get many unwanted changes where copy-pasting a page title to a wikilink gives a broken link. Maybe you could make some sitewide JavaScript to change the characters in the browser of the user. PrimeHunter (talk) 19:09, 4 May 2026 (UTC)

Thanks for your answer. It's the Egyptian^(arz:) Arabic Wikipedia, not the Arabic^(ar:) Wikipedia. Do you think it's possible to restrict the template's use to administrators only to avoid vandalism? --Esperfulmo (talk) 19:23, 4 May 2026 (UTC)

@Esperfulmo: An edit filter could attempt to only allow addition of DISPLAYTITLE for administrators but it has many other valid uses (at least in English) so it doesn't sound good to me, and I still doubt the developers would allow a change of wgRestrictDisplayTitle. PrimeHunter (talk) 22:54, 4 May 2026 (UTC)

I am unable to save any edits on Wikipedia. The Publish changes button does not respond on any page, any browser (Chrome, Firefox, Edge), any network (WiFi, mobile data), incognito mode, or after clearing cache. The error message says "There was an error while loading the form. To continue, you will need to reload the page." Reloading does not fix it.

This affects all pages including my own user page. My account is Andrei MYCRANE, created 3 May 2026. I have a confirmed email address.

Can anyone help diagnose this issue? Andrei MYCRANE (talk) 17:52, 4 May 2026 (UTC)

Well, you somehow managed to publish changes to this page. Did you do anything differently for posting this question? Are you still having trouble on other pages? GrayStorm^{(Talk to me|My Contribs.)} 18:07, 4 May 2026 (UTC)

Andrei MYCRANE, maybe some gadget or script messing with you? Try appending ?safemode=1 to the url on the page that is having the problem and let us know if that fixes it for that page. (Note: see Help:Safe mode about whether to use '?' or '&' as the first character.) (edit conflict) Mathglot (talk) 18:08, 4 May 2026 (UTC)

I have tried the ?safemode=1 suggestion from Village pump but the Publish button still does not work. The current saved draft is the original declined version. I have a fully revised neutral text ready but cannot save it due to this technical issue. Could you please paste the following revised text into Draft:MYCRANE for me?

{{connected contributor}}
{{paid|employer=MYCRANE|client=MYCRANE}}
'''MYCRANE''' is a technology company that operates an online platform
for crane rental and equipment procurement, headquartered in Dubai,
United Arab Emirates.<ref>{{cite web |url=https://www.cbnme.com/machinery/crane-rental-goes-digital-with-mycrane/ |title=Crane rental goes digital with MYCRANE |publisher=Construction Business News ME |date=29 August 2021}}</ref> The company was founded in 2021 by Andrei Geikalo.<ref>{{cite web |url=https://www.epcworld.in/india-is-a-huge-market-for-crane-rental-says-andrei-geikalo-founder-and-ceo-mycrane/ |title=India is a huge market for crane rental |publisher=EPC World |date=15 March 2023}}</ref>
==Operations==
MYCRANE operates crane rental services in Saudi Arabia and India under the brand MYCRANE Rental.<ref>{{cite web |url=https://www.logisticsgulfnews.com/e-commerce/business-booming-in-india-as-mycrane-platform-makes-strides-in-critical-market/ |title=Business booming in India as MYCRANE platform makes strides in critical market |publisher=Logistics Gulf News |date=11 April 2024}}</ref> As of April 2026, the platform had over 1,000 registered members in India.<ref>{{cite web |url=https://www.cranebriefing.com/news/mycrane-pases-1-000-member-mark-in-india/8120355.article |title=MYCRANE passes 1,000 member mark in India |publisher=Crane Briefing |date=28 April 2026}}</ref>
MYCRANE Trading is a subsidiary that provides crane sales, leasing, and maintenance services, based in Jebel Ali Free Zone, Dubai. In August 2025, MYCRANE Trading raised US$50 million to fund its UAE operations.<ref>{{cite web |url=https://www.cranestodaymagazine.com/news/mycrane-trading-raises-us50m-to-launch-uae-operations-from-jebel-ali-base/ |title=MYCRANE Trading raises US$50m to launch UAE operations from Jebel Ali base |publisher=Cranes Today |date=21 August 2025}}</ref>
MYCRANE Marketplace is a global platform for buying and selling crane equipment. A beta version launched in October 2022.<ref>{{cite web |url=https://www.craneandhoistcanada.com/mycrane-launches-free-to-use-online-marketplace/ |title=MYCRANE launches free-to-use online Marketplace |publisher=Crane and Hoist Canada |date=13 October 2022}}</ref> An updated version launched in November 2024.<ref>{{cite web |url=https://www.heavyliftpfi.com/cranes/2024/11/28/mycrane-launches-global-equipment-marketplace/ |title=MyCrane launches global equipment marketplace |publisher=Heavy Lift and Project Forwarding International |date=28 November 2024}}</ref>
==History==
MYCRANE was founded in Dubai in 2021.<ref>{{cite web |url=https://www.cbnme.com/machinery/crane-rental-goes-digital-with-mycrane/ |title=Crane rental goes digital with MYCRANE |publisher=Construction Business News ME |date=29 August 2021}}</ref> In 2022, the company announced a US market launch.<ref>{{cite web |url=https://www.int-liftandhoist.com/news/mycrane-announces-us-launch/ |title=MyCrane announces US launch |publisher=International Lift and Hoist |date=25 October 2022}}</ref> In 2023, the company secured funding for expansion into Saudi Arabia and the United States.<ref>{{cite web |url=https://www.constructionweeksaudi.com/news/mycrane-secures-fund-for-saudi |title=MYCRANE secures funds for Saudi and U.S. expansion plans |publisher=Construction Week Saudi |date=20 July 2023}}</ref>
==Recognition==
MYCRANE received the following awards in 2025:
* Startup of the Year, Construction Technology Awards, Dubai.<ref>{{cite web |url=https://ctf-awards.com/winners-2025 |title=Winners 2025 |publisher=Construction Technology Awards |year=2025}}</ref>
* Global Platform for Innovative Online Crane Rental, EPC Awards.<ref>{{cite web |url=https://globalsupplychainme.com/mycrane-wins-epc-award/ |title=MYCRANE wins EPC Award |publisher=Global Supply Chain |date=26 February 2025}}</ref>
* Innovation of the Year (Local), CMME Awards.<ref>{{cite web |url=https://constructionmachinerymenews.com/58536/cmme-awards-2025-winners-announced/ |title=CMME Awards 2025: Winners announced |publisher=Construction Machinery Middle East |date=26 June 2025}}</ref>
==References==
{{reflist}}
==External links==
* [https://my-crane.com Official website]

Andrei MYCRANE (talk) 18:24, 4 May 2026 (UTC)

Collapsed pasted article and enclosed in pre-tags. Mathglot (talk) 19:17, 4 May 2026 (UTC)

Other posisble reports at Wikipedia talk:Talk page guidelines#can't edit talk pages and Wikipedia:Help desk#Unable to publish edits, but IP is not blocked?. CMD (talk) 04:46, 5 May 2026 (UTC)

Also Wikipedia:Teahouse#Blue "Publish changes" button still not working and Wikipedia:Teahouse#Publish Button. TSventon (talk) 07:17, 5 May 2026 (UTC)

Went to view a diff and was taken to an interesting page: I see it has caught a few people, as per WP:AIV.--☾Loriendrew☽ ☏(ring-ring) 22:24, 4 May 2026 (UTC)

Seems like a strange but not otherwise particularly interesting link. Did you find it somewhere interesting? Anomie⚔ 22:29, 4 May 2026 (UTC)

I believe I have taken care of this. Let me know if it pops up again. ~ ONUnicorn^{(Talk|Contribs)}problem solving 22:47, 4 May 2026 (UTC)

@ONUnicorn: Looks like it has, per Wikipedia:Administrators' noticeboard#Many compromised accounts. Graham87 (talk) 04:20, 5 May 2026 (UTC)

Now at Wikipedia:Administrators' noticeboard#Many compromised(?) accounts, and that one has been resolved as well. Graham87 (talk) 07:11, 5 May 2026 (UTC)

@Loriendrew: Please spell what you did and what happened. Where did you see the diff that you clicked? What do you mean by "filter issue"? Johnuniq (talk) 04:28, 5 May 2026 (UTC)

I came across it while viewing this diff , and got exactly what the image shows.--☾Loriendrew☽ ☏(ring-ring) 10:53, 5 May 2026 (UTC)

It wasn't an edit filter it seems, but the edits Confirmationhistorian made. See for instance . 45dogs (they/them) (talk page) (contributions) 05:01, 5 May 2026 (UTC)

Basically, this vandal figured out how to replace page content with a warning that looks like an edit filter, and a button that takes you to an AIV report linked by Loriendrew. The vandal then replaced several random templates with this code, functionally blanking all pages on which they were transcluded. See screenshot, a now-revdeleted revision of {{Iowa-radio-station-stub}}. Nyttend (talk) 05:51, 5 May 2026 (UTC)

Has anyone else noticed this? The link WP:SOAPBOX is supposed to go to a section of WP:NOT, but the redirect just drops me at the top of the page. Same thing with redirects to anchors: FumoFumo is supposed to lead to Touhou Project#FumoFumo, but it just leaves me at the top of the page. What gives? Is this a bug?

I'm using Safari on an iPhone 11 running iOS 18.7.7. SuperPianoMan9167 (talk) 20:22, 30 April 2026 (UTC)

I suspect this has something to do with Parsoid as both pages show "Rendered with Parsoid" at the bottom. SuperPianoMan9167 (talk) 20:23, 30 April 2026 (UTC)

I just tried WP:ITSTHURSDAY and it works? Why is it so inconsistent? SuperPianoMan9167 (talk) 20:33, 30 April 2026 (UTC)

It works for me in Safari on iPhone 16e with iOS 26.4.2 PrimeHunter (talk) 22:37, 30 April 2026 (UTC)

It seems to be a Parsoid bug because it works when I turn Parsoid off. SuperPianoMan9167 (talk) 13:16, 1 May 2026 (UTC)

• Can this be reliably reproduced? https://en.wikipedia.org/wiki/Wikipedia:SOAPBOX?useparsoid=1 works for me. — xaosflux ^Talk 14:17, 1 May 2026 (UTC)

  @Xaosflux: I think it's a problem specific to Minerva skin. Try switching to mobile view. That link doesn't work for me in mobile view.

  These results are consistent:

  • Vector 2022, legacy parser: works
  • Vector 2022, Parsoid: works
  • Minerva Neue, legacy parser: works
  • Minerva Neue, Parsoid: doesn't work

  I mentioned this issue in the quick survey that popped up since I have Parsoid force disabled. SuperPianoMan9167 (talk) 14:26, 1 May 2026 (UTC)

  SuperPianoMan9167, it works for me on desktop (Librewolf) if I switch to the mobile view, and on my phone (Fennec). Have you tried logging out? — Qwerfjkltalk 14:37, 1 May 2026 (UTC)

  @Qwerfjkl: Just tried that. Same issue: some redirects to sections/anchors fail to scroll down to the section/anchor when using Minerva Neue and Parsoid. It's probably specific to Safari. What makes this really strange is that some redirects, like WP:ITSTHURSDAY, work, but the section header ends up in the middle of my screen instead of at the top like it's supposed to. SuperPianoMan9167 (talk) 14:44, 1 May 2026 (UTC)

  https://en.wikipedia.org/wiki/Wikipedia:SOAPBOX?useparsoid=1&useskin=minerva seems to work for me - logged in or logged out. We can get a bug opened, but need to be able to identify the failure more as best as possible. — xaosflux ^Talk 14:58, 1 May 2026 (UTC)

  What version of Safari are you using? — xaosflux ^Talk 14:58, 1 May 2026 (UTC)

  Safari 18. SuperPianoMan9167 (talk) 15:01, 1 May 2026 (UTC)

  If it helps, I can make a screen recording and email it/attach it to a bug report. SuperPianoMan9167 (talk) 15:06, 1 May 2026 (UTC)

  @Xaosflux Screen size seems to matter for this. I managed to reproduce this on my computer by using device mode on the Chrome dev tools to emulate a phone screen. So to make this happen I think you need Parsoid, Minerva and the right screen size. Warudo (talk) 21:43, 1 May 2026 (UTC)

  Actually, that's still not enough to reproduce reliably. I had to change to the mobile view too. Just "useskin=minerva" on its own was not enough. Warudo (talk) 21:49, 1 May 2026 (UTC)

  https://en.wikipedia.org/wiki/Wikipedia:SOAPBOX?useparsoid=1&useskin=minerva&mobileaction=toggle_view_mobile isn't failing for me either - is this only a problem on a certain browser? — xaosflux ^Talk 00:55, 2 May 2026 (UTC)

  Using this link I can't reproduce the issue at all no matter what. What I did to make it happen was switch to mobile view first using the link at the bottom of the page and then open e.g. https://en.wikipedia.org/wiki/Wikipedia:SOAPBOX?useparsoid=1 from the mobile interface (with device mode enabled). However, even doing that fails to reproduce the issue with https://en.wikipedia.org/wiki/Wikipedia:SOAPBOX?useparsoid=1&useskin=minerva&mobileaction=toggle_view_mobile. Warudo (talk) 02:17, 2 May 2026 (UTC)

  I can corroborate that these results are consistent with the results from an actual mobile device. That second link works correctly while the first one doesn't. SuperPianoMan9167 (talk) 02:20, 2 May 2026 (UTC)

  Interestingly, the second link does not create the "Redirected from [title]" popup like it's supposed to. SuperPianoMan9167 (talk) 02:26, 2 May 2026 (UTC)

  As for specific browser, no. I did this on both Chrome and Firefox, it's just that the steps to make it happen on desktop are very specific. Warudo (talk) 02:19, 2 May 2026 (UTC)

  It seems that the combination of Minerva + Parsoid + mobile screen size + certain page titles causes redirects to sections and anchors to fail. This is a very bizarre bug. SuperPianoMan9167 (talk) 02:22, 2 May 2026 (UTC)

  This is a fascinating bug. @SSastry (WMF) and @Jon (WMF) and I are going to work on this. It doesn't look like a Phabricator task has been opened for this yet, so I've done so: ⚓ T425290 Section links (HTML #anchors) don't work on mobile + Parsoid + minerva + specific screen sizes. Feel free to add information here, or contribute it to the thread.

  My first wild idea: is it possible that the mobile skin is setting display: none in CSS on certain elements of the UX which just "happen" to be holding the id="...." attribute which we are navigating to? It's also worth noting that we are in years-long transition to "new" HTML5 anchors, with a much wider set of allowed characters, from the older anchor style which percent-encoded quite aggressively and made the anchors unreadable, especially in non-Latin-script languages. So if the section title contains certain characters our HTML contains two separate anchors for each section, the "new" anchor and the "legacy" anchor (with percent encoding). It's possible that the element being hidden by the CSS is only one of these, which would explain why some anchors seem to work and others don't. Any further information you can help provide to make this bug reproducible will help!

  @Purple Vortex asked below "how long will this take to fix" and I'll answer here just to keep the discussion together: generally the MediaWiki "train" deploys to English Wikipedia on Thursday, as per the Wikipedia:ITSTHURSDAY link posted above. So assuming we find a fix before the train cutoff Monday night, and it rides the usual train, you'd expect to see a fix sometime on Thursday (the exact deploy time varies depending on the timezone of the deployers that week). A bug like this would typically warrant a backport, though. We have separate backport windows throughout the day, but I personally tend to use the one at 4pm Eastern Time. Hard to give more precise timing until we've identified more clearly what's going wrong and have a fix in hand. C. Scott Ananian (he/him) (talk) 16:58, 3 May 2026 (UTC)

  (If folks want to investigate this further, https://www.mediawiki.org/wiki/Heading_HTML_changes describes our heading/section markup on desktop. Mobile has always tweaked this to add things like collapsible sections, and there is an ongoing discussion about (a) trying to unify the mobile and desktop markup, and (b) trying to make the mobile markup as accessible as the desktop markup is. Happy to discuss both of those efforts in more detail, but let's fix this bug first.) C. Scott Ananian (he/him) (talk) 17:55, 3 May 2026 (UTC)

  A fix for this has been merged to master (change) and a backport to the current deployment branch is pending review (backport). The issue was that sectionCollapsing.js collapsed sections correctly on redirect but never scrolled to the target fragment. H^akan·IST 19:48, 4 May 2026 (UTC)

  The backport has now been deployed. This should be fixed for everyone. H^akan·IST 20:58, 5 May 2026 (UTC)

  I can verify that this is fixed. Thank you so much! SuperPianoMan9167 (talk) 21:02, 5 May 2026 (UTC)

I have placed User:AndyZ/peerreviewer.js's script link on my vector.js page, but the button is not appearing, in source or visual editor. It didn't work via my common.js page either. I am using Vector legacy (2010) in Google Chrome (with JavaScript allowed) on macOS, and I have repeatedly bypassed my cache. Is there a simple solution to this problem? Thanks :) Max263 (talk • contribs) 12:04, 5 May 2026 (UTC)

AndyZ seems to have left Wikipedia around 2008, before the old version of Vector was launched. It doesn't look as if a new maintainer was ever found (1, 2). How did you even discover this script? I don't see it on WP:US/L. ClaudineChionh (she/her · talk · email · global) 12:52, 5 May 2026 (UTC)

Apologies, I discovered at WP:TOPSCRIPTS. I suppose AI can now do the same job (for better or for worse...) but I appreciate the response. Max263 (talk • contribs) 14:05, 5 May 2026 (UTC)

Ah yes – TOPSCRIPTS is a list of most-imported scripts, not necessarily functioning ones. Have a look through US/L as it should be a more accurate list of usable scripts. Don't expect an LLM to be a good judge of content issues. ClaudineChionh (she/her · talk · email · global) 21:57, 5 May 2026 (UTC)

I no longer see "New sitewide requirement to enable Javascript to edit" anywhere on this page. It would seem that someone has deleted it despite no consensus having been reached and several major points not having been addressed (most notably, 1. that it is foolhardy to trust data returned from client-side scripts, especially in any security context, 2. that relying on a third-party for-profit closed-source service opens Wikipedia up to a number of risks, from the vendor upping stakes and leaving us without a ready substitute to the vendor "enshittifying" the service to authoritarian governments pressuring the vendor to in turn pressure us to slant articles in their favor, and 3. that there are modern captcha designs that are open source, do not depend on (let alone trust data from) client-side scripts, and avoid the accessibility and weakness issues of older captcha technologies).

So far as I am aware, deleting a discussion at all violates community norms here, let alone while the matter at issue remains unresolved. I don't see any message around here even acknowledging (let alone attributing, for accountability) said deletion, which is also a breach of norms, though I suppose trawling through this page's history diffs will, with some tedium, reveal the culprit's account name.

I request that the discussion be restored and continued until the matter is resolved, or failing that that it be continued in replies to this post until the matter is resolved. The first paragraph's parenthetical contains the gist of the unaddressed points.

Actually, I would further submit that relying on any single third party service provider of any kind, for any thing, without a substitute ready to go, in and of itself creates a conflict of interest for a project such as this, between keeping said vendor happy on the one hand and neutrally and accurately reporting facts about that same vendor on the other. This conflict of interest can only be avoided if the vendor is quickly and painlessly substitutable rendering the left-hand side of that conflict of interest moot; if the vendor is non-notable so the right hand side of that conflict of interest is rendered moot (but that means it's a small player in a big market, and so almost certainly also easily substitutable anyway); or if the product is open source and you have, or easily can, self-host it so the most that you lose if the vendor goes bankrupt or gets mad at you or something is paid third-party support. So far as I am aware, your questionable adoption of hCaptcha does not meet any of those three criteria. It is mentioned on several Wikipedia pages, in particular, and is in an apparent duopoly with Google, so it definitely doesn't meet the non-notability criterion.~2026-23303-64 (talk) 21:16, 3 May 2026 (UTC)

It was archived by an automatic process in this edit. There was no violation of community norms. When people stop commenting, discussions get archived. MrOllie (talk) 21:22, 3 May 2026 (UTC)

~2026-23303-64, you are shouting into the wind. The volunteers here can not help you in the slightest. If you want support, you will need to contact the WMF (where I suspect you will continue to be shouting into the wind, but you will be shouting in the direction of the right people). Izno (talk) 00:17, 4 May 2026 (UTC)

You can see it here: Wikipedia:Village_pump_(technical)/Archive_229#New_sitewide_requirement_to_enable_Javascript_to_edit. As others said, archiving is how this page works. Gråbergs Gråa Sång (talk) 05:31, 4 May 2026 (UTC)

More importantly, there should be zero expectation that anonymous users should be able to edit the wiki in all circumstances. Unregistered users are a frequent source of disruption and block evasion. If you want to edit without a captcha, you can create an account and do some edits and then you'll never have to enable JavaScript again. hCaptcha is much better than what we had before in terms of accessibility, and there are safeguards around its privacy (see mw:Product Safety and Integrity/Anti-abuse signals/hCaptcha#Privacy safeguards and risks), so there is zero chance it's going to be abandoned due to someone complaining on a village pump. stjn 10:13, 4 May 2026 (UTC)

Then what would be needed to cause it to be abandoned?~2026-23303-64 (talk) 05:38, 6 May 2026 (UTC)

Hey, folks! As we've mentioned before, we're gradually rolling out the use of the new Parsoid wikitext parser on English Wikipedia as part of the WMF Parser Unification project. Just now I turned it on for a fraction (20%) of pages for readers using the Mobile view. I am watching the cache impact of the transition closely, and assuming that everything looks healthy I expect to gradually increase the percentage over today and tomorrow until all Mobile view readers are seeing the Parsoid version of the page. If you want to see this in action, you can check out Fandom_(website), Wikidata, Talk:Wikimedia Foundation, or Talk:Jimmy Wales. The pages included are based on a hash of the page title, so the same pages will consistently use Parsoid but it's a bit random exactly which are included; I just clicked randomly around from Wikipedia until I'd collected a reasonable sample. Check the footer at the very bottom of the page, it will say "Page was rendered with Parsoid" if you're seeing a Parsoid render. If you click over to desktop view, that will go away, since we're not (yet) serving Parsoid by default for desktop views. If you want to be an early adopter, you can opt-in early in your user preferences following the instructions at Help:Extension:ParserMigration. You will also notice new entries in the tools menu for Parsoid-rendered pages: "Switch to legacy parser" and "Report visual bug". We know that Parsoid's rendering is pixel-for-pixel identical to the legacy parser's rendering on the vast majority of pages, but we can't test every single tool, gadget, and user script which you all are using. If Parsoid interferes with your workflow on the projects, "Switch to legacy parser" ought to get us out of your way, but please do use "Report visual bug" and let us know what's wrong so we can work together to fix it. This is a pretty exciting step for me, as I've been working in one way or another on this project for well over a decade, but my fondest hope is that it is completely transparent to you all, and you don't even notice anything's different --- except for the new features we'll be able to roll out later with Parsoid as our base. Thanks for your patience, and happy editing! C. Scott Ananian (he/him) (talk) 23:14, 29 April 2026 (UTC)

I've just clicked onto Mobile view to test it - it looks awful and makes navigation terrible. GiantSnowman 20:28, 30 April 2026 (UTC)

How exactly, and on what page? The page on Wikidata with Parsoid rendering, from a cursory comparison, looks the exact same with the page without Parsoid (using ?useparsoid=0) to me. OutsideNormality (talk) 21:42, 1 May 2026 (UTC)

The whole site looks entirely different. GiantSnowman 08:56, 2 May 2026 (UTC)

They look identical to me as well. Could you perhaps provide screenshots so we can see what's different for you? DLynch (WMF) (talk) 10:32, 2 May 2026 (UTC)

Well for one I have to click a dropdown menu to find my Watchlist... GiantSnowman 11:43, 2 May 2026 (UTC)

Might it be that you're talking about Mobile Web generally, rather than specifically about Parsoid? This thread is specifically about the Parsoid rollout on Mobile Web. OutsideNormality (talk) 16:22, 2 May 2026 (UTC)

Perhaps. Either way, see also #Links not changing colour below regarding bugs on desktop... GiantSnowman 10:26, 4 May 2026 (UTC)

Just gonna keep posting here every day until this is fixed. GiantSnowman 17:13, 6 May 2026 (UTC)

Why is this a thing? Like if I like part of someone's edit but don't like a cut they made, I want to be able to keep that part without reverting the entire thing, but I can't because when I try to copy the cut part, it pastes with a strikethrough in it that I have found no way to remove, and if it's a large scale edit with lots of little pieces that can't be easily rewritten manually, it means I have to revert the entire thing over potentially only a minor issue. Absolute hall monitor technology. Snokalok (talk) 21:47, 5 May 2026 (UTC)

It marks the content as semantically deleted (<del>...</del>), so that accessibility agents can indicate that information to their users. Izno (talk) 22:08, 5 May 2026 (UTC)

Is it possible for you to switch to the source editor and remove the <del> tags? Otherwise, yeah, I agree that Wikipedia should really have a way to revert/keep block-by-block if possible. Chaotic Enby (talk · contribs) 22:12, 5 May 2026 (UTC)

@Snokalok Install m:User:Jon Harald Søby/diffedit, it lets you edit the top revision(s) straingt from the diff. Ponor (talk) 22:13, 5 May 2026 (UTC)

This can be avoided by using "Paste without formatting" or other similar features of text editing parts of browsers. In Firefox on Windows and Linux, the shortcut is Ctrl+⇧ Shift+V. —⁠andrybak (talk) 22:14, 5 May 2026 (UTC)

@Snokalok: I guess you refer to edits made with the reply tool. Click "Source" to the top right of the reply box and remove something like <s>...</s>, <del>...</del> or {{strikethrough|...}} around the copied text. You can click "Visual" afterwards to return the normal state of the tool. PrimeHunter (talk) 22:20, 5 May 2026 (UTC)

After examining your recent edits I guess it wasn't actually the reply tool. This is why the edit notice of this page says: "Where did you encounter the problem? Please add links when possible." PrimeHunter (talk) 22:26, 5 May 2026 (UTC)

Snokalok, I'm not sure what you're talking about. When I view past diffs and copy content from them, it always pastes without markup tags. I've just reverted https://en.wikipedia.org/w/index.php?diff=1352916849 (don't worry, I'll put it back momentarily), and when I copy the text banner at the top of the page in Wikipedia and paste here, it just pastes as text, with no markup. I've never seen any markup get pasted along with text, aside from situations when markup tags were in the text that I copied. Nyttend (talk) 01:23, 7 May 2026 (UTC)

It works in the way User:Snokalok described in the visual editor. Both when editing a page separately (sandbox), and in the "Visual" mode of the reply tool. —⁠andrybak (talk) 01:29, 7 May 2026 (UTC)

Oh, this is some Visual Editor thing? Never used it. Nyttend (talk) 01:33, 7 May 2026 (UTC)

I am seeing a banner at the top of the page in Wikipedia asking me to “confirm my email address”. I have gone to my preferences in Wikipedia and learned that the email address for my account is one that I no longer have access to. I have then gone to “email options” and clicked on “change or remove email address”. This asks me to log in again, and when I do so, it sends a verification code to the email I no longer have access to. A note here says if I am having trouble receiving this code, I can “recover my account”. When I click on the link to recover my account, I get a permission error saying I cannot do this while logged in.

My question is: Is there a way to change my email address when I have no access to my current email address? Volutin (talk) 01:04, 7 May 2026 (UTC)

Volutin, are you 100% certain that you'll be able to log in again if you log out? If not, here's an idea — probably it won't help, but it can't hurt — log out and see what happens when you try the recover-my-account option. Nyttend (talk) 01:40, 7 May 2026 (UTC)

Well there's the risk of being stuck out of the account, unless I read this wrong? Chaotic Enby (talk · contribs) 01:45, 7 May 2026 (UTC)

Chaotic Enby, if you know your password and haven't set up 2FA with your unavailable email address, you wouldn't necessarily be locked out of your account. Nyttend (talk) 02:24, 7 May 2026 (UTC)

I logged out of my account, but could not find a way to recover my account after logging out. I could not log in again through Safari, as it required a code to be sent to the email I no longer have. I tried going to create a new account, but my IP address was blocked after logging in with the new account details (even though I have turned off private relay). I have been able to log in via Chrome using my old account credentials. I guess I will just ignore the banner and hope I can continue using my old account without a verified email until Wikipedia shuts me out completely at some point in the future? Volutin (talk) 02:09, 7 May 2026 (UTC)

Something you could do right now is add {{Committed identity}} to your userpage so you can later prove your identity if you get accidentally logged-out completely. Additionally, once that's done, I invite you to email cawikimedia.org to see which steps you can take. Chaotic Enby (talk · contribs) 02:22, 7 May 2026 (UTC)

[edit conflict] Volutin, wait a while and create an additional account (e.g. User:Volutin alt), and use your main account to mark that account as an alt. (Use an InPrivateBrowsing window to do it, just in case your browser gets confused between the accounts, although that won't help with Wikipedia-imposed IP restrictions.) This won't help with retaining access to your existing account, but if you ever do get shut out completely, this will ensure that everyone recognises the alt account as yours, so your permissions can transfer, and you can use the alt account to make requests related to this account. At worst, if you do this and then get locked out, you could ask the stewards to rename your accounts, so that "Volutin" became "Volutin old", and "Volutin alt" became "Volutin". (I assume they'd consider this; I'll leave a note on their noticeboard.) Still not ideal, but at least you'd continue to be treated as the same person. Nyttend (talk) 02:24, 7 May 2026 (UTC)

There's supposed to be a link to Special:AccountRecovery on the page about the email code. That's probably the one you mentioned earlier with the permission error. Since you're logged out in Safari, you should be able to use that form in that browser. Anomie⚔ 11:08, 7 May 2026 (UTC)

Is there a way to opt out of today's change to how the watchlist star button at the top of each page works? Not really a fan. Extraordinary Writ (talk) 20:24, 30 April 2026 (UTC)

I haven't checked on desktop yet, but on mobile browser when I hit the star, the box that pops up is about 60% off the edge of my phone screen. Trying to zoom in or scroll around does nothing to improve visibility. Sarsenet•he/they•(talk) 22:46, 30 April 2026 (UTC)

I have not seen that particular issue on desktop but others report they have (phab:T417847#11877654). Warudo (talk) 09:24, 1 May 2026 (UTC)

Still, the change is so broken on my side that I hope they revert it entirely. Warudo (talk) 10:35, 1 May 2026 (UTC)

Ouch. So many steps to watch or unwatch a page, and so buggy. Not sure I'll ever want to touch the watchstar again. Ponor (talk) 11:25, 1 May 2026 (UTC)

Ouch. This is in Vector2010 as well. Clicking the star when a page is not watchlisted appears to bring up exactly the same dialog as clicking the star when a page is watchlisted, which is the one with the "Unwatch" confirmation. CMD (talk) 12:10, 1 May 2026 (UTC)

Big oof, this isn't okay at all! — Fourthords | =Λ= | 12:42, 1 May 2026 (UTC)

Same with Monobook. If I click watch/unwatch instead of the desired action, I get a popup window and have to click once more to actually get that action. I don't use labels and everything on my watchlist is permanent, so this is a complete waste of time/mouse clicks/mouse movements for me. At aa minimum this should be opt in or easy to remove in my preferences. --Randykitty (talk) 12:49, 1 May 2026 (UTC)

I'll add my complaint also. (Using Monobook) Unwatching used to take one click, now it takes three - "Unwatch" tab, then "Unwatch" button in the "Organize watchlist" dialog, then X/Close the confirmation dialog telling me that the page has been removed from my watchlist. Not happy. Mitch Ames (talk) 13:00, 1 May 2026 (UTC)

Same. Not a fan of this change. Timur9008 (talk) 13:05, 1 May 2026 (UTC)

It's horrible. Really horrible. Bin it. DuncanHill (talk) 14:42, 1 May 2026 (UTC)

FYI: feature request T425116: Watchstar popup "Organize watchlist" should close when pressing the Escape key has been created. —⁠andrybak (talk) 14:41, 1 May 2026 (UTC)

That's a good idea. Additionally, I found that "Organize watchlist" was confusing. I wanted to watch a page temporarily. I got the box – fine; I needed it this time – and I change the drop-down menu to the time, and, um, now what? Do I "X" out of the box, which feels like it should cancel my change? Where's the "all done and please save my changes" blue button? WhatamIdoing (talk) 19:56, 1 May 2026 (UTC)

Initially it was supposed to be a non-blocking popup next to the star itself but they discovered some issues with Codex library on mobile and with certain sizes so they switched to a different style without updating the wording. So, not intentional that it doesn't make sense. stjn 22:13, 1 May 2026 (UTC)

+1 for "please give us a way to disable this", it actively slows me down when watchlisting anything. CoconutOctopus talk 19:27, 1 May 2026 (UTC)

+1. Best, Barkeep49 (talk) 20:07, 1 May 2026 (UTC)

+1, I watchlist every halfway interesting article I come across, so all these forced popups and buttons make my experience much worse Sketchsynth (talk) 20:17, 1 May 2026 (UTC)

+1 I need a way to disable this. I use the star a lot to take things on and off of my watchlist and it used to take one click to do it (click the star, you're done) and now it takes three, in different areas. You click the star, you get the "Organize watchlist" box (I do not want this, why am I getting this?) and then once you click the button to watch/unwatch, you then get a confirmation dialog box that you need to dismiss. I know each extra click doesn't maybe seem like much, but for power users it's a significant disruption in what should have been a microsecond interaction. I looked in the preferences and did not see another way to make this go away so I came here. I can definitely understand wanting to give people a way to organize their watchlist, but this is not the place to put it or the way to do it. Either consider making it another watchlist preference or consider removing it entirely. Jessamyn (my talk page) 22:31, 1 May 2026 (UTC)

Thank you all for this helpful feedback, we recognize this is an issue. The people who can help with this are offline for the day, but I'll flag this to the team to make sure someone gets back to you early next week. Thanks for being patient with us. SPerry-WMF (talk) 21:38, 1 May 2026 (UTC)

+1. ChaoticV (converse, contribs) 02:41, 2 May 2026 (UTC)

+1 Whenever I scroll up pass the navbar, the "Organize watchlist" window pops up if initialized (in desktop mode). Labratscientist (talk) 05:43, 2 May 2026 (UTC)

I've seen this also (using MonoBook on Firefox 113.35.1, Windows 7) - click Unwatch tab, Unwatch button, close dialog; then scroll down to bottom of page, then back up - "Organize watchlist" dialog pops up again, and article has been re-added to my watchlist! Mitch Ames (talk) 06:44, 2 May 2026 (UTC)

Here's a strange thing. At the top of this page, the blue star (or unwatch tab, depending upon skin) is a link to https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=unwatch and that fires the popup, meaning I need an extra two clicks, as described above. But at Preferences → Watchlist I have the "Add direct unwatch/watch markers (×/+) to watched pages with changes (JavaScript required for toggle functionality)" option enabled, which at Special:Watchlist adds a little "×" icon on every row. This icon also has a link, and that link is https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=unwatch - which is exactly the same URL, but when clicked, carries out the action immediately, without the double confirmation steps. So, on normal pages, something is intercepting that link to add the popups. This suggests that a preference could be created to prevent the interception, suppress the popup, and so restore the previous behaviour. --Redrose64 🌹 (talk) 21:38, 1 May 2026 (UTC)

That's two separate features and the watchlist one isn't default so many people don't even know about it or use it. stjn 22:10, 1 May 2026 (UTC)