Wikipedia:Village pump (technical)/Archive 227

Hi everyone,

We’re sharing an early look at an exploration into improving how people search on Wikipedia in order to gather your input. The goal is to help readers find the information they’re looking for more easily on Wikipedia itself, without needing to rely on external search engines.

One focus of this work is semantic search, a type of search that looks at the meaning of a query, not just the exact words typed, to help people find information resources. Today, Wikipedia search relies almost entirely on keyword matching, which works well when readers know the exact article they want, but less well when they have a question or are exploring a topic and the answer is inside an article without a keyword title match.

This post outlines why we’re exploring this, what our early research shows, and what kind of small, early experiment we’re considering.

Why are we working on this?

Many readers do not start their searches on Wikipedia. Instead, they often use external search engines or AI-powered tools, which then direct them to Wikipedia – or sometimes provide answers based on Wikipedia content without sending readers to the site at all.

If Wikipedia search does not meet modern expectations, especially for question-based or exploratory searches, readers are less likely to begin or continue their journeys here and instead rely on platforms where information isn’t made by humans, and is less reliable, neutral, and complete.

In short, improving search is one way to help Wikipedia readers find and enjoy what they read on our platform.

What has our preliminary research shown?

Our early research checked whether this problem is real and whether improving search could meaningfully help readers. Our findings suggest that it could.

1. About 98% of Wikipedia reading sessions originate outside Wikipedia search.

• The small group who use internal search are much more likely to be editors than casual readers. Most readers move between articles by returning to external search engines, even when links exist within Wikipedia itself.

2. Roughly 80–95% of on-wiki search sessions use autocomplete suggestions.

• The preference for autocomplete suggestions – those that appear as someone types – shows that small improvements to speed can have a large impact on success.

3. Between 4–7% of Wikipedia search queries are phrased as questions, but these queries are less likely to succeed.

• While this is a minority of searches, it shows that some readers attempt it and that many others likely avoid it because they’ve learned it doesn’t work.

What stage is this project in?

This work is currently in Phase 0, sharing early ideas, learning from research, and gathering community input.

What idea are we testing?

We’re exploring whether a hybrid search experience, one that combines keyword search with semantic search, could help readers find information more easily. The hybrid search would use machine learning, similar to how search engines rank and surface results today, to better match readers’ queries with relevant existing articles and sections.

Semantic search performs better for questions and exploratory searches, while keyword search works better for very specific or name-based queries. In early prototypes, combining the two approaches produced more useful results than either one alone.

Importantly, this exploration does not involve generating new answers or rewriting Wikipedia content. The goal is to better match readers’ queries to existing, editor-created articles and sections. Any experiment in this area would be small, limited, and designed to test whether this approach provides real value to readers.

What is the timeline?

Right now, we’re focused on discussing the problem space and sharing the findings of the report with you all. We especially want to understand if this problem space is worth learning more about. We are also trying to better understand if a simple Minimal Viable Product could be technically feasible.

Should there be alignment around further exploration, a possible next step would be a tightly constrained, time-bound A/B test with a limited group of readers, potentially beginning in February, to help answer open questions surfaced together.

What input are we looking for from you?

We’d especially appreciate your thoughts on the following:

1. What are your overall reactions to this exploration and the research behind it?
2. Are there risks or concerns you think we should be paying closer attention to?
3. What signals or outcomes would matter most in deciding whether a hybrid search approach is worth pursuing further?

For more details, including links to our research and early mockups, please see the project page.

Thank you! EBlackorby-WMF (talk) 16:09, 6 January 2026 (UTC)

Google is not a good role model here, given the amount of negative media coverage they have received in the last few years about how they are currently destroying their flagship product, in part by messing with people's search queries. Bringing this up as something Google "excels at" is actually baffling given how constant and how inescapable the negative commentary has been. (But I guess these are just "Internet pundits" and the feature isn't for them.)

