Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for 5 days.

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

Early Explorations Into Semantic Search: Phase 0

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, [1] (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)

Notified: Help talk:Searching, Help talk:Navigation, Help talk:Introduction to navigating Wikipedia/1 and mw:Help talk:CirrusSearch. Sdkb‑WMF ^talk 19:56, 11 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. 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. [...]

References

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.[2] 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 string

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)

Statistics error?

Tracked in Phabricator
Task T339291

For me at least Special:Statistics shows that out of 51,121,486 registered users there are merely 519 confirmed users and 78,094 extended-confirmed users in particular, which is oddly impossible, the real numbers for both must be significantly higher. Is this a bug of some sort? Brandmeister ^talk 16:17, 19 January 2026 (UTC)

"Is this a bug of some sort?" - yes; "registered users" count includes temporary accounts. sapphaline (talk) 16:24, 19 January 2026 (UTC)

Where is the bug report then on phabricator? Prototyperspective (talk) 21:51, 20 January 2026 (UTC)

phab:T339291 Johannnes89 (talk) 09:28, 29 January 2026 (UTC)

Note that the "Confirmed users" entry on Special:Statistics refers to users that have manually been added to the confirmed group, and is distinct from the autoconfirmed group that applies to old enough users with enough edits. The autoconfirmed group is an implicit group which means MediaWiki checks membership of that on the fly when needed, so a count can't be shown on Special:Statistics or other similar pages. taavi (talk!) 16:33, 19 January 2026 (UTC)

As per this query, there are 2,560,461 autoconfirmed users on enwiki and 519 manually confirmed users. There are 78,094 users who have made 500 edits and whose account age is older than 30 days. These numbers look correct to me. – DreamRimmer ■ 16:36, 19 January 2026 (UTC)

Weird, thanks. One can think MediaWiki should reflect the numbers automatically since Special:UserRights for every user is there. Brandmeister ^talk 16:54, 19 January 2026 (UTC)

It does. Autoconfirmed users are just not enumerated on the statistics special page, because they're not in a group that can be automatically queried by the software. Graham87 (talk) 03:35, 20 January 2026 (UTC)

@Graham87 Well, DreamRimmer was able to query the count of autoconfirmed users, so it is possible for that statistics page to show the same count, right? David10244 (talk) 06:16, 23 January 2026 (UTC)

@David10244: Nope, because it's not kept track of by a separate magic word. Graham87 (talk) 06:18, 23 January 2026 (UTC)

@Graham87 As computer programmers say, "that's just an implementation detail". The page could do the same query that DreamRimmer did, and show the result... David10244 (talk) 01:22, 26 January 2026 (UTC)

@David10244: Nope, it couldn't. That query took 20.23 seconds to execute, as you can see on its page. That is far far too slow for a constantly updating query on a page that's viewed, at the very least, hundreds of thousands of times a day. The query could be done once and cached, like some special pages such as Special:Mostrevisions, but that would make it the odd one out out of all the other values displayed at Special:Statistics, which are dynamically generated. Graham87 (talk) 01:45, 26 January 2026 (UTC)

@Graham87 Well, that does make a difference! David10244 (talk) 04:30, 29 January 2026 (UTC)

Display of math.../math

When I enter the following indented line of Wiki markup:
    :The sum of <math>x</math> and <math>y</math> is written as <math>x+y</math>.
I expect it to be displayed on a single line, looking more or less like

The sum of x and y is written as x + y.

Instead, I get something displayed across 7 lines:

The sum of

x

and

y

is written as

x + y

.

This used not to be the case. Something changed. I do not think it was an improvement.  ​‑‑Lambiam 14:24, 24 January 2026 (UTC)

It's displaying properly in one line for me (when one uses the actual math tags, like so:

The sum of $x$ and $y$ is written as $x+y$.

which the above does not). —Cryptic 15:03, 24 January 2026 (UTC)

@Cryptic It's all new lines on mobile, https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&mobileaction=toggle_view_mobile. Ponor (talk) 15:19, 24 January 2026 (UTC)

That link still works for me on every desktop browser I have installed, but it does linebreak on my phone (whether in mobile view or desktop). —Cryptic 15:28, 24 January 2026 (UTC)

Looks like the Math extension has CSS to set the width of inline-math inside a <dd> to 100% width if the viewport is less than 1120 pixels wide. There's a comment referring to phab:T201233. It seems the intent is to scroll just the equation when people write wikitext like

Some text
: <math>some long equation</math>
More text

(rather than using <math display=block> to format the equation as a block) instead of having the whole page have to scroll, and the people involved didn't consider how it would affect other cases like the one here. Looks like this was just merged on the 17th, so a complaint there might get attention. Anomie⚔ 17:55, 24 January 2026 (UTC)

phab:T401047 is another flavor of the problem, apparently. Izno (talk) 17:58, 24 January 2026 (UTC)

As a side note, you shouldn't use : to "indent" lines in articles. Use template:block indent or <math display=block>. ~2026-52837-0 (talk) 22:01, 24 January 2026 (UTC)

The problem should be considered as a bug. Because it appears even if : is used correctly as in a Description list. For example, the Group (mathematics)#Definition looks terrible on narrow displays. Rigormath (talk) 10:00, 25 January 2026 (UTC)

Viewing this page with Firefox on a fairly wide screen, I see the sentence just below the heading Associativity neatly on one line when (at that zoom level) the line itself, including the indent and the full stop, measures 337 px while the available linewidth is 2136 px. (These measures are plus or minus a pixel or two, since I cannot see the virtual boxes around each individual character.) But when I resize the window so that its width is even one pixel less, the same sentence gets splayed across nine lines. This is surely a bug; the sentence would still fit six times in the available linewidth. I think this bug was introduced after 13 January, since I think I would have noticed it then when previewing this edit.

There is a curious, probably unrelated bug, which seems to be specific to {{tmath}} being used: when the line is broken all punctuation in the sentence is no longer displayed.  ​‑‑Lambiam 10:44, 26 January 2026 (UTC)

The issue was "resolved" today. But now there is an opposite problem. If a formula is rendered using <math display=block>, there are no more additional line breaks before and after it on narrow displays. Rigormath (talk) 13:21, 29 January 2026 (UTC)

"You have a new talk page message" message

Tracked in Phabricator
Task T415472
Resolved

Resolved

I notice today that the "you have a new talk page message" notice on the top of the page when there's a message no longer has the yellow-orange background but is just plain text? - The Bushranger _{One ping only} 01:29, 25 January 2026 (UTC)

Indeed. What happend to the orange bar, which helps an editor know a talkpage contact, from a revert, etc? GoodDay (talk) 04:57, 25 January 2026 (UTC)

Vector22 does not have the orange bar, and I'm fairly certain was removed at some point in Vector as well, at least for logged in users (yes, see Help:Talk pages#You have new messages). Do you have a script enabled or are you using a different skin? Izno (talk) 07:07, 25 January 2026 (UTC)

Why the change though? GoodDay (talk) 15:17, 25 January 2026 (UTC)

Can't say without an answer to the question. Izno (talk) 17:31, 25 January 2026 (UTC)

I don't think The Bushranger is talking about that, the "You have a new Talk page message" message still exists and they're saying it's not styled. Nardog (talk) 16:13, 25 January 2026 (UTC)

Yes, it does display in the context of notifications, you're right. Has that disappeared for you? Izno (talk) 17:34, 25 January 2026 (UTC)

The orange bar was helpful. Why remove it? GoodDay (talk) 18:58, 25 January 2026 (UTC)

From a quick glance, Monobook simply doesn't match anymore. I believe this was unintentional [IIUC, the code is a spaghetti labyrinth, and breakages like this are easy when trying to fix/standardize related code elsewhere in the labyrinth], as it obviously should still match. I've filed phab:T415472 for the devs to investigate and fix. HTH. Quiddity (WMF) (talk) 21:25, 25 January 2026 (UTC)

