Wikipedia:Village pump (technical): Difference between revisions

Page for discussing Wikipedia technical issues

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

“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)[reply]

…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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

@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)[reply]

@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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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

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

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

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

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

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

References

1. ^ Case, Linda P. (2003). The Cat: Its behavior, nutrition, and health. Ames: Iowa State University Press. ISBN 978-0-8138-0331-9.
2. ^ Ollivier, F. J.; Samuelson, D. A.; Brooks, D. E.; Lewis, P. A.; Kallberg, M. E.; Komaromy, A. M. (2004). “Comparative morphology of the Tapetum Lucidum (among selected species)”. Veterinary Ophthalmology. 7 (1): 11–22. doi:10.1111/j.1463-5224.2004.00318.x. PMID 14738502. S2CID 15419778.
3. ^ Malmström, T.; Kröger, R. H. (2006). “Pupil shapes and lens optics in the eyes of terrestrial vertebrates”. Journal of Experimental Biology. 209 (1): 18–25. Bibcode:2006JExpB.209…18M. doi:10.1242/jeb.01959. PMID 16354774.

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

@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)[reply]

@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)[reply]

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)[reply]

My brain must be half-asleep this morning… I read the instruction page of WP:Redirect maker & can’t figure out how to frikkin’ do it. SO… Paid protestor is an article already. A term much used in the Trump presdiencie has been “Professional agitators”. (Just do a WP search for the term…) I think a redirect from “Professional agitators” (and maybe also “Paid agitators”?) pointing to “Paid protestors” should be created. I just can’t get it straight on how to do it. Much thanks to one of you smart lovely people who can easily do it. – Shearonink (talk) 16:07, 15 January 2026 (UTC)[reply]

@Shearonink  Done. In the future, use WP:AFC/R for these sorts of requests. —Ahecht (TALK
PAGE) 20:13, 15 January 2026 (UTC)[reply]

Ahecht Ok, yes, thanks I do know that *but* I’m came here also to say I didn’t understand the WP:Redirect instructions. At all. Maybe someone could please write up an easy step-by-step page or something? I kept on redirecting to the wrong title, so I never saved my endeavors. – Shearonink (talk) 23:39, 15 January 2026 (UTC)[reply]

The tutorial you’re looking for is at Help:Redirect. Wikipedia:Redirect is a guidelines page. —⁠andrybak (talk) 05:18, 16 January 2026 (UTC)[reply]

Really? Then the Redirect maker shouldn’t be labeled as such and the sentence at WP:Redirect should be completely re-crafted: “For technical help relating to how redirects work, see Help:Redirect.” If Help:Redirect is the actual step-by-step guide to making Redirects for Dummies it needs to be bolded, highighted or whatever. I’d go in a re-jigger some of the scattered-about prose concerning redirects but I don’t want to be accused of messing about because I possibly have some bone to pick with the instructions.

And I have some experience around here. Someone who is completely new would probably have a harder time figuring out/teaching themselves what to do. – Shearonink (talk) 15:53, 16 January 2026 (UTC)[reply]

@Shearonink I added a hatnote to the page that should clarify it a little. —Ahecht (TALK
PAGE) 18:43, 19 January 2026 (UTC)[reply]

I am not sure where to report it, but it’s getting annoying: for the last few weeks, I’ve been getting notifications for main threads in project spaces where I submit report. Two examples: after submitting a DYK to T:TDYK using the relevant gadget, I became subscribe to “current nominations” thread there. And while submitting AfDs using Twinkle, I became subscribed to similar threads on DELSORT pages. Note this is not a problem with Twinkle or gadgets, I’ve been using them for years (and notifications too). Something changed “under the hood” and is now treating posting in such places as doing something worth subscribing (probably related to the mechanic of subscribing to a parent thread when you post in it, or create a subheading in it?). I assume this affects many folks and is tracked in Phhabricator somewhere, but since it is not being fixed quickly enough, obviously, I am posting here, as it is starting to make notifications annoying (I am getting several false alerts each days now because of this bug). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:08, 17 January 2026 (UTC)[reply]

@Piotrus: Is “Automatically subscribe to topics” enabled at Special:Preferences#mw-prefsection-editing? If you never want to subscribe then you can also disable “Enable topic subscription”. You can unsubscribe individual subscriptions at Special:TopicSubscriptions. They may come back if you edit the same section. PrimeHunter (talk) 13:28, 17 January 2026 (UTC)[reply]