Also, based on the project page, this seems to go well beyond "improving search." The mockups that claim to be "semantic search" appear to actually illustrate a "Because you liked..." recommendation feature, and a "suggested questions" widget, which surfaces AI-generated questions for no apparent reason. (For Q&A use cases, AI-generated questions can potentially introduce factual or representational bias. -- you don't say!)

(Neither here nor there: I'm pretty sure that the project page was at least edited, if not fully generated, with AI.) Gnomingstuff (talk) 04:41, 7 January 2026 (UTC)

@Gnomingstuff Google is good at semantic interpretation (and many other things as well). It's not as good at giving the right answer as it USED to, but that has more to do with the overall pool of garbage that they have to sort through, not keeping up with development of their own platform's core functionality, as well as actively worsening their quality because they want to keep you coming back to their website.

On a scale of 1 through 10, they are however still at 7. If people want to focus on Google messing up the 7-10 part, then they are ignoring that WE are at 0 and not even close to their 7.

this seems to go well beyond "improving search."

I think that depends on if your definition of search is that of someone used to old style search (a specific word matching technology), or the actual meaning for most people in the world (finding what they are looking for). —TheDJ (talk • contribs) 14:50, 7 January 2026 (UTC)

The post here seems to only discuss "old style" search: We’re exploring whether a hybrid search experience, one that combines keyword search with semantic search, could help readers find information more easily.. What the Phase 0 proposal page seems to actually be proposing are "since you liked..." and AI-generated questions widgets, with proof-of-concepts already built out.

I also guess I don't see the problem with people getting to Wikipedia pages via Google rather than internal search or blue links. They still get to the page either way, the only difference is squeezing out 2 extra pageviews." Gnomingstuff (talk) 20:21, 7 January 2026 (UTC)

I feel WMF developers should be informed somehow that any LLM-generated text placed within the Wikipedia UI is unlikely to receive a positive community reaction (either due to anti-AI sentiment or cautious acceptance but feeling Wikipedia's human-written nature is what gives it a purpose distinct from ChatGPT etc.). Otherwise they will continue to spend effort on stuff that is unlikely to be accepted by the editing community.

On the core idea of semantic search, I somewhat disagree. Yesterday I was searching for some New Zealand-related topics. I typed NZ {phrase}, but it didn't come up with the correct article; although it works often enough for me to instinctively do it, stuff like this still fails for me a reasonable portion of the time. Having a search system that handles this sort of thing would be a better way of handling this rather than creating redirects for every conceivable topic.  novov talk edits 09:28, 8 January 2026 (UTC)

"with proof-of-concepts already built out" proof of concepts get built all the time for a variety of reasons. to spark discussion, to visualize ideas etc etc. Stop telling people what to do. —TheDJ (talk • contribs) 12:00, 8 January 2026 (UTC)

...I didn't tell anyone what to do? Pointing out the contents of a page is not telling anyone what to do and I have no idea how you are twisting "proof of concepts are built out" into "I order you to do XYZ."

...also, the entire point of this topic was to ask for feedback, in part to help decide what to do Gnomingstuff (talk) 14:31, 8 January 2026 (UTC)

Gnomingstuff, I'm pretty sure that the project page was at least edited, if not fully generated, with AI. - No, I'm pretty sure it isn't. WP:AISIGNS is not a good metric for finding AI-gen pages outside of encyclopedic articles. A lot developers write with bolded phrases as signposts and bulleted lists since it makes it easier to skim documents. with proof-of-concepts already built out I can personally tell you that those prototypes could be built at speed, over a evening if required. (in fact, if I were to speculate, (which is their other design) took more time to create than the AI question screenshot).

That being said,

EBlackorby-WMF, wrt What signals or outcomes would matter most in deciding whether a hybrid search approach is worth pursuing further? I do want to amplify one specific criticism by @Gnomingstuff and @Mir Novov, I do think The robot icon and AI label failed to clarify what was machine- vs human-generated and instead increased confusion. is a alarming finding that should have been a guard-rail, we cannot have Although the questions were AI-generated, participants often assumed questions were crowdsourced or editor-curated be a thing. The (enwiki-) community cares deeply about making sure folks understand that the encyclopedia is human-generated and organic and having some mixing of AI-gen content/attribution of human-gen content to AI will likely be poorly recieved by the community.

Moving to my personal feedback, I really really like "Concept 1" (the "because you read" feature). It's something I've been missing a fair bit. I really dislike the Q/A interfaces (mostly due to the reasons that folks in the thread have outlined). I'm personally ambivalent to the ask.toolforge.org prototype, though I wonder if instead to prompting the question, the interface could silently engage the reader to page snippets? (For example, iff a user types in "Company that owns biggest browser", y'all could silently switch from using CirriusSearch to surfacing Google#Google Chrome or similar). Sohom (talk) 14:19, 8 January 2026 (UTC)

I specifically had in mind stuff like "underscoring the need for transparent provenance labeling" and "align with Wikimedia’s infrastructure and privacy standards." As I said it's neither here nor there, this kind of document at any workplace is more likely than not to be AI-assisted and there's no rule against it. Gnomingstuff (talk) 14:33, 8 January 2026 (UTC)

I wonder if the AIs learned to write that way from the kind of techno-corporate bureaucratese that certain types of people have been writing for a long time? Anomie⚔ 00:06, 9 January 2026 (UTC)

(Probably, which is why I suspect no AI usage, that language is a bit corporate-speaky, but I've seen it used in earnest were folks were not using GPT) Sohom (talk) 10:51, 9 January 2026 (UTC)

@Sohom Datta and @Mir Novov, I appreciate your notes and acknowledge your concern around perceived mixing of AI- and human-generated content, as it's one we take very seriously as well. User testing showed that the bot labeling was confusing and would have to be completely rethought if Q&A explorations are found to be worth continuing. Right now it's clear that the current iteration of Q&A is not in production- or even an experiment-ready state.

However, there does seem to be interest in improvements to the search to support semantic-style queries. If this continues to be the case, we would return with a proposal for an experiment around search improvements and establish guardrails and goals together. Similarly, if there is another concept for improving wayfinding (that wouldn’t lead to confusing AI- with human-generated content) we’d return again to discuss before proceeding.

Interesting idea on silently engaging the reader to page snippets! Would this look like directly taking the user to the relevant heading instead of the top of the article? Do you have any other suggestions for areas for us to look into for information-finding? EBlackorby-WMF (talk) 20:47, 9 January 2026 (UTC)

@EBlackorby-WMF It would definitely be interesting if the search could send you to a specific heading in a article or even use tech like scroll-to-text-fragments to highlight areas in a article relevant to the user's queries. Sohom (talk) 19:30, 13 January 2026 (UTC)

@Gnomingstuff, thanks for your feedback. It helped us realize we uploaded a still of the design concept instead of a GIF, fixed here, which may have led to confusion about this work focusing on “Because You Read”-style suggestions.

While Google is definitely not a role model for this work, it is the most popular global search engine for people to discover content from Wikipedia, thus making it an important tool for understanding modern reader expectations. We’re trying to see how we can support the kind of queries users are used to making.

As for people coming to Wikipedia from Google, readers are now often simply reading the previews provided by Google Knowledge Panels and AI summaries (or their LLM of choice), rather than visiting the articles themselves. This tendency could harm their understanding of both the article content and the Wikipedia project, as well as prevent them from potentially becoming editors.

Do you have any other thoughts on ways to improve findability of article information for readers? EBlackorby-WMF (talk) 20:39, 9 January 2026 (UTC)

• Those of us who (sadly) recall the early days of DWIM know that this can be a very ambitious project. Please accept that you will find it hard to get the "super goal" of fully understanding what a user wants, but that you can achieve a good deal by even simple and clever means. So please have 3 or 4 goals of increasing complexity and do the simplest one first. A trivial example is keyword similarities such as fast/quick. Of course, before all else you need to improve the page Semantic search! It is in hopeless shape. Last talk comment was in 2019. Looking back, in the late 1980's I met a young investment banker who was somewhat obsessed with funding companies to do semantic search. Then around 2007 or so I happened to see him again, he had become a venture capitalist, and was trying to fund a company to do... guess what, semantic search. The LLMS do some such things but that should be your 3rd project, I suggest. So please do proceed, but step by step. Thanks

Yesterday, all my dreams... (talk) 22:02, 18 January 2026 (UTC)

1. It's an important R&D subject. One main problem users have is finding tutorials, help pages, policies and guidelines using the search. That is for example because these don't show in autocomplete and the default search results. Please also look into this wish proposal for something parallel to the conventional search as it could greatly help newcomers find the relevant tutorial and guideline pages (or other meta pages and articles/sections too).
2. Rather than just semantic search things please also work on and consider things like better integration and awareness-raising about other things users could use to quickly find what they're looking for such as the deepcategory search operator along with awareness and skills in knowing & finding categories. Another concern is that too little attention is paid and priority given to what the real-world users of Wikipedia in real-world practice needs or would like to have.
3. Maybe average reads per day and/or time spent on site mainspace articles increasing or reader surveys improving. Difficult question but basically whether it's a real-world improvement to readers in practice.

Prototyperspective (talk) 22:15, 20 January 2026 (UTC)

Really interesting point about helping newcomer editors find what they need for help. I'll share that back with the team.

We're definitely thinking about ways to make good use of the deepcategory search operator, there's such a wealth of organized information in there that readers could benefit more from.

Average reads and time spent are good ideas to track usefulness.

Do you have any thoughts about potential design considerations to help readers/newcomer editors know the sorts of things they could ask in a search with semantic capability? EBlackorby-WMF (talk) 21:35, 27 January 2026 (UTC)

Thanks! Btw, I'm thinking of maybe making a separate wish that is more specific in some ways (e.g. the application area such as only for helping newcomers instead of the myriad of listed ways this could be used) and broader in other ways (e.g. not specifying WikiChat in title).

Agree. Various things could be made possible/accessible that's based on it such as making it easier to filter an existing search or having the semantic search make use of it (e.g. searching in deepcat:"Films" if the user is clearly searching for a film) but so far I've mainly just explored its practical use on Commons. One could also show a button like "Search help and meta pages" near the top that searches again for just these namespaces because all the namespaces things are unknown and confusing to readers – e.g. they don't know these pages are not by default included in the search results. Also of note is that help pages are often very long with so much info that is helpful for various specific applications that readers landing there would have a hard time finding it or discovering it – this is what the wish is about to a large part but it's probably a bit too long or not written enough for people to see the large potential there and probable need for this (+other approaches addressing this).

Design considerations: when entering into the search bar show one stylized dropdown item like "Ask Wikimedia" which if selected/clicked makes the search use semantic search. At the top show the info that as a short/quick way to use this enter ? or q followed by the question in natural language. To raise awareness about this search mode one could consider changing the default label from "Search Wikimedia" to "Search or ask Wikimedia". Then there's of course also various ways to tell newcomers that they can search for guidance/helpful info relating to their editing. In part related to that, one could make short videos that explain in bite-sized pieces how to edit Wikipedia and start them off by entering a question into the search bar like "q how to make a video start at a certain timestamp" which then would show the relevant wiki help page section that explains how to do it. One could also show a search input box for just help, policy, meta pages etc in the editing window (or a wikilink to a help hub page which contains this searchbox in the center). Prototyperspective (talk) 16:15, 28 January 2026 (UTC)

Working on a better search system is a good idea, question based search has been a my staple on Google for 20 years and now I use LLMs. Take the question how is gps accurate enough for surveying (how can the same system that says I am sitting my neighbour's living room be used with any accuracy). Wikipedia has the answer in Surveying, in the History section, 20th century subsection. Or we have an article: Real-time kinematic positioning, that is too complicated to answer the question efficiently. Neither Surveying or Real-time kinematic positioning appear in the top 20 results of a Wikipedia search (Toronto Marathon does though :-P). I tried answering this question more than 15 years ago on the Reference desk (I can't find it in my contribs now, kudos to anyone that can).

When someone has a question, they don't want a search to tell them "the answer may be in this 7,000 word article, have a look". Or they ask a LLM "write me 7,000 word passage that overviews the topic related to my question".

Wikipedia does topic overviews. Wikipedian's can make it easier to find information by placing anchors in article introductions to relevant sections and making articles readable for the general population. And they can participate in a human-written q&a system.

Side note: recently I used Google to search for perth contours (to make a map for a Wikipedia article). The entire screen on the first results page was dedicated to skin contouring clinics around Australia. When I scrolled down after the two results wanting me to pay, the CC BY-4.0 contours were found by searching the gov website that was 4th result. I am more than happy to write an answer to that question for the next person so they can avoid my terrible experience, naturally that is outside the scope of Wikipedia. Google search is vulnerable at the moment.

To answer to your initial questions:

1. I am not surprised that 98% of visits originate outside Wikipedia search (search engines offer better results), and people using Wikipedia search have learnt that it is only good for auto-completing a topic title.
2. Risks: Wikipedia provides articles that overview a topic and the current search box is effective at getting you to an article. If people want to find a Wikipedia article this behaviour with auto-complete is great. Unfortunately it is not good for everything else.
3. I think a decent search should be pursued regardless (to be honest I want a Google competitor that doesn't try to sell me stuff or generate erroneous answer), I am not sure what other options apart from hybrid there are. If hybrid can get me to the answer my question above faster, that is great.

Commander Keane (talk) 10:07, 12 January 2026 (UTC)

@Commander Keane, Thanks for this feedback! Yes, we think for now, hybrid search is the logical next step to explore. Keyword search definitely has its uses so we want to ensure we are building upon our existing capabilities. We’ll share more details on the initial experiment soon.

To your second point on risks, do you have any ideas for wayfinding within an article? EBlackorby-WMF (talk) 18:25, 13 January 2026 (UTC)

1. "What are your overall reactions to this exploration and the research behind it?" → Chat-style search is going to be a necessary part of Wikipedia as that becomes more and more how people expect to engage with the internet. Younger kids shout questions to Alexa or Siri without ever surfing the web. Early Wikipedia used a model that barely made use of search at all; this just feels like a logical step.
2. "Are there risks or concerns you think we should be paying closer attention to?" → A reader should always know upfront if any writing or content was generated by AI.
3. "What signals or outcomes would matter most in deciding whether a hybrid search approach is worth pursuing further?" → Do the changes result in people using Wikipedia's native search more or less? As search engines and AI software become increasingly eager to quote or even plagiarize Wikipedia, we need local solutions because without readers actually seeing the articles, none of them will ever become editors.

I liked the highlighting in the prototype. Cat is also a good example as it's 7853 words long and much of the specific cat information is spread across other articles. For example, I was recently trying to remember what to make sure to avoid when getting floor cleaner to use around cats. The answer (phenols) is on Wikipedia but located at Disinfectant § Phenolics.

On the search results example, the results copied over from cat have their citations omitted:

Cats have excellent night vision and can see at one sixth the light level required for human vision. This is partly the result of cat eyes having a tapetum lucidum, which reflects any light that passes through the retina back into the eye, thereby increasing the eye's sensitivity to dim light. Large pupils are an adaptation to dim light. The domestic cat has slit pupils, which allow it to focus bright light without chromatic aberration. [...]

Have you all tested ways to show the citations in the search?

Cats have excellent night vision and can see at one sixth the light level required for human vision.^[1] This is partly the result of cat eyes having a tapetum lucidum, which reflects any light that passes through the retina back into the eye, thereby increasing the eye's sensitivity to dim light.^[2] Large pupils are an adaptation to dim light. The domestic cat has slit pupils, which allow it to focus bright light without chromatic aberration.^[3] [...]

References

1. [1]

   Case, Linda P. (2003). The Cat: Its behavior, nutrition, and health. Ames: Iowa State University Press. ISBN 978-0-8138-0331-9.
2. [2]

   Ollivier, F. J.; Samuelson, D. A.; Brooks, D. E.; Lewis, P. A.; Kallberg, M. E.; Komaromy, A. M. (2004). "Comparative morphology of the Tapetum Lucidum (among selected species)". Veterinary Ophthalmology. 7 (1): 11–22. doi:10.1111/j.1463-5224.2004.00318.x. PMID 14738502. S2CID 15419778.
3. [3]

   Malmström, T.; Kröger, R. H. (2006). "Pupil shapes and lens optics in the eyes of terrestrial vertebrates". Journal of Experimental Biology. 209 (1): 18–25. Bibcode:2006JExpB.209...18M. doi:10.1242/jeb.01959. PMID 16354774.

Good luck with the project, Rjjⁱⁱⁱ (talk) 14:25, 13 January 2026 (UTC)

@Rjjiii, appreciate your thoughtful comment. To your third point, our hope is that the changes would result in more readers using Wikipedia’s native search, so that is a key area we will be testing here.

Your note about citations within surfaced results is really helpful. The linked example is a very early mockup and does not reflect any sort of final design choice, so citations will be carefully considered. In addition to highlights, is there anything else you would be interested in seeing in terms of surfacing in-article results? EBlackorby-WMF (talk) 18:28, 13 January 2026 (UTC)

@EBlackorby-WMF: It makes sense to get feedback early on. One note regarding citations is that a study on how folks read Wikipedia showed that people were checking the citations in medical articles (via the popup) even when they were not going to the linked website. I bring it up because I think it would affect how any testing is done. Few people follow citation links, but apparently, in context-dependent situations, some people are checking the citation itself to evaluate the type of source. Regarding "surfacing in-article results", I hesitate to suggest anything here because an important thing make clear to the reader is what has been added by their search plus the AI tool. Highlighting has long been used by search engines, so that's intuitive. For other elements, I suspect you would need to do some kind of test where you ask readers afterward to see if they were confused or mistaken. Rjjⁱⁱⁱ (talk) 18:57, 13 January 2026 (UTC)

Yes, I believe hybrid search is worth exploring. As an editor I use site full-text search to find related and duplicate material, and I'd like to be able to run longer and more natural-language queries and still get meaningful results. I'd also like to see better snippets on search results pages. It's interesting to see this question because a work teammate and I recently implemented hybrid semantic search to improve information retrieval for users of an internal reference website. For that website's purpose, AI-generated text is not desirable/appropriate, but users needed better relevance rankings for search results. We were using PostgreSQL full-text keyword search, and we added pgvector and embeddings generated with a commercial general-purpose foundation model, using reciprocal rank fusion to blend the results. (Switching to Elasticsearch was out of budget/scope.) To figure out whether hybrid search was worthwhile for us, I made a sample list of recent real queries and realistic queries, and we did a lot of qualitative testing to figure out whether the new approach returned similar or better results for the majority of sample queries, rarely worse results. We used a prototype where we could fiddle with the parameters, similar to https://semantic-search.wmcloud.org/. I'm no expert in any of this, but I learned a few things that may be interesting:

1. For my site, semantic search works better for longer and more complex queries, and keyword search works better for single-word and quoted queries. So for one-word and quoted queries, we just run keyword search, and for queries longer than ~15 words, we just run semantic search.
2. Snippet quality and presentation have a big impact on making search results meaningful and usable; people want to see a quick preview of their keywords in context in the document. We kept a relatively traditional search results page, but started offering multiple snippets and longer snippets from each document.
3. It wasn't easy to figure out a good chunking strategy for our documents, but chunking made a big difference for quality of ranking and snippets, both for traditional keyword search and semantic search.
4. We've had difficulty getting really good semantic search ranking with our very DIY approach. Some keyword queries that did well in traditional search got worse with early versions of hybrid search because the semantic search results were not helping. So we limited the impact of the semantic element by limiting the distance threshold. Tested a lot of queries to figure out the best threshold for us. We found that the right threshold lets semantic search shine when keyword search is struggling to produce any relevant results, without muddying up search keyword search results when they're quite relevant.
5. On the search results page, we changed the search input box a little bit - made it a multi-line entry box, with new labeling, to encourage longer queries and more natural-language queries.

Dreamyshade (talk) 06:52, 14 January 2026 (UTC)

• Coming late to this but it seems worth commenting on. First, broadly, I'd agree a hybrid search has major upsides if implemented well. For me, Wikipedia is already faster and easier than finding (accurate) information on google, and I would like that to be true for as many people as possible. It feels especially important as search engines seem likely to generate less and less traffic for us, even as they use our content for AI-powered answers. To skip ahead, the most major risks are fairly self evident: don't make the search worse for current users. In gauging success, I think something like clickthrough rate is much more important than session length or "depth", because it's well known most sessions are very short and that should be taken as a sign of Wikipedia's usefulness to people in the everyday, not as an opportunity for more "stickiness" or "user engagement".

With that out of the way, I wanted to express some mild puzzlement at the motivation and logic behind this project. You ask Why do readers find it easier to locate Wikipedia information elsewhere than on Wikipedia itself? It's a worthy question, but while I haven't been able to comb through all the research in detail, I haven't seen anything yet that points directly toward semantic search. It's certainly true that major search engines have semantic search, which certain users probably find convenient, but there are many other differences those platforms have that could plausibly make readers prefer them. For example, if I happen to open wikipedia on my mobile browser instead of the app, the local search bar becomes inaccessible once I scroll down to read the article. I can access duckduckgo with a tiny swipe at any time, making it far faster. I don't know that this is a surmountable technical problem, but I was just a bit surprised that alternate explanations or solutions to these discrepancies didn't appear to have been considered. Similarly, the degree to which this functionality is in-demand seems rather uncertain: apparently roughly 5% of queries use natural language. To me, that indicates the vast majority of current users probably don't need semantic search, and you should be very careful not to ruin things for them with this experiment. To be sure, 5% is not nothing, but it makes me wonder if this is really mission-critical, or if someone just noticed that google has semantic search and we don't.

Again, I'm really not opposed to exploring this, the justification just seems a little weak, and when we have critical tasks starving for attention and resources, I think it's fair to ask these kinds of questions. —Rutebega (talk) 08:08, 25 January 2026 (UTC)

@Rutebega Similarly, the degree to which this functionality is in-demand seems rather uncertain: Wikimedia currently does not have a "good" way to figure what the readers want and whether building a system is going to have the readers use it. Given that we have a decline in readership specifically because AI engines keeping eating our impressions, I (personally) feel like exploring possibilities to engage readers is more important, since if they go away, we might as well leave as well.

If you have alternate ideas, of things that will help readers engage with Wikipedia further feel free to share them, or if there are critical tasks starving for attention and resources that you want fixed feel free to share them at the annual plan talk page. Sohom (talk) 12:29, 25 January 2026 (UTC)

@Sohom Datta, I wouldn't at all dispute that exploring possibilities to engage readers is more important now. I had hoped it was clear from my comment that I do support this exploration. Eliza asked for overall reactions, and I was responding to what I see as a potential opportunity for more explorations that could address the same root problems. I also wanted to give Eliza and the project team a chance to explain more about their work and rationale, since there can be a big knowledge gap and at times a sort of language barrier when it comes to communications about these kinds of initiatives, at least for someone like me with no real background in MediaWiki.

I did not want to veer off-topic by bringing up other ideas for improvements, as I don't think this discussion was soliciting those. Since you asked though, I was reminded of a very petty grievance I have that nonetheless could be investigated as related to this topic: I have always been totally mystified that Vector 2022 moved the search bar to the upper left corner of the UI, far from all the other controls. I continued using Vector 2010 for several years mostly because of this, but support for dark mode and other features eventually convinced me to put up with it. I have to imagine some UX research was done at the time, but I have a hard time imagining why anyone would prefer it this way, and it's not aligned with other sites I regularly use, where search is almost always top right or centered. Obviously this does not qualify as an issue of critical importance, but I think it's worth paying attention to how our existing UI design impacts some of the user behavior we are trying to modify, and I may try to raise that appropriately regarding the annual plan. Thanks for engaging, as always. —Rutebega (talk) 19:22, 25 January 2026 (UTC)

@Rutebega That is not a bad shout to be honest! I do think making the search bar more prominent by putting it in the middle is a good idea! Sohom (talk) 20:04, 25 January 2026 (UTC)

@Rutebega Thanks for your detailed and thoughtful comment. Your question about how we arrived at semantic search as the answer to this problem is a good one! The simplest response is that based on the qualitative research we’ve done, we landed on semantic search as one possible solution to this problem among many, and one that seemed the most reasonable starting point. There are a variety of other improvements that could and should be made to the search experience on Wikipedia as well. In particular, improving the UI has a lot of potential (your sticky search bar idea is intriguing!).

Some highlights from the literature review that might interest you:

• User studies have shown that readers have specific expectations about Wikipedia’s search functionality from their experience with other platforms and which are not met by our current search. We believe at least part of this is due to lack of semantic search capabilities on our sites.
• A major pain point relayed by all language wiki readers during the course of this research was the inability to properly find information on Wikipedia due to lack of natural language search, as well as having to put in multiple search prompts before getting to desired information.
• Research about discovery needs of in-depth readers highlights that readers prefer external search engines over WP search because the former offers advanced search capabilities (e.g. semantic search via natural language queries).

One relevant quote from our Readers Foundational Research: “Wikipedia search forces you to almost have the exact wording that is inside of the Wikipedia pages… You can't just ask a question like you do on Google and get the Wikipedia searches that are relevant to that question.”

Basically, we think the decline in direct traffic paired with people using external sources for meaning-based queries to navigate to our content are strong signals that we are underperforming in this area. That said, the only way to determine if semantic capability can meaningfully move quantitative numbers is in an experiment to test it with Wikipedia traffic which is what we hope to learn in this exploration.

Thanks again for your feedback. Do you have any other ideas on potential improvements to the problem for us to look into? EBlackorby-WMF (talk) 23:27, 28 January 2026 (UTC)

Google is a terrible model for a search engine; from the perspective of the user, they have been destroying the search engine for decades to please their customers. "Remember that you are not the customer, but the product." A good design goal for a user-oriented search engine is to avoid false positives. Google used to have syntax for "this must be in the candidate" and "this must not be in the candidate", but they removed the support in order to increase their hit counts. I urge that any new search engine provide an easy way to specify

1. Must include this string as is: no changes in spacing, no changes word order, no substitution of synonyms
2. Must not include this string
3. Nice to have: Must include a string matching this regex
4. Nice to have: Narrow the results of the previous stringsearch

The scoring used to train any LLM used for the search should prioritize accuracy over hit count. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:01, 25 January 2026 (UTC)

Thanks @Chatul. The notes around specifications and scoring are really helpful, I'm passing along to our engineers for consideration. Are there any other guardrails you'd recommend keeping in mind through this work? EBlackorby-WMF (talk) 21:43, 27 January 2026 (UTC)

• Helping people find information on Wikipedia is a good aim. Using machine learning methods of natural language processing and semantic search is a reasonable way to approach that problem. But I would highlight, as a crucial design goal, that Wikipedia should allow people to search with natural-language queries without making them feel like they are using an LLM chatbot. That bar of "feel like" means avoiding even aesthetic details that might remind people of chatbots. Those little chat popup interfaces on every website are right out. I like bringing readers to a highlighted section of an article, rather than ever providing a response in text (even a response that is a quote from the article). There are probably many ways to achieve a useful interface that still reassures people that they are on Wikipedia, and not the rest of the internet, so they are getting human-written answers. ~ le 🌸 valyn (talk) 23:54, 26 January 2026 (UTC)

  • look at how archive.org uses metadata for search; e.g.:(Category:Foo)
  • how would I find pages with these properties: American + photography + Italian name + people + fashion

  Piñanana (talk) 12:44, 3 February 2026 (UTC)

  Like so: deepcategory:"American people" deepcategory:"Photography" deepcategory:"Italian-language names" deepcategory:"Fashion".
  I previously left a comment about the deepcategory search operator and potential/needs for improvements regarding it; categorization can also be improved (exa mpl es). Prototyperspective (talk) 13:06, 3 February 2026 (UTC)

  Agree on categories I think the research team have to specify lots of scenarios similar to what you have mentioned. Categories on wikipedia serve little purpose because there are so many unions, all maintained by off wiki batch processes. The major user of categories is wikidata. Is there any evidence that readers navigate by category?

  There are a few UX issue.

  - As mentioned by others, It risks creating an AI layer over the Wikipedians work (see simple summary)

  - makes Wikipedia risk feeling like google AI (answers your spelling mistakes) or grok (guesses what you meant) or Facebook (spooky guesses what you meant based on your searches)

  - Wikipedia UX does not reward experience, exploration, or allow preference (except some skin options).

  - Experience - More advanced search methods are not visible on mobile, and can only be chosen after a search on desktop. SQL/quarry, special search, key words, and regex are invisible.

  - Exploration - Readers expect the left pane to have tools, seperated under clear headings with expandable sub headings. There are two search options visible on the UI (search bar and left pane - portal). a search heading with the options underneath would be far more interesting, and allow links visualisation tools of navigation.

  - Preference - If this is rolled out as the default, then there will be community and reader pushback. ASD needs preference and control of their space. (sed Vector 2022). I am suggesting an editor preference profile on village pump ideas Wakelamp (talk) d[@-@]b 13:30, 3 February 2026 (UTC)

  are operators and parameters conflated ?

  • at Help:Searching#Spaces : "operators, such as intitle: and incategory:"
  • later at Help:Searching#Parameters : "The main parameters are namespace:, intitle:, insource:, incategory:, and prefix: (namespace as used here isn't literal – use the name of the actual namespace desired)."

  is deepcategory a search operator/parameter like insource ?

  examples:

  • for example, find pages that link to filmreference.com ( task: remove Reftags to filmreference.com )

  Special:Search/insource:www.filmreference.com

  • for example, find pages that link to imdb.com ( task: remove Reftags to imdb.com )

  https://en.wikipedia.org/w/index.php?search=insource%253A%22cite%20web%7Curl%253Dhttp%253A%252F%252Fwww.imdb.com%22

  Wikipedia Search: insource:"cite web|url=http://www.imdb.com"

  (I cant make: [[:Special:Search/insource:"cite web|url=http://www.imdb.com"]]

  Piñanana (talk) 15:08, 3 February 2026 (UTC)

  Categories serve lots of purposes such as finding articles and creating lists. They could be used more and this would require some technical improvements – for example a cat-exploring module or integrating them better into into the search filter options. Disagree that the major user of categories is wikidata, that's just one way these are useful. Of course do readers use categories, the question is how many / could more be done to make more people aware of these and how they could use these.

  What's proposed here would not be "creating an AI layer" and isn't like the simple summary. I wonder if you actually read the thread starting comment. Moreover, even if it would be you would need to explain what you mean by that and more importantly where you see why problems. Regarding Wikipedia feeling like this or that, maybe that's exactly what people want (/need). Again more assumptions. But there also the search would show results just like before but also enable this for additional results (or via a new separate search mode(?)). Also all AIs I tested manage to deal with your typos and show you things based on a typos-corrected query.

  Wikipedia UX does not reward experience, exploration sounds interesting but what do you mean? Nevertheless, seems offtopic here(?) SQL/quarry, special search, key words, and regex are invisible. you describe a reason for why semantic search could/would be useful. Regex,SQL/quarry is not sth people can just easily enter; people can't just write some SQL and regex when searching sth on the go on mobile or even in general. Semantic search can make use of such things in simple terms (make them accessible to real people in the real world en masse). If this is rolled out as the default the plan isn't to replace the normal default search. I'd oppose that too.

  @Piñanana: your question is a bit unclear to me but I'll try to answer it; re is deepcategory a search operator/parameter like insource ? as said earlier, it's a search operator (a powerful too-unknown underused one). It's not much like insource if that's what you were asking. I cant make: [[:Special:Se… See Template:Search link. examples: I don't know how these relate to the topic; that's use-cases for the insource search operator. Prototyperspective (talk) 15:31, 3 February 2026 (UTC)

  @Commander Keane ~2026-77304-4 (talk) 16:26, 4 February 2026 (UTC)

  The title is "Early Explorations Into Semantic Search: Phase 0", so I included all the search methods for comparison, as readers might prefer an advanced search similar to the Internet archive and journals. A hybrid search method with a single search input is best for looking at a new subject, while an advanced search is much better at detail.

  • Category Using 2021 server data, Large Scale Characterisation of how readers browse Wikipedia found that only 0.39% (Desktop) and 0.2% (laptop), Readers include editors. And Categories are not visible on the Android App by default. There are 2.4 million categories.
  • "What's proposed here would not be "creating an AI layer" and isn't like the simple summary. I wonder if you actually read the thread starting comment. " .. : I did, but the researchers are suggesting a combination of semantic (which today means LLM AI) and lexcia lexical. A hybrid search method with a single search input is best for looking at a new subject, while an advanced search is much better at detail. Editors and Dev forget, that the current advanced is specified as a default in preferences for logged in editors , while other users have to "access advanced search on Wikipedia, type any query into the search bar, press enter, and then click the "Advanced" option on the search results page to filter by namespace"
  • " SQL/quarry, special search, key words, and regex are invisible" see [Help:Searching]] as are the[lexical and advanced search options on preferences
  • Exploration - rewarding reader through discoverability of features goes hand in hand with search. (greyed out menu items was how I discovered hidden features in systems) Wikipedia stickiness is based on going down rabbit holes. This suggestion is aimed at making the experience easier which will mean less clicks, while we should be aiming the various search options more visible to differentiate us from external search.
  • Glad we agree on preferences :-) But if it's on for all readers, then I am not certain what happens when they become editors
  • Lastly, the worst case for me is that this is brought in using wikimedia software rather than using OpenSearch or similar. New features are liked by Mediawiki's customers, but having everything done in house increases up maintenance dev and increases the risk (bugs, security) because it is not used elsewhere Wakelamp (talk) d[@-@]b 07:33, 10 February 2026 (UTC)

I am drafting a template at Template:Career FNCS results middle/sandbox. It works fine when I use #switch as follows:

{{#switch:{{{made_grands|}}}|true=Yes|false=''Eliminated in {{{elimination_stage}}}''}}

However, it seems to me that the code above could be re-written using #if as follows:

{{#if:{{{made_grands|}}}|Yes|''Eliminated in {{{elimination_stage}}}''}}

If I do this, and enter made_grands=false, the parameter is still treated as true, and thus produces "Yes". I am very new to conditional expressions; am I doing something obviously wrong? Rockfighterz M (talk) 21:37, 9 February 2026 (UTC)

@Rockfighterz M: #if tests for non-empty. See mw:Help:Extension:ParserFunctions##if. PrimeHunter (talk) 21:52, 9 February 2026 (UTC)

@Rockfighterz M I think you're looking for #ifeq:, not #if:, but even then you'd need two nested if statements to cover the case where the value is neither "true" nor "false". --Ahecht (TALK
PAGE) 18:47, 10 February 2026 (UTC)

Crosspost (sort of) from Template talk:Pounds, shillings, and pence#Alternative coding, I've been looking for something that lets me output non-decimalised numbers. So far I've been using {{GBP|10 8s 9d}} to produce £10 8s 9d for example, but leaving what is effectively text inside the curly brackets doesn't feel right and might break downstream applications e.g. inflation calculators.

I suppose the ideal outcome might be {{GBP|x|y|z|nd}}, with numbers in place of x, y, z, and "nd" for "non-decimalised". Empty y or z values would return a negative sign, e.g. £x/-/z or £x/y/-, and an empty x value would skip the "£" symbol as well e.g. y/z, y/- or -/z. Of course, values y and z would also need to be capped, with any excess being moved to the prior column e.g. 30 shillings would be displayed as £1/10/-, unless some extra term like |abbr=on was included?

Critically, the template system cannot require typing the £ symbol, because not everyone has that on their keyboard. Also, whatever system ends up working for this should be copy-able to other areas e.g. Australia where the three-piece currency system used to apply. ({{AUD|}} doesn't currently support £sd but it might one day.)

Anothersignalman (talk) 16:03, 7 February 2026 (UTC)

@Anothersignalman: While this could be implemented, I'm unsure why you want this. What's the problem with just {{GBP|10}} 8s 9d to get £10 8s 9d without including any letters? – Scyrme (talk) 23:08, 9 February 2026 (UTC)

Also, after looking at the code for {{£sd}} and {{GBP}}, it would probably be much more straightforward and cleaner to implement this as a new template rather than modify the existing ones. (And if you want the inflation calculator to work, that would probably require converting the input to decimal then converting it back. It doesn't look like the inflation calculator is set up to take nondecimal inputs.) – Scyrme (talk) 23:21, 9 February 2026 (UTC)

I've since swapped over from {{GBP}} to {{Australian pound}} for my articles, which I didn't know about before and seems to have solved my problem. My original concern was that I wanted to keep all numbers related to specific figures within a set of curly figures on a matter of principle, but the inflation element was a secondary concern. If I still needed this, I'd have accepted a modification to {{GBP}} so that it could take a decimal input and output the £sd arrangement, because I could then request or find a separate template that took £sd inputs to generate the decimal output and put that inside the GBP set. This would also have solved issues where a source reported a cost as say 30s instead of £1 10s. Anothersignalman (talk) 05:46, 10 February 2026 (UTC)

@Anothersignalman: Are you only using {{Australian pound}} with Australian predecimalised currency? The template links to Australian pound when it uses £. If you're also intending to use this with UK currency, maybe it would be helpful to modify the template to allow that link to vary (or to display no link by default), and move the template to a broader title? ({{Australian pound}} would exist as a redirect after the move, so the existing uses would still work.) – Scyrme (talk) 17:02, 10 February 2026 (UTC)

No, I'm writing an Australian article, I just used GBP because it had the right symbols and the two currencies were tied to each other in the relevant time frame. Anothersignalman (talk) 08:10, 11 February 2026 (UTC)

Suggestion Mode is a new Beta Feature for the VisualEditor that proactively suggests actions that people can consider taking to improve Wikipedia articles, such as "add citation", "improve tone", or "fix an ambiguous link". The feature is locally configurable, and can be locally expanded. It will be available here as a new Beta Feature on Tuesday (and thus, in practical terms, only visible to experienced editors to begin with).

The goal of this limited early release is for us to work together to:

1. Identify what issues and improvements need to be addressed before evaluating the impact of the feature on newcomers through a controlled experiment.
2. Generate ideas for new suggestions you think would be worthwhile to implement. More on this below.

The feature is closely related to the existing Edit Check feature which shows actionable feedback to newcomers as they edit, and shares many configuration details with it.

Why Suggestion Mode?

Suggestion Mode is meant to benefit two audiences:

• [Primary] Newcomers who are eager to edit and struggle with how to start doing so constructively, plus giving them encouragement to explore the policies and guidelines.
• [Secondary] Experienced editors seeking easier ways to find out what might need fixing, and assembling the context needed to decide how and if to act.
  • Note: volunteers have helpfully created many tools/gadgets/user scripts to help with the above. Suggestion Mode seeks to make the functionality these tools offer easier for more people and in more languages to access.

How it works

When an editor who has the Beta Feature enabled opens an article with VisualEditor, if there are any of the available types of suggestion within the article content, then one or more suggestion cards will be shown alongside. Each card contains a description of the potential problem, a link to the policy or guideline the suggestion is based on, a button to start resolving the problem, and a way to provide feedback about the suggestion itself. You can see some examples and the feedback flow below. See mw:VisualEditor/Suggestion Mode#Design for more examples.

• 
  "Add a citation" example on the article w:en:Mango
• 
  "Convert citation" example on the article w:en:Gooseberry
• 
  "Revise tone" example on the article w:en:Melon
• 
  Desktop feedback workflow
• 
  Mobile feedback workflow

The team has started with an initial set of suggestions to demonstrate the concept. They are derived from existing tools, policies, and content guidelines. We're very interested in your recommendations for additional types of suggestions, to add to the growing list in T360489. The complete list of initial suggestions can be seen at Special:EditChecks. You can test the feature immediately, via this user script.

Local configuration

The aspects of a suggestion that are community configurable will vary on a case-by-case basis. They can be configured by admins at MediaWiki:Editcheck-config.json, to enable/disable individual suggestion types and control parameters for each type (e.g. the categories and sections it should/should not be shown within, the cumulative edits someone must have made to see a suggestion, etc.). The listing of available parameters is at mw:Edit check/Configuration. In particular, the textMatch suggestion type is a relatively simple system that finds words or phrases within the text, and suggests either replacing, deleting, or thinking about the text (along with a contextual guidance link). That sub-feature is easily expanded/adapted in any way you wish. In the future, we hope to support regex for these suggestions.

Known issues

The team is currently working on: YAdding the ability to include links within the text-match types of Suggestions (e.g. The "English variant specified" type will link to MOS:RETAIN next week) (T416511); YAdding the editsuggestion-visible tag to monitor edits that are made when any Suggestions have been seen (T413419); Adding the ability to see the specific suggestions someone acted on within a given edit session (T416535); Improving the feedback flow to be more streamlined (T401739); Adding the ability to toggle the visibility of the Suggestions cards entirely (T415589).

Get involved

For now, Suggestion Mode will be available as a Beta Feature, in order to collect your recommendations for: changes to the default "descriptions" (both the wording and the links), feedback on the individual suggestions and their results, and requests/ideas for further types of suggestions. The team and some volunteers have been experimenting with the checks for the last few weeks, plus discussing the tool in Discord and Phabricator, and the team has fixed a number of issues, but we need your help finding more ways to improve this feature. We also hope you will have additional ideas for new types of suggestions, that can either be implemented entirely locally as text-match suggestions, or requested for developer-assistance in making more complex suggestions; there is a listing of existing suggestions in T360489. Please share your thoughts on the feature either here or at mw:Talk:VisualEditor/Suggestion Mode, and use the built-in feedback system to share any details about problems with specific suggestions. Much thanks, Quiddity (WMF) (talk) 00:29, 6 February 2026 (UTC)

Looks pretty cool. can't wait to try it out. —TheDJ (talk • contribs) 09:08, 6 February 2026 (UTC)

Agree, I think so too. This could be quite useful for the community. What I don't like here is that it's just for the VisualEditor and not the wikitext editor (albeit this feature is probably most useful for newish editors and not so much for active editors already overburdened with tasks anyway who don't benefit much from any such further ones – those are probably mostly using the wikitext editor but I could be wrong about that). Prototyperspective (talk) 15:28, 6 February 2026 (UTC)

Personally I think the difficulty involved in making it work in both modes would not be worth the extra dev effort. -- asilvering (talk) 18:36, 6 February 2026 (UTC)

Yeah, the problem is that you need two completely different systems when looking for suggestions to make and when applying them to the document. VisualEditor is easier to do, because it offloads the whole "you must parse and modify wikitext without breaking it" part to Parsoid, and lets us work with something that's already got some level of semantic meaning applied to it.

We actually could reuse this, kind of, by (essentially) running VisualEditor in the background, and having your wikitext sent into the API and parsed, working out what suggestions there are, then asking the API again to tell us what ranges in the wikitext source they correspond to. Then doing similar things when you want to take an action in response to a suggestion, etc. It'd be painful and slower, as you might imagine. DLynch (WMF) (talk) 17:55, 9 February 2026 (UTC)

This feature is now available. You can enable it at Special:Preferences#mw-prefsection-betafeatures. (If you have previously selected the preference for "Automatically opt-in to new Beta Features", then you still need to open your Preferences page once, in order to enable any new type of Beta Feature.)

Please do share your thoughts and feedback (and especially your ideas for other types of Suggestion that could be implemented (either by the team, or by yourselves locally via textMatch), that might be helpful for newcomers to act-on and learn-from) so that we can continue to improve it for you. Thanks. Quiddity (WMF) (talk) 18:52, 11 February 2026 (UTC)

Hi everyone,

I’m posting on behalf of WMF's Reader Growth team. The week of February 16 we will launch an A/B/C test that adds a Table of Contents on mobile web and auto-expands all article sections as a way to get readers information faster by addressing navigation difficulties. Our hypothesis is that by giving readers a table of contents to see sections at a glance, they will be able to more easily find what they’re looking for.

Why are we doing this?

We see this work as a part of addressing the decline in pageviews on Wikipedia. We want it to be easier to access content on the site, especially on mobile where newer readers tend to come in. WMF’s Reader Foundational Research found that difficulty with in-article navigation, in particular mobile, is a top complaint among readers. We’re trying out a table of contents on mobile web to see if it supports ease of browsing based on data that it can be helpful for navigating. The Wikipedia Android app, for example, has a table of contents, which on average gets opened almost 4 times per user, much more often than users start a search, which is only an average of 1.5 times a session. The app also sees 71.1% clickthrough rate, indicating strong usage on small screens.

What idea are we testing?

Article sections are currently collapsed by default on mobile, which was intended to save users time in navigating as they scroll through long paragraphs of text. However, we suspect that this default may contribute to navigation difficulties since users must first open individual sections before reading. In December 2025, we conducted an experiment on Arabic, Vietnamese, French, Chinese, and Indonesian wikis to 1) auto-expand all sections in an article by default and 2) pin the header of the section in the viewport to the top of the page.

We found that this change actually lowered the retention rate for readers by about 1.5% and shortened the amount of time they spent onwiki. We suspect that auto-opening all the sections on mobile ended up causing navigation difficulties by creating a wall of text, resulting in readers feeling overwhelmed or frustrated and leaving. So we decided to try out something different.

Now we want to see if offering a Table of Contents will improve those navigation needs. The new test will add a Table of Contents button on mobile. When users tap it, a panel slides up from the bottom showing the article’s section headings, which they can then click to jump to different parts of the page.

What stage is this project in?

This project is in phase 1: launching a small test with an early version of these ideas.  It’s not yet clear whether this feature will be an improvement for readers, so we want to test it to determine whether to proceed into phase 2: building a feature.  

What is the timeline?

The experiment will go live the week of February 16 and will run for four weeks. It will affect up to 10% of mobile users on Arabic, Vietnamese, French, Chinese, and Indonesian Wikipedias and up to 1% of mobile users on English Wikipedia. Once we have the results, we will come back here to discuss results and decide whether we want to proceed with this idea.

Thank you! EBlackorby-WMF (talk) 15:59, 10 February 2026 (UTC)

Something to entertain since you're poking around would be to display some lesser set of the table of contents, perhaps all items pointing to an (h1), h2, or h3, and excluding any pointing to h4s. Izno (talk) 19:30, 10 February 2026 (UTC)

The TOC in the first image on the right is a more familiar & self-explanatory kind of TOC I think. What is missing is a button to expand all section easily with a click on desktop. Is there an issue about this? Glancing over the sections is a good way to find what you're looking for or in discovery-mode see if there's something you may find interesting in an article but having to uncollapse each section individually is too much and one also starts to think about which sections may or may not be relevant instead of just doing that quick click.

.

Also I kind of liked how the TOC used to be in a way because when opening an article one could see the TOC and thereby somewhat a form of summary of the contents of the article at the top right away without having to click anywhere. I have the TOC collapsed to the top instead of the sidebar. On the other hand the always displayable TOC also has big advantages. Why not combine the best of both or give logged-in users to configure a setting to have that: display the left sidebar with the TOC when the mouse goes to the minimized panel on the left but when just reading the article make it a small panel that doesn't take up space. I could make an illustration but this video also shows what I mean. One could also have an option for whether or not the sidebar should display when opening the article or even then only when hovering left. The sidebar is usually just mostly whitespace so I have it hidden even when I like seeing the TOC often and miss the quickly glancable TOC at article opening. This would also make it faster and easier to find some info. Prototyperspective (talk) 00:57, 12 February 2026 (UTC)

Resolved

Can someone with the relevant permissions and technical knolwedge please revert Template:GeoTemplate back to a state where English language geohack works? The error seems to have been introduced yesterday. Tæppa (talk) 13:28, 6 February 2026 (UTC)

It's not protected so I suggest reverting to an earlier working version. Pinging @Tæppa — Martin (MSGJ · talk) 14:03, 6 February 2026 (UTC)

It is extended confirmed protected. Tæppa (talk) 14:10, 6 February 2026 (UTC)

Wrong user! @Mapeh — Martin (MSGJ · talk) 14:04, 6 February 2026 (UTC)

This is not a problem with Template:GeoTemplate (see Template talk:GeoTemplate#What happened?). It's at toolforge, but I cannot work the best way of filing a phab: ticket for a toolforge problem. --Redrose64 🌹 (talk) 22:49, 6 February 2026 (UTC)

(Discussion also at w:Template talk:GeoTemplate#What happened?)

Pinging @Trappist the monk: who edited the w:Module:Lang the day before (some) of the geohack language pages broke. My original thought was that the use of <br />{{lang|ar|خَرائط فلسطين المَفتوحة|rtl=yes}} broke the page, but <br />{{lang|he|עמוד ענן|rtl=yes}} has been there a while.

Just for interest:

Arabic (rtl) works , Hebrew (rtl) works , Pashto (rtl) doesn't work , Yiddish (rtl) doesn't work, Chinese (ltr) doesn't work , Russian (ltr) works . Tæppa (talk) 00:08, 7 February 2026 (UTC)

The change I made at Module:Lang was for {{transliteration}}. At this writing, there are ten {{lang}} templates in {{GeoTemplate}}. All ten are used for presentation and have nothing to do with the &language= query portion of the geohack url.

—Trappist the monk (talk) 01:12, 7 February 2026 (UTC)

Thanks for the clarification.

For the record, all of the above links (Arabic through Russian) are now "broken" so it's probably nothing to do with the templates that the wikipedias have for each language. Tæppa (talk) 22:02, 8 February 2026 (UTC)

As someone who reads a lot of geographic articles, this GeoHack glitch has been annoying for the last couple of days. I think the correct place to file a bug report is here. In case it helps to debug: I notice that, upon opening GeoHack, the table of links to Google Maps, OSM, and other services very briefly displays but disappears after a split second. If I use Firefox's "reader view", all the links are visible. HTH. ~2026-87494-1 (talk) 01:49, 9 February 2026 (UTC)

The reason Geohack is broken seems to be related to this change: 1234316. Geohack was depending on html comments to find the main content. These html comments are removed in the latest mediawiki update. --wimmel (talk) 08:57, 10 February 2026 (UTC)

 Working again --Redrose64 🌹 (talk) 18:44, 12 February 2026 (UTC)

Per phab:T413542, a task was created to use OOUI in the edit filter interface, but there's a major side effect: the view is messed up in desktop (laptop/computer), and the Ace editor is completely broken in mobile/desktop view (in iOS/Android). I am notifying the community about this error (which has probably affected all wikis) which should be fixed immediately. Codename Noreste (talk • contribs) 20:38, 12 February 2026 (UTC)

(@David10244 I split this question to a separate thread from #Hybrid Search: Phase 1 - Early A/B Experiment on the Android App above, I think that is not related to your issue. Matma Rex talk 02:58, 12 February 2026 (UTC))

@EBlackorby-WMF Will this fix the issue I see, where searching fir "Sense and Sensibility", or "Pride and Prejudice" (without the quotes) does not bring up what's expected?

When I search for Sense and Sensibility, the suggested matches all startcwith "Sensibility"! David10244 (talk) 05:23, 7 February 2026 (UTC)

I don't get that result. Do you have a link? WhatamIdoing (talk) 05:26, 7 February 2026 (UTC)

@WhatamIdoing When I click the magnifying glass next to my name, then type sense and sensibility (actually, all lower case), the first suggested result is the article Sensibility. The next suggestion starts with Sensibility. I'm not at my desktop, so I can't give much more info. I can't make and attach a screenshot easily from my tablet (I don't know how). 🙂 David10244 (talk) 05:35, 7 February 2026 (UTC)

Here's a WP:WPSHOT showing what happens when I type sense and sensibility (all lower case, as you can see) into the search bar at the top of the page.

Is that what you're talking about? Do you get different results when you do the same thing? WhatamIdoing (talk) 07:18, 7 February 2026 (UTC)

@WhatamIdoing Yes, I get different results. My list starts with "Sensibility" (pointing to the article by that name) and the second item is for the book named "Sensibility Objectified". It's very strange that we get different results. I don't have any local scripts in common.css or anything like that. David10244 (talk) 04:00, 11 February 2026 (UTC)

@David10244, please try this link: https://en.wikipedia.org/wiki/special:Search?safemode=1 and see if you get the same results. WhatamIdoing (talk) 21:59, 11 February 2026 (UTC)

@WhatamIdoing That link gives me the expected results, showing the movies and the book. David10244 (talk) 05:55, 13 February 2026 (UTC)

mw:Safemode turns off user scripts and gadgets, so that indicates that the problem is almost certainly somewhere in User:David10244/common.js (seems unlikely to me, but others will know more than I do) or in Special:Preferences#mw-prefsection-gadgets (I have no clue which). WhatamIdoing (talk) 06:02, 13 February 2026 (UTC)

Do you get different results if you try the different "Search completion" modes at Special:Preferences#mw-prefsection-searchoptions, or a different skin (e.g. Timeless)? Matma Rex talk 02:55, 12 February 2026 (UTC)

@Matma Rex I don't know; I don't want to change my search preferences or skin at the moment (I'm about to go to bed). I have never changed my search preferences OR my skin. I'll try soon. Thanks. David10244 (talk) 05:57, 13 February 2026 (UTC)

@Matma Rex Thanks for splitting this. David10244 (talk) 05:57, 13 February 2026 (UTC)

The sandbox link in the personal toolbar is no longer red even if it doesn't exist, in Vector (both kinds) and Monobook. It's still red in Timeless. The class new is added to <li> not <a> so a.new is not being applied. Nardog (talk) 02:35, 12 February 2026 (UTC)

This is filed as T408968. Matma Rex talk 02:54, 12 February 2026 (UTC)

No, it just became blue in Vector legacy (and I assume Monobook). Nardog (talk) 05:59, 12 February 2026 (UTC)

It's presently blue in MonoBook. I don't recall noticing it when was last shown as red except when first added some years ago. --Redrose64 🌹 (talk) 22:40, 12 February 2026 (UTC)

In Vector-2022 this is intentional. In other skins, it's regression: phab:T417372. – Ammarpad (talk) 11:44, 13 February 2026 (UTC)

the templates for the co-articulated and the non-pulmonic consonants over here doesn't format correctly, but it was fine the other day, heres an example of the page on jan 24 on the wayback machine DomTheNightShiftEditor (talk) 11:24, 13 February 2026 (UTC)

Sorry, fixed. Nardog (talk) 12:00, 13 February 2026 (UTC)

damn, already? Thanks, really appreciate it DomTheNightShiftEditor (talk) 12:03, 13 February 2026 (UTC)

Hi! I don't know whether I should put this here or in the Teahouse, but I was about to remove the deprecated parameter "nationality" from the infobox of Fernán Mirás and for some reason the preview warning doesn't appear, even if it hasn't been removed. It's not an issue with my browser, since in the other pages I removed the parameter from, the warning appeared. I removed the space between the infobox and the template above, thnking it would help somehow solve the problem, but nothing changed. Thanks, Bloomingbyungchan (talk) 15:36, 13 February 2026 (UTC)

The |nationality= parameter in that infobox is blank, so it should not show a warning. It was erroneously showing a warning before, but that error was fixed yesterday. – Jonesey95 (talk) 15:41, 13 February 2026 (UTC)

Thanks, I wasn't aware that it was an error, instead I thought that the warning was supposed to appear regardless of the fact that the parameter is blank or not. Bloomingbyungchan (talk) 15:54, 13 February 2026 (UTC)

Moving this here as I may get a better answer. The question is about AntiVandal. In the settings page, there's a setting for ORES score. I'm not understanding how that setting is supposed to work. I want it to mimic "likely bad faith" in Recent Changes, but it asks for a decimal? So what do I do if I want that behaviour? TheTechie^[she/they] | talk? 06:36, 13 February 2026 (UTC)

@TheTechie, I think you just set it to a low value, like 0.1. ORES has two values for edits "damaging" and "goodfaith". I assume this is the goodfaith one. — Qwerfjkltalk 12:15, 13 February 2026 (UTC)

I would guess it uses the same numbers as in the configuration here: but I'm still not sure how a single number can match that kind of configuration. Matma Rex talk 17:32, 13 February 2026 (UTC)

User:LaundryPizza03/CSD log is still not archiving. This is a followup to Wikipedia:Village_pump_(technical)/Archive_226#Page_not_being_automatically_archived. –LaundryPizza03 (dc̄) 22:50, 2 February 2026 (UTC)

Pinging participants from last discussion due to lack of participation: @Redrose64, PrimeHunter, Aidan9382, Graham87, and Jonesey95. –LaundryPizza03 (dc̄) 20:40, 8 February 2026 (UTC)

For what it's worth I checked and couldn't find anything wrong with the archiving setup this time. Graham87 (talk) 02:51, 9 February 2026 (UTC)

@LaundryPizza03: I don't know what stops the bot but try archiving the rest of 2024 manually and see if it picks up 2025. PrimeHunter (talk) 14:00, 13 February 2026 (UTC)

There are 12 sections left after doing that, so I will have to wait until March to find out. Ask the owners of ClueBot III (talk · contribs) to test the archive function on this page. –LaundryPizza03 (dc̄) 18:04, 13 February 2026 (UTC)

A reader asked me about a layout problem they're seeing with an article I currently have at WP:FAC. I suspect the issue is just that they're using an unusually wide window, but I would appreciate suggestions at Talk:Carlisle & Finch#Whitespace if there's some way I can improve on what I'm doing now. RoySmith (talk) 18:03, 13 February 2026 (UTC)

There is a {{clear}} template at the bottom of the Modern Lights section. If the images go further than the text the next section won't start until the images have been displayed. This results in the white space the other editor is seeing. You can remove the template, but then the images will flow down into the Navigation Beacons section unless you move one of the images elsewhere. -- LCU ActivelyDisinterested «@» °∆t° 19:37, 13 February 2026 (UTC)

I think it would be useful to see lists of articles that do not include any image, maybe with a column for the linked Commons category if it exists and a column for the image(s) set on the Wikidata item if there are any. The articles could be those in a category or especially some WikiProject list like Wikipedia:WikiProject Climate change/Popular articles or Category:High-importance science articles (corresponding articles, not the talk pages though). I think it's not unlikely that there is some way for this.

Asking this in the context of c:Commons:List of science-related free media gaps – this could be useful not just for adding images if a useful relevant high-quality one exists for the article, but also for identifying media gaps.

By the way, I was wondering whether to post this here or at c:Commons:Village pump/Technical.
Prototyperspective (talk) 14:49, 5 February 2026 (UTC)

You could find articles that have been tagged with Template:Image requested, but I'm not aware of any way to look for untagged articles. https://pagepile.toolforge.org/ will let you define a list of target pages, and that list can be used be used by other tools for various purposes, but, again, I'm not aware of any tool that would import such a list and identify missing images.

Images are one of the key things that readers want to find in a Wikipedia article. It would be nice to have more emphasis on finding and adding appropriate images. WhatamIdoing (talk) 23:59, 5 February 2026 (UTC)

Good idea – that method shows 191 pages in this query which is something one can start with.

A way to list articles without images would probably show way more results, would be more dynamic, and could be useful in more ways. It would not rely on users adding that template which is relatively rarely done. Additionally, having that template doesn't mean the article is short of even an image illustrating the main subject and entirely lacking images (also implies there is no image for the article in the page preview hovercard and in the Wikipedia app).

Agree on what you said there. Also of note that only very few users know of, see, and click the Commons category linked to an article – there's often high-quality files there but pageviews stats show that few go to these pages. After creating many Commons categories, I think most of them over a year later weren't even linked via the small often overseen {{Commons category}} somewhere in the article. One can often find images in categories that have been there for years but nobody ever added them to the article including articles including not even one image. Prototyperspective (talk) 00:26, 6 February 2026 (UTC)

Well, as I like to tell the people fighting over infoboxes: It'd be better to start with Category:Wikipedia articles with an infobox request than any random article. Searching by templates might be better if you get into larger groups of pages; deepcat searches sometimes time out for me. WhatamIdoing (talk) 03:38, 6 February 2026 (UTC)

Regarding the search link that checks for templates instead of the categories: don't know why it only shows 70 results instead of all 191.

Regarding the search link that checks via the two categories: I've looked into it further and excluded all articles that are biographies or films. Now it contains just 58 items instead of 191 and most of these are niche low-importance articles where I can't see how an image would be very useful or they already have an image for the article's topic (as in the case of Gypsum concrete). I nevertheless added the search query to the media gaps page.

deepcat searches sometimes time out for me this happens for deeply-nested categories which is why it won't really work for Category:Science currently. This may also be an issue here because not yet all relevant articles in that category branch have been tagged with the WikiProject template. Additionally, it doesn't look like one can scan if an article is in a category and its associated talk page in another. This would be useful because the WikiProject category is only set on the talk page. There's also ways to scan for articles in a category branch that don't yet have the WikiProject template but it's complicated and I guess barely anybody uses that (a tool for that would be great btw). Prototyperspective (talk) 15:55, 6 February 2026 (UTC)

Petscan gets about 95% of the way there - you can ask for pages in a category that don't have "a lead image", which I think is the single image returned in the API. Pages with no images will presumably also have no lead image. Andrew Gray (talk) 09:56, 6 February 2026 (UTC)

Following up on this - it seems "lead image" is defined from mw:Extension:PageImages and is a) one of the first four images in the lead section which b) has a certain range of ratios and c) is not explicitly excluded. So it is possible to have an article with images that nonetheless show up as no-image here. But having said that...

• Pages with a non-free lead image linked from Wikipedia:WikiProject Climate change/Popular articles (53/1000)
• Pages with no lead image linked from Wikipedia:WikiProject Climate change/Popular articles (137/1000)

It doesn't seem to be possible to do this in one step starting with a talkpage category (like importance tags), but it is possible in two steps via PagePile.

There's also an interesting query which I've found on Quarry and tweaked - thanks to @Cryptic for coming up with it originally - which identifies six "top/high" importance Science articles with no image links on the page. Andrew Gray (talk) 18:20, 6 February 2026 (UTC)

Interesting, thanks, I didn't know about the petscan feature to only show articles without lead image.

I tried to run it on Category:Science but the problem is that it's not possible because that cat has too many subcategories and also when limiting it to e.g. just 3 layers, it (query) shows too many results (>60.000).

I first thought maybe the approach of that petscan filter isn't really adequate as it also shows articles with images even lots of images – but looking more closely, I'm not so sure anymore: e.g. Agricultural science is listed buts its image in infobox does not illustrate agricultural science; Artificial intelligence is listed despite having many images but it does not have an image at the top that's some diagram explaining AI types and/or how AI works. Articles like Anthropology also miss some image that illustrates the subject well. So maybe the issue is not with the methods but simply that there's soooo many articles missing images (I think the community hasn't really begun to systematically address this).

What would be the best ways to address this that takes into account these issues: prioritizing articles that miss images, using only other methods that check whether there is any image at all in the article², somehow further filtering the petscan, somehow extracting fields or large-order topics lacking images?

² here's one additional way to check if there's any image whatsover (or animation or video or audio) in an article: deepcategory:Science -insource:"[[File:" (82,511 articles with incomplete results) Note: in this query it also shows articles with image in infobox so these would also need to be excluded somehow (maybe via filtering out things like .png?). One could combine this with incategory:"Commons category link is on Wikidata" to see just articles with no image but a Commons category (2,086 so this one seems quite actionable).

Pages with no lead image linked from Wikipedia:WikiProject Climate change/Popular articles (137/1000) Nice query, this one seems quite actionable as well. I'll probably link that on the science-related media gaps page as well and will look for other similar WikiProject pages for which to also create such a query for and maybe extract some topics in need of illustration/image (note that an article with lots of images illustrating the various subtopics may not be missing an image much even when there no lead image and ideally we'd like to have one).

interesting query which I've found on Quarry and tweaked … identifies six "top/high" importance Science articles with no image links weird that it only shows 6 items. So it seems like currently this query is not useful but maybe it can be tweaked further until it is. The description says that have no images of any sort (not even those from templates like {{unreferenced}}) so that seems to be the cause here; maybe one could exclude images in such templates but I also wonder why Research statement shows despite that there's several PDF document icon images on the page(?)

Thanks for your investigations and very helpful contributions on this issue. Prototyperspective (talk) 14:12, 8 February 2026 (UTC)

The pdf icons aren't added by image links - in a template or otherwise - but by a css class. They're not detectable with queries against the database even if we wanted to (other than by searching for external links ending in ".pdf", which isn't practical).

Excluding images included by templates isn't possible either. We've been asking the developers for an equivalent for simple links in WhatLinksHere for over two decades. And it wouldn't help anyway, since it would also exclude images in infoboxes.

What would help is a list of specific files to ignore, like {{unreferenced}}'s File:Question book-new.svg. Or I can write queries for non-free/non-existent lead images by talkpage categories/wikiproject ratings/etc. Asking at WP:RAQ is the best way for such requests not to get lost; my free time and attention is very limited this time of year. —Cryptic 18:59, 8 February 2026 (UTC)

Is there any code issue or wish or project page about enabling a functional Quarry query for seeing articles without any images via some list that specifies common icons used in templates (like the CCBY icon etc)?

So images in infoboxes are taken into account (in imagelinks) in that query? (If they aren't taken into account maybe one could take the results from the query and enter them into a second tool that checks for images in templates.) queries for non-free/non-existent lead images… that's a bit confusing to me – weren't you talking about the Quarry query earlier which doesn't check only for lead images but any images in the article? I would find this again more useful than scanning just for articles without lead images.

By the way, I randomly stumbled upon m:Research:Map of Visual Knowledge Gaps which seems to have some research on the thread topic. Haven't yet checked which method was used there to identify the articles. I've added the images included therein (on the right is one of them) to the category about the subject I created on Commons, c:Category:Images on Wikipedia. Prototyperspective (talk) 19:45, 13 February 2026 (UTC)

No infobox for "Corpus Inscriptionum..." exists and is very much needed. We have several such articles. I'll place similar notes there and direct people to discuss it here.

Anyone knowledgeable who can code? Arminden (talk) 16:46, 22 June 2025 (UTC)

"Infobox language" comes close to what's needed, but using it is an improvisation and not really suitable (will try to use it for now at Corpus Inscriptionum Iudaeae/Palaestinae). Arminden (talk) 17:05, 22 June 2025 (UTC)

Conclusion from improvising at Corpus Inscriptionum Iudaeae/Palaestinae: there are at least 3 serious problems:

• the title appears as the lowest-rung language,
• only one lang. family can be displayed, and
• the unneeded ISO line can't be removed.

Arminden (talk) 17:47, 22 June 2025 (UTC)

@Arminden Can you explain why it's needed? —Opecuted (talk) 14:33, 11 February 2026 (UTC)

Hi. Opecuted. Sorry, but did you read what I wrote? There are some 8 different articles called "Corpus Inscriptionum XY", they all need an infobox, but none exists. We are forced to use "Infobox language", but it does NOT serve the purpose well - see above only SOME of the inadequacies deriving from this improvisation. For our purposes on Wiki, a corpus is a collection of inscriptions, either in one language, or from one geopolitical region, including inscriptions in several languages, so very far from a language as such. Arminden (talk) 16:11, 11 February 2026 (UTC)

There are articles on (or redirects to, plus 1 red link to):

• Corpus Inscriptionum Latinarum
• Corpus Inscriptionum Etruscarum
• Corpus Inscriptionum Graecarum
• Corpus Inscriptionum Iudaeae/Palaestinae
• Corpus Inscriptionum Arabicarum Palaestinae
• Corpus Inscriptionum Indicarum
• Corpus Inscriptionum et Monumentorum Religionis Mithriacae
• Corpus Inscriptionum Insularum Celticarum.

Arminden (talk) 16:31, 11 February 2026 (UTC)

This sounds like you WANT an infobox. Articles never NEED an infobox. There is even a considerable “anti-infobox” section of our community, that thinks that we use infoboxes way too often and that infoboxes should be removed from lots of articles. —TheDJ (talk • contribs) 08:54, 14 February 2026 (UTC)

Moved from Talk:Corpus Inscriptionum Latinarum § No infobox for "Corpus Inscriptionum X" exists

 – moved here for better visibility —Opecuted (talk) 05:42, 14 February 2026 (UTC)

Being a series of books, {{Infobox book series}} comes to mind, though there's no parameter for the region and era of the original inscriptions (the existing "country" and "publication date" parameters don't seem appropriate). If you make a list of parameters that the infobox should support, then it wouldn't be too difficult to make one. – Scyrme (talk) 06:20, 14 February 2026 (UTC)

The question remains unanswered by the OP: why do they all need an infobox? Cinderella157 (talk) 09:01, 14 February 2026 (UTC)

@Arminden: forgot to ping —Opecuted (talk) 12:02, 14 February 2026 (UTC)

If an infobox is needed for these articles, Scyrme is on the right track: {{Infobox book series}} should fit the need. Each article is about a series (corpus) of books. – Jonesey95 (talk) 13:11, 14 February 2026 (UTC)

It's more accurate to say each article is about a series of books about a corpus of inscriptions; my understanding is they also include facsimiles of the original inscriptions. I assume they want an infobox that can handle including information about both the books themselves (title, editors, number of volumes, etc.) and the corpus of inscriptions which the books reproduce (era, region, languages). – Scyrme (talk) 16:22, 14 February 2026 (UTC)

Probably more the corpus than the book, but yes.

I find it hugely useful to cross-reference using Wikilinks etc. The inscription collections are in part available online and offer very helpful context to the historical phenomena and sites discussed in individual articles. When this is not the user's main interest that day, an overview in the shape of an infobox, sometimes with links to Google Books or the dedicated website, is just perfect. Without, it takes much longer and I myself sometimes give up and lose much of the context info. Arminden (talk) 16:37, 14 February 2026 (UTC)

@Arminden: It would be easier to fulfil your request if you provided a full list of parameters which it should have. What information should the infobox be capable of displaying?

Without a list it's difficult to make a new template or determine whether an existing template already has all the needed parameters as well as whether a new template would be warranted if one doesn't already exist (there may be other solutions besides an infobox, depending on what's needed). – Scyrme (talk) 17:22, 14 February 2026 (UTC)

Hi Scyrme, and thank you!

Now that I had to compare all the "Corpus..." pages, it slowly sunk in that yes, for my the one I'm interested in, Corpus Inscriptionum Iudaeae/Palaestinae (CIIP), it would be great to have an infobox, but for the other pages this hardly applies. CIIP is a bit odd in that it covers an unusually large number of languages from more than one language family, and it's limited in time. So I guess it doesn't qualify?

If nevertheless possible, for CIIP itself I would propose (pls compare with what's there already):

• Region
• Period
• Language family 1
  • Language 1
    • Dialect 1
    • Dialect 2
    • Dialect 3
    • ............
  • Language 2
  • ............

AND SO FORTH. Then:

• Volumes (see Index there)
  • Vol. I: ...
  • Vol. II: ...
  • ..........

With details added freely, in Italics or straight, as you see them in the "Index" section.

At the very least, can you pleade make the title disappear from the bottom of the "Language families" list (under Safaitic)? Thank you! Arminden (talk) 20:39, 14 February 2026 (UTC)

1. Is there are way for a template to read the parameters of a template nested inside it? For example, if I had {{template one| {{template two |para1=some |para2=thing}} }} is there some way to code "template one" to read the parameters from "template two"? Or can "template one" only ever read the output of "template two", not the inputs?
2. I've seen source code for some templates use #invoke where they could use an existing template. Is there a benefit to doing this, particularly for sidebars? What's the rationale for invoking a Lua module rather than just using {{sidebar}}?

I don't have a specific goal in mind with these questions, I'm just trying to understand how this works a bit better. – Scyrme (talk) 05:06, 11 February 2026 (UTC)

@Scyrme:

1. A template cannot do this. Via a module it can read the source text of the whole page and search this source text for strings like a specific template name, but we only do that in special cases like Module:Auto date formatter. It doesn't sound suitable for your purpose. It also relies on the parameter being present in the source text.

2.It reduces the post-expand include size to invoke a module directly instead of via a template. See Template:Navbox#Technical details.

PrimeHunter (talk) 05:29, 11 February 2026 (UTC)

@PrimeHunter: Thanks!

While I was searching, the closest thing I found was {{get parameter}} and {{template parameter value}}. Like you said, it looks like they invoke a Lua module to read the source of a specific article and extract the value of a parameter of a particular template on that page, as opposed to reading a value from parameter of a child template. So it seems you're right.

If anyone knows differently, let us know. – Scyrme (talk) 03:45, 14 February 2026 (UTC)

The advice given is correct. The innermost template is expanded first starting with expansion (if necessary) of its parameters. The expanded innermost template is then passed to the next outer template which is expanded. That means a template get expanded parameters and cannot determine where they came from. Except, that extremely dubious and fragile methods exist to parse the wikitext for the whole page and guess which parameter is wanted. Johnuniq (talk) 01:17, 15 February 2026 (UTC)

Why does it use <p> for spacing and <em> for italics instead of standard {{pb}} and ''? sapphaline (talk) 07:56, 13 February 2026 (UTC)

{{pb}} doesn't work across all wikis. (that's true, though irrelevant as DT didn't insert it) – SD0001 (talk) 08:39, 13 February 2026 (UTC)

What is this "p tag for spacing"? That is html for paragraph... Gryllida 09:26, 13 February 2026 (UTC)

There are no paragraphs on Wikipedia's talk pages. Well, there should be no paragraphs; DiscussionTools breaks this convention. sapphaline (talk) 09:40, 13 February 2026 (UTC)

It's fine to use paragraph elements appropriately on any page. It's unnecessary when writing paragraphs that aren't embedded within other elements, as the MediaWiki parser will parse newline-separated wikitext as separate paragraphs, but can be used when embedding paragraphs within other elements such as a list (see Wikipedia:Manual of Style/Accessibility § Multiple paragraphs within list items). The {{pb}} template is easier for most people to use, since it doesn't require a closing tag, but it also is less semantic, as it adds a visual vertical break but not a logical paragraph. isaacl (talk) 17:15, 13 February 2026 (UTC)

The <p> tag doesn't require a closing tag, either. It's implicitly closed by the next <p> tag, and by the closing tag of any block-level element that encloses it. It's also implicitly closed by the opening tag of any block-level element that you're trying to nest inside the <p>...</p> - in that respect it's unique among HTML elements. --Redrose64 🌹 (talk) 11:32, 14 February 2026 (UTC)

Yes, I am aware of this behaviour within HTML 5. I was echoing the guidance at Help:HTML in wikitext § p, since technically the wikitext parser could impose additional constraints. However, I missed the paragraph at the end of that section where it said it's not necessary on Wikipedia. isaacl (talk) 03:45, 15 February 2026 (UTC)

Various HTML elements are supported within wikitext. See Help:HTML in wikitext § Elements for more details. isaacl (talk) 17:20, 13 February 2026 (UTC)

HouseBlaster used <em> to denote emphasized content, which is exactly how it should be used. NguoiDungKhongDinhDanh 09:56, 13 February 2026 (UTC)

Are you sure the author of that commend didn't enter the <p> and <em> themselves in the wikitext? In my experience, the tool itself does multiple paragraphs by using multiple colon-indented lines, not <p> tags. As in this comment, for example.

It even does that when it results in WP:LISTGAPs when replying to a comment that already has bullet-indented comments. Anomie⚔ 13:10, 13 February 2026 (UTC)

That edit by HouseBlaster looks fine to me. I see no evidence that the reply tool caused any problems. Now if we could get the overzealous colon insertion described at T251633 fixed, that would fix an actual problem (second example, third example). – Jonesey95 (talk) 14:18, 13 February 2026 (UTC)

HouseBlaster's edit was made using the source mode of DiscussionTools (you can, kind of awkwardly, tell by using uselang=qqx to expose all the hidden tags on that revision, and seeing that it has the discussiontools-source tag), so this is indeed a case of them deliberately using HTML tags rather than wikitext. DLynch (WMF) (talk) 21:52, 13 February 2026 (UTC)

Do not ever modify someone else's comment as you did here. Those were inserted by the editors-plural, not by DT, and were used deliberately. Izno (talk) 15:55, 13 February 2026 (UTC)

@Sapphaline: About sixty HTML5 elements may be used within Wikitext. As I write this, the list is here. The element names are delimited by apostrophes; note that some are listed more than once. Sometimes, using these can produce a "cleaner" rendered page than Wikimarkup. For instance, if you have a list, it is possible for one of the items of that list to contain a sublist; but in Wikitext, such a sublist must be the last content in that list item. If you want text to appear at the level of the outer list, but after the inner list, you need to use HTML thus:

• Nested list

Original list item is still open, so my sig that follows is part of the post beginning About sixty HTML5 elements, and not divorced into a separate item. --Redrose64 🌹 (talk) 23:58, 13 February 2026 (UTC)

It seems like the magic word {{!}} is messing with the height of table cells in two templates I'm making (those being FNCS result/sandbox and FNCS LAN result/sandbox). See this example:

|}

As you can see, everything works fine except that the rows are taller than necessary – they could easily be one row tall (the first result appears fine in the visual editor but has the issue in the source editor's preview). I have no idea what caused this; has anyone seen this before? Rockfighterz M (talk) 23:57, 14 February 2026 (UTC)

@Rockfighterz M: There are two things to try. First, make sure that each <noinclude> tag follows on directly from the "real" template code, without any intervening spaces or newlines. Second, remove the blank lines. --Redrose64 🌹 (talk) 00:08, 15 February 2026 (UTC)

I did both. That solved the problem for the former template, but only mitigated it for the latter. Thank you @Redrose64 for that!

Have I missed something in the FNCS LAN result template, which leads to the problem pertaining? Rockfighterz M (talk) 00:49, 15 February 2026 (UTC)

The output of {{FNCS LAN result/sandbox}} can still have many blank lines when a switch doesn't produce anything but there is a newline after it. It doesn't work to simply remove the newline in the source text because cell-starting pipes must be at the start of a line. And it doesn't work to simply move the newline inside the switch because whitespace at the ends is stripped. I know ugly workarounds but not a pretty solution. PrimeHunter (talk) 01:40, 15 February 2026 (UTC)

I think I see what the issue was now. I rearranged some newlines to not have one after a switch and to have one before cell-starting pipes. It worked! I appreciate the help @Redrose64 and @PrimeHunter! Rockfighterz M (talk) 09:54, 15 February 2026 (UTC)

I just came across a lot of edits by a user who had changed "humourous" to "humorous" in over 50 articles that were almost all about UK/Australian/Irish/etc topics. Some (e.g. Rickrolling but not all had the "Use British English"/"Use Australian English" templates. The edits were done very quickly, one or two every minute, all with the same edit text, "Correcting typos". Examples: Before_(song), The Ballad of the Drover (in this case the "correction" was actually in the title of a cited source - automated editing of citations is really problematic), Dagoretti etc.

Is there a tool for correcting titles that this user would have used? And if so, could that tool be adjusted so it's not this easy for someone who is not aware of there being different valid spellings in different Englishes? Perhaps the tool is only using a US English dictionary and the dictionary could be expanded to not correct US or UK spellings? Or it could apply a different dictionary to articles depending on which language template they have - but a lot of pages don't have any language template. Lijil (talk) 12:06, 15 February 2026 (UTC)

(edit conflict) Lijil, User:Ohconfucius/EngvarB? — Qwerfjkltalk 12:12, 15 February 2026 (UTC)

Lijil Um, "humorous" is the correct spelling in both US and UK English. Even though the noun is spelled "humour" in UK/Commonwealth, the adjective never has the extra "u". That's the randomness of English spelling for you. You might want to revert yourself where you've changed it. Black Kite (talk) 12:17, 15 February 2026 (UTC)

Indeed. The Oxford Dictionary says: "Note that although humor is the American spelling of humour, humorous is not an American form. This word is spelled the same way in both British and American English, and the spelling humourous is regarded as an error." Your complaint about the title of a cited source is . The article gives the reference which doesn't show the part with humourous/humorous. I found both spellings in other sources about the work so I looked for an image of the original and found which says humorous. That means the editor corrected the spelling (although they may not have checked the source) and you incorrectly reverted it in with a false edit summary. Please revert all your edits unless they actually quote a source which says humourous, and consult a dictionary before making mass changes of spellings in the future. And no matter how much you think your own spelling is correct, never make up a claim about what a source says. PrimeHunter (talk) 13:08, 15 February 2026 (UTC)

Yes, "humourous" is an oddity (compare "humourless", which does have the "u" in UKENG) so it actually wouldn't surprise me that the incorrect spelling appears in sources, even though that's not the case here. Black Kite (talk) 13:22, 15 February 2026 (UTC)

Oh no. What a humorless and deeply embarrassing thing of me to gripe about - I am so sorry! And hopefully I'll never make this particular mistake again. Luckily @MtBotany fixed my incorrect reversions, and I've apologised to the user who was actually very helpfully fixing spelling errors. Sorry everyone. Lijil (talk) 21:20, 15 February 2026 (UTC)

Occasionally editors will start a discussion on one of the village pump subpages and create a subheader with a title like "Discussion" or "Survey", which inevitably creates navigation problems when there end up being multiple identical subheaders on the page under different discussions. It should just not be technically possible to create a generic subheader on these pages. If someone tries to create one, they should be prevented from saving until they change it a unique subject-specifics subheader (like "Discussion (section headers)"). BD2412 T 19:00, 11 February 2026 (UTC)

Yes please. Also on WP:ANI (and I suppose WP:AN). —Cryptic 01:17, 12 February 2026 (UTC)

I completely agree with those. I can imagine there are other messageboards where this would make sense. BD2412 T 01:19, 12 February 2026 (UTC)

Also agree. The section headers should be descriptive. This also relates to wish W311: Do not fully archive unsolved issues on Talk pages albeit another idea would be needed for what to do at meta pages like VP that get lots of thread than what's suggested in the image there and the bigger problem with that is that here threads aren't marked as 'solved' or at least 'issues' or 'nonissues' (eg Tech News posts aren't issues). I think the solution would be to add a sentence about this to the header asking for descriptive headers and having users edit headers when they're not descriptive. I edited a few section headers at d:Wikidata:Bot requests that weren't descriptive. Prototyperspective (talk) 11:33, 12 February 2026 (UTC)

Personally, I would prefer having a permalink icon next to the heading that provides easy access to a unique link to the heading, so users won't have to generate unique headings on their own. The unique(-ish) ID is already generated by the infrastructure underlying the reply tools feature; there just needs to be a user interface to expose it. (I have my own script to copy comment and heading links to the clipboard; other users have written similar scripts.) isaacl (talk) 02:00, 12 February 2026 (UTC)

This prompted to create a user script... sapphaline (talk) 22:09, 15 February 2026 (UTC)

Ideally section-based editing would be revised to support these IDs as well. However I don't know the practical feasibility of implementing this change. isaacl (talk) 02:02, 12 February 2026 (UTC)

@BD2412, please post this request to Wikipedia:Edit filter/Requested. --Ahecht (TALK
PAGE) 14:52, 12 February 2026 (UTC)

"User:Preime TH" has already placed a second "Infobox settlement" under the original "Infobox settlement" in wiki articles "Provinces in Thailand" with information about the provincial administrative organization (PAO), without realizing that an image that was in the text to the left of the first "Infobox settlement" has been shifted down to the top of the second "Infobox settlement".
This image now appears in a completely different article section.
To solve this problem with as few adjustments as possible:
Create a sub-template called "Infobox settlement/PAO", whose text is 100% identical to "Infobox settlement", but without the software component that prevents placement of an image above "Infobox settlement/PAO". SietsL (talk) 06:54, 16 February 2026 (UTC)

Toggling wikitext editor syntax highlighter in the 2010 editor (top) and 2017 editor (bottom).

I enabled this feature some time ago and now can't find the checkbox to disable it. sapphaline (talk) 09:25, 16 February 2026 (UTC)

Seems like there's no option in user settings to disable the "usecodemirror" preference. Great. How can I disable it through the API? sapphaline (talk) 09:46, 16 February 2026 (UTC)

Apparently it's only available with "Improved Syntax Highlighting" feature turned on. sapphaline (talk) 09:52, 16 February 2026 (UTC)

I assume you are using the 2017 Source Editor. If that's the case, click the Hamburger menu in the Edit page and uncheck "Syntax Highlighting". vitalkanev /discuss/ 09:52, 16 February 2026 (UTC)

@Sapphaline: There are different syntax highlighters. See WP:HILITE. PrimeHunter (talk) 10:53, 16 February 2026 (UTC)

Using the default (CodeMirror) syntax highlighter, you can turn it on/off with the pencil icon in the editor toolbar (2010 wikitext editor) or the hamburger menu (2017 wikitext editor). The documentation about it being a beta feature at WP:HILITE was incorrect and I've changed it: that only applies to testing a more advanced version of CodeMirror. the wub "?!" 11:27, 16 February 2026 (UTC)

Hello there :) Apologies if this has been discussed everywhere or is otherwise known, but I noticed an ugly visual bug resulting from the combination of a {{side box}} and (a table with) the floatright class. You can see the effect at Ejective consonant, opening the mobile version from a narrow enough screen (or emulator - the "iPhone SE" preset in chrome devtools is perfect). I tried fiddling with it for a bit but didn't find a convincing solution, or one in which I'm sufficiently confident (e.g., would it make sense to add a content-based width to {{side box}}?). I'm also not familiar with the available layout templates and classes here on enwiki, so y'all may already have a simple solution that I'm not aware of. Daimona Eaytoy (Talk) 22:04, 10 February 2026 (UTC)

This should be changed in the floatright class definition. Memory says this class (and its friends) used to be wrapped in a media query on mobile such that it only took effect above a certain width. I have been meaning to make that how it works globally and just have been ~lazy~. cc @Jdlrobson Izno (talk) 00:51, 11 February 2026 (UTC)

Those rules exist but they only work on responsive skins (not resized skins). They work fine on mobile devices and people using desktop site on mobile.

Generally people shout at you when you give any kind of impression you are making their favorite pre-2011 skin "responsive" or mobile like which is why we unfortunately intentionally dont have a response version of the Vector 2022 (or Vector classic) skin whicha makes me sad.

https://gerrit.wikimedia.org/g/mediawiki/core/+/257e5d8c0a298d31870727cba144dc6c46ecec5f/resources/src/mediawiki.skinning/content.thumbnails-common.less 🐸 Jdlrobson (talk) 02:21, 11 February 2026 (UTC)

@Jdlrobson Ok, 1) I'm not crazy, and 2) the styles there aren't applying in Minerva right now? https://en.wikipedia.org/wiki/Ejective_consonant?useformat=mobile only has the clear-right-float-right rule, not the clear-both-float-none rule, at the appropriate width. Izno (talk) 02:42, 11 February 2026 (UTC)

Because Minerva isn't using that version, it has its own. Izno (talk) 02:45, 11 February 2026 (UTC)

Phab:T368469 🐸 Jdlrobson (talk) 02:56, 11 February 2026 (UTC)

Thanks for the context :) I agree that the floatright class is ultimately responsible, although I guess I was also wondering if there's a simpler fix to apply to either of the involved templates while we wait for the proper fix. --Daimona Eaytoy (Talk) 12:01, 11 February 2026 (UTC)

"we unfortunately intentionally dont have a response version of the Vector 2022" - are you sure about that? sapphaline (talk) 12:05, 11 February 2026 (UTC)

intentionally is doing the heavy lifting there. That a parameter works with the skin doesn't imply that was intended (i.e. designed-for). Izno (talk) 17:39, 14 February 2026 (UTC)

If you view Vector 2022 on a mobile device it will always appear zoomed out due to the presence of the meta viewport tag. It will adapt to resizing the browser though. The only way to get mobile Vector 2022 on a mobile device is via [https://en.wikipedia.org/wiki/Main_Page?useformat=mobile&useskin=vector-2022 a specific url].

There has been an intentional decision here (which was pushed for by the community during rollout) for it to behave this way

Hope that clarifies. 🐸 Jdlrobson (talk) 17:54, 16 February 2026 (UTC)

It is the section starting with "include obviously. It is absurd to say that we should say "he had never been arrested before" in . See the discussion there about this. Thanks. Doug Weller talk 18:40, 10 February 2026 (UTC)

You are using one of the scripts that check links for reliability (Headbomb's I believe). It highlights the entire list item in which the unreliable link appears. I skimmed it so I can't say which specific link. Izno (talk) 19:28, 10 February 2026 (UTC)

Thanks. . Doug Weller talk 19:54, 10 February 2026 (UTC)

It would be great if somebody could change that script so it doesn't highlight replies on discussion pages or anything on discussion pages that aren't article talk pages. I'm having the same problem of random replies being marked in red and lots of users have that script installed. Prototyperspective (talk) 11:41, 12 February 2026 (UTC)

User:Headbomb can you help? Thanks. Doug Weller talk 19:15, 12 February 2026 (UTC)

Should be fixed. Headbomb {t · c · p · b} 19:23, 12 February 2026 (UTC)

Thanks for looking into it. This whole thread is still red and I think it's due to your script; could you check? Prototyperspective (talk) 19:42, 12 February 2026 (UTC)

This too. Prototyperspective (talk) 18:00, 16 February 2026 (UTC)

I'm trying to get started using modules, but I'm having difficulty getting a "Hello World"-type setup working. I asked ChatGPT to suggest a basic setup to help me learn, but even with its help I can't get it working. I have the following:
Module:Sandbox/Greenbreen/Toy
User:Greenbreen/Sandbox/Template:Toy
User:Greenbreen/Sandbox/Toy test
I expect that last page to show "10" under "Normal", but I get a red error:
'Script error: No such module "Sandbox/Greenbreen/Toy".'
What am I doing wrong? —Greenbreen (talk) 22:07, 15 February 2026 (UTC)

Your module page has the wrong content type: it's "wikitext" rather than "Scribunto module". I've fixed that for you. Anomie⚔ 22:23, 15 February 2026 (UTC)

@Greenbreen: It got the wrong type because you created it in another namespace and moved it. PrimeHunter (talk) 23:02, 15 February 2026 (UTC)

@PrimeHunter@Anomie I noticed that the actual change from "wikitext" to "Scribunto module" showed 0 bytes of difference, so I tried undoing Anomie's edit to see what changed, but ran into a permission error. I guess it doesn't matter as long as I create the module within the Module namespace to start with. Thanks for both of your help! Greenbreen (talk) 16:55, 16 February 2026 (UTC)

@Greenbreen: Yes, just create it as a module another time. The content model change is a log action seen here. Some log actions are also displayed in the page history for convenience. The developers didn't make a new type of edit for this but just used the existing format. The edit summary is made by concatenating the English version of the automatic log description and the user-supplied log summary, and the diff is empty. The actual change is in metadata for the page. The current content model is shown in "Page information". Administrators have a "(change)" link next to "Scribunto module". PrimeHunter (talk) 18:10, 16 February 2026 (UTC)

Hi all.

I was searching for a software that I can use to verify newly added content in drafts against sources linked, and thought about asking here. Do you possibly have any such resources? Opening 4 new sources in my web browser is time consuming. I forget which part was verified and which was not at a certain wiki page...

- Gryllida 18:56, 16 February 2026 (UTC)

MediaWiki message delivery 19:15, 16 February 2026 (UTC)

I'm using Samsung Tab 9A+, Android tablet, with Samsung browser. When I access any Wikipedia article, it displays in a small font, but as I read and scroll article, the font size jumps to a larger font. I have researched this crazy-annoying problem and I have tried locking down font-size in the browser, disabling browser zoom, using desktop form pages as per browser setting, and setting the Wikipedia "Appearance" font-size values to both small and standard.

This annoying browser behaviour is ONLY evident on Wikipedia pages - and queries to Google AI explain that Samsung/Android browser is probably "boosting" font size and Wikipedia is also dynamically adjusting font-size. I cannot disable the Samsung browser action (no option exists for this - went thru ALL options on browser, which is a variant of Chrome), and problem only evident on Wikipedia.

Google's AI says try "desktop view", which I now use exclusively. But Wikipedia still shows small-font initially, then, as I scroll to read page, font size jumps to large, and one loses reading position in the page.

Basically, I have tried almost all possible combo's of browser settings, and setting values for "Appearance" in Wikipedia - small font, standard or large - does not stop this annoying behaviour.

What I request, is that Wikipedia provide a simple option to **DISABLE** dynamic adjustment of font-size. Simple, easy fix, which would allow me read articles without having the font-size jump as I am reading. I looked thru tech info, no solution was located.

More info; Note, I can get this SAME annoying behaviour on one of my Linux desktop machines, running a Firefox browser. Setting the Wikipedia font to "small" after article loads, as I scroll, it will jump to "standard" and even "large", which is seriously annoying. It's like having some lunatic snatch your newspaper out of your hand while you're reading it! (And then handing it back to you with a magnifying glass...) And saying, "There you go!" Crazy annoying.

So, the problem is *not* with my browsers, or with my Android or Linux versions. Some unwise person has damaged the Wikipedia user-interface.

Fix this problem by just providing a display option to prevent Wikipedia from adjusting font-size under any circumstance, after page loads and displays. - Russel F. Rusfuture (talk) 18:51, 16 February 2026 (UTC)

@Rusfuture what if it is just your phone ? —TheDJ (talk • contribs) 22:19, 16 February 2026 (UTC)

@Rusfuture: Have you tried other skins at Special:Preferences#mw-prefsection-rendering? The skin selection only affects desktop view. PrimeHunter (talk) 11:55, 17 February 2026 (UTC)

I was reading the Swingin' (John Anderson song) article on my iPhone (Vector 2022 skin) and the “Other versions” section header is shown one character per line. Any ideas for troubleshooting this? It does not appear this way when I look at the article using my laptop. Thanks, 28bytes (talk) 13:29, 14 February 2026 (UTC)

I have seen this issue before but honestly I can't reproduce it now. It's flex gone wrong but there's nothing that should be causing it particular trouble in this context. Izno (talk) 17:35, 14 February 2026 (UTC)

It affected Pppery (talk · contribs) in August 2024, see User talk:Pppery/Archive 25#Something amiss with User:Pppery/topicons. --Redrose64 🌹 (talk) 18:15, 14 February 2026 (UTC)

It's been showing up like this on cellphones since a rather recent Wiki outlook change. What the new outlook screwed up even worse is the way edits are shown on "edit history": I don't understand anything anymore, "edit history" has becone totally USELESS to me.

Back to this issue: I figured out that by flipping the phone from "portrait" to "landscape" (sorry, I'm a photographer), it fixes the problem A BIT.

Why don't coders stick to the "if it ain't broken, don't fix it" principle? Pleeeease do! Or test phone mode before releasing, at the VERY least! And remember: heaps of conyributors are way past their spectacles-less years, along with all that implies. Arminden (talk) 20:11, 14 February 2026 (UTC)

This kind of issue is about as likely to be related to choices made by software engineers at the WMF as it is to be a failure of the Apple engineers. These days, the latter is more likely worth suspicion. Izno (talk) 21:35, 14 February 2026 (UTC)

I’m confused.. how do you have desktop on a mobile with width being constrained to device width ? —TheDJ (talk • contribs) 11:20, 15 February 2026 (UTC)

I’m using Vector 2022 and I have “Enable responsive mode” and “Enable limited width mode” both checked in the Preferences > Appearances > Skin preferences section, if that helps. 28bytes (talk) 12:11, 15 February 2026 (UTC)

The enable responsive mode doesn't apply to Vector 2022.. so I am also a little confused about how you are getting this view on a mobile phone!! Is there a gadget that does this? 🐸 Jdlrobson (talk) 02:53, 16 February 2026 (UTC)

I don’t think I’ve got any unusual gadgets enabled, but I rechecked that page logged out and the glitch does not appear, so it’s certainly possible it’s something in my configuration/preferences. It still looks broken when I’m logged in. (And as best as I can recall that’s the only page I’ve seen this issue occur on.) 28bytes (talk) 03:08, 16 February 2026 (UTC)

I'm using a Samsung A55, so it's not an Apple thing. And I bumped i to it on lots of pages, much more often on Romanian Wiki than on enWiki, don't know why.

Related to it: my phone offers me 3 different browsers. The default browser for Google searches (can't figure out which one it is) presents Wiki pages in PC mode, so that fonts are minuscule on the phone screen, but it has the "Listen to this page" function unlike another browser, so I'm still using it. Google Chrome has its own pros and cons, as does the third browser. Why I mention it here: the PC mode with its minuscule fonts, which I can't reset, showed up a few months ago, at about the same time as the problem flagged here, and it also introduced a tortuous editing mode (copy paste hardly possible etc.), all these almost simultaneous changes (not of my doing) making both using and editing Wiki A LOT harder. I guess coders tried to "fix" a system that wasn't broken. Even if it's me not being able to reset to the previous state: Wiki is for normal ppl, not all tech wizards, but with good experise in their field; forcing unhelpful changes on us is idiotic, as in: the opposite of user-friendly. This is not a sandbox for experiments. Arminden (talk) 11:35, 16 February 2026 (UTC)

with its minuscule fonts, which I can't reset, showed up a few months ago

this is a change in the Chrome browser. Apparently too few people were using the auto sizing of the fonts for the Chrome team (and thus most other browsers) to keep supporting that mode and it had a few significant problems, so they chose to remove it. You thus get the font sizing that you would expect of desktop site.

It also introduced a tortuous editing mode (copy paste hardly possible etc.)

This sounds like you enabled the syntax highlighting. You can simply disable syntax highlighting via the toolbar. For me it works most of the time, but I do also see a problem there every once in a while. None of that seems related to the problem mentioned here. —TheDJ (talk • contribs) 12:42, 16 February 2026 (UTC)

Does this issue have a Phab task? I just encountered it here, not on mobile. Seems related to or same as #Side box + floatright combination squishes text on mobile above. Nardog (talk) 14:58, 17 February 2026 (UTC)

Your "here" I've now fixed. It's a similar issue but not related at all in how it's corrected. Izno (talk) 17:48, 17 February 2026 (UTC)

I'm trying to figure out why a recent post on my user talk page is causing some of the content before it to not render. –LaundryPizza03 (dc̄) 05:44, 18 February 2026 (UTC)

Changing the reference tags to a bulleted list fixed this issue, but again I don't know why. –LaundryPizza03 (dc̄) 05:53, 18 February 2026 (UTC)

I fixed this by nowiki'ing a stray ref tag at the point where the page rendering stopped. –LaundryPizza03 (dc̄) 05:57, 18 February 2026 (UTC)

@LaundryPizza03: Yes, problems like this are almost always due to an unclosed <ref> tag further up the page. The new post contains a properly-balanced <ref>...</ref> pair, but the MediaWiki parser pairs the </ref> tag of that pair with the first unclosed <ref> that it can locate in the page, and not the one preceding the </ref>. --Redrose64 🌹 (talk) 17:01, 18 February 2026 (UTC)

Savannah River Plant has a chart in it:

{{#chart:Production Plutonium Hanford SRS (1947-1989).chart|data=Production Plutonium Hanford-SRS-1947-1989 (Corrected).tab}}

For some reason, this causes the Page Size tool to hang. Any ideas? Hawkeye7 (discuss) 03:45, 16 February 2026 (UTC)

It loads fine for me when I tested with page sizes standard and wide, alongside text sizes too (on Vector 2022 theme). What 'tool' are we talking about here? --- n✓h✓8 (he/him) 04:50, 16 February 2026 (UTC)

The Page Size tool on the Tools menu. Enabled by the Wikipedia:Prosesize gadget. Hawkeye7 (discuss) 05:02, 16 February 2026 (UTC)

The page size tool works fine for me on Vector 2022, with no errors in console that (I believe) come from prose size.  staglol   ctbs
talk 05:30, 16 February 2026 (UTC)

No, I created a test page with nothing but the line above. It runs fine with that line commented out. Hawkeye7 (discuss) 00:27, 17 February 2026 (UTC)

There's JS error Uncaught TypeError: id.childNodes[i].className.indexOf is not a function. It points to MediaWiki:Gadget-Prosesize.js#L-76. You can probably report that at Wikipedia talk:Prosesize.

There's another page size tool and it handles the page well: https://prosesize.toolforge.org/?title=Savannah+River+Plant&domain=en.wikipedia.org. – Ammarpad (talk) 10:04, 18 February 2026 (UTC)

 Done Thanks for that! Hawkeye7 (discuss) 18:53, 18 February 2026 (UTC)

In the past couple of weeks Special:WantedCategories has seen more than one recurrence of a redlinked Category:Temporary Wikipedian userpages that was deleted in 2016. Both times, it was populated entirely by the user talk pages of editors who were blocked for vandalism in 2008, the first time exclusively editors whose usernames began with W, and today exclusively editors whose usernames began with V — and the culprit appears to be that said talk pages have recently been undeleted on WP:DELTALK grounds, after having been previously deleted, and were thus put back into a category that existed at the time of the original deletion but has not existed for a decade.

So is there another way that this can be resolved without forcing me to gnome it out in an WP:AWB run every time it comes back again? Bearcat (talk) 17:28, 10 February 2026 (UTC)

The category is currently empty. Please always include an example. I found one in your contributions: . There is no way to prevent the categorization before you removed it. The page was undeleted by Hex. Her logs show she undeleted many such pages beginning with V on 7 February and with W on 29 January. If she is planning to undelete more pages then you could ask if she will remove the category afterwards but now I have also pinged her. PrimeHunter (talk) 18:03, 10 February 2026 (UTC)

Hiya - yes, I'm repairing a mass deletion of user talk pages by a former admin back in 2008 before we decided not to do that. It's slow and tiresome because I check each of them to ensure there's nothing requiring RevDel before hitting the button, so I was planning to ask someone to get a bot to clear off the category afterwards. I guess you'd like me to arrange that now? Given that I've done about 600 out of 11,000, this is going to take a while. By the way Bearcat, since you evidently checked the logs, you could have written to me first before posting here. It's also kind of odd that you didn't mention me and so PrimeHunter had to send a ping.  — Hex • talk 19:58, 10 February 2026 (UTC)

@Hex: Now that the topic is raised, I do have to wonder what purpose is served by undeleting these talk pages. Was there a discussion somewhere that concluded these 11000 pages would be useful to mass-restore 18 years later? Anomie⚔ 23:59, 10 February 2026 (UTC)

I have the same question. I looked at just one example, which had five Linter errors and one nonexistent category. I expect to see deleted templates as well. Restoring these pages will make work for a lot of gnomes; what is the benefit, and where was the discussion about this restoration? – Jonesey95 (talk) 00:32, 11 February 2026 (UTC)

No discussion was required. We established consensus a long, long time ago that user talk pages shouldn't be deleted except in rare circumstances because they form an important part of the historical record. When that happened, someone should have done this job, but nobody did. I'm rectifying that error. The effort of dealing with a small number of linter issues will be outweighed thousands of times over by the benefits of not having a massive chunk of user interactions and block log context missing for no good reason.  — Hex • talk 01:43, 11 February 2026 (UTC)

And what advantages are those, exactly? Since no one has cared in 18 years, it seems unlikely they're that significant. Anomie⚔ 12:57, 11 February 2026 (UTC)

thousands of times over? Actual human and bot editors are going to have to make thousands of edits to remove errors from these restored pages. That is a guaranteed downside if this crusade project goes forward. Hex: Please enumerate concrete instances that balance the downside of those thousands of edits with benefits. I won't ask you to justify the obviously unjustifiable orders of magnitude that you claim. Just a simple positive or break-even counterbalance would be fine. – Jonesey95 (talk) 15:09, 11 February 2026 (UTC)

A quick and dirty sql says that among the undeleted pages with linter issues, most have issues with obsolete tags, no background inline (which a number of wikipedians regard having a lot of false positives) and no end tags. Most of this can be automatically fixed. Everything else is less than 20 pages with issues.

Do users need to have a set number of edits to have userpages, and if so, why? Snævar (talk) 17:01, 11 February 2026 (UTC)

When you ran your SQL query, did you run it on the originally restored pages to account for the Linter errors that have already been fixed and the categories that needed to be removed? – Jonesey95 (talk) 17:37, 11 February 2026 (UTC)

@Snævar: There is no restriction. Some editors create their user page as the very first edit; indeed, for some, it is the only edit that they ever make. It's often harmless, provided it's not against WP:UPNOT and isn't speedyable under the G and U criteria. But this thread appears to be about user talk pages, these being the ones that Hex has been undeleting. Very few users create their own user talk pages, although some do. It's also not usually a Wikicrime. --Redrose64 🌹 (talk) 23:29, 11 February 2026 (UTC)

@Anomie - who can say, really? People are interested in anything and everything. Even the most seemingly mundane detail in an archive may be exactly what some future historian is looking for as part of a research project. You could really say that about almost all of our archives, which we generate at a ferocious rate - page revision histories, system logs, talk archives. 18 years is also not very long at all. The discussion we're having right now will get archived, and then nobody might care about it at all for 25, 50, 100 years. But there may be a single historian in 2126 who it's useful to and is reading it right now. (Hello! Do you live in space? I'm sorry for what we did to the planet.) It's that possibility that we keep archives for.  — Hex • talk 20:30, 11 February 2026 (UTC)

That's a whole lot of maybes and hypotheticals. Anomie⚔ 00:17, 12 February 2026 (UTC)

That's life.  — Hex • talk 00:22, 12 February 2026 (UTC)

So a moment ago it was the unsupportable The effort of dealing with a small number of linter issues will be outweighed thousands of times over by the benefits of not having a massive chunk of user interactions and block log context missing for no good reason, and now it's that's life? I hope that Hex will consider cleaning up the pages that they undelete (link to an example of a Linter error that is of a type that was completely eliminated years ago). Editors are responsible for their edits. This is like watching someone walk through my neighborhood throwing trash on the ground. – Jonesey95 (talk) 14:25, 13 February 2026 (UTC)

If anything, Jonesey95's crusade against linter errors is way more harmful than Hex's undeletions, because they seem to have no issues with loudly complaining and upsetting people over it. The message above ("This is like watching someone walk through my neighborhood throwing trash on the ground") is a perfect example of this. sapphaline (talk) 14:59, 13 February 2026 (UTC)

Re redlinked categories, I've told JJMC89 bot III (the bot that normally processes WP:Categories for discussion outcomes) to empty Category:Temporary Wikipedian userpages, so that problem shouldn't happen anymore. And I'll add (to counter Jonesey95's comment that no one has cared in 18 years), that I approve of what Hex is doing, and have expressed dissatisfaction with this trend since at least 2019 (for example Wikipedia:Requests_for_undeletion/Archive_344#c-Pppery-2019-11-07T21:55:00.000Z-User_talk_pages:_A). Admittedly that scattergun REFUND request wasn't my finest hour and I'm inclined to agree now with some of the comments criticizing that request, but the claim that nobody has cared isn't true and if Hex wants to spent their time doing this then I would say more power to them. * Pppery * _{it has begun...} 18:26, 11 February 2026 (UTC)

Oh, thanks for the bot-herding, and your comments!  — Hex • talk 21:02, 11 February 2026 (UTC)

@Pppery: That was me, not Jonesey95. I guess good for you that you cared at one point in 2019? But not enough to have started a discussion beyond the REFUND you now admit wasn't a good one. Anomie⚔ 00:23, 12 February 2026 (UTC)

• @Jonesey95: Mentioning me in every single edit summary you make so that I come back to find I have 75 notifications is unbelievably petty and childish. Grow up.  — Hex • talk 15:15, 13 February 2026 (UTC)

  It was a boilerplate edit summary. What is unbelievable is how much work you are making for your fellow editors. Please clean up the pages that you are restoring. Editors are responsible for their edits. See below for something more constructive. – Jonesey95 (talk) 15:23, 13 February 2026 (UTC)

  Two different boilerplate edit summaries which you wrote yourself to specifically mention and talk to me, which you've now stopped doing after getting called out on it. Sure dude.  — Hex • talk 16:01, 13 February 2026 (UTC)

You asked me to stop, so I stopped. That's the polite thing to do. See below for an example of an editor who did not stop causing problems when asked to do so. – Jonesey95 (talk) 16:43, 13 February 2026 (UTC)

MariaDB [enwiki_p]> SELECT
    ->     LEFT(log_timestamp, 8) as restore_date,
    ->     SUM(CASE WHEN actor_name = "Hex" THEN 1 ELSE 0 END) as restorations_by_hex,
    ->     COUNT(*) as total_restorations,
    ->     ROUND(100.0 * SUM(CASE WHEN actor_name = "Hex" THEN 1 ELSE 0 END) / COUNT(*), 2) as pct_by_hex
    -> FROM logging
    -> JOIN actor ON log_actor = actor_id
    -> WHERE log_type = "delete"
    ->     AND log_action = "restore"
    ->     AND log_timestamp >= "20260125000000"
    ->     AND log_timestamp < "20260301000000"
    -> GROUP BY LEFT(log_timestamp, 8)
    -> ORDER BY restore_date DESC;
+--------------+---------------------+--------------------+------------+
| restore_date | restorations_by_hex | total_restorations | pct_by_hex |
+--------------+---------------------+--------------------+------------+
| 20260213     |                 500 |                576 |      86.81 |
| 20260212     |                   0 |                 47 |       0.00 |
| 20260211     |                   0 |                 50 |       0.00 |
| 20260210     |                   0 |                 27 |       0.00 |
| 20260209     |                   0 |                 31 |       0.00 |
| 20260208     |                   0 |                 29 |       0.00 |
| 20260207     |                 105 |                154 |      68.18 |
| 20260206     |                   1 |                 34 |       2.94 |
| 20260205     |                   0 |                 23 |       0.00 |
| 20260204     |                   0 |                 36 |       0.00 |
| 20260203     |                   0 |                125 |       0.00 |
| 20260202     |                   0 |                 48 |       0.00 |
| 20260201     |                   0 |                 24 |       0.00 |
| 20260131     |                   0 |                 64 |       0.00 |
| 20260130     |                   0 |                 44 |       0.00 |
| 20260129     |                 259 |                287 |      90.24 |
| 20260128     |                   0 |                 41 |       0.00 |
| 20260127     |                   2 |                 63 |       3.17 |
| 20260126     |                   0 |                 66 |       0.00 |
| 20260125     |                   0 |                 40 |       0.00 |
+--------------+---------------------+--------------------+------------+
20 rows in set (0.134 sec)

By my recollection, I use to use a template {{Unsign}}, which is now redirecting to {{unsigned}}, which does not seem to be properly parsing its arguments. The redirect indicates it has been redirected for 20 years, so I don't actually know what has changed. I tried to use it at Wikipedia_talk:Vital_articles/Level/5/History_and_geography#Reducing_U.S._Cities and could not get it to generate both a user name and a time stamp.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 00:23, 19 February 2026 (UTC)

First of all, for this specific case, the comment I have split this because ... was added at 23:56. Template:Unsigned was used at 00:18. For such a close proximity in time (especially without any other editors between these edits) just signing the message with the regular four tildes ~~~~ is OK.

Secondly, did you try to use this template in a way beside providing the username and the timestamp as the first and second parameters (adapted from Template:Unsigned/doc): {{subst:Unsign|username|time, day month year (UTC)}}? As far as I can tell, using {{subst:unsign}} shouldn't be any different from using {{subst:unsigned}}. The template can even take these arguments in swapped order (timestamp first, username second) which gets detected automagically.

My only educated guess at what could have go wrong is that the timestamp somehow ended up with a stray equals sign. Just as an example: {{subst:unsign|...|2=time=stamp}} would "work", but {{subst:unsign|...|time=stamp}} would be parsed as a parameter called time with the value stamp, and the template would "assume" that the timestamp wasn't passed. —⁠andrybak (talk) 02:15, 19 February 2026 (UTC)

What, exactly, wikitext did you enter that did not work? Anomie⚔ 02:29, 19 February 2026 (UTC)

If the 22 minutes did not cross the UTC dateline, I would have signed regularly, but at VA a lot of decisions are made counting days before specific actions are allowable.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 02:40, 19 February 2026 (UTC)

I tried {{subst:Unsign|username|time, day month year (UTC)}}, {{subst:Unsign|time, day month year (UTC)|username}} as well as what I have usually done, which as I recall is either {{Unsign|username|time, day month year (UTC)}} or {{Unsign|time, day month year (UTC)|username}} so I tried both. No second parameter would present in any of these attempts.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 02:40, 19 February 2026 (UTC)

It is possible that I just put the time without the day month and year. Maybe it was me.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 02:42, 19 February 2026 (UTC)

The time stamp format is checked and invalid formats are ignored. Please post an actual example and not pseudocode like {{subst:Unsign|time, day month year (UTC)|username}} when you report issues. PrimeHunter (talk) 08:25, 19 February 2026 (UTC)

A discussion has been started about what help page on using AI on Wikipedia to draft first. See Wikipedia talk:Help Project#Planning help for AI workflows.    — The Transhumanist   13:38, 19 February 2026 (UTC)

Now that T416147 has been partially fixed (partially because pending the maintenance script the fix is not retroactive), if you add a label to a page, you will see that the item count shown in Special:WatchlistLabels will go up by two. This is because you are labelling two pages, the subject page and its talk page. Now, there is nothing inherently wrong with this convention but it is inconsistent with Special:Watchlist, where talk pages are not counted. So, what do you think, is this a bug or is it working as intended? Warudo (talk) 21:28, 19 February 2026 (UTC)

Do we have any real data (i.e. actually recorded and logged from live page views) on the distribution of line lengths used by our readers? I know it's possible to record window sizes in pixels, but that's not what I'm looking for. I'm looking for line lengths in characters. Yes, I know it will vary with a zillion things including the actual text being displayed. I'm not even sure if browsers make that available in any way. But, assuming all the planets align properly, is it possible we have this data? RoySmith (talk) 14:54, 18 February 2026 (UTC)

For 70% of our readers it's about 60 characters per line or less. That's with the smallest available font size and on a quite big phone screen. Ponor (talk) 15:03, 18 February 2026 (UTC)

Where is that data? RoySmith (talk) 15:12, 18 February 2026 (UTC)

I'm just playing devil's advocate here — people often forget that about two-thirds of our readers use mobile devices. You can add to it mostly casual readers who use the default line length in Vector 2022, which I believe comes to about 160. My (somewhat educated) guess is that that's what the data would show. Maybe @SGrabarczuk (WMF) or someone they know can tell us more. Ponor (talk) 15:24, 18 February 2026 (UTC)

I appreciate the effort but what I'm looking for is real data. RoySmith (talk) 15:31, 18 February 2026 (UTC)

Thanks for the ping! Roy, first I wanted to share this: Readability research report. Secondly, out of curiosity, what prompted you to ask this question? Would you like to work on something related? SGrabarczuk (WMF) (talk) 16:05, 18 February 2026 (UTC)

Thanks for that link. It'll take me a while to read that in detail, but I will do so when I have a chance. What prompted me was this thread. If the whitespace padding issue is something that will show up for 10% of our users (even 10% of our non-mobile users), then it's obviously of greater concern than if it happens to 1%, or 0.1%, or 0.01%, etc.

Do you know if there's a way to preview what a page looks like on different platforms? I know that in Chrome on my Mac desktop I can emulate various phones and tablets, but I haven't found a way to emulate a PC. I don't know why layout should differ so much between Macs and PC, but it does appear to be the case. RoySmith (talk) 16:19, 18 February 2026 (UTC)

There are paid ways to view pages on different platforms. Because doing it for real needs real hardware, I don't think there are any free ways. For desktop/laptops, typically the underlying browser engine is the key difference, rather than operating system. (Things can be weirder on mobile devices because of device screen constraints and possibly supplier customizations to the software. The default availability of fonts can vary of course on different operating systems, which will cause some differences but unless users configure their browsers with a radically different font than usual for a given style, the effect shouldn't be that big.)

Specifically regarding the issue in the feature article candidate discussion: ultimately, the automatic layout algorithms used by web browsers in order to support arbitrary browser window widths, font sizes, and user or browser-specific customizations means that there are some unavoidable tradeoffs in web design. If content is being floated to one side, then control is lost regarding exactly what surrounding content will be next to it. In the context of trying to keep an image entirely within a specific section, if the floating behaviour is cleared to force this, then the only approach to mitigate the risk of there being extra whitespace is to decrease the ratio of the size taken up by the floated content versus the surrounding content. If it's not possible to design the content to set the ratio to an appropriately small size (for instance, if an image is being floated and it needs a certain minimum size to be legible), the only way to have no risk of extra whitespace is to accept that floated content may extend to the following section. isaacl (talk) 18:08, 18 February 2026 (UTC)

Re: tools - No, not as far as I know. There used to be a variety of free web-tools that helped with this (Browsershots, BrowserStack, Browserling, CrossBrowserTesting, etc), that would generate dozens of screenshots, usually with a few hours queue/delay because they were very popular; but sadly they've all gone paid-access-only in the last few years.

Re: article layout expectations, generally - I believe that because the vast majority of logged-out users get the default settings (vector-2022 in standard width and standard text-size on desktop, or minerva/apps on smartphones) it is generally sufficient (and often helpful!) to test with both of those; plus ideally also test zooming-in to 150% or even 200% on desktop for the subsets of users that typically do that.

Re: this specific article/example - I think it works best with the {{clear}} and the left-float on that map, and without {{clear}} on the "Engraving of the expedition" image, for the default user-experience. It does leave a larger gap for users who either use the 'wide' width setting, or logged-in users with the 400px thumbnail preference, but as you and isaacl note it's often impossible to make a densely-packed-page look perfect in all-possible-configurations. HTH. Quiddity (talk) 00:07, 20 February 2026 (UTC)

There are so many variables that it's not quantifiable. Even for mobile users: not all mobiles are the same size, also it depends whether you hold it portrait or landscape, etc. --Redrose64 🌹 (talk) 20:03, 18 February 2026 (UTC)

Hello, I was directed here from the Teahouse. When opening a page from the Suggested Edits on my userpage, the Quick Start Tips scroll very quickly through their numbered suggestions. I generally consider myself to be a quick reader but adding 1 second more to the timer would be beneficial. Especially for other newcomers who might not know they can manually go back through the tips individually. They do, of course, come back around over time but just a small adjustment like that would be nice. Thank you for considering this! Itsaclarinet (talk) 02:51, 16 February 2026 (UTC)

Hello @Itsaclarinet, thank you for taking the time to share this feedback.

I agree that the Quick Start Tips advance too quickly. I am the Product Manager for the WMF Growth team, which develops and maintains the Suggested Edits feature, and I appreciate you calling this out. I have created a task for our team to review and discuss potential solutions (T417708). As you noted, simply increasing the display time may be a straightforward and effective improvement, but we will also consider whether other adjustments would better support newcomers.

We have also been discussing a related change (T408544). The idea being to not automatically showing the Quick Start Tips for task types that a user has already completed or previously viewed. The tips would still be available from the Help panel, but they would not appear by default each time. I would be interested to hear whether that approach would feel like an improvement from your perspective.

Thank you again for your thoughtful suggestion! - KStoller-WMF (talk) 23:29, 17 February 2026 (UTC)

Hi Kstoller, appreciate your reply. For T408544, that sounds like a fine idea. Will the Help panel remain highlighted/emphasised in case the user needs to be refreshed on the task? (I’m assuming this is visible when on a page and/or in edit mode?) I don’t know if it would be technically possible, or palatable, but for the Harder tasks, the tips could disappear after completing those edits x3 or x5 or whatever. Thank you for asking for my input as a newcomer! Itsaclarinet (talk) 02:29, 19 February 2026 (UTC)

@Itsaclarinet Thank you for following up, I like those ideas! We have recently discussed a related concept, which involves adding a subtle animation to the Help Panel to make it clearer how to reaccess onboarding, tracked inT414537.

I'm not sure what we will be able to prioritize, as this does not align directly with our current project focus. That said, we do try to incorporate as many small, high impact improvements as possible when opportunities arise.

Thank you again for sharing your feedback. I hope you continue editing and stay involved. :) - KStoller-WMF (talk) 05:52, 20 February 2026 (UTC)

i was installing a load of scripts for a while now and i realized none of them were actually showing, or, being implemented in my interface. Take User:Polygnotus/Scripts/AI Proofreader.js for example. This script would stand out because it adds another tab to the interface, but it doesnt. It does not show up in mine and that goes for the rest of my scripts. I thought it was a conflict problem, but it might just be my browser. But other scripts like VandalHandle works perfectly fine. If anyone could help me with this i would most appreciate it :) 203N7HN6 (talk) 10:53, 20 February 2026 (UTC)

@203N7HN6 wfLoadExtension( 'ORES' ); may be causing the problem. It's a PHP function that is not available in JS. I guess the script execution stops on that line because of an error and that's preventing the remaining lines from running. Dragoniez (talk) 13:15, 20 February 2026 (UTC)

it was! thanks so much! 203N7HN6 (talk) 17:09, 20 February 2026 (UTC)

When I try to search the archive from the talk page of Wikipedia:Requests for comment, it searches all of Wikipedia, not subpages. Is this the right place to raise? Dw31415 (talk) 20:11, 20 February 2026 (UTC)

Same as #Archive search boxes not limiting search scope? Nardog (talk) 22:02, 20 February 2026 (UTC)

Yes, thank you! I subscribed to the Phab issue. Dw31415 (talk) 22:11, 20 February 2026 (UTC)

As some may be aware by now, the maintainers of archive.today (and archive.is, etc.) recently injected malicious code into all archived pages in order to perform a denial of service attack against a person they disliked (this can be confirmed by the instructions described here.) While the malware has been removed now, it is clear that archive.today can't be trusted to not do this in the future, and for the safety of our readers, these archiving services should be swiftly removed and the websites blacklisted to prevent further use.

The rub is that https://archive.today alone is used in nearly 400,000 pages, and its sister site archive.is is used in around 50,000. We're clearly very dependent on this service, but we must find a way to break away from it. And fast. Children Will Listen (🐄 talk, 🫘 contribs) 00:26, 5 February 2026 (UTC)

I've been wondering the same thing. I don't have an answer but have notified Wikipedia talk:Link rot to get more attention to this issue. ClaudineChionh (she/her · talk · email · global) 01:05, 5 February 2026 (UTC)

Absolutely not. We are dependent on external sites for archiving and verification. I have in the past lobbied WMF to acquire archive.org so it can meet our needs (or set up our own version) but unless and until that happens we have to link to external sites for verification. Hawkeye7 (discuss) 01:24, 5 February 2026 (UTC)

We're not deprecating archive.org (run by the Internet Archive), only the archive services provided by whoever runs archive.today. The maintainers of that service cannot be trusted for the reasons I described. Children Will Listen (🐄 talk, 🫘 contribs) 01:27, 5 February 2026 (UTC)

I don't trust the maintainers of archive.org. Hawkeye7 (discuss) 02:28, 5 February 2026 (UTC)

I trust them a far sight more than someone who has now verifiably used their ownership of a domain we link some 400k times to DDOS another website on the Internet. Izno (talk) 03:39, 5 February 2026 (UTC)

Maybe, but we need verifiability and archival sites are required for that. We shouldn't sacrifice our primary mission. Hawkeye7 (discuss) 03:57, 5 February 2026 (UTC)

Archive sites that are willing to inject malicious javascript aren't particularly good for verifiability. AntiCompositeNumber (they/them) (talk) 04:31, 5 February 2026 (UTC)

They are better than nothing. The only solution is to run our own archive. Hawkeye7 (discuss) 04:46, 5 February 2026 (UTC)

Why insist on framing this as an all or nothing choice? Other archive sites exist and they don't have a demonstrable history of weaponising their service. Treating it as an exceptional case isn't unreasonable.

Also, even if this were an all or nothing choice (which it isn't), Wikipedia's need for citations isn't more important than the security of users. Archive.today has demonstrably abused its users' trust (including Wikipedia's editors and readers) and cannot be considered safe. – Scyrme (talk) 20:46, 5 February 2026 (UTC)

• Trash it completely. Archive.today has proven that it's not trustworthy as an archive source (unlike the Internet Archive) and links to it should be considered potentially malicious in nature. Silverseren^C 04:58, 5 February 2026 (UTC)

  "Archive.today has proven that it's not trustworthy" - there are no (known) examples of its owner tampering with archived pages. "unlike the Internet Archive" - Internet Archive removes archived copies regularly. sapphaline (talk) 14:56, 5 February 2026 (UTC)

  there are no (known) examples of its owner tampering with archived pages: Yes there is, see above. Injecting malicious JavaScript is tampering, visible or otherwise. If they are willing to do that, who knows when they'll decide to exploit zero-days or engage in blatant manipulation. Children Will Listen (🐄 talk, 🫘 contribs) 15:03, 5 February 2026 (UTC)

  They only injected it on the CAPTCHA page. sapphaline (talk) 15:04, 5 February 2026 (UTC)

  Which is only shown when you try to archive something, by the way. sapphaline (talk) 15:05, 5 February 2026 (UTC)

  I always see the CAPTCHA screen when I view an archived page for the first time. Children Will Listen (🐄 talk, 🫘 contribs) 15:06, 5 February 2026 (UTC)

  My point about them being trustworthy when it comes to archived copies stands. Internet Archive is way less reliable in this regard, because archived copies can always be deleted there. sapphaline (talk) 15:20, 5 February 2026 (UTC)

  I'd rather have information lost than readers having to encounter mailicious code whenever an archived copy is visited. Also, we know nothing about the maintainer(s) of Archive.today, how they make money, or even if they're ready to pack up their bags tomorrow and leave. They're in a jurisdiction that's politically unstable and prone to censorship. None of these problems exist with the Internet Archive. Children Will Listen (🐄 talk, 🫘 contribs) 15:30, 5 February 2026 (UTC)

  A jurisdiction that's politically unstable and prone to censorship - you mean, like the United States? (I wish I was joking about my country in 2026) Setting that aside, we shouldn't want any information lost just like that. We need a remedying/replacement process coming before a removal process. See my main comment below. Stefen 𝕋ower ^{Huddle • Handiwerk} 15:34, 5 February 2026 (UTC)

  If this RFC is going to pass (which will be a very unfortunate result!), megalodon.jp archives archive.today snapshots almost perfectly (the only issue is that they're zoomed out and for some reason have a 4000px width, but this is trivially fixed by unchecking some checkboxes in devtools). Maybe WMF could arrange some deal with their operators to archive all archive.today links we have? sapphaline (talk) 15:43, 5 February 2026 (UTC)

  "how they make money" - why should we care about this? "if they're ready to pack up their bags tomorrow and leave" - archive.today has existed for nearly 14 years. It's a snowball chance in hell they're going to shut the site down tomorrow or in any foreseeable future. "They're in a jurisdiction that's politically unstable and prone to censorship" - how do you know? "None of these problems exist with the Internet Archive" - US is extremely prone to censorship and political unstability + Internet Archive removes archived copies on any requests, not just governmental ones. sapphaline (talk) 15:35, 5 February 2026 (UTC)

  It is economically infeasible to hold trillions of archived pages and provide them indefinitely for free. We don't know how they're funding their project, which means we wouldn't know when this funding would dry out.

  Their willingness to inject malware over a petty dispute puts their stability in disrepute. If we get in the bad graces of these maintainers, who knows what they'll be willing to do to us?

  It's fairly well-known that the maintainer(s) of Archive.today live in Russia, and that the main archive storage is also hosted in Russia. Sometimes, they redirect certain IP addresses to yandex.ru, and of course, their official Wikimedia account Rotlink was created in ruwiki.

  However, you are right about the United States, sadly. Children Will Listen (🐄 talk, 🫘 contribs) 15:44, 5 February 2026 (UTC)

Actually the theory is Ukraine, not Russia, and the evidence is they provision on global edge cloud providers (such as CloudFlare - but not CloudFlare). -- GreenC 15:46, 7 February 2026 (UTC)

@GreenC What does "such as CloudFlare - but not CloudFlare" mean? David10244 (talk) 05:59, 13 February 2026 (UTC)

CloudFlare is an example of a global edge network provider similar to what archive.today uses, but is not the specific provider that archive.today uses. -Wiggles (talk) 01:05, 20 February 2026 (UTC)

@ChildrenWillListen makes an important point. People are bringing up that WP already has 500K links to them. What if they introduce malicious code on just some of the archived pages (for instance, because targets of their malice to be more likely to access those links)? Aurodea108 (talk) 01:49, 9 February 2026 (UTC)

I can't think of an explanation for this that isn't malicious. You'd think the maintainer(s) of archive services wouldn't be stupid enough to try to get a blog removed from the internet as a petty retaliation over some alleged doxxing. — DVRTed (Talk) 05:33, 5 February 2026 (UTC)

I agree, they should be blacklisted. Should have happened a long time ago, really, because of massive copyright violation: they distribute lots of content that the copyright owners only made available behind paywalls. See WP:COPYLINK: "if you know or reasonably suspect that an external Web site is carrying a work in violation of copyright, do not link to that copy of the work". — Chrisahn (talk) 11:11, 5 February 2026 (UTC)

I fully appreciate why this needs dealing with, but I am concerned about "the rub". We could end up harming verifiability on a *lot* of our content. Of course, we can leave citations in place without the archive.today links, but without the ready verification of having an article to load, I fear some useful article text could end up being removed by editors who decide they can't trust the listed source due to inaccessibility (typically those with little wiki experience). In cases where the paywalled content still exists, removal would be less likely, but in cases where the original link is permanently dead, it's not available on Archive.org, and we only have archive.today... yikes.

Deprecation makes sense as long as that doesn't include immediate removal before any replacement remedy is pursued. Any process that intervenes with using archive.today should encourage editors to directly replace these sources with archive.org links or newspaper.com clip links, or locate alternate sources. I realize this is generally what deprecation means but if the intervention can be clear and help the editor find an alternative, I would be more relieved of the ramifications of ditching this source. Stefen 𝕋ower ^{Huddle • Handiwerk} 14:51, 5 February 2026 (UTC)

well-said. i support blacklisting as long as it is accompanied by an effort to find alternative solutions instead of just plain removal. ... sawyer * any/all * talk 15:33, 5 February 2026 (UTC)

Oppose - this will greatly harm verifiability. sapphaline (talk) 14:53, 5 February 2026 (UTC)

Agree with those above arguing that archive.today is simply not trustworthy enough to be sending our readers to. Adding malicious code to cause a DDoS on another website is an absurd thing for a website maintainer to do and we shouldn't be facilitating their behaviour by sending more users to their site, nor simply hoping that they won't do something worse which targets our readers. Sam Walton (talk) 15:03, 5 February 2026 (UTC)

You may be interested to see Wikipedia:Requests for comment/Archive.is RFC (2013, with consensus to remove the then 10k links and blacklist for future, overturned by Wikipedia:Requests for comment/Archive.is RFC 4 in 2016.) Andrew Gray (talk) 18:56, 5 February 2026 (UTC)

I saw that, yes. Perhaps it's time for Wikipedia:Requests for comment/Archive.is RFC 5? Children Will Listen (🐄 talk, 🫘 contribs) 19:01, 5 February 2026 (UTC)

Yes, I think so. As you've said above, they can't be trusted to not do that again in the future, so I would support blacklisting their links. Some1 (talk) 01:17, 6 February 2026 (UTC)

I think there needs to be an official RfC on this to get more opinions. Personally I think this shows that archive.today can't be trusted (if they do this over something rather petty, what's stopping them from putting more malicious code into archived pages, not just the captcha?), and it should be at least deprecated - but only if the links can be replaced with a different archive without loss of information. Suntooooth, it/he (talk | contribs) 20:15, 5 February 2026 (UTC)

They blatantly violated Wikipedia:External links#EL3, but you think we need to have a long discussion about whether malware-serving websites are sometimes okay?

If we're going to have an RFC, let's blacklist now and focus the RFC discussion on how to cope rather than whether we should provide links to malware-serving websites. WhatamIdoing (talk) 22:16, 5 February 2026 (UTC)

And if we can't quite bring ourselves to list the sites on MediaWiki:Spam-blacklist, then let's at least put up a warning via Special:AbuseFilter. WhatamIdoing (talk) 22:17, 5 February 2026 (UTC)

I think that formally gaining consensus is important when it affects as many links as this does, especially since even in this thread it hasn't been unanimous. If this affected a much lower number of links (think a couple of orders of magnitude lower) and links that would be easily replaced or removed, then I wouldn't be suggesting a full RfC. Suntooooth, it/he (talk | contribs) 00:40, 6 February 2026 (UTC)

I wonder if there's a way to add a warning in the articles. Something like ^{[replace archive link]} (and a category showing affected articles) might encourage people to start the process of finding other sources. It might be possible to do this automagically through the CS1|2 templates. I'm assuming that would catch most of them. WhatamIdoing (talk) 02:44, 6 February 2026 (UTC)

It is in the realm of feasible just to turn off the display of archive links that are via archive.today/is in CS1/2. The real question is if we can get everything or if we just have to start off with vanishing the big quantity of links. Izno (talk) 03:59, 6 February 2026 (UTC)

Removing archive links (even by just turning them off, rather than fully removing them) from this number of articles would be a huge hit to verifiability. If consensus is gained to remove archive.today links, there needs to be a mechanism for replacing them with other archives. Suntooooth, it/he (talk | contribs) 16:05, 6 February 2026 (UTC)

would be a huge hit to verifiability I think turning their display off is a fair compromise on the road to removal and replacement. I do agree that half a million pages or links is a big number. A maintenance category would naturally be set up so we can actually find these quicker.

We probably also should notify WP:URLREQ and/or specifically @GreenC about this discussion. Izno (talk) 20:21, 6 February 2026 (UTC)

Good idea. Also considering the RfC above, isn't it possible that many of the archive.today links on the encyclopedia _aren't actually necessary?_ As in, they were added superfluously by the website operators themselves? Perhaps the true scale of the problem is much smaller, and we could vibe code a quick tool to check some of the links. audiodude (talk) 04:50, 8 February 2026 (UTC)

WhatamIdoing, see Template:New archival link needed, which I created pending the outcome of the RFC. mdm.bla 15:13, 18 February 2026 (UTC)

It's not feasible to blacklist it right now. sapphaline (talk) 07:20, 6 February 2026 (UTC)

Why do you think it's not feasible? What do you mean by "feasible"? — Chrisahn (talk) 15:18, 6 February 2026 (UTC)

Because we have ~500k+ (including all of the different domain names) links to it. sapphaline (talk) 18:25, 6 February 2026 (UTC)

That's not a problem. We won't remove them (at least not for a while). Blacklisting means that no new links to these domains can be added. It doesn't mean existing links have to be removed. — Chrisahn (talk) 22:29, 6 February 2026 (UTC)

Every day, links are added because there is no other option. They literally are the only source for a large set of web pages on the Internet. This is why there are so many links. It's the only option. It is pragmatic. You and some others appear concerned about what is best for Wikipedia, but you don't seem concerned about the consequences, which are very real, immediate and large scale - it would cause significant damage to Wikipedia. Unlike the good feelings about punishing Archive.today for some transgression. What is more important? -- GreenC 16:04, 7 February 2026 (UTC)

I've added archive.org URLs to lots of articles. In case a page hasn't been archived by them yet, I click "Save Page Now". I don't recall any significant problems, and I don't recall a URL that couldn't be archived. I'd say such URLs are pretty rare. — Chrisahn (talk) 22:50, 7 February 2026 (UTC)

Actually it's common. I speak from the data not an opinion. -- GreenC 23:27, 7 February 2026 (UTC)

The problems likely depend on the type of source, so some editors may encounter problems fairly often, and others will not ever encounter it. WhatamIdoing (talk) 23:35, 7 February 2026 (UTC)

What data? — Chrisahn (talk) 23:36, 7 February 2026 (UTC)

@Chrisahn, you might want to read the bottom of his User: page... WhatamIdoing (talk) 01:00, 8 February 2026 (UTC)

Agree that there should be an RfC. The implications of the discussion and potential actions taken by consensus will have far reaching effects across the encyclopedia. Additional comment as a technical editor, not one who edits a lot of articles: if archive.today provides a copy of a paywalled or linkrotted news article, but the article was actually published by the news organziation in question at some point, what does it matter if the archived copy isn't available? The citations are still technically valid right? Does wikipedia remove citations to books that are out of print? Does information exist if it's not on the internet lol? audiodude (talk) 04:47, 8 February 2026 (UTC)

Yes, you're right that a Wikipedia:Convenience link (to the original and/or an archive) is not required, if the news article is archived in some place that is accessible to the general public. For example, it's traditional for ordinary print newspapers to keep a copy of all their old newspapers, and many will either let the general public take a look or send the older ones to a local library or historical society. However, not all publications have a print edition, and some news outlets put more information/additional articles on their web. I have, for example, been disappointed that paper copy of The Atlantic has fewer articles than their website. A web-only source needs a working URL, because sources must be WP:Published#Accessible. WhatamIdoing (talk) 06:04, 8 February 2026 (UTC)

Has anyone linked to the circus that occurred when archive.today first appeared? As I recall, they used extremely advanced (for the time) techniques to attack Wikipedia by edit warring their links into pages. The views that we have to keep using them miss the big picture: these guys are obviously up to something bad. The infrastructure and operational maintentance to support their system would cost a vast amount and someone is planning to get a return on that investment eventually. It's much more effort than some libertarian philanthropist would support. Johnuniq (talk) 02:47, 6 February 2026 (UTC)

Yes linked above: Wikipedia:Requests for comment/Archive.is RFC (2013, with consensus to remove the then 10k links and blacklist for future, overturned by Wikipedia:Requests for comment/Archive.is RFC 4 audiodude (talk) 04:54, 8 February 2026 (UTC)

Technical question: How would blacklisting work? If I understand correctly, the idea is that blacklisting prohibits adding new archive.today (and archive.is etc.) links, but we'll keep the existing ones for now. Specifically: If I edit an article and try to add a new archive.today link, I get an error message and can't save my changes. But if I edit an article (or section) that already contains one or more archive.today links and I make unrelated changes, there's no such error message. Is that correct? Can we make that work? A "dumb" edit filter (that simply checks whether such links occur anywhere in the text I'm trying to save) won't work – it won't let me save unrelated changes. I can think of a few ways to implement a smarter filter, but I don't know if edit filters have access to the required information, or how efficient smarter checks would be. — Chrisahn (talk) 09:18, 6 February 2026 (UTC)

@Chrisahn Yes, this is how the built-in tools like MediaWiki:Spam-blacklist already work, and edit filters can also be made to work that way. They forbid adding new links to blacklisted domains, but if a link is already present in the article, it can be edited without tripping the blacklist. There are still some scenarios that cause problems (e.g. if a vandalism deletes a citation that links to archive.today, you won't be able to revert it without removing those links first), but that hasn't stopped additions to the blacklist before. Matma Rex talk 14:41, 6 February 2026 (UTC)

Thanks for the explanation! Sounds good. — Chrisahn (talk) 15:17, 6 February 2026 (UTC)

There have been concerns about archive.is/archive.today going back more than twelve years, see for example Wikipedia:Requests for comment/Archive.is RFC. --Redrose64 🌹 (talk) 11:13, 6 February 2026 (UTC)

Hi!

archive.today is just a very useful website that can be used if archive.org is not helping.

The hosters of archive.today are not as reliable as the guys that host archive.org. However, we don't know any case, where a snapshot was false, do we?

In this case, they "just" abused their visitors for a DDOS attack. Of course we should not support this. But this does not mean, we have to definitely block the website.

By the way, blacklisting (via WP:SBL) without a previous removal of all links is not a good option, because this leads to several problems:

• Moving of parts of pages to other pages (e.g. archiving) is not possible any longer, if the moved text contains a link.
• Modifying an existing blacklisted URL (e.g. link fixing) might trigger the SBL.
• It's not possible to add blacklisted links to a discussion which is challenging for some not so technical users.

In my opinion a technical solution could be:

• replace all links with a (unsubstituted) template (yes, this is a lot of work, but could be automized partially);
• if any problem with the domain occurs again, modify the template such that there is no link any longer to archive.today (and .is and all the other domains);
• when the problem is solved, revert the template change;
• if anybody adds a link to archive.today without the template, a bot could try fix that afterwards and the bot could write a message on the linker's talk page that they should check whether they could find something better.

By a solution like this we would would still have the benefits of the archived versions. But we could remove all links fast and at once, if needed.

-- seth (talk) 17:04, 6 February 2026 (UTC)

A couple hundred thousand bot edits is not a good solution, either.

Trappist the monk might have some ideas about whether the citation templates could special-case these domain names for a while, while the work is done. A maintenance category, as Izno mentioned above, would also be a good idea. And even if we don't want to use the MediaWiki:Spam-blacklist quite yet, for fear that it will interfere with rearranging pages, we could implement a Special:AbuseFilter that would prevent people from adding any new ones. WhatamIdoing (talk) 21:33, 6 February 2026 (UTC)

I still advocate going back to WMF with a proposal to create our own archive. This will get us off dependence on external archive sites that we cannot control. Hawkeye7 (discuss) 22:25, 6 February 2026 (UTC)

@Hawkeye7: It may open us up to legal difficulties we can't easily handle, especially if we refuse to delete content as instructed by copyright owners. Children Will Listen (🐄 talk, 🫘 contribs) 22:27, 6 February 2026 (UTC)

Setting up an internet archive requires years of planning and work. I'd like us to start making tangible progress on resolving this problem today, or at least in the next week. Even if we thought that was legal and a good idea, creating our own archive isn't going to address the problem right now. WhatamIdoing (talk) 23:24, 6 February 2026 (UTC)

cs1|2 can special case archive.today (and companion domains) if/when there is a consensus to deprecate/blacklist.

—Trappist the monk (talk) 22:58, 6 February 2026 (UTC)

One major problem with the edit filter (and SBL/BED) is that many unexperienced people who trigger a rule just don't know what that means and what they should do. We often see that people who wrote large paragraphs and failed of first try to safe, just run away, although the warning said that if they are sure about what they are doing, they just should try to save again.

The filter (and SBL/BED) should be used if people intentionally (try to) spam. If they actually just want to help, then there's a risk of annoying/frustrating them. That's why -- over time -- I more and more tend to use notification bots and maintenance lists instead of the blacklist-like tools in cases where links are mostly added by non-spammers.

-- seth (talk) 23:27, 6 February 2026 (UTC)

XLinkBot can deal with link additions, and we can modify the citation modules to not accept/show archive.today links anymore. After the number of links becomes manageable, an edit-filter based solution would be a good idea. Children Will Listen (🐄 talk, 🫘 contribs) 22:36, 6 February 2026 (UTC)

Also, am I the only person concerned by how OP downplays doxxing someone as a "petty dispute"? sapphaline (talk) 18:25, 6 February 2026 (UTC)

Might be concerning, but that's "two people have been bad people" and each should be judged on their own merit accordingly. You don't treat someone DDOSing another person off the Internet as a stable individual meriting half a million links from the most popular source of collated information on the Internet (and that ignoring the prior dramas, as linked above). Izno (talk) 21:37, 6 February 2026 (UTC)

@sapphaline: I wasn't fully aware of what the DDoS was a retaliation for when I started this thread, but either way, as @Izno said, they can't be trusted anymore, regardless of intention. Children Will Listen (🐄 talk, 🫘 contribs) 22:28, 6 February 2026 (UTC)

Doxing? Hardly. Quote: "While we may not have a face and a name, at this point we have a pretty good idea of how the site is run: it’s a one-person labor of love, operated by a Russian of considerable talent and access to Europe." — Chrisahn (talk) 22:40, 6 February 2026 (UTC)

Probably not important, but interesting: Less than a day before this discussion was started, User:Masharabinovich, an account probably connected to archive.today, was renamed by request. — Chrisahn (talk) 22:47, 6 February 2026 (UTC)

Well, the article they tried to remove did say that "Masha Rabinovich" is a pseudonym they use when creating online accounts. Children Will Listen (🐄 talk, 🫘 contribs) 23:13, 6 February 2026 (UTC)

Another aspect: Depending on how the FBI case against archive.today goes, there's a chance that these ca. 500,000 archive links in our articles will become useless in the not too distant future. — Chrisahn (talk) 01:05, 7 February 2026 (UTC)

This I agree with. Stay the course and wait and see. -- GreenC 17:11, 7 February 2026 (UTC)

• Prior to about 2015, the Wayback Machine did not systematically archive all links on Wikipedia. There are huge gaps prior to that date. Between 2012(?) and 2015, Archive.today systematically archived Wikipedia. Thus many dead links are only archived on Archive.today. The one time Archive.today got blacklisted a long time ago, it didn't last long. People reversed it. Why? Because Archive.today is incredibly useful. It's that simple. It's pragmatic. They have the goods nobody else does. This incident with the CAPTCHA will soon be forgotten as inconsequential to Wikipedia. But blocking Archive.today will cause daily conflict with editors who need to use it because there is no other option. -- GreenC 17:11, 7 February 2026 (UTC)

  The decision was reversed because the maliciousness of the maintainers used to be pure speculation. This is no longer the case. Children Will Listen (🐄 talk, 🫘 contribs) 17:14, 7 February 2026 (UTC)

Your wish to punish Archive.today over this silly incident (which they undid) would cause widespread and deep collateral damage to Wikipedia. -- GreenC 18:32, 7 February 2026 (UTC)

I think that would depend on how it's implemented. First, just to remind everyone, WP:Glossary#verifiable means someone can find a reliable source. It does not mean that the Wikipedia article already has a little blue clicky number (that's WP:Glossary#cited) or that the ref contains a functional URL. This means that if the Wikipedia article says "The Sun is really big", and there's no cited source, or the cited source is a dead URL, then that sentence is still verifiable, because an editor (or reader) could look up Alice Expert's book, The Sun is Really Big, and learn that the material in the Wikipedia article matches the material published in at least one reliable source. Removing archive links therefore doesn't (usually) destroy verifiability (unless that was the only source in the world that ever said that, and the original is a dead URL – in which case, are we really sure we should be saying that now?); it just makes verifying the information take more work.

Having looked at a too-small sample size (=4 articles) with these links, I think that some of these links are unnecessary and others deserve a {{better source needed}} tag no matter what the archive status is. I therefore think that checking and replacing sources might be a good thing, overall. WhatamIdoing (talk) 19:20, 7 February 2026 (UTC)

A citation to a book is always verifiable. So is the NYT and other news outlets. Referring to everything else online-only, which is most of it. Without an archive, a dead website is unverifiable. Maybe wait 10 years for an archive to surface, but eventually it's gone. You might find other sources, but who is going to do that for half a million links? Certainly not the few people engaged in these conversations. Most people don't even verify sources, much less try to replace them with other sources. People are busy creating new citations with future dead links that nobody fixes. The debt continues to grow, and one of our best tools for dealing with it is now being threatened with removal. -- GreenC 19:44, 7 February 2026 (UTC)

Please look at the definitions I linked. We don't care whether "a dead website is unverifiable". (It's really none of our business whether people can double-check that some other website's content was taken from a reliable source vs is an original work.)

We care whether the content in the Wikipedia article is verifiable – and we care whether it's verifiable in any reliable source, not just the cited one.

Yes, you're right: half a million sources is a problem, and the debt continues to grow. To stop the bleeding, I think we should deprecate/discourage future additions of this source. To get the existing ones checked, I think we should have a tracking category, and maybe even a way to make this a more mobile-friendly and/or newcomer-friendly task. Based on my experience the other day, we're looking at about five minutes per source. Also based on my experience the other day, half the sources are unreliable ones anyway (at least for medical content). WhatamIdoing (talk) 19:55, 7 February 2026 (UTC)

If Archive.today actually goes offline, then we have another problem. But treating it like it's already offline by adding {{dead link}} templates is backwards since we don't know the future. The assumption there are alternatives to Archive.today is a mistake. Most Archive.today links are added because Wayback can't do it. There's really only two games in town, and we are eliminating one. And you can't go back and fix it, either you save the web page before it dies or it's gone forever. Archive.today has a monopoly on many archive pages, and many citations are the only game in town there are no better sources. Most people don't read these forums, but if you start blocking or hiding links, there will be many editors complaining. It's a major resource for our community that has a large following. Nobody has really been notified about the RfC. -- GreenC 21:00, 7 February 2026 (UTC)

Roughly 2 years and 8 months seems like a decent chunk of time to me. Nil Einne (talk) 05:09, 13 February 2026 (UTC)

Wikipedia:Requests for comment/Archive.is RFC 5 is live. This should probably be added to WP:CENT to get a more global consensus. Children Will Listen (🐄 talk, 🫘 contribs) 17:12, 7 February 2026 (UTC)

Hoisting a comment by @Sapphaline to the top level:

"megalodon.jp archives archive.today snapshots almost perfectly (the only issue is that they're zoomed out and for some reason have a 4000px width, but this is trivially fixed by unchecking some checkboxes in devtools). Maybe WMF could arrange some deal with their operators to archive all archive.today links we have?" Aurodea108 (talk) 20:51, 15 February 2026 (UTC)

I experimented with taking this one step further by rearchiving to Wayback a megalodon archive of an archive.today archive (what a sentence...)

This "works" in the sense that the information is there, but it's certainly a bit fiddly to view.

It would be interesting to try this with a page that could not normally be archived on Wayback. PickledCookies (talk) 21:31, 17 February 2026 (UTC)

I first asked my question at the Help Desk, but the initial advice the senior editor gave me didn’t work. He suggested as Plan B that I come here. This is what I’d like to know:

Is there a way to search through our notifications—like for the name of a sender or key words in a topic—when we’re working on our phone rather than our computer? If so, is it done differently on a Macintosh than an Android? Augnablik (talk) 16:45, 19 February 2026 (UTC)

Notifications from what software? This is not a general help desk for technical issues but instead for issues that are impacting specifically the Wikipedia experience. Izno (talk) 17:51, 19 February 2026 (UTC)

I'll WP:AGF and assume they're talking about Special:Notifications. In any case, it's going to be whatever search function their mobile browser has, as I don't know of any search feature built in to mediawiki. --Ahecht (TALK
PAGE) 19:43, 19 February 2026 (UTC)

Yes, @Izno, I knew VPT was basically for technical issues, so I was a little unsure about coming here even on advice. Sorry. Augnablik (talk) 07:43, 20 February 2026 (UTC)

@Augnablik no that is fine, if it is Wikipedia related. But there are many problems in this world, you have to give very accurate descriptions, for others to be able to correctly identify what you are asking about. —TheDJ (talk • contribs) 06:32, 21 February 2026 (UTC)

Just so I know for next time (if there is one): what is the right way to refer to the notifications we see when we open the Wikipedia app on our phone? Augnablik (talk) 17:37, 21 February 2026 (UTC)

Wikipedia notifications? — Qwerfjkltalk 17:50, 21 February 2026 (UTC)

It is not possible to search through our onwiki Notifications from onwiki (the old task for implementing that is phab:T132805). If you have your Notifications settings configured to send Notifications to your email, that is the best current option for searching historic entries. More generally: There are many ways that the Notifications system could potentially be improved, in ways like this, but they all add extra complexity to both the code and the user-experience (I'm reminded of Zawinski's Law), and are not frequently needed use-cases, hence haven't been prioritized in the past. I hope that info helps. Quiddity (WMF) (talk) 21:29, 19 February 2026 (UTC)

Okay, then I guess what you’re saying is that there’s no way within the Wikipedia notifications … which answers my question. Disappointing but clear. I don’t want them sent to my e-mail. Thanks! Augnablik (talk) 07:22, 20 February 2026 (UTC)

You can open Special:Notifications and use your browser's find-in-page. Nardog (talk) 01:52, 20 February 2026 (UTC)

I was referring to the notifications that come up in the Wikipedia app. When I followed your link, the results looked similar to what I see in the app.

I can’t use your advice to use “my browser’s find-in-page” feature, though, because I’m in the Wikipedia app and not a browser like Chrome or Safari. That’s the basic problem I have, not knowing how to find past notifications that I could easily search for if I knew of a way to go about it. Augnablik (talk) 07:18, 20 February 2026 (UTC)

You can follow phab:T132805, but I wouldn't hold your breath; it's been open for 10 years. — Qwerfjkltalk 10:47, 20 February 2026 (UTC)

Even so, Qwerfjkl, thanks for the tip. I’ll ask there if anything’s planned to follow through. “Hope springs eternal …” Augnablik (talk) 05:55, 21 February 2026 (UTC)

I assumed you were on the mobile web given the tag "Mobile web edit". Nardog (talk) 12:02, 20 February 2026 (UTC)

Didn’t know that was displayed … Augnablik (talk) 05:49, 21 February 2026 (UTC)

I forgot my password and tried to reset it from a different account and got ip blocked for 3 wrong password inputs. I have enabled the option to recover password when email and username are provided. How can I reset it? 8rz (talk) 17:33, 21 February 2026 (UTC)

@8rz There's a 10-year-old task discussing this on Phabricator, but unfortunately there is currently no way to reset a password when the request originates from a blocked IP address. The only workaround is to try again from an unblocked IP address. (BTW, which account are you trying to reset the password for?) Dragoniez (talk) 17:53, 21 February 2026 (UTC)

@Dragoniez:, can I get my ip unblocked then? Do I go to WP:ANI for this?

which account are you trying to reset the password for?

Mine. 8rz (talk) 18:02, 21 February 2026 (UTC)

Note that the block is probably not caused by the wrong password attempts. The IP address is likely already blocked from editing. Dragoniez (talk) 17:58, 21 February 2026 (UTC)

So, it's an ip range block then? 8rz (talk) 18:03, 21 February 2026 (UTC)

I assume so. You might want to check Special:BlockList using your source IP. I can't tell whether a block appeal would work as the block was likely placed for a reason. Dragoniez (talk) 18:10, 21 February 2026 (UTC)

Thanks. Will look into it. 8rz (talk) 18:14, 21 February 2026 (UTC)

If I create a new account can I get this account "moved" to the new one, if/when eventually I get logged out (being continuously logged in lasts up to 1 year, to my knowledge)? 8rz (talk) 18:06, 21 February 2026 (UTC)

No, you cannot move the contributions made under this account to a second account. Izno (talk) 19:37, 21 February 2026 (UTC)

 Courtesy link: Hawara

Wikignoming my way around Category:Harv and Sfn no-target errors I come across all sorts of coding issues and here's a new one for me, sfn|EB15 citations. I cannot figure out why the two Encyclopedia Britannica cites are not working - {{sfn|EB15|2007|loc=v.1, p. 323}} and {{sfn|EB15|2007|loc=v.7, p.84}}. In my experience sfn cite usage means there should be a complete citation for the source within the article's References section for the sfn cite to link to, but is that the case for sfn|EB15? I went to Template:Cite EB15 but that page didn't answer my question. Thanks in advance for any help/answers/etc. - Shearonink (talk) 06:13, 19 February 2026 (UTC)

Shearonink, when you say "not working", can you elaborate what you mean by that? The p. 323 citation is at the end of the lead using footnote number [1]; the p. 84 citation is in section § Excavations using fn [5]. They each link to a short citation under heading § References (#1 for p. 323; #5 for p. 84), and in each case, those link down to the same full citation under section § Bibliography (i.e., this one), exactly as they should. In the References section, the caret (^) in each short citation links up to the in-text footnote. This looks like normal functionality for {{sfn}} to me. If it's the category you're worried about, you can whitelist the CITEREF so the target link resolves and the category is not created. This is covered at {{sfn#Link works but displays a no target error}}. Mathglot (talk) 08:00, 19 February 2026 (UTC)

Mathglot Thank you for doing the whitelisting at Hawara and for the link to the fix. I think I've maybe run into a similar issue only once before, where a CITEREF had to be whitelisted to fix the false error. And I also probably shouldn't try to edit when am exhausted lol. Why, though, does a false error display? It's not "Real" and yet it puts the article into the no-targets Category... - Shearonink (talk) 15:11, 19 February 2026 (UTC)

Shearonink, somewhere I wrote up an explanation of that, I forget where, but it has to do with the sequence of events that turn wikicode stored on the servers into Html delivered to your browser when you request a page, where it happens, and what can be seen at each step. One of those events is expansion of templates (like {{cite EB15}} which wraps a citation template) and modules (like Module:Footnotes, which handles sfn, et al.) into wikicode, and another is conversion of ref tags into numbered notes inline and citations at the bottom, with linkage in both directions, which is done natively in the Wikimedia software. (Which is why all Wikipedias have <ref> tags and <references>, but not all have sfn: en-wiki does, but de-wiki doesn't.) If a citation target (i.e.. a WP:CITEREF) isn't available yet because it is still hidden inside an as-yet unexpanded template, then there is no target and the error is generated. Depending on the situation, it might still get resolved in a later step before the Html is delivered, so you get properly double-linked footnote-citation linkage (e.g., here) along with the error already generated by then. In other situations, you don't get proper linkage, as in some cases involving list defined references (e.g., here). This is all very hand-wavy and not really an explanation, but I hope it gives you a flavor of what is going on. Mathglot (talk) 19:44, 21 February 2026 (UTC)

Mathglot THANK YOU. This is such a simple brilliant explanation of what is going on "under the hood", and now I think I can actually understand it. Thank you for taking the time to do this, greatly appreciated. - Shearonink (talk) 04:50, 22 February 2026 (UTC)

I've been trying (without luck) to somehow collapse the list of mayors at Arcadia, California#List of mayors. Any help would be appreciated. Thank you! Magnolia677 (talk) 12:18, 22 February 2026 (UTC)

It's (almost) never a good idea to collapse article content – MOS:DONTHIDE. I suggest a a columnar presentation for that list: {{div col}}. -- Michael Bednarek (talk) 14:21, 22 February 2026 (UTC)

@Michael Bednarek: I'll give that a try. Thanks. Magnolia677 (talk) 14:46, 22 February 2026 (UTC)

Announce: {{Archive URL counts}} a new template to track web archive statistics across all Media Wiki projects.

For example, to show the number of Archive.today URLs on English Wikipedia:

• {{Archive URL counts|archivetodayurls|en.wikipedia|N}}

  247,591

Special thanks to User:Johnuniq who doesn't know it yet but is credited for the Lua code design. I wrote the asynchronous bot that updates Commons with the statistics. Looking for feedback before the template is installed on other wikis. -- GreenC 19:58, 22 February 2026 (UTC)

It should probably have a better name. Abbreviated names don't translate well. It took me a second to realize it was "Num-of-arch" and not "Numo-farch". NguoiDungKhongDinhDanh 20:10, 22 February 2026 (UTC)

I've moved it to {{Archive URL counts}}. We are not spoiled for the space character nor for the actual word intended; my first interpretation was architecture. Izno (talk) 20:28, 22 February 2026 (UTC)

Thanks for the feedback. I don't like long names it clutters particularly in tables where templates like this are often used 100s of times on the same page. But it looks like there was no discussion and it got renamed unilaterally without consideration of options. -- GreenC 20:34, 22 February 2026 (UTC)

WP:Template namespace is pretty clear about the expectations around naming templates. It's so other people can identify, find, and use them. Izno (talk) 20:49, 22 February 2026 (UTC)

OK need to make a shortcut. Suggest WP:NUMOFARCH .. if it helps you to remember "numo-farch" all the better, like I remember it as "wed-nes-day". -- GreenC 21:07, 22 February 2026 (UTC)

Thanks for the credit, and thanks for this valuable tool. However, WP:NUMOFARCH is not helpful. Use WP:NUMARCHIVES which is easier to understand and to type (because you don't have to think much about where the abbreviation stops). Johnuniq (talk) 02:32, 23 February 2026 (UTC)

Can you add Ghostarchive and Megalodon to the table? sapphaline (talk) 20:36, 22 February 2026 (UTC)

Proto-Indo-European (PIE) is a reconstructed language. When I use the template template:lang, it will show Piro Pueblo language (if pie is used). And also, it seems to be no specific template for PIE.

On Wikipedia, if one needs to input a special language, e.g. PIE, what template should he use? Or use nothing? Noordpunt (talk) 12:58, 23 February 2026 (UTC)

Template:Lang uses ISO 639 language codes, and in that standard code "pie" is Piro Pueblo language. It appears that Proto-Indo-European isn't assigned an ISO 639 code. Template:Lang#Proto-languages suggests that "ine-x-proto" might be appropriate for the template. Anomie⚔ 13:36, 23 February 2026 (UTC)

Thank you! I tried. It worked. Noordpunt (talk) 13:54, 23 February 2026 (UTC)

Check out Help talk:Citation Style 1 § module suite update 28 February – 1 March 2026 for details. Some context for the archiving changes is on the talk page, and more is at Wikipedia:Archive.today guidance. Please, followup with any concerns at Help talk:CS1 rather than here. Rjjⁱⁱⁱ (talk) 18:14, 23 February 2026 (UTC)

MediaWiki message delivery 19:01, 23 February 2026 (UTC)

Please join the discussion at Template talk:Multiple image § Dark mode skin invert image problem. —⁠andrybak (talk) 23:02, 23 February 2026 (UTC)

See Talk:John/Eleanor Rykener#The slash has some technical issues for the conversation that led me here. Per WP:NC-SLASH and as seen at Talk:John/Eleanor Rykener, there is a link at the top of the talk page to Talk:John, since the slash makes the talk page into a subpage. For some reason that NC-SLASH does not explain, however, Talk:Aoraki / Mount Cook does not have this link. Do the spaces around the slash disable the subpage functionality in some way? Mike Christie (talk - contribs - library) 22:41, 18 February 2026 (UTC)

It's because Talk:Aoraki doesn't exist. --Redrose64 🌹 (talk) 22:58, 18 February 2026 (UTC)

It exists now. ~2026-12043-58 (talk) 08:44, 24 February 2026 (UTC)

I want to create a subst:d template that puts a Template:Database report on a page and sticks the {{PAGEID}} for an existing page inside the template. I want editors to be able to create something like Wikipedia:Archive.today guidance/high traffic pages report except for any arbitrary page containing links (e.g., a list of all the articles in a WikiProject's scope).

I want the process to look like this:

• An editor types: {{subst:my-new-template|Alphabet soup}} into a new page, and clicks the big blue button to create the page. (Note: The Page ID for Alphabet soup is 21725178.)
• When they open the page later, they see: code code code 21725178 code code code.

Is this possible, or do they need to look up the Page ID manually and type {{subst:my-new-template|21725178}} instead? WhatamIdoing (talk) 18:19, 23 February 2026 (UTC)

@WhatamIdoing: {{PAGEID}} accepts a pagename argument: {{PAGEID:Alphabet soup}} → 21725178. NguoiDungKhongDinhDanh 18:26, 23 February 2026 (UTC)

Just fetch it in the query. AND pl_from = (SELECT page_id FROM page WHERE page_namespace = 0 AND page_title = 'Alphabet_soup') —Cryptic 18:39, 23 February 2026 (UTC)

Since they won't all be in the same namespace, I think I should probably try the pagename argument. WhatamIdoing (talk) 19:53, 23 February 2026 (UTC)

You are essentially looking to create a templatized database report – this is supported via Module:Database report. – SD0001 (talk) 09:50, 24 February 2026 (UTC)

I am trying to access Newspaper Archive via Wikipedia Library, but I keep getting a "connection refused" error. Anyone know how to fix this? Ten Pound Hammer • ^{(What did I screw up now?)} 19:42, 21 February 2026 (UTC)

@TenPoundHammer: Thanks for reporting this. We're not sure exactly what the issue is but are looking into it. Updates will be posted at T418219. Samwalton9 (WMF) (talk) 10:33, 24 February 2026 (UTC)