@The Bushranger: There is work on a fix but it may take time to be deployed. You can fix it for yourself with this in Special:MyPage/monobook.css (assuming you have MonoBook and don't want to influence other skins):

.mw-echo-alert {background-color:#fc3 !important;}

PrimeHunter (talk) 02:21, 27 January 2026 (UTC)

@PrimeHunter: Thanks for the heads up, and the quick fix! - The Bushranger _{One ping only} 05:18, 27 January 2026 (UTC)

@The Bushranger: About two years ago, I wrote the first version of this rule:

/* make it easier to pick out edits to own user talk page, but only if not yet visited */
li.mw-changeslist-line-watched.mw-changeslist-ns3-Redrose64 {
  background-color: #fef6e7;
  border: 1px solid #edab00;
  color: #000;
}

it goes in either Special:MyPage/common.css or meta:Special:MyPage/global.css. You will need to replace my username in the second line with yours, replacing the space with an underscore. It operates on the list produced by Special:Watchlist, and its effect is to highlight, with an orange border and light orange background, all unvisited edits made to your user talk page. --Redrose64 🌹 (talk) 21:20, 27 January 2026 (UTC)

It's Thursday, and it's now fixed - the orange background returned within the last half hour. --Redrose64 🌹 (talk) 19:46, 29 January 2026 (UTC)

Sub-referencing coming in 2026?

Sub-referencing – example

After a decade or so in development, sub-referencing is scheduled to roll out this year according to meta:WMDE Technical Wishes/Sub-referencing. It's a way to reuse citation with different in-source locations:

<!-- Add the details attribute directly to the <ref> tag -->
<ref name="Miller" details="Page 23.">E. Miller, ''The Sun''. New York: Academic Press, 2005.</ref>

<!-- As a next step, you can add another sub-reference using the following statement: -->
<ref name="Miller" details="Page 48." />

The German Wikipedia article Doris Stockhausen has some live examples of the feature. Rjjⁱⁱⁱ (talk) 20:55, 25 January 2026 (UTC)

Too bad they chose a poor way to do it. After years of prior discussion decided against trying to put wikitext in a tag attribute, they decided to override and do that anyway because VE still doesn't do LDR well. Anomie⚔ 01:50, 26 January 2026 (UTC)

Yeah, their original syntax was lot more flexible. It's the kind of formatting that could have even been expanded down the line to let MediaWiki handle short citations so we could move away from the jigsaw puzzle of templates we have now. It's a step down from that, but I guess a step up from Template:rp. It does mean that we will likely have templates in a new place which any regex will have to take into account, and links to archive in a new place. ESanders (WMF) really improved the reference list on VE and so may have some insight on where the WMF is at in terms of fully implementing list-defined references. Rjjⁱⁱⁱ (talk) 02:00, 26 January 2026 (UTC)

What fresh hell is this? The example article contains apparently valid references like <ref name="Blumröder" details="{{Google Buch |BuchID=3iyv_4s6rY4C |Seite=74 |Linktext=S.&nbsp;72 |KeinText=ja}}" /> Heaven help us all. – Jonesey95 (talk) 02:38, 26 January 2026 (UTC)

Just to be clear: That's how sub-references can be used from a technical standpoint. It's based on years of community consultations which made it clear that most editors want the possibility to use templates in sub-references, just like in regular references. There's a simpler example of that use case in m:WMDE Technical Wishes/Sub-referencing#Templates and sub-references. If some wikis don't want templates in sub-references, they could restrict usage in their local citation guidelines.

While we've seen a variety of sub-reference details on German Wikipedia (e.g. book chapters, audio timestamps or quotes), the vast majority of sub-references simply add different page numbers to a re-used reference (<ref name="Miller" details="Page 48." />). The German Wikipedia community decided to replace all instances of {{rp}} with sub-references and proceeded to delete the template afterwards. --Johannes Richter (WMDE) (talk) 11:47, 26 January 2026 (UTC)

Prediction: the community is going to oppose this as it is currently presented, there will be a massively long discussion about rejecting its implementation, there will be a slight numerical majority in favor of rejecting it, it will be implemented anyway, and there will be years of grumbling at places like WP:GAN and WP:DYK whenever it's used. Thebiguglyalien (talk) 🛸 03:48, 26 January 2026 (UTC)

Hi @Thebiguglyalien, could you elaborate on your prediction? Sub-referencing has been a long-standing wish from the global community, appearing many times on the WMF Community Wishlist with lots of support from enwiki community members as well. We've received mixed feedback when we've asked for feedback on English Wikipedia, but mostly due to different preferences in citation styles (e.g. some editors preferring {{sfn}}) – which I don't think is an issue due to WP:CITEVAR. What we've seen on German Wikipedia (our first pilot wiki) is some editors happily converting all of the articles they've created to sub-references while others preferred not to use sub-referencing in "their" articles (or only in certain circumstances) which is fine, sub-referencing is an entirely optional feature. Johannes Richter (WMDE) (talk) 12:12, 26 January 2026 (UTC)

@Johannes Richter (WMDE): I feel like the unsaid collary to We've received mixed feedback when we've asked for feedback on English Wikipedia is "then we ignored the feedback". Case to the point, I can find 0 posts on the Village pumps from team asking for any kind of feedback. For what it's worth, I raised these exact concerns to you and your team back in early Jan following a post/call-to-action on Discord and was met with (to paraphrase) "implementing it in a manner that enwiki would like is too hard at this point" from you/your team... which, sure, I can understand at a technical level, but in that case you should also temper your hopes of adoption/acceptance compared to German Wikipedia where you've clearly made active changes in accordance to feedback. Sohom (talk) 12:59, 26 January 2026 (UTC)

Hi @Sohom Datta, I'm sorry if my comment on Discord came across that way. I was replying to your notice about sub-referencing issues in VisualEditor which were caused by the {{reflist}} template. That's why we first deployed to German Wikipedia where all articles use <references />. As I said on Discord: We are still working on full {{reflist}} support – we won't deploy to projects using {{reflist}} until VE issues with sub-referencing are solved.

What you understood as "too hard..." was probably my comment about Community Wishlist/W18: Make it possible to reuse citations from infobox in VE? That's unrelated to sub-referencing and something we cannot fix as it requires larger improvements to VisualEditor.

I did a quick search myself: Some enwiki discussions on sub-referencing (we also got feedback from enwiki users participating at WikiCite, in our Wikimania 2024 session or on m:Talk:WMDE Technical Wishes/Sub-referencing):

• 2018 (inviting users to m:WMDE Technical Wishes/Sub-referencing/Call for feedback (May 2018) where multiple enwiki users participated)
• July 2024 (community discussion)
• August 2024 (when we were hoping to deliver the feature that year)
• December 2024 (asking for feedback on a new approach in order to avoid technical limitations)
• 2025 (inviting users to sign-up for user testing sessions)

As a response to community feedback, we've changed our initial approach (which was based on list-defined references) to fully support in-line references as well. We've also made changes to sub-referencing workflows in VisualEditor based on feedback from enwiki users during our UX sessions. Johannes Richter (WMDE) (talk) 14:03, 26 January 2026 (UTC)

@Johannes Richter (WMDE) The conversation immediately above it was about Make it easier to use sfn in VE wish. I now see that you reference W18, but that was not what the discussion was about. Given that you responded to me in that discussion, I think it was fair on me to assume that your statement was a broad rejection to work with the community towards W39 as well. Sohom (talk) 14:15, 26 January 2026 (UTC)

Sorry for causing confusing when replying on Discord. It's up to the WMF's Community Tech team (responsible for the Community Wishlist) or the WMF Editing team (responsible for VisualEditor) to decide about W39. Given that the wish is not related to sub-referencing, it's out of scope for my team at Wikimedia Deutschland. The German Wikipedia Technical Wishes survey has concluded that WMDE Technical Wishes will continue working on improvements to references, but we are trying to focus on MediaWiki improvements which benefit all Wikipedia language versions and sfn is only used on a fraction of them. We are considering to pick up WP:VE:NAMEDREFS as a future project, but we cannot make any promises at this point. Johannes Richter (WMDE) (talk) 16:48, 26 January 2026 (UTC)

@Johannes Richter (WMDE) I'm still somewhat confused here, sfns and subreferencing are basically the same thing in that the only difference is that the "subreferences" are in a box outside of the reflist itself. Assuming the community does the work of converting the {{sfn}} templates to use subreferencing, I'm not grasping why you think adding a mode (say <references showsubrefshere="true" /> or similar) that shows the subreferences outside the main reflist to be absolutely outside the scope of the "subreferencing" project . I can understand if the answer is a technical problem, but but we are trying to focus on MediaWiki improvements which benefit all Wikipedia language versions and sfn is only used on a fraction of them alongside the out-of-scope argument does not make sense to me in this context. Sohom (talk) 17:04, 26 January 2026 (UTC)

Sfn is a template created and maintained by the community. Some Wikipedia language versions have copied the template ore created similar ones, others didn't. Sub-referencing is an addition to mw:Extension:Cite to allow re-using references with different details without relying on templates or other community built workarounds. The MediaWiki solution also allows improving Reference Previews and the mobile reference pop-up when citing sources with different details (compare these screenshots with sub-referencing (desktop / mobile). We are aware that sfn addresses the same problem as sub-referencing, but we are are now able to offer a solution for all wikis which works equally well in Wikitext and VisualEditor.

Regarding <references showsubrefshere="true" /> (separating sub-references from the main reflist): That's not what W39 is about? If that's what you've been asking about, I apologize for not understanding your wish previously. We are currently thinking about improvements to the reference list design, I will relay your feature request to our team. Johannes Richter (WMDE) (talk) 17:44, 26 January 2026 (UTC)

@Johannes Richter (WMDE) Isn't <references showsubrefshere="true" /> the only major (presentation-level) difference with the {{sfn}} templates? I'm not asking you to support specifically the underlying technology behind {{sfn}} but rather allow the community have a path towards being able to convert the sfns to use the sub-references feature. The community can take the {{sfn}} template, gut the internals and make it so that we can get <ref name="Miller89" details="[[#CITEREFMiller89|Miller, 1989]], p 2" /> as the output of the sfn template. This alongside list defined references should effectively make {{sfn}} work on Visual editor? (provided we have <references showsubrefshere="true" />)? I recognize that there might be some additional trickery required to get the name of the reference to match up but I don't think what I am saying is necessarily too far fetched/completely unimplementable (or alternatively completely out of scope) Sohom (talk) 18:16, 26 January 2026 (UTC)

Sub-referencing relies on regular references (<ref>...</ref>) to provide the main information, sfn relies on sources listed in the bibliography section. I agree that there are similarities on the presentation-level, but less once you consider using sub-referencing with non-book sources or details other than page numbers (see e.g. de:Ophiuride#Einzelnachweise or other examples listed in this report) where you probably wouldn't want to separate main and sub-references in the reference list. I have noted your wish, as I said we will take a look at it while investigating improvements to the way sub-references are displayed in the reference list. Johannes Richter (WMDE) (talk) 18:48, 26 January 2026 (UTC)

@Johannes Richter (WMDE): I offer NBR 224 and 420 Classes as an article that uses {{sfn}} for all refs, whether book or otherwise; whether paginated or otherwise. --Redrose64 🌹 (talk) 23:33, 26 January 2026 (UTC)

Thanks for sharing! Perhaps I'm not missing something, it seems to me all sfn in that articles are book sources? But it's interesting to see the separation of sfn from other <ref> using reference groups, I was mainly familiar of reference sections mixing sfn and non-sfn, like in Minerva#References. Johannes Richter (WMDE) (talk) 07:09, 27 January 2026 (UTC)

Most (but not all) are books, and most (but not all) have page numbers. Bird 1899 is a magazine, whilst Yolland & Barlow 1880 is a report, currently available via a website (this one should probably use {{cite report}} and not {{cite web}}). BR Main Line Gradient Profiles: The Age of Steam is a book, but has no page numbers - instead it has identifiers for each of the figures. There may be more than one figure on a page; and there are a few figures that span multiple pages. --Redrose64 🌹 (talk) 22:08, 27 January 2026 (UTC)

I will note that even in April 2025, the same question that I had asked was raised in response to the call for feedback and the approach of the team appears to have been to ignore the feedback. Sohom (talk) 14:18, 26 January 2026 (UTC)

W39 is about making it easier to use sfn in VisualEditor. The question asked in April 2025 was about creating templates (or updating existing ones) to avoid dealing with sub-referencing syntax. That's a community decision which has been answered in this comment (and the discussion which followed).

Personally speaking I don't recommend using wrapper templates to avoid (sub-)reference syntax given the existing issues for VisualEditor. Also creating wrapper templates instead of using MediaWiki reference syntax makes it harder to translate articles to other Wikipedia language versions. That's another reason why some other major Wikipedia language versions avoid any reference wrapper templates. But if communities decide to create such templates for (sub-)references, there's nothing stopping them to do so. Johannes Richter (WMDE) (talk) 17:02, 26 January 2026 (UTC)

I can understand that wrapper templates can cause problems, but even then, it would be better support than the current status quo which makes it sfns invisible to VE users. Sohom (talk) 17:12, 26 January 2026 (UTC)

I understand your wish, but that's something to discuss with the WMF, my team cannot support with that. Johannes Richter (WMDE) (talk) 17:44, 26 January 2026 (UTC)

Johannes Richter (WMDE), thank you for responding. The problem with "optional features" in the WMF world is that they are typically left half-done and buggy, developers move on to other projects, editors will use them in ways that have bugs, and then gnomes need to clean up after the bugs. In this case, the "optional feature" is the Visual Editor and the bug is improper insertion of ISBNs into article text. This bug was reported in 2017 (T174303) and is still not fixed. Articles (and gnomes) are affected by this bug on a daily basis. – Jonesey95 (talk) 13:18, 26 January 2026 (UTC)

Hi @Jonesey95, thanks for raising your concerns. As I said last year our team always takes ownership of the features we're developing (see m:WMDE Technical Wishes for some of our past projects). While we can't promise significant changes once a project has been completed, we always devote time when users are reporting bugs in one of our features and try to quickly resolve them. Johannes Richter (WMDE) (talk) 14:14, 26 January 2026 (UTC)

Don't get me wrong, I think it's great that there's focus on practical features like this. But this seems to be the pattern whenever there's a new development that affects things project-wide and has some significant drawback: the enwiki community inevitably makes the situation into a huge deal (something I'm myself guilty of), but things progress until everyone has to just accept it without any improvement. Sohom_Datta and Jonesey95 have elaborated on this specific example better than I can. Thebiguglyalien (talk) 🛸 15:02, 26 January 2026 (UTC)

I see the concerns, that's why we try to involve community members from many wikis to make sure the feature meets their needs. But we are also aware that citation style preferences vary a lot between different users, that's why we always make it clear that sub-referencing is an optional feature where WP:CITEVAR applies. Our recently published report on three months of sub-referencing on German Wikipedia highlights this as well. Johannes Richter (WMDE) (talk) 18:07, 26 January 2026 (UTC)

We should also probably expect something similar to happen here when it comes to sub-references replacing {{rp}}. They have better accessibility, usability, and flexibility than the superscript page numbers. There is already a discussion at Template talk:Reference page. {{r}} either uses {{rp}} or uses similar formatting. It seems not quite flexible enough to replace shortened footnotes (which were designed after existing citation styles). Rjjⁱⁱⁱ (talk) 02:29, 27 January 2026 (UTC)

I believe that while the original <ref extends=name>...</ref> design would have been incredibly useful, the new <ref details=text>...</ref> has only limited utility. What would it take to get VE fixed and add the old design as an alternative? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:59, 26 January 2026 (UTC)

See m:Talk:WMDE Technical Wishes/Sub-referencing#Request for feedback and m:Talk:WMDE_Technical_Wishes/Sub-referencing#Moving forward with sub-referencing for our thoughts (and responses to community feedback) on using the details syntax. VisualEditor would need significant improvements dealing with templates in order to make the old syntax work with {{reflist}}. That's way beyond the limited resources of our small Technical Wishes team at Wikimedia Deutschland. Faced with the decision to stop working on sub-referencing or change our approach to move around the limitations, we asked for community input and concluded that continuing with the new approach would be better. Johannes Richter (WMDE) (talk) 14:55, 26 January 2026 (UTC)

The usage of {{reflist}} with the |refs= parameter is being phased out to address VE's inability to handle references defined inside templates. See:

• Template talk:Reflist
• User talk:DreamRimmer bot II

How close is VE to being able to implement the original syntax using <references></references>? I think VE cannot add a list-defined reference, right? Rjjⁱⁱⁱ (talk) 15:18, 26 January 2026 (UTC)

We've observed the enwiki discussions to move away from {{reflist|refs=}} which would have been an important step towards implementing the previous approach to sub-referencing. To be honest we didn't believe this could happen anytime soon (but there are also dozens of wikis that would be required to follow enwiki's example...).

VisualEditor's inability to add or remove list-defined references (phab:T356471) appears to be harder to solve than we immediately thought (trying to make VE remove list-defined references from the reference list once they are no longer used in the article immediately lead to issues with other templates phab:T356471#11175220 / phab:T404421). That's another reason why moving to a sub-referencing approach which properly works with in-line references was a good idea. Johannes Richter (WMDE) (talk) 16:13, 26 January 2026 (UTC)

We're bot-removing all the simple ones. {{refwidth}} should help with the rest. Right now I see it's doing {{refwidth|short}} where it could in theory do {{refwidth|20em}} and be a drop-in replacement though this with a brief css snippet like:

.mw-references-columns { column-width: 20em; }

That's kind of wonky, but would be the quickest way to switch. Rjjⁱⁱⁱ (talk) 16:52, 26 January 2026 (UTC)

How likely is it that someone would use <ref extends=name>...</ref> inside of {{reflist|refs=}} or <references>...</references>? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:31, 26 January 2026 (UTC)

We've seen quite a number of users combining sub-referencing and list-defined references on German Wikipedia, because it makes the main body wikitext less cluttered. Johannes Richter (WMDE) (talk) 16:16, 26 January 2026 (UTC)

Do mean just the base in LDR or also |extends= in the list? I would find <ref extends=foo>...</ref> useful even if prohibited inside <references>...</references> and {{reflist|refs=}}. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:20, 28 January 2026 (UTC)

Perhaps I misunderstood your initial question, are you asking about inserting a sub-reference in the reference section?

The previous extends syntax was based on the concept of always using list-defined main references. There was no way of using "extends" in combination with in-line references (which is what <ref name="XYZ" details="p. 123">Main information</ref> allows you to do) unless you wanted to use the main reference without details in the article text at least once. We could not find a reasonable way to move forward with "extends" given VE's issues with {{reflist|refs=}}. Using a different way of connecting main- and sub-references, we've reduced the technical challenges for VisualEditor and allowed using sub-referencing with both LDR and in-line references.

When comparing our initial "extends"-syntax with the one we've chosen now, some editors mention that it feels unusual to place content within a reference attribute (details="..."), but the same concept already exists for other features as well, e.g. galleries (<gallery widths="90" heights="90" caption="San Francisco">) or maps (<mapframe width="90" height="90" text="San Francisco" />) and is just as easy to use. Johannes Richter (WMDE) (talk) 16:24, 28 January 2026 (UTC)

I'm quite positive on this, despite the changed design. Why the hover-panel still has such large white space I do not know, but all the relevant information does seem to appear on the hover-panel, which is a very positive change on existing options. CMD (talk) 14:38, 26 January 2026 (UTC)

Thanks, we are currently looking at UX improvements in Reference Previews and the way sub-references are displayed in the reference list. Some of our early designs include ideas to remove some of the white space. We will reach out to communities in the near future to get some input. Noting that enwiki uses ReferenceTooltips as a default gadget, we will reach out to communities providing help on how to update the gadget once we're moving closer to rolling out sub-referencing to wikis where Reference Previews is not enabled by default. Johannes Richter (WMDE) (talk) 15:16, 26 January 2026 (UTC)

Request for Lua/template coding help

Presently, when {{GHS phrases/list all}} has |setid=P the table it produces begins from P103 rather than P101. I've been trying to figure out why, but have been unsuccessful. The template pulls its data from Module:GHS phrases/data which straightforwardly just lists all the entries in order. The entries for P101 and P102 don't appear to be in anyway different from P103, so I don't think the data module is to blame (though I may be wrong).

That suggests the problem is with Module:GHS phrases which {{GHS phrases/list all}} invokes to generate the table. I've looked at that module, but I don't see a difference between what it does for H phrases (invoked when |setid=H) and what it does for P phrases (invoked when |setid=P), so I'm unsure why the template is only fails to start from the beginning of the list for the P phrases. Can anyone here help with fixing this? – Scyrme (talk) 17:49, 26 January 2026 (UTC)

(Originally posted this over at Wikipedia:Help desk and another editor suggested I ask here.) – Scyrme (talk) 17:49, 26 January 2026 (UTC)

@Scyrme Haven't looked at the code in detail, but dictionaries in Lua are explicitly unordered. The terms may sometimes be returned in order, but there's no guarantee. You'd need to have the code extract the keys to an array, sort the array, and then use the array to access the dictionary. --Ahecht (TALK
PAGE) 20:55, 26 January 2026 (UTC)

Sorry, I'm not well versed enough in programming to fully know what that means or how to implement it. What I understand from you've said is that the order in the entries in the data module (the dictionary) isn't necessarily the order the data will be presented in by the template. That's something I already knew, since the section for the listAll function described in Module:GHS phrases helpfully included this comment: Intermediate table t2 to maintain order; read from original table (/data). Unfortunately, the code that comment describes is beyond me. Module:GHS phrases was programmed by another editor who understands programming much better than I do; unfortunately they've been banned so I can't ask them about what it means or why it may not be functioning as intended.

If the purpose of the code is, as the comment says, to maintain the order of the data, it seems to do that successfully since the phrases in the template-made table are in the correct (numerical) order. The problem isn't that P101 and P102 are in the wrong position; they just aren't in the table at all. They're missing. – Scyrme (talk) 21:47, 26 January 2026 (UTC)

@Scyrme I think that code to create t2 is drastically overcomplicated and prone to accidentally overwriting values. I suppose they were trying to save time by having the list start mostly sorted, but the performance difference is likely minimal. I simplified it at Special:Diff/1335018456. Does Module:GHS phrases/sandbox work properly? --Ahecht (TALK
PAGE) 22:37, 26 January 2026 (UTC)

Thanks for taking a closer look! Your version seems to work as intended. The P-phrase table produced by {{GHS phrases/list all/sandbox}}, after I set it to use Module:GHS phrases/sandbox, isn't missing P101 or P102 anymore and still lists the phrases in numerical order. However, I noticed that the total count didn't change. That might just be because {{GHS phrases/number of phrases}} was always working correctly and wasn't missing anything anyway. I'll have to take a closer look later when I have a bit more time to make sure the count is correct, but assuming it checks out your version seems to work well, thanks!

By the way, do you know if it's possible to automatically subset the list of entries in the data module? Like instead of listing all the P-phrases, it would list only the ones within a certain numerical range, such the range from P200 to P299. If so, would the method work even if the range has gaps (eg. P274 to P279 don't actually exist)?

This would be helpful in automating the lists at GHS hazard statements and GHS precautionary statements so they're consistent with what's used throughout Wikipedia in the infoboxes of articles for chemicals and no longer have to be manually updated in addition to Module:GHS phrases/data, while still preserving the structure of those articles as they presently are. – Scyrme (talk) 23:19, 26 January 2026 (UTC)

@Scyrme I added "min" and "max" parameters to the sandbox that should do what you want. I'm not that familiar with all the things that that module does, so please test it out to make sure that nothing else if broken, and if so I can copy it to the main module. --Ahecht (TALK
PAGE) 15:33, 27 January 2026 (UTC)

It appears to work perfectly! Lists everything within the range even when the range has discontinuities and handles the predefined combinations like "H302+H312+H332" appropriately. I also checked the count when listing all the H/P phrases, and they matches the count given by {{GHS phrases/number of phrases}}.

The only problem is that the min/max parameters only apply to {{GHS phrases/list all}} not {{GHS phrases/number of phrases}}, so when |min= and |max= are used the count is still given for the full list, not the subset. Can function r.numberOfPhrases(frame) in Module:GHS phrases also be changed to count the range between mix/max values? – Scyrme (talk) 20:03, 27 January 2026 (UTC)

@Scyrme I think I fixed that in the sandbox. Give it a shot. --Ahecht (TALK
PAGE) 14:57, 28 January 2026 (UTC)

Seems to work flawlessly so I imported the changes to the main module. So far everything is still functioning as intended. I'll start updating the relevant templates/documentation. Thanks so much! – Scyrme (talk) 15:57, 28 January 2026 (UTC)

Edits to watched article not appearing on watchlist

Tracked in Phabricator
Task T364245

I've noticed that edits from one article placed on my watchlist, Almohad Caliphate, are not currently appearing on my watchlist, even after updating. As far as I know, I haven't changed any settings recently. Any insight on what could cause this? Thanks, R Prazeres (talk) 00:53, 27 January 2026 (UTC)

The most recent edit is missing for me, too, almost certainly because of phab:T364245. If I check "Expand watchlist to show all changes, not just the most recent" at least some earlier edits appear. Suffusion of Yellow (talk) 01:35, 27 January 2026 (UTC)

Thanks for looking. I'm not familiar with the technicalities of what you linked, but I did notice that the most recent edit at that page ([3]) is now appearing in my watchlist. R Prazeres (talk) 18:52, 28 January 2026 (UTC)

Redlinked template weirdness, again

The latest run of Special:WantedCategories features an oddity where 18 pages have somehow been "filed" in a redlinked Category:Category:Templates with TemplateData errors instead of the existing Category:Templates with TemplateData errors — so obviously somebody made a typing error somewhere in a recent edit that caused the superflous double "category", but it's a "templates calling other templates and/or modules that are transcluding the bad category from somewhere other than the impacted page itself" thing again, so I'm struggling to find where the error is in order to fix it. I have tried Special:ExpandTemplates, and I did find a "Category:Category:" in the result, but it's such a WALLOFCODE that I don't have the slightest clue how to determine what specific template or module it's coming from. So could somebody with more skill at this kind of thing find where the wrong category name is coming from and put it back to the correct one? Thanks.

Also, there were several "YYYY in Scotland" categories that were populated solely by the eponymous YYYY in Scotland articles and nothing else — a CFD discussion recently upmerged them to the decade level on small-size grounds, but as the categories were being autogenerated and transcluded by the {{Year in Scotland}} infobox template, I had to manually wrap that in {{suppress categories}} on each individual page to make the redlinks go away. So could somebody with more skill in template coding than I've got edit {{Year in Scotland}} to put an #ifexist condition on its categories, of the "use '[Year] in Scotland' only if it actually exists, and use '[Decade] in Scotland' if the year doesn't have its own category" variety? (For the record, these were all from years before the unification of the United Kingdom, so "Year in the United Kingdom" isn't an automatic substitute for Scotland in all cases.) Thanks. Bearcat (talk) 18:01, 28 January 2026 (UTC)

I may have fixed the first issue here. Pinging @RogueScholar to be sure — Martin (MSGJ · talk) 18:15, 28 January 2026 (UTC)

Yep, that was almost certainly it, because doing a null run on the redlink cleaned the contents out. Thanks! Bearcat (talk) 18:26, 28 January 2026 (UTC)

(edit conflict) Fixed {{Year in Scotland}}. The template already unconditionally added the decade category so it didn't need to be added. Sorry, this is my fault. I checked several other countries that were part of the the same speedy merge, and all of them did use ifexist checks, so I got complacent and assumed they all would use ifexist checks. * Pppery * _{it has begun...} 18:26, 28 January 2026 (UTC)

No worries. As long as we got it fixed, it's all good. Bearcat (talk) 18:37, 28 January 2026 (UTC)

Hi, y'all, hopefully this link can help...?
Search 'Category:Category:' in articles and templates
--CiaPan (talk) 18:56, 28 January 2026 (UTC)

History management for a potential merge/split/delete

Hello all. There is a discussion happening on WT:LING about Indo-European sound laws. I am trying to gather support to collapse this functionally unreferenced page into a redirect to Glossary of sound laws in the Indo-European languages and take whatever's worth salvaging over to Proto-Indo-European phonology (also not in great shape). In the event we do end up salvaging something from the page, my question is how we should go about performing such a change while preserving the authorship per WP:HM. While it seems similar to the Military of Japan example, there are substantive differences I don't know how to handle (or whether I can as a non-admin) since the merge would not go to the page the redirect would target. If we decide nothing on the page is salvageable and decide to simply redirect it, do I need to nominate it through AfD or can I just be bold, delete everything, and turn it into a redirect? Thanks in advance. ThaesOfereode (talk) 23:16, 28 January 2026 (UTC)

You cannot history merge here. See WP:Parallel histories.

If you incorporate text into another article you must attribute that text (in one of several locations, my preferred is the edit summary). See WP:Copying within Wikipedia. If you do not incorporate text, you may do whatever you want with the old page. Izno (talk) 23:47, 28 January 2026 (UTC)

Fantastic. Thank you for the assist! ThaesOfereode (talk) 00:00, 29 January 2026 (UTC)

200% Zoom & sidebar appearances

Due to my wonderful eyesight? I use 200% zoom for my text. Now, under "my preferences/appearances", how do I get sidebars to appear smaller? GoodDay (talk) 00:48, 29 January 2026 (UTC)

Related:

• User talk:Robminchin#Image sizes - 23:20, 28 January 2026 (UTC)
• Wikipedia talk:Manual of Style/Images#Image sizes & zoom - 23:22, 28 January 2026 (UTC)
• Wikipedia talk:WikiProject Olympics#c-GoodDay-20260128232600-RfC on the placement of 2026 Winter Olympics and similar templates - 23:26, 28 January 2026 (UTC)

There seem to be others. --Redrose64 🌹 (talk) 00:09, 30 January 2026 (UTC)

I suggest trying a different skin. Go to Preferences - Appearance and choose "Vector legacy" (then remember to scroll down and click Save) to see if that helps things. It should make the content column of articles considerably wider than the default in Vector 2022. – Jonesey95 (talk) 01:13, 30 January 2026 (UTC)

Gave it try, but it changed the appearance of the page in a undesirable way. I just don't understand how the sidebar can go from normal width at 175% zoom, to near the entire article width at 200% zoom. GoodDay (talk) 04:52, 30 January 2026 (UTC)

Is it undesirable, or just unfamiliar? You will probably have to compromise somewhere. You might get used to it. Does the sidebar still take up the whole width of your browser window at 200% zoom in Vector legacy?

I don't understand what your screen is doing either. I am unable to reproduce the issue at 2026 Winter Olympics. When I go from 125% to 133% in the Brave browser (logged out), the side rails automatically disappear, making more room for the content. At 200%, the article prose is 863 pixels wide and the sidebar is 510 pixels wide. My entire browser window is just 1450 pixels wide, not including the scroll bar; I have a 14-inch laptop. – Jonesey95 (talk) 06:24, 30 January 2026 (UTC)

Yup under "Vector legacy" at 200% zoom, the sidebars stil are as wide as the article. GoodDay (talk) 15:34, 30 January 2026 (UTC)

Must be because I now have a laptop. GoodDay (talk) 04:29, 1 February 2026 (UTC)

Preference has something there for changing the size of images and thumbnails, but nothing there for changing the size of sidebars. GoodDay (talk) 04:41, 1 February 2026 (UTC)

This could be down to how the browser is formatting the page. At some point the the sidebar and text are to squashed, so the text is being moved down and once that happens the sidebar expands into the space that the text has vacated. Moving from 175% to 200% must be stepping over that tipping point. -- LCU ActivelyDisinterested «@» °∆t° 21:49, 1 February 2026 (UTC)

Yup, the dividing line is between 175% & 200%. GoodDay (talk) 21:59, 1 February 2026 (UTC)

Template problem: Signpost draft

I have to say, I'm absolutely clueless when trying to track down problems with templates. Anyway, I awoke this morning to find that nearly 200 pages had popped up in Category:ParserFunction errors. They all seem to involve the use of Template:Signpost draft, and the ParserFunction error is in the "deadline" box at the bottom; but that template hasn't been edited since September of last year, so it's probably not a problem with the template itself. Could it be related to the fact that the new Signpost just came out? Any help? Deor (talk) 17:08, 29 January 2026 (UTC)

Sometimes changed software upstream can cause what appear to be innocent revisions of templates to stop being innocent many months after the fact. This is most common with error categories that we use, but can also apparently affect categories created by upstream processes. Izno (talk) 17:34, 29 January 2026 (UTC)

It does look like a template issue. It is not correctly accounting for the fact that the Signpost deadline may hit so causing the Template:Percentage bar template to have to process a division by zero. JPxG can perhaps sort out where that's being used and subsequently use the correct day or fix it so it cares about division by 0 (namely, that it's time to have a new Signpost out, I guess!). Izno (talk) 17:37, 29 January 2026 (UTC)

Template:Signpost/Deadline has caused this problem in the past when the deadline has been in the past. My workaround has been to push the deadline a couple of days into the future. The template should really capture this issue (deadline in the past instead of the future) and display something friendly rather than a bold error message. Anybody want to track down the relevant code? – Jonesey95 (talk) 17:49, 29 January 2026 (UTC)

Likely because I did not yet update it to the next issue deadline. It also behaves strangely around the time of publication, so maybe some fix would be nice, although I cannot commit myself to this. jp×g🗯️ 18:20, 29 January 2026 (UTC)

"hist" changed to "history" in interface

Tracked in Phabricator
Task T244411

phab:T244411 changed MediaWiki:Hist from hist to history. Apparently they only thought about RecentChanges which already said "history" when grouping edits by page (MediaWiki:Enhancedrc-history), but MediaWiki:Hist is used in other places like contributions. There are already objections and I predict it will be reverted globally but we could also revert it locally right away by creating MediaWiki:Hist with the text hist. PrimeHunter (talk) 21:55, 29 January 2026 (UTC)

Does it cause any actual problems? I thought it looked funny at first but I can't say I really care either way. --Trovatore (talk) 22:01, 29 January 2026 (UTC)

Many users hate bad unnecessary changes no matter how small. I anticipate protests, maybe more peaceful than rioting in the streets, but I thought we might just change it to avoid trouble. PrimeHunter (talk) 22:11, 29 January 2026 (UTC)

Three extra letters on every line take up valuable real estate in space-wasteful skins like Vector 2022. Me? I use MonoBook, but the extra letters are still noticeable. --Redrose64 🌹 (talk) 22:16, 29 January 2026 (UTC)

I mean, it does have the advantage of being an actual word. Histogram? Histamine? Nothing else makes much sense, but if you see "history" you don't have to think about it. I'm basically neutral; carry on. --Trovatore (talk) 22:46, 29 January 2026 (UTC)

Looks like a reversion has already been merged. Nardog (talk) 23:00, 29 January 2026 (UTC)

Since it's already reverted in Gerrit, I went ahead and temporarily created MediaWiki:Hist so we don't have to wait for next Thursday to get it fixed here. Anomie⚔ 01:23, 30 January 2026 (UTC)

I will have to put away my pitchfork then...rats. I don't like change just for the sake of change either, PrimeHunter. I can relate. wikt:if it ain't broke, don't fix it and all that. Thanks Anomie. --TheSandDoctor ^Talk 01:24, 30 January 2026 (UTC)

How do I suggest a domain be added to a spam blacklist?

We've had a few attempts to add links to the site chess.game to our chess articles. Even if you know little or nothing about chess, a quick look at that site will confirm that the content is garbage, ungrammatical and error-ridden, and likely generated by AI. If we can add that domain to a spam blacklist to be automatically reverted by a bot, that will save us some time at WikiProject chess. MaxBrowne2 (talk) 23:26, 29 January 2026 (UTC)

@MaxBrowne2 You can put requests for the blacklist in at MediaWiki talk:Spam-blacklist Andrew Gray (talk) 23:30, 29 January 2026 (UTC)

adding meta tag to some pages headers

hello all.

came here to ask something that stems from a discussion in another wiki.

the discussion had to do with sexually explicit content (such as photos and/or drawings) which are considered to be "not fit for children". i dug a little and discovered that html gods did create something: specifically, there is a "rating" meta tag which, supposedly, can tell things like filters to refuse to display some pages. the idea is that the concerned parent will not be "forced" to block WP from their younglings completely, but will prevent them from getting the content and presumably search engine hits on some pages the community agrees are too explicit.

after the long forward, a short question: is there a way to define "meta rating" for a page? i know that it's possible to define some other meta attributes, such as "noindex" and "nofollow", but i do not know about "rating".

peace. קיפודנחש (aka kipod) (talk) 18:05, 30 January 2026 (UTC)

No, there's not. Izno (talk) 18:30, 30 January 2026 (UTC)

@קיפודנחש: Please see Wikipedia:Content disclaimer. --Redrose64 🌹 (talk) 19:07, 30 January 2026 (UTC)

thanks, both. that's too bad. maybe i'll add something to "community wish-list" - i think it makes at least as much sense as the "noinded" magic word.

the disclaimer is irrelevant to my question - you don't have to tell me that WP contains content which may be objectionable - i know that and have no problem with it.

the fact that such disclaimer is even exists kinda corresponds with my question - one way to look at "mata rating = <whatever>" is as an extra disclaimer that's relevant to some specific pages, which is "stronger" than the general content disclaimer of the whole site (let alone the fact that the disclaimer on enwiki is not relevant to other wikipedias...)

peace. קיפודנחש (aka kipod) (talk) 19:39, 30 January 2026 (UTC)

Some MediaWiki extensions like mw:Extension:MetaMaster can do it but they are not installed here and I doubt there would be support for it. We have editors from around the World. Countries and editors have different standards. PrimeHunter (talk) 21:33, 30 January 2026 (UTC)

i dug a little and discovered that html gods did create something I don't see any "rating" defined at https://html.spec.whatwg.org/multipage/semantics.html#standard-metadata-names. Are you sure it was really the html gods and not some pretender to that status? 😉 Anomie⚔ 22:11, 30 January 2026 (UTC)

Presumably from other-metadata-names which links to MetaExtensions at wiki.whatwg.org, which does have such a meta name. The existing support for it... does not look like it would support our use case in the slightest, which would certainly require greater fidelity than "everything on this page should be off limits to anyone of any age young than age of majority". Even if there were social desire to do something like that. Izno (talk) 22:46, 30 January 2026 (UTC)

I'd also separately guess that setting your meta name to that value would tank any SEO whatsoever for the audience we as Wikipedians wish to reach, which is most often the age group for which it would be restricted. We don't know how the sauce is made, but I imagine if there's a meta name like that one, search engines are listening for it. Izno (talk) 23:06, 30 January 2026 (UTC)

With a very quick search, all I found was a non-standard rating metadata name (I believe the same one to which Izno alludes). It only has two values defined, both synonymous and used by search engines to identify adult content (apparently all the adult web sites use it). There are no other rating values defined that are used by the largest search engine, Google. Unless there is some standardization, and sites that actually follow the standard, there isn't much incentive for someone to write, say, a browser plugin to filter page access using rating values in the meta data. isaacl (talk) 03:43, 31 January 2026 (UTC)

Visual editor citation errors - not reproducible

I have been having a number of visual editor errors in recent times, I am not sure what the exact scenario in which it happens but I can explain a bit of my usage pattern. I sometimes format a <ref>{{cite ...|. ...}}</ref> string in a text editor and then copy and paste it into the visual editor, this used to work fine but in recent times I find that this results in some pre-existing nearby citation going into "[undefined]" and two citations becoming identical copies. I am not sure if there is some other gadget or preference that may be causing the problem and I do not have a perfect demonstration of the issue. I now avoid the issue by first switching into source editor before the paste and then switching back to VE. Shyamal (talk) 03:10, 31 January 2026 (UTC)

Archive search boxes not limiting search scope

At Talk:Turkey and Wikipedia talk:WikiProject Guild of Copy Editors, the archive searches aren't confining searches to the archive root. Largoplazo (talk) 10:49, 31 January 2026 (UTC)

• Strange. They both work correctly for me. (Just in case, Win11, Firefox 147.0.1). Black Kite (talk) 10:54, 31 January 2026 (UTC)

  I'm realizing what happened. On my phone, I'm entering a word in the field. The auto-complete list comes up. But it isn't the sort of list where it inserts your choice into text field and let's you proceed. It's the page title auto-complete, and when you touch one of the choices, it pulls up the page rather than inserting it into text field so you can perform the search you want to do. It's a usability snag. Considering it's a free-form search field, perhaps the autocomplete attribute should be off. Largoplazo (talk) 11:32, 31 January 2026 (UTC)

Problem with latest AfD page

The latest AfD page at Wikipedia:Articles_for_deletion/Log/2026_January_31 seems to somehow be getting screwed up by the WP:DELSORT/FICT page which is transcluding some odd headings onto the page. My recently-created AfD has been shoved into a heading titled "Fictional element Proposed deletions" for example, despite neither being about fiction nor a PROD. Athanelar (talk) 11:01, 31 January 2026 (UTC)

• Caused by these two edits by Cyberbot_I (which I've reverted). I've reported it, but User:Cyberpower678 has only edited once since December. Can anyone work out which task it is on User:Cyberbot_I? Black Kite (talk) 11:15, 31 January 2026 (UTC)
  • Looks like the underlying cause is that Wikipedia:Articles for deletion/List of fictional diseases (4th nomination) had an unconditional Category:AfD debates (added in Special:Diff/1335816528) which is causing the list pages to be in the category that's supposed to indicate an individual AfD. I removed that in Special:Diff/1335844693, so hopefully the bot won't be confused anymore. P.S. The task appears to be "AfDBot". Anomie⚔ 14:56, 31 January 2026 (UTC)

Template problem: Ibadism

Hi, I hope you’re doing well.

In the Template:Ibadism, there seems to be a problem that I couldn't figure out.

In this article, for example, when the template is added, we get an extra white space between the two template: Ibadism and Rustamid dynasty topics. If anyone can fix it, I would be grateful.

Regards, Riad Salih (talk) 13:19, 31 January 2026 (UTC)

@Riad Salih: Fixed by removing white space from the template. -- John of Reading (talk) 13:22, 31 January 2026 (UTC)

@John of Reading thank you ! Riad Salih (talk) 13:32, 31 January 2026 (UTC)

This is covered at WP:NOINCLUDE - first paragraph after the table, beginning "Perhaps the most common ..." --Redrose64 🌹 (talk) 16:35, 31 January 2026 (UTC)

Incorrect redirect? Disk_image", "Optical_disc_image" and "Optical_disk_image".

Hi,
From what I read in the Wiktionary, Optical_disc and Optical_disk are approximately synonymous with Optical_disc the preferred spelling in some cases.

Here (w:) Optical_disk_image redirects to Disk_image but should redirect to Optical_disc_image.

Objectionable? Can someone correct the redirect? Or give a link to instructions for changing a redirect.

Thanks, ... PeterEasthope (talk) 22:41, 31 January 2026 (UTC)

I went ahead and changed the target for optical disk image to optical disc image as it seems likely to be uncontroversial. The article optical disc image includes a link to the original target, disk image, in the first paragraph so if anyone were looking for that article they'd still find it.

For future reference, if you click on a redirect there'll be a little notice at the top of the page saying where you were redirected from with a link. If you click that link, it'll take you to the page for the actual redirect without redirecting you. You can edit the page like a normal article. All redirects follow the same format; they start with the text #REDIRECT followed by a link to the target of the redirect. You can change the target by replacing that link.

However, you should only change the target if you're sure the change won't be controversial. If it's controversial or you're not sure if it would be controversial, you should instead list it at WP:Redirects for discussion. That page has instructions for how to start a new discussion. – Scyrme (talk) 23:13, 31 January 2026 (UTC)

Good. Big thanks for the detailed explanation.

... PeterEasthope (talk) 00:10, 1 February 2026 (UTC)

What is the logic archiving unresolved talkpage topicstarter?

Archiving some discussions if a talk page gets to big seems okay (i would prefer pagination) but i now see a bot killing the talk. What is accomplished with this? I couldnt even find the archives on mobile. I know one can "endlessly" reinsert an archived discussion back into the talk page but it feels like doing something naughty.

Can we at least keep a few kb of discussions? The blanked talk page isnt inviting. You know, my proposal was probably made before? It is in some unfindable place probably without feedback?~2026-69525-0 (talk) 05:20, 1 February 2026 (UTC)

@~2026-69525-0: Please always link any page you post about, or give an example. There can be different archiving instructions but we cannot tell what happens or change it without knowing the page. PrimeHunter (talk) 11:35, 1 February 2026 (UTC)

Please see m:Community Wishlist/Wishes/Do not fully archive unsolved issues on Talk pages (voting open!).

For this and for what you're asking about, one would first need to mark threads as solved so one can identify which threads are unresolved. For this, see m:User:DreamRimmer/WhyNotResolve – I'm surprised it's so far not used here. The blanked talk page isnt inviting. are you talking about a page where this auto-archiving resulted in an empty talk page? I think one can configure the archiving-bot to leave a minimum number of threads on the talk page and you could change the config of the bot at the respective talk page. Prototyperspective (talk) 10:24, 2 February 2026 (UTC)

Diana Rennik

I have been through the coding for this article three times and cannot find the source for that tiny, blurry image in the infobox. Where is it coming from? Bgsu98 (Talk) 08:51, 1 February 2026 (UTC)

• Wikidata. Removed as worse than useless. Black Kite (talk) 09:45, 1 February 2026 (UTC)

  Absolutely worthless. The same at Aleksei Saks. Bgsu98 (Talk) 09:49, 1 February 2026 (UTC)

This was about File:ISU pairs Rennik&Saks-1 beax (cropped) - Diana Rennik.jpg and File:ISU pairs Rennik&Saks-1 beax (cropped) - Alexei Saks.jpg. They were cropped from File:ISU pairs Rennik&Saks-1 beax.jpg and have both been removed from Wikidata now. I don't know Wikidata standards for images but I agree they are too poor for Wikipedia biographies. PrimeHunter (talk) 12:21, 1 February 2026 (UTC)

Comment doesn't work in gallery

Something is strange with comments in gallery tags. First, a gallery tag with one image:

• 
  Auditorium of the Old Burgtheater, 1888–1889, Vienna Museum

Second, the same gallery with the image commented out, but it's still there!

• 
  Auditorium of the Old Burgtheater, 1888–1889, Vienna Museum -->

Third, the same gallery with the image commented out, this time no newline between the open comment markup and image to be commented out, but something on a new line before the close comment.

• File:This is also a comment

It seems that within gallery tags, a newline character ends an open comment. I don't think this is correct. Is it documented anywhere? How long has this been going on? —Anomalocaris (talk) 06:15, 2 February 2026 (UTC)

Possibly related to phab:T18057, looks like HTML comments and gallery tags don't play nice. — xaosflux ^Talk 14:26, 2 February 2026 (UTC)

Flexible number of blocks before Infobox on mobile

Ordinarily, on a mobile device, the infobox appears under the first paragraph. Check out Levansucrase, where what's basically the first sentence consists of a paragraph ending with an indented formula. It'd be ideal for the infobox to be deferred till after the formula. Is there a way to accomplish that? Largoplazo (talk) 06:35, 2 February 2026 (UTC)

@Largoplazo Have you tried making it an inline formula ? —TheDJ (talk • contribs) 15:51, 2 February 2026 (UTC)

Well, that certainly sounds like a valid work-around. But, no, not yet. Largoplazo (talk) 16:11, 2 February 2026 (UTC)

No, there is not a way to accomplish that. You will have to change how you structure your "lead". Izno (talk) 17:44, 2 February 2026 (UTC)

Partially blocked from article space but template showed blocked from creating accounts

see [4] Doug Weller talk 10:24, 2 February 2026 (UTC)

What template did you subst in, the wikitext suggests Template:Uw-acpblockindef was used, and that seems to be the text that is there? — xaosflux ^Talk 14:23, 2 February 2026 (UTC)

See Special:Block/2nightmania Doug Weller talk 16:23, 2 February 2026 (UTC)

Watchlist labels

Hello. Suddenly we've something new. Whe you check your watchlist, a box comes up saying 'create & asign labels'. GoodDay (talk) 15:19, 2 February 2026 (UTC)

Yes, confusing. Doug Weller talk 16:24, 2 February 2026 (UTC)

Adding div.mw-special-watchlistlabels-onboarding { display:none; } in a new line to your common.css page, e.g. this edit, will make it go away. Writ Keeper ⚇♔ 16:28, 2 February 2026 (UTC)

Is there a page that explains labels? I clicked past it because I was looking for a specific thing this morning. Now I don't know what they are or how to use them. I know I didn't ask for it, but they don't care if we ask for "features," so my opinion on that doesn't matter. --Onorem (talk) 16:39, 2 February 2026 (UTC)

There is a help page at mw:Help:Watchlist_labels. William Avery (talk) 17:08, 2 February 2026 (UTC)

Indeed, if you visit the new tab, that help page is linked at upper right. --Redrose64 🌹 (talk) 20:20, 2 February 2026 (UTC)

There's really no need to hide it with CSS. It's just an informational popup that shows up only once. – SD0001 (talk) 20:38, 2 February 2026 (UTC)

First the orange bar notification is taken from us & now this new feature. Who's behind these changes, that nobody asked for? GoodDay (talk) 16:55, 2 February 2026 (UTC)

I can't answer that, but I like this feature. I plan to use it to divide up my watchlist into groups -- articles I'm watching because I worked on them; pages related to the bot I operate; FAC/GAN related pages; and everything else. I didn't ask for this but now I see I think it'll be very handy. Mike Christie (talk - contribs - library) 17:19, 2 February 2026 (UTC)

Multiple watchlists is something that various editors have requested for a long time; see m:Community Wishlist Survey 2017/Watchlists/Multiple watchlists, for instance. isaacl (talk) 17:32, 2 February 2026 (UTC)

without community consent? Features like this one are why we have WP:CONEXEMPT. Please stop complaining here unless you actually have a bug to report. Izno (talk) 17:41, 2 February 2026 (UTC)

I’ve had multiple watchlists for a long time, I forget which script. Doug Weller talk 18:32, 2 February 2026 (UTC)

Make it go away, the feature is useless for me, with more than 10k articles I'm not going to add labels now. fifteen years ago, perhaps. - Walter Ego 18:36, 2 February 2026 (UTC)

Make'em consensus-required. These sudden changes are annoying. GoodDay (talk) 19:15, 2 February 2026 (UTC)

Not having any changes is also annoying. People whining is annoying, people not writing articles is annoying, ppl getting shot in the streets is annoying, deep dish pizza is annoying, my niece is annoying. And that freaking piece of gravel in my shoe right now. I just choose to give priority to just a few and ignore the rest. —TheDJ (talk • contribs) 20:28, 2 February 2026 (UTC)

I for one would be against that, as nothing would ever get done.  novov talk edits 21:23, 2 February 2026 (UTC)

@GoodDay There have been ~200 code changes today (Feb 2). Asking for feedback from the community on all 200 of them in not scaleable in any way shape or form. This is not to mention that asking for community feedback on whether to fix production outages/revert bad code or even (say) translate a part of the language is not beneficial to the community or the developer base.

For what it's worth, this feature is something that the community has been wanting since 2008. There have been entries for it in the 2017community wishlist where it has seen community support and even on the new wishlist the community has shown support for WMF to work on this issue. I understand that you feel frustrated that you haven't been consulted and that your workflow has been impacted (in which case you are free to leave feedback on things that can be fixed) but I don't think the criticisim that the Foundation is adding things without community consensus holds water in this case. Sohom (talk) 23:49, 2 February 2026 (UTC)

We've already had "two" surprises, this new year. I hope we don't have anymore via sudden changes. GoodDay (talk) 23:54, 2 February 2026 (UTC)

I guarantee you that there will be more. Set your expectations accordingly. Wikipedia is always changing, as are most things in life. – Jonesey95 (talk) 00:16, 3 February 2026 (UTC)

All that's really changed is that your watchlist has one extra tab compared to how it was yesterday. You can safely ignore this new tab. The popup tells you about it. To make the popup go away: click Next and then Got it. Job done. --Redrose64 🌹 (talk) 19:23, 2 February 2026 (UTC)

If this is a change "that nobody asked for" then why does WP:PERRENIAL#Multiple watchlists exist? People here on the English Wikipedia have been asking for this since 2008. I for one am already using it. Warudo (talk) 20:28, 2 February 2026 (UTC)

Note that if watchlist filtering doesn't seem to be available and you want to enable it, go to Preferences / Watchlist / Advanced options and uncheck the "Use non-JavaScript interface" option. MANdARAX • XAЯAbИAM 21:51, 2 February 2026 (UTC)

Paging Samwalton9 (WMF) who has provided some updates at Wikipedia:Help desk § Watchlist labels. ClaudineChionh (she/her · talk · email · global) 23:24, 2 February 2026 (UTC)

Additional thoughts: I was aware of this feature being developed though I can't recall where I first saw it, and I certainly didn't know it was going to go live yesterday. I want to suggest that in future, WMF developers put some thought into how new features or other highly visible changes are introduced to this Wikipedia. For example, post a notice on WP:VPT or WP:VPW, with at least 48 hours' notice, ideally at least one week's notice (even power users have days off), outlining the following (one or two sentences per dot point may suffice):

• We're going to roll out (new feature) on (date)
• Why we're doing this
• What this will look like / How this might impact your current workflow
• Link to an up-to-date documentation page on MediaWiki/MetaWiki
• Link to local documentation page that will need to be updated

As someone who IRL has had to introduce new processes into communities of experienced and opinionated people, I get that not every new feature needs community consensus but I'm not surprised there has been pushback here. ClaudineChionh (she/her · talk · email · global) 00:33, 3 February 2026 (UTC)

• Yes, just make it go away until community consensus can be obtained for what seems like a useless box and a major intrusion for tens of thousands of users everytime they look at their watchlist (and no, most won't know to "Keep on clicking until it goes away"). WMF make-work project? Randy Kryn (talk) 00:45, 3 February 2026 (UTC)

  The only thing that's different from my Watchlist view is the addition of a "Manage labels" link next to the "Edit watchlist" link. Besides that new and nonintrusive link, I don't see that anything else has changed...? Some1 (talk) 04:40, 3 February 2026 (UTC)

  He's complaining about the popup box introducing the feature. As Redrose64 said, clicking "next" and "got it" will make it go away. But maybe the devs can add a "dismiss" button on the first popup if some folks find it that annoying. – SD0001 (talk) 06:55, 3 February 2026 (UTC)

I've updated the section header to be more useful, since as pointed out, this was something that many people have been asking for for two decades. Legoktm (talk) 04:28, 3 February 2026 (UTC)

Please remember to leave an anchor when you do this so that incoming links continue to work. I have added one to this section. – Jonesey95 (talk) 06:33, 3 February 2026 (UTC)

Hybrid Search: Phase 1 - Early A/B Experiment on the Android App

Hi everyone,

Following the Phase 0 exploration we shared earlier, we’re moving into Phase 1 of the Hybrid Search project. Now for Phase 1, we are launching a small, time-limited experiment to learn whether hybrid search approaches can help readers find information on Wikipedia more effectively, learning from real Wikipedia traffic.

Phase 0 findings showed that some readers struggle to find specific information using internal search, especially when queries are phrased as questions or natural language. Based on that we decided that a hybrid approach, e.g. a search with both keyword and semantic capabilities, would be worth exploring in an experiment.

The video shows an early stage design for a hybrid search experiment.

This video shows an early stage design for the experiment, with an explainer note to users, letting them know that with this beta feature they can search using natural language. The example here is "cats and dogs comparison," which, when searched, retrieves the standard keyword match results, as well as beta-marked semantic results that surface relevant snippets from articles.

Who is this experiment for?

The Phase 1 experiment will be shown to a subset of mostly logged-out readers on the Android app on English, French and Portuguese Wikipedias. We will update the project page with the precise percentage of users included in the experiment. Editors will not be included in the experiment group at this stage, but can provide feedback through user testing interviews if interested.

What are we testing?

We’re testing a hybrid search approach that combines:

• Keyword-based (lexical) search, which works well for exact titles and names, and
• Meaning-based (semantic) retrieval, which can better support question-style or exploratory searches.

All results shown come from existing, human-authored Wikipedia articles and sections. This work does not involve generating new answers, rewriting content, or summarizing articles.

How will the experiment work?

Phase 1 will run as a controlled A/B test:

• A control group will see the current search experience.
• An experiment group will see semantic results surfaced alongside existing keyword-based results.

Readers will not be asked to choose between search modes. The experience will be clearly labeled as experimental, and readers will have the ability to opt out and continue using the current search experience unchanged.

Search results may include short excerpts, such as sentences or short paragraphs anchored to article sections, with clear indicators showing where information comes from.

How will we evaluate outcomes?

We’ll evaluate a combination of:

• Reader behavior (such as engagement and time-to-click)
• Qualitative feedback
• Performance guardrails, including latency and overall retention

If results show that this negatively affects the reading experience, the experiment will be adjusted or stopped. If results are promising, the findings will inform whether and how this work should continue.

Timing and next steps

Phase 1 is focused on design exploration, technical feasibility, reader insights and early community feedback. The experiment is set to begin in the second half of February and will be live for two weeks. Initial learnings from this work will be shared for discussion in March.

Learn more and stay involved

More details about Phase 1 scope, goals, and evaluation criteria are available on the project page. We’re especially interested in hearing from you:

• What are your overall thoughts on this early design?
• Are there risks or concerns you think we should be paying closer attention to?

We welcome continued feedback and discussion as this work progresses.

Thank you. EBlackorby-WMF (talk) 15:44, 2 February 2026 (UTC)

Looks great, this could be very useful. I wonder if this could also show results about help & meta pages and forward text snippets from these pages. Sometimes I'm wondering about things already answered perfectly well in a 10 year old VillagePump thread or want to find out sth like 'how to easily add a table column' or 'how to make video start at a specific time' and it's not easy to find the info and even more so for newcomers and as by default help&meta pages are not included in the search results. m:Community Wishlist/W442 includes or could inspire further ideas. I like the design but don't like the window that displays before one can search (maybe that's just temporary early on). Prototyperspective (talk) 17:35, 2 February 2026 (UTC)

@EBlackorby-WMF Why is the video using the example query "cats and dogs comparison" that cannot be answered by pulling snippets from random Wikipedia articles, since there is no Wikipedia article comparing cats and dogs? It may be wise to use a better query when presenting an idea for a feature.

Why is the WMF trying to compete with large companies like Google and Meta with a tiny fraction of their resources? They train their LLMs on gigantic amounts of data, including but not limited to Wikipedia, so they will always have a superior product. Which means that I can make a better tool than what you are proposing, simply by using a bit of JavaScript that makes an API call to an external provider.

How will you add value to or improve upon what those multibillion dollar companies do?

Will the improved privacy, control, no dependency on commercial providers, cost at scale or whatever be worth it when you spend a lot of money making something inferior to tools everyone already uses? Polygnotus (talk) 18:24, 2 February 2026 (UTC)

I wonder why you assume this is about competition with "large companies like Google and Meta" and secondly why you seem to support these companies instead of improvements to Wikimedia. Lots of people also search things specifically within Wikimedia or use the Wikipedia search engine so that other content can be found on Google is no reason not to improve the Wikimedia search. This isn't a Web search engine. And there are article sections comparing cats and dogs and it was just an example anyway so if that example is bad that doesn't imply the concept is bad. Asking bonobos vs chimpanzees for example could surface section Bonobo#Cognitive comparisons to chimpanzees for example. Prototyperspective (talk) 18:31, 2 February 2026 (UTC)

@Prototyperspective why you seem to support these companies I dislike em, but they obviously have more resources than the WMF. why you assume this is about competition with "large companies like Google and Meta" because there is a limited amount of people asking questions? This is a zero sum game, there is a limited amount of people asking questions at any given time and if you ask a question to provider X you do not ask that same question to provider Y. And because those companies don't have this self-imposed limitation on not generating new text their answers would obviously be far superior.

why you seem to support these companies instead of improvements to Wikimedia I obviously support improvements to Wikimedia, I made quite a few, but this is just not a great idea. Or at least, in its current form as it is presented in the comment above.

Lots of people also search things specifically within Wikimedia or use the Wikipedia search engine so that other content can be found on Google is no reason not to improve the Wikimedia search. The amount of people who use the Wikipedia search for answers to questions is actually very low, especially when compared to Googles search box. You can just type your question in the address bar of your browser, actually navigating to en.wikipedia.org and then typing a question in a tiny search field is unnecessary and will lead to inferior results.

That doesn't mean I am anti-Wikipedia-Search improvements; I actually want the WMF to improve the fuzzy search stuff.

This isn't a Web search engine. See Knowledge Engine (search engine). Enjoy!

And there are article sections comparing cats and dogs Nope.

it was just an example anyway so if that example is bad that doesn't imply the concept is bad Agreed. But, as I explained, both the example and the concept are bad.

Asking bonobos vs chimpanzees for example could surface section Bonobo#Cognitive comparisons to chimpanzees for example Yeah there are many better queries they could've picked so its weird they used this one to present the idea to the community. If the work does not involve generating new answers, rewriting content, or summarizing articles then what is the point? If you bother extracting data you might as well present it in a useful format, otherwise the user experience is bad. Also if you want people to actually use the wikipedia search boxes, and type entire sentences into them then it may be wise to make them far more prominent and bigger. And sorry for stating the obvious but these 'success' indicators are so vague that it is impossible that this would not be considered a "success". Polygnotus (talk) 18:41, 2 February 2026 (UTC)

but they obviously have more resources than the WMF and… self-imposed limitation on not generating new text their answers would obviously be far superior

no, they wouldn't; at least often not or depending per what the user wants in the particular case if you ask a question to provider X you do not ask that same question to provider Y. flawed reasoning – this isn't so much about where Internet users are searching but primarily about users that are searching Wikipedia. However, unlike you apparently I wouldn't have an issue with more users coming to Wikipedia to search for a larger fraction of their information searches. I made quite a few I know and big thanks for them but as a personal subjective view you seem to be quite upset whenever WMF develops sth innovative and then complain how this should be left to companies or volunteers; maybe this makes sense in some cases but it doesn't feel like you truly reflect (and/or think more deeply) on whether this applies here or there anymore and what the topic beforehand is. I don't see why it wouldn't be a great idea, you certainly didn't explain why. The amount of people who use the Wikipedia search for answers to questions is actually very low …and? Is that a reason to not improve it? And still quite a few are using it. lead to inferior results only for most cases currently so that's not a good reason to not improve it, quite the opposite. See Knowledge Engine (search engine). Enjoy! Wikimedia search isn't the Knowledge Engine and still isn't a Web search engine. Nope What you're criticizing is not the actual subject, but the example selection. Hopefully better example selection next time, fine. But you're still wrong, there are many comparisons between the two on Wikipedia such as in Cat–dog relationship or if somebody improved that promising article, Comparison of sensory perception in species as well as List of animals by number of neurons and as well as the ability to produce amylase, an enzyme that functions to break down carbohydrates into simple sugars – something that obligate carnivores like cats lack in Dog food. Disproven I'd say. Another approach would be to show articles about comparable things of the two, e.g. Domestication of the cat and Domestication of the dog alongside or right after another and then Dog intelligence & Cat intelligence. the concept are bad It's useful to find info that way for lots of people for lots of cases plus lots of people are increasingly used to this type of searching so the search is good to adapt to also show them good results. so its weird they used this one to present the idea it's not always so easy to find or readily think of a good example but this is one where the general idea is easy to understand, whether or not the results in this case are good was I guess secondary to that. Btw, such searches may also make it clearer to editors that certain info is missing in Wikipedia and editors can also use this to check whether some info already is somewhere in Wikipedia or whether there's value in them looking into maybe adding it. and type entire sentences into them that's what users already do and secondly that's what's a type of searching that's easier to many for lots of cases. you might as well present it in a useful format, generated text is prone to hallucinations and inaccuracies, the text snippets approach is great and text responses is something that could be considered in addition (see the wish I linked) but that doesn't make this any less useful. then it may be wise to make them far more prominent and bigger could be considered later but it's not needed to make it bigger and lots of search input boxes also aren't large; it's large enough. Prototyperspective (talk) 19:39, 2 February 2026 (UTC)

no, they wouldn't; at least often not or depending per what the user wants in the particular case Not sure what you mean. Of course a generated text that directly answers a question is superior to two or more snippets of Wikipedia articles.

flawed reasoning – this isn't so much about where Internet users are searching but primarily about users that are searching Wikipedia. LLMs already have a large amount of users and already can be used to extract information from Wikipedia, which is in the datasets they are trained on. You can't convince people to start using Wikipedia search when it offers a far worse experience. Building a proper search engine or LLM tool is hard, and the WMF already failed at making a search engine. There are next to no people currently using wikipedia search in the way described in the OP. Most people just type in the article name and bash Enter.

as a personal subjective view you seem to be quite upset whenever WMF develops sth innovative and then complain how this should be left to companies or volunteers No, I desperately want them to develop something innovative. But I know that this is one of the pitfalls for the WMF. Making a semantic search thing or an LLM tool is fun. But it is not what we need. And the WMF has a tendency to work on things that are fun, and then bolt a shiny new interface on top of a dinosaur codebase, instead of working on the boring incremental improvements we need.

I don't see why it wouldn't be a great idea, you certainly didn't explain why. I wasn't trying to convince you specifically.

…and? Is that a reason to not improve it? Like I said, I want them to improve it. But stuff like this is very difficult. And they can easily waste a lot of very scarce dev time on a fun project like this while ignoring the important stuff. And there is a pattern of halfbaked things that don't actually help us reach our goal.

only for most cases currently so that's not a good reason to not improve it, quite the opposite No, the WMF will never be able to compete meaningfully with Alphabet or Microsoft, and making something inferior that no one will use because there are many better alternatives out there is not a great use of resources. If we had unlimited devs with unlimited time then it would be a cool project to have some fun tho.

Wikimedia search isn't the Knowledge Engine But making something somewhat related is obviously a bit iffy.

Hopefully better example selection next time Agreed!

there are many comparisons between the two on Wikipedia such as in Cat–dog relationship... You probably already noticed those are not in the video, sadly. Maybe you can help EBlackorby-WMF make a better video? With a better search query and actually relevant results from Wikipedia articles?

Another approach would be to show articles about comparable things of the two, e.g. Domestication of the cat and Domestication of the dog alongside or right after another and then Dog intelligence & Cat intelligence. Yeah and that proves my point. If I ask to compare dogs and cats, and Wikipedia Search shows me those 2 articles next to eachother, then that is a truly terrible answer. ChatGPT and Gemini and Claude and whatever else will provide a far superior answer than "here are 2 somewhat related wikipedia articles, enjoy!".

It's useful to find info that way for lots of people for lots of cases plus lots of people are increasingly used to this type of searching No, that is useful to no one on planet Earth. And people are getting increasingly used to chatbots writing an custom answer for them, which is far superior than just putting 2 Wikipedia articles next to eachother. And you can ask follow-up questions to chatbots....

it's not always so easy to find or readily think of a good example So offer to help them. Make something better.

such searches may also make it clearer to editors that certain info is missing in Wikipedia and editors can also use this to check whether some info already is somewhere in Wikipedia or whether there's value in them looking into maybe adding it. No, that is not how that works.

that's what users already do Well the younger generations mostly just shout at their phones in my limited experience.

secondly that's what's a type of searching that's easier to many for lots of cases Not sure what you mean.

generated text is prone to hallucinations and inaccuracies, the text snippets approach is great Sure, but so are humans. The text snippets approach is obviously terrible because people will stop using it after discovering it doesn't answer their questions.

text responses is something that could be considered in addition (see the wish I linked) but that doesn't make this any less useful. Yes it does, the existence of superior LLM chatbots does make this Wikipedia Search thing less useful. Things don't exist in a vacuum. Having a truck made the horse and cart less useful.

type entire sentences into them that's what users already do No they don't. They type the article name and press Enter. Most natural language questions in English are longer than the ~40 chars you got on 1080p, and the situation is worse on a phone. In the video you can fit ~28 chars in that inputbox.

it's not needed to make it bigger and lots of search input boxes also aren't large; it's large enough Its certainly not large enough for natural language questions in English. And if you want people to use something you need to put it front and center, hence Googles famous design that mostly consists of a textbox and 2 buttons. Polygnotus (talk) 20:11, 2 February 2026 (UTC)

Of course a generated text that directly answers a question is superior to two or more snippets of Wikipedia articles. no, it's not – not for everyone and not for every case. Imo the ideal result would be a preference and a toggle button for which to display where the default is both and I'd mostly use the snippets instead of potentially misleading answers, e.g. because I want to use this to check what exactly is in Wikipedia so that I can add or not add some missing info but there's also sorts of search-uses and users. You can't convince people to start using Wikipedia search strawman since that wasn't even set as the goal. a far worse experience. it's complementary and sometimes you may prefer that and sometimes the other. There are next to no people currently using wikipedia search in the way described in the OP. 1. false 2. not unexpected when that doesn't work.

- - break: please understand one thing and this one thing is important – not everyone uses Wikipedia like you. And also not necessarily like you imagine. There's use-cases of the search and types of searches and purposes you can't even conceive of.

very scarce dev time on a fun project like this I've heard you say this many times. But really I suggest to not see everything as a problem of that type. This isn't a fun project. It's an important over due project on something of impact and I wouldn't be surprised if it can be developed with relatively little volunteer time. Why do I not see you calling for more tech development – this being neglected is the real problem, not them developing sth you don't right now understand the value of (but it's clearly there). No, the WMF will never be able to compete meaningfully with Alphabet or Microsoft people talking like that are usually employed by such companies so could you please just not continue with this talking point… It's not about competing with them. And a little more users coming to Wikimedia instead to search Wikimedia-related things would be great but that's not the goal (/the entire goal) here as I've already explained. making something inferior that no one will use you're comparing apples and oranges as I've already explained. Largely different purposes. Are you next saying we don't need hosting because Amazon could do it for us? What is next, come on. Please understand that saying something is inferior or not requires the use-cases to be the same but they aren't. And even if they were that doesn't imply we shouldn't improve the search. Other search engines being better is just an additional reason to upgrade the outdated tech. and Wikipedia Search shows me those 2 articles next to eachother, then that is a truly terrible answer for. you. Not for me and many others. I'd like to have exactly that in specific with text segments from within the article. ChatGPT and Gemini and Claude and whatever else will provide a far superior answer than "here are 2 somewhat related wikipedia articles, enjoy!". I listed more than 2 articles. I tried AI models, asking them to show me Wikipedia article sections about it and compare and they failed or weren't better. Seems like you seem to want people to use just LLM answers but not Wikipedia text; really I don't get why somebody would want that. No, that is useful to no one on planet Earth. false; it would be useful to me. Don't make assessments so easily. which is far superior than just putting 2 Wikipedia articles next to eachother. It's not 2. It's not just the articles but also text segments (and there's other use-cases than the example). And it's not always better. And fourth, the user who has searched on Wikipedia has searched on Wikipedia, not Google so your premise even if you don't recognize it as such is flawed. So offer to help them. Make something better. why are you so hostile whenever WMF develops sth when I give some feedback and am positive about the development? And OP's post doesn't come down to just one example. I also don't find it so nice to discuss here at such length. No, that is not how that works. good point /s Well the younger generations mostly just shout at their phones in my limited experience. good point /s Not sure what you mean. that to many people searching in natural language questions is easier – in specific not always but at least sometimes. because people will stop using it it's just additional results. No value is lost if people try this search and find they don't find the info they look for. does make this Wikipedia Search thing less useful. well obviously less useful but not unimportant or not having large impact; and I explained why your so-great LLM replies do have severe flaws. They type the article name and press Enter 1. not all 2. probably more and more try natural questions 3. obviously relatively do longer queries or even ask things because that currently doesn't work well/at all In the video you can fit ~28 chars in that inputbox and? It's same for the Web search engine and I still write long queries on the phone. Apparently you assume that there can never be any typo in it and/or the user must see the whole query they write at all time to be able to write it. Its certainly not large enough for natural language questions in English maybe watch the video again; it's more than large enough in the app and if it's too small the size can be increased. I don't want to hear about Google this or that anymore; we're not Google; next maybe you'll be asking we should stop spending scarce volunteer time writing Wikipedia because people can just ask superior AI models their questions. No. Prototyperspective (talk) 23:18, 2 February 2026 (UTC)