@PrimeHunter Yes, it’s useful – for talk pages. Not for project space work pages. _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 13:46, 17 January 2026 (UTC)[reply]

@Piotrus: You can subscribe to level 2 sections with comments, probably identified by signatures. Transcluded comments like Template talk:Did you know#Current nominations and Wikipedia:WikiProject Deletion sorting/North Carolina#North Carolina apparently count since I see subscribe links. I don’t know whether such details have changed recently. PrimeHunter (talk) 14:57, 17 January 2026 (UTC)[reply]

Seems like a bug, doesn’t it? There should be a way to enable this functionality for talk pages, but not project mainspace or template pages _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:23, 18 January 2026 (UTC)[reply]

It makes sense to me that the feature looks for comments and lets you subscribe for that. It’s not in sections without comments. This village pump is in project space. PrimeHunter (talk) 18:10, 18 January 2026 (UTC)[reply]

There was some discussion about it on Commons because filing a deletion request would automatically subscribe the reporter to the whole deletion page (which can easily mean 200 notifications per day). If I remember correctly, there was a recent change that caused this behavior and a bug report has been filed. Nakonana (talk) 19:27, 22 January 2026 (UTC)[reply]

Here’s the discussion from Commons: [3]. And here’s the change that might be causing the problem: [4]. Nakonana (talk) 19:37, 22 January 2026 (UTC)[reply]

@Nakonana Thanks, I am surprised nobody else is complaining about this. Folks active in submitting DYKs and AfDs should be affected (I am hardly the only one active in this areas). _{Piotr Konieczny aka Prokonsul Piotrus| reply here} 04:12, 23 January 2026 (UTC)[reply]

It may be that those people don’t have the “automatically subscribe” feature enabled in their settings, or maybe they don’t make DYK / AfD reports that often — the issue doesn’t appear if one merely comments in one of the report threads. Or maybe there are not as many reports per day as there are DRs on Commons each day. But yeah, I’m also somewhat surprised; I’m quite a frequent commenter on DRs but not a frequent reporter, and yet it took me only two DR reports to turn to that VP thread on Commons because it’s especially inconvenient if you access the site via mobile browser where the un/subscribe button isn’t even displayed so that you have to switch to desktop view to find the problem and unsubscribe from the notifications. Nakonana (talk) 08:03, 23 January 2026 (UTC)[reply]

Good Afternoon,
I have been dealing with certain issues this week on the wikipedia advance search. For instance, I put “Democratic Socialists of America” under exactly this text, and in the category box, Female United States Representatives. I realized that there were no results shown when there should be. Same went for just “American Democratic Socialists” in the category box, when no results were shown when expected. In addition, I tried putting “she” “american” “environmental economist” under the search bar with category:Living people last week. It worked then, but not today. If I just put “Environmental Economists” under the category, no results show up when there should be some.
I am copying and pasting some of the links below:
https://en.wikipedia.org/w/index.php?search=%22Democratic+Socialists+of+America%22+deepcat%3A%22Female+United+States+representatives%22&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%22fields%22%3A%7B%22phrase%22%3A%22Democratic+Socialists+of+America%22%2C%22deepcategory%22%3A%5B%22Female+United+States+representatives%22%5D%7D%7D&ns0=1
https://en.wikipedia.org/w/index.php?search=%22she%22+%22environmental+economist%22+%22american%22+deepcat%3A%22Living+people%22&title=Special%3ASearch&profile=advanced&fulltext=1&advancedSearch-current=%7B%22fields%22%3A%7B%22deepcategory%22%3A%5B%22Living+people%22%5D%7D%7D&ns0=1
Sincerely,
~2026-36954-3 (talk) 17:38, 17 January 2026 (UTC)[reply]

@~2026-36954-3: Advanced search with “Pages in these categories” uses deepcat: which is currently broken. See phab:T414859: “Searching by category (deepcat) is broken”. You can enter incategory:"Female United States representatives" in the search box instead. deepcat: would have included subcategories if it worked. incategory: only searches the category itself. See more at Help:Searching. PrimeHunter (talk) 18:05, 17 January 2026 (UTC)[reply]

Good Afternoon,

I tried doing incategory:”Female United States representatives”, as well as incategory:”2007 births”, and it worked. Thank you so much for helping me resolve this issue. ~2026-39174-2 (talk) 17:51, 18 January 2026 (UTC)[reply]

