If you want to report a JavaScript error, please follow this how-to page. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for 5 days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker. An offline spellcheck of all articles is run by Wikipedia:Typo Team/moss; human volunteers are needed to resolve potential typos.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Hey everyone – due to a critical security advisory about the PHP language (which we depend on), many Wikimedia services are going to be affected. We are hoping to avoid downtime to the wikis, but some supporting tools and services are unfortunately going to be impacted. This is a complex operation on short notice and we are still figuring out the details. More information will come later this week. Johan (WMF) (talk) 21:55, 20 October 2026 (UTC)Reply
Thank you for your patience as we've been dealing with this security issue. It's been a lot of hard work, for the Wikimedia technical community and the web in general.
Toolforge and Cloud VPS have been back up since last Thursday, 22 October. Many key tools the editing communities depend on have been gradually restored.
Some tools need the respective volunteer maintainers to restart them. Others still need to upgrade to a patched PHP version – some tools were using older versions of PHP which are not supported by the recent security patches, and these will require maintainers to carefully upgrade to a more recent version, which might require additional effort to make them compatible. You can follow the work on Wikitech. Johan (WMF) (talk) 15:57, 28 October 2026 (UTC)Reply
In response to the recent PHP security advisory[0], we are temporarily disabling all network access for Toolforge and Cloud VPS pending security patches.
As security patches get deployed we plan to incrementally re-enable services. Initial efforts will be focused on securing Toolforge, but if you are 100% sure that your project uses no PHP please contact us
directly and we’ll put you on the short list.
This is likely to be a prolonged outage which will depend on a lot of coordination with project and tool admins. This is not ideal, but is the best option among those currently available.
Well, this answers some of the questions that drew me to this page. Please keep the communication open and alert us to any progress made or obstacles that come up. Thank you. LizRead!Talk!00:12, 21 October 2026 (UTC)Reply
For people following along: We have a two-pronged approach to getting services back up.
Toolforge:
We're working on making the Toolforge build service smart enough to block launching of PHP tools so that we can start launching non-php things safely. Next, we'll figure out what to do about tools that rely on unfixed/unfixable PHP versions. We hope to have partial (php-free) Toolforge functionality restored sometime in the next 24 hours.
Cloud-VPS:
We're currently focusing on projects maintained by WMF staff and/or NDA users, since we have more flexibility to adjust those projects to our current safety standards. Our team is auditing projects one by one with the goal of starting up those projects that don't use PHP at all ASAP. After that we'll look at patching projects that use PHP in some form - we'll do so to the best of our ability and understanding of each project, with a focus on security rather than fully enabled functionality at first - and after that we will face up to the projects that rely on unfixed PHP versions. This whole process will likely take a few days for most projects which have a simpler path to safety, and a few weeks for the most complex ones. We might start contacting some maintainers for support as we start working on their projects.
Both:
It's worth noting that while we're still focused on the wider platform functionality, we're hoping to use your input on specific tools at some point, so thank you to everyone who has been contributing to the talk page[0].
All of these timelines should be interpreted very loosely -- any new surprises will delay things. We appreciate your continued understanding and support as the WMCS admins continue to work diligently to bring as much as possible back up as quickly and safely as possible.
We are happy to announce that Toolforge is available again for users.
We don't have yet images with patched php or have updated the buildpacks to be able to build images with php, but non-php jobs and webservices are free to run once again.
We will update as soon as possible once we have patched images for webservice and can allow build service images that use php back, but until then, please refrain from trying to work around the guardrails we have put in place.
There might be other things still not working completely, as not all CloudVPS is online yet, but please reach out with any issues you find and we'll try to help get you unblocked, though please be patient as we are still working on bringing some of the system online.
Our availability across timezones is also limited, and we're trying to make sure the team can get some rest in between all the effort we're applying, so any and all questions can take a while to get back to.
Thanks you very much for your patience and your effort, it's really appreciated.
The wikis were temporarily affected by related maintenance work, but the link above should remain the best place for updates about which tools remain offline and which have been fixed. Johan (WMF) (talk) 18:14, 21 October 2026 (UTC)Reply
I'm assuming that it's still down, perhaps? Tried to visit these links:
but it reports an error about the services being unable to be reached, and telling me to contact a maintainer, without stating who a maintainer is in this instance (but including instructions for maintainers):
Error
This web service cannot be reached. Please contact a maintainer of this project.
An autopatrolled user, checkuser, and administrator, 22 years old, with 103,715 edits. Last edited 14 minutes ago. From Wikipedia, the free encyclopedia.
I'm unable to find a link to https://xtools-ec.toolforge.org in my ArticleInfo gadget, neither by manually testing nor by looking at the code. Perhaps you are loading an old/beta/weird version of the ArticleInfo gadget?
and for the very beginners, PHP is the absolute essential foundation software Wikipedia needs to run. The whole of Wikipedia cannot operate without PHP. MilkyDefer07:26, 21 October 2026 (UTC)Reply
Also just noticed that many images aren't displaying on en.wiki, although when you click through to Commons, they seem fine there. Presumably that's somehow part of this. -- DoubleGrazing (talk) 15:23, 21 October 2026 (UTC)Reply
Down for me. But this is expected, they will selectively allow certain blocks of IPs to work (sites, services), check logs if any exploits come in, move on to the next. -- GreenC15:59, 21 October 2026 (UTC)Reply
I see also that image issue now. It looks like it's just previews - when reading the articles the thumbnails seem to load just fine, but when I click into the preview it goes black. Then, on Commons the preview also doesn't load but the image does. Chorchapu (talk|edits) 15:38, 21 October 2026 (UTC)Reply
All my non-PHP tools on toolforge required a webservice restart to get rid of that error. Refill looks like it's node.js based, so Novem Linguae probably just has to give it a good kick to get it running again. --Ahecht (TALK PAGE)21:51, 22 October 2026 (UTC)Reply
Even though Toolforge is back up, for the most part, AIUI the owners of each tool/bot still need to update their individual tool to get it working again. Chorchapu (talk|edits) 22:23, 22 October 2026 (UTC)Reply
For non-PHP tools nothing needs to be done other than a restart. For PHP tools, if they're using a patchable version it should be similar once WMCS updates the images over the next few days, but otherwise tool owners will need to update their scripts to support a more modern version of PHP. That being said, for non-PHP tools, this is a good opportunity for tool owners to update them to the latest versions of their languages. --Ahecht (TALK PAGE)23:41, 22 October 2026 (UTC)Reply
The Excel-to-Wikitable tool on Toolforge is still down. When I copy a spreadsheet into the tool, it says no healthy upstream. Do I need to ask the owner of the tool when it will be available, or can that question be answered? Robert McClenon (talk) 05:18, 23 October 2026 (UTC)Reply
I think Toolforge PHP is still disabled. We should circle back to this when the cloud-announce mailing list says that safe PHP versions on Toolforge have been restored. –Novem Linguae (talk) 05:50, 23 October 2026 (UTC)Reply
I am the owner of a tool. That tool also says no healthy upstream. If you asked me when it will be available I wouldn't know the answer. I think owners are meant to add the tool to this list. I think that has already happened for Excel2Wiki Sean.hoyland (talk) 05:53, 23 October 2026 (UTC)Reply
It's back up, and I took the opportunity to rewrite it entirely in Javascript so there's no server-side processing or dependency on PHP. --Ahecht (TALK PAGE)21:24, 23 October 2026 (UTC)Reply
As User:Ahecht notes, the tool has been rewritten. There is no longer a button to push to request the conversion. The conversion happens immediately on pasting the spreadsheet into the space. This is good, but is a surprise. Existing links to the tool work, but existing pages of the tool do not work, and must be relaunched from links. Thank you. Robert McClenon (talk) 23:29, 23 October 2026 (UTC)Reply
I'm a big user of the Wikipedia Library wikipedialibrary.wmflabs.org which is not available currently. Same problem? Any timeline to fix it? Thanks.Bob (talk) 20:13, 23 October 2026 (UTC)Reply
I am unable to git push to gitlab.wikimedia.org/toolforge-repos. I am getting a "ssh: connect to host gitlab.wikimedia.org port 22: Operation timed out" Hawkeye7(discuss)23:32, 27 October 2026 (UTC)Reply
Some of those are functioning bots that had placeholder/not-very-important webservices. But a lot of them are things that were important to someone at some point, but now may never run again. If you rely on any of these tools, and the maintainer doesn't seem to be around, please mention it here so that folks might be able to get the ball rolling on the wikitech:Help:Toolforge/Abandoned tool policy. AntiCompositeNumber (they/them) (talk) 05:47, 5 November 2026 (UTC)Reply
CopyPatrol is one of the more important tools. Every couple days I try logging in and it fails. I'm hoping that maybe I'm accessing it wrong – I looked at the status report for other tools and don't see any mention.--S Philbrick(Talk)14:28, 5 November 2026 (UTC)Reply
Given this has come up multiple times, it might be worth putting together a page somewhere that lists the old and new URLs that can be found when someone searches for the tool name and/or the error message they see. Thryduulf (talk) 22:19, 9 November 2026 (UTC)Reply
Yeah, this sounds like what happened with xtools (see above). Given a choice between updating links to point to the new one vs fixing the redirect, updating the links seems like the more logical plan. RoySmith(talk)23:00, 9 November 2026 (UTC)Reply
The likelihood that we will be expanding the reach of {{cite Q}} I estimate is about 0. So, it has no chance of being a default gadget any time soon. Izno (talk) 21:03, 30 October 2026 (UTC)Reply
Cite Q is and always has been an ill-behaved and underdeveloped template that has caused CITEVAR issues. Just to check if anything had changed, I clicked on four articles at random from its "What links here" list, and found Cite Q CITEVAR problems and related inconsistency at Frances Abington, Edible mushroom, Atrial natriuretic peptide, and William Dampier. Four out of four. This template being used in over 17,000 articles is a problem for people who care about consistent presentation of citation information. – Jonesey95 (talk) 21:57, 30 October 2026 (UTC)Reply
"Simple author fixes at the Wikidata end" is an oxymoron. Nothing on Wikidata is simple and fixes on Wikidata are often reverted because they were inconsistent with some other database somewhere else. —David Eppstein (talk) 01:01, 13 November 2026 (UTC)Reply
Some issues. Cite Q only exists in 78 languages while cite journal is in 237. This is going to be an issue for those of us involved in translation.
When one looks at the Wikitext like <ref>{{cite Q|Q38897648}}</ref><ref>{{cite Q|Q104102440}}</ref> one has no ability to see the metadata. Ie what journal is this, what was the year of publication, all critical to determine reliability. One has to go back to the article text to see the reference which makes editing difficult.
Would need global templates and would need the lake of metadata in wikitext mode solved before this template should be used IMO. Doc James (talk · contribs · email) 22:32, 30 October 2026 (UTC)Reply
Cite Q is available to any project which wishes to use it and works in any language which Wikidata supports - which is far more than 237.
Your second paragraph is addressed in the template documentation.
I think this would be good - Cite Q's quite a mature template now, and it's widely used across many different language Wikipedias. There's been ongoing conversation in particular re Doc James's points in T289287. Thanks. Mike Peel (talk) 20:25, 2 November 2026 (UTC)Reply
Cite Q still breaks multiple different things, imports broken cites and improperly formated references. It use shouldn't be expanded until it's properly fixed. Beyond that editors shouldn't have to go to a different project just to change something on Wikipedia, but that's a different discussion. -- LCU ActivelyDisinterested«@» °∆t°14:27, 5 November 2026 (UTC)Reply
If I want to format the way an image is displayed on Wikipedia I don't have to edit Commons. If that was the case I would argue for images to be uploaded locally, as that would be a ridiculous situation. -- LCU ActivelyDisinterested«@» °∆t°11:42, 8 November 2026 (UTC)Reply
If you want to change how a citation using Cite Q is formatted you can do so on Wikipedia.
If you want to crop or rotate (by a few degrees) an image transcluded from Commons, that is where you must do so.
If you want to replace an image transcluded from Commons with one where the white-balance is adjsuted, that is where you must do so.
You can not change the details that cite q imports from wikidata, the example of commons is not the same. That some editors like editing wikidata as well is not a reason to impose it in other editors. -- LCU ActivelyDisinterested«@» °∆t°22:43, 8 November 2026 (UTC)Reply
It was you who chose to bring up the issue of formatting.
Svg images such as those I gave as examples import data from Commons, which cannot be changed, so yes, that example is the same.
Who is imposing Wikidata on whom, exactly? If you don't like editing Wikidata, then don't use Cite Q, use something else. I like editing Wikidata, and see it as a self-improving ever-incrementing thing much like Wikipedia itself, and so Cite Q is something I very much enjoy building and using, and many other editors I know do in fact like to use it too. So I'd much prefer it if you didn't go around undoing many people's hard work by, for instance, converting Cite Q to other citation templates. Such an action would make a lot of people I know very unhappy. Besides, rather than all this unhelpful and somewhat hysterical invective, I would rather that you were more constructive, and perhaps instead list what you don't like about it, so we can improve it. In the last two months, I've fixed almost all of the items on @Headbomb's laundry list (archived), so if you could kindly itemise exactly how Cite Q makes you sad, I'd be more than happy to fix those things as well. — Jonathanischoice (talk) 04:06, 9 November 2026 (UTC)Reply
Anyone using cite Q on anyone who doesn't want to also edit on Wikidata, and wants to modify the the citation being used in Wikipedia. I don't convert cite Q that would be a violation of CITEVAR, something that editors who go around adding cite Q to articles appear to miss. Something that makes a lot of editors I know very unhappy. Issue with the template, one that doesn't have full community support per the box at the top of its own documentation, are continually ignored or handwaved, go back to its talk page if you want examples or the many discussions on it. -- LCU ActivelyDisinterested«@» °∆t°13:07, 9 November 2026 (UTC)Reply
No. A bot that regularly turns all Cite Q templates into regular local citation templates would be a good thing though. We should limit the times people need to edit Wikidata to correct errors on enwiki to the absolute minimum, not burden articles with errors like "{{Cite Q}}: QID parameter must be supplied as "Q" followed by digits, e.g. Q12345 (help): Missing first/last names in Wikidata" (apparently this error happens in 3000 of the 18000 articles which use Cite Q, so not a rare occurrence). Fram (talk) 14:43, 5 November 2026 (UTC)Reply
The missing name errors were added recently as a result of much better name handling. We are working on the backlog; it was over 4000 when the changes went in, and will hit zero in a few weeks at the current rate. Fixing these errors also improves the data in Wikidata, so you could always roll your sleeves up and help, rather than complain about it here. I find the idea of converting Cite Q to local templates very short-sighted and strange. — Jonathanischoice (talk) 03:33, 8 November 2026 (UTC)Reply
No, if someone vandalises a Wikipedia reference I can very easily correct it. If someone vandalises a Wikidata reference I won't even notice it. Wikidata still has the issue of BLPs being connected to pornography despite not being pornographic actresses Maybe you should solve that issue before attempting to push more Wikidata rubbish onto WP? Traumnovelle (talk) 04:33, 7 November 2026 (UTC)Reply
@Traumnovelle: You just enable Wikidata in your enwiki watchlist, and revert vandalism there if needed (which is rare in my experience)? I've checked the Wikidata item you linked to, and can't see any signs of it being connected to pornography?
@Headbomb: personally I wish that Cite Journal was discouraged everywhere. Having worked in academia for 20 years now, Wikipedia is pretty much the only time I've had to manually write out a reference (or use a tool to hard-code it in the article), rather than just using a bibcode and a database that I can maintain centrally (e.g. preprint -> journal article) - and that's what Wikidata now provides us with here.
In general I wish we could avoid rhetoric and disinformation when talking about Wikidata, and focus more on the pros and cons... Thanks. Mike Peel (talk) 22:13, 7 November 2026 (UTC)Reply
If you do enable Wikidata edits, you'll immediately see that there's onehelluvalot of irrelevant junk going through before you spot something that deserves attention. Stuff like descriptions in some language you simply cannot comprehend. Or "badges" - which seem to be something like featured article. It just clutters up the watchlist. In short: can't see the wood for the trees. --Redrose64🌹 (talk) 22:26, 7 November 2026 (UTC)Reply
Yah there was a request to be able to watchlist only those parts of Wikidata used specifically on Wikipedia. Right now I think if one adds Wikidata to your watchlist it shows every single change to the Wikidata item. Not sure were that request is at. Doc James (talk · contribs · email) 22:28, 7 November 2026 (UTC)Reply
There's two parts to this. The first is the change I experience the most as an active researcher: references change from preprints to journal references. That's probably less relevant for enwiki since it lags behind. The other is when references become outdated (withdrawn/replaced), e.g., see Wikipedia:WikiProject Medicine/Cochrane update. This is something I've been supporting through Wikipedia:WikiProject Medicine for many years now through my bot as an interim measure, but I'd love to see transitioning to a proper solution such as Cite Q in the future. Thanks. Mike Peel (talk) 23:21, 7 November 2026 (UTC)Reply
RetractionBot looks really useful, but let's approach the edits from that tool from the general approach taken in this conversation so far. And sorry @Samwalton9 and Mdann52: in advance. First off, it's only working on enwiki - a far cry from the minimum standard here of the 78 languages that Cite Q supports, and of course, 1 is very much less than 237. It's making random edits like removing https in favour of http, and removing unused parameters. I think we all want things to work on-wiki first rather than relying on external tools, and that's where Cite Q helps: everything is on-wiki either here or on Wikidata, and you can track and fix any issues on-wiki. Thanks. Mike Peel (talk) 21:48, 8 November 2026 (UTC)Reply
I shouldn't have to do that. I removed the item because its obviously an issue for a BLP to be connected to pornography. The more integrated Wikidata becomes with Wikipedia the more desirable it becomes to vandalise it. Traumnovelle (talk) 07:27, 8 November 2026 (UTC)Reply
Ah, this edit? That was definitely a bad edit, and thanks for reverting it. It doesn't have anything to do with Cite Q, though. With your last sentence, there's a trade-off with visibility: the more visible something is, the more quickly any vandalism will get reverted. That's kinda fundamental for how Wikipedia operates. Thanks. Mike Peel (talk) 21:29, 8 November 2026 (UTC)Reply
The old "vandalism isn't really an issue on Wikidata" claims... Since 5 November, thanks to Wikidata, the infoboxes on Catalan, Welsh, Basque, Norwegian, Romanian, Hungarian, Swedish, Greek, ... all claim that Blake Lively is married to Justin Baldoni since 2012. Apparntly the high visibility (famous person, shown on many wikis) did nothing to catch this rather blatant BLP violation for over a week now. Lower visibility vandalism remains much longer, as witnessed by the 1412 children of Fyodor Vasiliev on his Spanish article: Wikidata vandalism from september which stayed for nearly 2 months and which remains visible on eswiki due to caching delays.
The 4 November edit you link to for Himmler shows the Monge birth name being added as deprecated. If malformed templates on certain Wikipedias are displaying deprecated values, that's a local issue for those Wikipedias to fix. It wouldn't happen on this Wikipedia (and if if did, it would rapidly be corrected). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits; 14:00, 13 November 2026 (UTC)Reply
I support adding this as a non-default gadget but oppose making it default. Clearly to what degree to use Cite Q bitterly divides the community and has for a very long time. The best way to reflect that divide is to let people who want to use it enable it while not forcing those who don't to do so. * Pppery *it has begun...23:38, 7 November 2026 (UTC)Reply
MDWiki appears to be a fork of enwp - what's going on with that? And why would you bring it up in a conversation about on-wiki tooling? Thanks. Mike Peel (talk) 21:20, 8 November 2026 (UTC)Reply
Yes it is partly a fork developed to assist in translating health content to languages other than English, as EN WP did not want to be used for that purpose. Andy says Cite Q could be easily made to work. Happy to hear how. P.S. a significant portion of non EN WP health articles have come into existence via this process. On the topic of Commons, it works beautifully on any MediaWiki install. Unfortunate that WikiData is not the same. Doc James (talk · contribs · email) 01:54, 9 November 2026 (UTC)Reply
There is a bit of confusion in the diff post, and it is unclear if that is due to the LLM or a feature of the gadget. The diff post says "AutoCiteWikidata uses this structured information to create citations through the Cite Q template" and a couple of similar statements as well as "The tool attempts to identify the underlying work and retrieve its bibliographic information". However, the discussion above suggests that the tool is simply finding if a certain url/doi/pmid/isbn/etc. is associated with a specific Qid, rather than putting structured data into a citation or retrieving bibliographic information. Maybe it can do both? They are very different processes, with different implications for use. CMD (talk) 14:33, 8 November 2026 (UTC)Reply
Latest comment: 8 hours ago12 comments6 people in discussion
Hello, I'm Maryana, a WMF Product Manager. We’re planning to add a new way to share Wikipedia articles on mobile web: a dedicated Share button and Share Card.
Screenshot of what the new share button on mobile Wikipedia looks like. The new button is to the right of the (locked) edit button in this screenshot.Screenshot of the share card that appears after tapping the share on mobile Wikipedia. Tapping to Share pulls up your phone’s native Share sheet to ensure we don’t promote any specific third-party app or website.
Why are we doing this?
People share Wikipedia articles with each other through text and social media, but our mobile experience doesn’t encourage this behavior. With Wikipedia traffic declining, we want to help bring readers to our platform by providing additional information and attribution. Share buttons on articles are a WP:PERENNIAL request, and we’ve built this feature to allow users to choose whichever social or messaging apps on their phones that they would like to use to address the concern of promoting any specific third-party app or website.
This work is based on a May 2026 Reader Growth team experiment on mobile Wikipedia (arwiki, zhwiki, frwiki, viwiki, enwiki) to show this new Share button/card to a sample of readers. Findings from this experiment indicate that additional traffic was brought in by people clicking on Share Cards shared on external platforms, bringing an estimated potential 25 million additional pageviews to Wikipedia per year.
What risks have we considered?
We have held two calls with Wikipedians on Discord this year to discuss this feature and hear any concerns or risks, which we have worked to address:
Bad-faith actors using Share Cards to share inappropriate images. To mitigate this and concerns about the quality of images in Share Cards, we disabled sharing for images that appear on the Bad Images Lists and have ensured that we are respecting notpageimage, noviewer and/or NOMEDIAVIEWERCAROUSEL. Editors who don't want a particular image to show up cards can add notpageimage to the image.
Promoting specific social platforms to share to. As noted above, the Share Card does not specify any social platforms to share to and allows the user to share to any messaging or social app that is installed on their phone.
The feature won’t be used because there are other ways to share (via link, browser share button, screenshot, etc.). There were thousands of article shares and pageviews to Wikipedia coming from the share button and cards during the small-scale (1% of readers) experiment earlier this year, so we are expecting a good amount of usage when scaled up to all mobile readers.
How we are planning to proceed
Today through November 8th: we are inviting all Wikipedians to test this feature for themselves on their wiki. To test: on a mobile device, add ?useformat=mobile&sharecard=1 to the end of any Wikipedia article URL. Please feel free to report any issues here or on this task in Phabricator: phabricator:T442968.
On November 9th: if all looks good and there are no outstanding major issues, we will deploy this feature on mobile web to all Wikipedias. (This feature will not be available on desktop.)
After November 9th: we’ll continue to monitor for any bugs, issues, and any enhancements suggested by communities. We will also consider future iterations of the share card to test.
I don't think I fully understand the functionality you are trying to create here – the new share button in my testing just creates an image composite. I wonder where traffic from people clicking on Share Cards comes from, because the image does not automatically become a link when shared. If someone posts the card in discord, I can't navigate to the article unless I type out the shortened URL or just search for the article title, which is significantly worse functionality than you get from just posting the link directly (which automatically embeds an image and short description). Your assertion that this generated thousands of article shares and pageviews in testing is plausible, but not impressive considering enwp alone gets on the order of 250 million page views daily. Do you have any idea how much more external traffic is coming from direct links, or how the CTR compares? I almost always use the mobile app when reading on my phone if I can help it, so I already have a very functional share button, but I have a feeling that anyone who does use this feature will actually be driving less readership than they would if all they had was a URL. —Rutebega(talk) 10:20, 3 November 2026 (UTC)Reply
Sharing to text message
Sharing to text message (more)
Hi @Rutebega, thanks for your question and apologies for not making this clearer in the original post: when someone taps the big blue "Share" button on the Share Card, what's shared is the image you see in the screenshot above plus a link to the article (which we've instrumented using our standard practice of establishing provenance on traffic coming from different platforms/products).
To the right are a few more screenshots I took to show you what this means concretely. What you're seeing here is:
After I tapped Share on the Cat article, I selected to share as a text message.
When I did this, it opened up a new text message in my text message app, and the Share Card image, as well as a snippet of the lead and a link to the article (that's the box at the bottom of the text message in the second screenshot to the right, below the lead text, that says "Read more on Wikipedia") are automatically added here already.
Note: This is what it looks like to share to iMessage on an iPhone – on Android or if sharing to other apps, this will look slightly different because they all take in the "share" metadata framework we're using slightly differently, but in general a link is shared along with the visual card.
This is how we know that people were coming back to Wikipedia via this feature during the small-scale experiment we ran earlier this year – other links to Wikipedia don't have this unique provenance parameter, so the only way for a pageview on Wikipedia to have this parameter is if it came from a click on a link shared via Share Card (or I guess someone could have manually copied the specific URL parameter we used and appended it to a Wikipedia URL, but that would be... implausible ).
While I'm sure this is useful for people who don't know how to copy URLs or who use the app, I find that it clogs up the interface more. Making buttons more cramped together means they're even more difficult to press. Many useful tools are hidden behind the ellipsis, and I don't want a button I won't ever use to take up valuable screen space. Heck, I can't even watchlist pages anymore without clicking the ellipsis.
While I appreciate the thought that has gone into this, especially for readers, I think it's a net negative for me. How can I disable it?
P.S. I've had the same problem with the "saved articles" button - won't ever be using it, so I don't want it there. Advice on how to disable that would be appreciated as well. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester•FAC) 17:37, 10 November 2026 (UTC)Reply
I've just found that in Vector 2022, ⇧ Shift+Alt+W has lost some functionality. If the watch/unwatch tab is visible, or if it's in the ellipsis menu and that menu is open, all that ⇧ Shift+Alt+W does is to move focus to that tab or menu item - there is no toggling. You need to then press ↵ Enter to actually toggle the setting. The automatic toggling still works in Vector Legacy, MonoBook etc. although the popup no longer disappears in seconds - it now persists until dismissed or you navigate away. WP:ITSTHURSDAY, I think. --Redrose64🌹 (talk) 08:26, 13 November 2026 (UTC)Reply
@Not-cheesewhisk3rs thanks for chiming in here. We’re thinking about and testing potential ways to improve the top navigation experience for both logged in and logged out readers (including via the MinMin experiment and other experimental design improvements to reduce top navbar clutter and make sure the right actions are available at the right time). Clarifying question: are you typically logged in when you're browsing Wikipedia on mobile, and do you typically use an Android or an iOS device? The icons you get in the top navigation bar change depending on logged in/out state and which device you're on, so this info helps me get a better sense of what you're seeing/reacting to. Maryana Pinchuk (WMF) (talk) 21:31, 12 November 2026 (UTC)Reply
@MPinchuk (WMF): I edit on mobile. (This is a mobile edit, for example.) The feature is only frustrating because I'm a logged-in contributor. I've got both an Android and iOS device, and I use Wikipedia in my browser.
Essentially, what I'm seeing is that the top bar icons are "language", "save", "history", "edit", "share" and the ellipsis. Now that the "watch" function has been moved into the ellipsis, I can no longer tell from a glance whether I'm watching a page or not, and watchlisting a page is also more difficult because things in the ellipsis options are so close together. The spacing of stuff is really annoying on a phone, because small, clustered things are more difficult to click on precisely.
I think there should be some option for logged-in users to disable the "share" and "save" functions because they take up crucial space. That is all. More customisability for mobile editing makes it easier to work with. I also think that there should be a fix for some common bugs, such as the bug where the website freezes and I have to reload the page and I lose the edit which I was working on (because MinervaNeue doesn't save it in that case). But that is an entirely different can of worms. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester•FAC) 22:05, 12 November 2026 (UTC)Reply
leads with indented formulas are fragmented on mobile
In enzymology, a NADPH dehydrogenase (EC 1.6.99.1) is an enzyme that catalyzes the chemical reaction
[infobox]
The lead of NAD(P)H dehydrogenase (quinone) has the same problem. I could just edit these articles to make the formulas part of the lead sentences, but a) I wonder if there's a better solution, and b) I suspect there may be more cases like this: perhaps someone knows how to look for any, and then fix them all systematically. -sche (talk) 03:01, 4 November 2026 (UTC)Reply
I guess the trick we need is to add a line break before the formula, but keep it marked up as a part of the previous paragraph, so that the mobile site doesn't split it. Here's one way to do it, using <chem display="block"> markup:
The "looks bad" is font mixing, which I clearly see happening in your example. The wiki-text prose is sans-serif. The equation that is in wiki-markup matches that. The <chem display="block"> is serif instead. DMacks (talk) 04:37, 9 November 2026 (UTC)Reply
Unfortunately, neither this (1) nor this (2) fixed the problem. {{pb}} like this (3) and {{pad}} like this (4) didn't fix the problem either, nor did this (5), removing the line break but leaving the 'block indent' template. The only thing I've found that stops the infobox from breaking the line in half is this (6), just putting the formula as part of the sentence without any indentation or template. I feel like that solution might not work in cases where the formula is particularly complex and/or requires special formatting or templates, but I could be wrong. Should this be reported at Phabricator, with the argument that the software shouldn't be putting the infobox in the middle of the sentence in a situation like (3) or (4), or do we think they'll tell us it's not their problem, it's that the entry should be formatting the text in some other way? -sche (talk) 00:42, 13 November 2026 (UTC)Reply
The reason this happens is because mobile moves the infobox after the first paragraph. The first paragraph ends before the formula. You can either rewrite the lead or accept the results. as I don't anticipate the developers will change that behavior. Izno (talk) 01:42, 13 November 2026 (UTC)Reply
TemplateData doesn't appear to work with templates based on Lua
Latest comment: 4 days ago11 comments4 people in discussion
Resolved
– Thanks for the help everyone, TemplateData now works for templates that didn't used to work with TemplateData. If I continue to face any issues, I will open a new discussion with a link to this one. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪12:07, 9 November 2026 (UTC)Reply
See {{Old moves}} and {{Top 25 report}}. I raised this issue at the former's talk page with @Primefac, where adding TemplateData (call it TD or TDATA for short) in the doc page doesn't work, ie the data won't show up when editing with the 2017 wikitext editor. I also tried adding TDATA on the latter page's doc but that didn't work too. The common thing between the two templates is that they both use Lua and some form of "invoking" (which I don't understand), so could that be the issue? I don't have time to write a full report of the issue, so I'm just saying the main points here for now, stuff like reproduction steps would be detailed later. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪04:40, 6 November 2026 (UTC)Reply
TemplateDate does work with {{Cite web}} though. The thing is, I believe, that someone needs to "null edit" the main template for you since the TD additions are relatively new. Ponor (talk) 04:57, 6 November 2026 (UTC)Reply
It kind of works, but there needs to be more cleanup post-implementation, which is technical work I'm placing it as super duper low priority – partly because of "who the fuck cares about VE/2017WTE" backlash from certain editors who feel strongly about using "old technology" and "not embracing new technology" (a rhetoric that is not limited to Wikipedia). Also, many more such templates need TDATA as well. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪06:08, 6 November 2026 (UTC)Reply
It doesn't recognise parameters without the digit (eg date instead of date1), for existing templates, such as the link you provided. I tried adding aliases, but that didn't seem to work. I'm more worried for the Top 25 report template tho, because I don't really know how to add unnamed parameters into TDATA. I will try waiting it out for the software to update itself. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪07:07, 6 November 2026 (UTC)Reply
@Hason-LEK-SIN: those aliases will work. Sometimes it can take about a day to update the TemplateData. Other times it just takes a minute; I have no idea why. Are "unnamed parameters" the ones with no equals sign like {{Short description|none}}? If so, they are equal to {{Short description|1=none}}, so the TemplateData would apply to "1", as at Template:Short description/doc. TemplateData does have a longstanding limitation where if the purpose of parameters can change, it has no way to account for it, so in {{sfn}} you can see the TemplateData for each number is trying to explain how it's either this or that or the other thing, and it also means that for a lua module that accepts infinite unnamed parameters or infinite enumerated parameters with numbers or letters appended (like the "lastx" parameters in cite web), TemplateData has no way to account for that so Template:Cite_web/doc#TemplateData ends up listing a massive number of parameters. Rjjiii (talk) 07:42, 6 November 2026 (UTC)Reply
Latest comment: 3 days ago7 comments4 people in discussion
I noticed that when I'm replying to a comment on a talk page, the first word isn't automatically capitalised as it is when starting my own topic. It would be useful if it did as I always have to go back and correct it. I'm on a mobile, android, using chrome and it's not the app so presumably counts as the "mobile website". ~2026-57767-13 (talk) 13:15, 8 November 2026 (UTC)Reply
If I'm on my desktop PC (Windows, Firefox) and start a new topic on a talk page, both the Subject box and the main edit box start off as lowercase. But on my mother's iPad (iOs, Safari) and start a new topic, both the subject box and the main edit box have the first letter capitalised, the rest lowercase. Therefore, it's not a MediaWiki control but a feature of your device, operating system or browser, or a combination of those. --Redrose64🌹 (talk) 22:35, 8 November 2026 (UTC)Reply
Latest comment: 3 days ago7 comments5 people in discussion
I'm not sure if this is off topic (if it is feel free to remove it) but I kinda have a weird question. If deleted revisions are viewable by admins, is a page ever "really" deleted? Do the wiki servers have infinite storage? Jacksonvil (talk|contribs)08:22, 9 November 2026 (UTC)Reply
Jacksonvil, firstly there is a higher level of suppression that revdel (see Wikipedia:Oversight) that admins can't see. However, to answer your point no nothing is fully deleted as far as I know, and not enough to matter to storage needs. Technically as it is just database records they could be, and there are tools in the software such as mw:Manual:deleteOldRevisions.php. Never heard of Wikipedia doing it though but maybe it's happened for legal reasons. No they do not have magical storage, but although large it's still manageable. English Wikipedia was 31TB last year, and commons is past a pebibyte. KylieTastic (talk) 09:28, 9 November 2026 (UTC)Reply
Size wise still well behind others such as Google search, Youtube and Meta etc. I think google said the search database was over 100 petabytes now. For less public data the LHC generates petabytes per day and I believe they passed 1 exabyte. Things have certainly got a lot bigger and faster since I started with my TRS-80 and had to wait minutes to access a few KB of data from a tape drive. KylieTastic (talk) 09:59, 9 November 2026 (UTC)Reply
There are WP:OFFICE reasons still to nuke things entirely off the wikis, but this is obviously exceptional and I understand to be most often applied on Commons. Izno (talk) 16:09, 9 November 2026 (UTC)Reply
The capacity of the servers is not infinite, which is one of the reasons why donations are invited from time to time - some (but not all) of it gets spent on additional hardware. As for actual physical deletion - that is, permanent removal of a revision from the data tables in a manner that cannot be undone even by oversighters - that is a rarely-used action available only to sysadmins. It's rarely-used because it can compromise data integrity (a table might end up with a row that references a no-longer-existent row in a different table). So more than one table may need to have rows removed or amended. And so on. --Redrose64🌹 (talk) 20:09, 9 November 2026 (UTC)Reply
Latest comment: 4 days ago3 comments3 people in discussion
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
The Wikipedia Apps team is preparing to launch Year in Review in early December. Year in Review gives app users a personalized recap of how they read and engaged with Wikipedia throughout the year. The team is looking for volunteers to help make it available in as many languages as possible. Translators can contribute through translatewiki.net. For Android, search for yir under the "Untranslated" tab, and for iOS, search for year-in-review under the "Untranslated" tab.
Following the release of Reading Lists to all Wikipedias in September, logged-in users will soon be able to organize articles saved in their lists into customizable categories. This will enable readers to create collections and revisit saved articles based on their interests, potentially encouraging frequent visits to Wikipedia. The update will roll out to all Wikipedia users between November 9 and 16.
The Wikipedia Apps team is preparing to launch the first of two notification experiments for English Wikipedia readers on Android who have opted in to notifications. The three-week experiment will send notifications suggesting personalized Discover reading lists which are collections of Wikipedia articles recommended based on articles the reader has previously viewed. The goal is to understand whether these recommendations help readers discover relevant content and encourage them to return to the app. No action is required, and users can manage their notification preferences in the app settings. Learn more and share feedback.
A bug in the Global Watchlist was causing the page to fail to load for users who have unseen changes on Wikimedia Commons. The bug has now been fixed. If you temporarily removed commons.wikimedia.org from your personal Global Watchlist settings due to the bug, you can restore it there.
A new Beta feature called "Home" will be deployed to 10 Wikipedias for a limited test. This new feature aims to replace Special:Homepage for newcomers, with additional modules planned for the future to improve upon the current experience. If you want to participate in the test, please sign up. "Home" will be released to all users later this month.
On English and Russian Wikipedias, Source Verification is now available as an experimental Suggestion for experienced editors within Suggestion Mode. It uses an LLM hosted on LiftWing to try to check whether a cited source supports the claim it’s attached to. To try it out, please see these testing instructions. If you are at another language Wikipedia and your community is interested in trying it out, please express your interest.
View all 35 community-submitted tasks that were resolved last week. For example, an issue where dates passed as blank parameters to functions in wikitext were incorrectly interpreted using the month-day-year format instead of the day-month-year format, has now been fixed.
Updates for technical contributors
Starting on 1 December 2026, hCaptcha will be required for edits made via the API by non-autoconfirmed users. If your tool, gadget, or user script makes edits on behalf of newcomer users, see how to update it.
Toolforge has introduced two new beta features. "Toolforge alerts" send email notifications when a tool becomes unavailable, returns errors, or restarts frequently. "Extended logging" makes it easier to investigate problems by providing logs for events such as job creation, deletion, and deployment failures through the toolforge logs command. Both features are opt-in and help tool maintainers become aware of and resolve problems with their tools more quickly. Maintainers can enable alerts and learn how to access extended logs. They are also encouraged to try the features and provide feedback.
A proposal to change how we currently organize the Wikimedia Hackathon has been shared. It explores making the event more accessible to technical communities in different regions. Share your feedback on the proposal’s talk page; the deadline has been extended to November 13th.
Latest comment: 3 days ago7 comments4 people in discussion
I don't see this addressed anywhere. I find myself getting notifications of the form "Topic: The Signpost 1 November 2026 was archived or removed from User talk:someoranotherusername", and its user talk pages I've never contributed to. Seems to have started yesterday. Did I muck some or another preference, perhaps? --jpgordon𝄢𝄆𝄐𝄇22:25, 9 November 2026 (UTC)Reply
I've been seeing this too, but with "This week's article for improvement (week 44, 2026)". I don't recall turning on any setting or anything. Interesting to know that it's not just me. Chorchapu (talk|edits) 22:29, 9 November 2026 (UTC)Reply
This is a known bug: phab:T334906 ("Multiple notifications when subscribed to mass-posted topics"). Unfortunately, it's not easy to fix, and it does have a positive (unintended) consequence for some of the users that send the MassMessages: phab:T334906#10899424. For now, I believe the best individual solution is to unsubscribe from those threads, once the auto-archiving begins. HTH. Quiddity (WMF) (talk) 22:45, 9 November 2026 (UTC)Reply
When the notifications start arriving for us, that means auto-archiving has begun somewhere. I.e. Some individual editors might have auto-archive settings on their usertalkpages that are sooner than the "5 days of inactivity" settings that are used on this village pump page.
If you unsubscribe from that first notification (which can be done directly from the "..." menu within the Notification popup (at least in the website, I'm not sure about the UI in the Apps)), that will unsubscribe you from all of them. HTH. Quiddity (WMF) (talk) 23:37, 9 November 2026 (UTC)Reply
Latest comment: 1 day ago17 comments4 people in discussion
Is there any reason that the displayed page title (controlled by {{DISPLAYTITLE:...}}) does not have the mw-parser-output class? WP:DISPLAYTITLE says that { and } are allowed for template transclusions, suggesting that it is supposed to be a "parser output". A specific example of the problem is that the title of the article n-body problem (with {{DISPLAYTITLE:{{mvar|n}}-body problem}}) is displayed as "n-body problem" instead of "n-body problem" because {{mvar}} relies on the class mvar (which is correctly added to the displayed title), but that class has a specificity .mw-parser-output .mvar and thus no effect unless mw-parser-output is also present. — Mikhail Ryazanov (talk) 22:53, 9 November 2026 (UTC)Reply
The title isn't part of the article body is why. OTOH, there's nothing stopping you from doing {{DISPLAYTITLE:<spanclass="mw-parser-output">{{mvar|n}}-body problem</span>}} to make it work if you really need to. Anomie⚔23:45, 9 November 2026 (UTC)Reply
@Mikhail Ryazanov:Special:ExpandTemplates shows that {{mvar|n}} produces <templatestyles src="Math/styles.css" /><span class="texhtml mvar">n</span>. {{Math/styles.css}} adds italics to mvar. It is the TemplateStyles extension which automatically adds .mw-parser-output to limit the scope as mentioned at Wikipedia talk:TemplateStyles#Scope limited to wiki content. When mw:$wgRestrictDisplayTitle is true (the default value), DISPLAYTITLE only permits changes which allow the page heading to be copy-pasted to a wikilink and work. That would break if TemplateStyles was allowed to change the heading. I don't know whether that's the official reason for not having mw-parser-output in the page heading but I think it's a good reason. Just write ''n'' in DISPLAYTITLE when you want italics. PrimeHunter (talk) 23:47, 9 November 2026 (UTC)Reply
I have tested that DISPLAYTITLE does allow wrapping in class="mw-parser-output" as suggested by Anomie. <templatestyles src="Math/styles.css" /> doesn't load the CSS page if it's only inside DISPLAYTITLE but it does work if it's elsewhere on the page. Did we just find another thing DISPLAYTITLE should block? PrimeHunter (talk) 23:54, 9 November 2026 (UTC)Reply
Regarding "another thing DISPLAYTITLE should block", T285329#9336131 nicely summarizes this: a security fix for a problem that is mostly abstract in nature. It's basically saying "we don't trust Wikipedia editors to deal with vandalism". Has the real purpose of this feature actually been discussed anywhere? If it is only supposed to prevent vandalism, a much more sane solution would be to set up a hook that will allow DISPLAYTITLE modifications only by "page mover" users. Otherwise, I see no reason in explicitly allowing templates but crippling their functionality. As for using ''n'', this is what, for example, Lp space does. However, MOS:MATH §Font formatting says that Using {{math}} and {{mvar}} also helps some spell checkers and screen readers treat math markup properly, which does make sense in light of MOS:ACCESS and semantic HTML in general. That is, I would prefer if this resolves into allowing reasonable markup in DISPLAYTITLE; but if the decision would be to make it less usable/useful (being afraid of imaginary problems), then this must be clearly explained in WP:DISPLAYTITLE. — Mikhail Ryazanov (talk) 01:43, 10 November 2026 (UTC)Reply
The "n" should just be read out normally in n-body problem so I don't see a need for anything fancy there. The main problem solved by restricting DISPLAYTITLE modifications is not vandalism but good-faith editors who try to use DISPLAYTITLE instead of moving the page, or who accidentally transclude or copy a wrong DISPLAYTITLE from another page. I may have fixed more than a thousand articles in Category:Pages with disallowed DISPLAYTITLE modifications and maybe saw a couple of vandalism attempts. PrimeHunter (talk) 02:30, 10 November 2026 (UTC)Reply
Guarding against accidental mistakes by good-faith editors does not require disallowing classes and inline HTML/CSS markup at all. As for n in that particular title (and other math/phys articles), it is a "variable", not just an italic letter, and thus should be better marked semantically as {{mvar}} (as it is in the lead). — Mikhail Ryazanov (talk) 02:47, 10 November 2026 (UTC)Reply
I was commenting on T285329#9336131 which claimed the reason for $wgRestrictDisplayTitle=true is mostly vandalism. I disagree with that. You are right that bad styling of DISPLAYTITLE is not a problem with good-faith editors. Most vandals are primitive but some learn non-trivial tricks. PrimeHunter (talk) 03:05, 10 November 2026 (UTC)Reply
But both mentioned tickets discuss $wgRestrictDisplayTitle mostly in terms of "security" (look at their tags) and "vandalism", so I was assuming that those are the "official reasons". Then you've mentioned "another thing DISPLAYTITLE should block", and I was basically arguing that it should not. I would say that class="mw-parser-output" should be added by default as long as templates are allowed (and it is reasonable to assume that since the title is repeated in the lead paragraph, per MOS:LEADTITLE, the necessary CSS will be loaded). — Mikhail Ryazanov (talk) 03:54, 10 November 2026 (UTC)Reply
Templates are only "allowed" in the sense that you can write template calls inside DISPLAYTITLE where they are evaluated before applying DISPLAYTITLE. With the current result of {{mvar|n}}, the code {{DISPLAYTITLE:{{mvar|n}}-body problem}} is the same as {{DISPLAYTITLE:<templatestyles src="Math/styles.css" /><span class="texhtml mvar">n</span>-body problem}}. The part <templatestyles src="Math/styles.css" /> doesn't do anything inside DISPLAYTITLE but is ignored there. It only appears to partially work in n-body problem because {{mvar}} is also called in the body. The official reason for $wgRestrictDisplayTitle is given in mw:Manual:$wgRestrictDisplayTitle#Details:
"Restricts display titles to titles that normalize to the same canonical database key as the real page title. This roughly means that only capitalization variations of the title are accepted. If set to false, any display title is allowed. This is not recommended however, as it breaks the wiki convention that a page's title is its name, and thus can be used for linking to it."
Adding mw-parser-output to DISPLAYTITLE would break that when TemplateStyles is used. It can be discussed whether fake page titles should be called a security issue but I don't think it should be allowed. PrimeHunter (talk) 05:17, 10 November 2026 (UTC)Reply
As I understand, roughly means that only capitalization variations of the title are accepted is in terms of the literal string if all formatting is ignored. I do not think that italic and other font changes (including class="texhtml", which is applied because it is duplicated in the global style), as well as sub- and superscripts, make a page title "fake". In any case, what do you think is the reason to explicitly allow template expansion in DISPLAYTITLE? And since this becomes more "general" than technical, where would be a better place to discuss what DISPLAYTITLEin principle should do and what it must not? — Mikhail Ryazanov (talk) 03:48, 11 November 2026 (UTC)Reply
I'm not saying those would be fake titles but TemplateStyles can do other things like changing text completely, e.g. displaying the N word as page title on Barack Obama if TemplateStyles was allowed to apply there. Nobody decided to "allow" template expansion in DISPLAYTITLE. The DISPLAYTITLE is part of the wikitext and that's just how wikitext works. The developers would have to code something special to disallow it, and I see no reason for that when you could just have written whatever the template expands to. I don't know whether anybody specifically decided to disallow TemplateStyles to affect the page title. TemplateStyles adds mw-parser-output to limit it to the wiki part of the page and not allow things like changing interface menus. The page title is separated from the page body in the HTML and mw-parser-output is added at the page body. Requests to change MediaWiki belong at Phabricator. See WP:PHAB. I don't think a request to also add mw-parser-output at the page tile would be accepted. There is little reason when it could be abused and DISPLAYTITLE can already do everything we want to be possible. It would require significant developer time for very little benefit to figure out how to block unwanted TemplateStyles changes to the page title while allowing harmless changes. PrimeHunter (talk) 23:53, 11 November 2026 (UTC)Reply
For "Nobody decided to 'allow' template expansion in DISPLAYTITLE", please see the quote in the very beginning of this discussion; to be precise, the full sentence in WP:DISPLAYTITLE is "Some forbidden characters are not supported by DISPLAYTITLE (< and > are allowed in markup, and { and } are allowed for template transclusions)." That is, developers did "code something special to disallow" some functionality but explicitly allowed template transclusions. If the only purpose of DISPLAYTITLE was to change capitalization, then no markup or templates would be allowed. But they are. On purpose. So I'm asking what exactly that purpose is. As I've said previously (and demonstrated below, plus see the Phabricator tickets mentioned by Anomie), currently allowed inline CSS is more than enough to do wrong tings, and thus disallowing legitimate styles from legitimate templates makes no sense. As for a making a request at Phabricator, again, as I said, before addressing the technical problem, it must be decided what we really want to achieve. And this forum ("technical") is apparently not the correct place to discuss "what DISPLAYTITLEin principle should do and what it must not". This must be decided before asking to add mw-parser-outputor instead to restrict DISPLAYTITLE even more. — Mikhail Ryazanov (talk) 03:02, 12 November 2026 (UTC)Reply
We want titles to be as simple as we can get away. Displaytitles primary function is to turn IPhone into iPhone. A few things like italics etc were added later and are still relatively easy to handle for users like the apps, apple dictionary, and kiwix. Adding more cruft to it however only further complicates things, which creates a long tail support problem that developers dont want. There is no mw-parser-output, because it is not considered to be rendered wikitext. Just like editcomments in history and recent changes, these are special cases, with limited formatting capabilities. —TheDJ (talk • contribs) 14:02, 12 November 2026 (UTC)Reply
"{ and } are allowed for template transclusions" merely means that templates are expanded exactly as usual in wikitext. I haven't seen the code but bet that template brackets are long gone by the time DISPLAYTITLE runs. Saying that DISPLAYTITLE "allows" templates is like saying that your body allows to drink melted ice. It doesn't care where the water came from. TemplateStyles can do worse things than the allowed CSS in DISPLAYTITLE. Kitchen knifes can do bad things but are used in kitchens. That doesn't mean you should use a sword there. PrimeHunter (talk) 15:28, 12 November 2026 (UTC)Reply
@Jacksonvil: On that page you can see the same instructions by clicking "show" at "Technical instructions for closers". At phab:T269033 the editnotice was added to the new topic tool but not the reply tool where it seems too intrusive. You can see an editnotice by clicking the "edit" link at a section heading. PrimeHunter (talk) 14:27, 10 November 2026 (UTC)Reply
@Jacksonvil: It appears so. The "reply" links are relatively new and were designed to make it simpler to reply. I use the old "edit" links at the section heading where both an edit notice and the full edit interface is shown. PrimeHunter (talk) 23:11, 10 November 2026 (UTC)Reply
Phase 2 Semantic Search A/B test live on web: help us test!
Latest comment: 2 hours ago8 comments5 people in discussion
Hi all,
I’m writing to let you know that the Reader Growth team’s A/B test of "semantic search”, or natural language search, capabilities on the web version of Wikipedia went live today. We are trying this to make it easier for people to find the information they’re looking for on the wikis so that, as we face declining pageviews, Wikipedia can be a better destination for learning and discovery. Here is an example search results page that the treatment group could see; you can also try more semantic queries on this page (please check that you have &mpo=semantic-search-for-web:hybrid-srp at the end of your URL to see semantic results if you do multiple searches).
We increasingly have been hearing from readers that they want to be able to ask questions to Wikipedia. This makes sense, since more and more people are getting used to using chatbots. But we also know that it is important for Wikipedia content to be presented in the way that volunteers wrote it. So in this feature, readers will ask natural language questions – but rather than generating answers, it returns the excerpts from Wikipedia articles that may answer their question. So far, as we’ve shown this to volunteers, it sounds like we’re on the right track! (but of course I want to hear what you think).
Check that Phase 2 thread for more details, including research about the gaps in our current search experience, the results of a previous semantic search test on the apps, the differences between the apps and the web, and metrics we are looking at for this current test. The project page also has much more information about all of our thinking, research, and progress in this area.
The left screenshot illustrates the current experience of searching on Wikipedia mobile for "who invented airplanes." The screenshot on the right shows the experience asking the same question in the experimental semantic search treatment.
What this test is:
Semantic search means retrieving information based on the meaning, concepts, or contextual relationships of someone’s query. Currently Wikipedia search does not support semantic search, and instead fully relies on lexical retrieval, which is based on exact search terms, or keyword matching.
This test will be shown to 1% of desktop and mobile English Wikipedia readers typing in the search bar, who will see the existing "Search for pages containing..." call to action (CTA) as usual below the typeahead suggestions. Clicking that CTA, or hitting enter on their query, will take readers in the test's treatment group to an advanced search results page that will include semantic results. This page will also include a survey question asking whether users found the results helpful, and inviting them to write out more feedback.
I also want to note that the search results page in the treatment is not as fully featured as the regular search results page (e.g., it doesn’t have the red link to create a new article, and it doesn’t have the search results from sister projects). That’s not a long-term design decision; rather, we built a simple page to conduct and learn from this test.
The test will be turned off in December. If early results are promising, we will come back to discuss them together and what we think should happen next.
What we’re asking for your help with:
We have done some early work identifying risks and edge cases, particularly related to queries where semantic results could be easily misinterpreted or even harmful. We’re thinking about 1) situations in which people’s searches could bring up some of the more sensitive content on the wiki, and 2) situations where our search algorithm might present results that appear to answer the query, but in a way that does not seem neutral. For example, we know an issue exists with block quotes – sometimes the search returns a block quote from a specific point of view that is presented like it is a neutral article excerpt, which is misleading. This is an improvement we’re working on (it is a technical challenge for the search algorithm to identify block quotes appropriately).
As you try out various queries, please help us be on the lookout for risks we may not be aware of yet. If you find any, please share a URL and screenshot of the results, along with a description of your concerns, at the Information Retrieval Phase 2 project talk page. We think community testing of this feature will be crucial to build something useful for our billions of readers while also taking care not to cause harm or create confusion. Thank you for your help. EBlackorby-WMF (talk) 22:19, 10 November 2026 (UTC)Reply
I clicked the link to try queries but it doesn't work, at least on my end. The link takes me to https://en.wikipedia.org/w/index.php?title=Special:SemanticSearch&mpo=semantic-search-for-web:hybrid-srp but all I see on there is a link to "Switch to classic search" in the middle of the page. – Scyrme (talk/solidarity) 22:55, 10 November 2026 (UTC)Reply
@Scyrme -- thanks for trying it! Yes, so from that page, try typing a question into the search bar and pushing enter/search (e.g. "What is the difference between a tuba and a sousaphone?") MMiller (WMF) (talk) 22:58, 10 November 2026 (UTC)Reply
I see! Sorry, it wasn't clear initially. I thought the usual search bar would exit the semantic search testing page and take me to classic search results, and expected another search bar within the page area where the "Switch to" button is. Seems to work well so far, even when I try strange questions (eg. why do fish dig?→ received a snippet about fish that burrow in mud) or questions that contain wrong assumptions (eg. why do cats bark?→ received snippets about cat vocalisations). – Scyrme (talk/solidarity) 04:12, 12 November 2026 (UTC)Reply
Thanks @GrinningIodize! Your experience with the "did you mean" (DYM) feature is partly due to our not yet having tailored the suggestions for semantic searches, as you also discovered when you tried the same query in classic search and got the same suggestion. We've discussed this a bit as a team and would be interested in updating DYM for semantic searches as a future improvement. I know the Search team also has been investing over time in the existing DYM logic as well and can pass on this example to them so we at least can avoid the ouroboros of suggesting the same correction for the thing that didn't need to be corrected:) SherryYang-WMF (talk) 17:24, 13 November 2026 (UTC)Reply
Latest comment: 21 hours ago4 comments2 people in discussion
I'm copyediting Taxation in Finland, and the page rendering went berserk–narrow columns and long, single-letter columns which are bolded (possibly section headers). I was going to go on wikibreak until whatever was wrong was fixed when I saw a "Switch to legacy parser" in the page tools; clicking that makes the page render normally. It would be nice to know what's going on; I have to switch to the legacy parser after copyediting each section, which is time-consuming. In solidarity, Miniapolis23:10, 10 November 2026 (UTC)Reply
On that page it states UserMerge is currently incompatible with either $wgSharedDB or CentralAuth. That would block enabling it. T216089 is also relevant. Anomie⚔00:25, 11 November 2026 (UTC)Reply
Latest comment: 2 days ago6 comments3 people in discussion
Is there a way to mark a page so that reply links are unavailable? I'd like to see if I can get agreement to turn it off somewhere, because it tends to just not work right. But only if it's actually possible of course, and I couldn't find anything in the docs... –Deacon Vorbis(carbon•videos) 13:51, 11 November 2026 (UTC)Reply
Actually, while I'm here and am thinking about it, this would mostly be unnecessary if there were some way to hint that replies to specific initial comments and relisting notices should be done with a *, rather than a :. I don't suppose this is possible? –Deacon Vorbis(carbon•videos) 15:41, 11 November 2026 (UTC)Reply
Latest comment: 1 day ago4 comments3 people in discussion
There seems to be some technical issues to the Syrian Civil War detailed map at the moment - without any traceable changes from anyone since the last time it was properly working. For example - the Suwayda villages don't show up on the map while they're still present in the code (search for "START OF SUWAYDA GOVERNORATE" in the module), and the icons in the legend don't load properly. Has there been a recent change that creates an overload because of the amount of code so everything doesn't load properly or something? AntonSamuel (talk) 16:30, 11 November 2026 (UTC)Reply
The reason this just came up now is that the 1,250 image limit was changed from unique images to total images recently, so all the copies of that used to count as one image are now counted individually. --Ahecht (TALK PAGE)15:17, 12 November 2026 (UTC)Reply
So, the first time I clicked on "log in", I got a text page about a parserURL (or some such) failure. Second click of log in worked, I've seen this before, it happens. But when I logged in, I got a message saying "Authentication was successful but your session has expired. Please click "Log in" to recover it.". That's new. More meatballs in the backend spaghetti code? - The BushrangerOne ping only03:27, 12 November 2026 (UTC)Reply
Latest comment: 1 hour ago8 comments6 people in discussion
Today I notice that when I unwatch a page by clicking the "unwatch" tab from a recent diff of that page, the browser pops up a box says "[page name] and its talk page have been removed from your watchlist", with a big Undo button. This is both annoying and unnecessary - I can see it's been removed because the "unwatch" tab changes to "watch", and if wanted to undo it I would just click that tab again. Can we please not have the box - or at least make it optional.
Yep, these are related - my team just rolled out new watch star popover behaviour to make it easier to add labels to your watched items. Previously, the same popover was displayed as a toast notification, the main change is that the location has moved so that it's closer to the Watch star that you just clicked. Additionally, after unwatching you can now Undo the action, which preserves your expiry date and labels, if they were set. I see what you're saying about already seeing that it's unwatched. Maybe the popover with Undo should only be displayed if you had an expiry or label configured? I worry it might be confusing to show it some times and not others, curious what others think! Samwalton9 (WMF) (talk) 12:46, 13 November 2026 (UTC)Reply
It is somewhat regrettable that the unwatch popup doesn't seem to have a unique ID or class distinct from the watching popup so it could be hidden in one's CSS. Nardog (talk) 12:59, 13 November 2026 (UTC)Reply
Yes that is unfortunate. You can hide both popups with this in your CSS:
Another option if you have an article link to hover over would be to enable Wikipedia:Tools/Navigation popups via the Preferences → Gadgets → Browsing option.
I generally use the Action → un option in the hover window to unwatch pages as I review my watchlist, and it's pretty convenient (and appears to bypass the new "Undo" functionality). — SirOlgen (talk) 19:53, 13 November 2026 (UTC)Reply
New tool: Wikipedia2Book – printable PDF books from Wikipedia articles
Latest comment: 7 hours ago1 comment1 person in discussion
Hi all, I'd like to share a tool I've been developing: Wikipedia2Book, hosted on Toolforge.
Since the Book Creator PDF export was retired, there has been no simple way to turn a set of articles into a single printable book. Wikipedia2Book fills that gap:
add articles by URL or title, or import an existing book page (e.g. User:Example/Books/My book), keeping its order and chapters;
explore linked articles to add more;
organise chapters, add a cover, introduction, table of contents and page numbers;
each article is included through Wikipedia's official PDF rendering (content is not re-parsed), fitted to the chosen print size (A4, Letter, Legal, A5…);
a license/attribution page is generated automatically (CC BY-SA).
Privacy: the server is stateless – no account, no tracking, no book stored server-side. Your book stays in your browser and can be exported/imported as JSON.
It should update automatically. This was a more complex move, though, since the pagename already existed. It looks like the deletion of London Underground S Stock didn't result in the sitelink being removed from Wikidata, so when the page was moved to that title it didn't update. Maybe it all happened a bit too quick for the systems to keep up with? I've already fixed this on Wikidata. Maybe @Lydia Pintscher (WMDE): might know more? Thanks. Mike Peel (talk) 20:15, 13 November 2026 (UTC)Reply
Resolved
Sharing to text message
Sharing to text message (more)
).
View all 35 community-submitted tasks that were resolved last week. For example, an issue where dates passed as blank parameters to functions in wikitext were incorrectly interpreted using the month-day-year format instead of the day-month-year format, has now been fixed. 
that used to count as one image are now counted individually. --Ahecht (TALK