If you ask a question and instead of an answer you get 2 vaguely relevant snippets of Wikipedia pages you'd figure something was wrong with that person and back away slowly. Same thing with software.

I'd mostly use the snippets instead of potentially misleading answers No, you wouldn't, and both options are potentially misleading. Have you ever factchecked a Wikipedia article? Pick any Wikipedia article with a lot of edits and factcheck some of the most interesting claims.

I want to use this to check what exactly is in Wikipedia so that I can add or not add some missing info I don't think the tool described in the OP is intended for that usecase (and it wouldn't be great for it).

strawman since that wasn't even set as the goal. That is not what a strawman is, and that was set as the goal. I linked to it and so did the OP.

it's complementary and sometimes you may prefer that and sometimes the other. Nah, people will just continue using whatever tool they are already using. You don't see Google users using Bing once a week.

1. false 2. not unexpected when that doesn't work. 1) lol no its not. 2) sure, but it shows demand is low.

not everyone uses Wikipedia like you Thank god. also not necessarily like you imagine. I am very familiar with how people use computers.

There's use-cases of the search and types of searches and purposes you can't even conceive of. Well, you suggested to check what exactly is in Wikipedia so that I can add or not add some missing info but this tool wouldn't really work for that, sadly.

This isn't a fun project. It is for nerds.