In patrolling new pages, am encountering many users who are mistakenly putting page text in the edit summary dialog when creating new drafts, such as User:Multiverse Dimensional Leisure/sandbox and User:Ngọ Văn Nghị 2004/sandbox. –LaundryPizza03 (dc̄) 06:15, 18 January 2026 (UTC)[reply]

The first 200 characters appear in the edit summary automatically if the user creating the page doesn’t provide an edit summary when creating it. ///// JUMPINGISNOTACRIME (he/him) 10:33, 18 January 2026 (UTC)[reply]

But in this case, the pages ended up blank, indicating that the editors mistook the edit-summary dialog for the actual edit. –LaundryPizza03 (dc̄) 14:54, 18 January 2026 (UTC)[reply]

To be exact, the wikisource of both pages as originally saved was:

{{User sandbox}}
<!-- EDIT BELOW THIS LINE -->

which isn’t blank – see Template:User sandbox. Admins may view them at Deleted revision of User:Multiverse Dimensional Leisure/sandbox (as of 17 January 2026, at 19:44) and Deleted revision of User:Ngọ Văn Nghị 2004/sandbox (as of 17 January 2026, at 15:39). —Redrose64 🌹 (talk) 18:15, 19 January 2026 (UTC)[reply]

Working on a userscript here. For some reason the code at the very top, line 3, is encoding all spaces with %20… Cannot for the life of me figure out why, or how to prevent it. Any help appreciated!!! Zackmann (^{Talk to me}/_{What I been doing}) 05:01, 19 January 2026 (UTC)[reply]

What browser/OS are you using. I can’t replicate in Chrome on Linux. If you open your browser console and run:

document.getElementsByClassName('mw-page-title-main')[0].innerText

what happens? —Chris 12:56, 19 January 2026 (UTC)[reply]

@Chris G: I’m on chrome on an iPad… Weirdly the line you pasted above works fine. But when I concat the Category: onto the start the issue presents. Zackmann (^{Talk to me}/_{What I been doing}) 15:55, 19 January 2026 (UTC)[reply]

Sounds like Category: makes it treated as a URI. Does it also happen with mw.config.get('wgPageName').replace(/_/g, ' ')? Nardog (talk) 16:00, 19 January 2026 (UTC)[reply]

Bizarrely it does still happen: Special:Permalink/1333757770. So confused… Zackmann (^{Talk to me}/_{What I been doing}) 16:04, 19 January 2026 (UTC)[reply]

You might to want to explore the document.execCommand('copy') method then, which is more hacky and technically deprecated but still works. Nardog (talk) 16:11, 19 January 2026 (UTC)[reply]

I suspect it’s the use on line 15: when the link is clicked, the Javascript function call is executed, and I think the browser is then helpfully URL-encoding the result before following it. Note the href attribute should contain an URL, so if the script is intended to work on any subpages, it should be prefixed with “/wiki/”. isaacl (talk) 18:04, 19 January 2026 (UTC)[reply]

Not sure if I buy that theory, but doing away with embedding or referencing JS code directly in href, onclick, etc. in favor of addEventListener() (or jQuery on()) is generally a good practice. Nardog (talk) 13:33, 20 January 2026 (UTC)[reply]

I wouldn’t expect the Navigator.clipboard.writeText() to parse the text before writing it, or for Javascript string concatenation to do so, either. I think the change has to be occurring somewhere other than line 3 in the script. I agree that using an event handler would be a better approach. isaacl (talk) 17:44, 20 January 2026 (UTC)[reply]

Would it be possible to automatically detect and apply the appropriate spelling for “romanization/romanisation” by extracting data from the engvar templates, like {{Use American English}}? Currently you have to manually specify it using the engvar parameter. There shouldn’t be any reason the spelling in the tooltip should be different within the same article, so I don’t see a need to manually override it in just a single spot if that was the justification for this setup. —Opecuted (talk) 09:17, 19 January 2026 (UTC)[reply]

I know the citation templates do something similar with regards to date format templates. —Opecuted (talk) 09:19, 19 January 2026 (UTC)[reply]

When do you need to specify the variety of English while using {{langx}}? Nardog (talk) 09:20, 19 January 2026 (UTC)[reply]

Take these examples:

Also applies to {{transliteration}} since they both use Module:Lang (hover cursor over text):

• No engvar (displays as Chinese-language romanization): Yī
• British (displays as Chinese-language romanisation): Yī

(You may wish to view this in the edit source window) —Opecuted (talk) 09:53, 19 January 2026 (UTC)[reply]

@Opecuted Yes, you can use {{engvar|defaultWord=romanization|defaultLang=en-US|en-UK=romanisation|engvar={{{engvar|auto}}}}}. If no |engvar= value is passed to it, it will fall back to auto, which tries to detect the engvar templates on the page. —Ahecht (TALK
PAGE) 18:35, 19 January 2026 (UTC)[reply]

Is there any way I can delete notifications? sapphaline (talk) 10:57, 19 January 2026 (UTC)[reply]

@Sapphaline: If you mean the list of notifications when you click icons at top of the interface then no. Special:Preferences#mw-prefsection-echo has options to receive fewer notifications in the future but it doesn’t affect the list of past notifications. PrimeHunter (talk) 13:09, 19 January 2026 (UTC)[reply]

You can just mark them aas read. Gryllida 15:42, 19 January 2026 (UTC)[reply]

If on the other hand you want to stop getting notifications for something you subscribed to, you may manage those here: Special:TopicSubscriptions. — xaosflux ^Talk 19:59, 21 January 2026 (UTC)[reply]

Hello, when working with newcomers I wanted to get browser notifications when the user replies. Why is https://phabricator.wikimedia.org/T113125 with “Lowest” priority, then? For most users having this feature would be easier than setup delivery of notifications to email, which email client not all users have setup with notifications anyway either. Hope you can help. 🙂 Gryllida 15:41, 19 January 2026 (UTC)[reply]

Have you tried clicking the Subscribe link on the talk page section where the reply will be made? That will give you a new notification in the upper right corner of any new page or tab when any post is added to the section. – Jonesey95 (talk) 15:50, 19 January 2026 (UTC)[reply]

Hi @Jonesey95

THanks. Gryllida 16:02, 19 January 2026 (UTC)[reply]

Oh, I see. That sounds like a nightmare scenario to me, but I can see how some people would like it. – Jonesey95 (talk) 16:07, 19 January 2026 (UTC)[reply]

works better on smaller wikis or for users here who are not heavy into a million pages, @Jonesey95 Gryllida 17:13, 19 January 2026 (UTC)[reply]

@Gryllida, I think c:User:Jack who built the house/Convenient Discussions can do this? Qwerfjkltalk 17:12, 19 January 2026 (UTC)[reply]

Does it do the push notifications? Also would be great to get that for page edits, edit summary mentions and other kind of events. Thank you, I will check it out, though I think it just does a part of the job! Gryllida 17:15, 19 January 2026 (UTC)[reply]

https://commons.wikimedia.org/wiki/User_talk:Jack_who_built_the_house/Convenient_Discussions#Re:_desktop_notifications Gryllida 17:21, 19 January 2026 (UTC)[reply]

Hi @Qwerfjkl that does not work. Requires a wiki page is open WITH THAT PARTICULAR FORUM PAGE OPEN. That does not meet my requirements. Gryllida 07:07, 20 January 2026 (UTC)[reply]

@Gryllida: It was set as “Lowest” priority by Legoktm (talk · contribs), when originally creating the ticket more than ten years ago, specifically at 07:13, 19 September 2015 (UTC). The priority has not been altered since. —Redrose64 🌹 (talk) 14:01, 20 January 2026 (UTC)[reply]

See Nemo’s bug philosophy for why I used lowest at the time, dunno what the right value is today. Legoktm (talk) 15:13, 20 January 2026 (UTC)[reply]

Ok, I increased priority, I don’t mind if someone lowers it again, it is just there for record. I posted Real-time Echo notifications in the browser (push notifications) (Community Wishlist/W498) – Meta-Wiki Gryllida 23:02, 22 January 2026 (UTC)[reply]

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)[reply]

“Is this a bug of some sort?” – yes; “registered users” count includes temporary accounts. sapphaline (talk) 16:24, 19 January 2026 (UTC)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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

MediaWiki message delivery 20:27, 19 January 2026 (UTC)[reply]

Great to see some work on the Global Watchlist – it includes a button to see a diff of all unseen changes with a click. I don’t know how people can use the Watchlist without such a button.
However, it’s still not really usable in practice because unless you check all your Watchlist items each and every day there are seas of blue of username-links and that diff button is at an always varying location after the article title, impeding opening up many diffs one after another.
Here’s two wishes calling for this to be changed; I don’t think the Global Watchlist is usable really in its current shape so I hope somebody will eventually fix these problems (at least via options):