I wouldn't be surprised if it can be developed with relatively little volunteer time. Probably zero, hence the "scarce dev time" thing.

Why do I not see you calling for more tech development I repeatedly have.... and do.

tech development – this being neglected is the real problem And yet these people go to work every day. And they do stuff. So do we want devs to work on this or on something important? We can't clone 'em.

you don't right now understand the value of (but it's clearly there) & people talking like that are usually employed by such companies so could you please just not continue with this talking point… People can just have a different opinion, without them "not understanding" or working for evil companies.

It's not about competing with them Yes it is. They are proposing making something that answers questions by searching Wikipedia and providing relevant snippets. Any AI chatbot can do the same except a billion times better (they are not limited to wikipedia, and can generate an answer to better match the question).

And a little more users coming to Wikimedia instead to search Wikimedia-related things would be great but that's not the goal I think you need to click the links in the OP above. I already linked to https://www.mediawiki.org/wiki/Readers/Information_Retrieval/Phase_1#Success_indicators So you keep making incorrect assertions.

you're comparing apples and oranges as I've already explained. Largely different purposes. Both share the purpose of answering questions.

Are you next saying we don't need hosting because Amazon could do it for us? Doing your own hosting saves a hell of a lot of money compared to just paying Amazon.

Please understand that saying something is inferior or not requires the use-cases to be the same but they aren't. And even if they were that doesn't imply we shouldn't improve the search. Other search engines being better is just an additional reason to upgrade the outdated tech. What is the point if no one is gonna use it because the alternatives are so much better?

and Wikipedia Search shows me those 2 articles next to eachother, then that is a truly terrible answer for. you. Not for me and many others. I'd like to have exactly that in specific with text segments from within the article. If you want that I am sure you can write a script to make that. But it would be terrible at actually answering questions. You can look at User:Polygnotus/CitationVerification for inspiration.

Seems like you seem to want people to use just LLM answers but not Wikipedia text; really I don't get why somebody would want that. Those LLMs are trained on Wikipedia. And those companies generate text. So their service is gonna be infinitely better at providing answers to natural language questions than the proposal above. Sometimes it is not about what people want, there are just cold hard immutable facts we have to deal with.

It's not 2. It's not just the articles but also text segments (and there's other use-cases than the example). And it's not always better. And fourth, the user who has searched on Wikipedia has searched on Wikipedia, not Google so your premise even if you don't recognize it as such is flawed. Wut?

OP's post doesn't come down to just one example. Well using a terrible example does undermine any proposal. For example the simple summaries thing had a terrible screenshot.

No value is lost if people try this search and find they don't find the info they look for. I value the wasted dev time.

I probably missed some bits because much of what you wrote was difficult to understand. Polygnotus (talk) 00:15, 3 February 2026 (UTC)

Well you insist you know how everyone is and will be searching Wikipedia. If you ask a question and instead of an answer you get 2 vaguely relevant snippets of Wikipedia pages This is an issue with the example; at other times it can be exactly what one was looking for. You don't see Google users using Bing once a week. because they're both for the same purpose. to work on this or on something important This is sth important. We can't clone 'em. I'll make an extraordinary claim: more devs could be hired. Additionally, lots of other things. Wut? people do (already) search (within) Wikipedia, the main question is what / how good the results are/can be. What is the point if no one is gonna use it because the alternatives are so much better? you don't understand it. Neither what I just said nor that not everyone always wants to ask an AI but maybe wants to just have human-written Wikipedia snippets and/or search Wikipedia. So their service is gonna be infinitely better at providing answers to natural language questions well I stop here. Prototyperspective (talk) 00:44, 3 February 2026 (UTC)

Well you insist you know how everyone is and will be searching Wikipedia. I did? Can you provide a link please?

This is an issue with the example; at other times it can be exactly what one was looking for. Theoretically. Or it could be the same or worse.

because they're both for the same purpose. Yes, that purpose is answering questions.

I'll make an extraordinary claim: more devs could be hired. I see your claim and raise you: more devs should be hired.

The WMF got a new CEO. Maybe you can ask her to hire more devs?

maybe wants to just have human-written Wikipedia snippets and/or search Wikipedia I understand that people might wanna search Wikipedia, and building a semantic model could be interesting. But very few search queries on Wikipedia are actually in something approaching natural language.[5]

Because of the limited dev time I predict the idea is just to play around with something like paraphrase-multilingual-MiniLM-L12-v2 for a bit. And while that sounds cool, I can foresee a bunch of problems:

When presenting snippets, how can we ensure the relevant bits of context are preserved while everything else is filtered out?

A fact I asked about may be in a long paragraph of text I can barely understand.

Or my understanding may be based upon context that no longer exists when only that paragraph is presented.

And what if its not a paragraph but a cell in a long table, how to present that without context?

If you don't generate your own text these are almost unfixable problems.

Once users discover LLMs give them actual custom answers while Wikipedia search gives them decontextualized snippets, they'll just use their preferred LLM. And you can ask any LLM a follow-up question.

"Don't build anything ever because competitors exist" is not the same as "don't build an inferior version of something that already exists made by a competitor with a thousand times more resources." Polygnotus (talk) 01:10, 3 February 2026 (UTC)

The WMF doesn't have (enough) people who point out flaws in their plans. Someone explaining why a plan sucks is, for a company, not an enemy but the most valuable person you have.

Before working on a plan you need to consider the pitfalls and downsides. So if this is a great plan they already have an answer to counter all criticism, built into the proposal. Polygnotus (talk) 20:33, 2 February 2026 (UTC)

Is there a way to download just the lead of all wikipedia articles?

There used to be "abstract" dumps but they seem to have been phased out. mghackerlady (talk) (contribs) 17:24, 2 February 2026 (UTC)

@Mghackerlady Have you tried https://dumps.wikimedia.org/other/cirrus_search_index/ ? IIRC those contain extracts but in JSON. Polygnotus (talk) 18:06, 2 February 2026 (UTC)

no, but taking a look at it, it seems more complex than the regular wiki dumps mghackerlady (talk) (contribs) 18:15, 2 February 2026 (UTC)

Agreed. But it does contain "opening_text" nodes. Polygnotus (talk) 18:27, 2 February 2026 (UTC)

Tech News: 2026-06

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• The "Page information" feature, which gives validating information about a page (example), now automatically includes a table of contents. If there is a local MediaWiki:Pageinfo-header page created by individual users, it can now be removed. [6]
• View all 21 community-submitted tasks that were resolved last week. For example, VisualEditor previously added bold or italic formatting inside link descriptions, making the wikicode complex. This has now been fixed. [7]

Updates for technical contributors

• There was no XML dump on 20 January. Additionally, from now on, dumps will be generated once per month only. [8]
• The MediaWiki Interfaces team removed support for all transform endpoints containing a trailing slash from the MediaWiki REST API. All API users currently calling those endpoints are encouraged to transition to the non-trailing slash versions. If you have questions or encounter any problems, please file a ticket in phabricator to the #MW-Interfaces-Team board.
• Detailed code updates later this week: MediaWiki

Weekly highlight

• Users are reminded that the Wikimedia Foundation has shared some guiding questions for the July 2026–June 2027 Annual Plan on Meta and Diff. These focus on global trends, faster and healthier experimentation, better support for newcomers, strengthening editors and advanced users, improving collaboration across projects, and growing and retaining readership. Feedback and ideas are welcome on the talk page.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 17:41, 2 February 2026 (UTC)

Pinging PrimeHunter and Izno re MediaWiki:Pageinfo-header. --Ahecht (TALK
PAGE) 20:04, 2 February 2026 (UTC)

Removed, though I note that MediaWiki:pageinfo-footer still isn't included, which looks to have a patch working on it at [9]. Izno (talk) 20:10, 2 February 2026 (UTC)

Unofficial addendum to Tech News: The WMF apparently rolled out a new "Labels" feature to the Watchlist in early February 2026. See this thread, above, and mw:Help:Watchlist labels, where improvements to the documentation are welcome. – Jonesey95 (talk) 23:38, 2 February 2026 (UTC)

Sort watchlist by expiry, not alphabetically?

Previously asked this as Help:Watchlist but I thought I'd try here since I didn't get much help there, and I see others have been raising their issues with the new labelling system.

The previous version of the watchlist used to list articles by how soon they were due to expire off the list. That was the default behaviour and it's a feature I used a lot until it was seemingly quietly removed. Now I have to manually scan over the whole list to see if anything is about to slide off which I might want to swing back around to, and hope I don't miss anything before it disappears. The new list resembles a table, but the columns don't seem to be sortable. Is there an option to make it sortable by expiry that I wasn't able to find? If not, does anyone know if there are plans to update the watchlist to allow it to be sortable by expiry? Should I be asking about this over on MediaWiki instead? (If so, where?) – Scyrme (talk) 18:43, 2 February 2026 (UTC)

I assume in this question that you're actually referring to Special:EditWatchlist. The task that changed it to use a table is phab:T411596. I would suggest asking there if it can be supported, though they may open a new task.

I'm going to go file a separate task, which is to emit a notification when an item on the watchlist is soon to expire, possibly on a per-watched item basis. Izno (talk) 19:00, 2 February 2026 (UTC)

Thanks! Your suggestion sounds like it'd be super helpful too. Hope it gets implemented. I know I'd use that feature if it were an option. – Scyrme (talk) 19:11, 2 February 2026 (UTC)

Or maybe add a label per discussion above about new feature. Johnuniq (talk) 00:41, 3 February 2026 (UTC)

Button in Watchlist to see all unseen changes with 1 click

Wikipedia Watchlist with highlighted button to open diff of all unseen changes of the page (via script)

Hello, how are you going through your Watchlist to check unseen changes?

Global Watchlist, a cluttered unoverseeable sea of blue with the button(s) at varying locations in between

I must be missing something – if it wasn't for that unknown hacky button (not available natively) then I would have to

• open the "hist" link in a new tab for all the pages that I want to check (can be dozens)
• and then manually select the oldest seen diff for each of opened tabs by clicking very precisely on the small selection dot (often having to scroll down to find the last revision)
• then scroll up and click "Compare selected revisions" and go to the next tab (and then wait until all loaded)

This takes a lot of time and is quite exhausting mentally if one goes through for example 100 pages.

I've only heard of the alternative to enable the setting "Group changes by page in recent changes and watchlist" and "Expand watchlist to show all changes, not just the most recent" and tested it. But that makes it even more exhausting and time-intensive as the Watchlist explodes in size because each individual edit is displayed and one can't even check one article at a time because it groups them not "by page" but 'by day by page'. Because of the 30days/1000edits limit, it's possible (for my WL rather likely) that not even all days are displayed. But even if they are, the changes are now cluttered across the multiple day sections in the Watchlist, making it much harder to go through or check them. Maybe this works for users who complete checking their Watchlist once per day on average and want to check each and every edit to each and every page in it and/or users who have less than 50 slow-changing articles on their Watchlist but I can't imagine that this is how the majority of active editors check their Watchlists.

The other alternative I know of is the Global Watchlist. Somewhere in its preferences one can enable the button to see unseen changes. However, there also is a sea of blue of usernames and the button(s) is at always at varying locations instead of aligned somewhere before the pagetitle. That doesn't sound like much of a problem but imo it in practice renders this rather useless as it's also exhausting to go through the Watchlist. One can't quickly click one diff button after another to go through pages one at a time (as one can if the buttons are aligned directly underneath).

What's so surprising is that Wikipedians seem to be fully fine with wasting so much extra time on checking their Watchlist. For very active editors that could well be hours weekly, not fully considering the extra cognitive load. I consider the core functionality of the Wikipedia Watchlist broken. This is why I'd like to know how you're checking your watchlist.
Are there any other routines, tools or workflows you as active editors are using? (if you watch at least 40 articles)

Furthermore, I created a wish about a native button to see the diff of unseen changes (has this been asked about before?)
W424 – A button in the Watchlist to see a diff of all unseen changes next to each article (voting open).
Prototyperspective (talk) 19:15, 2 February 2026 (UTC)

I open the "hist" link, then on the history page I find the first line not marked as unread and click the "cur" link on that line. I don't care for the "expand watchlist to show all changes" setting here, as the English Wikipedia is sometimes too active for the 1000 edits to go back far enough. Anomie⚔ 00:59, 3 February 2026 (UTC)

Page not being automatically archived, part 2

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)