(voting open!). Prototyperspective (talk) 23:19, 20 January 2026 (UTC)[reply]

This is likely a HarfBuzz bug, since it’s working on Webkit, but breaks on Firefox and Chrome. Following the lead of “using exactly the same syntax, except inserting a line break“, according to my tests adding a letter glyph after the char in some cases fixes the bug, but punctuations and spaces don’t affect it. So a possible workaround fix (also shown in the template on the right): |char=◌̆<span style="color:transparent; font-size:1px; user-select:none" aria-hidden="true" data-nosnippet>o</span> ~ Boro (talk) 15:48, 22 January 2026 (UTC)[reply]

Yes, that works for me. Fantastic, was seriously beginning to doubt my sanity.

But now you have hit the wall of my expertise, so could you apply that solution to {{infobox punctuation}}, please? 𝕁𝕄𝔽 (talk) 16:07, 22 January 2026 (UTC)[reply]

I have updated {{infobox punctuation mark}} (to which {{infobox diacritic}} redirects, with that code. It works, afics — Preceding unsigned comment added by JMF (talk • contribs) 14:40, 23 January 2026 (UTC)[reply]

The issue ticket was created for HarfBuzz on GitHub, if it gets fixed, I’ll revert the patch. Tldr: None of the commonly installed fonts can display this correctly, so we can’t fix this with setting the right font. In Webkit, when the font config is insufficient, the fallback behaviour of the display engine guesses it right. Boro (talk) 04:36, 24 January 2026 (UTC)[reply]

Is there a way to make the source editor come up in a monospace font? I feel like there’s been a recent change though I haven’t been able to nail it down; I’m seeing the editor come up in a proportional typeface that makes it difficult to follow indent levels. —Trovatore (talk) 21:54, 21 January 2026 (UTC)[reply]

@Trovatore What is your “Edit area font style” at Special:Preferences#mw-prefsection-editing? —Ahecht (TALK
PAGE) 22:25, 21 January 2026 (UTC)[reply]

It has a dropdown box that says “Monospaced font”. —Trovatore (talk) 22:29, 21 January 2026 (UTC)[reply]

Check your browser’s font preferences. You might have a proportional font selected as your preferred monospace font. In Firefox, for example, I can go to Preferences – Fonts – Advanced to see the fonts that my browser chooses for different purposes. – Jonesey95 (talk) 23:35, 21 January 2026 (UTC)[reply]

Is it still proportional in safemode? PrimeHunter (talk) 00:04, 22 January 2026 (UTC)[reply]

The issue seems to have gone away. Some sort of glitch server-side? —Trovatore (talk) 02:31, 22 January 2026 (UTC)[reply]

Maybe some CSS wasn’t loaded for some reason (server/browser/connection/device/whatever). It happens. Text and styling are often loaded from different places (see separation of content and presentation) and combined by the browser. PrimeHunter (talk) 03:04, 22 January 2026 (UTC)[reply]

Whilst using the Random article function, it seems that places in Poland and Iran are displayed far more frequent that any other places.

Has anybody else experiences this? Phil.j.groom (talk) 02:02, 22 January 2026 (UTC)[reply]

@Phil.j.groom The “randomize” function takes several shortcuts to make it faster, so it is anything but random. —Ahecht (TALK
PAGE) 17:24, 22 January 2026 (UTC)[reply]

Note: the technical issue doesn’t seem to be fixed! Fram (talk) 15:34, 22 January 2026 (UTC)[reply]

Hello! I’m developing a gadget that supports the new features for the redesigned huwiki Main Page. I’m not experienced in MediaWiki gadget development, so I heavily relied on Claude. Nevertheless, I’ve tried to be thorough and checked everything many times, but I’m a bit anxious since the Main Page has the highest traffic: better safe than sorry. Unfortunately, we don’t have active editors at huwiki who can review complex JavaScript, so I’m hoping to get some feedback here.

My main questions:

• Are there any general best practices for MediaWiki gadgets I might have missed? Is there anything I should reconsider or fix before activating this for all users?
• Is the use of mw.storage/localStorage configured correctly?
• The Gadget-definition currently filters by both category and namespace for safety. Is this optimal, or is it redundant given how ResourceLoader works? The code also has early exit points to prevent unnecessary execution if page structure changes in the future.
• In the definitions, the CSS is currently set as peers. Is this ok, or TemplateStyles would be better? I’m planning to split out some parts (like a sister projects template) into TemplateStyles so they work on other pages too.

My planned rollout:

1. Remove the rights=editsitejs restriction to activate for all users (but still namespace+category-restricted)
2. Cross-browser/device testing and bug fixes
3. Community discussion before going live
4. When deploying: keep namespace+category filter, change namespace to Main (0) and Template (10), begin splitting HTML into templates per box (matching the current mechanics of the Main Page)

I’d appreciate any advice, especially from those experienced with gadgets and MediaWiki CSS. Feel free to comment here, or on the gadget’s talk page at huwiki. Thanks! Boro (talk) 14:13, 22 January 2026 (UTC)[reply]

Gadgets definition loading in certain namespaces or with certain categories only is not per se a safety feature, it’s just there to limit where the gadget is loaded. The real safety feature is deciding in the gadget where it loads instead, since I vaguely recall some dis-guarantees about this aspect. I would say that if you load it by category you probably do not need to limit it by namespace also, but you can if you want.

You should prefer TemplateStyles for content generated by editing wikitext. Eyeballing your current CSS sheet I believe that 1) this would be basically the entire sheet, and 2) the part which is not would be the definition of the CSS variables in the top block(s). For that, you must either 1) put this content in sitewide styles, or 2) do this the “hard way” in TemplateStyles by removing the CSS variables and adding new CSS rules. Which should be preferred is a question probably more of whether you can set the gadget page to be style-only (|type=style in definition), since to do otherwise will present a FOUC. If you do that, I do not know if it can be a dependency / peer and/or use the definition support of where it will load (particularly, as a category gadget). If it can’t be a style only gadget, then there is no reason to have the separate line in the definition. Izno (talk) 17:09, 22 January 2026 (UTC)[reply]

And I guess hu:Szerkesztő:Boro/project3 is your planning page. Skimming your JS gadget I am not totally certain some significant chunks of it are needed, but you don’t have a page where you outline the requirements.

I would instead check for whether mw.config.get(“wgPageName”) returns the name of your main page, rather than look for the class. This is much higher up the page, as it were. Izno (talk) 17:14, 22 January 2026 (UTC)[reply]

Is having the main page display totally dependent on a gadget really a good idea? Does it work in all skins? Does it work in Android and iOS apps? What will people who disabled javascript see? Will archive.org be able to archive it properly? (…) Ponor (talk) 19:33, 22 January 2026 (UTC)[reply]

There’s some strange alignment/wrapping going on in discussion headers if accessing Wikipedia via a mobile browser. Here‘s a screenshot of the problem. The screenshot is from Commons but the same problem is also happening on English Wikipedia (and maybe other wiki projects, too). Today is the first time I’m seeing this problem. I first thought that it might be caused by a change to a template but that doesn’t explain why it’s happening across projects.
If relevant: I’m using Firefox mobile browser. Nakonana (talk) 19:22, 22 January 2026 (UTC)[reply]

WP:ITSTHURSDAY — looks like gerrit:1220393 has just gone out, and has made changes to mobile heading markup. This has also broken DiscussionTools on mobile, see phab:T415303. DLynch (WMF) (talk) 21:40, 22 January 2026 (UTC)[reply]

I have reverted that change and backported the revert to production, so this should be fixed everywhere now. (I’m leaving this comment from mobile, which is a good sign, right?) DLynch (WMF) (talk) 22:20, 22 January 2026 (UTC)[reply]

@DLynch (WMF) Looking good now – thanks for the fix. Andrew Gray (talk) 23:35, 22 January 2026 (UTC)[reply]

Also being discussed here, but I figured this is a more appropriate venue. It doesn’t happen when replying to every comment, just seems to happen when trying to reply to opening posts. Screenshot of the error I get. There are multiple errors because I clicked the reply button several times. I can reply without a problem when I choose “Desktop site” view. TurboSuperA+_[talk] 21:42, 22 January 2026 (UTC)[reply]

Same underlying issue as this topic above. DLynch (WMF) (talk) 21:47, 22 January 2026 (UTC)[reply]

My javascript console seems to get filled up on every Wikipedia page with messages such as those below, even with safemode=1. Anyone know what’s causing this?

mw.xLab.getExperiment(): The "xlab-mw-module-loaded-v2" experiment is not active or the current user is not enrolled in. Is the experiment configured and running?
mw.testKitchen.getExperiment(): The "test-kitchen-mw-module-loaded" experiment is not active or the current user is not enrolled in. Is the experiment configured and running?
mw.xLab.getExperiment(): The "fy25-26-we-1-1-19-mobile-section-dead-end-phase-2" experiment is not active or the current user is not enrolled in. Is the experiment configured and running?
mw.xLab.getExperiment(): The "synth-aa-test-traffic-impact" experiment is not active or the current user is not enrolled in. Is the experiment configured and running?

—Ahecht (TALK
PAGE) 19:51, 22 January 2026 (UTC)[reply]

I did file phab:T415309. —Ahecht (TALK
PAGE) 20:05, 22 January 2026 (UTC)[reply]

I am on mobile, using google chrome. However as the title indicates, I can’t get to my homepage. I also can’t thank using the 3 buttons. Please help. Thank you for your time. Dafootballguy (talk) 23:47, 22 January 2026 (UTC)[reply]

It might be the same issue as the last few questions. Dafootballguy (talk) 00:06, 23 January 2026 (UTC)[reply]

@Dafootballguy have you enabled that option in your preferences? for some reason, thehomepage isn’t defaultive on enwiki and has to be selected manually. פרוגנתודון (talk) 11:49, 23 January 2026 (UTC)[reply]

I just did, thank you so much. Happy editing and great username. Dafootballguy (talk) 20:35, 23 January 2026 (UTC)[reply]

It used to be that for fully protected modules (Module:Citation/CS1 is one such) the code editor displayed a pink background during editing. I know, Thursday, but is it just me? When I opened Module:Citation/CS1 for editing, I got a brief pink background flash and then whatever the background is for unprotected editing. Chrome, win 11 desktop.

—Trappist the monk (talk) 01:14, 23 January 2026 (UTC)[reply]

The background likely comes from MediaWiki:Group-sysop.css:

.mw-textarea-protected,
.mw-textarea-protected + .ui-resizable .ace_content,
.mw-textarea-protected + .CodeMirror,
.ns-8 textarea,
.ns-8 .ace_content,
.ns-8 .CodeMirror {
  background-color: hsl(0, 100%, 94%);
}

It seems that the second and third selectors no longer work.

• .mw-textarea-protected + .ui-resizable .ace_content: .ui-resizable is part of jQuery UI, which has been deprecated for a long time. It was probably removed. A fix would be to change it to div.
• .mw-textarea-protected + .CodeMirror (if you enabled the Improved Syntax Highlighting beta feature): The CodeMirror extension uses version 6 of CodeMirror now, so .CodeMirror should be replaced with .cm-editor (docs).

NguoiDungKhongDinhDanh 02:10, 23 January 2026 (UTC)[reply]

I have added the other selectors. When CM6 is the only editor, we can remove the couple that pertain to jquery/CM5/Ace.

This probably should also live in gadgets instead to load at edit time rather than in the Group-X.css world and so people can turn them off if they want. Izno (talk) 02:57, 23 January 2026 (UTC)[reply]

Yes, this was because jQuery UI was removed from CodeEditor (phab:T323330), so the selector with .ui-resizable no longer matches. – SD0001 (talk) 12:09, 23 January 2026 (UTC)[reply]

I fixed it for CodeEditor in Special:Diff/1334424874. – SD0001 (talk) 13:23, 23 January 2026 (UTC)[reply]

Hello there,
am still working on a rewrite of furiant in User:פרוגנתודון/Furiant.
In User:פרוגנתודון/Furiant#Cultural_heritage_and_origin, I tried to use {{coat of arms}} on the three historical regions of Czechia. What I expected to have is File:Small coat of arms of the Czech Republic.svg, File:Znak Moravy.svg, File:Znak Slezska.svg.
What I get, however, was empty, unknown symbol. Tried switching to {{flag}} but then only Moravia got the right one.
On hewiki the fix was as simple as adding three new templatespace pages, but I couldn’t figure out how to add these three coats of arms to the template for Bohemia, Moravia and Czech Silesia accordingly in enwiki.

What should I do? פרוגנתודון (talk) 07:50, 23 January 2026 (UTC)[reply]

The template documentation explains that you can see the list of options by clicking Edit (or View Source) at the top of the template page. For the Czech regions, the following are listed in the template code:

| Central Bohemian Region=Central Bohemian Region CoA CZ.svg
| South Bohemian Region=South Bohemian Region CoA CZ.svg
| Plzeň Region=Plzen Region CoA CZ.svg
| Karlovy Vary Region=Karlovy Vary Region CoA CZ.svg
| Ústí nad Labem Region=Usti nad Labem Region CoA CZ.svg
| Liberec Region=Liberec Region CoA CZ.svg
| Hradec Králové Region=Hradec Kralove Region CoA CZ.svg
| Pardubice Region=Pardubice Region CoA CZ.svg
| Olomouc Region=Olomouc Region CoA CZ.svg
| Moravian-Silesian Region=Moravian-Silesian Region CoA CZ.svg
| South Moravian Region=South Moravian Region CoA CZ.svg
| Zlín Region=Zlin Region CoA CZ.svg
| Vysočina Region=Vysocina Region CoA CZ.svg

If you choose one of those options, you should see an image. – Jonesey95 (talk) 16:45, 23 January 2026 (UTC)[reply]

@Jonesey95 none of the above fit, since they’re Czechia’s modern adminstrative regions, not the three historical regions. I did check the source code, and I cannot add the right coats of arms for the historical regions within my current perms. פרוגנתודון (talk) 16:47, 23 January 2026 (UTC)[reply]

Also, I just noticed you put the Central Bohemian Region CoA in the draft in the place of Bohemia. Why? It’s the wrong place and the wrong CoA. פרוגנתודון (talk) 16:53, 23 January 2026 (UTC)[reply]

Ask on the template’s talk page for additional images and options to be added. Provide specific region names and links to the relevant File: pages. As for putting the Central Bohemian Region CoA in the draft to match the name shown on the map, it seemed reasonable as a way to show you how the template works, in conjunction with the above note. – Jonesey95 (talk) 16:56, 23 January 2026 (UTC)[reply]

I understand, will do. פרוגנתודון (talk) 16:58, 23 January 2026 (UTC)[reply]

Like maybe I want to retain the cite for possible future use, and don’t want to delete it. Anyway, something about this seems to have changed recently, Now when I use “ref=none”, then the following code pops up after each ref=none citation “CITEREF_temp_preview_id_[with a different number if there are multiple ref=nones]. Anybody know what’s going on? Thanks, Shearonink (talk) 02:18, 24 January 2026 (UTC)[reply]

Wikipedia has no business making up new rules on how non-English languages should be spelled. Yet the Citation Bot is constantly “correcting” what shouldn’t be corrected in non-English sections. The most recent examples I’ve come across are these, where it changed the capitalisation of titles of Russian academic journals: Special:Diff/1334365510 and Special:Diff/1334339631 – I’ve reverted similar edits too many times already.

I pointed out the problem on the bot’s talk page some time ago, the report has been marked as “fixed” even though evidently nothing has been done at all. Similarly so, an editor complained about the bot changing non-English style quotation marks in Icelandic, to which an another editor responded with pointing to MOS:QUOTE, probably to say it’s not a mistake but in line with WP rules, even though MOS:CONFORM says that quotation marks within non-English text should follow that language’s style (“When quoting text from non-English languages, the outer punctuation should follow the Manual of Style for English quote marks. If there are nested quotations, follow the rules for correct punctuation in that language.”).

Can anyone try to find a way to fix this problem? I do not believe this can be acceptable behaviour, it’s basically mechanised disruptive editing.

— Phazd (talk|contribs) 03:36, 24 January 2026 (UTC)[reply]

After the latest Chrome update (Version 144.0.7559.97 (Official Build) (x86_64)), I’m now getting an alert on every wiki page: “en.wikipedia.org wants to look for and connect to any device on your local network”, with Block and Allow buttons. I’m not seeing that on other sites. Any clue what’s going on here? RoySmith (talk) 11:47, 24 January 2026 (UTC)[reply]

You have mw.loader.load('http://localhost:8080/pingifier.js'); in your common.js file, I assume that is what Chrome is freaking out about! Sohom (talk) 12:08, 24 January 2026 (UTC)[reply]

Ah, that makes sense, thanks. Chrome stopped nagging me after a few rounds, so I guess it got bored. RoySmith (talk) 12:20, 24 January 2026 (UTC)[reply]

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)[reply]

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

The sum of ${\displaystyle x}$ and ${\displaystyle y}$ is written as ${\displaystyle x+y}$.

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

@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)[reply]

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)[reply]