This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Seeking clarification on WP:NEWLLM regarding human-reviewed translations
Summary: I am seeking community clarification on the scope of the recently published WP:NEWLLM. Specifically, does the prohibition of "generating new articles from scratch" via LLMs apply to the translation of existing Wikipedia articles from other languages when they are subject to full human review?
---
Full context:
I am writing to seek urgent community clarification on the recently published guideline WP:NEWLLM, specifically the transition from "AI-assisted editing" to the new restriction stating that "LLMs should not be used to generate new Wikipedia articles from scratch."
While I understand the intent is to prevent the influx of low-quality, hallucinated content, this guideline, as currently phrased, carries a significant and likely unintended consequence: the effective prohibition of modern machine-assisted translation.
The landscape of translation has shifted fundamentally. Nearly all industry-standard tools (including DeepL and modern iterations of Google Translate) are now powered by LLMs or are in the process of integrating them. For an editor translating a high-quality article from another language (e.g., Spanish or French) into English, the workflow almost always involves an LLM-based starting point followed by rigorous human editing.
A strict interpretation of WP:NEWLLM suggests that:
Pasting a translation generated by an LLM-powered tool into a draft is now a violation, even if it is based on a pre-existing, sourced Wikipedia article in another language.
The "from scratch" clause does not currently distinguish between synthetic content generation (making up new facts) and linguistic transformation (translating existing facts).
If we define "from scratch" to include translations, we are effectively mandating that editors return to "fully by hand" translationsāa standard that very few contemporary editors can or will meet, potentially stalling the growth of cross-wiki knowledge sharing.
Personal Context and Impact on OKA
This issue is not theoretical for me. I am the founder of OKA, a non-profit that provides grants to editors to translate pages across Wikipedias.
Our track record includes:
12,000+ articles published across the movement in 3 years.
4,500+ articles on English Wikipedia, all of which pass through the AfC process and undergo thorough human review by our grant recipients.
Support for 15 full-time editors whose work is now in limbo.
Upon reading this guideline, I have had to instruct all 15 editors to halt the creation of new articles. If this guideline is interpreted to ban LLM-assisted translation regardless of human oversight, it would render the workflow of organizations like OKA technically impossible, effectively ending our ability to contribute to English Wikipedia.
Request for Clarification
I believe the community needs to clarify whether "from scratch" applies to translations of existing Wikipedia articles. I suggest that the policy should distinguish between:
Prohibited: Using an LLM to generate a new topic/article where no source text exists (High risk of hallucination).
Permitted: Using LLM-based tools to translate an existing article from a sister project or other source, provided it undergoes significant human review for accuracy, tone, and formatting before publication.
I look forward to the community's thoughts on how we can protect the encyclopedia from AI junk without inadvertently killing the translation movement. 7804j (talk) 14:09, 3 January 2026 (UTC)[reply]
I think we should consider the intent of the guideline and the editors supporting it. All risks listed at WP:LLM can be avoided as long as the original article is policy-compliant and the translation is thoroughly verified. While translation tools were worse in the past, they have definitely improved; in my experience, intervention is rarely necessary with modern tools. So as long as the editor ensures that the translation complies with all relevant policies and it is faithful to the original, I see no good reason why that should not be allowed onto Wikipedia. And per WP:IAR, we should not be too focused on the letter of the guideline, especially since the closer of the RfC noted that I determine that there is community consensus to adopt this as a guideline in principle, but the current wording (which changed during the debate) does not enjoy a particularly strong consensus. Kovcszaln6 (talk) 14:56, 3 January 2026 (UTC)[reply]
To generate something from scratch would be to start from nothing, or from primitive components. Working from an existing fully-formed text is far from either, and would not run afoul of WP:NEWLLM.
Thank you. I agree with your interpretation, but it's not clear to me if this is universally how people interpret "from scratch" (as I've seen in the talk page of the policy many people discussing translation) so I feel an official clarification will help remove ambiguity.
I have seen the Rfc you mentioned, but it also doesn't seem to explicitly allow for translations. I will weigh in there as well 7804j (talk) 23:41, 3 January 2026 (UTC)[reply]
Actually just had an example of an article getting rejected from AfC with the stated reason being that "it used an LLM", and that this is supposedly prohibited by Wikipedia guidelines. As discussed here, this shouldn't happen since it wasn't generated from scratch but was clearly a translation. We have flagged this to the two reviewers, but it hasn't got anywhere so far.
This is a situation where the current wording is already creating friction in the AFC review process. I'm not sure what to take as next step on that particular article, since the AFC review decision doesn't seem consistent with the actual guidelines.
@7804j No, as I already told you in my reply that you apparently did not read, the issue here is that the original article in Portuguese appears to have been generated by a LLM. It is your responsibility as the translator to make sure the article you are translating confirms to all of the English Wikipediaās policies and guidelines.
I'm not sure what to take as next step on that particular article I told the original translator what to do back in December: review the entire article for LLM hallucinations, vague language, etc. and rewrite as necessary. That wasnāt done, so another editor declined the submission again.
Also, Iām surprised no one had said this yet, but it appears you used an LLM to write your original statement here. The English Wikipedia community generally does not like this and it doesnāt exactly help your cause. I2Overcometalk23:46, 28 January 2026 (UTC)[reply]
Ah then it is simply a misunderstanding from my end. When you said the original article, I thought you said the EN article, not the one from PT Wikipedia. Then all good! 7804j (talk) 06:34, 29 January 2026 (UTC)[reply]
AfC is hardly consistent - I've seen many bad rejections and good acceptances; that said, it is, well, run by people, like everything around here. I doubt it has a different error ration from OKA, for example. Anyway, based on what @I2Overcome said just above, the problem here is not OKA, but the quality of the original article. The only question I'd have is how obvious it is that the original article was LLM-generated, and whether it is something the translator could've reasonably caught? (And I2Overcome, the use of LLM for revising replies by 7804j has been discussed in another thread, and is not a very productive line of discussion, since they claim they are just using it to organize their thoughts, and it's allowed for people with certain forms of disabilities, and going down that line of discussion is, well, shrug. Best to focus on other dimensions). Piotr Konieczny aka Prokonsul Piotrus| reply here01:09, 29 January 2026 (UTC)[reply]
It is obvious in the English translation, so it could have been reasonably caught at that point even if not obvious in Portuguese. The method of replies is also a productive line of discussion, especially if replies are making up quotes like "it used an LLM". CMD (talk) 03:27, 29 January 2026 (UTC)[reply]
Full disclosure, up front: I think this is extremely bad optics as a concept: "this organization is paying people to add AI articles to Wikipedia." Which, bluntly, is exactly what is happening.
AI translations do not tend to be faithful to the original, and the text that deviates tends to contain the usual problems with standard AI-generated text. It's analogous to AI "summaries" actually just attributing their own generated text to the source, despite the source not actually backing it up. So "review" in that case would require not only checking the text against the original article, but against the sources as well, every single sentence and every single source.
In practice the level of review being done is far short of that. For example, this "translation" inserted an entire chunk of text under "River transport" when the corresponding section in the French article was completely empty.
For transparency, it would also be good for the exact tool, prompt, etc. being used should also be disclosed WP:LLMDISCLOSE. Virtually nobody does this and many people are cagey about it when directly asked -- which is not specific to this project, but is again bad optics, and makes it difficult to know how much review needs to be done. Gnomingstuff (talk) 05:50, 4 January 2026 (UTC)[reply]
Seconding this. The level of human review to AI additions is, quite often, very insufficient. If the worry is that it would render the workflow of organizations like OKA technically impossible, then it is indicative of a structural issue with OKA's own workflow, rather than a sign that policies should be adjusted to make it acceptable. Chaotic Enby (talk Ā· contribs) 06:21, 4 January 2026 (UTC)[reply]
I'm not sure I follow the rationale. My point was that if translators had access to no tools at all, they would be back to the "stone age" of translations, making it highly inefficient. If there are quality issues such as the one Gnominstuff raised, they should be raised with the due process with potential suspension of editors who make abusive use of the tools (in this particular instance, I will also look into what happened with the editor, ensure they fix the issue, and issue a formal warning). I have never said that OKA can only work if we tolerate "poorly reviewed edits" -- we don't -- and I am supportive of any strengthening to policies introducing consequences to publishing bad content.
Note that OKA has had over 40 editors in total (who are grant recipients, but otherwise just regular editors), who published thousands of articles, so with that scale it makes sense to occasionally have issues, just like with the rest of Wikipedia 7804j (talk) 13:33, 4 January 2026 (UTC)[reply]
My point was that if translators had access to no tools at all, they would be back to the "stone age" of translations, making it highly inefficient. Efficiency shouldn't come at the cost of adding errors at a large scale (or, as you call it, occasionally have issues). By using AI tools, your output becomes much higher, but so does the burden to verify the content added by your (paid) editors, which often falls on (unpaid) reviewers. If the issues with AI translations turn out to be systemic rather than individual, it makes sense to introduce much stricter standards (for instance, making sure that editors are fluent in the languages they translate from), and this is a baseline we can work from. Chaotic Enby (talk Ā· contribs) 13:41, 4 January 2026 (UTC)[reply]
My point was that if translators had access to no tools at all, they would be back to the "stone age" of translations, making it highly inefficient.
I do not think this is a problem. You seem to be a PR guy; imagine "this organization is paying people to add AI articles to Wikipedia" as a headline and that quote as the statement by the organization. How do you expect readers to respond? Gnomingstuff (talk) 14:14, 4 January 2026 (UTC)[reply]
7804j, your translators are welcome to use the very useful tools that are proficiency in a given language and dictionaries. The stone age? Translators now have access to the treasure trove of information that is the internet. In the stone age, a translator would be lucky if he had access to something like the Rosetta stone! Yours, &c.RGloucester ā ā01:24, 5 January 2026 (UTC)[reply]
To be clear, I am not saying that efficiency is the primary goal that trumps quality. In fact, the reason why we switched from traditional tools like Deepl to LLMs is because we've seen an i crease in overall quality as a result. But for equivalent quality, efficiency matters 7804j (talk) 23:46, 5 January 2026 (UTC)[reply]
Did you ever consider, perhaps, not using machines? I mean, if you claim to be the leader of an organisation of translators, the least you could do is prove that your organisation can produce a translation the old-fashioned away. You say that quality has improved upon switching from traditional machine translation to LLMs, but how are you evaluating quality? If your translators don't have the proficiency to translate without machine-assistance, I don't think they are likely to be able to perform such an evaluation. How are your translators qualified? How do you verify whether they are sufficiently skilled in a given language pair? Do you make them take an examination before engaging their services? Yours, &c.RGloucester ā ā10:27, 6 January 2026 (UTC)[reply]
RGloucester is not the one claiming to represent an organisation of paid, full-time translators, so I'm not sure what your whataboutism is supposed to prove. Athanelar (talk) 11:45, 24 January 2026 (UTC)[reply]
Update: @Gnomingstuff I have checked with the editor regarding the "River transport" section you mentioned. She told me that this wasn't an AI hallucination, but something that she independently expanded with her own research. I haven't checked the quality of the content she added, but just wanted to clarify that it's not an instance of an "LLM issue". 7804j (talk) 09:26, 8 January 2026 (UTC)[reply]
I'm sorry, but I don't believe that. At the very least AI seems to be used to have edited the text and/or for source summarization, you almost never get stuff like Overall, the lack of navigable rivers for large-scale transport underscores New Caledonia's reliance, which seems unlikely to be backed up by the book it is cited to; I don't have full access, but the section of the book containing pages 45-60 is about "The Kidnapping Inquiries and the Suspension of the Labor Trade, 1882 and has nothing to do with rivers at all (that section is accessible in full, you can see for yourself); and indeed there seem to be few mentions of rivers in the book at all.
Or something like Government reports emphasize the ecological sensitivity of these waterways, not only very characteristic of AI but similarly it seems to be poorly backed up by the source it is cited to, which seems to be primarily about whether local or state government should manage waterways. (GPTZero also comes back 100% AI-generated, though I don't generally use detectors.)
That section is further strange because a lot of the text in sections above it was not translated/lost in translation. "Historically, indigenous Kanak communities have utilized rivers for traditional transportation, employing canoes for fishing, trade, and cultural exchanges along waterways" also seems entirely hallucinated, and more concerningly, the source it is attached to has been attached to a similar statement earlier in the article where there was no source in the fr.wiki article (and that statement is also not supported). CMD (talk) 16:29, 8 January 2026 (UTC)[reply]
I was very surprised about this claim, as someone who lived in New Caledonia for two years, so I decided to go looking for sources. I found this ethnographic study about Kanak fishing, which only talks about it being practiced at sea or in lagoons, but not in rivers ā the words "riviĆØre" or "fleuve" (the two French words for river) aren't found once! Chaotic Enby (talk Ā· contribs) 16:47, 8 January 2026 (UTC)[reply]
Confirming that the entire text of The People Trade only has 6 mentions of rivers, each concerning a specific river (either the Dumbea or Diahot), and does not support that statement.
the Diahot River, flows for approximately 100 km (62 mi) with a catchment area of 620 kmĀ² (240 sq mi), but like most rivers in the territory, it is not navigable for commercial vessels due to its variable flow and challenging terrain.[1] ā 100km is supported, 620kmĀ² is not, non-navigable is not, variable flow and challenging terrain is not.
indigenous Kanak communities have utilized rivers for traditional transportation, employing canoes for fishing, trade, and cultural exchanges along waterways.[2] ā Entirely unsupported.
Other observations:
Extended content
Statements about how the area's rivers are primarily used for recreation and are known for kayak navigability are supported with two sources from a site promoting New Caledonia tourism [3][4], this is something that editors easily recognize as inappropriate sourcing but LLMs are often blind to.
When citing an academic article, the entire page range was provided instead of being specific, this is something I've commonly observed in tandem with LLM edits.
I also don't rely on detectors, but have ran the section through pangram after forming my own conclusion that the text is LLM-generated, the result was in 100% agreement.
@Leeanah Could you take a lot at the above discussion and at the concerns raised? There seems indeed to be evidence that there were hallucinated facts here, unlike what you told me offline. If this is the case, it is very concerning -- should be fixed immediately, and you should ensure this doesn't happen again with your future edits. 7804j (talk) 23:50, 8 January 2026 (UTC)[reply]
It seems very pertinent to the topic that quite obvious AI hallucinations are entering our articles through an organised translation process. CMD (talk) 06:12, 9 January 2026 (UTC)[reply]
For transparency, Iām posting the same response here as in the other related thread:
Thank you for taking the time to look into this and for laying out the concerns in detail.
This edit was made back in August 2025, and I want to be clear that the āRiver transportā section should not have been added the way it was. At the time, I misunderstood the boundaries of a translation task and treated an empty section in the source article as something that could be developed further. That was an error on my part.
I did consult external sources then, but after reading the discussion here, itās clear that parts of the content were not properly supported by those sources and should not have been included. Regardless of my intent, the end result does not meet Wikipediaās standards for verifiability or for faithful translation.
As a first step, I will remove the āRiver transportā section entirely, as well as any other content identified as unsupported, so that the article reflects only what is present and sourced in the French version.
Iāve also changed how I work since then. I no longer expand or supplement content during translation. My role is strictly limited to translating existing, sourced text, with AI tools used only to assist with revising language and editing formatting, followed by manual review against the original article.
I also recognize that I should have responded sooner on the talk page, for that I apologize. While Iām a professional translator, Iām not the most experienced when it comes to navigating talk pages and Wikipediaās internal processes more broadly. Thatās something Iām actively working to improve, so I can engage more effectively and avoid situations like this in the future.
I appreciate the feedback from everyone here and take responsibility for fixing this and making sure it doesnāt happen again. Leeanah (talk) 16:07, 11 January 2026 (UTC)[reply]
I've also performed a spot-check of different or added sources within Perce-Neige Publishing as translated on 27 December.
Extended content
the house was relaunched in 1990 by young poets Fredric Gary Comeau and Jean-Philippe RaĆ®che.[5] ā Citation is repurposed from elsewhere and doesn't mention Comeau or RaĆ®che, nor 1990.
Poetry: ... Essays and documents: ... Prose: ... Memoir: ... [6] ā None of these are supported by the provided primary reference which is absent from the original. Either mentioned persons are absent, or if present, other information is absent.
I think this is quite complex. The extent to which I think LLM-assisted machine translation is appropriate depends on:
The sister project. For example, you need to assume that any text written in the Croatian Wikipedia between 2011 and 2020 needs to be translated by a human with good judgment.
The topic. For example, the Japanese Wikipedia is credibly alleged to contain bias about the Nanjing Massacre, comfort women, and Unit 731.
The language pair. Machine translation into English is generally better from Indo-European languages, particularly Spanish, French, and German, than it is from (for example) East Asian languages.
Also note en.wiki's citation standards. A difficulty I keep finding with translating from German or French to en.wiki is that the origin language's citation standards are much lower, so I typically end up trying to locate more sources. This sometimes necessitates substantial rewriting where the origin language editor interpreted the sources considerably more loosely than en.wiki would consider acceptable.āS MarshallT/C10:04, 4 January 2026 (UTC)[reply]
Fully agree with that last point. Standards on other wikis (sourcing, notability, or general quality) don't necessarily neatly map onto en.wiki, and directly translating material isn't necessarily ideal for that reason. Chaotic Enby (talk Ā· contribs) 10:39, 4 January 2026 (UTC)[reply]
I think we are mixing quite a few things here. The question being discussed isn't whether translation should be allowed, but whether it should be allowed to use tools to assist translations. The examples above aren't specific to the use of tools: they are about the process necessary for checking sources across Wikis. While all these points are valid, they are outside of the scope of this immediate discussion 7804j (talk) 13:05, 4 January 2026 (UTC)[reply]
I don't think they're necessarily outside of its scope, as reviewing the accuracy of an LLM translation inherently depends on one's proficiency in the source language. Editors who don't rely on machine translation are obviously limited to languages they are proficient in, but this limitation doesn't exist for those making use of these tools, leading to the very cases of unreviewed machine translation we're trying to avoid. Chaotic Enby (talk Ā· contribs) 13:10, 4 January 2026 (UTC)[reply]
I generally agree with the points raised, i.e., that the topic of "translating wikipedia" is complex, that poor translations or translations from poor sources shouldn't be tolerated, and that what should be allowed depends on many factors including source language, editor's proficiency, etc.
But as long as we agree that we want to tolerate "some form of translation", this means that we also both agree that there should be at least some form of tolerated use of LLMs for translation purposes, right? If we're in agreement there, I think the focus should be on finding the right "rules" for what's admissible or not, to then be able to formulate these into the LLM or translation guidelines. 7804j (talk) 13:22, 4 January 2026 (UTC)[reply]
I do agree that defining these rules is the next essential step. We already have some rules against unedited machine translation which can serve as a starting point. A baseline level of proficiency in the source language should be necessary for an editor to be able to check the output of an LLM translation, and it could be helpful to make that explicit in the current guidelines. Chaotic Enby (talk Ā· contribs) 13:28, 4 January 2026 (UTC)[reply]
The examples above aren't specific to the use of tools: they are about the process necessary for checking sources across Wikis. The point that we are trying to make here is that this process requires tasks and competencies that might be incompatible with some or all types of LLM-assisted translation workflows, including workflows that are acceptable in other types of professional translation settings. -- LWGtalk(VOPOV)19:36, 4 January 2026 (UTC)[reply]
Machine translation of any kind, LLM-type or otherwise, should be prohibited on the English Wikipedia. There are a number of problems with allowing machine translation tools ā 1) they encourage editors without sufficient language ability to review either the source or target language text to create bad articles ā 2) they encourage editors to copy pages from other language Wikipedias, when in most cases, articles found on those other language Wikipedias are not suitable for inclusion on the English Wikipedia, due a difference in standards ā 3) machine translation varies in quality widely depending on the language pair; with more difficult pairs, the results are nigh useless ā 4) LLM-based translations are just as likely to contain hallucinated content as other kinds of LLM-generated content ā allowing rampant use of LLM translation will foist more work onto the already taxed members of the AI Cleanup project. Machine translation in its traditional form can be a useful tool, but its utility is entirely dependent on the language proficiency of the user. Much as with those editors who use LLMs to 'generate articles from scratch', editors who are wont to use machine translation to basically transfer articles from some other Wikipedia to the English Wikipedia are unlikely to have the necessary language ability to review content in a sufficient manner. If any kind of machine translation is to be allowed in the manner described above, it should require a specific user right. Moreover, the user right should be issued on a per language basis, as editors should never attempt to translate content that they cannot comprehend unaided by a machine. Finally, any content produced using this user right should be clearly marked and recorded. Yours, &c.RGloucester ā ā11:33, 4 January 2026 (UTC)[reply]
I would agree with a per-language user right, with proficiency in that language being an absolute requirement. For example, I know that I could review machine-translated content from French as I'd have the ability to cross-reference it with the original, but I couldn't do the same with, say, content translated from German. Chaotic Enby (talk Ā· contribs) 11:41, 4 January 2026 (UTC)[reply]
I think it's more complicated than that. The complexity of the writing and the editor's knowledge of the subject matter are also factors. For example, I don't speak a word of Swedish, but if the source article is sufficiently short and simple, and my knowledge of the subject is sufficiently high, I could produce a good translation from Swedish to English with machine translation (or even without it ā there just aren't that many ways to write "Astrid Lindgren was a Swedish author", after all). WhatamIdoing (talk) 23:50, 4 January 2026 (UTC)[reply]
If the content produced in such a workflow is not entirely dependent on the source material, then it is not a translation, but an original work. That is to say, if you already know that 'Astrid Lindgren was a Swedish author', the Swedish text becomes irrelevant. The Swedish and English text may end up meaning the same thing, but the resulting English text could not be positioned as an English rendering of the Swedish. Yours, &c.RGloucester ā ā00:10, 5 January 2026 (UTC)[reply]
That sounds rather philosophical, or even metaphysical. Back her in the boring mundane world, "Astrid Lindgren was a Swedish author'" is an English translation of the sentence "Astrid Lindgren var en svensk fƶrfattare". I'm using the word translation to mean "a rendering from one language into another"[9] or "The product or end result of an act of translating, in its various senses"[10]; as a result, if the Swedish and English text end up meaning the same thing, then the newer is a translation of the older, even if the process for the creating the newer is not one that meets your particularly high standards. WhatamIdoing (talk) 17:17, 6 January 2026 (UTC)[reply]
Related to your point about dual-language fluency: LLM translations are also difficult to clean up, because you need a fluent speaker who is also knowledgeable about fact-checking AI and willing to do arduous work, which is often a "pick any two" situation. Gnomingstuff (talk) 14:26, 4 January 2026 (UTC)[reply]
As I understand it what it basically comes down to is that while there are beneficial uses for LLMs, the community doesn't agree on what they are or how to distinguish them from the bad uses, and that lack of agreement plus the Dunning-Kruger effect has made it extremely difficult to develop clear, nuanced guidance that works. Speaking for myself, when I do research in my day job I might use machine translation to access sources in languages I'm not fluent in, but if I actually cite one of those sources I am going to want to take the time to do a closer reading, and I would never insert a machine-translated block of text into my academic writing without clearly marking it as such. In the context of cross-wiki translation, the challenge is that we can't assume text on another wiki meets enwiki sourcing standards (after much of the text on enwiki doesn't meet enwiki sourcing standards). So before translating from another wiki, the editor needs to check the sources cited on the other article, which is a task that an LLM can't do, so the editor doing the translation still needs to at read the source language at a level that allows them to comprehend and verify sources. -- LWGtalk(VOPOV)13:44, 4 January 2026 (UTC)[reply]
Machine translating an article and then simply publishing with little or no editor input is a problem, there're many duplicate or broken article to attest to that fact. Translating an article is definitely a good thing, but as with any article creation it needs to be done with care. -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°18:50, 4 January 2026 (UTC)[reply]
I'd been meaning to raise this after a brief discussion among NPP reviewers late November, since I hadn't been aware of the switch until then. I note on the oka.wiki website it says We constantly compare the performance of the various models (e.g., ChatGPT, Claude, Gemini) to ensure our translators have access to the most reliable tools. Publishing both the methodology and results this evaluation process would be good as an additional step.
I think the thread starting with Gnomingstuff and Chaotic Enby's responses make this fairly clear, but efficiency is most certainly the wrong goal to focus on. Accuracy is not going to be something most editors consider negotiable, and your evaluations should provide clear evidence that autoregressive NMT is producing lower error rates than encoderādecoder models, which themselves should only be used, under current guidance with sufficient review that machine-assisted translations have lower error rates than fully manual translations by a dual-proficient editor.
Additionally, as a particularly pernicious type of error, I'd assert your process should produce hallucinatory text, if not almost nowhere, then arbitrarily close to that standard. If that ends up halving or quartering the hourly output of OKA, that would still be the approximate standard to strive for. Alpha3031 (t ā¢ c) 10:24, 5 January 2026 (UTC)[reply]
One of the mains reasons why we switched from traditional tools like Deepl to LLMs is because we've seen an i crease in overall quality as a result (while efficiency also increased). In general, OKA promotes reductions in outputs for increase in quality, we never asked our translators to make the opposite tradeoff 7804j (talk) 23:48, 5 January 2026 (UTC)[reply]
DeepL is an LLM-based tool. Which is something that you, yourself, said in your initial post: Nearly all industry-standard tools (including DeepL and modern iterations of Google Translate) are now powered by LLMs or are in the process of integrating them. Gnomingstuff (talk) 04:23, 6 January 2026 (UTC)[reply]
Yes here I was refering to the "general purpose LLMs" (while Deepl does use LLM under the hood, without going into the specifics, it's a very different type of implementation).
Also Deepl today is LLM-based, but Deepl previously wasn't. What we've noticed at OKA is that (1) Deepl is better today than it used to be (which is why they switched to LLMs), (2) "regular" LLMs like Grok, Claude, Gemini are better than Deepl today.
I am actually planning to publish a more formal set of data on our findings comparing the different tools for translation purposes, and evaluating the "error rate per 1000 words", etc. so will be able to share more insights soon 7804j (talk) 14:05, 6 January 2026 (UTC)[reply]
I agree with @7804j: translating an existing article isnāt ācreating an article from scratchā. Youāre starting from a complete source text, not inventing a topic or drafting new claims out of thin air.
If the translator actually knows both languages, checks the output against the original and the sources, and removes any hallucinated or policy-problematic additions, then using LLM-based translation tools should be fine. A blanket ban would mostly punish careful translators and slow down cross-wiki sharing. Grudzio240 (talk) 11:33, 8 January 2026 (UTC)[reply]
Did you read the OP? Why do you suppose it includes this:
If this guideline is interpreted to ban LLM-assisted translation regardless of human oversight, it would render the workflow of organizations like OKA technically impossible, effectively ending our ability to contribute to English Wikipedia.
I did read it thank you. My question was why they are being coy about what model they use. The instructions are clear: DeepL is for writing prose and correcting output, Grok is used for the actual translation work. ExtantRotations (talk) 02:52, 9 January 2026 (UTC)[reply]
(To clarify, though, I suspect the reason this is being pointed out is the recent news about xAI encouraging the use of Grok to generate revenge pornography and child sexual exploitation material, which has drastically tainted its reputation, and the proposed and/or enacted bans in several countries in response. Given this, it seems like incredibly bad optics for Wikipedia to recommend Grok.) Gnomingstuff (talk) 17:18, 12 January 2026 (UTC)[reply]
Proposal
These are the circumstances when you may use machine translation tools that include a large language model element to translate text from a foreign-language Wikipedia into the English Wikipedia mainspace:
a) You have dual fluency, which means you have sufficient knowledge of both the origin language and English to verify that the translation is accurate;
b) You've checked the sources in the origin language article and you confirm the translated text reflects them fairly; and
c) You've reviewed the English language text and revised it where necessary before moving it to mainspace.
You may put the raw output of LLM-generated text into your userspace (preferred) or draftspace while you work on it, but if you do, you must clearly tag it as LLM generated text requiring review from a human with dual fluency, and that tag must be in place from first creation.
Thanks a lot, that's a great starting point! "Origin language" could read better as "original language" or "source language" in my opinion. Additionally, "You've reviewed" could stand to be clarified as "You've manually reviewed".Regarding the tags, I think it could be good to clarify that the text is LLM generated text and would require review before going in mainspace, but, if the editor is still working on it, not explicitly invite other users to review it right now (for example, the tag shouldn't place the page it in a tracking category). Chaotic Enby (talk Ā· contribs) 14:11, 4 January 2026 (UTC)[reply]
I'd like to avoid "source language" because of the risk of confusion between "language you're translating from" and "language the sources are in" (which may be different). No objection to "original language" if we can't coalesce around the (briefer) "origin language". I probably need to add the WP:TFOLWP requirement in there as well.āS MarshallT/C14:55, 4 January 2026 (UTC)[reply]
S Marshall, you should use industry-standard terms; see Translation#Source and target languages. Some alternatives are L1 and L2, and there are others. Also, the texts are sometimes called source text (ST) and target text (TT). MT systems sometimes talk about from-language and to-language. If there is a risk of confusion, then explain what you mean, but don't just create some neologism. Mathglot (talk) 14:18, 8 January 2026 (UTC)[reply]
I agree with Chaotic Enby, this is a very good start. I was also going to suggest that the tag should be one that indicates it is a work in progress rather than something presented for others to review, but actually I think there should be a set of tags:
This is LLM output that is either unchecked or incompletely checked. Checking and revising is currently a work in progress. Please check with [editor] before making content changes to this page.
The checking and revising is partially complete, contributions from other editors are welcome.
The original editor has reviewed it and made the changes they see necessary but would welcome a check from someone else before it's moved to mainspace.
General tags should be placed in addition to the ones above when they are relevant and meaningful (most other AI-related ones are not going to add anything useful so shouldn't be added, but something like {{in use}} in addition to the contributions welcome template would be). Thryduulf (talk) 14:26, 4 January 2026 (UTC)[reply]
I'm wondering if this could all be handled by a single template with parameters controlling its display, to avoid confusing editors with too many different templates. Chaotic Enby (talk Ā· contribs) 14:30, 4 January 2026 (UTC)[reply]
If that's the better way of doing it then that's fine. I'm just noting that I think there should be a way of indicating multiple states, not expressing a preference for the method of implementing that. Thryduulf (talk) 15:12, 4 January 2026 (UTC)[reply]
Not my preferred proposal for a number of reasons, mostly because it's basically just the status quo. Most people think they're doing sufficient review, relatively few people are just YOLOing text onto the page. The original post here claims "rigorous human editing" is being done. There needs to be a clearly stated, reasonably objective standard for what "review" means. (I think this is a problem with WP:MACHINE too.) Gnomingstuff (talk) 14:37, 4 January 2026 (UTC)[reply]
At minimum: Every single claim should be checked against both the original article and the sources cited, not just for truth but for verifiability. In the translation step, no content, claims, or interpretations should be added that weren't present in the original article (though they may be removed).
Which isn't all that different from "regular" machine translation, the footguns are just different and are less obvious if you haven't edited AI text before (e.g., common forms of AI editorializing like turning "said XYZ" into "emphasized the need for XYZ.") Gnomingstuff (talk) 14:53, 4 January 2026 (UTC)[reply]
(edit conflict) @Gnomingstuff: there are, broadly, two possible workflows for translation using LLMs:
Get the raw output
Paste that somewhere on Wikipedia (e.g. userspace)
Review and correct the raw output (over one or more edits)
Move to mainspace when done
Get the raw output
Paste that somewhere other than Wikipedia (e.g. locally)
Rewiew and correct the raw output
Copy and paste to Wikipedia when done (either direct to mainspace or via user/draftspace to check for typos in markup, template parameters, etc)
Both methods should be seen as equally acceptable based on personal preference. The purpose of the tag S Marshall suggested/the first one I suggested is for people using the first workflow to explicitly mark that the output is unchecked/lightly check but they are actively working on doing that. Someone "YOLOing" raw LLM output direct into mainspace is not going to be using this process at all, either because they don't know our policies and practices or because they don't care. The tag is not for those people, it is to assist those who do care to do things properly and to assist those who are patrolling for LLM output to distinguish between those who are doing it properly and those who aren't. Thryduulf (talk) 15:04, 4 January 2026 (UTC)[reply]
To clarify, my concern is not where people do that review -- there are benefits and drawbacks to either of those -- but whether and how much. I'm not talking about people who don't review; that's exactly why I just said there aren't that many of them. But just because someone does genuinely does want to do things properly and thinks they are, doesn't mean they actually are. Gnomingstuff (talk) 19:16, 4 January 2026 (UTC)[reply]
But you do, though. You very much do generate novel text when you're translating properly. If I translate an article very literally and exactly from German to English, then I get a kind of horrible Yoda-speak that's light on verbs and very heavy on the nouns. If I translate into fluent, idiomatic English, then the process involves a lot of periphrasis.āS MarshallT/C14:58, 4 January 2026 (UTC)[reply]
Sort of. The generation of text you do when idiomatically translating something is different to the generation of text you do when creating something from nothing. In the context of LLMs "generated" is most likely to be understood as the latter, which a translator is not looking to do. "Translated" is going result in less confusion here, even if "generated" is technically correct. Thryduulf (talk) 15:11, 4 January 2026 (UTC)[reply]
You may only use machine translation tools that include a large language model element to translate text from a foreign-language Wikipedia into the English Wikipedia mainspace when:
a) You have dual fluency, which means you speak both the origin language and English well enough to confirm that the translation is accurate;
b) You've checked the sources in the origin language article and you confirm the translated text reflects them fairly;
c) You've reviewed the English language text and confirmed that each fact or claim that's challenged or likely to be challenged has an inline citation to a reliable source; and
You may put the raw output of LLM-translated text into your userspace (preferred) or draftspace while you work on it, but if you do, you must clearly tag it as automatically translated text needing review from a human with dual fluency. That tag must be in place from first creation.
Thanks for the new proposal! I wonder if Gnomingstuff's addition of no content, claims, or interpretations should be added that weren't present in the original article could be relevant? Of course, these can be added later during regular editing, but checking against any spurious LLM additions might be necessary to require. Chaotic Enby (talk Ā· contribs) 16:50, 4 January 2026 (UTC)[reply]
I simply don't like that addition. If someone translates an article and finds it (for example) fails NPOV or lacks balance, they should be allowed to add any additional material needed for policy compliance without breaking the rules.āS MarshallT/C17:59, 4 January 2026 (UTC)[reply]
Of course, they should be allowed to do that, but my worry is that it will lead to editors leaving AI hallucinations in the translated product while claiming to have "reviewed" it, especially since LLMs are prone to false balance. I believe that any higher-level content issues (meaning, beyond basic verifiability, which can be dealt with by removing problematic content) should be dealt with after the translation itself (of course, if they want, while the article is still a draft), and more crucially shouldn't rely on the AI additions.Maybe we can come to a middle ground by requiring that AI additions (that weren't present in the original translation) shouldn't be left, in the spirit of WP:NEWLLM? Chaotic Enby (talk Ā· contribs) 18:21, 4 January 2026 (UTC)[reply]
Wording wasn't meant to be set in stone. I was thinking of the very common AI failstate of revising a portion of text by roughly paraphrasing it but also adding its own editorializing/interpretation. This kind of thing (the last sentence) -- that's obviously not a translation but it's the same effect at work.
Would also cover the case linked above where an entirely new section of text appeared in the English translation where there was once an "expand" tag and nothing else. Gnomingstuff (talk) 19:20, 4 January 2026 (UTC)[reply]
At the moment the proposed text just says a tag of some kind must be used, but it doesn't make any particular tag mandatory. If we want a specific tag with specific fields, perhaps an interested person will code a template for us?āS MarshallT/C17:59, 4 January 2026 (UTC)[reply]
ā
You've reviewed the English language text and confirmed that each fact or claim that's challenged or likely to be challenged has an inline citation to a reliable source; and
+
You've reviewed the English language text and confirmed that each fact or claim that's challenged or likely to be challenged has an inline citation to a reliable source which supports the fact or claim; and
You may only use machine translation tools that include a large language model element to translate text from a foreign-language Wikipedia into the English Wikipedia mainspace when:
a) You have dual fluency, which means you speak both the origin language and English well enough to confirm that the translation is accurate;
b) You've checked for AI hallucinations and you confirm that you've removed all of them;
c) You've checked the sources in the origin language article and you confirm the translated text reflects them fairly;
d) You've reviewed the English language text and confirmed that each fact or claim that's challenged or likely to be challenged has an inline citation to a reliable source which directly supports that fact or claim; and
You may put the raw output of LLM-translated text into your userspace (preferred) or draftspace while you work on it, but if you do, you must clearly tag it as automatically translated text needing review from a human with dual fluency. That tag must be in place from first creation.
Should probably list out what machine translation tools we are talking about. I've had discussions with people who refuse to believe DeepL, for example, uses an LLM, even when directly linked to DeepL itself talking about its LLM. Other people simply aren't aware.
Should add something about the text being otherwise compliant with article standards for WP:NPOV, WP:OR, WP:SYNTH, etc. I know that's in our general translation guidelines already but still.
Last paragraph should state "LLM-translated" rather than "automatically translated," like I said, "regular" machine translating and LLM translating tend to make different mistakes and reviewers should know which one they need to especially be aware of.
I don't think we should itemize the translation tools because there will be new ones and we don't want people going, "Well I used a tool that isn't on the list so it's fine, isn't it?" We mean any translation tool with a LLM element. But I can reasonably add language to reflect that.
I'm afraid I'm going to need to say no to listing out all the core content policies. We're heading for a "shall we promote this rule to guideline?" type RfC here and people will definitely piss and moan about rules bloat. Each word counts against us. WP:CREEP is the single most likely thing to sink the RfC and besides, I don't think anyone's going to get as far as reading this proposed guideline without being aware of en.wiki core content policy.
I do think it's right to reiterate the "challenged or likely to be challenged" bit of WP:V because the mere fact that AI was involved is a factor that increases the chance of a challenge.āS MarshallT/C20:27, 4 January 2026 (UTC)[reply]
Main reason I mention that is because I guarantee people are going to think "well I didn't use ChatGPT so I didn't use AI." And the latter part is because I guarantee people will be like "well I did everything on the checklist so I'm fine." Gnomingstuff (talk) 20:56, 4 January 2026 (UTC)[reply]
I'm a big fan of this. A small suggestion: For "b", not everyone knows what "hallucination" means in this context, so I would at minimum wikilink it to further explanation, or just explain it in the guidance. Maybe something like: "b) You've checked that the AI has not rephrased or inserted text in a way that implies information that was not implied in the origin language, and have removed any such hallucinations.". -- LWGtalk(VOPOV)19:47, 4 January 2026 (UTC)[reply]
Proposal 4
Scope: The following rules apply to machine translation tools that include a large language model ("LLM") element. Most automated translation tools include a LLM nowadays. Translator should assume that these rules apply to your translation tool unless you've checked and confirmed that there's no LLM element.
You may only use machine translation tools that include a LLM element to translate text from a foreign-language Wikipedia into the English Wikipedia mainspace when:
a) You have dual fluency, which means you speak both the origin language and English well enough to confirm that the translation is accurate;
b) You've checked for AI hallucinations and core content policy violations, and you've removed all of them;
c) You've checked the sources in the origin language article and you confirm the translated text reflects them fairly;
d) You've reviewed the English language text and confirmed that each fact or claim that's likely to be challenged has an inline citation to a reliable source which directly supports that fact or claim; and
You may put the raw output of LLM-translated text into your userspace (preferred) or draftspace while you work on it, but if you do, you must clearly tag it as automatically translated text needing review from a human with dual fluency. That tag must be in place from first creation.
While I am a strong proponent of brevity in policyā¦ clarity is perhaps more important. If it take more words to be clear as to what is and isnāt appropriate use of AI, so be it.
The following rules apply to machine translation tools that include a large language model ("LLM") element. Most automated translation tools include aLLMnowadays. Translatorshouldassumethatthese rules apply toyourtranslationtoolunlessyou've checked and confirmed thatthere'snoLLMelement.
+
The following rules apply to the use of machine translation tools that include a large language model ("LLM") element. Most automated translation tools include an LLM. These rules apply unless a translator has checked and confirmed for themselves that a tool does not use an LLM.
Stricter wording, no "should".
ā
You've checked for AI hallucinations and core content policy violations,andyou'veremovedallofthem;
+
You've checked for and corrected any AI hallucinations and core content policy violations;
More concise, I think "corrected" more accurately conveys what translators need to do.
I don't think we should allow raw LLM text into draftspace, even if tagged. Draftspace is a shared environment, while this process of creating and correcting machine translated text should be a more individual endeavor with the effort shouldered by the editor who chose to undertake it. Userspace is plenty big. fifteen thousand two hundred twenty four (talk) 21:37, 4 January 2026 (UTC)[reply]
I get this; in practice though people don't tend to mess with other people's drafts. Having gone through a large portion of drafts rejected as AI-generated I almost never see them changed by anyone but the original editor before submission, with the exception of linter bots. Gnomingstuff (talk) 22:03, 4 January 2026 (UTC)[reply]
Even if draftspace as a potentially collaborative environment is mostly (but not entirely) aspirational, it's one that I don't mind trying to uphold.
There's some other issues too: like increased likelihood of drive-by AfC submissions or spurious mainspace moves, or that a stalled LLM draft may end up effectively soft-salting a title until G13 reclaims it or a rather bold editor overwrites it (not likely for a newcomer to do).
Having read Mr Marshall's proposals, I find that they may well be adequate as rules, but how will they be enforced? Rules without teeth are a waste of time. There is a risk that making such rules without providing for a clear enforcement mechanism will encourage more editors to use these tools in an undesirable manner. As with other LLM content, we can expect editors to say they followed all the rules, they reviewed all of the content, &c., &c., but in practice, will they have done so? The likelihood is, sadly, no ā then the cavalcade of cleanup begins. Are we going to create a new speedy deletion criterion for machine translations that do meet the proposed standard? Personally, I would much rather we created a user right the clearly controlled who is permitted to perform machine-assisted translation, as I described above. Mr Marshall's proposals would serve as a nice base for the terms and conditions that seekers of this right would have to agree to. Yours, &c.RGloucester ā ā23:27, 4 January 2026 (UTC)[reply]
An editor who would disregard and be deceptive about these rules would disregard permissions-based rules too right?
how will they be enforced? ā G15 is an option if the page is eligible. If not then move the page out of mainspace and into user/draftspace with the appropriate tags, this is in line with what the proposed rules already disallow and allow. If an editor repeatedly violates the rules then that's simple disruptive editing and can be dealt with accordingly. What more needs to be defined? fifteen thousand two hundred twenty four (talk) 00:25, 5 January 2026 (UTC)[reply]
If a user right were created, the community and granting administrators could exercise control over who could be granted that right. Much as with autopatrolled, the right could be revoked when problems are discovered. Moreover, machine-translated pages created by editors without the right could be speedily deleted using a new speedy deletion criterion. In other words, a user right would allow a higher level of control. I am not opposed to enacting rules as described in any of the proposals above, and it is possible that, much as with WP:NEWLLM, simple is best. I am simply concerned that creating rules may give certain editors the green light to mass produce machine-translated articles... Yours, &c.RGloucester ā ā00:38, 5 January 2026 (UTC)[reply]
I don't understand how c) and d) can co-exist. If you've c) checked the sources and the translated text reflects them, then surely d) is met by default? On the other hand, if you do what d) says and only ensure sourcing for contentious statements, then you haven't done c) as c) can't be done if text is unsourced. CMD (talk) 01:35, 5 January 2026 (UTC)[reply]
I can write text that reflects what the sources mean, but nevertheless doesn't contain an inline citation for each surprising or contested fact.
I can also write text that contains an inline citation for each surprising or contested fact, but nevertheless isn't a fair reflection of what the sources mean.
You can write text that reflects what the sources mean without inline references (although not best practice on en.wiki), but that is a different ask to translating someone else's writing while checking sources. As for not reflecting sources fairly, that is something that should be done for inline sources as well. CMD (talk) 02:04, 5 January 2026 (UTC)[reply]
Whether the editor can "speak" (this language; or at all) is an irrelevant consideration for Wikipedia. I suggest going back to version #1, and shortening it to You have sufficient knowledge of both... Editors need to be able to "read" the source language and "write in English", or to "know" or "understand" both languages. Introducing wording like "dual fluency" will only result in disputes over what those words mean, and some desirable translators saying their skills aren't good enough because they only understand the source, but they are slow to speak in that language, so they don't consider themselves fluent (some people understand language fluency to mean the smoothness and rapidity with which they speak). WhatamIdoing (talk) 02:56, 5 January 2026 (UTC)[reply]
So:
These are the circumstances when you may use machine translation tools that include a large language model element to translate text from a foreign-language Wikipedia into the English Wikipedia mainspace:
a) You have sufficient knowledge of both the origin language and English to verify that the translation is accurate;
b) You've checked the sources in the origin language article and you confirm the translated text reflects them fairly; and
c) You've reviewed the English language text and revised it where necessary before moving it to mainspace.
You may put the raw output of LLM-generated text into your userspace (preferred) or draftspace while you work on it, but if you do, you must clearly tag it as LLM generated text requiring review from a human with dual fluency, and that tag must be in place from first creation.
Scope: The following rules apply to machine translation tools that include a large language model ("LLM") element. You should assume that these rules apply to your translation tool unless you've confirmed that there's no LLM element, as most include them nowadays.
You may only use these tools to translate text from a foreign-language Wikipedia into the English Wikipedia mainspace when:
a) You have dual fluency, which means you speak both the origin language and English well enough to confirm that the translation is accurate;
b) You've checked for, and removed, AI hallucinations and core content policy violations;
c) You've checked the sources in the origin language article and you confirm the translated text reflects them fairly, and that each fact or claim likely to be challenged is supported by an inline citation to a reliable source; and
You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, you must immediately tag it as automatically translated text needing review from a human with dual fluency.
I must agree with what WhatamIdoing said above ā the ability to 'speak' is quite irrelevant. I would replace the text of a) with 'You have sufficient proficiency in both the origin language and English to verify that the translation is accurate'. 'Dual fluency' in the final line can be replaced with 'proficiency in both the origin language and English'.
Additionally, the term 'foreign language' is othering in the context of our global encyclopaedia. There is a high likelihood that the relevant language will not be 'foreign' to whomever is reading this text. Hence, I would suggest replacing this terminology with 'text from a Wikipedia written in a language other than English'. Yours, &c.RGloucester ā ā06:04, 5 January 2026 (UTC)[reply]
Scope: The following rules apply to machine translation tools that include a large language model ("LLM") element. You should assume that these rules apply to your translation tool unless you've confirmed that there's no LLM element, as most include them nowadays.
You may only use these tools to translate text from another Wikipedia language edition into the English Wikipedia mainspace when:
a) You have sufficient proficiency in both the origin language and English to verify that the translation is accurate;
b) You've checked for, and removed, AI hallucinations and core content policy violations;
c) You've checked the sources in the origin language article and you confirm the translated text reflects them fairly, and that each fact or claim likely to be challenged is supported by an inline citation to a reliable source; and
You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, you must immediately tag it as automatically translated text needing review from a human with proficiency in both languages.
This looks like a good start to me. I think the next issue will be to find a home for this guidance. WP:TRANSLATION? WP:NEWLLM? WP:TRANSLATION isn't a policy or guideline, but if this proposed text were to enter force as part of WP:NEWLLM, WP:MACHINE would require reconsideration. There is also the additional consideration that NEWLLM may be completely changed in the coming days, depending on the outcome of the ongoing RfC. Yours, &c.RGloucester ā ā07:33, 5 January 2026 (UTC)[reply]
Scope: These rules apply to machine translation tools that include a large language model ("LLM"). Assume these rules apply to any online translation tool unless you've confirmed there's no LLM element.
You may only use these tools to translate text from a non-English Wikipedia into the English Wikipedia mainspace when:
a) You know both the origin language and English well enough to confirm the translation is accurate;
b) You've checked for, and removed, all AI hallucinations and core content policy violations;
c) You've checked the sources in the origin language article and you're sure the translated text reflects them fairly, and each fact or claim likely to be challenged is supported by an inline citation to a reliable source; and
You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, you must immediately tag it as automatically translated text needing review from a human who knows both languages.
I'm afraid I do not quite understand what 'know' means in this context, and do not find this vague phrasing helpful. One can 'know' a language without having proficiency sufficient to conduct a thorough review. I must also object to the term 'confirm' in point a) ā the correct term should be 'verify'. Yours, &c.RGloucester ā ā09:36, 5 January 2026 (UTC)[reply]
I believe that 'know' is detailed later on in the sentence (well enough to confirm the translation is accurate), although I agree that 'verify' would be better suited than 'confirm' to avoid a rubber-stamp effect. Chaotic Enby (talk Ā· contribs) 09:57, 5 January 2026 (UTC)[reply]
Regarding 'know', yes, I saw that 'well enough to confirm the translation is accurate' is appended in the first instance, but it is missing in the second. Moreover, I am not sure that 'knowledge' of a given language is sufficient. I expect translators to have the facility to use the language, rather than to merely 'know' it. Regarding 'verify', Mr Marshall, it is precisely because the term has that meaning on Wikipedia that I believe it should be adopted here. I expect translators to verify that any translation produced is faithful to and clearly supported by the source text. A mere confirmation or check is altogether out of the question. Yours, &c.RGloucester ā ā10:12, 5 January 2026 (UTC)[reply]
Seconding this, we want "verify" in the technical Wikipedia meaning (analogous to point c) where we want the translators to also verify it with respect to the cited sources). Chaotic Enby (talk Ā· contribs) 10:15, 5 January 2026 (UTC)[reply]
We want both. We certainly want "verify" with the inline citations as in point c, but we also want the translator to make sure the translated text has the same meaning of the origin language text. This matters because "verify" means "prove by reference to someone else's publication". In this case we want the translater to use their own knowledge of both languages to make sure the translated text conforms to the origin language sources. That's not the same thing as WP:V at all.āS MarshallT/C10:42, 5 January 2026 (UTC)[reply]
In that case, I presume it means "verify (the translation output) by reference to the source (being translated from)", which is analogous to WP:V (for which we also presume the ability to read the language of the sources to verify the text). Chaotic Enby (talk Ā· contribs) 10:46, 5 January 2026 (UTC)[reply]
Although honestly, I believe this is really a nitpick and wouldn't mind if another word was used in place of "verify", as having a guideline is much more important than a single word choice. Chaotic Enby (talk Ā· contribs) 10:47, 5 January 2026 (UTC)[reply]
I would be most inclined to write something like "You have sufficient proficiency both in the origin language and in English to be sure that the translation is accurate", avoiding both "know" and "verify" for the reasons indicated above. (But any of the phrasings discussed gets the point across tolerably well, I would say.) Dionysodorus (talk) 10:51, 5 January 2026 (UTC)[reply]
Pomposity is one thing ā but, I must protest. Proficiency and knowledge are not one and the same. If 'proficiency' is intolerable, consider 'ability'. Yours, &c.RGloucester ā ā11:08, 5 January 2026 (UTC)[reply]
On second thoughts, perhaps it is best to avoid "proficiency", since we want this guideline to be understood by people whose English may not be very good, and they might not know the word. Maybe "know" is better after all: it's less exact than "proficiency" or "ability", but perhaps gets the point across more concisely and clearly. Dionysodorus (talk) 11:43, 5 January 2026 (UTC)[reply]
Mr Marshall, perhaps your understanding of translation is different from mine, but I do not want translators to rely solely on their 'own knowledge' to evaluate whether a translation is faithful to the source text. Translation is first and foremost an exercise in one's research skills, rather than one's language ability. In many ways, it is similar to writing a Wikipedia article. One needs to fully understand the source text before proceeding to the translation stage, and to do that, one needs to consult dictionaries, examples of similar texts in both languages, and reference materials related to the relevant subject matter. Then, one needs to fully understand the correct style for the translation output ā in Wikipedia's case, this means one will need a full grasp of our policies and guidelines. One's 'knowledge' of language alone is hardly sufficient. Finally, there is the quality assurance stage. The translated text must be checked against the original, to verify that the translation is supported by the source. This kind of verification is indeed, analogous to WP:V. The original text is a source that must support the translation. Yours, &c.RGloucester ā ā10:58, 5 January 2026 (UTC)[reply]
I think that if you can't read a foreign-language Wikipedia article without a dual dictionary and a model text, then there's too high a risk of errors when you translate it into English. I think you should confine yourself to translating articles you fully understand including all the idioms. I would translate from French or German because I speak those languages, meaning I could hold a conversation with a native speaker without resort to dictionaries or phrasebooks. They'd know I was English from my accent but, barring certain technical subjects, certain unconventional dialects, or old texts in pre-modern language variants, there'd be no risk of confusion about meaning. I know Portuguese well enough to read it with a dual dictionary but there's no way I'd attempt to translate from the Portuguese Wikipedia.āS MarshallT/C11:09, 5 January 2026 (UTC)[reply]
On reflection: I think differently about someone who knows lots of languages. Once someone can fluently read four or five Western European languages, I do trust them to translate other Western European languages with a dual dictionary, because when they're at that stage of linguistics, they know what to look for in terms of false friends and grammatical gotchas.āS MarshallT/C11:16, 5 January 2026 (UTC)[reply]
Idiom is hardly the issue. The translator's defining trait is that he knows very little. He often translates texts in fields with which he has limited familiarity, and no matter what he does, he cannot jump into the author's head and understand precisely what was meant by any given turn of phrase or piece of specialist language. Sometimes, he may be able to ask the author, other times not. No text is so perfect that it lacks any ambiguities or unclear points, nor is any translator capable of knowing every word in a given tongue, even his mother one! A good translator must be humble ā do not presume to know what one cannot, and never rely on supposition alone. He takes full advantage of whatever information is available to him and proceeds with care. Of course, the degree to which outside information is required depends on the level of the text to be translated. A translator's knowledge alone, however, is no more certain than that of any other human being. Yours, &c.RGloucester ā ā11:25, 5 January 2026 (UTC)[reply]
I think this is as good as it's going to get for a set of guidelines allowing it, although my actual preference is a user-right and/or mandatory public disclosure of the final product. Gnomingstuff (talk) 13:48, 5 January 2026 (UTC)[reply]
The current proposal is focused on the translation of one Wikipedia article into EN WP. Would it make sense to extend the scope to make this guideline also applicable for translation of non-WP content into WP?
It makes more sense to first focus on drawing up a guideline for translation between Wikipedia editions, and then see if it makes sense to expand it to other kinds of translations (and how to adapt it), instead of aiming for an overly broad guideline that might make it harder to discuss concrete specifics. Chaotic Enby (talk Ā· contribs) 14:31, 5 January 2026 (UTC)[reply]
That makes sense to me. Then I would suggest a small tweak in this sentence:
"You may only use these tools to translate text from a non-English Wikipedia into the English Wikipedia mainspace when..."
--> current wording could be perceived as "translation tools can only be used for translation of Wikipedia text" (which would imply it forbids translation tools for any other purpose).
To avoid any ambiguity, what about something like:
"When translating text from a non-English Wikipedia into the English Wikipedia mainspace, you may only use these tools when..." 7804j (talk) 14:40, 5 January 2026 (UTC)[reply]
Two thoughts. Like I said above, I don't support the requirement to disclose the tools used. It's discriminatory and privacy-invading, and will be habitually ignored my most editors anyway (I don't mind recommending this as a best practice, but I strongly oppose requiring this). Second, I am not sold on a). Most people today use machine translation for nearly everything, including checking sources, and this is going to become even more common in the future (whether we like it or not), also reducing the number of people learning other languages. If someone translates text from A wiki to B wiki, they should double check it by using a different tool, but they don't need to be speak the original language themselves. Ex. they can use ChatGPT to translate content, and the browser build-in translate-a-web-page functionality to double check if things match. That's what I see most of my students are doing, and I don't think it is realistic, or necessary, to expect more from an average person - or editor. Setting unrealistic, pie-in-the-sky standards is just going to create rules that are going to be regularly broken, making folks pay even less attention to the rules that should matter. Piotr Konieczny aka Prokonsul Piotrus| reply here03:54, 22 January 2026 (UTC)[reply]
I would enthusiastically support the current version, although I would also be okay with it being proposed as part of a user right. Perfect is the enemy of good, and opposing this because it doesn't have all the perfect details means that we risk ending up with a consensus against any form of regulation. Chaotic Enby (talk Ā· contribs) 18:13, 5 January 2026 (UTC)[reply]
I guess I don't know why "don't translate articles with AI" is off the table. Let alone "don't pay people to translate articles with AI in a way that skates right at the edge of policy." Gnomingstuff (talk) 04:21, 6 January 2026 (UTC)[reply]
Is this enough RFCBEFORE? Sure, but even nothing is "enough". If you actually go read WP:RFCBEFORE, you'll find that it's not about pre-discussing a proposal. (It's about choosing non-RFC alternatives, as in "'BEFORE' you start an 'RFC', maybe try asking for help at the Teahouse.") WhatamIdoing (talk) 17:25, 6 January 2026 (UTC)[reply]
Proposal 7
Scope: These rules apply to machine translation tools that include a large language model ("LLM"). Assume these rules apply to any online translation tool unless you've confirmed there's no LLM element.
You may only use these tools to translate text from a non-English Wikipedia into the English Wikipedia mainspace when:
a) You have sufficient ability in both the origin language and English to verify the translation is accurate;
b) You've checked for, and removed, all AI hallucinations and core content policy violations;
c) You've checked the sources in the origin language article and you're sure the translated text reflects them fairly, and each fact or claim likely to be challenged is supported by an inline citation to a reliable source; and
You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, you must immediately tag it as automatically translated text needing review from a human who is proficient in both languages.
To address the concerns I expressed above, please allow me to propose another iteration. 'Knowledge' of a language is quite different from 'ability' to verify that a translation is accurate. Yours, &c.RGloucester ā ā21:27, 5 January 2026 (UTC)[reply]
Proposal 8
Scope: These rules apply to machine translation tools that include a large language model ("LLM"). Assume these rules apply to any online translation tool unless you've confirmed there's no LLM element.
You may only use these tools to translate text from a non-English Wikipedia into the English Wikipedia mainspace when:
a) You are sufficiently skilled in both the origin language and English to verify the translation is accurate;
b) You've checked for, and removed, all AI hallucinations and core content policy violations;
c) You've checked the sources in the origin language article and you're sure the translated text reflects them fairly, and each fact or claim likely to be challenged is supported by an inline citation to a reliable source; and
You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, you must immediately tag it as automatically translated text needing review from a human who is skilled in both languages.
Both fail because they omit 7804j's change as discussed with Chaotic Enby, and less seriously because "sufficiently skilled" reduces to "skilled enough".āS MarshallT/C23:13, 5 January 2026 (UTC)[reply]
I was hoping to ensorcell you with the alliteration. In any case, 'skilled enough' is more than satisfactory, if less prosodic. Yours, &c.RGloucester ā ā10:13, 6 January 2026 (UTC)[reply]
Feel free to edit this proposal
Scope: These rules apply to machine translation tools that include a large language model ("LLM"). Assume these rules apply to any online translation tool unless you've confirmed there's no LLM element.
When translating text from a non-English Wikipedia into the English Wikipedia mainspace, you may only use these tools when:
a) You are skilled enough in both the origin language and English to confirm the translation is accurate;
b) You've checked for, and removed, all AI hallucinations and core content policy violations;
c) You've checked the sources in the origin language article and you're sure the translated text reflects them fairly, and each fact or claim likely to be challenged is supported by an inline citation to a reliable source; and
You may put the raw LLM-translated text into your userspace (preferred) or draftspace while you work on it. If you do, you must immediately tag it as automatically translated text needing review from a human who is skilled in both languages.
This is well-written and I would support as is. Thanks to all who drafted. However, there is a ton of evidence that machine-generated text is rarely sufficiently reviewed to be compliant with core content policies. So I would prefer machine translation to be limited to users with a specific user right OR required to go through independent spot-checking prior to moving to article space. Likely a discussion for later. NicheSports (talk) 07:02, 6 January 2026 (UTC)[reply]
I believe it's better to start with a baseline guideline we can all agree on, and, if it isn't followed by most users involved, we'd have a good reason to limit it to a user right. Chaotic Enby (talk Ā· contribs) 08:41, 6 January 2026 (UTC)[reply]
I think there's enough support for gating it behind a user right that we need to offer that as an explicit option at the RFC. Something like:Option A: Do not adopt this as a guideline.Option B: Adopt this as a guideline.Option C: Adopt this as a guideline but editors must also have a specific user permission before using AI-aided translation tools. Details about how this would work to be agreed separately.āS MarshallT/C08:55, 6 January 2026 (UTC)[reply]
As I said above, I am strongly in favour of a user right, with the proposed text serving as the terms that holders of the right must abide. I would be very content with a three-pronged RfC. Yours, &c.RGloucester ā ā10:17, 6 January 2026 (UTC)[reply]
This looks good, but given the recent kerfuffle about the admin recall RFCs we should encourage people to be explicit about which options they support (e.g. does someone supporting C also support B as a second choice or is their support for C only?). Thryduulf (talk) 12:20, 6 January 2026 (UTC)[reply]
The line about "each fact or claim likely to be challenged is supported by an inline citation to a reliable source" sets a higher standard for translated articles than for non-translated articles. Is that really what we want to do? WhatamIdoing (talk) 18:07, 6 January 2026 (UTC)[reply]
Wikipedia:Verifiability does state that four types of information must be accompanied by an inline citation to a reliable source that directly supports the material: [...] material whose verifiability is likely to be challenged, so this is in line with our policies. Beyond that, I can think of two reasons why this is beneficial to emphasize:
Many Wikipedia editions are much less rigorous than English Wikipedia in terms of sourcing, so we want to be careful with importing unsourced content
This is magnified by organizations paying editors to translate articles, and we should make sure they're privileging quality over quantity
Oh there's a grammatical ambiguity. I meant it to parse each / fact or claim / likely to be challenged but I wonder if WAID's parsed it each fact / or claim likely to be challenged?āS MarshallT/C21:35, 6 January 2026 (UTC)[reply]
The literal reading of WP:V sets a much lower bar than what is expected in practice, is what the issue seems to be. I agree with Chaotic Enby that it doesn't work in this situation, as porting over unsourced text for a topic you may well be unfamiliar with is a different situation to writing something you know to be verifiable. CMD (talk) 00:35, 7 January 2026 (UTC)[reply]
Let's say you are. Is that text a fact or claim that's challenged or likely to be challenged? If it's not, then you don't need a citation. Personally I think that the fact that a LLM was involved increases the likelihood of a challenge.āS MarshallT/C16:30, 12 January 2026 (UTC)[reply]
I agree with the goal here, but I think this goes too far. Most of these requirements are already covered by existing content policies, and turning them into a strict checklist risks scaring off careful translators rather than stopping bad ones.
For me the key point is still simple: translation isnāt āfrom scratchā. If someone actually knows both languages, checks the output against the original and the sources, and removes hallucinations, then LLM-assisted translation is fine. Grudzio240 (talk) 12:05, 8 January 2026 (UTC)[reply]
This is why it's a guideline reminding translators of what to keep in mind, not a policy or a strict checklist. It is, pretty much, a more precise wording of the same key point you've highlighted. Chaotic Enby (talk Ā· contribs) 12:19, 8 January 2026 (UTC)[reply]
I'm not a native English speaker, but this last version sounds very strict and categorical to me. E.g.: "When translating ā¦ you may only use these tools when:" followed by a list of conditions reads like a prohibition-with-exceptions, not a guide/reminder. Would you be open to rephrasing to something like āIf you use an LLM-assisted machine translation tool, make sure that:ā (aād) ā same substance, but less rule-like / checklisty? Grudzio240 (talk) 13:50, 8 January 2026 (UTC)[reply]
If you don't intend a rule to be rigidly enforced by rule-followers, then you should not put it on a page labeled {{guideline}}. It just doesn't work in this community. Even if you write a rule as "As an optional suggestion, check A and B", you'll find the occasional person saying "The guideline says you need to "check A and B"". They won't necessarily be trying to mislead (though with about three-quarter million registered editors making 1+ edits per year, one may encounter now and then an editor whose truthfulness you doubt a bit), but then our telephone game kicks in, and it'll be passed along as The Truthā¢. WhatamIdoing (talk) 02:17, 12 January 2026 (UTC)[reply]
What you are describing is already the difference between a policy and a guideline. The fact that one might be misinterpreted as the other (even if clearly described as such) doesn't mean we shouldn't have guidelines if we don't intend to make them absolute policies. Chaotic Enby (talk Ā· contribs) 18:27, 12 January 2026 (UTC)[reply]
Wikipedia:The difference between policies, guidelines, and essays is subtle and variable. Nothing that I wrote above is the difference between a policy and a guideline. Rigid enforcement, in particular, is not the difference between policies and guidelines. (If this isn't instantly obvious to anyone reading this comment, then tell us exactly how we could rigidly enforce the Wikipedia:Ignore all rules policy.)
What I'm describing is the inevitable human process of taking some good advice, passing it around (mostly by word of mouth), and ending up with "a rule" that says you have to cut the ends off the pot roast, only it turns out that the "rule" depended on the circumstances and never was meant to be rigidly enforced across all circumstances. If your goal is to have something useful for reminding translators of what to keep in mind, not a policy or a "strict checklist", then we can do that, but we need to write different words to accomplish that goal. For example:
Don't write "When translating text from a non-English Wikipedia into the English Wikipedia mainspace, you may only use these tools when"
Do write "Here's some advice that will help you produce high-quality translations".
This is the "translate then fix" vs "fix as you translate" thing I've brought up several times as needing to be decided before we can have any guidelines like the ones being discussed in the RFC. We presently have some editors complaining that "you didn't translate it accurately" when someone fixes errors in the source and others complaining that "there aren't enough sources" when someone accurately translates an under-sourced (by en.wp standards) article. Both have their pros and cons but they can't exist simultaneously if we want to allow any translation at all. Thryduulf (talk) 04:57, 12 January 2026 (UTC)[reply]
They can exist simultaneously in User subpages or Draft space, where my impression is that piles of core P&G (like WP:Notability, WP:Verifiability, use of reliable sources) do not apply (but some legal ones still do, like libel, copyvio, and maybe some others). I see no reason why translator-users cannot do it any which way they please in Draft, and the guideline, whatever it turns out to be, only becomes relevant when it gets moved to main spaceāexactly like WP:N, WP:V, and WP:RS. If this guideline will apply retroactively to what happens pre-release, it will be the first one that does, to my knowledge. Mathglot (talk) 05:13, 12 January 2026 (UTC)[reply]
They can't exist simultaneously because editors are not letting it. Translations are meant to be both accurate to the original language and compliant with en.wp standards which is a problem if the original language article isn't compliant with en.wp standards according to the requirements proposed in the RfC. Whether accuracy or our standards are more important depends on the reviewer. Thryduulf (talk) 05:22, 12 January 2026 (UTC)[reply]
Some editors complaining that "you didn't translate it accurately" when someone fixes errors in the source: this is a misrepresentation of the issues that have been brought up, as the complaints are either due to the addition of unsourced text, or to the addition of false sources that do not verify the text. I haven't seen anyone complain about someone fixing actual errors or adding correct sources, and in fact many OKA users have adapted their translated material to en.wiki standards with no issue. Chaotic Enby (talk Ā· contribs) 18:30, 12 January 2026 (UTC)[reply]
I haven't seen anyone complain about someone fixing actual errors...assuming the would-be complainer recognizes that they were actual errors instead of translation errors. WhatamIdoing (talk) 22:37, 12 January 2026 (UTC)[reply]
Steps b and c are vital in this processā¦ they are the only way we can ensure that the original (non-English) article wasnāt itself created using an LLM. The one thing we DONāT want is an English LLM translating crap from a non-English LLM. Blueboar (talk) 02:03, 13 January 2026 (UTC)[reply]
Yeah that's a whooooooole other can of worms. I'm not aware of any research into signs of LLM-generated text in languages other than English. The French Wikipedia has this, seems to reference the English text studies in a few places but also appears to have some stuff of their own. Gnomingstuff (talk) 21:07, 13 January 2026 (UTC)[reply]
Reiterating, I strongly object to the requirement to disclose the tool used (it's discriminatory and privacy-invading). And next to nobody is going to be following step c) anyway. These rules are not going to be followed, as they create standards that are too high for average editor, we are talking Featured level expectations here. Piotr Konieczny aka Prokonsul Piotrus| reply here03:57, 22 January 2026 (UTC)[reply]
I find (c) actively harmful: "You've checked the sources in the origin language article and you're sure the translated text reflects them fairly, and each fact or claim likely to be challenged is supported by an inline citation to a reliable source." The important thing for us is not whether the original article is properly sourced, but whether the resulting English version is properly sourced. In fact, this rule will eliminate most cases of article translation because the sources in the original article are likely to be in the original language and inaccessible to the English translator. The only requirement should be that material in the new article that should be sourced has reliable sources that support it. Whether they are the original sources that the translator has checked or new sources that the translator has found is a secondary issue. The whole focus of the rule set should be on producing English articles that meet our standards, but (c) is an obstacle to that. Zerotalk05:02, 22 January 2026 (UTC)[reply]
Nothing in this proposal stops editors from reading the original sources and producing an article in their own words. If you're doing that, then you're not translating an article from a foreign-language Wikipedia into English. What you're doing is writing a fresh Wikipedia article based on foreign-language sources. Frankly, that's often the best way.These rules specifically apply to translating an article from a foreign-language Wikipedia. If you're going to do that, then we propose to require you to read the sources to make sure that the origin-language article is accurate and doesn't contain hoaxes, disinformation, marketing, etc.āS MarshallT/C09:28, 22 January 2026 (UTC)[reply]
Yes! Because "read the sources" and "make sure the article is accurate and doesn't contain hoaxes, disinformation, marketing, etc." and "make sure everything challenged or likely to be challenged has an inline citation to a reliable source" are exactly the same as meeting the featured article criteria.āS MarshallT/C11:09, 22 January 2026 (UTC)[reply]
We don't check this outside FA review (and occasional GA, depending on a reviewer). I see no reason to require translations to meet such high standards - higher than what we require from average AfCs (where, again, reviewers will often not check this). And per WP:AfC (which per this explicitly allows general references - i.e. no footnotes, which I think is way too lax). Translations should not be held to higher standards than AfCs are. Piotr Konieczny aka Prokonsul Piotrus| reply here11:33, 22 January 2026 (UTC)[reply]
On your first point: it's core content policy that each fact or claim that's challenged or likely to be challenged must be supported by an inline citation to a reliable source. This isn't FA or GA. It's the minimum standard for an article to be in mainspace.On your second point: Yes, on a philosophical level translation should be held to a somewhat higher standard than AfC. AfC is for content that someone has researched and written. Translating is easier and can be done faster, so it's reasonable for there to be a requirement to check the words that you're translating.āS MarshallT/C12:07, 22 January 2026 (UTC)[reply]
Re the first point: WP:AFCSTANDARDS state that "The content and sourcing policies require inline citations for only four specific types of material, most commonly direct quotations and contentious material about living persons.". This seems to be the minimal standard.
Re the second point: I don't follow. Yes, translating is easier, but so what? It's like saying "I spend an hour a day editing Wikipedia, so everyone who cannot do at least that much doesn't deserve respect" or "using citation templates is better, but more time consuming than using bare URLs, so people who use bare URLs should be banned". I dislike bare URLs, but, like it or not, it's allowed for folks not to format citations, and I doubt community would be amenable to banning folks who don't format them. Or who are less active than you or me, or otherwise fail to meet our quality output. No, I don't expect or require most people to meet us, the long tail 1%, at our level, and forcing the issue is just going to backfire (WP:BITE comes to mind). Piotr Konieczny aka Prokonsul Piotrus| reply here12:58, 22 January 2026 (UTC)[reply]
"Demonstrate"? You don't exactly need to be Sherlock Holmes to see that AFCSTANDARDS is out of sync with core content policy there.āS MarshallT/C16:25, 22 January 2026 (UTC)[reply]
I thought Watson did all the thinking. I do like your proposals, but I think you need to add something about cultural and political aspects. An example would be issues related to Renminbi manipulation and Renminbi currency value which in different countries could have RS sources all the way but say different things. There are things you don't type in Chinese if you know what is good for you. I think Watson would agree with that. Yesterday, all my dreams... (talk) 17:07, 22 January 2026 (UTC)[reply]
Or there's also possibility 3, which is that you're mistaken about how AFCSTANDARDS work and I shouldn't have believed you. Now that I investigate, I see that the relevant part of WP:AFCSTANDARDS says:
The content and sourcing policies require inline citations for only four specific types of material, most commonly direct quotations and contentious material about living persons.
The "four specific types of material" is a wikilink to WP:MINREF. WP:MINREF says:
So we see that WP:AFCSTANDARDS does require an inline citation for any statement that has been challenged or is likely to be challenged before an article can be moved to mainspace. The whole thing's a red herring. QED.āS MarshallT/C09:27, 23 January 2026 (UTC)[reply]
I fail to see how rule (c) will eliminate most cases of article translation because the sources in the original article are likely to be in the original language and inaccessible to the English translator, given that (a) mandates understanding of the original language. Rosbif73 (talk) 10:36, 22 January 2026 (UTC)[reply]
S Marshall seems to have missed my point entirely. To Rosbif73: "inaccessible" doesn't only mean "can't read" but also "can't access". Editors in English-speaking countries will frequently have difficulty locating works written in foreign languages. I have this problem all the time with books in Hebrew cited by he.wiki. The fact that a book is only available in Israel shouldn't prevent me from translating an article and substituting fine English sources. In fact our general preference for English sources tells me that it is the preferred option. Also, a general point is that a policy about "translating an article" will not be understood as only referring to "translating everything in an article and using the same references". Zerotalk12:34, 22 January 2026 (UTC)[reply]
I don't think anyone should be translating content they can't check checking the content is correct does not necessarily require checking the exact same source. Many US news sites are unavailable in Europe (they don't wish to comply with the GDPR being the usual reason), which means that I cannot verify that source supports the text. I can however find an alternative source about the same subject that I can access and use that to verify the article is correct. The same is true with translations - I might not be able to access a book written in Hebrew but I can access other sources that verify the same content. Unless the book is called out specifically for some reason, and that reason is both pertinent to the article content and not replaceable in some way (e.g. "multiple authors including Smith, Jones and Hall" ā "multiple authors including Smith, Hall and West") then it does not and should not matter whether I use the same sources as the original article, only that the English article is accurate. Thryduulf (talk) 13:15, 22 January 2026 (UTC)[reply]
I agree that if you can use an alternative source to check each fact or claim that's likely to be challenged, then that should be a permissible alternative, and I wouldn't object to a rephrase that says that more clearly.āS MarshallT/C13:37, 22 January 2026 (UTC)[reply]
I see what you mean about access, particularly with offline sources. More generally, if for whatever reason the translator can't access the source cited in the original language version, but can verify claims using some other source, then of course that should be acceptable. Rosbif73 (talk) 13:00, 22 January 2026 (UTC)[reply]
And now that we're all agreed on this common-sense approach, it should be obvious that the proposal needs to be adjusted.
While we're at it, @S Marshall, I think we should reflect on this idea that It's the minimum standard for an article to be in mainspace. Full sourcing is not the minimum standard for an article to be in the mainspace; if that were true, then the half-million articles in Category:Articles needing additional references would all be out of the mainspace. Yes, WP:V and BLP impose a requirement. But they don't impose a deadline for meeting the requirement. Requiring full citation at the time of translation is imposing a deadline that is not present in any of the policies. WhatamIdoing (talk) 03:26, 27 January 2026 (UTC)[reply]
Hear, hear. Translations should not be held to a higher standard than creating articles from scratch. (That said, playing my own's devil advocate here, I think many of the tagged articles in mentioned above are legacy of old times, even decades, when our standards were much more lax - which is why I think it's better to talk about current standards, as represented by AfC). Piotr Konieczny aka Prokonsul Piotrus| reply here05:46, 27 January 2026 (UTC)[reply]
Re-reading what I wrote, I will note apples and orange issue. Someone creating an article from scratch is expected to read the references - setting aside the fact that yes, we do still allow addition of unreferenced content to the mainspace (something I am not very happy about, but it's a fact). What we are in arms about here is AI hallucinated content, or text-source integrity (people adding content that appears to be referenced but isn't). And rightly so - this should not be allowed (and frankly, neither should be adding unreferenced content, IMHO). However, a translator is not creating new content (new facts), just changing the language of the content, and IMHO the translator is not required to verify whether the translated content is backed up by citations, just like someone who splits or copies content from one article into a new one (or someone who changes the citation style, and does a bunch of other gnomish things) isn't require to verify that it is supported by the citations. In the end, I think what we have here is a consensus that we don't want AI hallucinations and that translators need to be warned that the tools they are using right now tend to produce them and they need to be careful, and repeated offenders will be dealt with harshly. Separately, I think the community should discuss when we are finally going to stop allowing folks to add unreferenced content to this project - I'd say the sooner, the better. But it is a mostly separate issue (mostly, because realistically, if we allow unreferenced content addition in many contexts, but will force the translators to verify the refs, i.e. we will make adding referenced translated content much more burdensome than adding unreferenced content, the result will be that most translators will stop translating references - hardly a productive outcome). Piotr Konieczny aka Prokonsul Piotrus| reply here05:55, 27 January 2026 (UTC)[reply]
The only thing (with respect to references) that the LLM-assisted translator should be required to check is that the existing references have either been carried over as-is or been replaced by equivalent English-language references, and that any new references the LLM may have added are actually relevant. It would be preferable for them to also check that the existing unchanged references actually verify the claims made, but that shouldn't be an absolute requirement IMO. Rosbif73 (talk) 07:44, 27 January 2026 (UTC)[reply]
I'm afraid I maintain that each and every statement that's challenged or likely to be challenged must have an inline citation to a reliable source.āS MarshallT/C09:51, 27 January 2026 (UTC)[reply]
Agree. Within the entirety of WP:V, only one statement is emphasized in bold: The burden to demonstrate verifiability lies with the editor who adds or restores material. Editors do not get to flaunt flout V by adding new text someone else originally wrote. fifteen thousand two hundred twenty four (talk) 21:49, 27 January 2026 (UTC)[reply]
Argh! Flout. Flaunt has a different meaning. (This is Wikipedia, my horrible pedantry is allowed!)I want to stress that I made that remark in the context of material we might reasonably suspect of being LLM-generated. If a human writes text on Wikipedia in good faith, then they're not expected to be psychic and they don't necessarily know what's controversial and what isn't. Where there's reasonable doubt about whether it's verifiable, then that text usually shouldn't be removed without giving them a reasonable amount of time to cite their source.We have experience with some volunteers who thought it was helpful to go around using WP:CHALLENGE to remove easily-sourceable material, and I don't mean to encourage this at all.āS MarshallT/C22:45, 27 January 2026 (UTC)[reply]
"each and every statement that's challenged or likely to be challenged must have an inline citation to a reliable source". Of course, we can all agree on that. But this is not what we are talking about here, aren't we? The issue is whether we require translators to fact-check sources in the original article, or only these added by LLM. I support the latter, not the former. Piotr Konieczny aka Prokonsul Piotrus| reply here04:43, 28 January 2026 (UTC)[reply]
All of us, including translators, should ensure that what appears on en.Wikipedia is accurate and verifiable. A human translation of bullshit is just as unwelcome as an AI translation of bullshit. Blueboar (talk) 00:53, 29 January 2026 (UTC)[reply]
Assuming an article might be bullshit is not assuming bad faith. People can create bullshit in perfectly good faith. In anything in life where you're relying on someone else's work that came before yours, it is good practice to assume the last person was an idiot and double-check everything they did. It's not assuming bad faith, it's just covering your ass so you don't get blamed if your work inherits the existing problems (case in point here) Athanelar (talk) 01:27, 29 January 2026 (UTC)[reply]
I go back on ocassion to articles I wrote 20 years ago and find some of them to be pretty crappy. There is also the fact that more sources are available to me now than there were 20 years ago. I certainly never intended to, but I know I put things in articles that would fail verification today. So I agree, vetting an article for any reason is not a failure to AGF. Donald Albury02:46, 29 January 2026 (UTC)[reply]
If you're changing the meaning of a sentence materially, then yes, you do need to verify that, as you're essentially making a whole new claim. It just happens that LLMs change the meanings of things all the time. Gnomingstuff (talk) 18:25, 2 February 2026 (UTC)[reply]
The whole point of the proposed guidance is that translators are supposed to check that the LLM's translation reflects the original, so there shouldn't be any significant changes of meaning that would be considered as "whole new claims" needing verification. In any case, if you provide an LLM with existing text to be translated from one language to another (and don't prompt it to "improve" the text in any way), changes of meaning are relatively rare ā unlike the hallucinations that are to be expected if you ask it to draft some text "from scratch". Rosbif73 (talk) 07:37, 3 February 2026 (UTC)[reply]
How my students can help Wikipedia against AI
Hello,
I am a professor at Boston University and am seeking ways to convey to my students the importance of protecting Wikipedia from AI. One of Wikipedia's challenges seems to be that there are not enough volunteers who help edit Wikipedia and who scan articles for AI infestation. Do you need volunteers for this or related tasks? I could make this a task in my courses for extra credit.
Thank you.
Roy Grundmann, Boston University ~2026-32066-8 (talk) 14:44, 15 January 2026 (UTC)[reply]
Ironically, the worst of AI cleanup I had to do were AI edits made by Wiki Ed students who had poor behavior and prioritized checking off their syllabus requirements over anything else and spurred with volunteers by edit warring. Graywalls (talk) 00:25, 16 January 2026 (UTC)[reply]
The sentiment here is appreciated, but I would caution against describing "AI cleanup" as required coursework. Wikipedia struggles less with edit volume and more with editor judgment, care, and consensus. Coursework requiring students to hit quotas can lead inadvertently to a high volume of adversarial or low-effort editing that drives more work for volunteers, not less. That being said, there are positive models for student editing, especially in coursework run through Wiki Education that focuses on sourcing, tone, and norms over edit counts. Emphasizing human-based review, discussion, and consensus will almost certainly have more impact than singling out "AI detection," which will always be imperfect. (Do we run all of Wikiepeida through turitin or GptZero?) End of the day, Wikipedia and society in general may get more value from student participation if we educated students on how Wikipedia worked than editing itself. Sparks19923 (talk) 20:10, 20 January 2026 (UTC)[reply]
That person is an associate professor (not a professor). I also don't see the link between film studies and AI detection.
Serious question: do we believe anyone who claims to be an identifiable living person or do they have to prove that they are who they claim to be? M.Bitton (talk) 01:54, 16 January 2026 (UTC)[reply]
That person is an associate professor (not a professor). In the United States, associate professors are generally tenured professors. Film professors are also allowed to care about inappropriate AI usage. And no, I don't believe everyone claiming to be an identifiable person, but asking how to help fight AI on Wikipedia would be quite the odd form of impersonation. voorts (talk/contributions) 02:01, 16 January 2026 (UTC)[reply]
do we believe anyone who claims to be an identifiable living person or do they have to prove that they are who they claim to be? I made this comment earlier at BLPN [11], so I'm also curious about the answer to that question. Some1 (talk) 02:26, 16 January 2026 (UTC)[reply]
BLPREQUEST and "I'm a professor, how can I help build a good encyclopedia" are two very different circumstances. I see no reason to be suspicious of this editor. If they're not in fact Professor Grundmann, all they've done is make Professor Grundmann look like a good person who wants to help. voorts (talk/contributions) 02:31, 16 January 2026 (UTC)[reply]
Hello, all. I appreciate your concern about my (and anyone's) identity when engaging with this platform. I am in fact a real person, an Associate Professor of Film Studies at Boston University. My name is Roy Grundmann and you can access my website by googling me. They say impersonation is a form of flattery, but given the times we live in (and the advent of deep fakes), I'm not so sure about that anymore. In any case, I contacted this platform because I am getting ready to start the semester and I would like to explore ways of getting my students involved in engaging with Wikipedia and, if possible, helping to stem the tide against AI. Someone from the Wikipedia team has gotten in touch with me and we'll communicate after the holiday weekend. Thanks, everyone, for your concern! ~2026-32066-8 (talk) 13:46, 16 January 2026 (UTC)[reply]
Please let me note that there is a discussion at Wikipedia:Reliable_sources/Noticeboard#Tool_for_detecting_AI_writing? That may relate to this. It is well known that over time adversaries end up seeking and obtaining similar weapons. If one side has tanks, the other side will try to develop tanks, etc. I think WMF will eventually try to develop some AI defensive systems, some type of "super cluebot" system. Text analysis is not my area of expertise but I know that programmers at large will not be able to get it right without expert help. So WMF needs to hire some expert for guidance. Yesterday, all my dreams... (talk) 12:50, 18 January 2026 (UTC)[reply]
Thank you for trying to help Wikipedia by tying it in with your class. We do need more volunteers, and classes can be a good way to get people involved (even if just for the semester). The hesitance you may be observing is that when class projects go wrong, problems are multiplied across many students and ultimately sap volunteer time rather than contribute to it. That said, hundreds of profs have done so in the past through programs like the one Ian (Wiki Ed) works with. I may be wrong, but my sense is that Wiki Ed doesn't support an AI-related cleanup assignment, but they do provide best practices. Things like (a) don't require a particular number of edits, (b) don't grade based on what "sticks" in an article, (c) be sure students understand how to communicate with others on-wiki, (d) be sure students understand Wikipedians -- to be blunt -- care more about our own policies than about their grades/assignments, and saying "but I have to for class" is kind of a sure-fire way to attract extra scrutiny and cynicism. That kind of stuff. WP:AIC, linked above, may have some ideas for possible projects. I'll ping Chaotic Enby, one person I know to be involved there, who may have ideas for an assignment students would be equipped to handle. My hunch is that a good place to start might just be the Wiki Ed article writing assignment, which guides students to write articles and exposes them to the "wiki way" of doing things. If you're already training them to be critical of LLM output, they have a head start. :) Once they start writing, they'll probably be in a better position to understand why and how LLMs can create problems (some fixable, some not). Also, you'll want to register for an account. At minimum, it means you can be notified when someone replies to you, even if it's not on a page you're watching. One final note: if you do run an AI cleanup assignment and it goes well, I think a bunch of folks here would be interested to hear about it! :) ā Rhododendritestalk \\ 18:52, 27 January 2026 (UTC)[reply]
@Rhododendrites I believe Helaine has gotten in touch with them. I suspect we could adapt the assignment to support things like this, but I'm not going to promise anything that depends on other people have the time to do things I don't have the technical skills to help with. Ian (Wiki Ed) (talk) 19:39, 27 January 2026 (UTC)[reply]
Thanks a lot for the ping! An idea that I've always liked for an assignment that lets them get hands-on experience with how AI can generate misinformation: start with prompting the AI to generate an article, paste it in your draft page, and in the next edit, go through the article and review it (by yourself) to see what the AI got right, what it got wrong, and try to clean it up into an actual article. Bonus point if they write a small report (say, on the talk page) detailing what they found to be the AI's strengths and weaknesses in writing an article. You can even give students the choice of trying out different models to compare their results with each other!I've always preferred WikiEd assignments where the students get to work on a new draft rather than editing an existing article. Both for the students, as it gives them a greater sense of self-accomplishment, and for the volunteers, as reviewing drafts is often more streamlined than spotting and cleaning up articles in mainspace. One drawback is that writing an article from scratch is usually harder (although I do like this guide), but this assignment concept sidesteps this in what I believe to be an elegant way. Chaotic Enby (talk Ā· contribs) 19:50, 27 January 2026 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
I floated this at Village pump (proposals) here awhile back, and there was wide support for doing this (some editors said they felt it unofficially already was a guideline). But, it was noted that the essay, Wikipedia:WikiProject Albums/Album article style advice, needed some clean up and to be fleshed out in places. After multiple discussions, including some disputes and RfCs, I think the essay is finally in a place where there is an updated consensus and enough detail that it can be an official MOS style guideline. This is a formal presentation of the updated and discussed essay to see if there is support for making it formally part of Wikipedia's Manual of Style.--3family6 (Talk to me|See what I have done) 12:35, 26 January 2026 (UTC)[reply]
Look under "Track listing", where someone added "This is generally assumed and does not need explicit citation in most cases". Even when albums are already released, we frankly shouldn't be so quick to presume that an unsourced track list lines up with actual credits. Adding liner notes or an iTunes/Amazon link would be better than nothing. You might be surprised how often others have dubiously tried to use the essay as an excuse to ignore the non-negotiable requirements of WP:Verifiability and WP:No original research. SNUGGUMS (talk / edits) 23:30, 26 January 2026 (UTC)[reply]
WP:V doesn't require citations, and the essay reflects consensus. Are there cases of people inserting false information? I'm not opposed to modifying that text a bit, I just fail to see how it doesn't reflect consensus.--3family6 (Talk to me|See what I have done) 00:03, 27 January 2026 (UTC)[reply]
On the contrary, WP:V opens its second paragraph with "Each fact or claim in an article must be verifiable." That doesn't give essays the right to make selective exceptions. I also haven't seen any consensus suggesting citations wouldn't be needed for facts. As for fabrications, I wouldn't be surprised if there have been, though cannot think of specific instances at the moment unless one counts vandalism. SNUGGUMS (talk / edits) 00:23, 27 January 2026 (UTC)[reply]
The spirit of WP:V is that anybody should be able to check that the claimed facts are true. Picking up a record sleeve or CD inlay should be OK for that. That said, there are occasional discrepancies between the reality and what's actually written. Two examples: (i) Masque where the actual playing order matches a sticker on the sleeve but not the record labels; and (ii) Platinum, where the track "Sally", present on original copies, was replaced by "Into Wonderland" but without the sleeve being amended. --Redrose64 š¹ (talk) 14:07, 27 January 2026 (UTC)[reply]
As long as articles make it clear that credit listings are taken from sleeves, inlays, or anything similar, I don't see an issue with using print sources for credits. If there are discrepancies, then it shouldn't be too difficult to find additional sources backing them up, perhaps even with some commenting on omissions. My qualm is enabling lazy-at-best mentalities of "just trust that I got these accurate" or "I don't need anything to back up my insertions of credits/personnel" when adding credits without any citation at all, even print ones. One or more refs (whether online or printed) helps show the listings aren't being pulled out of nowhere. SNUGGUMS (talk / edits) 17:46, 27 January 2026 (UTC)[reply]
For a few samples showcasing the latter attitude by trying to use the essay as a cheap cop-out for not sourcing credits at all, have a lookatthesediffs. The choice to deliberately leave such sections with no sources is careless. SNUGGUMS (talk / edits) 23:03, 27 January 2026 (UTC)[reply]
You're welcome, and for starters, I would recommend fully scrapping the sentence quoted above within the "Track listing" section even if this essay never becomes a guideline or a policy. We also shouldn't endorse any similar phrasing that people would attempt to use as an excuse for not implementing citations. It baffles me how anybody thought an essay could plausibly be used to overrule policies/guidelines. SNUGGUMS (talk / edits) 19:11, 28 January 2026 (UTC)[reply]
As mentioned elsewhere, it is not overruling policy. Read WP:V. Content needs to be cited if the content is likely to be challenged, is BLP relevant or is a quotation. If there is consensus that primary sourcing (i.e. the album itself) is sufficient for verifying the track listings and that this is generally not likely to be challenged then no citations are required. This is the current consensus for plot summaries (which are sourced to the primary work and not cited because it's the subject of the article). You can make an argument that that citations should always be provided either because it's regularly wrong and therefore likely to be challenged but providing a citation isn't mandatory in all cases. Scribolt (talk) 10:26, 29 January 2026 (UTC)[reply]
That would be up for discussion, but wouldn't be a requirement imo. An article about an album isn't a BLP, and material about who did what during the production isn't necessarily contentious or controversial. There's certainly a higher possibility of getting the content wrong here compared to simply checking the track listing, so there might be added value in recommending in a guideline to make the extra effort and cite the content as a default, but if there isn't consensus to do this I wouldn't regard this it as being against any higher level policy. Scribolt (talk) 08:08, 2 February 2026 (UTC)[reply]
Thanks. The concerns brought up in that discussion seem to have been taken care of, and I don't share Snuggums' concerns w.r.t. WP:V issues. Increasing to a regular level of support. mdm.bla04:52, 28 January 2026 (UTC)[reply]
Support It may need further improvement, but making it formally a part of the MOS rather than a wikiproject sub-page will make that more rather less likely. Scribolt (talk) 14:33, 27 January 2026 (UTC)[reply]
Support ā I don't think its necessary to have to cite the release for information from the release, as anyone with access to the media can verify it themselves (Ć la MOS:PLOTSOURCE). That said, I wouldn't oppose making {{Cite AV media notes}} (or w/e source) a requirement for WP:PERSONNEL, as that's often not as easily as accessible with digital releases, but I would argue it's unnecessary for the track listings (as anyone with access to both the physical release and streaming services can easily verify for themselves). Nilš„04:18, 28 January 2026 (UTC)[reply]
Comment ā I'd like to hear more about the intended benefit of promoting WP:ALBUMSTYLE to a guideline. What problem would that solve? What isn't the page able to do as a WikiProject advice page that it could do as a guideline? If it were promoted to a guideline, where would it be moved to? Wikipedia:Manual of Style/Albums? There are already a few MOS subpages dealing with music, most of which, in my opinion, are better fits for explanatory essays or WikiProject advice pages. As a procedural note, there area few steps outlined at WP:PROPOSAL that should be followed for this discussion, including adding a formal RFC tag and posting a notice at Wikipedia talk:Manual of Style.--Trystan (talk) 13:50, 28 January 2026 (UTC)[reply]
isn't the page able to do as a WikiProject advice page that it could do as a guideline? In practice, I'm not sure, as it's de facto treated as an MOS already (for example, the short name link WP:MOS). This would formalize what is effectively the status quo. It would give more weight, though of course it's still a guideline to which IAR applies.--3family6 (Talk to me|See what I have done) 01:35, 29 January 2026 (UTC)[reply]
Oppose per SNUGGUMS. Clearly the advice not to source credits doesn't fit with wider policies and guidelines. And more broadly, per WP:CREEP, having too many guidelines of this nature which are crafted by niche WikiProjects and may not be widely watched, is not beneficial. The overall MOS has almost all the guidance you need, and any further details should be worked out by consensus at individual articles, not by a wide-ranging set of arbitrary guidelines that aren't being widely vetted. ā Amakuru (talk) 14:58, 28 January 2026 (UTC)[reply]
Comment. Generally, the MOS applies to all topics. Are there any other examples of subject-specific guides within MOS, or would this be a scope expansion? pburka (talk) 16:54, 28 January 2026 (UTC)[reply]
Why there is a WikiProject portal about train stations but articles covering bus routes tend to be considered not notable?
Hi, recently, I saw a deperate WikiProject portal which is about train stations. However, I do not see the same way as bus routes, not even making articles covering bus routes are mentioned in the WikiProject: Buses portal, because articles about bus routes tend to not meet the citera for notability. This makes the phenomeon where train stations are considered noteworthy while bus routes are considered insignificant. It makes the systematic issues worse, especially when there are some bus enthusiasts worldwide who don't know more about bus routes in general (because they are only limited to knowing about bus types when there is a lack of information about bus routes in their area). Not to mention that buses tend to get underrepresented in general transit content. KobaltKolibri (talk) 09:30, 27 January 2026 (UTC)[reply]
Wouldn't the comparison be train lines to bus routes? Or trains stations to bus stops? Anyway, the significant difference between train and bus infrastructure is permanence. Train stations and lines tend to be relatively fixed, and very simply that means there is more time for sources to develop about them, even before getting to their creating a larger immediate impact on the landscape. Many bus routes do reach notability, but most will simply lack relevant sourcing. CMD (talk) 09:44, 27 January 2026 (UTC)[reply]
Taking that seriously, as it may or may not have been meant, air transport falls between the two. It needs a lot of infrastructure where 'planes start and finish, but very little in between. Phil Bridger (talk) 19:56, 27 January 2026 (UTC)[reply]
I don't fly commercially but don't want to be on the ground if an infrastructure is found directly in the path of a plane either. Otr500 (talk) 22:41, 1 February 2026 (UTC)[reply]
Yes, this is the point. Railway stations (and routes) tend to be fixed (unless/until they close or are removed). Of course many - even closed ones - are very old, which means there are multiple sources about them ranging across history. Bus routes, and infrastructure, tend to be more ephemeral. There are exceptions, of course, as can be seen by Category:Bus routes in London. Black Kite (talk)20:01, 27 January 2026 (UTC)[reply]
But not always. I sincerely doubt the Trailways bus station where I worked for a year is notable. It was built on the site of a railroad station for the Tampa and Jacksonville Railway, which was a relatively impressive building, but used by a building supply company for many years before being torn down in the early 1960s, and that doesn't have an article, and I am pretty sure I could never find enough coverage of it to justify an article. Donald Albury00:38, 28 January 2026 (UTC)[reply]
A building can remain notable even if its function changes. A former train station, gaining notability as a train station at that time, will remain notable even it's its converted to retail space or similar that otherwise has no notability related to its new purpose. Masem (t) 14:34, 28 January 2026 (UTC)[reply]
My point was that I don't think that sources exist to establish the notability of that train station, let alone sources to establish the notability of the bus station that replaced it. Donald Albury19:07, 28 January 2026 (UTC)[reply]
Train stations aren't really notable by default either, although many are of course notable. But anyway, I don't believe there is a Portal for train stations, only one for trains in general, Portal:Trains? And we also have Portal:Buses, so I don't know what caused this section in the first place... Fram (talk) 14:11, 28 January 2026 (UTC)[reply]
Are "users" only human editors and bots?
Hello, all,
I run several Quarry queries to try to catch mistakes that might not be observed by our patrollers and other editors who look to correct or tag pages that do not fit into our project policies. One of the queries finds "User pages" that do not belong to human editors. The speedy deletion criteria to tag these pages for deletion is CSD U2 or "nonexistent user". Typically, these pages are just mistakes by new editors who are not familiar with different namespaces.
But a few weeks ago, my query posted these pages, User:Command line script, User:Move page script and User:ScriptImporter, all by User:K6ka, none of which are human editors and bots which are scripts. I tagged this all for speedy deletion, CSD U2 but they were untagged by User:Toadspike who believed these deletion required more discussion. I wasn't sure where to start this discussion as no one who see it on these User talk pages so I am starting it here.
So, can a script be considered a "user" and have user pages? Thanks for pondering this rather existential question and letting us know whether or not these pages should be deleted, moved or just left alone. Thank you. LizRead!Talk!21:23, 27 January 2026 (UTC)[reply]
A script is software. If software (script, bot, whatever) is running on Wikipedia, it is doing so because a (human) user instructed it to do so. There is nothing 'existential' about this. CSD U2 would certainly apply, since there is no user with the name specified. If the pages were created for test purposes or similar, this would appear to be a misuse of the user namespace for an unintended purpose. This appears to be new, and I'd assume entirely unnecessary, given that people have been creating complex bots for many years without having to resort to such gimmickry. AndyTheGrump (talk) 21:44, 27 January 2026 (UTC)[reply]
Considering Command line script has links to check the contributions and log entries, neither of which work without an actual user involved, I'd say we need a better description at the bare minimum. SarekOfVulcan (talk)21:44, 27 January 2026 (UTC)[reply]
This was first brought up at User_talk:K6ka/Archives/2026/January#User_pages. To recap, these are reserved usernames and cannot be registered in the same sense as regular human and bot accounts. The user pages are intended to be informational pages providing information on what the scripts do and why they may appear in the logs. We already have such user pages: User:Unknown user is a reserved username that is not registered but has a user page explaining what it's for, whose existence does not appear to be contested. Toadspike cited that user page as the reason for declining U2 as this was a unique case. One could argue that we don't "need" need these pages, but there is also no harm in keeping them either. If nothing else, they could be soft redirected to their respective user pages on Meta, or redirected to a dedicated project page here describing reserved usernames. āā k6kaš (Talk Ā· Contributions) 22:06, 27 January 2026 (UTC)[reply]
See k6ka's post aboveāthese user names are exceptions built-in to MediaWiki via its configuration. It's not some user running a script. Perhaps WP:Reserved usernames should be created with an explanation and each user page should redirect to that. And I guess the user talk pages should redirect to the WP talk page because someone will otherwise create them. @K6ka: The links you gave for edits and logged actions made by each script don't workāis there a record of what they do? Johnuniq (talk) 01:04, 28 January 2026 (UTC)[reply]
@Johnuniq: The links to their contributions and user logs don't work because technically they don't have local accounts on the English Wikipedia. If you check the CentralAuth pages for Command line script and ScriptImporter, you'll see that they have local accounts on some wikis, and the contributions and user logs on those wikis will work there. To my knowledge, the scripts mentioned in this thread have never edited the English Wikipedia before, though they are still reserved in the MediaWiki software. āā k6kaš (Talk Ā· Contributions) 04:21, 28 January 2026 (UTC)[reply]
In a quick look, I couldn't find any links that show any contribs or logs so there might not be anything useful for a doc page other than your above "reserved usernames" link with a brief explanation. Johnuniq (talk) 04:31, 28 January 2026 (UTC)[reply]
There are more scripts than this, but there was a bug some time ago that allowed users to register new accounts with the same name as the script, inheriting its edit history. (The same problem is why so many 2001 accounts are blocked) It looks like you found some that were not affected? 3df (talk) 01:42, 3 February 2026 (UTC)[reply]
I have created Wikipedia:Reserved usernames for an overview of MediaWiki reserved usernames. I have not touched the existing userpages for things like MediaWiki default and some old friends like Conversion script since their existence isn't contested. I believe the main issue arose with userpages being created for reserved usernames that aren't registered locally, which MediaWiki default and Conversion script very much are. Both of the aforementioned reserved usernames also have global accounts, and so a global user page could be created for them on Meta, which would appear automatically on all wikis regardless of whether it was registered locally. āā k6kaš (Talk Ā· Contributions) 04:27, 3 February 2026 (UTC)[reply]
It's acceptable since it's not spam or advertising, it's a batch of articles about an important cultural entity running on the anniversary of such entity. Yes it's a commercial product, but that's not all it is and that's not why the set is running.--3family6 (Talk to me|See what I have done) 01:38, 29 January 2026 (UTC)[reply]
Mehā¦ It certainly is a cultural entityā¦ but I question that it is an important cultural entity. I could see us doing a single DYK to mark the anniversary, but a set of DYKs seems overkill (and if there is an announcement of a new product, I think over celebrating would cross the line into promotion - even if that isnāt the intent). Keep it simple. Blueboar (talk) 01:49, 29 January 2026 (UTC)[reply]
I donāt think that having a Pokemon themed main page or section on the main page is spam or advertising. Nintendo isnāt paying us to do it after all. You could complain that referencing religious or cultural holidays in featured content is problematic because so and so, but it happens all the time. Dronebogus (talk) 11:11, 29 January 2026 (UTC)[reply]
I don't see an issue, as the promotion is incidental to the showcasing of our new/good articles, instead of the kind of promotion we would all agree to hate - the deliberate one, which doesn't care about NPOV.
I would definitely be much more vigilant about hooks are inaccurate, boring or break policy on that date. If I were you, I'd be spamming WT:DYK with threads about bad hooks or bad articles behind these hooks. Szmenderowiecki (talk Ā· contribs) 11:12, 29 January 2026 (UTC)[reply]
Re-evaluating the ECR wall in the Kurds and Kurdistan topic area
As a non-XC editor, Huryutan is not yet allowed to participate in discussions of this topic, including contesting the sanctions regime itself. Please review WP:ECREXPLAIN and earn your stripes on Wikipedia before trying to reorganize its practices. signed, Rosguilltalk20:45, 28 January 2026 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Iād like to open a discussion on the long-term impact of the current Extended-Confirmed Restriction (ECR) for the Kurds and Kurdistan topic.
While the January 2023 disruption clearly required a strong response, the current blanket application of ECR has turned into a permanent wall that is hurting the encyclopedia. We are currently in a knowledge vacuum where subject-matter experts and neutral new editors are effectively locked out of the topic entirely.
The biggest issue is that ECR doesn't just throttle editing; it blocks non-ECR users from even using Talk pages to suggest improvements and completely prohibits them from creating new articles. As a result, coverage of essential Kurdish figures, literature, and history has become stagnant. We are losing out on high-quality academic research because the people who have the sources aren't allowed to contribute or even start drafts in the mainspace.
Protecting the project from coordinated disruption is vital, but the current fortress approach is starving these articles of nuance. Can we look into a more surgical approach? Moving less-contentious sub-topics like arts, biographies, and culture to Pending Changes Level 2 would keep the vandals out while finally allowing constructive growth and new page creations.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Introduce maximum page size and mandatory archiving for pages intended for user communication (accessibility)
The following RfC concerns a set of proposals be implemented for all pages intended for user communications (e.g. (X) talk: pages and noticeboards in the Wikipedia: namespace) A short summary of the complete set of changes:
Establish a minimum number of 10 threads on pages, except on user talk pages
Establish a maximum size of pages (about 200 KB) and page archives (about 150 KB).
Mandate some sort of automatic archiving mechanism for all pages, except for user talk pages; that archiving mechanism will by default do all the enforcement of the maximum size rules on non-user talk pages.
Require pages that will likely routinely fall afoul of the maximum size rule to introduce a short archiving interval
Limit discretion of users to manage their assigned talk page to comply with maximum size guidelines, but leave the choice of the preferred way to comply with the guideline to the users; no other part of user discretion is disturbed
Introduce an enforcement mechanism for users failing to abide by the accessibility guideline (max size)
Force changes to the codes of archive bots in such a way that any input value above the maximum permitted/below the minimum permitted thresholds will default to the threshold values.
Full changes, along with the reasoning, is presented in the collapsed table.
Do you support these changes as presented in the table below? If not, which specific parts of the changes do you not like?
Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions ā see Help:Archiving a talk page.
All pages intended for communication between users have to be reasonably accessible. Their size must not substantially impact device/browser performance while reading or editing.
The whole premise of the RfC.
All pages intended for communication between users must have some sort of automated archiving deployed. This concerns all (X) Talk: pages, and noticeboards in Wikipedia: namespaces. There are two possibilities:
A bot can generate pages for a given period that are assembled in a log (see example here). Discussions are started directly on these subpages. This is the procedure used at various venues to discuss potential page deletion. The period should be adjusted so that each individual subpage is unlikely to break the archive size guideline. Generally meant only for extremely busy pages.
Do not archive pages manually, unless this is necessary because bot errors somehow prevent the pages from being archived.
User talk: pages are exempt. Single discussions split into their own pages due to size considerations are exempt from internal archiving but have to be searchable through archives of the page they were split from.
We have well-tested archiving tools/subpage creation tools that automate the process. This wording will eliminate bickering over archiving preferences, which is pretty lame and a waste of editor resources. Set up an archive once and forget about it.
There are pages that remove discussions instead of deleting them, e.g. WP:ERRORS, which could benefit from the log-based scheme. Pages that remove discussions are already in violation of the rule that discussions should be archived, not blanked; this rule will make sure that the transition must take place.
All pages intended for user communication should not exceed 1200 KB HTML weight. Archives of these pages should not exceed 900 KB HTML weight. Existing archives are grandfathered. This rule should not be interpreted as discouraging new or existing discussions in any way.
A recent RfC about talk page guidelines scrapped the 75 KB wikitext size limit on non-user talk pages as it had no consensus and practically was not followed anyway. I do not read the discussion as finding consensus against any sort of talk page size limit and the closer specifically encouraged a user talk-dedicated discussion. I don't see the functional difference between the two, that's why this proposal concerns all such pages.
The point is to make sure that pages are responsive upon reading and editing. HTML size is not a perfect proxy for measuring this but much better than wikitext. Page weight matters a lot, so some value needs to be set. A median desktop page weighs about 800-900 KB HTML+CSS+JS these days. We can't measure the impact of JavaScript directly on the CPU/browser, but there are Inspect tools integrated in the (desktop) browser.
For example, ANI (2062 KB HTML as I write) has an OK value for Largest Contentful Paint (1.86 s) and good Interaction to Next Paint time (40 ms), but not very good values for Cumulative Layout Shift (0.1 s). When I try to edit it in source, however, the latter two values grow to pretty horrible 1,256 ms and 1.02 s; typing text sends INP value - which is basically lag - to an asinine 4,432 ms (syntax highlight on; Chromium 143). The page visibly struggles. Larger talk pages may freeze or crash browsers, or make them effectively uneditable, which is an absolutely unacceptable outcome.
The point is to make sure that the value is set reasonably high to allow wide discretion to manage talk pages but not too high to make compliant pages struggle on devices that are not top-shelf. Compliant pages should give users at most mild inconvenience in reading and editing, given any reasonable device and Internet configuration. Any threshold value is arbitrary but the value appears to be a good compromise.
(second and later paragraphs based off performance and the page weight chapters of the HTTP Archive Almanac. See the performance page for good reference values of Inspect parameters I mentioned)
Lazy loading and render engine improvements depend on WMF/MediaWiki. While their performance improvements are welcome, there is absolutely no guarantee that they will do it, and there is no deadline for them. This proposal is something we as users can do right now.
Some users claimed that we should not do it because other websites become heavier over time, which they do, so the value will become obsolete as old hardware is inevitably replaced with better hardware. For one thing, if other websites create pages that consume tons of resources, they are free to do so, but it doesn't mean we should do the same or force people with devices that have poorer performance to make them suffer through loading. For another, consensus can change and we can edit the value later.
Footnote: As a rough estimate, 1 KB of wikitext weight (the one you see in the page history) is about 5-6 KB HTML weight (source: my observations using PROSESIZE on a couple dozen pages). The more templates, formatting, and user JavaScript and CSS there is on the page, the more HTML weight there will be per 1 KB wikitext weight. Archiving bots assume that 1 KB of wikitext is 6 KB of HTML for the purpose of this guideline. Although the limit is in HTML size, not wikitext, this ratio will allow most discussion pages to stay well within the maximum allowed value.
HTML size does not account for the weight of loaded images. If the page is image-heavy, consider lowering the maximum page size limit.
To measure HTML weight of a given page, you can use tools such as WP:PROSESIZE. On desktop, there is also an option to open "View page source" and copy-paste the code into a text counter to see the number of bytes.
None
The archive interval value must balance the need to keep the talk page within a reasonable length with giving adequate notice to all potential participants to engage in the discussion. Only finished discussions may be archived; if possible, the only discussions that go to archive should be clearly stale (=1 year since last comment). If in doubt, apply a longer archive interval. In particular, pages with very high traffic are allowed to exceed the limit to some degree if necessary to give adequate notice to potentially interested users, or to show a recent discussion of large impact.
If the page intended for user communication is likely to routinely exceed the maximum size limit, and if the log system is not used, the archiving interval (=time since the last comment in the thread) of an archiving bot must be set at at most 10 days. This, or lower, value, should be only set for high-traffic pages.
The first part is pretty self-explanatory.
The second part is designed to a) force high-traffic pages to adopt relatively aggressive archiving schedule and b) effectively exempt them from the requirement that the page be smaller than 1200 KB HTML.
The only consideration for high-traffic pages is whether it's more desirable to keep the page small and friendly to edit/read or to keep threads for slightly longer to encourage more discussion. Generally more discussion is more desirable, but on pages like ANI, where threads are often closed in a matter of hours, this may actually be not necessary.
Apart from the exception described in WP:TALK#User talk pages, discussions should be archived, not blanked.
Discussions on all pages, except for user talk pages, should be archived, not blanked.
Any user may choose to blank most messages on their own talk pages, but archiving is recommended instead. There are messages that the user must not remove.
If a user removes a message from the talk page, whether by themselves or assisted by automation, this will mean that the user has read and is aware of its contents. Insisting on keeping the message that the user may delete against the user's wishes is not appropriate.
As mentioned above, pages like WP:ERRORS violate this guideline by not keeping any archives.
Policy does not prohibit users, whether registered or unregistered, from removing comments from their own talk pages, although archiving is preferred. If a user removes material from their talk page, it is normally taken to mean that the user has read and is aware of its contents; this is true whether the removal was manual or automatic. There is no need to keep them on display, and usually users should not be forced to do so. It is often best to simply let the matter rest if the issues stop.
Basically a slightly refactored restatement of these two rules, with emphasis on user autonomy on user talk pages.
WP:TALKSIZE
If a thread has been archived prematurely, such as when it is still relevant to current work or was not concluded, unarchive it by copying it back to the talk page from the archive, and deleting it from the archive.
Add this before the red passage:
Archive bots must not archive threads on pages intended for user communication if:
there are 10 threads or fewer on the main talk page
the last comment in a given thread is 10 days old or younger, unless the archiving interval was set at a lower value
This is to address user complaints in the linked Talk page guideline thread above, as confirmed on VPI, that empty pages discourage discussion. I agree. Hence the first requirement.
The second requirement is to prevent (potentially) active discussions from being archived. As mentioned above, manual archiving of talk pages is discouraged. But on the off-chance that the thread still is relevant even if archived by bot, the instruction is kept.
While you do not "own" them, by custom you may manage [user space pages] as you wish, so long as you do so reasonably and within these guidelines.
While you do not "own" pages in User: namespace, by custom you may manage these pages as you wish. Your requests not to edit your User: namespace will be honoured. However, your style of userspace management must be within reason and not lead to breaking these guidelines.
This is to separate User: from User talk: namespaces. Nothing changes in the User: namespace, and generally editors will still have free rein in their user namespace.
If an editor asks you not to edit their user pages, such requests should, within reason, be respected. However, editors should not make such requests lightly, especially concerning their talk pages, as doing so can impede the ordinary communication which is important for the improvement and smooth running of the project.
The length of user talk pages, and the need for archiving, is left up to each editor's own discretion.
A user can generally manage their User talk: namespace pages as they see fit, so long as they keep the management within the talk and user page guidelines, including those on maximum size limits.
All discussion pages have to be reasonably accessible, both for reading and for editing, under all reasonable configurations allowed by MediaWiki software. There is no legitimate reason for distinguishing non- User talk: discussion pages from those in this namespace.
Users will still be able to manage User talk: pages as they like, but they will have to clear clutter from time to time. It doesn't matter how they do it so long as they do it.
None
Any user or bot may notify you about your excessive user talk page size that violates the guidelines, and ask you to fix this issue. If you:
refuse
agree to do it but fail to bring the talk page within compliance within 10 days
have a history of notifications that shows that you are unable to maintain compliance with the maximum size long-term
an administrator may unilaterally impose an archive bot using the loosest limits necessary to maintain the minimum user talk page accessibility criteria long-term, or correct values to more aggressive archiving if the archive bot was deployed but the size of the talk page is still too large. For people who use archiving by periods of time rather than numbers, a period can be chosen that is likely to stay within these limits, but no longer than 365 days. The archive bot must not be removed without agreement from the administrator who imposed it. The administrator must notify the user of the intervention.
This is the mechanism to enforce size restrictions on user talk pages if the clutter is not cleared. The mechanism respects user's autonomy to decide how to manage their talk page but steps in if it is clear that the user can't or doesn't want to comply.
If a user doesn't know how to set up an archive, they can always ask for help. Again, it doesn't matter how they choose to clean up the page to a minimum standard so long as they actually do the clean up. I'm not saying "make it super tidy" but more like "make it not look a total mess".
If users feel particular attachment to the collections of their discussions that they ABSOLUTELY NEED on one page, they can create a subpage in the User: space for themselves and advertise it with big-ass fonts. They can also have discussions they are fond of on their talk page so long as they keep the overall size in check.
The requirement for administrators to intervene is to make sure the heightened accountability standards apply, even if such intervention does not involve administrative tools.
Note that having a big talk page is NOT in itself misconduct. No blocks, no warnings intended, unless there's some real shenanigans going on or the refusal is so stubborn it has a real impact on the community.
Minimum thread count: 10 (outside user talk pages)
Maximum archiving interval: 365 days (1 year), but not until the minimal thread count is exceeded.
If the parameter is unspecified, or if any value outside the permitted range is put in the parameters, the values will default to the threshold values.
Oppose all, mega oppose c, turbo oppose d and g, turbo mega oppose f. Automatic archiving of talk pages, astonishingly frequently, preserves any vandalism or disruptive edits of talk pages in the archives. We should not make it mandatory and we definitely should not mandate giving people even less time to check for vandalism until the bot strikes (that window is already as short as one or two days, in some cases). We absolutely should not make it the job of users to enforce accessibility considerations, that is the job of the actual paid frontend employees. Gnomingstuff (talk) 15:25, 29 January 2026 (UTC)[reply]
also, I assume a) is meant to be "maximum number of 10 topics" because otherwise that makes most talk pages non-compliant. But I still oppose it either way, because setting a topic maximum codifies the loophole of spamming a talk page with many new topics to force the archive bot to trigger and disrupt the discussion. Gnomingstuff (talk) 15:28, 29 January 2026 (UTC)[reply]
No, it's actually minimum. Most threads are not that long. If that the threads are so huge as to spill over the maximum limit, which doesn't happen that often (average >20 KB wikitext or even more), then this setting will be overridden.
re: spamming a talk page with many new topics to force the archive bot to trigger and disrupt the discussion. -> impossible under this proposal, because archiving will be disallowed if the last comment in a given thread is 10 days old or younger, unless the archiving interval was set at a lower value. And that's a hard one. Szmenderowiecki (talk Ā· contribs) 16:03, 29 January 2026 (UTC)[reply]
Support all except point a - there should be flexibility on this point. 10 would be innappropriate for infrequently accessed talk pages, and 3 or 5 is perfectly adequate for encouraging discussion. Danners430tweaks made15:29, 29 January 2026 (UTC)[reply]
Skeptical of hard rules - If a page is at a hard maximum, and someone comes in with an important topic that needs to be discussed, is their edit disallowed? Do they have to fiddle with archiving something (perhaps even an active conversation) before they can tell everyone that Willy on Wheels is deleting the main page again?I'm fine with a smarter archive bot that can dynamically change how aggressively it runs based on page size. That seems worthwhile to me. Is forced archiving of user talk something that affects more than a few dozen editors? Is there a systemic problem here? However, if we happen to have 2 big, active important discussions on a noticeboard at the same time, I think accessibility is the sacrifice we make for keeping those discussions intact and in the expected place. It also might be worth exploring a finer grained structure for some noticeboards - Wikipedia:Administrator's Noticeboard/Quick Requests for things that don't need huge input is one wild guess I had that might work. Tazerdadog (talk) 15:38, 29 January 2026 (UTC)[reply]
If a page is at a hard maximum, and someone comes in with an important topic that needs to be discussed, is their edit disallowed? -> ABSOLUTELY NOT. The question is why the page hits the ceiling. If the reason is that the page has very high traffic, but the bot is set at 10 days archiving interval or shorter, then deviations will be tolerated for the sake of keeping discussions, although huge discussions probably should be spun out in their own pages (see table). If the page hits the ceiling because the parameters are too loose and there's suddenly high traffic, they have to be set at 10 days. The page should not generally hit the ceiling despite low traffic, unless it's a userpage, where archiving will not be obligatory, in which case the enforcement kicks in. These archiving enforcement restrictions are absolutely not supposed to discourage or ban discussion.
I don't think there are archive bots that dynamically adjust aggressiveness of archiving. This would be ideal but require a bit of coding I simply do not have the brain for, and I think this will actually be hard to code well, and will be likely too much effort for someone who is not paid for the coding. Szmenderowiecki (talk Ā· contribs) 16:13, 29 January 2026 (UTC)[reply]
This is probably worth exploring after this discussion is closed. At the grave risk of saying this about anything technical, it doesn't look like it'd be that hard to implement a minimum viable product of dynamic archiving. Tazerdadog (talk) 01:57, 30 January 2026 (UTC)[reply]
Skeptical of hard rules I can understand the premise, but I am not convinced that we want a one-sized fits all solution. Fundamentally, I think there should be ways to "sticky" some threads on a talk page and there is a smarter way to search archives. --Enos733 (talk) 16:32, 29 January 2026 (UTC)[reply]
Oppose: I think this is too inflexible to allow for the deviations mentioned. This (except a maximum page size which should be a requirement unless all sections are ongoing and not close-able) should be a set of recommendations, not enforced rules. That would be very unWikipedia.Turbo mega oppose a: I don't really see the purpose of a requirement that so deviates from our current practice. This would be a lot of enforcement for little benefit. I would think just one is enough, and I unfortunately don't have time to figure out where the TPG talk page discussed this right now, so I'd appreciate if someone could point this out. Aaron Liu (talk) 16:35, 29 January 2026 (UTC)[reply]
unfortunately don't have time to figure out where the TPG talk page discussed this right now, so I'd appreciate if someone could point this out. This was discussed at the linked idea lab thread of the Village Pump. I got some feedback that the number is too high, and on the other hand, a temp account suggested a maximum of 15 threads/30 for high-traffic areas. This is not the essential part of this RfC, so if the number is 3 or 5, so be it. I don't care that much so long as it's not 0. 1 is probably not good enough. Szmenderowiecki (talk Ā· contribs) 16:42, 29 January 2026 (UTC)[reply]
As I was reviewing discussions, I found some users' concerns that empty pages discourage discussion. One may be pretty empty, particularly if the suggestion is not answered, as it is on most article talk pages. Szmenderowiecki (talk Ā· contribs) 17:30, 29 January 2026 (UTC)[reply]
Oppose all - I'm not really convinced there's an issue here that requires fixing, especially "fixing" via enforcement. If a talk page for an article is too large, please feel free to add automatic archiving as you see fit. If a user's talk page is too large, consider opening a discussion with that user, even if their page loads kinda slow when you start that discussion. Per Gnomingstuff's earlier point, if there's actually widespread accessbility issues related to how pages are rendered and presented to users, that would be a UI problem to be fixed by development and not a content problem to be fixed by limiting content. --tony16:46, 29 January 2026 (UTC)[reply]
Oppose all also BADRFC which goes against the consensus. RfC statement is not neutral nor brief. Pinging large groups of people wastes valuable volunteer time. Polygnotus (talk) 16:50, 29 January 2026 (UTC)[reply]
I don't think such restrictive requirements are a good idea, and definitely strongly oppose a. Editors should keep in mind that very large talk pages could be a barrier to communication. For article talk pages simply setup archiving if you come across one with size issues. When it comes to the talk page of that one particular editor active editors maybe there could be an annual AN discussion to encourage them to tidy up their talk page. There are many inactive editors without talking page archiving who receive endless automated messages, leading to a lot of bloat, but that's of very little impact (noone needs to communicate with them, and there is little limit on storing text). -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°16:56, 29 January 2026 (UTC)[reply]
I firmly support introducing an enforceable talk page size limit. Having a talk page that will load across all editor devices is important for accessibility, and as we have documented elsewhere we have talk pages that are unusable (so contra several colleagues above, there is a concrete problem, albeit one of limited scale). I don't want to get too far into the weeds with respect to specifying limits; a byte-size should be sufficient, because we do not want the enforcement to become a bureaucratic mess. I suspect this RfC has too many specifics to gain consensus, but in the interest of making a closer's life easier I will note I support b & e, oppose a and am largely agnostic as to the rest. Vanamonde93 (talk) 16:58, 29 January 2026 (UTC)[reply]
Oppose almost all, the one possible support is b (maximum byte size for pages, a reasonable technical limitation) but that should probably be done in a separate RFC on just that topic, and be a "soft" maximum anyway. Everything else is a bad idea that creates layers of bureaucracy and bad feeling over nothing important. SnowFire (talk) 16:59, 29 January 2026 (UTC)[reply]
Oppose The OP claims that We have well-tested archiving tools/subpage creation tools that automate the process. This is not my experience. I've been editing Wikipedia for nigh on 20 years and I've not gotten on with any of the assorted archive tools which I've tried. And the archive pages for subprojects like ITN are among the worst offenders in my experience -- bloated and broken due to the template limit. What's needed is for the WMF to address the technical issues as that's their job. Wild development and draconian diktats are unlikely to be helpful. Andrewš(talk) 17:05, 29 January 2026 (UTC) (edit conflict)[reply]
This is not well-thought-out at all. It contradicts existing practice for the majority of cases, and some of the provisions (particularly a and b) are mutually exclusive. āCryptic17:15, 29 January 2026 (UTC)[reply]
Essay Make an essay. Create the case there, supported by common sense, guideline and policy. Create a CAPLETTER link. Start linking it. If it catches on, within a couple years, you or someone else will promote it to guideline. This is the way to do it. These all-or-nothing hail mary proposals on VPP are lazy and usually don't work. You got to build something if you want to make change. -- GreenC18:02, 29 January 2026 (UTC)[reply]
Oppose oppose oppose. Oppose RfC structure. The letters a-g don't match the rows in the table. My head hurts, and since this should be headed for SNOW close I won't renumber. Capital letters below talk to the table, not the lower-case list. Oppose A. Not mandating archiving of user talk (i.e. just deleting old stuff is fine) is valuable and should be kept. Archiving parameters (including "no archiving") is a personal preference. While the justification of the RfC is making user talk accessible, the proposal fails to explain why such harsh measures must be taken. Oppose B. No need for a specified number. Just force EEng to archive, and you've solved all problems :) Oppose C. Different talk pages require different archiving intervals. Archiving every 10 days is insane for regular user talk pages. Oppose D. Start a new separate discussion (without the infected atmosphere of this one). Opposing mostly because bundling this together with everything else is really ill-advised. Oppose E. The suggestions makes it clear the proposer don't know how people use archiving bots. The only sane minimum number of threads to keep is 4. 10 is way too many. Oppose F. For the same reason as D - start a separate discussion. Oppose G. Just hell no. Oppose H. For the same reason as D - start a discussion separate from everything else. In closing, the proposer really needs to study how to create constructive RfCs because this ain't how you do it. CapnZapp (talk) 18:22, 29 January 2026 (UTC)[reply]
Oppose as written This goes too far and is too strict (and "a" is just a bad idea). I'd support stronger recommendations around archiving than we have now after Wikipedia talk:Talk page guidelines#RFC: Recommended maximum talk page size, but strict limits aren't going to work well and mandating bots archive every talk page would probably work even less well. Good luck figuring out what those recommendations should be though, since it seems the people who really care are mostly the ones who like having ridiculously huge user talk pages and they're happy to derail straightforward heuristics into demanding any rule be based on "page weight" and so on. Anomieā19:56, 29 January 2026 (UTC)[reply]
Oppose all. This entire proposal is a complete waste of time. There's no reason whatsoever why we should enforce a hard limit on talk page sizes. This has to be one of the most poorly thought out RFCs I've ever seen, let alone participated in. Sugar Tax (talk) 20:11, 29 January 2026 (UTC)[reply]
Strong oppose all - A is a terrible idea. That will add to clutter, not reduce it. It will make pages less accessible, not more. B is also a terrible idea. This has been explained many times: how long it takes for a page to load is not based on how many kB the page is in size. Because A and B are bad ideas, the rest of the proposals, which seek to enforce A and B, are also bad ideas. And really, the last thing this website needs is more r00lz. There are like a million f'ing rules on this website because it's 25 years of people being like, "I don't like this, let's make a rule to prevent it!" Look, you want to make every page on Wikipedia load reasonably quickly, there is one way, and really only one way, to go about it: you pick your website performance tool, and you say "must load within 5 seconds (or whatever amount of time) on any browser less than 10 years old (or whatever amount of time), as measured by X tool (or the average of multiple tools, take your pick)." You don't regulate the damn kB or the number of minimum threads if you want a page to load quickly, because that doesn't solve the problem. Levivich (talk) 20:31, 29 January 2026 (UTC)[reply]
Oppose all and suggest WP:SNOW close:I have a fair amount of experience with limited hardware and ancient software. As I look around my lab I see that my CP/M machine (actual Z80 hardware, none of this emulation rubbish) from 1983 is still working fine and used daily for text editing and my daily driver is a ThinkPad T580 from 2018. The limits proposed in this RfC are far too small. Anyone who has trouble reading a page twice the size of these limits is already used to having trouble reading half of the web. I would be inclined to support a policy against exceeding the limits found in https://www.mediawiki.org/wiki/Manual:$wgMaxArticleSize and https://www.mediawiki.org/wiki/Manual:$wgAPIMaxResultSize --Guy Macon (talk) 20:47, 29 January 2026 (UTC)[reply]
Oppose all. In particular:
a) oppose minthreads=10. If you have sufficient experience with Talk pages you know that sometimes an individual thread can run long, including longer than 200kb on occasion, so this would contradict one of your other proposal terms.
b) oppose max pagesize=200 and max archive=150. This has been very recently debated, and it is inadvisable to raise this again so soon, even if subsumed as part of a longer proposal.
c) oppose mandated archiving: better clarify what you mean by mandated. We mandate very little at Wikipedia, other than WP:LIBEL, WP:COPYRIGHT, some trust & safety considerations, and a short list of other policies with legal implications.
d) oppose required short archiving delay in some cases, per WP:CREEP and WP:BURO. You do not trust administrators at WP:ANI to know enough how to do the right thing? I can conceive of no case where having a rule about this will do anything other than provoke unnecessary strife.
e) oppose limitation on user freedom to choose their own talk page size. Is this about EEng's talk page? If so, then it is none of your fucking business. Don't bring proposals to VPP aimed at particular users; solve it in discussion with them, or at WP:AN if you must. If not about their (or some individual's) talk page, then please ignore the previous statement with my apologies; in that case I oppose per WP:OWNTALK and WP:CREEP.
f) oppose oppose oppose UTP max size enforcement. See e), and WP:OWNTALK, WP:CREEP, and WP:BURO. Personally, I would consider invoking WP:IAR to reverse enforcement at random other UTPs under this rule to see how strong the community support for this disastrous provision really was, assuming it were ever adopted, which I strongly doubt.
g) oppose enforced bot maxsize validation. I see a lot of terms like mandate, enforcement, limit, require, comply, and force in your proposal. You see to be in battle dress here, getting ready for the mother of all archiving wars. Where are all the terms like generally, should, typically, suggested, consider, and other terms that are often used in Wikipedia policies and guidelines to indicate something less than a hanging offense? Your usage smacks of my way or the highway, and does not conform to general usage at Wikipedia, in my opinion.
In re "e)", if there's something about someone's User_talk: page that makes it difficult for other editors to communicate with them, then it is other editors' business. WhatamIdoing (talk) 22:07, 29 January 2026 (UTC)[reply]
Not necessarily. If you have trouble accessing a webpage, it's not necessarily the problem of the webmaster to fix it, it might just be that you're using obsolete technology. It's not tolerable or practical to expect us to have every single web page work great for every single user no matter how obsolete (or laden with plug-ins, scripts, etc.) their client is. We should require ourselves to meet industry-wide web standards, not the standards of every random person on the internet. Levivich (talk) 22:12, 29 January 2026 (UTC)[reply]
If you're required to post an ANI notice, and you can't because the editor has a million-byte-long User_talk: page, then we have a problem. "Hey, stop being a jerk and archive your talk page" is something we can do. "Dude, stop being poor and buy a new computer if you want to report someone to ANI" is not something we can do. WhatamIdoing (talk) 22:54, 29 January 2026 (UTC)[reply]
Not necessarily. If 1,000 people have no problem posting the ANI notice, but one person does have a problem because they have too many plug-ins or scripts installed, or they're simultaneously downloading many files, or they're just using a 30-year-old machine, then "we" do not have a problem, just that one person has a problem, and "fix or update your client" is something we can say. Again: we should comply with industry-wide web standards, not with the needs of every single person out there. Levivich (talk) 22:59, 29 January 2026 (UTC)[reply]
Re: recommendations vs mandates, recommendations are basically unenforceable with enough determination from the user who does not want to follow recommendations. We already have a recommendation saying that Large talk pages are difficult to read and load slowly over slow connections and User talk pages must serve their primary purpose, which is to make communication and collaboration among editors easier. - Hint: make pages accessible enough to make collaboration easier. Does this recommendation work? No. There is a reason government pages require basic accessibility support, with reference to WCAG guidelines. There is no reason we cannot require this on our side. Szmenderowiecki (talk Ā· contribs) 23:10, 29 January 2026 (UTC)[reply]
And how exactly is this the job or responsibility of unpaid volunteers, as opposed to the engineers who are actually paid to make websites accessible and improve rendering time? Gnomingstuff (talk) 23:47, 29 January 2026 (UTC)[reply]
I have never seen anyone get any actual negative action against them if they fail to post on a user's talk page for an ANI report. Many editors are eager (perhaps overly so) to notice omissions and correct them. To avoid this argument (and I think it's actually generally a good change) perhaps we should amend the ANI rules to say that if you cannot reasonably, for any reason, post on a user's talk page, mention that in your initial report (or immediate reply). Skynxnex (talk) 00:54, 30 January 2026 (UTC)[reply]
More generally, even when specific forms of communication are not required, we expect editors to be able to communicate with each other. That includes making it reasonably possible for newbies to be able to leave a message on any page that is used for discussion.
ANI itself frequently breaks that limit; a handful of editors' User_talk: pages do as well. For example, I remember when DGG's talk page regularly ran >800K long (example) and sometimes exceeded a million bytes. That revision took about 10 seconds just now to load on a modern computer with a decent internet connection and all scripts/gadgets disabled via mw:safemode. @Levivich mentions industry-wide standards, which I believe are that pages should generally load within three to four seconds (because that's when users start giving up). Now imagine that it's not loading on my MacBook, but on a smartphone. Good luck loading the page. Extra good luck being able to edit it, or even to scroll to the end.
That old revision took about 8 seconds to load load on my modern phone over 5G. Most of the time was spent, I am pretty sure, by the server itself having to freshly fetch and render the page since it was probably uncashed for me. I think one circle I'm trying to square is that none of this should be be any editor's job. It shouldn't be a bot's job. There shouldn't be rules and potential punishments if you do it wrong. The MediaWiki itself should just allow editors to pick how many sections they see per talk page. Abd the rest are the archives. But of course the long history of talk pages just being a page makes that hard. But that sort of change is less disruptive than more rules. Skynxnex (talk) 05:40, 30 January 2026 (UTC)[reply]
What do you think the loading time would be if you were using a low-end phone (e.g., a JioPhone) on a pay-per-use data plan? I think it's safe to assume that the answer is "worse", and yours was already twice the industry standard. Did you try to scroll to the end of the page?
The problem with changing talk pages (remember Wikipedia:Flow?) is that the change would have hurt one group of people and benefited a different group of people. So naturally the first group complains that it's all harm and no benefit (to them), and the beneficiaries are already have difficulty with joining conversations, so they have much less ability to make their view heard. I don't think that reality will change this decade. We will probably have to wait until the small minority of editors who primarily use mobile devices become a more vocal part of the Wikimedia communities. In the meantime, what's happening is that mobile-heavy communities are finding off-wiki places for discussion and coordination (e.g., Whatsapp or Discord). WhatamIdoing (talk) 18:50, 31 January 2026 (UTC)[reply]
I support a limit on the size of user talk pages, but not on noticeboards, which are generally archived automatically and have not proved an issue in the past. However, I also think the horrendous formatting of this RfC has killed any chance of us getting a productive outcome here. Proposing seven different changes at once, some of which put the cart waaay before the horse (enforcement mechanism for a guideline that has yet to exist??) was a bad idea. Toadspike[Talk]21:34, 29 January 2026 (UTC)[reply]
Oppose all - I am yet to be convinced that there is a real problem with talk pages - annoyances yes, problem no. Nor do I think that any of the proposals would be an appropriate way to deal with the annoyances. When there is an issue with a talk page, our current rules (and lack thereof) give us FLEXIBILITY to deal with them as we think best fits the specific situation. This all seems to CREAPY to meā¦ boxing us in unnecessarily. Blueboar (talk) 21:46, 29 January 2026 (UTC)[reply]
Oppose as misguided and repetitious. As I already said in December, If archiving a thread is controversial, it very likely should not happen. If it's not controversial, there's no reason to wait until the page reaches some arbitrary size. The fact I am quoting myself from another RFC on this same topic barely a month ago suggests this RFC is problematic. āRutebega (talk) 23:00, 29 January 2026 (UTC)[reply]
Oppose all, as strongly as possible. Good grief, not this nonsense again! The idea of making this kind of stuff enforceable is downright offensive. --Tryptofish (talk) 00:14, 30 January 2026 (UTC)[reply]
Oppose as written This is a bit too much to do in one RfC. Would suggest rescoping this RfC to be targeted to user talk pages only (I'd assume that's why you wanted to make this RfC right?). In addition, outside of the user talk space, if the talk page is too big, no one is going to complain if you archive some stale topics so no hard guideline is needed. Workshop something that's basically "you have a problem if the average user can't discuss conduct issues on your user talk page" and I think that would be sufficient. JumpytooTalk01:54, 30 January 2026 (UTC)[reply]
Support a maximum size, absolutely. I have a reasonably good computer, and it still takes an absurd amount of time for some user talk pages to load. This is a collaborative project, where accepting communications is necessary, and should not be hobbled by an inordinate pride in an absurd talk page size. BD2412T04:52, 30 January 2026 (UTC)[reply]
Strong support some kind of stronger enforcement for accessibility, including a maximum size for user talk pages. I don't know why editors think the layout of their talk pages is so important that they can impede accessibility for others. Wikipedia is not a forum and talk pages exist so editors can communicate with each other, not so they can be fancily decorated or have years old discussions visible at first glance. There is a good reason we have a WP:SIZERULE for articles, and there is even less of a reason to not impose a strict limit on the size of user talk pages than for articles. While WP:CREEP can be a valid concern, it does not apply here, at least without meaningful justification as to why a user talk page might need to be that large. I don't have strong opinions on many of these particular proposals other than I generally echo the sentiment from others (particularly Toadspike) that this is far too specific/narrow a proposal to work. For the closer, you might interpret this as support b, e and f, oppose a and no opinion on the rest. Katzrockso (talk) 13:45, 30 January 2026 (UTC)[reply]
No. With all due respect, this feels like a case of wasting the community's time to resolve a petty issue of minimal consequence. I struggle to believe that even goofy talk pages like User talk:EEng present a real accessibility problem. How frequently does someone need to contact those specific editors so urgently that they can't wait a few seconds for the page to load, or wait until they are on a more reasonable browsing setup? Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds. -- LWGtalk(VOPOV)19:34, 30 January 2026 (UTC)[reply]
Oppose - None of these seem worth doing. Too many edge cases, too much bureaucracy when it's only very rarely a problem. On-wiki page sizes are tricky measures to use, because the size of the wikitext is not the same as the size of a page in a browser, with all the images and templates and whatnot. And there are some talk pages that really do need to be longer than others. So this all seems like for circumstances when both of these are true: (a) multiple people have difficulty using a talk page and ask for something to be done about it (or tries to do something about it), and (b) someone ignores the complaints and/or reverses efforts to fix the issue. The latter is very rare, and only ever an issue in userspace, where we tend to frown on other users jumping in to archive. Really, I can only think of one case where both of the above have been true on a usertalk page. I do not know why that person digs their heels in, or why several people reliably show up to insist it's cool, but them's the breaks with norm-breaking and social capital on wikipedia (and, let's face it, most places). In other words, if anything it's a one-off for an administrators' noticeboard, no ta new policy; and I'd also recommend against that noticeboard trip as pointless. As I wrote below, a new entry in perennial proposals would be justified at this point. ā Rhododendritestalk \\ 00:53, 1 February 2026 (UTC)[reply]
Why not zero? If all the discussions on my user talk page are a year old and refer to something long since resolved, who are you to tell me that I can't archive all of them? --Guy Macon (talk) 01:41, 1 February 2026 (UTC)[reply]
Establish a minimum number of 10 threads on pages, except on user talk pages. So I think we are talking about article talkpages. But often article talkpages contain only stale stuff that has been dealt with years ago and is no longer relevant. Polygnotus (talk) 01:53, 1 February 2026 (UTC)[reply]
I can see the value in the default being a non-zero value for article talk pages automatically archived by a bot, which cannot tell whether the stale stuff is still relevant. That also gives an approximate indication of how active the talk page is (if I ask a question there is it likely to be seen or should I hunt down a WikiProject?) but if editors at a particular talk page think a non-default value (including zero) is appropriate there then that should be allowed imo. Thryduulf (talk) 02:01, 1 February 2026 (UTC)[reply]
OK thanks, I think this proposal is confusingly worded. Certainly we wouldn't require pages to have 10 discussions on them, it seem that that is supposed that 10 part is supposed to only be about a parameter for this mysterious archiving solution - and not actually a minimum number of topics required on a talk page (i.e. a talk page can't even be CREATED unless you start 10 or more discussions at once). ā xaosfluxTalk01:32, 1 February 2026 (UTC)[reply]
I think this is intended to relate to the number of threads left on a page by archiving bots. For example Wikipedia talk:WikiProject UK Railways archiving configuration has the parameter minthreadsleft = 5 so old threads (in this case defined as 30 days since the last activity) will not be archived if it would result in fewer than 5 threads being left on the page. I'm at a loss as to why this is something that needs to be a guideline, let alone anything stronger. Thryduulf (talk) 01:50, 1 February 2026 (UTC)[reply]
Some people think a talk page with some discussions on it, even if they're really old, is more inviting for newbies. Possibly the proposer here is one of them. Or maybe the idea was just to avoid "unnecessary" archiving on very inactive pages since the proposal calls for automatic archiving of all talk pages. Anomieā02:01, 1 February 2026 (UTC)[reply]
That's the impression I got from reading the TPG discussion, where two issues were raised: disputes over manual archiving and empty talk pages that may result out of that. It was a minor thread in the discussion, but the people who did address it were largely opposed to both. Hence the proposal. Szmenderowiecki (talk Ā· contribs) 09:06, 1 February 2026 (UTC)[reply]
The easiest solution is an addition that anyone can archive any inactive threads on any talk page, and reverting these archivals is disruptive. sapphaline (talk) 10:10, 1 February 2026 (UTC)[reply]
Strongly oppose preposterous proposal for draconian, misguided, additional rules. I'll admit it: you lost me at your very first point, Establish a minimum number of 10 threads on pages. You mean you demand that we add up to 9 (or even 10) threads to every talk page on enwiki? No, thanks. I went on, anyway, out of basic respect, but your suggestion that we let the bots from Minority Report crawl over every page and disrupt even appropriate and useful retention of discussion did not entice me. Your hidden tableākudos: you collapsed it!āwas impossible for me to make any use of. I did see reasonably accessible but did not make it to the part where you defined "Reasonable". In summary, the specific parts of the proposed changes I do not like are a through g. Thanks for asking, but I can offer no support. ā JohnFromPinckney (talk / edits)23:04, 2 February 2026 (UTC)[reply]
Counterproposal
EEng is asked to archive his talk page.
If, within 7 days, EEng doesn't archive his talk page so it works like a normal talk page, then EEng is topic banned from editing any other page except his talk page. This sanction expires when EEng's talk page works like a normal talk page.
Quick question: how does this help us achieve our goal of a world in which every single human being can freely share in the sum of all knowledge? Polygnotus (talk) 21:01, 31 January 2026 (UTC)[reply]
I have asked Quiddity to find a WMFer who can dive into the technical stuff; that way we have a solution for all long pages once and for all. Polygnotus (talk) 21:09, 31 January 2026 (UTC)[reply]
S Marshall is asked to stay on topic, avoid personalizing discussions, and stick to general principles of Wikipedia.
If User:S Marshall continues to waste everybody's time by perverting this discussion and turning it into an attack on one editor (and in the wrong venue), then S Marshall shall be required to write one hundred times on a Village Pump subpage (which may be entitled, .../Blackboard, if desired) that "I shall stick to the point and avoid personalizing the issue and being a general dufus at Village Pump." (in cursive)
I think this talk section illustrates vividly how unhelpful the entire idea proposed at the top really is. And frankly, this section (not the whole discussion, just this section) should be closed and hatted as a personal attack. --Tryptofish (talk) 22:00, 31 January 2026 (UTC)[reply]
should have been hatted the moment someone brought donald trump into it, really
Has this been retained (not archived) for humor reasoning, a community consensus against one or more editors, or maybe the love of drama and large talk pages? Surely it is not because of a lack of archiving knowledge-- Otr500 (talk) 22:41, 31 January 2026 (UTC)[reply]
Is it time to just add "force EEng to make his user talk page functional" to the list of perennial proposals? Or an extension of WP:UNBLOCKABLES called "WP:UNARCHIVABLES" or "WP:UNTALKABLES"? Raised by many people many times over many years, but just gets a bunch of "relax, it's no big deal" responses from third parties. After it crashed my browser a couple times some years ago, I'm certainly not going there (not that I've had a need to), and I light a candle for any newbie who tries to leave him a message on mobile. But yeah, I agree with the pile-on above that we're not going to institute hard rules for this. It's one of those fairly-low-stakes-in-the-grand-scheme-of-the-project norms that everybody just kind of does because we want this to be a place where collaboration is easy and we don't make life unnecessarily hard for each other, and which we're realistically only going to enforce if someone lacks social capital. Adding: EEng is not usually the person with the longest page -- we should enforce this evenly or not at all -- but EEng is certainly the page that comes up most frequently. ā Rhododendritestalk \\ 23:12, 31 January 2026 (UTC)[reply]
It occurs to me that a counterproposal that involves the idea of sanctioning EEng is something that EEng ought to be notified of. (Oh, but his talk page was too long to notify him, I get it! rolls eyes) So I did it: [12]. --Tryptofish (talk) 23:39, 31 January 2026 (UTC)[reply]
I've been trying to talk to you for about half an hour Tryptofish and got edit conflicted every single time so you get the short version.Your claim that this reduces to a personal attack on EEng is wildly mistaken. It's about EEng personally. It's about a problem with EEng's talk page behaviour. But it's not an attack to propose a solution.āS MarshallT/C23:45, 31 January 2026 (UTC)[reply]
And, the solution for EEng is not the solution for every editor in the long talk pages category. Some of those talk pages load easily. Some of the editors are indeffed and it's not realistic to expect them to fix it.āS MarshallT/C23:47, 31 January 2026 (UTC)[reply]
But, EEng is a user in good standing who's bright enough to see that his talk page is a problem. He's well aware that it needs to be fixed. We've established at the DRV that preceded this mess that other people don't get to archive EEng's talk page for him.āS MarshallT/C23:49, 31 January 2026 (UTC)[reply]
Therefore there's only one person who can fix the problem and it's EEng. He knows he needs to do it. He hasn't. So I suggest ways of making him.āS MarshallT/C23:51, 31 January 2026 (UTC)[reply]
In a collaborative project you must have a talk page people can work with. If people can't work with your talk page then you're being uncollaborative. It's the Wikipedia equivalent of antisocial behaviour.āS MarshallT/C23:53, 31 January 2026 (UTC)[reply]
There isn't only one way to look at this. There's several different ways. One way I like to see it, is that outside of article space, I don't care how long a user talk page is, but it presents technical problems that have yet to be solved. When I comment on a long talk page on my desktop and on my mobile (using desktop view), there is a bit of lag that makes using the reply function impossible. Using the edit section isn't as bad, and adding a new comment entirely tends to work. This shows that there is a problem with MediaWiki, not EEng. How about we fix that first? Viriditas (talk) 00:10, 1 February 2026 (UTC)[reply]
In a perfect world, MediaWiki would be less ghastly. But we don't control that. We have to work with the software we have, not the software we want. So we need volunteers to have the behaviours that make the software work. EEng doesn't. It's got a lot in common with hoarding: begins with a disinclination to get rid of old rubbish, but over time it evolves into a situation where the neighbours are complaining about the smell and the postman can't force any more mail into the overstuffed letterbox.āS MarshallT/C09:52, 1 February 2026 (UTC)[reply]
S Marshall, you and I have both been around this project for a very long time. (Indeed, I remember the verifiability-not-truth debates of a bygone era.) You, like EEng, are a user in good standing who is bright enough to realize that this discussion you have started is only inflaming the issue, and not accomplishing anything productive. If you have accomplished anything at all, it's that you just might have caused more editors to come over to the opinion that is opposite to your own. --Tryptofish (talk) 19:31, 1 February 2026 (UTC)[reply]
Well then I don't know if it's the case that no one got the ping or it's just random users in the list didn't get it, or maybe those that were at the bottom of the alphabet? I knew that {{ping}} only fits 50 usernames but I didn't know that one comment couldn't have more than 50. Szmenderowiecki (talk Ā· contribs) 16:17, 29 January 2026 (UTC)[reply]
@Szmenderowiecki This is just a bad RfC which is probably why people don't respond to it. And I don't really see the point. What are you hoping to achieve? We already had this discussion a short while ago. Polygnotus (talk) 16:25, 29 January 2026 (UTC)[reply]
This is just a bad RfC - in what way? I'm looking at WP:RFC and I don't see your point. You can disagree with the premise (which I guess you will based on your prior comments) but it doesn't make it a bad RfC.
We already had this discussion a short while ago. - addressed in the table.
which is probably why people don't respond to it - We are just two hours into the discussion, so how do you know?
What are you hoping to achieve? - minimum accessibility standards that will cause at most moderate performance issues for all users wanting to engage in Wikipedia discussions; also stopping quarrels about archiving preference. Szmenderowiecki (talk Ā· contribs) 16:34, 29 January 2026 (UTC)[reply]
This is just a bad RfCin what way? you don't have a clear understanding of the situation so any proposal you make is hindered by that.
We already had this discussion a short while agoaddressed in the table. Maybe, but this is still a problem.
which is probably why people don't respond to itWe are just two hours into the discussion You are, that is my point, but" we" as an alleged community are not "just two hours into the discussion"
minimum accessibility standards that will cause at most moderate performance issues that proves you don't understand the problem. Read what I wrote in that earlier discussion. Then think about it for a day or two. Then, if you have a good idea you can propose it. But starting an RfC and pinging a bunch of people when you haven't really understood the problem, the various factions in the debate and the upsides and downsides of the various options is unlikely to lead to a good result.
I don't think there are archive bots that dynamically adjust aggressiveness of archiving. This would be ideal but require a bit of coding I simply do not have the brain for, and I think this will actually be hard to code well, and will be likely too much effort for someone who is not paid for the coding. But you didn't ask anyone... You don't have to be a nerd to have a good idea, but when talking about (talk) page archiving it does help. Polygnotus (talk) 16:41, 29 January 2026 (UTC)[reply]
I may or may not have resting bitch face in English. In 2003 Brooke Vibber wrote: There's no theoretical maximum, but our server only has 2 gigs of memory, so don't push it please. ;) In all seriousness though, I very strongly recommend against letting articles grow beyond 32 kilobytes.[13] Server. Singular.
We may need to write a userspace essay explaining how long this topic has been debated for and how complicated it is so that we can stop new users who aren't nerds wasting a bunch of everyone's time. Note also [14] and [15] and [16], this is not the first time. Polygnotus (talk) 19:55, 29 January 2026 (UTC)[reply]
Wow, I missed that before. This whole, huge, indigestible discussion no longer looks like a good-faith effort to improve editor collaboration by making talk pages more generally accessible (a totally defensible goal per se). It now looks to me more like a way to harass an editor in a fit of pique after previous attempts to directly interfere with their chosen archiving one-on-one were rejected and undone by admins, lightly concealed as a broad, improve-accessibility discussion. Only, this time, their fit of pique is not only harassing one user, it is wasting the time of many users. This is completely unacceptable. This isn't ANI, but by raising this discussion, Szmenderowiecki's behavior should be open to scrutiny as well. If there were a proposal on the table to ban Szmenderowiecki from starting a discussion on archiving or pagesize for eighteen months, I would vote to support. Mathglot (talk) 07:16, 1 February 2026 (UTC)[reply]
The first link is irrelevant to this discussion, the second link is the DRV, the third is literally a companion discussion to DRV. I am using all forums for their intended purpose. Mathglot I started this discussion because it became apparent to me at DRV that there are no good procedures to enforce talk page accessibility, which I believe are needed. This is the only reason I was starting this discussion. I am amazed that some editors dismiss my concerns as fake. I urge you to strike your accusation of me trying to harass editors. If you insist or want to go the route of banning discussion, go ahead, but that accusation, and that of any other editors suggesting I'm trolling or creating the concern out of thin air, will also be brought to light in appropriate forums if need be. Szmenderowiecki (talk Ā· contribs) 08:57, 1 February 2026 (UTC)[reply]
I am sorry, but that is my honest impression, right or wrong. If I were in your shoes, I would comment anywhere but here, as it will only draw more attention to your actions. In my opinion, you are skating on thin ice, and the more attention paid to this, the more likely it is that it will cause trouble for you now, or at some later date. You are of course always welcome to raise accusations you view as inappropriate at the appropriate forum, which would be my Talk page, followed by WP:AN/I if you don't get satisfaction there. If you just want to vent, I invite you to my Talk page. I can be very conciliatory, and will listen to what you have to say. Maybe it will make you feel better. Good luck, Mathglot (talk) 09:40, 1 February 2026 (UTC)[reply]
I'm not going to be the one to escalate, so the ball is in your court. I don't think any disciplinary intervention is necessary for any party here, for now, at least if you strike that accusation. I'm not going to be the one who shouts WP:UNCIVIL at the slightest hint somebody makes a faux pas and the one who drags you to ANI. I've worked jobs where people assaulted me every once a while and where I learned a lot of very interesting things about who I am and where I need return to (as a naturalised immigrant). I managed to still maintain a poker face most of the time and grow somewhat immune to these attacks. Bickering strangers on the internet are several pay grades below that. But I will mount a defence if necessary. Or remain silent where I believe it will be best for my case. Szmenderowiecki (talk Ā· contribs) 09:53, 1 February 2026 (UTC)[reply]
I have no wish (nor time) to escalate, so we agree on one thing at least. Sorry to disappoint, but I will not strike, as it represents my honest opinion. I agree that remaining silent is best for your case. I should add that I did not realize you were an immigrant and I am very impressed (and envious) of your command of English, which to me, appears to be of native-speaker level. I wish my abilities in foreign languages were as good as yours. Kudos! Mathglot (talk) 10:38, 1 February 2026 (UTC)[reply]
Szmenderowiecki, Actually, I will strike under one condition: I strike my comment, and immediately following that, you withdraw and {{hat}} this proposal as "|status=withdrawn". That would be to the general benefit of everyone. Do you accept? Mathglot (talk) 10:50, 1 February 2026 (UTC)[reply]
If there is a viable alternative proposal, I will withdraw this one. I am in works of discussing another one proposed by Sapphaline. This is independent of my request to strike/remove. PS. For the future, I have a thing to say: editors are always responsible for their edits. It's only your decision because you made the claim. I don't want it to be on you, and I'm not going to complain myself. But if you stand by your claim, I reserve the right to consider it if necessary for any appropriate defence against any allegations. This is because if you have that honest opinion which you stand by even upon request to retract, this should imply that you have good evidence to back it up, which will stand upon independent scrutiny and presentation of all exculpatory evidence. And I want that possibility to rebut any point of that potential complaint, hence the "reserve the right". I still appreciate honesty, even if it occasionally breaks rules of what discussion should look like. Szmenderowiecki (talk Ā· contribs) 14:02, 1 February 2026 (UTC)[reply]
you don't have a clear understanding of the situation so any proposal you make is hindered by that - sorry?
that proves you don't understand the problem. Read what I wrote in that earlier discussion. Then think about it for a day or two. Then, if you have a good idea you can propose it. Read all these discussions, understood them well, and I disagree with your premise. You can disagree with mine. You can think of it as a terrible idea but it doesn't mean it becomes a bad RfC question.
But you didn't ask anyone... You don't have to be a nerd to have a good idea, but when talking about (talk) page archiving it does help. And no one came up with that idea at the idea lab, where you could have participated and told me this was a terrible idea and maybe we should do something else instead... That discussion was up for almost a month in a high-traffic forum. You could have proposed that idea yourself, the idea I didn't have before that comment. Why nobody thought of that before? Why do you blame me? For what?
neutral and brief - you just seem to be opposed to holding the RfC because you are satisfied with the status quo rather than having problems with neutrality and brevity. Because you don't say how it's not neutral. It's not the shortest statement but it's definitely not out of place for RfCs I witnessed in terms of size. Szmenderowiecki (talk Ā· contribs) 16:54, 29 January 2026 (UTC)[reply]
@Szmenderowieckiyou just seem to be opposed to holding the RfC because you are satisfied with the status quo To me it seems to be the other way around. It looks like you disagree with consensus formed in the recent preceding discussions (which is allowed of course) and then started an RfC that ignores the opinions expressed in them. Combine that with a very long and non-neutral RfC statement and you got a bad RfC. Polygnotus (talk) 17:02, 29 January 2026 (UTC)[reply]
I mention that the way I read that discussion was that the 75 KB wikitext limit was removed, and that's it. Nothing more, nothing less. The question was not specific enough to say if that means no limits or maybe some higher limit or something else. That was a bad RfC, because the result's interpretation is ambiguous. And you know it because you engaged in that discussion extensively. Szmenderowiecki (talk Ā· contribs) 17:12, 29 January 2026 (UTC)[reply]
What the hell is this, your idea of a "big beautiful bill"? I presume I was pinged to here because of my close of this thread. It seems you've disregarded my advice to start separate RfCs for article-talk and user-talk. I do not care to spend hours getting up to speed on what you're asking for ā your ping was an annoying distraction when I'm trying to stay focused on tasks in my to-do list which require focused concentration. Pick the one change that you most want to make, and which you believe has a strong chance of obtaining a consensus, and start with that, please. I'm not a member of a political party who will just vote up or down on your big bill, based on how my party leadership tells me to vote, without even bothering to read the details of the bill. ā wbm1058 (talk) 17:14, 29 January 2026 (UTC)[reply]
What the hell is this, your idea of a "big beautiful bill"? Trump aside, the proposal was up for a month on a high-traffic page. Why didn't you engage? I gave a list of ideas and anyone could have said the thing you say now. But no, I have to be pummeled at the start of the RfC because people don't bother to look at the very place intended for workshopping proposals. Why workshop them at all then?
I presume I was pinged to here because of my close of this thread. - no, that's because you posted in the Discussion : Recommended maximum talk page size part.
It seems you've disregarded my advice to start separate RfCs for article-talk and user-talk. As I said, I see no functional difference between these two. I am free to disregard your advice if I believe it's bad advice.
your ping was an annoying distraction when I'm trying to stay focused on tasks in my to-do list which require focused concentration - Jesus Christ, I didn't know that pings can make people so cross. You don't have to engage with it, you can come to it later if your task list is what you need. There's no need to be so worked up. Szmenderowiecki (talk Ā· contribs) 17:28, 29 January 2026 (UTC)[reply]
I have no idea what proposal was up for a month on a high-traffic page, but it's not this proposal. The idea lab thread? At almost 1,500 watchers, 9K pageviews per month, you bet it's a pretty high-traffic area. Or at least one that people supposedly watch.
Ad Aaron Liu: A recommendation is unenforceable. I meant it to be specifically a rule. If I wanted to make it a recommendation, I would have said so, but IMHO there's no point to discuss a recommendation if there's no enforcement of the recommendation.
Who cares if something is recommended if I disagree with the recommendation and there's nothing against disobeying the recommendation? Same for essays: who cares about essays if anyone can say "essay is not policy/guideline, so leave me alone"? Anyone's understanding of terms like "reasonable", "substantial", "large", "slow", if not backed by specific numbers, is different. What is "slow enough"? Is this "reasonable"? Is this inconvenience "substantial"?
Some people say "this is against current practice". OK. Just because it's current practice doesn't mean it's good practice. Substitute "current practice" with "industry standard", and you'll see what I mean.
Unfortunately, untangling a single piece of it is going to be very hard. Presumably, for the sake of simplifying discussion, it's going to be the size limit. So let's look at it:
- People are still gonna edit war over archiving and that's a concern, expressed incidentally at the TPG.
- I read opinions from certain users that manual archiving is busywork, and I agree. Also expressed incidentally at TPG.
- Doesn't address lack of archiving on pages like ERRORS.
- Enforcing anything on user talk pages without an impartial and specific mechanism is going to be hell.
- People are gonna ask: why only enforcement on user talk and not any talk? Well, that enforcement was supposed to be archive bots/logs (mostly) but you insist this be one proposal at a time, so I can't propose this. Unfortunately certain proposals only work in tandem.
- Empty talk pages are a concern for some users, and I agree with their concern - and it was discussed at the maximum talk page size discussion of all places, not minimum. So I felt it was necessary to address. I again get pummeled for that.
(Contrary to some suggestions, I don't mean this proposal as a snide against EEng. EEng's page was not the first time I had this problem, I just didn't speak up. This is a general applicability rule. Any talk page about 500 KB is absolutely terrible for my browser just reading it, pages of the size of ANI are terrible editing them). Szmenderowiecki (talk Ā· contribs) 18:24, 29 January 2026 (UTC)[reply]
You'll notice there are very few guidelines as rigid as what you propose.Ease of implementation is always something policywriters need to consider. Min threads and max archive size are going to be hard to implement.It is great that you've identified and analyzed issues and are willing to put in the work or fix them. But often, if you put them forward in an RfCāthe process for attracting as many participants as humanly possibleāwithout consulting through non-RfC discussions, you are going to attract as many participants as humanly possible that have a lot of questions. Aaron Liu (talk) 22:32, 29 January 2026 (UTC)[reply]
This proposal does not say anything about min size. minthreadsleft or similar exist in both of the used bots. Max size is easily implementable by something like this: If pagesize exceeds, say, 200KB, archive the oldest discussions whose last comment was at least a year ago; if still exceeds, decrease by 30 days until you get within 200KB, but not below 10 days. Or something like that. But often, if you put them forward in an RfCāthe process for attracting as many participants as humanly possibleāwithout consulting through non-RfC discussions the problem is that I have consulted my proposal. The gist was always there: mandatory automated archiving and limits on all pages intended for user communication. There may be an detail that I have not, but I consulted most of it. And people are shouting me down for this. Szmenderowiecki (talk Ā· contribs) 23:00, 29 January 2026 (UTC)[reply]
Yes, I'm talking about min threads. You're not going to stop the extremely-popular manual archiving by just forcing changes to the most popular bots. It will also be hard to set up automatic archiving everywhere.I'm sorry, but I did not see where you mentioned a, c, f/g, the change from "should" to "force", or the 50%/90% reduction in the page size limits. I did not see where you mentioned mandatory automated archiving at all. Aaron Liu (talk) 03:36, 30 January 2026 (UTC)[reply]
It will also be hard to set up automatic archiving everywhere. Nope, all it takes is a bot function that automatically introduces e.g. {{subst:setup auto archiving}}, when the first talk page thread is created. It is going to default to the loosest parameters, but you can change them manually later. For existing pages, check for existing archive, if there is none but there are talk page threads, automatically deploy. I'm not a coder but pasting a text if a certain piece of text exists isn't a complicated piece of code we are speaking of.I'm sorry, but I did not see where you mentioned a, c, f/g, the change from "should" to "force", or the 50%/90% reduction in the page size limits
a was originally expressed as the minimum size limit (it was 500 KB HTML, but it could be 200 or 300 or even 100, so long as it's not 0. The pseudocode part at the bottom included the minkeepthreads parameter. I got feedback that the code was "too complicated", so I simplified it. I was never that part was a bad idea.
c (mandated archiving) is literally the second bullet point in the VPI.
f is the seventh bullet point
g was discussed along the way.
the change from "should" to "force" Equivalent in meaning for purposes of guiding user behaviour. If "should" had been supposed to be a non-binding recommendation, the discussion would have made no sense.
the 50%/90% reduction in the page size limits. I don't know what you are talking about.
Szmenderowiecki, is it then your position that mandatory automated archiving would apply to all user talk pages, including those currently archived manually? As an example, my user talk page, now nineteen years old, is manually archived and always has been. If your proposal achieves consensus would I have to give up manual archiving and submit to obligatory bot archiving? What about users who manually archive by theme (or other algorithm of their choice) instead of last comment age? Oblige them to switch as well? Mathglot (talk) 03:49, 30 January 2026 (UTC)[reply]
Read the proposal carefully and you will get the answer. Short answer: no, do whatever you want so long as you keep within the size guidelines out of your own accord. If you refuse upon request, or you have trouble keeping the maximum size long-term, only then it becomes a yes. Archiving by theme will not be possible because we don't have bots that guess the discussion's context and sort discussions into buckets according to what you are talking about. If an admin wants to manually sort their discussions, fine, but I don't expect admins to do that because they likely won't hve the time and their job is not to micromanage others' talk pages. If you don't want this to happen, keep within your 1200 KB HTML and you'll be golden. I'm upfront that this is a restriction on user autonomy, but user autonomy, just like generally being allowed to edit, is not a right, it's a convention. If your user autonomy makes others suffer, you are abusing it. Szmenderowiecki (talk Ā· contribs) 10:46, 30 January 2026 (UTC)[reply]
Any talk page about 500 KB is absolutely terrible for my browser just reading it @Szmenderowiecki: Three quick questions. What browser are you using, how much RAM do you have, and how fast is your download speed? This is because I think the problem here may be your device, whatever it may be.
This is not to say that people should intentionally keep talk pages large just for the fun of it; I'm just saying that there may be technical limitations on your end that are affecting your ability to read really large pages. I can still open EEng's 972k talk page in Safari on my iPhone 11 with 140 other tabs and 24 other apps open, probably because iOS is really good at memory management and frees up memory from inactive apps and Safari tabs. Trying to edit EEng's talk page, however, is a different matter... SuperPianoMan9167 (talk) 23:19, 29 January 2026 (UTC)[reply]
Sure: Chromium 143, 8 GB RAM, 25 Mbps download on WiFi. RAM is 100% not an issue because I have tons of spare RAM without forced cleaning, neither is download speed because the whole source code should be downloaded within at most a second, shorter than the rendering itself. Everything works pretty fine with these parameters on any web site until I get to gargantuan talk pages on Wikipedia. Or try to edit big talk pages. It's not a "me" problem. Szmenderowiecki (talk Ā· contribs) 23:31, 29 January 2026 (UTC)[reply]
Okay. I figured as much but I still wanted to ask.
I admit that I have sometimes experienced issues on very large pages; I've gotten the "This webpage was reloaded because a problem occurred" message (which is Safari's way of telling you that the page crashed because it ran out of memory) on large talk pages before. When I scroll down a very large page, it usually takes a couple of seconds for the page content to appear. And of course, the sheer size of these pages makes them difficult to navigate on mobile (Minerva skin helps to make this less tedious). SuperPianoMan9167 (talk) 23:41, 29 January 2026 (UTC)[reply]
Minerva skin looks shit on desktop, and besides readers are very likely not aware that they can change the skin using the "Mobile version" link, and quite a few may not be even aware of the possibility.. So long as we allow IP editing, any reader may become an editor with no warning. Any IP who wants to post on any noticeboard or talk page and the noticeboard is 500K+ is likely to abandon the effort due to the lags. This is unacceptable Szmenderowiecki (talk Ā· contribs) 10:50, 30 January 2026 (UTC)[reply]
My understanding is that there's no standard way of archiving pages and so there's a mish-mosh of bots and tools. I've evolved my own way of filing my talk page but it's too manual for my taste. Anyway, I have a question. What I'd really like is a simple method of moving a section from one page to another. This is the way that email and other documents are usually filed -- you move them to folders. Is there such a thing in Wikipedia? Andrewš(talk) 17:30, 29 January 2026 (UTC) (edit conflict)[reply]
I believe the closest we have is one click archiver, but in theory it should be possible to develop something that can do a similar action but to a manually defined page. CMD (talk) 03:34, 30 January 2026 (UTC)[reply]
BTW, every time I've tried to say something in this discussion, I've gotten an edit conflict. Wiki software is really poor at doing user communication when compared to just about everything else. Andrewš(talk) 17:34, 29 January 2026 (UTC)[reply]
I've heard of that tool before but it seems too complex for my needs and I gather that it is resource-hungry. Looking at its talk page, it seems that there's an incompatibility which is going to break it. I've seen many useful tools broken as a result of change and that's why I think all such infrastructure and interface should be managed centrally by the WMF. Andrewš(talk) 23:19, 29 January 2026 (UTC)[reply]
I daily-drove the parser migration tool (which allows you to set your default parser to parsoid) in late 2024 and had no issues with CD (in fact, little issues at all other than the reduced server caching increasing page load times). I just checked again and everything works. @ChildrenWillListen probably had a configuration issue. There's been many calls for WMF to maintain promising infrastructure. WMF couldn't even install it. (slightly clickbait, but I couldn't figure out a better way to summarize this, sorry) Aaron Liu (talk) 03:31, 30 January 2026 (UTC)[reply]
You mean the same engineers who built out the internet to give us a postliterate society where everyone is addicted to screens, where people no longer read books, where society is more susceptible to disinformation and propaganda, and who are solidly against the humanities and democratic values? Those guys? Viriditas (talk) 22:47, 31 January 2026 (UTC)[reply]
Please keep in mind about mobile users, who because of such small screen size have to contend with extremely difficult scrolling of pages with long discussions or too many threads (especially as the font size for thread headings can be relatively large ~2026-63332-0 (talk) 17:54, 29 January 2026 (UTC)[reply]
~2026-63332-0 consider going to WP:VPI and proposing that the WikiMedia software automatically provide page nav links 'skip to top' and 'skip to bottom' for moibile users, when the page size or number of threads is greater than X (user preferences-configurable). Then, after you get some feedback and some kind of working consensus there on what might be useful and have some support, take it to the meta:Community Wishlist and register your wish. Mathglot (talk) 19:34, 29 January 2026 (UTC)[reply]
Minerva skin already provides a "Latest comment" link at the very top of the page and in the header of each section, which is very helpful. In fact, it is so helpful that I sometimes find it easier to comment on talk pages on my phone than on my computer in Vector 2022.
(Yes, I use Vector 2022. Experienced editors may now publicly shame me. I've been reading articles here for long enough to remember a time when it didn't exist yet. I also (gasp!) used VisualEditor when I started editing, but I eventually quit using it because I find that writing wikitext directly is much faster, especially on mobile where I don't have access to keyboard shortcuts.) SuperPianoMan9167 (talk) 23:52, 29 January 2026 (UTC)[reply]
That's good to know; that means that the code to do this already exists, and porting it to other skins should not be that difficult. I would say in response to temp user 63332, that either in addition to, or instead of the Community Wishlist idea, you could file a Phabricator ticket requesting it as an enhancement. (I think you have to be registered, but make a request at WP:Help desk and I am sure someone could help you with that.) Mathglot (talk) 02:32, 30 January 2026 (UTC)[reply]
CapnZapp I'm confused about your order of opposes in justifications.
The A part refers to what, the introductory statement or the mandatory archiving? Mandatory archiving does not speak about user talk exemptions or even user talk at all in the justification. User talk is specifically exempted, end of story. What are you talking about?
The B part presumably refers to specific limits. I don't have a problem with EEng, I do have a problem with his talk page, as with hundreds of others I cannot easily read, interact with, let alone edit. Also, good luck.
C (max archive interval) misunderstands the proposal. The 10 day limit is only meant to cover high-traffic pages ("likely to routinely exceed the maximum size limit"), and that's additionally explicit in the last sentence.
D is not substantial to this discussion, I could have edited this myself.
E: Why 4 minimum threads specifically? I had opinions that 1 is the number. Some prefer 2. Some prefer 5. We can discuss it.
F: Impossible to discuss in separation of B because there are no maximum user talk page size regulations right now, so such change would be meaningless. I'm not sure what I'm poisoning by opening this discussion.
H: Possible to discuss at the archive bot pages, but will likely discourage people from using bots. So pretty much impossible to discuss without A because it's pointless. It is meant to be the automated enforcing mechanism. Szmenderowiecki (talk Ā· contribs) 18:48, 29 January 2026 (UTC)[reply]
I explained at the start. Basically, I went through the table, creating a point for each row. Only once I was done did I realize you failed to match your a-g to your table. CapnZapp (talk) 18:54, 29 January 2026 (UTC)[reply]
My comment before was that Endorse This is the single stupidest thing Iv ever seen be discussed on here. I'm legit laughing my tired ass off, and despite having zero memory of writing that(it was 3AM, and I was coughing up a storm). I still stand by it and it's even more funny that this was made seemingly solely because of EEng.
Has anyone ever considered that if we weren't such assholes about it, he might be willing to archive more often? Or ask him to add skip to top or bottom buttons like iv seen on a few other user talkpages?
We have had this discussion so many times, it always ends the same.
If the page starts crashing browsers, bring it up to him, otherwise, just wait the extra two seconds for it to load. And use the edit section function.
From the table: Single discussions split into their own pages due to size considerations are exempt from internal archiving but have to be searchable through archives of the page they were split from.There might be creation of subpages due to size considerations, but I understand that there may be discussions with huge turnout wbhich cannot be split, or pages with several questions that are interconnected ando so would be inadvisable to split. So there's no dedicated solution for this problem. Accessibility is an issue due to poor performance, but any other solution would be worse. Szmenderowiecki (talk Ā· contribs) 22:13, 29 January 2026 (UTC)[reply]
I'm here because of the ping. I don't like anything about this proposal, but I do like the comparison made in this discussion to the so-called Big Beautiful Bill. --Tryptofish (talk) 00:17, 30 January 2026 (UTC)[reply]
You gave the reason yourself above (@23:10, 29 Jan) why this Rfc was unnecessary and a gigantic waste of time; quote:
We already have a recommendation [about] [l]arge talk pages...
Precisely. There are different levels of obligation and administrative enforcement depending on how serious a particular kind of violation is, which is why adding copyrighted material to a Wikipedia article or libeling someone is going to get you in hot water faster than conflict of interest violations, which in turn will get you in trouble faster than WP:Manual of style violations.
As you say, we already have a recommendation about this, but apparently, your opinion is that the existing recommendation doesn't have enough teeth in it on the enforcement side, hence all the draconian language trying to sharpen the teeth. But this violates the sense of proportion. There is a reason that libel and copyright get more attention and stricter enforcement. No doubt in the thicket of Wikipedia regulations, improvements can be made, but we do not want very large talk pages to have the kind of enforcement wording or response that libel does; it is way out of proportion to the seriousness of the violation (if it is even deemed a violation at all). Nothing in your Rfc proposal is an improvement over current guidelines imho, imperfect as they my be; rather, they would make page and archiving guidelines worse, and cause additional strife among editors, perhaps resulting in enforcement discussions against users with long talk pages. Is that really the hill you want to die on?Mathglot (talk) 02:58, 30 January 2026 (UTC)[reply]
Precisely. There are different levels of obligation and administrative enforcement depending on how serious a particular kind of violation is You may disagree with me on this point, but overbearing talk pages that barely load and are all but impossible to edit are pretty much a serious violation on a website whose core tenet is enabling editing and good-faith discussion by anyone interested in the topic or in a contributor at any time. If the "anyone can edit" (=have technical tools to edit) part in "Wikipedia is a free online encyclopedia that anyone can edit" can be rendered effectively moot, then it should not advertise itself as such. If Wikipedia effectively forces users to switch from not-clearly-outdated devices to view/edit content, it is no longer anyone who can edit.Also, the enforcement for libel and copyright violations is potential blocks as well. This rule is not meant to create another means to block someone because this can be resolved without blocking anyone. And I wrote just that in the reasons. So despite the seriousness of obstruction of talkspaces, it does not escalate to revocation of editing privileges. Szmenderowiecki (talk Ā· contribs) 11:13, 30 January 2026 (UTC)[reply]
"Overbearing talk pages that barely load and are all but impossible to edit" would be a problem if they existed, but they don't. As another user said, "Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds."
And even if they did exist, the rational approach would be to go to ANI, document the problem, see what happens when others try to replicate it on similar hardware, and if the problem is real deal with that one page. (If anyone does this, ping me. I have a number of ancient computers running ancient browsers available to me) --Guy Macon (talk) 03:16, 31 January 2026 (UTC)[reply]
Also, while it might be great if everyone could easily use any device to leave messages at all talk pages, forcing compliance with a uniformity rule would make Wikipedia a nastier place with the side effect of encouraging rule-pushers while discouraging a variety of editors. Johnuniq (talk) 03:50, 31 January 2026 (UTC)[reply]
Guy Macon, is it that you insinuating that I am lying my ass off about the problems I have with loading the pages, do you pretend to know better than me how my device works, or are you saying "not a problem for me, so deal with it"? My device specs are public knowledge at this stage. Some of the devices I use to browse the web are so ancient that they struggle to load most pages on the web, but I was still able to load User talk:EEng, scroll through the sections, and click edit on a section of my choice in about 30 seconds A lot to unpack here:
We don't know what the specs of that device that loaded the page for 30 seconds were, and what software they use.
We don't know if that device is one of the "ancient" devices that the user uses for browsing the web (what is "ancient"?). What they said does not exclude the possibility that they tested it on an iPhone 16 Pro or some modern PC for $2000+.
the rational approach would be to go to ANI, document the problem, see what happens when others try to replicate it on similar hardware, and if the problem is real deal with that one page Or maybe, just maybe, avoid all this dragging to ANI unless absolutely necessary and document a procedure that everybody knows, and everybody is aware what happens if it is not followed? And not bog down in discussion on whether your device sucks, on whether you should change your device, lifecycles, operating systems, differences in browsers, popular userscripts you choose to run and so on? I thankfully see, hear and read well, but there are folks who have to read Wikipedia with a page reader. Folks who need high contrast because they don't see that well. On Chrome, this is done via extensions. But these extensions will struggle even worse on huge pages. Which is a reason you don't do huge pages unless absolutely necessary. (OK, you'll say, this concerns like 1% of readers/users, so whatever, suffer. Well, modern public transport has Braille and wheelchair ramps not because there are a lot of blind/physically disabled people but because they also deserve the service. It generally features low-floor vehicles not only for these people but for anyone - whether you are a normal passenger or you carry a big bag of groceries home or maybe a bicycle or a stroller. You could have the bare minimum of seats for the frail to cram as many people as possible within a given budget for new vehicles - after all, most people can stand up for 15 minutes just fine - but that doesn't normally happen because passenger comfort is also a valid consideration.) Same logic applies here. forcing compliance with a uniformity rule would make Wikipedia a nastier place with the side effect of encouraging rule-pushers while discouraging a variety of editors. One by one:
nastier place: in which way?
side effect of encouraging rule-pushers: where possible, make rules that are clear, unambiguous and tight so that they do not leave the possibility for wikilawyering. Simple as that.
discouraging a variety of editors - well, the inaccessibility discourages me from engaging on Wikipedia because I have that info in the back of my head that I will not be able to edit certain pages without some non-standard hacks. And I'm pretty sure I'm not alone, but I'm also pretty sure not everyone would want to search for said hacks.
Also, the difference is that libel can get you sued and long talk pages can't. POV pushing is a serious violation of Wikipedia's rules, but will not generally get you sued. Same for obstruction of discussion process. I don't see your point.
Plain text rendering is extremely fast. Even large amounts of text render quickly. The bottleneck on Wikipedia is almost always JavaScript, especially scripts that process the entire page. So limiting the amount of plain text makes no sense.
Loading large external resources (images) can slow things down, but usually those get cached so they would only be slow once. So in your case the reason is JavaScript.
Find a page on which the problem is reproducible (ANI?)
Visit that page in an incognito (sic) window, without logging in. Does the problem still occur?
In a non-incognito window: disable your scripts and DiscussionTools in preferences, then try again. Does the problem still occur?
Enable your scripts and DiscussionTools again and capture a performance profile (not the HAR file) and post a link.
I will tell you the results: Point 2: Loading pages like EEng's make browser visibly struggle upon rendering even when logged out. Just slightly less time than in my JS configuration. Impossible to say if editing is impacted because my editing environment in source is the 2017 wikitext editor and it's a small box when logged out. Also, I do feel the need for syntax highlighting to better see the, you know, syntax. My eyes get lost in the sea of monotone black text. Point 4: The files have like 50 MB each, so I'd need to make sure you will have to be able to download these. I tested this on just readingUser talk:Tryptofish (870 KB wikitext at the moment). The summary results I got were these:Painting 10,280 ms Scripting 4,300 ms Rendering 4,116 ms System 2,050 ms Loading 285 mswith all scripts but Convenient Discussions enabled; and I have a separate batch for Convenient Discussions enabled - which did eat a lot of resources but is also clearly superior to current talk design IMHO. The browser could not load the right-click menu without significant delay while all of this was happening. On Convenient Discussions disabled, LCP 2.56 s (needs improvement, <2.5 s for good), Cumulative Layout Shift (CLS) 0.91 (poor, <0.25 for needs improvement, <0.1 for good), Interaction to Next Paint (INP) 600 ms (poor, <500 ms for needs improvement, <200 ms for good)But all of that is besides the point. An editor does not have to disable the JavaScript tools they feel they need for editing just to accommodate for excessively long talk pages. You have it backwards. If WMF says the software option is good enough for choosing directly in my preferences without any caveats, I trust that the software is ready to be used out of the box. That's the default expectation of any new user, and it's how it always should be. The JS may be buggy, but that's not the issue of buggy JS, at least not on my side, because I can replicate all the same issues while logged out. And even then users are not expected to be debuggers or know how a certain piece of code may impact performance. Maybe if you get the template editor or the interface administrator bit. But that's not for the vast majority of users. I am used to the environment I edit in and it doesn't cause me much problems for 99.9% of my use cases. I don't have to change it because of the 0.1% of the times when I need, or hell, choose to land on long talk pages, that's ridiculous. Also, there's a brilliant public service announcement by the government of Wales on disability that illustrates my way of thinking - why don't you just raise the roof if you can? Or, in this case, why don't you make the pages uncluttered enough so that any user can answer? The roof job may be expensive but the uncluttering isn't asking for much. Szmenderowiecki (talk Ā· contribs) 14:00, 31 January 2026 (UTC)[reply]
@Szmenderowiecki Interesting, thank you. I can download files up to ~20tb in size.
It looks to me that the problem is not the amount of plain text (as I predicted). The problem is the amount of Document Object Model elements.
Every piece of a webpage, each paragraph, link, button, image, or heading, is a DOM element.
The issue is that talk pages contain many DOM elements: signatures, timestamps, indents, etc.
So if you want to limit something it should be the amount of DOM elements on a page, not the amount of text.
And the situation wouldn't be so bad if DiscussionTools didn't add so many DOM elements per comment. Even when you aren't logged in.
Would you be willing to share some data with a WMF nerd? I may be able to find someone who can further diagnose this problem, and work towards a fix.
It won't be automated archiving of all pages, but maybe drastically reducing the amount of DOM elements added by DiscussionTools.
@Quiddity (WMF): probably knows who to ask. @Quiddity we need someone who can check why long usertalkpages render very slowly for Szmenderowiecki. It is probably/possibly DiscussionTools related. Do you know someone who can look at a performance profile and diagnose the problem? Thanks, Polygnotus (talk) 15:24, 31 January 2026 (UTC)[reply]
DOMs are in large part generated by text you and other editors type. Too much DOMs is usually a problem of the page and not the user who tries to load the page. If the page is user-generated, then it becomes the responsibility of the user(s) who contribute to that page, and to maintainers of the engine rendering that page, to make sure the amount of DOMs does not impact user experience. The meaning of DOM is not also something we typically expect from a regular user to know about. They just expect the website to work. DiscussionTools were disabled because I use Convenient Discussions, which is incompatible. WMF can contact me directly for inquiries at any time. Szmenderowiecki (talk Ā· contribs) 15:55, 31 January 2026 (UTC)[reply]
@SzmenderowieckiDOMs are in large part generated by text you and other editors type. DiscussionTools adds a whole bunch of DOM elements per comment. About ~8. If you want to we can make a test page that contains the same DOM elements but no text and you'll see it load slowly on your computer.
It is the responsibility of the WMF to deal with performance problems. Quiddity has over 2 decades experience on Wikipedia and started working at the WMF in 2013. They'll know who to ask.
DiscussionTools were disabled because I use Convenient Discussions, which is incompatible. Unfortunately DiscussionTools still adds those DOM elements to the page, even if you have it disabled and even if you are not logged in. Polygnotus (talk) 16:02, 31 January 2026 (UTC)[reply]
Irony above: "This page is too big. Excessive page size can cause accessibility problems for some editors. Please temporarily speed up the page archiving rate or split large discussions to separate subpages" ~2026-68406-1 (talk) 15:19, 31 January 2026 (UTC)[reply]
I have a 4Mhz (That's megahertz, not gigahertz) Z80 running CP/M and Fusix that communicates at 9600 baud. It can display and edit text-based discussions of any length on USENET or BBSs lightning fast -- no need to limit discussion size. If computers that are thousands of times faster than that are struggling, the obvious answer is to talk to the WMF and ask them to look at what they are adding to the text. --Guy Macon (talk) 17:38, 31 January 2026 (UTC)[reply]
I mean, any website would load well, whatever its volume, if it looked like The Motherfucking Website. It could probably run on a potato - but that's not really the point. In 2026 I'd expect at least this or this or this or this. I'm not saying there isn't a room for code improvement (although I don't know if it's true) but if the suggestion is that I have to disable certain in-built features just to be able to view/edit large pages, that person also has it backwards. Szmenderowiecki (talk Ā· contribs) 21:24, 31 January 2026 (UTC)[reply]
I played around with document.querySelectorAll('*').length and that first assumption is incorrect. Reducing all talk pages to 10 bytes max does fix the problem so the second one is hard to disprove. Polygnotus (talk) 20:21, 31 January 2026 (UTC)[reply]
Polygnotus what's your plan if WMF says that everything is all right with the software or if they do not answer back your ping (presumably because they don't think that your suggestion of simplifying MediaWiki output is not worth the effort))? Szmenderowiecki (talk Ā· contribs) 10:08, 1 February 2026 (UTC)[reply]
@Szmenderowiecki There are people who work at the WMF whose entire job it is to ensure that Wikipedia works properly on as many devices and in as many situations as possible. Quiddity works or has worked in the relevant team.
Help them help you, this is your best shot. There are people who have been tracking such stats for years and are interested in situations where the user experience is bad, so they know what to do and not do.
Quiddity is usually quite busy so we can leave a message on their talkpage in a week or so , if necessary. If you are polite and constructive they will help you. They may ask you some follow-up questions or do some tests so they can understand your experience better. Polygnotus (talk) 12:48, 1 February 2026 (UTC)[reply]
This doesn't really answer my question. Sorry if I'm not clear, so I'll rephrase it. While I disagree with their opinion, some users say that WMF alone is responsible for this, not users (my opinion is that it's a joint responsibility). Suppose that WMF/MediaWiki says any of the following:
Our software works just fine, no bugs impacting performance detected, anything else?
We fixed bugs that give a boost of 1.3% in loading time, but that's about all you will get.
This is core functionality that we are not ready/willing to disable.
We are introducing something new that will increase JS load, so no scaling back (given that webpages get more bulky over time and old devices, including, hopefully, mine as well someday, get changed - not a stupid thing to expect). We are not introducing any "lite" version of MediaWiki with just the bare minimum of DOM elements necessary for MediaWiki functioning and images linked instead of actually loaded. There will be no toggles.
I agree with Szmenderowiecki that just because there's a technical limit to a page that our servers can handle doesn't mean that any individual page ought to push towards it because of UX issues. (They may even issue a recommendation in their user guides to the effect that a page is not supposed to be over X KB wikitext unless necessary)
In other words, suppose WMF/MediaWiki says it's actually not their problem, it's the problem of the community, because there's nothing/not much to fix on the software side (regardless of whether they tell the truth, because you are not going to get anything (more)). What happens next?I will reiterate that if @Quiddity (WMF): or any other person who they believe will be competent to look into this issue wants to get feedback from me, they can ask all relevant questions and get relevant test results. Here, by email or otherwise. Szmenderowiecki (talk Ā· contribs) 13:16, 1 February 2026 (UTC)[reply]
@Szmenderowiecki That is a very hypothetical hypothetical. They own the servers and they sign the contracts and they have the money.
So in theory they could decide to stop this whole Wikipedia thing and start a VIP dog walking business in Lithuania instead. There is nothing you or I could do to stop them.
Of course its a joint responsibility; I could easily install some Javascript shitcoin miner that will tank performance.
In reality at least some of the people who work at the WMF are nice, hardworking people who share our goal. That doesn't mean I agree with every decision ever. Quiddity was a Wikipedian for years before he started working at the WMF.
Since they share our goal they want Wikipedia to work well for everyone, on any device. That means they will at least try to investigate the situation.
Will you be happy/agree with the result of the investigation? Will there be a quick fix that solves the problem in a week? I do not know, but if we don't give them the information they need we can't complain about performance.
If they say "WONTFIX" then at least we know where we stand. I can look at your pc (if you let me), but not their servers. The WMF can see exactly what is happening on both ends if you let them. So they are in the position to fix this.
I am pretty certain they will at least look at the problem. I can't promise you'll be happy with what they do with that information because they don't work for me. They are independent beings with free will. And they are your best bet to fix this problem once and for all. Polygnotus (talk) 14:04, 1 February 2026 (UTC)[reply]
Listen, if MediaWiki suddenly runs 3x faster and the load time is no longer a nightmare, I think anyone will be ecstatic. I would still argue the switch is necessary on other grounds - for example, because large pages, even if they load OK, are hard to navigate. But at least the barrier to discussion will be not as severe. So yeah, I wait for instructions from MediaWiki/WMF team. Szmenderowiecki (talk Ā· contribs) 14:11, 1 February 2026 (UTC)[reply]
(reply-to @07:56, 31 Jan) The performance report (parser profiling data linked at T416247) on loading the long user talk page you most complained about, shows a CPU time of 5.977 and real time of 6.714 seconds. This is only half again over the limit of 4 s you list as acceptable performance. If that is the actual load time for the worst Talk page at Wikipedia, then I'd say we were doing pretty darn well! I believe you wen you say that it is taking much longer than that for you to load the page on your hardware/software configuration, even if it takes much less time for others who have tried it on various setups, including ancient ones. Various conjectures have been raised about why that is, and the phab ticket will hopefully shed some light on that and lead to improvements for everyone. But making a proposal to limit Talk page size based on a misdiagnosis of a problem you are seeing and others do not, and then adding a draconian archiving proposal on top of it to be imposed on everyone based on the original misdiagnosis seems to be compounding error upon error, and not a valid proposal. I suggest we wait until we understand why you are getting the delay you are. And thanks for agreeing to provide input to the investigation tracked at the Phab ticket. Mathglot (talk) 03:55, 3 February 2026 (UTC)[reply]
There is irony and confusion. Why do we need more "rules"? Maybe this is putting the proverbial cart before the horse in some or most cases. Read #7- "Require pages that will likely routinely fall afoul of the maximum size rule to introduce a short archiving interval. Who has encountered pushback for achieving long talk pages? It seems any editor who finds a long discussion page (article talk) can archive older discussions.
At best, this is a terrible idea. At worst, it might be insane. It is too broad. Editors should not run out and buy a cart, then walk around looking for a horse. I would think suggestions or a number by consensus on page size limits would be found at Wikipedia talk: User pages. Help:Talk pages#Archiving states, On talk pages that generate significant amounts of discussion, old discussions are often archived to keep the size of the talk page at a manageable level. It states this can be done manually or with the help of a bot, but no suggested size. Although there is no link to the specific bot for "help", there is the "Main page: Help:Archiving a talk page". (TALKSIZE) gives some rationale, and Wikipedia:Talk page guidelines#User talk pages (maybe in the "Personal talk page cleanup" section) might be a good place to have some information on page size? It seems this may be important for new users or editors who would like some teeth and a place to point to. It is sort of a sad idea to attempt to teach someone to swim by just tossing them into the water. I think we should steer clear of user talk pages. -- Otr500 (talk) 01:10, 1 February 2026 (UTC)[reply]
A lot to unpack here:We don't know what the specs of that device that loaded the page for 30 seconds were, and what software they use.
We don't know if that device is one of the "ancient" devices that the user uses for browsing the web (what is "ancient"?). What they said does not exclude the possibility that they tested it on an iPhone 16 Pro or some modern PC for $2000+. We don't know what the "other pages" are.
I'm the user in question: that particular test was with an obsolete Android phone from circa 10 years ago. I tried it today with a 2015-model Raspberry PI 2 that I bought in 2016 for about $30 (now past end-of-life, has been sitting in a non-climate controlled junk drawer for years) and was also able to successfully load the page and open the editor (first load on that machine took about 10 minutes, but subsequent loads took ~30 seconds, indicating that the slow first load was due to media loading/caching, not byte size as targeted by this proposal). I don't claim to understand your computer setup better than you do, but I'm just saying that you seem to have far more powerful hardware than I do, on a better internet connection, yet you seem to be getting worse results. -- LWGtalk(VOPOV)02:22, 1 February 2026 (UTC)[reply]
OK, so that makes sense now. I mean, yes, obviously a Raspberry Pi will be less powerful than my computer. But contrary to what you say, my computer is not so bad as to be loading User talk:EEng for 10 minutes. It takes about 30-35 seconds on the first load (so no cache yet available) with browser freezing in the meantime or extreme difficulty to navigate any other part of the browser or the already rendered part of the page. With cache, this decreases to something like 15 seconds. It still is unacceptable behaviour. Say what you will about Google but they know how to code shit and know about reasonable expectations of performance, and also know a bit about UX/UI as well. Szmenderowiecki (talk Ā· contribs) 09:18, 1 February 2026 (UTC)[reply]
It still is unacceptable behaviour. Ok, so it sounds like your experience is pretty similar to what I get on my primary devices. It seems like the core point of contention here is: should Wikipedia users be obligated to maintain their talk pages to provide a Google-level industry standard UI/UX experience to all conceivable hardware/browser configurations? to which the answer of the community appears to be matching recent North American weather with a resounding no. -- LWGtalk(VOPOV)16:37, 1 February 2026 (UTC)[reply]
You are asking the question no one was actually asking. The good/needs improvement/poor score is a score that any website can get and these score are relevant for any website. It is not guidance for Google-owned sites only, it is guidance for all web sites. So no, Google-level UI/UX experience is something we probably should strive towards but this was NOT proposed as a requirement. Szmenderowiecki (talk Ā· contribs) 16:48, 1 February 2026 (UTC)[reply]
Sorry for being unclear, by "Google-level" I didn't mean to imply only Google owned sites, just the best practices they advocate. Which is a fine question to ask, but the community seems to be comfortable with falling a few seconds short of that ideal. -- LWGtalk(VOPOV)18:57, 1 February 2026 (UTC)[reply]
Also the top 99 contains only 19 users that are active (defined as having edited in the past 12 months) and not blocked, 2 indeffed users and 78 users who have not edited in the past 12 months. There is no reason to edit the talkpages of inactive and indeffed users. Polygnotus (talk) 02:35, 1 February 2026 (UTC)[reply]
Continue, close, or what
This discussion was opened two days ago (14:29, 29 January) so why does it already feel like a month? The section sizes template (which I don't trust for word count) tallies the discussion at 129,627 bytes and 606 prose words. My text editor (which I do trust, but which counts hidden text and sigs as words) tallies it as 130,065 bytes and 21,662 words. There is a do-not-archive-until template at the top configured for 5 March. If the discussion keeps going at this rate until 5 March, it will be approximately 1.8 million bytes and over 300,000 words.[b]
Looks like it's WP:SNOWing to me. The proposal seems too flawed to get much support, and the discussion seems to be mostly people sniping at each other or re-arguing whether slow old devices are actually slow and old rather than trying to work out something better. We can leave it a while longer if people want to see if it turns around, but I'd be surprised if it runs all the way until March. Anomieā03:59, 1 February 2026 (UTC)[reply]
I really don't like closing down discussions after two days. I don't want to feel like I have to check Wikipedia every day just so I don't miss some discussion that gets opened and closed while I am spending a weekend away from my computer. --Guy Macon (talk) 05:07, 1 February 2026 (UTC)[reply]
Well, lemme see. I like the close-it-yesterday aspect of A, but I hardly see the point of requesting that someone waste their time divining a consensus. I think nothing good can come of B, and I find the claims that productive discussion is still happening downright ridiculous, although I enjoy the humor of SuperPianoMan's idea. Perhaps we should just leave it open forever. --Tryptofish (talk) 19:42, 1 February 2026 (UTC)[reply]
I completely agree with this. Could the closing summary have been better? Yes. Did reverting the closure benefit the project in any way? No. Thryduulf (talk) 21:19, 2 February 2026 (UTC)[reply]
Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions ā see Help:Archiving a talk page. Apart from the exception described in Ā§ User talk pages, discussions should be archived, not blanked.
Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions ā see Help:Archiving a talk page. Apart from the exception described in Ā§ User talk pages, discussions should be archived, not blanked. Any person can archive any inactive (2+ weeks without new messages) threads on any talk page; reverting these archivals is disruptive unless there's a valid reason to do so.
2 weeks may be a rather tight cutoff for a lot of folks here. I mean, I don't care if my page gets a drive-by archiving, and I'd be even grateful to some extent, but it seems that others will be pissed off big time. I think it's a month at a minimum, and probably preferably 3.
does this concern user talk pages? If so:
what to do with users who insist that their talk page, or specific (list of) thread(s), are not be touched, even if such threads heavily tax your browser?
if the user has autoarchiving deployed, the archiving presumably must conform to the preferred choice of archiving by the user, correct? So numbered archives are continued, new monthly/yearly archives may be created, OK. What to do with theoretical topic-based archives?
what if the user says: I only want discussions to be blanked, I don't want no archive box or any fancy bots? Because after all the clause at Wikipedia:Talk page guidelines#Personal talk page cleanup that The length of user talk pages, and the need for archiving, is left up to each editor's own discretion. is unchanged by this proposal. They insist that they need no archiving and that any old thread be removed. But this proposal does not allow drive-by removal of threads from user talk pages, only archiving. Welcome to ANI I guess?
how do you address some editors' complaints that empty talk pages are uninviting. It's not a hill I'm willing to die on, but I have a mild preference for non-empty pages if possible. And there are folks who seem to care about this a lot, at least if judged by the linked TPG discussion.
"does this concern user talk pages?" - "any talk page" = "any page intended for communication between editors" so yes. "what to do with users who insist that their talk page, or specific (list of) thread(s), are not be touched, even if such threads heavily tax your browser?" - such behavior is covered by "reverting these archivals is disruptive unless there's a valid reason to do so" and wp:own. "if the user has autoarchiving deployed, the archiving presumably must conform to the preferred choice of archiving by the user, correct?" - I think pages with auto-archiving can be excluded. "what if the user says: I only want discussions to be blanked, I don't want no archive box or any fancy bots?" - they should be blanked, then, not archived. "how do you address some editors' complaints that empty talk pages are uninviting" - can they explain why they are uninviting? sapphaline (talk) 10:45, 1 February 2026 (UTC)[reply]
So something like this:
Current text
New text
Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions ā see Help:Archiving a talk page. Apart from the exception described in Ā§ User talk pages, discussions should be archived, not blanked.
Large talk pages are difficult to read and load slowly over slow connections. As a rule of thumb, archive closed discussions when a talk page has numerous resolved or stale discussions ā see Help:Archiving a talk page. Apart from the exception described in Ā§ User talk pages, discussions should be archived, not blanked. Any person can archive or blank any inactive (3+ months without new messages) threads on any talk page, unless there's auto-archiving with a reasonable archiving period set up; reverting these archivals is disruptive unless there's a valid reason to do so.
This goes in a much better direction and makes sense. I applaud your effort. The other two things that may be litigated are:
what is a "reasonable" archiving period? "Reasonable" is a very vague word, and if we take real life, Americans with Disabilities Act lawsuits about "reasonable accommodations" is something of a cottage industry, judging by number of Supreme Court cases listed in the article. Because there are a couple of ways to define it:
"It keeps the page below a certain limit" (define the limit)
There is a maximum thread count so that users don't get lost in the ton of old threads nobody cares about (again, define the limit)
It keeps the page from substantially impacting user experience on their browser (on Chrome-based browsers, this could be the Inspect tool performance indicators). Judging by how the discussion is going, the next question is likely going to be "what device are you using? specs please", "what scripts you are running?" and the addition that "it works fine for me" or "it's not that big an inconvenience to complain about, I can load the page in X seconds".
some other criterion I can't think of right now?
Any person can archive or blank conflicts with discussions should be archived, not blanked. I get the point. My proposal would be: Discussions should be archived, not blanked. Any person can archive any inactive (3+ months without new messages) threads on any talk page, unless there's auto-archiving with a reasonable (?) archiving period set up. On user talk pages, users may request that discussions be blanked instead of archiving - respect their wish. Reverting these actions is disruptive unless there's a valid reason to do so.
Oppose Editors should please mind their own business. Here's a fresh example. I get several regular newsletters posted to my talk page and I usually blank older ones so that only the latest appears. It would be better if the newsletters did this automatically but so it goes. Anyway, after recently clearing a batch of these, another editor restored them. An admin then turned up to revert their action because it appears that this user has a developing tendency to disrupt. The problem is that Wikipedia is the encyclopedia that anyone can edit and so our editors have a wide range of (in)competence. As they cannot be relied on to agree on such matters or have the necessary skills and understanding, they should not be encouraged to mess with other users' personal workspace. The Wikimedia software ought to have a foolproof interface maintained by its professional staff and, if there are technical problems with it, there ought to be a properly professional system for reporting and resolving them.Andrewš(talk) 13:50, 1 February 2026 (UTC)[reply]
with other users' personal workspace The problem with arguments like these is that I don't think such thing exists on Wikipedia, at least if we consider WP:OWN (No one "owns" content (including articles or any page at Wikipedia and Wikipedia offers wide latitude to users to manage their user space as they see fit. Nevertheless, they are not personal homepages, and are not owned by the user. They are still part of Wikipedia and must serve its primary purposes; in particular, user talk pages make communication and collaboration among editors easier. These functions must not be hampered by ownership behavior.) A better descriptor would be "a communal workspace assigned to a user for issues relating to a user, with customarily large latitude at self-management" Szmenderowiecki (talk Ā· contribs) 14:21, 1 February 2026 (UTC)[reply]
Oppose - There is no god-given right to talk to each and every other user on this website. Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user. Can't post an ANI notice on their page? Fine, then they don't get an ANI notice on their page. That's their problem. The notion of limiting all 250,000+ editors to some stupidly arbitrary and onerous rules, or letting busy-bodies mess with other people's talk pages, just because some editors don't want to wait for some talk pages to load, is ridiculous. Editors should not try to be so controlling of other editors. Levivich (talk) 14:28, 1 February 2026 (UTC)[reply]
"Can't load their user talk page? Don't want to wait 30 seconds? Then don't talk to that user" - Wikipedia isn't a social media website; you can't opt out of communication in a collaborative project. sapphaline (talk) 14:39, 1 February 2026 (UTC)[reply]
Yes. And template collaboration happens on template talk pages. And project wide collaboration happens on Wikipedia space talk pages. You don't need to talk to people on their user talk pages in order to collaborate with them. Levivich (talk) 14:46, 1 February 2026 (UTC)[reply]
Yes conduct issues exist. You don't need user talk pages to resolve them. We have conduct noticeboards. If you didn't get a chance to discuss conduct issues with a user because their talk page was too long, that's too bad for them. It doesn't mean everybody else needs to follow new rules. Levivich (talk) 16:13, 1 February 2026 (UTC)[reply]
The conduct boards have a giant notice saying that you must leave a message on the personās talk page and that a ping is not sufficient, so I donāt think that would be acceptable. ExtantRotations (talk) 23:35, 2 February 2026 (UTC)[reply]
From WP:USER: User pages are for communication and collaboration. ... However, pages in user space belong to the wider community. They are not a personal homepage, and do not belong to the user. They are part of Wikipedia, and exist to make collaboration among editors easier. From WP:OWNTALK: User talk pages must serve their primary purpose, which is to make communication and collaboration among editors easier.Szmenderowiecki (talk Ā· contribs) 14:45, 1 February 2026 (UTC)[reply]
1) you're bludgeoning. You've posted these quotes already in this discussion. 2) you're not making any point here with these quotes. Levivich (talk) 14:46, 1 February 2026 (UTC)[reply]
No, I'm rebutting a point which is obviously wrong according to current policy. Policy says this is the literal purpose of these pages. You may want to use pages not according to their intended purpose but that's your personal preference. I'm going to use these pages according to what they are for and which use policy explicitly endorses. And I should not be punished for asking that these pages be used for the purpose specifically outlined in the policy. I also don't believe that any argument to the effect of "let's allow users to force discussions in non-obvious forums because they don't want to do the housekeeping in the places where such discussion is intended to take place" complies within the general intent of Wikipedia policies and guidelines to promote discussion. Szmenderowiecki (talk Ā· contribs) 14:53, 1 February 2026 (UTC)[reply]
None of our policies and guidelines say Every user talk page must load within a time frame acceptable to User:Szmenderowiecki. I checked EEng's user talk page (the longest on the website) on pingdom and it said 11 seconds load time. If that's too slow for you, too bad. It doesn't mean we need to have everybody else in the website limit their page sizes. Levivich (talk) 16:11, 1 February 2026 (UTC)[reply]
Another problem with this proposal is that sometimes threads "2+ weeks without new messages" should still remain on a talk page. Sometimes returning old threads from the archives is exactly the right thing to do. To require those to be archived, or to prevent them from being un-archived, mass collaboration harder, not easier. Rarely have I seen "solution in search of a problem" as clear as this. Levivich (talk) 14:44, 1 February 2026 (UTC)[reply]
There is no god-given right for any editors to have their user talk page be organized or contain any content that they wish it does. User talk pages exist for a purpose - to facilitate communication. Katzrockso (talk) 20:00, 2 February 2026 (UTC)[reply]
Oppose all per most people above. There should be (and indeed are) already guidelines about talk page size, but they should remain no more than guidelines because there are far too many variables for a hard and fast one-size-fits-all rule to be useful, even if one were desirable (per most people above). If you need to post on someone's talk page to notify them about something then state that, with a ping, in whichever discussion you want to notify them about. Either they will respond to the ping or someone who can post on their talk page will leave a message on your behalf. Thryduulf (talk) 14:38, 1 February 2026 (UTC)[reply]
Oppose all, with no small amount of annoyance. Seriously, if someone comes to my talk page and wants to blank it, that's OK, but if I revert even part of that, I'm violating policy? Now, I'm quite tempted to blank this VPP discussion, and would love it if I were empowered to do whatever pops into my mind, with nobody allowed to object (woo-hoo, I wanna be an autocrat!), but no, just no. --Tryptofish (talk) 19:37, 1 February 2026 (UTC)[reply]
Oppose this and all future attempts to give random trolls power over what I can post on my talk pages:
(I have no problem with anyone bringing up any problems they have with my talk page at ANI and asking an admin to deal with them. That's why they get paid the big bucks.)[CitationNeeded]
If your 386SX running Internet Explorer on Windows 3.0 doesn't allow you to post a required ANI notice just say that in your ANI post -- someone will notify me.
Nobody forced you to read my talk page. Unless, of course, you are strapped to a chair with your eyelids taped open in front of a monitor with a Wikipedia feed and with The Wikipedia Song blasting in the background.
If you are strapped to a chair, etc., then let me address this message to your captors: First of all, keep up the good work. Secondly, please take away their keyboard. --Guy Macon (talk) 19:44, 1 February 2026 (UTC)[reply]
Per WP:RFC#Reasons and ways to end RfCs, there are five ways an Rfc may end. One way, is a consensus among participants to end it (#2 in the list). However, that requires discussion and time, and given the size of this discussion already and the number of participants, that may be a significant effort in itself. However, there is a much quicker and easier path. The originator may decide to withdraw the Rfc unilaterally (per #1) if the outcome seems clear early. Normally, this would be carried out by the OP removing the {{Rfc}} tag at the top, however, this Rfc has no such tag.
So that we don't become bogged down in bureaucracy, I think I can speak for most participants here that a clear statement from the OP, such as, "I withdraw this Rfc because reason" would be sufficient to meet the requirements of method #1. Szmenderowiecki, you are in a unique position to be able to end the Rfc now. Would you be willing to do so? You are, of course, under no obligation whatever, and you don't even need to respond to this if you don't wish to. Cheers, Mathglot (talk) 23:00, 2 February 2026 (UTC)[reply]
Concerns around COI Edit Request system
Something I have seen often is professional public relations firm reps hinting or requesting they'd like their requests worked on by certain editors much like people specifying certain servers at restaurants based on past experience. I believe something that encourages randomized matching would benefit with protecting the integrity of neutrality. The concern I am seeing with the current system is serious potential for the formation of premediated "buddy system" planted by resourced public relations firms. Algorithm based random matching of requester and volunteer responder would prevent such collusion. Graywalls (talk) 18:26, 2 February 2026 (UTC)[reply]
I was unaware this wasn't already protocol. If not, this layer of protection in terms of neutrality ie WP:5P2 seems like an obvious improvement. DN (talk) 18:39, 2 February 2026 (UTC)[reply]
As an experienced Wikipedia editor who also submits COI edit requests from time to time (I have I think 3 of them open now) and has even answered a few of them, I'd have great concern about some sort of random-assignment basis. At this point, a request is going to be handled either by 1) someone who was already watching the article and saw it get posted, or 2) someone who chooses an article from the list. While 1) won't be changing under your request, changing 2 seems like it would have some problematic fall-out. If I'm looking at the COI edit request list, I'm not picking the first one off the list, I'm looking for something that I'm likely to understand the issues, so I might be more confident in my ability to handle a biographical edit request than a medical one. Removing my choice from that both discourages me from doing such edits at all (part of being a volunteer here is that i get to choose what I do) and is likely to assign me one on which I don't feel competent. Having already faced some competency issues with the people who choose to handle such things, I think we should be wary of exacerbating that. Plus, anything that discourages editors from handling the request backlog will only increase that already-sizable backlog, increase the lag in reasonable edits being added, and thus encourage folks to ignore COI concerns. And unless you eliminate the possibility of option 1, you'll still have a fair chance of bias in the editing. -- Nat Gertler (talk) 18:50, 2 February 2026 (UTC)[reply]
I don't think there's anything untoward about that. I've been asked before and I politely decline and say that there's a queue and someone will get to it. Unless you have evidence that reviewers are not properly applying PAGs, I don't see a need for any changes. voorts (talk/contributions) 18:51, 2 February 2026 (UTC)[reply]
You will probably have my support if you tell "professional public relations firm reps" where to stick their COIs, but I haven't seen any evidence of a problem with the current system. Phil Bridger (talk) 21:30, 2 February 2026 (UTC)[reply]
If I were a notable person who had no clue about how Wikipedia worked but noticed obvious errors in an article about me, I'd probably hire someone and want them to do it properly. There's no reason to be hostile towards people who are doing their job within the rules that have been set for them. voorts (talk/contributions) 21:37, 2 February 2026 (UTC)[reply]
Without naming specifics, I can say public relations editing gets hairy at times. What does "within rules" mean? If a wealthy 65 year old man gets into a relationship with their granddaughter's 18 year old friend. In the US, government law considers such to be consensual relationship between consenting adults. While, legal, it is considered culturally unacceptable in most circles. A lot of strongly discouraged Reputation Management and PR edits that are technically within Wiki rules fall into that territory. Even practices that are considered acceptable in marketing and communications profession may not be on Wikipedia. Graywalls (talk) 00:51, 3 February 2026 (UTC)[reply]
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:
What are your overall reactions to this exploration and the research behind it?
Are there risks or concerns you think we should be paying closer attention to?
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.
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!)
@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. novovtalkedits09: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."
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, [18] (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]
@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.
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
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).
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.
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.
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)[reply]
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)[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:
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.
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.
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, 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.
"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.
"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.
"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] [...]
^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. PMID14738502. S2CID15419778.
@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.[19] 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. Rjjiii (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:
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.
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.
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.
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.
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.
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)[reply]
@RutebegaSimilarly, 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)[reply]
@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)[reply]
@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!).
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.
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
Must include this string as is: no changes in spacing, no changes word order, no substitution of synonyms
Must not include this string
Nice to have: Must include a string matching this regex
Nice to have: Narrow the results of the previous string
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)[reply]
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)[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? Brandmeistertalk16:17, 19 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]
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]
@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)[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:
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). āCryptic15:28, 24 January 2026 (UTC)[reply]
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)[reply]
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. āāāLambiam10:44, 26 January 2026 (UTC)[reply]
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)[reply]
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 BushrangerOne ping only01:29, 25 January 2026 (UTC)[reply]
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)[reply]
@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):
@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:1pxsolid#edab00;color:#000;}
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 --><refname="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: --><refname="Miller"details="Page 48."/>
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)[reply]
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. Rjjiii (talk) 02:00, 26 January 2026 (UTC)[reply]
What fresh hell is this? The example article contains apparently valid references like <refname="Blumrƶder"details="{{Google Buch|BuchID=3iyv_4s6rY4C |Seite=74 |Linktext=S. 72 |KeinText=ja}}"/> Heaven help us all. ā Jonesey95 (talk) 02:38, 26 January 2026 (UTC)[reply]
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 (<refname="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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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.
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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). Rjjiii (talk) 02:29, 27 January 2026 (UTC)[reply]
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)[reply]
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? Rjjiii (talk) 15:18, 26 January 2026 (UTC)[reply]
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)[reply]
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:
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 <refname="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 (<gallerywidths="90"heights="90"caption="San Francisco">) or maps (<mapframewidth="90"height="90"text="San Francisco"/>) and is just as easy to use. Johannes Richter (WMDE) (talk) 16:24, 28 January 2026 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)?
@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)[reply]
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}}.
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)[reply]
Edits to watched article not appearing on watchlist
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)[reply]
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 ([20]) is now appearing in my watchlist. R Prazeres (talk) 18:52, 28 January 2026 (UTC)[reply]
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 errorsinstead 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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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".
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...)
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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.
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)[reply]
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)[reply]
@~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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. - WalterEgo18:36, 2 February 2026 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
@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)[reply]
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)[reply]
@Prototyperspectivewhy 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.
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)[reply]
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)[reply]
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 themthat'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)[reply]
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)[reply]
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).
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 answerfor. 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.
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)[reply]
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.[22]
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)[reply]
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)[reply]
Is there a way to download just the lead of all wikipedia articles?
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. [23]
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. [24]
Updates for technical contributors
There was no XML dump on 20 January. Additionally, from now on, dumps will be generated once per month only. [25]
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.
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.
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)[reply]
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)[reply]
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)[reply]
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)
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)[reply]
Hello everyone, I was told by the Wikimedia foundation email to direct my query here.
Recently I have seen an influx in what I call ādud-articlesā, by this I mean articles that people try to make about themselves, their company, their mother etc. and I believe that this wastes our usersā time, declining and reading these pages, so on the Teahouse I suggested a new system, a disclaimer on the account creation page, saying something along the lines of:
āIf you are coming to Wikipedia to write about yourself, a family member, business or influencer please reconsider and refrain from making such articlesā
Even if that was the deter only one person that would still be an improvement. I did get support for this idea on the Teahouse from other users on this issue.
I'm personally for the harsh wording. being soft about it seems to make the kind of editors that need this warning think they can be an exception to the rules. The amount of times I've seen these WP:NOTHERE types try to argue something isn't technically against the rules because we try to not speak in absolutes is laughable mgjertson (talk) (contribs) 20:28, 8 January 2026 (UTC)[reply]
Anything we say on the sign-up page should be policy-based and link to the policy. Imho a WP:LOCALCONSENSUS here is not strong enough for changing what every new user sees as "instructions" for signing up from now on. I think we could say that it is discouraged, but not that they cannot do it, unless we change policy first, to change 'discouraged' to 'must not' and arm it with some teeth with what kind of sanctions happen if they do so anyway. Mathglot (talk) 03:58, 6 January 2026 (UTC)[reply]
Perhaps something not as harsh, I believe the policy says that writing about yourself is discouraged, and is a COI, so perhaps it could say āPlease note, writing about yourself, your company or another close topic to you is discouraged and if you do decide to join to write a page on these please reveal your Conflict of Interestā
Not recommending sanctions at all; what I was trying to say, is that you ought not say a user must not do something on the sign-up page, unless the policy page supports that; the flip side is that if you want to say 'must not' here, then the policy page must be changed first. I wouldn't support that, just explaining what's dependent on what. Hope I am being clearer, but if not, I blame the wine. Mathglot (talk) 10:00, 6 January 2026 (UTC)[reply]
Just saying it's discouraged doesn't stop the kind of people it needs to. Regardless of whether or not it's technically possible, we need to state clearly that they can't do that as they don't have the needed experience to do it to the level needed mgjertson (talk) (contribs) 18:57, 26 January 2026 (UTC)[reply]
I would be opposed to adding any extraneous information or links to a sign-up page that are unrelated to signing up for an account. Once they are signed up, they are automatically assigned a mentor, and often (but not invariably) receive one of the welcome templates maintained by the Welcoming committee. A link to Help:Your first article is present in 23 different welcome templates, including the most popular template {{Welcome}}, which is present on the talk pages of over 600,000 users. Also, the sign-up page disappears after they are signed up, and they lose the link, whereas their User talk page remains, and they can consult the links anytime. Mathglot (talk) 02:49, 8 January 2026 (UTC)[reply]
At face value, this seems like a good idea. But as with any idea, there could be unintended consequences:
Thousands of new accounts are created every day. Most of those accounts never make an edit. Do we really need to show all these people this additional information? Would a scary warning message discourage users who never intended to edit promotionally at all?
Most accounts never engage in promotional editing. By showing everyone a message telling them not to do it, we may give them ideas that they previously didn't have.
If we imply that these people shouldn't create an account, will they simply make promotional edits without an account (from TAs) instead?
I mean in life people are told not to do crime, or ādo not stealā or āemployees onlyā signs, and most abide, it doesnāt discourage someone from living their life or going into a shop as they know they wonāt do what the signs tell them not to do. I donāt think we would give them ideas, because they would know it will be declined hence the warning, thirdly I do see your last point about TAs instead, but TAs canāt make pages I believe so that cures the issue.
Most don't "abide" because they read a sign that says "Don't steal"; they were never going to steal anyway. Vandals gonna vandalize, no matter what words you add (which they will skip). I question whether there is any point to a wording change at all, especially wording they will see once, and never again. Mathglot (talk) 22:22, 11 January 2026 (UTC)[reply]
I do so what you mean, but perhaps there would be users who simply donāt know that Wikipedia isnāt a sort of LinkedIN or Instagram and would stop when told, like people on the Teahouse who accept their mistakes and donāt continue with the page on themselves, a family member etc.
Has anyone called for any stats (easily done) to find out just how often such articles that people try to make about themselves, their company, their mother etc. actually arrive in the NPP feed or even asked the 800-strong NPP community? They are dealt with swiftly at CSD. There are dozens of other totally worse articles that creep in under the radar of the less experienced patrollers. Kudpung ąøąøøąøąøąø¶ą¹ąø (talk) 14:36, 11 January 2026 (UTC)[reply]
The initial proposal probably doesn't say what the OP intended. The wording of the initial proposal includes "yourself, a family member, business or influencer". It doesn't say "your business", and therefore it includes any business and any influencer ā including, e.g., Microsoft and MrBeast.
@Kudpung, I second your idea about getting more information. I sometimes wish for a list of research ideas (e.g., for grad students in search of ideas). I wonder what we would learn if someone contacted the last 50 companies for which articles were created, and said "I'm doing research and would love to know what it took to get your Wikipedia article and if you have any advice for other companies". How many would say "We hired ScammersRUs" or "We just had an intern write it"? How many would say they were unaware of it having been created? WhatamIdoing (talk) 22:54, 11 January 2026 (UTC)[reply]
You could also ask the approx. 200-strong (and growing) Wikipedia Mentor community. Anecdotally, I see more autobiographies and my-band/my-biz articles on new account User pages (not subpages) than I do appearing in Draft space (marked for submission or not). Besides welcoming new users, I also hang out at thhe WP:Teahouse and often see them there as well. Data is always a good idea, and if you want to measure something, draw up a null hypothesis and a proposal for an AāB test where half of new attempts get a create account page including the text you want to measure (A), and the other half (B) do not, and let them run it for a few months. Later, you can analyze the data and see what happened. Keep in mind that things may not go the way you want: one possible outcome (besides adherence to guidelines) is that A numbers go down, while B numbers stay the same. Then you'd have to argue whether that's a good thing, if A folks who went on to complete registration ended up adhering to the rules a bit better. Mathglot (talk) 00:06, 12 January 2026 (UTC)[reply]
I think that if someone thinks it's harmless fun to create an article about their pet rabbit (real example), they wouldn't have stopped to read a sign-on notice, just like many of us ignore the "terms and conditions" when shopping. If someone is determined for some reason to promote a person, place or whatever, they'll do it in any case. A sign-on notice wouldn't deter them. Also, in general, how much do we think of editors being in a contractual relationship with Wikipedia? If we do think of it that way then, yes, terms and conditions apply. If we think of it more as an informal personal relationship then it's more about assuming good faith, trusting and forgiving, but accepting we'll have to spend time ā maybe too much time? ā working on the relationship by debating the case for or against every silly or promotional article on a trivial subject. --Northernhenge (talk) 16:47, 14 January 2026 (UTC)[reply]
They never have let me use blink text on wiki, but we sometimes get to use big red text.
If you wanted to work on warnings for creating articles, then that should appear when you click the [Edit] button. It might be possible to put something into the software itself. Imagine something that triggers if the edit count is <50, and now you have to answer a few simple questions before it will let you proceed. WhatamIdoing (talk) 23:14, 15 January 2026 (UTC)[reply]
Realistically, non-trivial software development requires a budget allocation and then time to actually do the work. It's January now, so the best-case scenario would be to join the annual budget planning process (which is starting now), and to have a team assigned to begin work in July (beginning of the new fiscal year) and then maybe to have something to test next calendar year. But "years" is more likely. WhatamIdoing (talk) 22:38, 17 January 2026 (UTC)[reply]
@WhatamIdoing. This is the fundamental problem when WMF intervention is needed for a just few lines of code on something critically important but because it was a community idea and not their own, they find any excuse not to entertain it. They also appear to have a strong opinion that because they are paid for what they do, nobody among the tens of thousands of volunteers has any technical clue even though some of us have done MediaWiki installations or built extensions ourselves. This comes down to even throwing a simple switch on one of the default prefs on a MedWiki package. AFAIK, the registration page has jealously guarded WMF access only. Kudpung ąøąøøąøąøąø¶ą¹ąø (talk) 05:56, 18 January 2026 (UTC)[reply]
A user project is in the making to address precisely the registration page which by offering a few simple words of very short text in the nicest possible way, would channel new users to through a new route that at the same time would not only prevent the creation of nonsense articles, but also provide much better on-boarding and truly interactive help than the current development at the WMF which is in its 3rd (or fourth?) year with limited success. Kudpung ąøąøøąøąøąø¶ą¹ąø (talk) 22:22, 14 January 2026 (UTC)[reply]
Sounds interesting; can we please get a link to 'project is in the making'? Also, what is the the current development with limited success in its 3rd/4th year? Thanks, Mathglot (talk) 00:22, 15 January 2026 (UTC)[reply]
@KeyolTranslater. Saw your request at WT:NPR. The best place to go for stats is probably Wikipedia:Request a query. I would suggest taking a sample size of a recent month and asking for a breakdown of articles deleted under G1, G2, G3, G10, A1, A3, A7, A9, and A11. These are the WP:CSD criteria, broadly construed, that address your proposal. It's fair to assume that most CSDs are tagged at NPP. You may then have to parse them manually to fit your criteria, but it's something we all have to do when we want to back up our claims with data. It would also be an excellent exercise if you are thinking of embarking on a career as an NPPer. There are roughly 800 rights holders, less than 10% are truly active, and the backlog is in its worse crisis for years, a lot of help is needed. If you were to obtain those stats it would also be really useful on several nascent ideas. Kudpung ąøąøøąøąøąø¶ą¹ąø (talk) 22:13, 16 January 2026 (UTC)[reply]
@KeyolTranslater. @Mathglot. On the premise that G11 and A7 are the main reasons for the majority of deletions, these numbers now need to be looked at from the perspective of two audiences: 1. The creators, 2. The curators (i.e. NPP) and how any change in the wording of the interface might:
Discourage/Deter new users from creating something that is highly likely to be deleted
Provide some relief for the NPPers by reducing the overall number of new articles in the daily feed.
Unless I'm missing something, I donāt see any significant rises/falls in the numbers of deletions over the 3-year sample (G15 is a very new criterion), but what is important now is to see how these deletions correlate to a rise/fall in new article submissions over the sample period and decide if a change in wording would have sufficient impact on the new users and ultimately - which IMO is more important - reduce the workload at NPP.
For reasons I have not been entirely able to pinpoint, despite the strong number of NPP rights holders (now around 800) since the right was created in 2016, the NPP system has been reduced to pattern of backlog drives having become the rule rather than the exception, and why enough interest cannot be generated in patrolling new pages to keep a flat line backlog at a sustainable level. Perhaps the thread at Investigating the cause(s) of backlogs explains much of it and maybe Novem Linguae has some suggestions. Kudpung ąøąøøąøąøąø¶ą¹ąø (talk) 20:09, 17 January 2026 (UTC)[reply]
@KeyolTranslater. I don't think declined AfC submissions will skew the results much. It depends on what percentage of new articles in the sample period are received into AfC. There are two types of AfC: ones moved to draft at NPP because they have the potential to reach mainspace if more sources are added or if the text is cleaned up, and articles that are created immediately as drafts which are probably the most likely to be deleted. The latter are possibly quickly dealt with under A7 and G11, while both kinds can end up at G13 (abandoned drafts). If you can get them, it might be interesting see how many drafts get deleted at A7 and G11, but G13 is best left out of the equation as it would be hard work to parse them into different types. Kudpung ąøąøøąøąøąø¶ą¹ąø (talk) 18:20, 18 January 2026 (UTC)[reply]
I would sooner see a sign-up warning about not using your real name than about not signing up to edit in a promotional manner. But frankly, any sort of message like that would discourage people, and we desperately need new editors. Its easy to deal with promotional pages, and in the process teach those people about how Wikipedia really works. With luck, some of them will actually write decent articles or become editors. CaptainEekEdits Ho Cap'n!ā22:17, 22 January 2026 (UTC)[reply]
Opposed. I have to agree with CaptainEek. Having read and participated here, I am coming down formally as opposed to the whole idea of a sign up page disclaimer. Anything we say that might discourage a new editor from registering is a bad idea. I'd rather see ten new vandals and COI-only editors registering along with one good encylopedia-building candidate, than none of them. As part of my volunteer work as a mentor, I see those ten regularly (and I bet CaptainEek, as mentor #24, does too), and I don't want to lose the one good editor for the sake of making my life easier by not having to deal with some clueless or bad apples. (Also opposed to real name warning.) Willing to modify my position if new information is brought to light, but this is where I stand now. Mathglot (talk) 22:51, 22 January 2026 (UTC)[reply]
I think everyone here is on the same team: we are all working to improve the encyclopedia, and to acquire and retain good editors. Regardless what path is taken, thank you for bringing your concerns and your ideas here for discussion. Mathglot (talk) 19:29, 26 January 2026 (UTC)[reply]
I think the following conditions should be met if it is something local yet to be created on WP:
A) They have to be relatively popular within the sub-division of whatever they are from (e.g. Tottenham or Fulham in London is an example of the type of subdivision, or even Telford & Wrekin in Shropshire)
B) If A) does end up being the case, and it is local, GET THEIR PERMISSION!! I feel that if you can request it, whether via email or in person or something, it could help your case significantly, but you may still have it taken down if it isn't noteworthy enough.
C) If it is just some average bloke, don't bother unless they have some actual achievement within a local area, and no, something like being the millionth person to climb the Wrekin doesn't count as noteworthy, as an example
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
baby globe
to celebrate wikipedia's 25th anniversary, a toggleable "birthday mode" has been created. it consists of easter eggs involving baby globe, such as having it scroll a phone in the top right of an article while the reader scrolls down an article. more details can be found on the linked page. if the feature is enabled, by 26 january, administrators can configure the mode through community configuration; and the mode will be public from 16 february to 16 march (an administrator will have to turn on the feature on the day itself).
enabling the feature requires "a consensus from your community", so i have brought it here to ascertain the community consensus. (there was some previous discussion on Wikipedia:Village pump (miscellaneous)/Archive 86 Ā§ Easter eggs, but it was archived without further action.)
should english wikipedia enable the 25th anniversary birthday mode, and if so, should it be on by default?
option 1: enable birthday mode, and have it on by default
option 2: enable birthday mode, and have it off by default
option 3: do not enable birthday mode
voting (25th anniversary birthday mode)
option 1 > option 2, oppose option 3. i think it would be a shame if the largest wikipedia did not participate in the celebration. i'd also prefer it to be on by default, as people generally don't change default settings, but i'm fine either way. ltbdl (skirt) 19:19, 17 January 2026 (UTC)[reply]
Support option 1 > option 2, oppose option 3 per ltbdl. This is an excellent feature that our readers will hopefully enjoy. It also fits nicely with one of our goals in recent times, which has been to emphasize the human aspect of Wikipedia. Toadspike[Talk]20:41, 17 January 2026 (UTC)[reply]
Option 2 Per Thilio. Suggest that greater consideration be given to limits on the number of top-of-page distractions we allow. I also wouldn't mind a shorter period.--Wehwalt (talk) 21:10, 17 January 2026 (UTC)[reply]
Second choice is 3. I feel the case can be made that we're being very self indulgent in patting ourselves on the back in ways that do not benefit the reader. Wehwalt (talk) 15:17, 19 January 2026 (UTC)[reply]
Option 1 Agree with Chaotic Enby that this is contingent on having a readily available (and known--e.g., included in banner announcement of easter eggs) method to disable. ā rsjaffeš£ļø21:13, 17 January 2026 (UTC)[reply]
Option 1 let's have fun for once, 25 year anniversaries don't happen very often. Yes it's quirky, correct some people won't like it, but this is only temporary. Let's celebrate in style and get noticed for it. CNC (talk) 20:09, 18 January 2026 (UTC)[reply]
Option 3 unless we have a lot more information. I wouldn't like to see a confetti-throwing Wikimedia globe appear on the page for some disaster- or genocide-related page with massive viewer numbers. The linked Wikimedia page doesn't inform me sufficiently about what to expect. Fram (talk) 10:32, 19 January 2026 (UTC)[reply]
option 1, it's toggleable by the user and doesn't affect the actual contents of the page (thinking back to the grimace mcdonald's wiki incident) Jaidenstar (talk) 17:43, 19 January 2026 (UTC)[reply]
option 1. No one will notice it if it's not on by default. And Baby Globe is great. It would be a shame not to participate in the birthday celebrations. -- asilvering (talk) 04:27, 24 January 2026 (UTC)[reply]
Option 1 ā I was hesitating due to the concerns that Fram raised, but now that @CDekock-WMF has shared the table of different page queries and configurations, I feel reassured that a lot of thought has gone into context-aware presentation of the mascot. ClaudineChionh (she/her Ā· talk Ā· email Ā· global) 22:45, 19 January 2026 (UTC)[reply]
Option 1 - Like Fram, I had some concerns about showing a celebratory globe on pages for horrific actions, but I am confident in the solution provided by the Foundation for that. So, yeah, after 25 years I think we can celebrate for a bit. LightlySeared (talk) 12:21, 20 January 2026 (UTC)[reply]
Option 1 - per above.Option 2 - I'm unsure how this would affect printable versions and whatnot, so I would prefer if it was disabled by default. (It would make it more of an Easter egg as well, per ObserveOwl.) The Wikidata configuration shared above is useful. Also, it's been 25 years, so why not? Jude Halleytalk/contribs13:18, 21 January 2026 (UTC)[reply]
Option 2 Please, please don't put animated stuff on pages by default; it's distracting and makes it much harder for me to focus on the content that I am trying to read. Thanks. --David10244 (talk) 05:48, 22 January 2026 (UTC)[reply]
Option 2. I'd suggest send a notification to users on the website to indicate its now available, or an email, albeit some editors don't link their account to their email. Inpops (talk) 17:11, 28 January 2026 (UTC)[reply]
Option 2: Color and especially movement are distracting and annoying, and the described month-long persistence of the annoyance is beyond the pale. āā āā BarrelProof (talk) 01:38, 27 January 2026 (UTC)[reply]
Option 1: While I wouldn't mind Option 2, I personally would prefer Option 1, especially since the OG should have it defaulted. F1fan00 (talk) 09:44, 28 January 2026 (UTC)[reply]
Option 1 (strong option 1) - We can always use more reasons for the public to feel warm and fuzzy and Wikipedia, and this does exactly that. This is a serious project, but it's also a fun project, and written by volunteers. Letting people have a glimpse of that fun -- reminding people that this can be a silly place -- has value. Just look at the resonance of Depths of Wikipedia, for example. Do it, and deal with issues as they arise. I say this as someone who has been critical of our April Fools antics in the past. Unlike that (or rather, unlike the way that used to be), if you look at the page linked at the top, there are already provisions in place to consider context and set limits for e.g. the confetti globe. Deal with any issues as they come on a case-by-case basis (I'm sure people will let us know if something unintended happens). ā Rhododendritestalk \\ 17:13, 28 January 2026 (UTC)[reply]
Option 1 or Option 2. An opt-in process means that very, very few people will end up getting the celebration at all. We can always fine-tune after launching if there are issues, but my preference is to get it up-and-running first. ThadeusOfNazereth(he/him)Talk to Me!13:03, 30 January 2026 (UTC)[reply]
Looking at the documentation, it looks like it will be pretty accessible (pop-up) on mobile, while V22 desktop users will have it in their configuration panel ā not exactly hidden, but not the most accessible for new users unfamiliar with the interface.
Regarding distractions, we have several articles with GIFs near the top of the page. Ones you'd expect, like Chronophotography, but also ones you may not, like Swing bridge and Panenka. Those GIFs can't be stopped by the average reader ā at least, I wouldn't know how ā which is in stark contrast to the cute puzzle globe, which looks like it can be disabled with one or two well-advertised button presses. Toadspike[Talk]21:09, 18 January 2026 (UTC)[reply]
As a reader, the GIFs do distract me from the text. For me, the value they add by illustrating the concept better than a static image justifies the distraction, but it's silly to say there is no distraction. Toadspike[Talk]15:52, 23 January 2026 (UTC)[reply]
Comment. Some thoughts:
Like Fram, I am also concerned that cute (they are) easter eggs will show on serious articles.
If we want to enable the easter eggs by default, then we need to accept that they will show on serious articles or we need to filter which articles they show on. Aside from the scale needed for it, the second option also might go against the community sentiment that Wikipedia is not censored.
Do we know which extension this is linked to? If so, we could raise a patch/file a bug and/or read the code to figure out if there are safeguards against this. Sohom (talk) 11:43, 19 January 2026 (UTC)[reply]
Oh this is Extension:WP25EasterEggs, taking a look at the code it is extremely configurable! We can enable it for a specific set of pages, or enable it globally and not show it for a specific set of page and all of that is configurable through CommunityConfiguration (read through a on-wiki JSON file). Sohom (talk) 12:05, 19 January 2026 (UTC)[reply]
Good job finding it! My concern is that, if we enable it globally, we need to check most en.WP pages if they should be excluded.Excluding categories may help, but I remember an argument against actual policy proposals like inappropriate-image blurring that also apply here: categories are imprecise in a lot of ways (the first thing in my search about it is Thryduulf's 2024-11-06T11:57:00). If we will do categories regardless of that, you will still need to vet which categories are included or not. LightNightLights (talk ā¢ contribs) 12:24, 19 January 2026 (UTC)[reply]
Pretty much every pick for which pages will have it disabled or not will be extremely controversial, and more worryingly could be used as precedent for future "hiding" tools, so I don't think that's something we should go through. Going deeper than straightforward things like "have it enabled on the Main Page" and "have it enabled/disabled on X namespace" opens up a massive can of worms. Chaotic Enby (talk Ā· contribs) 12:37, 19 January 2026 (UTC)[reply]
This has nothing to do with NOTCENSORED though. We are not here to deliberately cause offence with unencyclopedic content either. Displaying these easter eggs or not doesn't change the contents of the encyclopedia. Fram (talk) 14:01, 19 January 2026 (UTC)[reply]
I doubt "deliberately" is the best way to put it. It doesn't change the contents directly, but does leave us with a list of "acceptable pages" and "controversial pages", which can absolutely be used as a precedent for making some "controversial" material less visible/prominent. Chaotic Enby (talk Ā· contribs) 14:03, 19 January 2026 (UTC)[reply]
Wouldn't like such a list either, which means this can go on the Main Page or perhaps on user pages but should stay out of the articles in general (with what we now know of what kind of easter eggs we may expect). Perhaps my opinion would change with more info, at the moment it feels too much like writing a blanco cheque. Fram (talk) 14:22, 19 January 2026 (UTC)[reply]
A reader choosing to look at a potentially offensive article does not change the fact that Wikipedia is 25 years old now and we are celebrating that. These are entirely unrelated. Toadspike[Talk]14:39, 19 January 2026 (UTC)[reply]
Not if you display them on the same page, in ways so far unknown. A reader looking in mid-March to our article "US invasion of Greenland" may well be completely unaware that Wikipedia was 25 years old a few months before and that the rightside image is displayed for that reason and not to celebrate the invasion. Fram (talk) 14:50, 19 January 2026 (UTC)[reply]
In my opinion, this is why we should make it clear (e.g. with a banner) that this easter egg is to celebrate Wikipedia's birthday. Incidentally, this also solves the "make it easy to turn off" problem. Chaotic Enby (talk Ā· contribs) 15:02, 19 January 2026 (UTC)[reply]
Your idea sounds good. Maybe we should have text below the globe mascot images in the lines of "Celebrating English Wikipedia's 25th birthday"? It does not suffer from banner blindness and will always appear alongside the cute images, but does not solve the turn-off problem. LightNightLights (talk ā¢ contribs) 15:27, 19 January 2026 (UTC)[reply]
That could work! Either that, or making the banner very obviously birthday-themed so readers don't have to actually read the words to understand the context behind it all. Or both! Chaotic Enby (talk Ā· contribs) 15:34, 19 January 2026 (UTC)[reply]
id say, put below the globe thing, put in the normal size, 'Wiki 25', then below in a smaller font, put '25 Years of the Free Encyclopedia', or something along those lines F1fan00 (talk) 10:03, 28 January 2026 (UTC)[reply]
Based on what is already implemented, tThere is going to be a relatively large toggle on the sidebar every page (similar to the dark mode one) that says "birthday mode" but yes, also CE's idea is not a bad idea. Sohom (talk) 15:14, 19 January 2026 (UTC)[reply]
Maybe the "Birthday mode" toggles should be shown above the old ones so that people will see a) most likely see the new ones first, and b) most likely see that something was added in the options menu. LightNightLights (talk ā¢ contribs) 15:33, 19 January 2026 (UTC)[reply]
Hello :) My name's Corli and I'm working on this project and want to share a bit more context on how we've tried to solve this very tricky problem of "which articles gets which version of Baby Globe?"
We also concluded that trying to make a "disable" list would be extremely difficult (if not impossible!) to do, especially because what we're building needs to work across all language Wikipedias. So we created a version of Baby Globe that appears "neutral". They don't do much, they stand around, blink and look cute. This version can then show up on pretty much any page and not imply anything particularly positive or negative.
By comparison, the versions that are overtly celebratory (like the confetti one) can be configured to show up on overtly celebratory things (people also turning 25 this year, all ācakesā). This is done using mostly Wikidata items, you can see a first version of this here, which we will be updating with all the versions of Baby Globe later this week.
The configuration setup allows Baby Globe to be configured by each opted in language edition to be blocked on specific pages defined in community configuration (eg. define specific pages where no instance of Baby Globe will appear, not even its default neutral state). So you can very easily override and adjust this default setup.
The longer story is that there are 14 different versions arranged along a spectrum of sorts from very neutral to outright celebratory. You can get a sense for them in the table, which this week we'll update with the actual gifs so you can properly see the vibe :) These can all be individually turned on / off and customised to appear or not appear on specific articles. CDekock-WMF (talk) 16:21, 19 January 2026 (UTC)[reply]
I want to explicitly mention that I think there is a sentiment among editors that Wikipedia is not censored outside of NOTCENSORED, so I avoided saying "NOTCENSORED" at my original comment.LightNightLights (talk ā¢ contribs) 14:19, 19 January 2026 (UTC)[reply]
Comment #2. Some more thoughts:
If we decide to hide it by default (option 2), I think a lot of people will not enable it. This may be bad because it would mean that we did not utilise someone's work to the fullest reasonable extent, but may also be good because we probably should not shove it in our readers' faces.
If it's hidden by default, then we might want to run "opt-in now!" messages, and that might be more annoying than just having it visible.
I don't find the "but what if someone's reading serious content?!" argument to be very compelling. AFAICT Google doesn't suppress the Google Doodle if you search for a "serious" subject. I've never seen anyone saying "I was searching for information on how to plan my aunt's funeral, and Google posted a celebratory logo. How dare they!" Have you? And if you haven't, why would you expect readers to accept Google's celebratory logo but not Wikipedia's? WhatamIdoing (talk) 02:26, 25 January 2026 (UTC)[reply]
If it's hidden by default, then we might want to run "opt-in now!" messages, and that might be more annoying than just having it visible. that's absolutely right. What if we configure a default display timer of five minutes? For example, the baby globe would appear on readersā screens for a maximum of five minutes and then automatically disappear... If a reader closes the browser session and later reopens it, the baby globe would be displayed again for five minutes before disappearing. CONFUSED SPIRIT(Thilio).Talk05:22, 25 January 2026 (UTC)[reply]
Question I assume this would not be available on classic vector? If so, that would be a shame, considering I've strongly preferred classic Vector's enumeration of a page's table of contents and am unwilling to temporarily switch to Vector 22 to experience the joy of birthday mode, but I understand. DrewieStewie (talk) 21:02, 26 January 2026 (UTC)[reply]
This is not the most pressing inquiry for resolving the technical implementation of this feature, but can someone explain to me why a baby was chosen as the mascot to celebrate the project having reached the milestone of 25 years--it seems peculiar to me, if not outright counter intuitive, given that, if you are going to anthropomorphize such an abstract condition, 25 would normally be an age that one might reasonable associate with coming into full adulthood? What am I missing here? If it's not obvious to me after having been with the project for roughly 2/3's of that period, I can't imagine it's any more intuitive for our average reader. Am I overthinking this--was it just an organic selection of the most obvious cutsy mascot that could be adapted from the movement logo? SnowRise let's rap00:27, 31 January 2026 (UTC)[reply]
It's not a baby it's a plushie, which doesn't denote age or lifespan. Despite it's anthropomorphic appearance, as is common with these toys, plushie's aren't the embodiments of humans so I'm not seeing the issue. If it were a greenland shark, at 25 years of age it would still be considered a juvinelle (and shark plushies are quite popular btw). So plushies can symbolically live for upto hundreds of years, thus 25 shouldn't be measured anthropocentrically, even if WP is indeed anthropocentric. CNC (talk) 09:19, 31 January 2026 (UTC)[reply]
Well, I never regarded it as an "issue" so much as a peculiar choice. But I've since found an interview with the artist of the original graphic which clarifies that the unnamed design came first, and people just started calling it "Baby Globe" organically after the fact. I still think this makes for a curious mascot to celebrate this particular threshold, but certainly a curiosity of a "meh" level of significance. SnowRise let's rap07:50, 1 February 2026 (UTC)[reply]
Support as proposer: WP:Close is an information page that well-documents current community practice with the level-of-detail one'd expect from a guideline, with the exception of the "Closing procedure" section mostly of uncontroversial technical details, but it's not unheard of for guideline pages to include such sections either (e.g. Wikipedia:Signatures#Dealing with unsigned comments). Despite the widespread practice of consensus being the counted supermajority when arguments are of equal weight, this determination is only documented in essays and this information page (If the discussion shows that some people think one policy is controlling, and some another, [...]). An experienced editor in a discussion I closed a few months ago pointed this out to me and thus argued my close should've said "no consensus" instead as a small number of participants !voted oppose. The increased visibility of this page as a guideline would reduce the amount of editors (including newcomers) who aren't caught up on our closing standards.It is my opinion that the practices documented in this information reflect the current community standard, and the situation I mentioned above marks a need for such practices to be included in guidelines. Aaron Liu (talk) 17:22, 26 January 2026 (UTC)[reply]
Support per Aaron Liu. I've long found this a useful guide and personally never had it questioned as only an info page, but I can see the issue of it not being an official guideline as an issue, especially given it's the guidelines that closers follow. It might be worth considering some other pages in this area for review and promoting; Wikipedia:Non-admin closure (widely accepted essay, referenced in hatnote at WP:INVOLVED as guidance on involvement for non-administrator actions - also not a guideline but quasi-advertised as such. Likewise we have Wikipedia:Requested moves/Closing instructions, as a subpage of RM no less, which again is nothing more than an essay, even if widely used as guidance. I think it might be time to start making the effort to categorise certain pages more accurately, reflecting their status quo as defacto guidelines. CNC (talk) 13:30, 30 January 2026 (UTC)[reply]
You're not wrong, "enforced BRD" is referenced in WP:STANDARDSET, whereas BRD is only an essay intended as advise. Given it describes an optional strategy rather than any fixed rules, the categorisation doesn't seem off to me at all. Realistically it's evolved into an infopage as documents the cycle in-depth, rather than pov-led like essays often are.
I'm aware not everything needs a tag, but if there are sets of best practices supported by consensus, then promoting to guideline satus is logical for sake of clarity. Five pillars is otherwise a higher-level summary page, so acts more like an infopage than policy or guidelines. There doesn't appear to any independently crafted policies or guidelines, only references to them. Thus, it's categorised correctly as a page that either isn't confirmed to have widespread consensus, or doesn't require it. CNC (talk) 16:48, 30 January 2026 (UTC)[reply]
Good suggestion, also the notes on that page that are linked need anchors, or ideally resolve the duplicate lists of restrictions. There is one at the base page and the other transcluded to subpages; one with useful links, notes, and a set of other restrictions; and the other without. Hopefully an arb can bring some sanity to that. CNC (talk) 20:19, 30 January 2026 (UTC)[reply]
No, I can't. The Enforced BRD sanction in my userspace is historical and part of the point of STANDARDSET is that it eliminated custom sanctions like the ones in my userspace. ~Awilley (talk)22:06, 1 February 2026 (UTC)[reply]
(Pedantic note: it didn't eliminate custom sanctions. It made them so only a rough consensus of uninvolved admin at AE could do them.) Best, Barkeep49 (talk) 03:08, 2 February 2026 (UTC)[reply]
Great. What's the procedure for getting the committee to stop linking to a page that says it is "one of many optional strategies" (emphasis in the original)? WhatamIdoing (talk) 06:19, 2 February 2026 (UTC)[reply]
I support better documenting the de facto approach to consensus. I do find this sentence weird: The desired standard is rough consensus, not perfect consensus. I understand itās the de facto approach, but should there be an effort to revise consensus, rather than having a separate guideline that sorta says, āwe didnāt mean that page, we mean this pageā? Dw31415 (talk) 01:09, 31 January 2026 (UTC)[reply]
AIUI our notion of Wikipedia:Rough consensus is derived from the Internet Engineering Task Force. "Rough consensus and running code" is the goal for their decision-making process. The first half means that it's unnecessary to have unanimity, to have agreement on the details, or to have a formal vote. In the case of decisions made under RFC7282, it literally means that support sounds louder than opposition. They are looking for an absence of significant opposition, rather than strong support. The second half means that the group should defer to the people doing the work instead of someone pontificating about theory. WhatamIdoing (talk) 01:51, 31 January 2026 (UTC)[reply]
I'm not sure why we should expect people to know the IETF's protocol.That said, I think WP:C already appropriately summarizes consensus as Consensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy. Detailed, further explanation is what WP:Close provides. Aaron Liu (talk) 02:26, 31 January 2026 (UTC)[reply]
Iām not sure about the best solution and donāt want to distract too much from the main question. I just think thereās an odd smell about this (as a guideline) saying we donāt use policy (consensus) we use an essay (rough consensus). If no one else sees a problem with it Iāll defer. Dw31415 (talk) 03:17, 31 January 2026 (UTC)[reply]
Mostly, I don't see why not make clear a series of practices are standard. Your assumption is correct but I don't see why that lessens the argument for clarity, and said editor is someone I usually wouldn't assume obstructionist motivations. Aaron Liu (talk) 21:14, 26 January 2026 (UTC)[reply]
Meta comment: A WP:PROPOSAL is supposed to be made on the talk page of the proposed guideline. I don't think we need to take any action right now, but if this discussion gets long (RFCs on Village pump pages frequently need to be WP:SPLIT to keep the overall page size under control), maybe it could be moved there instead of to a subpage. WhatamIdoing (talk) 20:25, 26 January 2026 (UTC)[reply]
I agree that there should be a guideline on closing discussions, but it might be worth fine-tuning it a bit and getting everything in one place first. Right now it's not as concise as it probably could be. Thebiguglyalien (talk) šø22:08, 26 January 2026 (UTC)[reply]
I've finally looked over both; I don't believe there is overlap, other than If the matter under discussion is not contentious and the consensus is obvious to the participants, then formal closure is neither necessary nor advisable. which I don't see a problem with. Aaron Liu (talk) 03:22, 28 January 2026 (UTC)[reply]
Hi Aaron, I boldly added a link to the RfC close template. Feel free to revert if it should get more review. I would like there were more consistency in using the RfC closure template or to have it deprecated. Dw31415 (talk) 14:34, 30 January 2026 (UTC)[reply]
This part of RFCEND strikes me as out of touch with current practice but maybe Iām looking at a controversial subset. Editors are expected to be able to evaluate and agree upon the results of most RfCs without outside assistance. I guess thatās not immediately relevant to this discussion. I support the proposal to make it a guideline. Dw31415 (talk) 03:33, 28 January 2026 (UTC)[reply]
I looked through a handful of consecutive RFCs from November-ish. About two-thirds got a closing statement. However, almost half of those didn't need a closing statement (e.g., Andrew Huberman, Advance UK, Scientology) because the responses were so lopsided. That said, sometimes editors want a closing statement for social/behavioral reasons rather than because they don't know what the result is. WhatamIdoing (talk) 06:00, 28 January 2026 (UTC)[reply]
It helps prevent the (factually incorrect) wikilawyering over "well that discussion was never closed so there's not a true consensus". Katzrockso (talk) 13:54, 30 January 2026 (UTC)[reply]
I don't think I've ever seen that particular claim before, but I'd expect that to be solved by educating the editor about Wikipedia's processes. If that happens a lot (more than a couple of newbies a year), then I'd like to have a few examples (drop some on my talk page? It's kind of off-topic for this discussion), then we should address that error somewhere. Maybe Wikipedia:Tendentious editing#Concerning discussions would be the place for that. WhatamIdoing (talk) 16:02, 30 January 2026 (UTC)[reply]
I'd like to open a wider conversation about the wider practice of including those winter storm names in articles. The storm names are called a "marketing ploy" in that storm article above, and so we should really have something stronger than a silent consensus to back up their inclusion (see background below).
Ideally, coming out of a discussion here we would have either an affirmative consensus of the status quo or a reversal of the TWC guidance. This could also instead act as a WP:RFCBEFORE if a wider discussion is needed.
The on-wiki guidance is at the WikiProject level with WP:TWC. The inclusion of the names within articles does not appear to have been recently tested at any level above a silent consensus and various small discussions on article talk pages. Specifically, TWC says that an "understood consensus" exists that "allow[s] mention of the TWC names within the articles, as long as said names are not part of the article title and that there is a "silent consensus for this method and process".
Meteorological agencies in some parts of the world assign names to winter storms, but in the United States, only hurricanes and tropical storms get official names from the National Weather Service. Since 2012, The Weather Channel has used its own list of names for storms, a move that has been criticized as a marketing ploy. It is calling this one Fern.
I am against using TWC names but they are (unfortunately) widely used in news sources. Since the names are used nationwide and not just locally, support status quo, which makes it clear that the names are unofficial. HurricaneZetaC16:17, 27 January 2026 (UTC)[reply]
Support status quo ante bellum. I see no reason to change how weāve been handling these with a small mention in the lead. As Zeta said, once you have the names being referenced by media outlets it becomes hard to ignore, and we should not leave it out, as some readers may find it helpful. Zeta made it pretty clear as well, and we should not move the article names to them. MarioProtIV (talk/contribs) 20:18, 27 January 2026 (UTC)[reply]
Support I honestly donāt see what the big deal is. There are many storms with unofficial names like Superstorm Sandy, Snowmageddon, The Beast, etc. Trying to take out one nickname/unofficial name is just a waste of time and honestly sounds stupid to me because itās just nitpicking for no reason, especially when numerous media outlets use them. ChessEric06:43, 29 January 2026 (UTC)[reply]
Overall I think that this should be treated as a navigation issue and similar to how we treat nicknames for people or organizations. We should include the names if readers might be looking for them (e.g., to make sure that they're reading about the storm that they want to read about). We should consider bolding the name if a redirect points there, under the same rules we would bold a nickname. The approach of explicitly labeling it an "unofficial" name sounds good to me. I think the quotation from The New York Times about a "marketing ploy" is unnecessary, but there's nothing inherently wrong with providing a brief quotation from a paywalled source. WhatamIdoing (talk) 16:11, 30 January 2026 (UTC)[reply]
Support trying to get rid of it because itās āa marketing ployā or whatever seems like WP:GREATWRONGS (or at least pretentiousness, as if a for-profit source is too good for Wikipedia), as does mentioning that the NYT considers it as such. As long as itās not the article title and explicitly stated to be unofficial itās completely fine. Dronebogus (talk) 01:31, 2 February 2026 (UTC)[reply]
I agree. In particular, when we tell the life-story of a historical figure, we tell it in chronological order, from birth to death. For historical figures it looks plain silly to list their life backwards. As one typical example, we list the ships commanded by Sir William Parker, 1st Baronet, of Shenstone in order from the first he commanded, to his last command. Since all our subjects will eventually become historical figures, and we're in the business of telling history, it makes sense to use chronological order from the get-go. The place where "most recent service" style is relevant is (1) in CV's (for impact, not our role), and (2) in articles about the post, not the post-holder. For a post that's important and ongoing, we need to give prominence to the current post-holder, but usually we do that by labelling them as incumbent in the info-box; the former post-holders are still in chronological order (see Secretary of State for Education for example). Pierre Trudeau's info-box is a really good example of a totally confusing layout because of its most-recent-service style. It's particularly inconsistent when the box is listing multiple posts, with some fully-enclosed in the time-line of another, for example his leader of the opposition, which is entirely enclosed in leader of the liberal party. If the whole thing were chronological, we'd quite intuitively order everything by start-date. Elemimele (talk) 17:15, 27 January 2026 (UTC)[reply]
Also agreed. It's rather confusing to go back in time like that, especially in an example like Trudeau where the first term was so long that it's very surprising to jump from reading 1984 to 1968. Cremastra (talkĀ·contribs) 16:40, 28 January 2026 (UTC)[reply]
Is the proposal that lists may, should or must be as you describe? And are you proposing to order the entire infobox chronologically (irrespective of any order of precedence that might hypothetically be relevant), or just the entries under a single infobox heading (irrespective of where it lies in the infobox)?
Would it not be best to have this put the current or most recent office at the top? That's usually the one people are looking for, after all. WhatamIdoing (talk) 18:53, 30 January 2026 (UTC)[reply]
It depends, though. If the person is currently in office, they're probably looking for the times of the current service. In the Pierre Trudeau example, though, he was last in office some forty years ago: it's more informative to start at the beginning of his first term, as the reader will probably want to know about his tenure overall, not just his most recent stint as PM. Cremastra (talkĀ·contribs) 18:57, 30 January 2026 (UTC)[reply]
Would this be desirable: Within a heading, start with the oldest entry on top. Within an infobox, order the headings with the most recent on top (irrespective of the order of entries inside that heading).TheFeds07:42, 31 January 2026 (UTC)[reply]
Example - For Trump's infobox? I recommend having "January 20, 2017 ā January 20, 2021", be above "January 20, 2025 ā present". GoodDay (talk) 22:14, 2 February 2026 (UTC)[reply]
Hi everyone. Having just started my first Good Article review, I've found there to be quite a great deal of difficulty in citing material that needs significant correction outside of the talk page. What I mean is that information like that can often be missed amid long discussions over necessary changes, complicating the process on both ends and only delaying it further.
I have a sense that it could be useful to have an option for editors (with some degree of authority granted to them by nature of their having taken on a review, or received a request for comment/second-opinion amid that review process) to leave commentary or flags at specific points in the article they're evaluating. The only such system that exists at present is invisible comment feature, which is restricted to the source code and complicated by the fact that it may mess up that source coding or leave unnecessarily long blocks of white space in between sections (if the editor wants to make certain that it's visible).
Having searched through the noticeboard, the only such proposal I could find was from 2008, wherein the majority of participants expressed concerns over the potential for such a system (if left unchecked and provided with equal access to all editors) to wreak havoc, particularly on articles dealing with current events or significant controversies. What differs with this proposal is that the editor in question would have to be vested with specific permissions from an authority at WP:GA (or WP:FARC), from what authority I'm not entirely sure, nor how this would be done (hence my bringing this to the idea lab). This would only occur at the time of nomination, at which point very few divisive topics are still as heated as they were when the controversy first began (spurring the creation of the article, in some cases).
I'm curious to hear what others' thoughts are. Any assistance with the technical side of such a proposal (if deemed worthy of passage) would be greatly appreciated. I'll look forward to the discussion to come.
Itās difficult to have a discussion about such comments, Iād opt to keep it in talk page which isnāt perfect either but most collaborative. ~ š¦ Shushugah (he/him ā¢ talk) 12:28, 14 January 2026 (UTC)[reply]
Hi Shushugah, thanks for the response. I'm curious, why would such a discussion be difficult?
I dunno, @CSGinger14. If we tried something like that, we'd probably have editors making misstatements like if it's not cited, then it's OR[27], even though the Wikipedia:No original research says that information can be 100% compliant with the NOR policy even if no source is currently named in the article. And if that commentary system is only editable by someone who has been vested with specific permissions from an authority, then 99% of editors aren't going to be able to reply in the same place with a comment like "They've got the jargon mixed up, and anyway you only have to cite information once in an article, so go look at the #Transportation section if you want sources about rail and bus." WhatamIdoing (talk) 01:42, 18 January 2026 (UTC)[reply]
Building off your point, I figure that's exactly the sort of risk that could be worked out here. Editors assisting in bringing the article up to GA status could have a means of requesting or acquiring access (perhaps automatically for those with the top 4 highest attributions (i.e edits / authorship %), or requested based upon recent activity (combined with evident participation in the review process).
'
Frankly, and evidently, the same sort of misstatements can be made on talk as well; your having located the invisible comment on the main page shows that such mistakes can be located by experienced editors and corrected, but that the process might be cumbersome for those who are new to the game. Alerts might be included on the transcluded discussion to notify involved editors of such changes. I'll wait to hear your word, but do honestly feel that such a change would be greatly beneficial, and assist with the visibility of exactly the sort of errors you've pointed out. Best wishes, CSGinger14 (talk) 03:26, 18 January 2026 (UTC)[reply]
If we're going to have such a system, I wouldn't restrict it very much. I definitely wouldn't want to see a comment from an editor that sits there forever, complaining about something in the article, or a couple of editors arguing in the mainspace. But maybe something vaguely like a custom {{info}} or {{fix}} template would serve the purpose ā not that we would exactly want {{info|reason=This stuff about rail and bus service isn't cited here ā should it be?}} to be visible to readers, but similar in the sense that you can place them in particular parts of an article, and anyone can change them or remove them later.
In terms of the GA workflow (because you need something that works now, not in the magical future), you might consider copy/pasting the whole article to a word processing doc, so you can highlight and comment as you read. That would make it easy to take notes as you go along, and to close them as they get resolved/you decide they're not worth it, and of course to walk away mid-process whenever you need to without losing your place. It's not a great workaround, but it's the only one I can think of right now. WhatamIdoing (talk) 05:27, 18 January 2026 (UTC)[reply]
So based on my understanding, you want a comments feature for a mainspace article when it's under a GAN review, akin to a Google Docs / online document software commenting feature? I do like the idea, but for a different reason; I think this would save reviewing time for the reviewer. Typically for a GAN review, I use something like Template:tq or any colour-text template to highlight specific phrases in an article that need resolving. I haven't encountered any issues with this system, though I must say that the articles I usually review are relatively small. For Editors assisting in bringing the article up to GA status could have a means of requesting or acquiring access (perhaps automatically for those with the top 4 highest attributions (i.e edits / authorship %), or requested based upon recent activity (combined with evident participation in the review process), can't they just circumnavigate the waiting time by leaving comments on the article's talk page? And how would we know that the reviewer truly left comments on the nomination if it's restricted to them and the nominator? Probably go with a general permission like AFCH. Icepinner (Come to Hakurei Shrine!) 13:40, 18 January 2026 (UTC)[reply]
Hi @Icepinner, you make several good points. I'll push back though in reference to @WhatamIdoing's earlier comment, as well as the discussion that took place here about two decades ago which pointed out the dangers of having open permissions for editors, as such a system could essentially be used as a means of advertising their disagreements with the page outside of talk. Visibility restrictions weren't my primary concern, mainly edit restrictions, to ensure that the system couldn't be abused.
'
I don't disagree that there should be a well deliberated breakdown of the article in talk alongside commentary in the main-space (which I'd argue should be restricted to the edit window (with notices similar to that of Refideas or Pp-semi to allow editors actually involved in the GA process to turn their attention towards it, but not crowding out the view for Gnomes or other editors that only intend to be there in passing (Would it make sense for visibility to appear as an option in extensions like HotCat?)). I'd ask other editors for their thoughts on how such a system would work. Best wishes, and best of luck to those in the US facing the storm this weekend. CSGinger14 (talk) 01:08, 24 January 2026 (UTC)[reply]
Adding a brief note here to re-up for another week of preservation. Hoping to get enough feedback to make a proposal soon.
I have an idea to (propose to) include a dedicated box on the Main Page for The Signpost similar to that Today's Featured List/Picture etc. I'm thinking it should displayed on the Main Page for 3/5 days after each issue is published; Any thoughts/suggestions regarding it would be appreciated..! Vestrian24Bio12:24, 18 January 2026 (UTC)[reply]
Just for clarification's sake (for everyone else if not yours), that article was republished from Meta probably because it was previously already a major topic of discussion on Wikimedia-l and elsewhere. I haven't seen evidence that the Signpost knew AI was involved in writing/copyediting it, probably because that was buried on the Meta talk page, and they added a disclaimer to the article when they learned. That "bit of heat" is at best a flickering candle; give them a break. Ed[talk][OMT]15:57, 21 January 2026 (UTC)[reply]
I didn't select it, but I'm the one who did the final copyedit on it, albeit with a lot of what I did reverted (it happens). It was kind of late on in publication, and I thought it was incredibly dense, about twice or three times longer than it needed to be, and hard to follow, but I was under the impression this was brought over from one of the WMF publications, so reluctantly passed.
I could probably edit it into a more coherent document of half its size. But it wouldn't be the author's words at that point, and I'd be co-author of a paper I didn't believe in the argument of. But if we're only publishing articles that don't challenge readers, what are we doing as a newspaper? Sometimes, you just throw it out there, don't under any circumstances state that it's an official view of the Signpost, and let the debate go where it may.
If you're unable to even see it's made with AI, then it's probably not AI "slop". The word has lost all meaning already and now just serves to signify overt AI aversion without ability for any nuance. I don't know if it was good that it has been featured mainly because it has some flaws like at least one misleading and possibly inaccurate data which I had asked about before signpost publication with basically no response. A reason to include it nevertheless is that has been read by very many and had substantial impact and got a lot of feedback by the community on its talk page ā it could be reasonable to feature it for that reason alone but with proper warning notes at the top. People may be interested to read about essays have had major internal impact/audience. Prototyperspective (talk) 12:59, 22 January 2026 (UTC)[reply]
As I said, I personally found it barely readable and overly dense without ever saying much, while being technically gramatical. I didn't suspect it was AI because I didn't think there was any possibility someone would publish AI in what I thought was an official WMF publication. Once it came out it was AI, my first reaction was "Oh, that explains it", replacing my previous judgement of "corporate writing".
Humans and AI are both capable of writing in that rather awful corporate style. Humans and AI can write overblown claims of disaster. Humans and AI can get me to give up and say "this was already published, I'm just going to copyedit the opening and let the WMF have their place in this issue; it's not my job to speak for them."
Thanks for explaining. I misread your comment thinking you were basically just referring to excessive length and maybe some grammatical issues here and there. Prototyperspective (talk) 14:24, 22 January 2026 (UTC)[reply]
I think if we had some more staff, this could be nice, but as it stands stuff is broken pretty often (e.g. some image gets deleted or some template breaks and then it's just cooked for a while until I can fix it). Currently, I am employed at a job that does not give me a lot of free time, so I cannot spend as much time as I think would be required to make it be consistently Main Page material (e.g. every article of every issue). jpĆgšÆļø14:18, 18 January 2026 (UTC)[reply]
Honestly, even when I do have enough time, the task of technical maintenance for the Signpost is so abjectly unpleasant that I would prefer to minimize my responsibilities as much as possible. For example, routine maintenance of templates and redirects will often be subjected to weeks-long bureaucratic review processes. A redirect that hasn't been wikilinked to anywhere since 2007 might be useful, according to somebody, so it needs to go through RfD and can't be CSDed and has to clog up the PrefixIndex until the RfD is processed; a template to black out text for crossword answers has the same name as a template that people got mad about in 2008, so even if it is hard-coded to be incapable of ever doing the thing that people got mad about the different template doing, it will be nominated for deletion, with a TfD notice breaking all the crosswords until it's resolved, et cetera. An image that we used in an article to discuss a hoax that was found and deleted gets nominated for deletion on Commons... for being a hoax. Somebody thinks an article from last year should have been titled something different, so they just edit the page to have a different title, which breaks a bunch of stuff in Module:Signpost. Oh, now some WMF guy slopped the copy in his essay that he submitted, so that's an ethical issue or something, because maybe the LLM was incorrect about what his own opinions were. Now some famous blogger is going to come call me a dipshit on the Village Pump over it. The whole tag system is busted because it was maintained entirely by force of Chris Troutman tagging the articles by hand every issue, and then he decided to go on some crazy tirade and get himself indeffed, so now the tag lists and the article series templates don't really work right, and even if we started tagging them again somebody still has to go through and add all of the articles from the last couple years. The archive pages and the main page still use totally different templates for some reason even though they basically do the same thing. There are about eight bajillion CSS classes that haven't been migrated into the master stylesheet, and also a bunch of them are just inline from random articles. Nobody knows what all the layout templates are or what they do. Also the commons delinker bot just fucks up old articles basically every day, and then you can't even go through to try to make a list of redlinked images to...
Thank you for your service, @JPxG. You've made it so that the average reader doesn't realize any of this, which is most likely a double-edged sword. :) JuxtaposedJacob (talk) | :) | he/him | 17:58, 18 January 2026 (UTC)[reply]
No. It's internal and much of what's written would be incomprehensible to people outside the project. Also, there are serious unresolved issues regarding the use of LLMs in Signpost articles. It's antithetical to Wikipedia's mission to put LLM content in front of humans. Mackensen(talk)16:49, 18 January 2026 (UTC)[reply]
This is also hardly the first āscandalā to hit the publication; theyāre a recurring feature and a leading cause of turnover in the editors contributing to the Signpostās publication. It also generally fails to contact editors for comment when it covers topics theyāre involved with, which is a failure to follow basic journalistic practices. This latest issue also included reporting on the Baltic birthplaces story that I believe seriously misrepresented the events in question; I havenāt made a big deal about it because the Signpost getting it wrong currently doesnāt really matter, any productive discussion towards resolving the actual underlying dispute will not come from such a complaint, and I donāt expect the Signpost to meet professional journalistic standards. If this were something we were advertising to all readers, however, I would have objected to its publication directly. TLDR, the signpost isnāt ready for prime time (even though I do think itās worthwhile as an internal newsletter), and unless thereās a huge shift in the amount of editor effort and interest going into preparing its issues, it isnāt going to be ready in the foreseeable future. signed, Rosguilltalk16:35, 21 January 2026 (UTC)[reply]
Strong oppose. The Signpost is a mixture of original reporting with opinion articles. It is not held to the same sourcing standards as mainspace articles. Putting it on the main page with our mainspace content will lead to confusion. Apocheir (talk) 19:47, 18 January 2026 (UTC)[reply]
The Signpost is a big part of why I signed up for Wikipedia in the first place! Having some more visible insight into the community would not be a bad idea per se, although putting The Signpost on the Main Page might be a bit much. And there is a bit of heat right now regarding the LLM generated article, too. MEN KISSING(she/they) T - C - Email me!22:39, 18 January 2026 (UTC)[reply]
Support. The main page is boring and not engaging. There is only a very small chance the user is interested in what happens to be interested in the one daily featured article; the DIYs are mostly meaningless mundane trivia; featured pictures are nothing of importance to society and not really educational but just aesthetically pleasing which is a type of photos people see tons of online already; on this day is an arbitrary selection of events that happen to have occurred on the same day; the In the news tile is imo the only interesting changing content but gets just very rarely. Adding the signpost there would make it things more interesting.
Additionally, people would develop more interest and excitement about Wikipedia and become more interested in becoming a contributor themselves or a more active contributor if they've already signed up if they read the internal news there.
and of next to no interest to the reader. not true imo. Wikipedia news are or can be of interest to the Wikipedia reader. Wikipedia readers also read news about Wikipedia in external sources, there's no reason why they wouldn't be interested in some internal news as well. Additionally, a fraction of Wikipedia readers are contributors. An option would be to only display it for users who are logged in but it would I think probably be best to include at least some visible link to the latest issue also for logged-out users. Prototyperspective (talk) 18:02, 19 January 2026 (UTC)[reply]
The problem is many readers will expect a "Wikipedia newsletter" to be some kind of official newsletter about interesting facts and upcoming changes, not an internal newsletter about the latest WMF scandals. Cremastra (talkĀ·contribs) 18:25, 19 January 2026 (UTC)[reply]
I don't know why putting sth about the Signpost on the Main page would be interpreted by readers for it to have "official backing" but one could also clarify that it's nothing official at the top of the Signpost or at the top of whatever page is linked to. Prototyperspective (talk) 20:50, 20 January 2026 (UTC)[reply]
I'd rather it's opinions weren't on the main page at all, it's already pushed via notifications on the watchlist any interested editors can find it there. Even if labelled as unofficial it's presence on the main page would suggest it's articles have community support. -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°21:32, 20 January 2026 (UTC)[reply]
No. The Signpost is mostly an internal project newsletter that thinks of itself as, and tries to be, a tabloid newspaper doing it's best to amplify minor scandals and division. The main page is focused on showcasing the best parts of the encyclopaedia to the readership, and The Signpost is neither part of the encyclopaedia nor our best work in project space. We do want to encourage readers to become editors, but not all readers - we want those who want to and can contribute collaboratively and collegiately. The Signpost will drive away many of those folk while attracting more of those looking for drama - the exact opposite of what the project needs. Thryduulf (talk) 16:06, 21 January 2026 (UTC)[reply]
The Main page is read by a lot of Wikipedians. An idea would be to only show some tile / brief info with link about it for registered logged in users. The general public does read about Wikipedia from time to time as well and there's a bigger chance for that if they're browsing the WP Main page exploring around. Prototyperspective (talk) 19:45, 31 January 2026 (UTC)[reply]
I oppose that suggestion for two reasons, firstly all the reasons I oppose putting the signpost on the front page, secondly portals are not obsolete. Thryduulf (talk) 23:34, 29 January 2026 (UTC)[reply]
Re-evaluate long-duration protections
When looking through the articles of the top-importance medical articles, I noticed that about 1/3 were protected, often WP:Semi-protected and in a few cases extended protected. Many of these protections were placed over a decade ago, for disruption that might not always be considered enough for protection now, or were leftovers from the hottest part of the COVID pandemic. I've since unprotected a couple per WP:TRYUNPROT, and asked for ECP to be lowered to semi, but I wonder if a wider evaluation would be beneficial. If new editors, who mostly read highly-read articles, face barriers to editing so often, we might lose out on new editors during a period we really need them.
So, a bit of a brainstorm on how to tackle this:
We could trial a large-scale reduction to WP:Pending changes protection of articles protected over 10 years ago, and evaluate in a year which articles still got vandalism (removing protection altogether). Say, reduce the protection in 500 or 1000 articles.
We could start a project with a couple of admins to re-evaluate protections to our highly-read articles, and use common sense to trial a reduction in protection levels where it seems sensible
We could add some guidance about applying protection of 2-5 years more often, rather than jump from a few weeks/months to indef.
As a reviewer I'd support systematic reduction of certain pages to pending changes protection. The PC backlog is almost always very small, and PCP is just smoother on both ends compared to edit requests. The only snag is that PCP is canonically only to be applied for persistent vandalism, BLP vios, and copyvios. The issues with the medical articles you mentioned I suspect were more in line with WP:V or FRINGE. I still think PC could work in practice, but there would probably need to be a wider discussion before implementing it. āRutebega (talk) 19:23, 20 January 2026 (UTC)[reply]
Hoping to get initial reactions here + new ideas before proposing it at WP:VPPr. The medical articles mostly suffered from vandalism, in terms of reason for protection (COVID was more to keep FRINGE out I imagine). āFemke š¦ (talk) 19:29, 20 January 2026 (UTC)[reply]
I don't support indiscriminate reduction in protection across the board, that's just going to lead to problems. However, something more focused that allows for a quick and easy reduction without too much hassle would seem to be useful. Thryduulf (talk) 20:11, 20 January 2026 (UTC)[reply]
I think it's a good idea to restrict it to vandalism-related protections. Overall, there are about 10,000 articles indefinitely semi-protected, while Category:Wikipedia pages semi-protected against vandalism has about 2300 pages. Curious to see how big the union of those two categories is. Maybe an experiment with the following parameters might work:
Get a list of all articles that were indefinitely semi-protected for vandalism more than five/ten years ago
Allow time for people to remove articles from the list where it's obvious that they will be vandalised again
Lower protection to PCR of remaining articles
A year later, re-evaluate with two goals:
Find out what share of article got reprotected to semi
Find out what share of articles had any instance of vandalism
Only 48x articles are in both "Wikipedia pages semi-protected against vandalism" and "Wikipedia indefinitely semi-protected pages", though I don't think pages are consistently tagged with the two different templates, so this may not add much information. I think you'd have to go digging in Quarry to find how old the protections were. Andrew Gray (talk) 21:41, 22 January 2026 (UTC)[reply]
Of the 11796 permanently semi-protected non-redirect articles, 23% were last logged more than ten years ago (2015 or earlier), and 30% 5-10 years ago (2016-2020).
This query is the same as above, but only those pages in the "Wikipedia pages semi-protected against vandalism" category. Of 1726 non-redirects, 24% were from more than ten years ago, and 37% from 5-10 years ago.
That makes for about 2700 pages which have been protected indefinitely for more than ten years, of which a little over 400 are explicitly marked as protected due to vandalism. So that might be a good first batch to look at. Andrew Gray (talk) 18:03, 23 January 2026 (UTC)[reply]
If the goal is to attract new editors by removing page protection, then the focus shouldn't be on unprotecting highly-vandalized articles; instead, we should start by getting rid of restrictions like WP:ECR and allow new editors to contribute to contentious topic areas/articles (e.g. PIA or Donald Trump). Some1 (talk) 20:29, 23 January 2026 (UTC)[reply]
PIA the purview of the arbitration committee. I'm generally quite skeptical of ECR and ECP, and think we can lower the protection on some pages in other CTOPs where they are discretionary. Many covid pages do not require ecp anymore for instance. āFemke š¦ (talk) 20:52, 23 January 2026 (UTC)[reply]
Support ā this makes sense. Also note that if there's better tools like Automoderator and Cluebot quickly reverting or flagging/spotting vandalism, then there's less need for such prevalent protection. I generally think the requirements for these protection levels are easy to meet but on the other hand, people have to start somewhere and often it's probably some article that is protected where they first find sth that needs to be edited.
An alternative or complementary approach would be to get more new users to post about the change they'd like to make on the talk page when the article they'd like to edit is protected ā e.g. directly redirecting them to the talk page with the new thread input fields opened (maybe prefilled with a text like "Please describe the change you'd like to make and other editors will do it for you if they agree") after for ~5 seconds the notice about the page being protected is displayed. Prototyperspective (talk) 13:19, 22 January 2026 (UTC)[reply]
The protection policy essentially already has that guidance and I think that's how most administrators handling protection requests do things nowadays. Most of the indefinite durations that should be revisited are older protections.
I am in favor of revisiting protections, but I don't support lowering the protection level of any category of articles "across the board". More specifically, I would be in favor of trialing pending changes for articles that haven't experienced a significant number of reverts recently. Most articles that are semi-protected indefinitely where it's warranted still receive some disruptive edits from relatively new accounts.
We could stack rank articles that were indefinitely protected more than ten years ago by a metric like "percentage of edits that are reverts or reverted edits in the last two years" and trial unprotecting the bottom 10% first. I would also filter out any articles that have had any higher-level protections in the last five years. If that goes well for six months, we could extend that to the next 10% or 20%, and so on. If there's interest in trying this approach or one similar to it, I would be happy to help on the technical side. Daniel Quinlan (talk) 22:44, 23 January 2026 (UTC)[reply]
When is the last time the foundation looked at creating a search engine?
Wikia Search? Given the increasing enshitification of corrupted engines like Google and Bing, what obstacles exist to creating a language independent Wikipedia-favorable search tool? BusterD (talk) 12:00, 21 January 2026 (UTC)[reply]
So a long time ago. Thanks for the history. Nice to know they saw it coming. I'll do my reading. Seems like we'd want to utilize one of the best known internet knowledge brands for more than just fund raising... BusterD (talk) 14:00, 21 January 2026 (UTC)[reply]
Please take a look at the technical village pump. The first item is about a project on semantic search, in very early days. I think starting a general search engine like Google would require far more funds than available. Yesterday, all my dreams... (talk) 12:23, 23 January 2026 (UTC)[reply]
That's a very expensive and complicated endeavor and would require some strong reason to greenlight it... stronger than just baseless conspiracy theories. Cambalachero (talk) 14:58, 23 January 2026 (UTC)[reply]
Is it not standard practice to research before forming your opinions? I would have thought that the curators of truth that are Wikipedians, like you, would have done that. I did it so easily, so what is your excuse? LightNightLights (talk ā¢ contribs) 13:00, 24 January 2026 (UTC)[reply]
The burden is on the person making such claims to substantiate them with sources, especially when it comes to active editors who have enough other things to do with their time. Prototyperspective (talk) 13:12, 24 January 2026 (UTC)[reply]
Let's dissect your comment.
Cambalachero made the claim with no sources that, paraphrased, "'Google is getting worse' is a baseless conspiracy theory." Where is your rage about that?
My 50th-to-last edit was on 16 January. BusterD's was on 12 January. Cambalachero's was on 1 January. Let's keep telling ourselves that Cambalachero is the "active editor" here. (And I do not even intend to make myself look good on whatever edit metrics there are!)
Did you actually read my comment? The one that linked to three sources and a Google search, therefore fulfilling my burden of proof? The one that is above your reply?
Asking me to be enraged is a bad thing to do. Meta discussions are supposed to be calm deliberation with rational arguments and again the person who should provide sources that explain and substantiate is the one making the respective claim(s) and this is all I said. Prototyperspective (talk) 13:53, 24 January 2026 (UTC)[reply]
That would be kinda nice, especially if it's just indexing pages linked in wikipedia articles (whether as sources or infobox things) I might be interested in doing that if the wmf isn't. It could even plug into wolfram alpha for actual questions instead of trying to find things mgjertson (talk) (contribs) 19:05, 26 January 2026 (UTC)[reply]
Proposal to create new categories for escape lines
Thousands of people from France, Belgium, and the Netherlands were involved in escape and evasion lines during World War II. The escape lines were devoted to helping downed allied airmen and others evade capture by the Germans and return to England, most commonly via neutral Spain. Wikpedia has nearly one hundred articles about the escape lines and prominent escape line leaders -- and more are being created. At present, articles about escape lines and escape line leaders are categorized as Category:French Resistance, Category:Belgian Resistance, etc. A category titled "Escapes and rescues during World War II" exists but it is little used and perhaps also too broad to focus on the very specific activities of escape and evasion lines.
I believe the escape lines and personnel merit their own category (or categories) -- as some escape lines already are in the French-language Wikipedia. The escape lines were distinct in their function and they avoided contact with armed and violent resistance groups. Thus, I hope that whoever is dealing with categories will create "Category:Escape and evasion groups (World War II)" and "Category:Members of escape and evasion lines". Separate categories might also be created for the most important of the escape lines, the Comet Line and the Pat O'Leary Line. Smallchief (talk) ā Preceding undated comment added 16:15, 26 January 2026 (UTC)[reply]
Big popup when trying to edit with recent LLM cookies or links with an LLM referral link
This will likely be thrown out as a bad idea but we should have a big popup with a 1 minute timer for any new editor (less than 50 edits or not logged in) if they have cookies from llm services or use references with llm referral links. Something that makes it very very clear that they should not, under any circumstance, use an llm for anything when editing, especially if they think they can or are the exception to the rule because they 'know what they're doing'. mgjertson (talk) (contribs) 18:51, 26 January 2026 (UTC)[reply]
Just because it isn't completely banned doesn't mean we shouldn't stop people who don't know what they're doing from doing it (for example, writing about yourself isn't technically banned but so heavily discouraged it might as well be) mgjertson (talk) (contribs) 19:10, 26 January 2026 (UTC)[reply]
We should just make an edit filter for any edit that adds a URL with LLM metadata, set to disallow for any user, admins included. I generally agree with Thryduulf's view, and reluctantly acknowledge that there are some tenuous use cases for LLM-assisted editing when a human reviews before submitting, but there aren't any for these sorts of links, and having them disallowed by a filter also populates a handy log if we need to investigate a user. Ivanvector (Talk/Edits) 19:09, 26 January 2026 (UTC)[reply]
Links found by LLMs fall into all the following categories:
Reliable and relevant
Reliable and irrelevant
Unreliable and relevant
Unreliable and irrelevant
Of unclear reliability and/or relevance
Non-existent
Obviously we don't want links of types 2, 4 and 6, however we definitely do want links of type 1. Types 3 and 5 are sometimes good and sometimes bad, depending on the context (for example an unreliable source is often a useful way to locate a reliable source or determine the plausibility of given claim). A blanket disallow would prevent additions we do want as well as those we don't. Thryduulf (talk) 19:48, 26 January 2026 (UTC)[reply]
Wikipedia's servers (and its JS) has no access to cookies from other sites, unless the WMF would convince chatbot sites to make requests to Wikipedia in order for us to set the cookies.
Having an edit filter warn (maybe warn maybe block but then have instructions about how to remove the tracking params) and link to whatever our best at the time policy related to LLM use might have some advantages. Not to be "scary" but to inform. Although I do admit the few times I recall accidentally trying to save an edit with a blacklisted URL I got a bit of a fright. Skynxnex (talk) 21:29, 26 January 2026 (UTC)[reply]
Yes, I've run into URL blacklisting issues a few times in discussions and it's frustrating and disruptive. I wouldn't be surprised if it results in lost edits (I know this is tracked for some things, but I don't know if it is for this - WhatamIdoing is often knowledgeable about stuff like this). If so it is likely that something related to LLMs would also result in lost edits - for some edits that wouldn't be a significant loss to the project, but for others it absolutely would be. Thryduulf (talk) 21:45, 26 January 2026 (UTC)[reply]
What the abuse filter looked like yesterday
Yes, pretty much any interruption at all loses edits, and "scary" interruptions like blacklist and abuse filter triggers lose a lot of edits (including some that we want to be discarded). This is hardly surprising.
In fact, I've been meaning to ping @PPelberg (WMF) and ask him whether they've done anything to the save dialog in mw:Extension:VisualEditor recently, because what you can see in this screenshot from about 12 hours ago is not helpful. I'd guess that even most experienced editors would struggle to understand what's going on here.
(Note: I had this comment drafted before the above one by Skynxnex.) Please clarify on what you mean by cookies from llm services. While on certain websites it is possible to identify if a user is logged in using tricks with images, random websites (like wikipedia.org) cannot just steal cookies from other sites (like chatgpt.com, claude.ai), and using the image method (if even possible) would be a HUGE privacy violation, outweighing any benefit earned from identifying potential LLM users, not to mention false positives (just because someone is logged in to ChatGPT doesn't mean they will use it on-wiki). As for the ?utm_source=chatgpt.com "referral links", someone could just be using an LLM to search for sources but not to write any of the actual content. OutsideNormality (talk) 22:31, 26 January 2026 (UTC)[reply]
Wikipedia cannot on a technical level interfere with other site cookies. It is possible, similar to ad servers, have cooperative methods to track users across sites. Firefox (and to a lesser extent Chrome), and other browsers, block many attempts however. Skynxnex (talk) 03:50, 28 January 2026 (UTC)[reply]
Browsers only send cookies back to servers in the same domain as the server who originally created the cookie. So Wikipedia servers will never see the cookies from other sites. isaacl (talk) 04:16, 28 January 2026 (UTC)[reply]
replacement symbols
what im saying is there could be a option in settings where you could remap certain text actions to other symbols, ot wouldn't literally make the symbols act like the normal counterparts, just replace them when you use them, for example, you could remap the template function from {{ to { but in source, it would still be {{, its just that all instances of { are replaced with {{, of course, this would only work on visual editor, nor source editor, by default it has the regular wikitext markup symbols we have now Misterpotatoman (talk) 20:38, 26 January 2026 (UTC)[reply]
This is feasible in a user script, but UI designers who remember the 1990s would tell you that it's probably a bad idea. A lot of people thought that single-character "commands" were great, until the commands started executing whenever the person bumped a key, typed the wrong one, thought they were in a different window, etc.
Note you can use the keyboard shortcut mechanism supported by your device's operating system (or use a third-party program). However it would probably apply across all apps, or at best, within one app, so it wouldn't distinguish between Visual Editor and the source editor. isaacl (talk) 02:45, 28 January 2026 (UTC)[reply]
What if some articles could add a comment section?
Like for example, what if an article on a fiction book or series could be commented on by people who feel like the article is missing something? Any thoughts if this is unreasonable? ā Preceding unsigned comment added by ~2026-57372-0 (talk) 21:14, 27 January 2026 (UTC)[reply]
Entertaining this idea a bit, it could be nice to make a place that served as a forum for some topics, as talk pages are NOT a forum. Honestly makes it hard to collaborate when you can't shoot the shit with other editors. There are some unofficial places for Wikipedia in general, like Discord or Reddit, but "You will never find a more wretched hive of scum and villainy." GeogSage (āChat?ā) 02:13, 28 January 2026 (UTC)[reply]
I do get it, but the #1 issue with "forum pages" is moderation. There won't be WMF content moderators, it'll be Wikipedians. It's just gonna spiral into being a Facebook comment section. I think if a feature like this were to be implemented, it would have to be turned on for uncontroversial pages.
Here are some examples of pages that shouldn't be allowed to have these pages:
BLPs and recent deaths
Anything subject to WP:ARBCOM measures, broadly construed
Anything relating to race, ethnicity, sexual orientation, disability, etc.
Top-level country pages (i.e. USA, Pakistan, D.R. Congo) and their relations
etc.
Also, it violates neutrality. By allowing anyone to talk about the topic of the article and shove their own (often bad) opinions on the subject, Wikipedia will shift away from being a neutral encyclopedia.
Maybe the relevant Wikiprojects could host a metaphorical "water cooler" if appropriate. That said, with a few exceptions, I find the participation in Wikiprojects a bit disappointing. There isn't much collaboration, and when new people stop by to find people they are often met with silence. GeogSage (āChat?ā) 03:43, 28 January 2026 (UTC)[reply]
Wikipedia should have a place to make humorous essays (Signer the News). With gamification and a user analytics dashboard. Gamification with points and badges. Goal - to teach new users to make articles soon. Signer made articles will have the humor tag by default. Does this sound like a good idea. Wagon fossil gala (talk) 21:48, 27 January 2026 (UTC)[reply]
Are you thinking that this would teach new users how to edit (e.g., to make links or italics)? I don't think it would do much for teaching them about notability, sourcing, and neutrality. WhatamIdoing (talk) 03:01, 28 January 2026 (UTC)[reply]
from what I understand, you are suggesting a non serious tutorial, like how to add images or even something as simple as switching modes at the first test, i support of this! pretty much every editor has the same questions at the beginning and it would take alot of work off mentors, there are also alot of rules and things outside of how to write like what to write and not, when to and not link and cite, how to upload images and what belongs on other wikis, id imagine direct instructions and not actually writing your own things because then someone would have to grade them then Misterpotatoman (talk) 19:52, 2 February 2026 (UTC)[reply]
Repetitive editors
Do we have rules or policies for editors who systematically do the same thing repetitively? Like changing which/that or killed/murder or any number of examples. Like splitting/merging paragraphs. They are some of the most irritating editors. Some are banned and they never go away turning into decades-long zombie LTA cases. They start out in good faith, become true believers, irritate the hell of everyone, get banned, and keep coming back with socks and IPs. There should be some kind of rule that can quickly stop it. Call it WP:REPETITIVE, a noticeboard where the community can discuss cases brought there. This often comes up at ANI, but usually not until they have already caused a lot of disruption. Repetitive editing is neary the same as bots, which have strong regulations. Human editors doing the same have no checks, except ANI which is inconsistent and difficult. -- GreenC04:20, 28 January 2026 (UTC)[reply]
Are you talking about stuff like that one issue with the mass changing of BLP's places of birth from "Estonia" to "Estonian SSR, Soviet Union"
I mean, those kind of editors are textbook WP:DISRUPTIVE editors. I think exact scenario might specifically warrant a section in here.
Disruptive editing is a pattern of editing that disrupts progress toward improving an article or building the encyclopedia. This may extend over a long time on many articles.
Depending on the case, it could fall under WP:TENDENTIOUS (essay of WP:DISRUPTIVE)
Tendentious editing is a pattern of editing that is partisan, biased, skewed, and does not maintain an editorially neutral point of view. It may also involve repeated attempts to insert or delete content in the face of the objections of several other editors, or behavior that tends to frustrate proper editorial processes and discussions. This is more than just an isolated edit or comment that was badly thought out.
Some of these might fall under WP:MEATBOT and require permission in advance. However, some of these are helpful edits, even if you don't like seeing the change happen. For example, people who change which to that for restrictive clauses in American English articles are doing a good thing and should be encouraged. Small improvements are still improvements. WhatamIdoing (talk) 20:36, 2 February 2026 (UTC)[reply]
Return to IP editing
wp:deny
The following discussion has been closed. Please do not modify it.
We could ask the WMF, but we can't tell them. The chances of them saying "yes" if we did ask are extremely low for all sorts of good reasons, including those mentioned by 331dot and Aaron Liu. Thryduulf (talk) 21:49, 29 January 2026 (UTC)[reply]
Named Preference Sets ("Editor Profiles") for Task Switching & Accessibility
The Problem:
Currently, MediaWiki preferences are monolithic. If you want to switch between different editing tasks ā for example, from patrolling recent changes (which might use the Vector legacy skin, Twinkle, and specific watchlist settings) to writing a new article (which might use Vector 2022, the VisualEditor, and a distraction-free gadget setup)ā you have to manually change multiple settings across several tabs in Special:Preferences. This is time-consuming and creates friction for task-based editing.
More importantly, this system creates barriers for:
1. New editors, who face analysis paralysis with dozens of complex options. An option could be created called New Editor
2. Neurodivergent editors (e.g., those with Asperger's, ADHD, or sensory sensitivities), who benefit greatly from predictable, customized interfaces and the ability to switch contexts with minimal executive function load.
3. Change - My analysis of why UX and UI changes fail to get community support, because is because it is imposed on wikipedians, rather than giving them an option, or differentiating between the needs of editors and readers.
4. New preference options are not used - Dev creates new options, but because they aren't known, people don't add them to preferences. An option could be to create a preference set - called early adopter
A script would be a great way of trying it out, but if it was done as a script would it be able to address the cases above? (have added 5 above for experienced editors). I was also hoping that there could be a way of sharing profiles. Wakelamp (talk) d[@-@]b10:25, 3 February 2026 (UTC)[reply]
addition of favorite pages
almost all the pages on my watchlist, i dont actually add to because i want to watch them, but because i want a easy way to access them and remember them, so i propose favorites, specifically for pages you want to remember, plus, a average user of wikipedia probably only uses it for checking pages, they may have a particular or multiple pages they need to a easy way to access, for example, a person might need to write something on topic like color theory, they could add it to their favorites and not their watchlist as they have no plans to edit it Misterpotatoman (talk) 19:41, 2 February 2026 (UTC)[reply]
by what i mean is articles you can create with no strict laws of how and what to write and what needs sourcing, there would be no quality standard, blogs would show up below the search results when you search up, for example you can make a blog about your favorite but niche topic that cant happen because its actually apart of another topic, or just make a list you want to share, i would add a absolutely massive amount of content and user accessibility, having something users can actually do other than editing thats not serious, i say theres a separate button to browse only blogs Misterpotatoman (talk) 09:20, 3 February 2026 (UTC)[reply]
@Misterpotatoman can you clarify your idea a bit further. I think having a shared blogs (what editors are working on now) as part of a project could be interesting and build community, especially if we could somehow grab project members edit summaries to do with articles that are part of the project Not certain about on article as we try and avoid diverting people, but diverting high conflict editors from protected pages could be good.. (With fun, I find wiki meetups and pages to do with Wikipedia on FB and Reddit and mastadon helped.)
WMF
Planned short test of mobile banners promoting the Wikipedia app
Hello,
The Wikimedia Foundationās Communications and Product teams would like to implement a small test on centralized notice banners to encourage more people to download and use the Wikipedia app. It will be a simple banner, targeting logged out mobile users and will run for just a few days, starting on December 15. The goal is to get more people using the app so that they become more engaged with Wikipedia in the long term. This is increasingly important as our Wikipedia traffic is changing, and it is part of our Foundationās annual plan. If you have any questions or concerns, please let us know. Thank you so much.
@ARamadan-WMF Are you sure that "get[ting] more people using the app [will cause them to] become more engaged with Wikipedia in the long term"?
I prefer web browsing over apps. (I don't understand why, for example, Home Depot even HAS an app. Browsing their inventory and ordering online works perfectly well from a web browser. Similarly, when reading The New York Times online, their web page nags you to use their app. Why? Reading the NYT using a web browser is perfect, in my opinion.)
Reading plus editing Wikipedia on a tablet and also a Windows PC, using a browser, is a great experience for me. I read WP using my phone. I don't generally edit from my phone, but some long-term editors do. Does using the app really drive engagement, and how can you tell? David10244 (talk) 05:06, 21 November 2025 (UTC)[reply]
@David10244: Are you sure that "get[ting] more people using the app [will cause them to] become more engaged with Wikipedia in the long term"?: Apparently the Wikipedia mobile app has games that are supposed to keep people engaged now. T400512 says they're going to add even more in the future. ChildrenWillListen (š talk, š« contribs) 23:23, 23 November 2025 (UTC)[reply]
@ChildrenWillListen OK, thanks for that info. (Personally, I dislike games on mobile devices, but of course people do have their own preferences.) Are people really "engaging" with Wikipedia if they are playing games? Even if the games are hosted within the app, time spent playing the games is time not really spent engaging with WP...
@ARamadan-WMF: I haven't used it in while, but if the app restricts editing or has missing features compared to mobile web (due to underdevelopment) it should make it clear that mobile web is better for that task. Otherwise, you are pushing Wikipedia-lite: a watered down, crappy version of Wikipedia and people will disengage entirely out of frustration. There must be a list of restrictions somewhere (or the app is better in every way?) that you have evaluated before pushing the app with a banner.
@David10244: not that I am a proponent of a Wikipedia app, given the development costs, but apps can have more features compared to the web. From my hazy understanding, apps can:
allow easier payments (didn't the WMF just announce you can donate from the app using Google/Apple pay?)
securely store the number page visits locally (the WMF is developing donation banners based on number of views)
Allow users to upload a photo in a free file format when your phone uses a proprietary format
Send push notifications to your device (e.g. you have new messages), etc
@Sohom Datta maybe I am confused or didn't explain it well, but on on mediawiki.org: "The apps already locally store and surface the user's reading history" and in relation to the new banner placement widget, "Readers will be able to [...] choose how often they want to be reminded, based on the number of articles they read". Commander Keane (talk) 10:39, 28 November 2025 (UTC)[reply]
I am leaving this comment from the app after the reading comment above. With an account I can manually leave a comment here by editing the wikitext of the whole page. I don't see any "reply" buttons anywhere though. A streamlined way to upload freely licensed photos would be a great addition to the app and one of the few clear advantages to editing on a phone (while we are apparently trying to get people to download the app). Right now (on Android using the official app), I have to switch over to the Commons app and it's all but clunky. I imagine it's also a more straightforward addition than improving the mobile's editing interface. Rjjiii (ii) (talk) 20:17, 28 November 2025 (UTC)[reply]
Maybe the IOS app lags behind in capabilities? I tested logging in and there is no way to navigate to these boards; the Home page simply scrolls endlessly back in time. ~2025-37129-61 (talk) 23:21, 28 November 2025 (UTC)[reply]
Ah, okay, then yes they are different. On Android, if you open a new tab it begins on the Main Page. This may be coming to IOS as well, because I think that new tabs only started showing the Main Page this year. Rjjiii (ii) (talk) 05:43, 30 November 2025 (UTC)[reply]
Aside from the editing issues mentioned above, the app also mostly ignores the main page content which our community has decided to show on any given date. Aside from the featured article, it substitutes its own things without community approval, such as having a Most-viewed article section, using the Commons featured picture of the day instead of our choosen WP:POTD, and replacing our set of anniversary articles with its own OTD that isn't vetted or necessarily on our list. I've no idea who curates that, but I don't think we should be promoting something that fights against the community's editorial decisions. It also sucks in incoming links from browsers, making it more difficult to view the project on the Web even if you want to. ā Amakuru (talk) 07:29, 28 November 2025 (UTC)[reply]
That's terrible, and should be discussed at an RfC at VPP, and then probably removed from the app. I thought the WMF didn't do content and left that to the wikipedia's? At the very least they should be able to tell us how / by whom the sections on the App main page are created, and why they don't use the local ones. I don't have the app so haven't checked this, I do remember the reluctance they had to remove the Wikidata short description from it: I hope any necessary changes this time will be quicker and in a more collaborative spirit. Fram (talk) 09:10, 28 November 2025 (UTC)[reply]
@Amakuru, @Fram It is very hard at a technical level to exactly extract the on-this-days section of the main page in a reliable manner due to it's free flowing nature, as a result to my understanding of what the underlying code is going for a compromise, it is parsing November 28 (today), using the much more standardized format of those pages to serve chronological information from the page. The first OTD entry on the app is "Over seven hundred civilians are massacred by the Ethiopian National Defense Force and Eritrean Army in Aksum, Ethiopia" which corresponds to a community generated entry on November 28. For what it's worth, I don't think there is a conflict with the communities editorial decisions here, the content being shown here is community generated and is prominently linked to in the first link in our OTD section. This is not WMF generated content, it is literally content we have decided is good enough to link from the main page. Sohom (talk) 16:47, 28 November 2025 (UTC)[reply]
There is a huge difference between content linked from the main page, and content shown on the main page. Basically, this gives vandals a clear method to vandalize the main page on the App. Fram (talk) 16:52, 28 November 2025 (UTC)[reply]
I personally don't buy this argument, if content is one click away, people going to the page, through mind you the literal first link on OTD will have a pretty bad impression of Wikipedia anyway. Not to mention that this concern is effectively the same threat model as if somebody where to vandalize a DYK or OTD and the preview of the article showing up on hover on the main page, however, we as a community typically do not fully protect DYKs or OTDs. For what it's worth, I think there are mitigations against this kind of scenarios, in that I think there is aggressive caching and if the code sees a empty page, they will revert to showing a cached version + the app randomizes and caches which entry folks see, and so the chances of a person vandalizing the page and it immediately showing up on the main page are pretty slim. Sohom (talk) 17:03, 28 November 2025 (UTC)[reply]
The clickthrough is minimal compared to the impressions the main page gets though. Vandalizing a linked page will reach a few dozen people or so (assuming the vandalism is up for a few minutes), vandalizing the main page reaches thousands of people in the same timeframe, and is much worse for PR as well. I don't know about the caching and whether that helps (though the "empty page" is a very uncommon type of vandalism). Would probably be best to test this (not with vandalism, but by constructively changing some text which is visible on the App main page, and seeing how long it takes to change on the main page). Fram (talk) 17:23, 28 November 2025 (UTC)[reply]
Hmm, I went to edit November 28, and realized that it seems to be protected under pending changes, that would make it much harder to get vandalism over to the main page for today. (it might be instantaneous for us cause both of us would bypass pending changes). Sohom (talk) 17:57, 28 November 2025 (UTC)[reply]
The incoming link issue has been a particularly pernicious issue for me, the only obvious end-user solution for it is to delete the app which is presumably not what is wanted. CMD (talk) 09:17, 28 November 2025 (UTC)[reply]
I really like some of the app landing page features, and some of the editorial(!) decisions like the POTD and OTD can be refreshing. However, the 17 fair use images shown (I stopped scrolling after a few days worth of feed), often cropped and with no way to tell they do not have a free licence, was disappointing. I am guessing there were 17 fewer fair use images on the Main page during that period.
I agree the incoming links issue has been one of the reasons I have the app set to never open wikipedia links, and Android somehow still disobeys me sometimes :(. Sohom (talk) 16:52, 28 November 2025 (UTC)[reply]
I tried the app the other day, it is dreadful. How they do the lead image is really strange, and some of the features donāt make sense. The app should be designed with the community, idk what they think theyāre doing Kowal2701 (talk) 12:39, 28 November 2025 (UTC)[reply]
First off it's horrendously impractical for editing, I could list dozens of things but it's very clear it's not intended to be used by editors so I won't waste my time. I deleted it after 10 minutes. Just on the tabs:
the Explore tab, I don't understand what they were going for. The Main Page is carefully curated, idk why it wouldn't be kept (the layout is ugly and monochrome as well). For something called Explore, I'd expect them to use Wikipedia:Contents, or propose random topics for people for people to learn about, or whatever. Something that actually lets the reader explore the encyclopedia, ie. where they can navigate themselves rather than getting random articles on Polish towns etc.
Places is an interesting idea, but what is its purpose? Is it for Americans to learn geography? Why is it only limited to settlements, administrative divisions, and landmarks? Why are administrative divisions presented as a point? Could it be tied into country outlines (eg. Outline of Myanmar)?
The others, sure they make sense, I wouldn't really use them or find them helpful other than "Search"
On the app, it just isn't a wiki anymore. I can't edit any of the tabs. I don't like the personalisation. The lead image appears as a banner at the top, and the infobox is collapsed under "Quick facts". It boggles my mind that the team working on this thinks they can redesign everything without community consensus, especially when it's done so poorly. The website is brilliant, just copy that over and maybe add a couple more features for exploring, that's all that needs to be done. It being awful for editing also means we'll get less new editors, which is what we really need to have begging banners for. A "reader" version and an "editor" version that people can switch between might make more people aware of their ability to edit and make it more accessible so they try it out. This being said, the idea of prioritising the app is great, it bypasses Google's LLMs, but the execution and process was very poor. Kowal2701 (talk) 17:23, 28 November 2025 (UTC)[reply]
I've been somewhat involved in discussions related to the Android app so I can give you the high-level "why" of the design choices. Back in the day of Vector, when the app was first created our UI, infoboxes, image placement, warnings and even our main page sucked on mobile, taking up often more space than was available on mobile. As a result, the team at the foundation had to make certain optimizations/tradeoffs (like hiding the infobox, lifting the lead image etc), and changes to the layout of a variety of elements to get it to work on mobile. Since then, there has been significant improvement in our ability to serve mobile-first content, particularly due to collaborations between technical editors and WMF teams to overhaul and improve Wikipedia's templates and user interfaces to be mobile oriented. There is still a significant amount of work to be done before we can get to your standard of "hey they could just put the website into the app" and for folks to be happy with it (not to mention that even then, a significant amount of engineering will be required to replicate mobile-web-only features using Java code).
To a few of the more specific points, the explore tab was developed to copy the essential features of the current main page back when showing the main page wasn't a option, similarly, the way the "places" feature works is that it uses your geolocation to find articles close to you, unfortunately, we only use coordinates in administrative divisions and such, limiting the feature. To the point of using outlines, our outlines are free flowing and outside of using a LLM, there is not a lot of ways to extract structured data that can be used to augment this features through outlines. I can see a situation where we use Wikidata to augment some of this data, but such uses have been frowned upon by the community back in the day (see also short description), which is why I think the app avoids it Sohom (talk) 17:52, 28 November 2025 (UTC)[reply]
Thank you. The technical aspects are beyond me, I just find the website on mobile pretty good all considering (on iOS btw). I can understand some of the design changes like collapsing the infobox, I just wish things like this were run past the community, like in batches. This project operates by consensus. I'm sure WMFers see it as given that some in the community are going to rage against anything they do, but involving the community at earlier stages would negate a lot of that. Kowal2701 (talk) 18:19, 28 November 2025 (UTC)[reply]
I installed the App. It gave me Dutch as default language, but allowed me to another language. But after adding English, the app hecame quite a mess with the two languages mixed. I thought I would get some switch to see enwiki only or nlwiki only, but no, I got something unwanted. I have removed it again, as it also interfered with my standard Wikipedia editing on the phone here. Not a fan... Fram (talk) 19:10, 28 November 2025 (UTC)[reply]
Eh no I agree, the "using different languages" thing is weird for me as well. It's always given me English though, maybe it picks the language based on location now ? Sohom (talk) 19:44, 28 November 2025 (UTC)[reply]
@Sohom Datta I know this is a few weeks old, but... Why do we have a Wikipedia app at all? The effort devoted to creating such an app could have been used to improve the layout on smaller screens, as you mention.
I wonder why many apps exist today. Why does Home Depot, or Wal-Mart, for example, even have an app? Their web sites work fine on mobile and tablets.
Well for one, the talk page button isnāt easily accessible while reading a page, you have to click the āmore itemsā ellipses to find it. Worse, the ālearn more about this pageā link appears as broken HTML, making it vastly less likely for app users to click in and read it. Thereās no ability to access category pages, and the notice boards are completely walled off from the IOS app. ~2025-37100-27 (talk) 23:43, 28 November 2025 (UTC)[reply]
No VisualEditor (and the joys of visual citation insertion, etc), no access to Help desk/Teahouse (without pushing you to the web on Android, ~2025-37100-27 suggest zero access on iOS). Not suitable for new editors. Not suitable for experienced editors. There are more limitations.
I thought the app was just a bit of fluff that the WMF was going to half-develop because cash was slushing around. Without VisualEditor (a 13 year regression) and Noticeboards (a 21 year regression) it is. Minor landing page issues, as discussed above, are not my major concern. If the WMF intends to make the app equivalent to mobile web then I am on board. I will test, and file bugs/features 'till the cows come home. We all could.
If it going to remain dreadful, then I would like to keep editors on mobile web (and lets face it, mobile desktop), or push them away from the app ASAP. This would not involve a mobile banner promoting the app. I do think the reading experience is superior on the app. But people read Wikipedia because those before them have edited to create that content. Appealing to financial reasoning: over time, you will get less and less donations with less and less editors. Commander Keane (talk) 01:04, 29 November 2025 (UTC)[reply]
In the iOS app, talk pages are often difficult to get to. But whatās much worse is that it appears impossible to reach an article from its associated talk page. MichaelMaggs (talk) 09:25, 14 January 2026 (UTC)[reply]
To you and everyone else at the WMF: Stop trying to make Wikipedia popular. Focus on making it good. We aren't here to make money, or gain users, or have power. We're here to make a good encyclopedia with a strong set of moral principles. The WMFs recent actions do not seem to reflect this goal, instead believing that more users equals a better encyclopedia when it is the other way around mgjertson (talk) (contribs) 19:15, 26 January 2026 (UTC)[reply]
Hi all, thank you for the thoughtful questions and concerns raised here. My name is Jaz, and I am the Lead Product Manager for the Mobile Apps Team.
The banner is intended to be a time-limited test that would only be shown to logged-out mobile readers on Japanese Wikipedia (in Japan) December 15-16 and English Wikipedia (in South Africa and India) December 15-18. The purpose is to understand whether a simple banner can help raise awareness that the Wikipedia app exists, especially among new readers, and if those readers retain at the same rate as readers that discover the app organically through the app stores.
Why do we want to drive more traffic to the apps?
Our broader goal is to help new and existing readers return to Wikipedia because they find it a compelling place to learn. To address this we want to experiment with ways that help new generations of readers find Wikipedia useful, return frequently and eventually become the editors we need to keep the projects healthy.
There are two shifts in reader behavior that are driving this:
The number of people visiting Wikipedia, and the ways that they visit, have been changing for several years, with fewer people arriving to the site through external search engines.
Based on our existing data, we know that readers on the apps return more frequently and engage more while they are reading than readers on the mobile web, thanks in part to built-in platform features. Readers who install the app tend to come back more often and explore more content directly on the platform. However, install rates are stagnant and primarily come through organic searches in the app store.
In short: We think that having people come to us through a platform we control, instead of mostly through search where we have no way to ensure we remain as visible as we have been, is key to remaining a vital, viable movement. This is a small test to see if this could be one way of helping that.
Because long-term sustainability depends on new readers returning and eventually becoming editors, as outlined in the Wikimedia Foundationās annual plan and the Readers work, we want to connect people with the reading environment where they are most likely to stay engaged. For new generations there is a higher tendency to rely more on mobile apps and personalized experiences when learning online.
The difference between apps and mobile web
Several people raised very valid concerns about the apps not fully matching mobile web functionality. This is correct, and we want Web to remain the primary environment for editing workflows that are not supported, or are less than ideal, in the app. For users interested in editing on the apps, we will ensure that easy and intuitive ways to transfer over to the web are available: We want readers to be able to easily use the apps for all the things the apps do well, and lead editors to the web for editing. If you are interested in efforts to improve mobile web editing you can read more here.
On the apps, we want to focus on the needs of readers who prefer mobile-native experiences and are accustomed to personalization, like enabling readers to pick topics they want to see more, showing them trends in their reading patterns or notifying them if they havenāt met a reading goal. This shift allows the apps to focus on what they are uniquely good at, including reading on the go, offline capabilities, personalization that respects privacy, push notifications, and other mechanisms like widgets that help readers return more consistently.
New capabilities weāre exploring on the apps
Explore feed
You are right that the Explore Feed could use an upgrade. We want it to be easy for people to discover content of interest when they are browsing. We have plans to revamp the Explore Feed in May to address some of the gaps that have been raised (for example, surfacing content across wikis in more useful ways). There will be outreach to shape the new explore feed in late January, in the meantime, consider signing up for the app's newsletter so you can receive updates directly on your talk page.
WikiTrivia game
It is also understandable to have curiosity as to why features like the WikiTrivia game exist. With the challenge of readers coming to Wikipedia for a single question and leaving, simple, low-effort interactions can help people discover articles they might not have found otherwise, which in turn can lead to them to read more and return more often.
WikiTrivia is one example of this and actually leverages the On This Day page curated by the community. It gives readers an enjoyable way to discover articles that they can then read, save, or share. We have received positive feedback and requests for more games through in-app feedback forms, our support emails, project pages, press and play store reviews. Based on the positive feedback and data from Android, we plan to bring it to iOS as well in 2026.
Why do some features vary by platform?
I see there is a question of why some features are on one platform but not another. The way our team works is to see if a feature performs well on one platform before bringing it to the other so we are being thoughtful about where we put our time and energy and not scaling features that do not work or arenāt desired. Tabs is a recent example of a feature that was originally released on Android and highly requested by iOS app users, so we prioritized releasing it there recently. You can see a similar approach to Year-in-Review which was only available on iOS last year but is currently available on both platforms this year, with improvements based on feedback the team received.
How can you get involved?
We welcome ongoing feedback about the apps, especially from editors who use them or want to use them more effectively. App development is shaped by community input through Village Pump discussions, project pages, the support email channel, and app reviews. You can leave feedback at any time on our discussion page and stay informed by subscribing to the app newsletter. Iāve tried to respond to all of the great feedback here, but will also take a pass at individual comments again and will respond inline if I missed something over the next few days.
Ultimately our goal is to run this test thoughtfully, learn if it increases retained installs, and discuss the results with you all to determine if efforts like these could support the overall health of Wikipediaās reader and editor ecosystem. If the apps are not personally your preferred platform or you do not have strong opinions about their direction, that is okay, we understand we have a diverse community with diverse preferences and interests, thatās what makes it so great. The web teams also regularly welcomes feedback on how to improve the mobile and desktop web experiences for readers and editors.
But the key thing is this: The internet is changing and fewer readers are finding their way to Wikipedia, or come less often, because search traffic doesnāt work the way it did in 2003 or 2014 or even 2021. This means we have less chances of making more people edit. We want to find ways to make it easier for readers to return to our articles. This is a small, limited experiment to see if this can help readers return. If we can make readers come to our own platform, and return, then we can send them to the mobile web for editing, keeping our ecosystem healthy.
JTanner (WMF) (talk) 20:21, 2 December 2025 (UTC)[reply]
Thank you. Is there anything on the app that pushes/nudges people into editing on the website? Another concern is that a lot of people make their first edits by correcting spelling errors etc. while reading, if the app is cumbersome for editing it'll drive away would-be-editors and would mean people who get into 'full-on' editing slowly and gradually are lost since it's a big step to visit the website purely to edit. Could the 'edit' button on the app redirect to the web? Kowal2701 (talk) 20:55, 2 December 2025 (UTC)[reply]
Hi @Kowal2701, thank you for this question. Youāre right that many people make their first edits while reading, and we donāt want the app to make that harder. Some experienced editors have told us they want to be able to make small, quick edits directly in the app using wikitext, while others prefer to be redirected to the mobile web and use VisualEditor. We want to strike the right balance so both groups are supported and are able to execute handoffs seamlessly between platforms. A part of us exploring this problem space is also determining the best approach and timing for sending new editors to mobile web. We want to provide a good user experience.
From a technical standpoint, the app currently sends people to the web for certain workflows, so redirecting the edit button when itās the preferred experience is absolutely possible. At the moment we are gathering existing research on this topic, and early next year weāll reach out to request feedback. Iāll make sure youāre notified so you can participate in shaping the path forward. In the meantime youāre welcome to subscribe to the related Phabricator task where you'll get automatic updates via email and can weigh in along the way. JTanner (WMF) (talk) 22:50, 2 December 2025 (UTC)[reply]
Thanks for the ping. So the app is a reading companion (with fringe benefits like push notifications). That is fine. As I said above, the reading experience is better than browser and I can see the WMF's motivation. Maybe I will end up using the app for reading Wikipedia too :-).
Ideas to evolve readers to editors:
phab:T409603 (as mentioned above) is a priority - put a VisualEditor browser link at the top of the wikitext edit box, and a link back to the app once the edit is completed. As mentioned, the wikitext editor is for experienced editors but it is probably a good idea to show the wikitext when they hit the pencil for responsiveness and so they know that Wikipedia can be edited by them - and after the shock of seeing 2025 wikitext they can retreat to the palatable VE. Or maybe they will give it a go in the app.
There absolutely needs to be a link to a help page, with the forums (on browser, DiscussionTools is essential) and editing documentation. Whether that is Help:Contents or a newly tailored page I don't know.
Somehow, each article's talk page (and what it is for) needs to be easier to find than right at the bottom. Possibly at the top of the collapsed right side bar. I know years ago got the community rejected the software feature for people to report errors and it got removed, but new editors are hesitant to make changes and more likely to ask on a talk page.
Allow users to curate the content in games. After they play, have a "write your own question" link. I have always wanted games for Wikimedia projects, and they are wikis after all. The user supplied content system does not need to be sophisticated.
Given the editing limitations on the app, the community could leave a talk page message for anyone that has edited using the app and not progressed to browser and let them know about browser and its advantages. And how to disable the OS deeplinking (app launching when clicking a link), that is mentioned above.
Put the tagline "the free encyclopedia that anyone can edit" on the landing page. Given the fall in Main page views, I thought it would disappear forever. Anecdotally, the idea that anyone can edit and everyone is a volunteer has never been effectively conveyed.
I am not sure how the new user on-boarding works with the app, but I assume we get them to mobile web efficiently somehow for the dashboard, mentorship etc.
@Commander Keane, hey I meant to reply to this and totally forgot. You wrote, "Allow users to curate the content in games. After they play, have a "write your own question" link. I have always wanted games for Wikimedia projects, and they are wikis after all. The user supplied content system does not need to be sophisticated." They are sort of doing this. Those dates are pulled from Wikipedia:Selected anniversaries. That builds on the scrutiny that all main page sections get for fact-checking and spam-checking. I don't know to what extent it would be good to encourage this, but there might be a way to direct people to that project where they could suggest dates? I believe the WMF's short videos did something similar by leveraging DYK hook facts. Rjjiii (talk) 18:25, 13 January 2026 (UTC)[reply]
Thanks Rjjiii. I did read somewhere that is where they pull the questions from, I didn't expect them to write the questions themselves, or hire a consultant ;-). I played the guess which event happened first and the questions were robotic, mundane, and the difficultly didnāt ramp up (they were really hard to begin with!). A timer, search box and time penalties for hints would add elements of risk and adventure. It seems to be a trend of WMF development that doesn't lean on Wikimedian (human) involvement: the games, the short videos, the current Semantic Search discussion I see you at. Commander Keane (talk) 06:14, 14 January 2026 (UTC)[reply]
Yeah, perhaps an unfair comparison, but Microsoft Encarata's "Mind Maze" let you pick a topic and ramped up in difficulty. I am both hopeful and skeptical about these projects getting more readers and therefore more editors, Rjjiii (talk) 06:19, 14 January 2026 (UTC)[reply]
I used to love Mind Maze! And the small set of words spoken in various languages. I also don't know if games would be worthwhile long term, but I know they will not be good in their current state and approach. I will add there is no need for games to be app-only. Commander Keane (talk) 06:40, 14 January 2026 (UTC)[reply]
@JTanner (WMF), hey sorry for the late reply. (This is my main account; I'm Rjjiii (ii) above on mobile.) I get why the app is valuable and wish you all luck with it. I want to address a specific part of your message because I think it overlooks something: "Several people raised very valid concerns about the apps not fully matching mobile web functionality. This is correct, and we want Web to remain the primary environment for editing workflows that are not supported, or are less than ideal, in the app. For users interested in editing on the apps, we will ensure that easy and intuitive ways to transfer over to the web are available: We want readers to be able to easily use the apps for all the things the apps do well, and lead editors to the web for editing."
One problem with that is that for whatever reasons right now, the mobile app does not render articles the same as the desktop or mobile web versions of Wikipedia. @Kowal2701 wrote above, 'The lead image appears as a banner at the top, and the infobox is collapsed under "Quick facts".' I get the explanation on why this might have been done, but so long as the rendering is different, it's going to result in content that does not look right on the mobile app. Here is a concrete example:
Some images are diagrams:
Diagrams are one case where an editor making decisions is going to be taking into consideration (most likely) the desktop environment first as it is where most people edit, and the mobile web environment second as it is now the main place where people read Wikipedia articles. There are a lot of articles where a diagram makes even more sense as a way to explain the topic than these welding ones. Take the citric acid cycle, which has a great diagram that makes no sense for the mobile app's top image.
This is not the only difference in content choices, but it's one that often sticks out to me when I check things on the mobile app. Take for example, 3 welding articles: Shielded metal arc welding, Oxyāfuel welding and cutting, and Flux-cored arc welding. Their lead images are respectively a photograph, a diagram with embedded text, and a labelled diagram with text in the caption. The photo works great on the app, and the SMAW article has its diagrams in a body section. The two diagram lead images both look a bit weird when the diagram is blown up as the top image. The labelled diagram is better for accessibility, but becomes almost meaningless as the top image.
It's even worse in the cases where a complex diagram and an infobox both make a good introduction to the topic. In the featured article, electron, which is a topic inherently too small to photograph, there is a great diagram of orbitals with a caption explaining in accessible plain text in the infobox. For the mobile app, a reader is shown half the diagram in the top image and the explanation is hidden away in the collapsed infobox.
ā TL;DR
Regardless of the reasons why the mobile app is rendering differently, it's going to result in the mobile app often delivering suboptimal or even broken content to readers who are editing on mobile web or desktop and therefore testing on mobile web or desktop Rjjiii (talk) 18:41, 2 January 2026 (UTC)[reply]
@David10244 (I am not JTanner): in a browser, a websearch is forced down your throat. Every time I open my a browser I see a tantalising Google search bar, why should I choose to click a Wikipedia bookmark? Google summarises Wikipedia's information without making you visit and offers to sell you something all at the same time! (This is sarcasm). The app can also personalise your feed based on previous reading habits, should be smoother for loading and can send you notifications - a sure reason to return. On a mobile device, which includes most readers, hopefully they will launch the Wikipedia app rather than their browser. Having said all that, the app ignores editing in favour of reading. Also, Wikipedia's search is bad and Wikipedia poorly presents information to answer questions. Commander Keane (talk) 00:59, 20 January 2026 (UTC)[reply]
@Commander Keane Hmmm. OK, I see how that might apply to some people... I am not sure why, but I don't like most apps (even though I use them). I said elsewhere that Web sites like Home Depot or Best Buy are perfectly fine for me in a browser, even on my phone, and I find that Home Depot's app (in particular) is slow and badly designed. These companies don't need an app, IMO!
I generally read and edit Wikipedia on a tablet. I can't imagine trying to read OR edit on a phone, although I know that some people do.
Not to discount your answer, and I appreciate it, but for me: My reading habits are pretty random; loading pages is fine (perfectly smooth) on my Android tablet and on my Windows 11 PC; and I get notifications in either place. I think that phone users get notifications now too, and that was a big problem for a long time.
I often do a Web search for topics, knowing that a result from WP will be near the top. I'll read that and/or click on some of the other search results. (When I read WP articles, I get sucked in to editing, then I'll go read VPT, or some Phabricator tickets, or the Help desk questions for fun.)
The Chairman of Wikimedia Estonia commited a personal attack against me on national television
I was adviced to post this issue here, since there's no other suitable place for it.
It's a rather unusual incident that technically occured outside of Wikipedia but is deeply intertwined with it.
Yesterday the chairman of the board of the NGO Wikimedia Estonia Robert Treufeldt talked about my user page on national Estonian television (Eesti RahvusringhƤƤling). The interview in original language can be seen here
Over there he accused me of being a "Sweet figure of Great Russian chauvinism" for hosting a neutrally worded RFC regarding the mention of USSR in infoboxes of Estonians born 1944-1991, as well as my efforts to implement the conclusion.
He was tactful enough to not mention my username, yet he did mention some personal details from my page.
Hasn't he just publicly violated the WP:GF and committed a WP:PA on me? I mean, this behaviour should be unacceptable for any Wiki representative. Should we do something as a community to attract the attention of WMF to this issue, or just let it slide? Gigman (talk) 09:19, 8 January 2026 (UTC)[reply]
This whole situation is absolutely inexcusable from the head of a Wikimedia chapter. A Wikimedia chapter head has zero business publicly advocating for nationalist editors to subvert the Wiki movement. An attack in this manner is an attack on English Wikipedia and the project as a whole. CoffeeCrumbs (talk) 12:40, 8 January 2026 (UTC)[reply]
Calling for specifically Estonian editors to resist "Russian propaganda sources" on English Wikipedia while denigrating the votes of people from being from Canada and Yemen sure as fuck is nationalist. CoffeeCrumbs (talk) 16:06, 8 January 2026 (UTC)[reply]
What you said before was very different, that he was calling on nationalist editors to subvert the Wiki movement, not that he called on Estonian editors to resist Russian propaganda sources (not that this is accurate either) and that his statements were nationalist. LordCollaboration (talk) 16:20, 8 January 2026 (UTC)[reply]
Calling for nationalist editing is subverting the Wikipedia movement, as it undermines our core principles, both as an encyclopedia and as a community editing an encyclopedia. A chapter head should never be acting in this manner. And let's not pretend that he's talking about theoretical Russian propaganda; he's charging specific editors, who he "shames" with their nationality, without a shred of evidence. CoffeeCrumbs (talk) 19:16, 8 January 2026 (UTC)[reply]
Wikimedia chapters are independent from the WMF [28], so realistically I'm not sure how much recourse there can be unfortunately. @Castellum: (which appears to be Treufeldt's Wikipedia account, see this interview with him in which states that he created his account in 2008 (which matches, see [29]) and came to Wikipedia through the activities of his charity Castellum, and that (in google translation) Castellum has become my username), would you like to explain yourself? Hemiauchenia (talk) 13:44, 8 January 2026 (UTC)[reply]
this is something that can probably be brought up to m:U4C given the broadside swipe on a Wikimedian community member (allegedly, given I have not processed the video/audio) and a Wikimedia project (according to the translated article accompanying to the video) by another Wikimedian community member.
Is there a way to have the audio transcribed and translated into English though?
As for a response to this from the English Wikipedia project, probably an open letter may be an appropriate response for now, subjected to consensus of course. ā robertsky (talk) 14:16, 8 January 2026 (UTC)[reply]
There're some news articles and Reddit posts of partial translations that highlight the main details. I can link them here if they're nescessary. Gigman (talk) 19:03, 8 January 2026 (UTC)[reply]
There's an English article that doesn't look promising. Quotes include: "Unfortunately, if you look at who took part in that vote, there were no identifiable Estonian usernames. There was someone from Canada, someone from Yemen," Treufeldt said. In other words, according to him, the decision was made by users who are not familiar with the history of the Baltic states or the Soviet Union. "Behind this rewriting of history are often users who express Russian chauvinistic views and act in alignment with Russian interests," he said, adding that this can be determined from the profiles of users who edit articles. Then he seems to explicitly encourage nationalist editing, which is several steps more than something like "we need more Estonian editors". For example, he also says: Estonia faces difficulties in monitoring Wikipedia because Russia's state-backed resources far exceed the capabilities of local volunteers. "Who would take on the task of ensuring that the 'Estonian version' prevails globally? Competing with Russia in terms of resources is quite difficult". It's a tremendous assumption of bad faith to accuse an editor implementing the result of an RfC of pushing Russian propaganda. Clovermossš(talk)00:32, 17 January 2026 (UTC)[reply]
@Clovermoss And, why should the Estonian version "prevail globally"? That doesnāt sound balanced; it sounds like a battleground. Sadly, I don't suppose that Estonian viewpoints and Russian viewpoints can "get along". David10244 (talk) 23:22, 19 January 2026 (UTC)[reply]
I agree that it's inappropriate for the user directly in the controversy to do that, but other than that it's an acceptable addition. I modified it to make the language clearer and also to explain why Estonians consider this offensive. Szmenderowiecki (talk Ā· contribs) 21:13, 8 January 2026 (UTC)[reply]
I wasn't expecting to find myself being involved in any Wiki controversies, so when I found out that theres a list for them, I added the scandal that I've basically started myself. It was purely out of excitement, but I agree it makes me look like I'm proud of that or seeking for attention here. I should've waited a bit for things to clear up before doing that at least. Gigman (talk) 20:08, 9 January 2026 (UTC)[reply]
I agree with Legoktm, and I highly advise Glebushko0703 to keep this issue confined to an appropriate discussion, location, and venue. The article space is absolutely not the place for this - especially considering that Glebushko0703 is directly involved with said issue. ~Oshwah~(talk)(contribs)21:35, 12 January 2026 (UTC)[reply]
The fact that this "community member" has not yet gotten a permanent block for massive NPOV and other violations is a clear disgrace to English Wikipedia. And I am not speaking about Robert in here. Attacking the messengers is not really a way to go (even as this seems to have been a standard approach towards Estonians, Latvians, Lithuanians, and everyone else who has voiced any opposition to his actions). This topic has so far been covered at least in Estonian, Latvian, Lithuanian, and Belgian news sources, and more seem to be coming. Considering that there are numerous Wikipedia articles with detailed descriptions on the topic of occupation and good references, yet they have been ignored, it should come as no surprise what the prevailing theory is on the topic, as it is becoming increasingly difficult to assume ignorance. To provide an analogy, the current actions could be considered comparable to spreading holocaust denial claims. So again, it should be no surprise how that enrages a lot of people, and I should not need to explain how that violates Wikipedia's core principles. The question is not if an occupation happened or not; obviously, it did. The question is how that is framed. And if academic and legal consensus is different from what is written on Wikipedia, then yeah, that raises questions. Ivo (talk) 18:24, 11 January 2026 (UTC)[reply]
Side note: I doubt that there's any academic or legal consensus (or even discourse) on how Wikipedia should be handling birthplaces in its infoboxes. If we're going by official documents, i.e. primary source -- the birth certificates of the people who were born in the Soviet period, then their official documents definitely say "Estonian / Lithuanian / Latvian Soviet Socialist Republic", see for example the following Latvian birth certificate with the USSR coat of arms on its cover and the birth place being stated as ŠŠ°ŃŠ². Š”Š”Š (i.e. Latv. SSR) (see second line from the bottom on the right side the entry for "republika"). If we'd be using primary sources on Wikipedia, then we'd be misrepresenting what the primary source says if we'd say that person was born in Latvia instead of Latvian SSR. Nakonana (talk) 19:59, 11 January 2026 (UTC)[reply]
If a user starts RFC and subsequently steers the discussion in a way that appears to favour a predetermined outcome, then summarising the result as merely "following wiki policy" does not, at least in my view, reflect the concerns raised during the discussion. Several editors have clearly questioned whether the close was appropriate, and that feedback should not be dismissed.
To clarify my own position: I am not arguing that the birthplace should be labelled simply as "Estonia". It could, as it is short, simple, and correct, but alternatives such as Soviet-occupied Estonia or Estonian SSR[a] could acknowledge the historical context more accurately (it just may not be relevant in all articles). However, using "Estonian SSR" presents a significant NPOV concern.
For Estonians, edits like this are experienced as deeply offensive because they appear to normalise or legitimise a period of occupation and repression and link people to it that were the ones being oppressed. The historical background is well documented in articles such as Occupation of the Baltic states. Estonia lost ca 1/5 of its population during WWII, mostly due to Russia, followed by killings and deportations, and half a century under Soviet occupation. Given this context, it should not be surprising that the topic is highly sensitive for Estonians (as well as Latvians and Lithuanians among others). One would not write "Nazi" into some Jews article, who lived under Nazi rule in a concentration camp. This is that kind of offensive.
When this sensitivity is combined with a pattern of editing by a user who has received multiple blocks and whose edit history contains repeated examples of similar issues (let me just take some examples from a single article: ex1, ex2, ex3, ex4, ex5... but there were also earlies edits like this, that later led to RFC), I do not think it is reasonable to expect individual editors to challenge every instance separately. The pattern is visible, longstanding, and has been raised by multiple contributors over time. In such circumstances, it would seem appropriate for administrators to take a broader view of the conduct involved.
Finally, it is concerning when a user whose editing pattern bears clear marks of consistent POV-pushing asserts that there is clear consensus while simultaneously accusing others of sockpuppetry and violations of Wikipedia rules. This does not help maintain a good-faith environment for resolving an already contentious issue and is partly the reason why this question has gotten so much out of hand. Ivo (talk) 23:50, 11 January 2026 (UTC)[reply]
^Estonia was occupied and de facto incorporated into the USSR from 1944 until 1990/1991, though this annexation, like those of the other Baltic states, was widely considered illegal and invalid by the international community
There were about 23 editors involved in that RfC, if I'm counting correctly. subsequently steers the discussion in a way that appears to favour a predetermined outcome -- are you saying that participants have changed their votes or argumentation because of the things that editor said? The options which they provided in their opening statement did include variants that would not have mentioned the Soviet Union. Their opening statement appears neutral. Furthermore, the active off-wiki canvassing on Reddit and in other media can also be seen as "steering the discussion in a way that appears to favour a predetermined outcome". Nakonana (talk) 00:15, 12 January 2026 (UTC)[reply]
RFCs should not be decided by a simple headcount, as popularity alone cannot override substantial policy concerns. While one position indeed may have attracted somewhat more support, it is not clear to me that this constituted a decisive majority, particularly given that significant NPOV objections were raised and do not appear to have been fully addressed.
Some aspects of the discussion process contribute to my concern. One user, who was even more active in the discussion, even has multiple bans that also point to topic bans and controversial edits on Eastern European topics. It does not invalidate his arguments, but suggests that there may be need for a bit closer scrutiny. And even you don't seem to question that much on actions done by Glebushko0703. I am not an administrator on English Wikipedia nor is this my home wiki, so I am raising these concerns in the hope that some uninvolved local administrators will review the situation and the RFC process more broadly. This is a contentious topic area where extra care may be needed.
The fact that this issue has attracted substantial attention outside Wikipedia reflects how this change is perceived by many as a serious NPOV concern. While off-wiki discussions are not that relevent here, the level of public and community reaction clearly suggests that this is not a minor or purely technical matter and that a more careful examination of neutrality and historical context may be warranted. Ivo (talk) 04:50, 12 January 2026 (UTC)[reply]
And even you don't seem to question that much on actions done by Glebushko0703. That was not related to this topic though? It was about them continuing to cast aspersions against another user, and me (seemingly successfully) advising them to stop their clearly problematic behavior. I don't know how you'd use that against me.
One user, who was even more active in the discussion, even has multiple bans that also point to topic bans and controversial edits on Eastern European topics ā that actually leads us back to what I said earlier: Instead of attacking [this one] user, it is the RFC that you should be challenging. and Even if you'd get this particular user banned for NPOV or whatever, this still wouldn't change anything about the RFC result and what the Manual of Style says. It would just mean that someone else would take on the task [of] "NPOV pushing" (as you seem to perceive it). As long as the RFC is in place anyone could implement those changes without having to expect punishment over it. Nakonana (talk) 19:28, 12 January 2026 (UTC)[reply]
Iāve looked into this situation quite extensively and Iām going to share a view from a Baltic nativeās perspective as someone who understands Estonian. Iām taking into account both the article published on ERR and the one on Digigeenius.
First, accounts that strongly defend soviet SSR talking points have had extremely long Wikipedia editing sessions lately, often many days in a row without any proper breaks, which logically raises suspicions about possible coordinated or manipulated activity.
Second, almost every time someone challenges these accounts or even just expresses a differing opinion, the account holders respond immediately and start accusing others of all kinds of things sometimes in a somewhat degrading way.
Third, users GoodDay and Gigman (Glebushko0703) recently had a discussion where both of them wrote in a very malignant tone about how in retaliation for a series of articles published on Digigeenius they should create a Wikipedia page for the author and how his birthplace would definitely be marked as Estonian SSR and not Estonia. They also added that the journalist was just an attention seeker and working for yellow media which couldnāt be further from the truth. Complaining here about how one person is merely expressing concerns while at the same time attacking a journalist does not put Gigman (Glebushko0703) in a good light.
Fourth, some information that users GoodDay and Mellk spread and that Gigman (Glebushko0703) usually agrees with can be taken as direct russian propaganda. For example thereās a page about the Estonian War of Independence where Mellk among other things changed the aim of the war from defensive to offensive which is a blatant lie and serves a russian narrative. When this was corrected, only one minute later Mellk changed the page back to the historically incorrect version again. Suspiciously fast. Furthermore, later an Estonian Wiki editor RobertRSMN corrected the page yet again until GoodDay came and copied exactly what Mellk had done. After this Mellk started accusing the user of sockpuppetry based on only one comment āRussian troll factory in actionā allegedly because some blocked users had used a similar sentence. When other users mentioned that this was ridiculous Gigman (Glebushko0703) defended Mellk fiercely by insisting āEstonians are quite famous for their IT sector and judging by their actions all those socks were most likely issued by their government.ā Somehow all the opposing comments have suddenly disappeared from the page.
Fifth, in October Gigman (Glebushko0703) suddenly and without any good reason started changing birthplaces to Estonian SSR which was before the RFC post was even created by the user. He also changed the birthplace to the soviet union for people who were definitely born before the soviet occupation, like here. This can be taken by many as direct russian propaganda.
Sixth, the RFC consensus looks quite shady from a Baltic perspective especially when some anonymous users decide how Baltic history should be written while ignoring the official guidelines of the Baltic countries on how a personās birthplace under Soviet occupation must be written: place of birth + Estonia, Latvia or Lithuania. Taking official guidelines into account is especially important now because AI is taking information straight from Wikipedia. The previous rules were completely adequate and had been in place for decades. Nobody had any problems until Gigman (Glebushko0703) started questioning them without any good reason. Therefore, I believe the old rules should be reinstated to calm the situation.
My suggestion is to stop considering how credible journalists and people who are expressing concerns under their real names are allegedly attacking one anonymous user. Before some start accusing me of sockpuppetry I would suggest to have a think first. Perhaps Iām simply a regular person who encountered false information and is expressing a personal view on an issue that matters to most local people. T1blaspotter (talk) 10:59, 12 January 2026 (UTC)[reply]
some anonymous users decide how Baltic history should be written while ignoring the official guidelines of the Baltic countries on how a personās birthplace under Soviet occupation must be written. While it may be entirely acceptable to those from the Baltic states to defer to the 'official guidelines' of said states, I'd have to suggest that were you to look at the broader context, and in particular the pressure that the English-language Wikipedia is coming under from certain quarters, you might get a better understanding of why contributors here are reluctant to hand over editorial control to external powers. AndyTheGrump (talk) 11:11, 12 January 2026 (UTC)[reply]
If we look at the English-speaking world, then the USA (following Stimson Doctrine), among others, explicitly did not recognize the Soviet annexation of the Baltic states, either de jure or de facto. So it is not exactly something that only some non-English speaking countries in Europe state. And most countries (not just the western ones) did not recognize the Soviet annexation de jure but recognized the Soviet administration in the Baltics de facto. This topic has been covered many times, as can be seen in the article State continuity of the Baltic states. People are free to think what they want about it, but this is Wikipedia, and facts should matter more than opinions here. Ivo (talk) 18:55, 12 January 2026 (UTC)[reply]
Sorry, but how did the US de facto not recognize the Soviet annexation of the Baltic states? Did they not include them in maps of Soviet in schoolbooks etc? Did they have ambassies in those countries wether Soviet liked it or not? GrƄbergs GrƄa SƄng (talk) 19:00, 12 January 2026 (UTC)[reply]
official guidelines of the Baltic countries. Imagine that the government of Russia publishes official guidelines that the current events in Ukraine are not to be called "war" but "special operation".........
Wikipedia does not follow official state guidelines of whatever countries. Wikipedia has its own policies. If you want said change, you'll have to argue based on those policies and not on official state guidelines. Nakonana (talk) 19:41, 12 January 2026 (UTC)[reply]
Sorry, but "ignoring the official guidelines of the Baltic countries on how a personās birthplace under Soviet occupation must be written: place of birth + Estonia, Latvia or Lithuania." isn't a problem. It's called presenting facts. I get that the Baltic peoples hate that their countries were overrun by the Soviets. But they were. There simply was no Estonia, Latvia, or Lithuania at the time. Regardless of what comforting lies or technical lack of recognition you might mention. So, yes, we will continue to do so. --User:Khajidha (talk) (contributions) 20:02, 12 January 2026 (UTC)[reply]
What is the point of arguing about the official positions on this, if what some people think is considered way more important? It has been clearly stated that things like "Tallinn, Estonia" are reasonably accurate (while it is indeed true that this lacks some nuances), but if that lack of accuraccy is a problem, then how is that not a problem, that "Estonian SSR" is just as inaccurate as "Estonia"? Solution could be to write Soviet-occupied Estonia. Or are there some people here, contrary to popular belief, who know the state continuity of the Baltic states to be a lie? Where are the proofs? And my birthplace in my passport is listed as Estonia. I understand that some people say this could not be true, but again, where are the proofs? Ivo (talk) 21:57, 12 January 2026 (UTC)[reply]
At least for an average Estonian, the first is perceived as a massive NPOV violation, the second just reflects the reality. No Estonian would claim that there was no occupation. It is common to refer to that time period specifically as "occupation time". That is just like German occupation of Norway, just lasted longer. What Estonians have a problem with is if that is communicated in a way that could leave an impression that there was no occupation and "Estonian SSR" does just that. Three Baltic states were an exception among all other republics of the Soviet Union, but if this keeps on being marked as they were just the same, that is exactly what Russia has tried to systematically promote everywhere (including telling things that Estonians joined voluntarily, life was good etc). That is what makes it an exceptionally contagious topic as people are fed up with lies. Ivo (talk) 23:04, 12 January 2026 (UTC)[reply]
Are there WP:RS that state that Estonians were born in "Soviet-occupied Estonia" rather than "Estonian SSR"? Because, tbh, before stumbling upon this discussion I've never seen anyone anywhere render the Estonian SSR as "Soviet-occupied Estonia". When I Google "Soviet-occupied Estonia" I only get 10.000 results, and on the first page of search results I'm only seeing Wikipedia, Reddit, and Quora. Nakonana (talk) 23:34, 12 January 2026 (UTC)[reply]
References? There is even Soviet-occupied Estonia. There are many ways to set the words here (like Estonians often just refer to that as "Russian occupation"), but that is clearly used.
There are many comments on this page dicussing the editing on Wikipedia. That isn't the problem. It's the incident of the WMF official who attacked on editor on TV who needs to be looked at. I have no idea if that is allowed or not. Guz13 (talk) 18:47, 12 January 2026 (UTC)[reply]
Robert is not a WMF official, and most of what has been stated about what he did is misleading or an outright lie. And those accusations fall into the same pattern where all people who say anything against those changes or voice any concerns get attacked, and often by multiple editors. Ivo (talk) 19:07, 12 January 2026 (UTC)[reply]
According to that page, "Wikimedia Eesti on Wikimedia Foundationi (WMF) ametlikult tunnustatud haruorganisatsioon Eestis (inglise chapter). Wikimedia Eesti on iseseisev Ć¼hendus ega kuulu ametlikult Wikimedia Foundationi koosseisu, kuid saab oma tegevusteks WMF-lt raha taotleda". I don't read Estonian, alas, but Google Translate gives, "Wikimedia Estonia is an officially recognized branch organization of the Wikimedia Foundation (WMF) in Estonia. Wikimedia Estonia is an independent association and is not officially part of the Wikimedia Foundation, but can apply for funding from the WMF for its activities". Phil Bridger (talk) 20:48, 12 January 2026 (UTC)[reply]
Editors opposed to this change would do better if they stop making aspersions and challenged the RFC that decided the matter. It wasn't decided by one editor, nor russian agents, but by consensus of that RFC. -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°20:27, 12 January 2026 (UTC)[reply]
If you think the fault here lies with Wikimedia Estonia, this might be an issue for the m:Affiliations Committee
All that said, you should carefully consider the responses here. While you'll probably feel attacked by some of what's said here, it's important to stop and consider what people have said about your actions. It's hard when you feel unfairly criticised, but it's important if you want to learn from what was said and find a good resolution. Guettarda (talk) 23:53, 12 January 2026 (UTC)[reply]
Glebushko0703 actions have been to implement the results of a RFC, that they didn't start, where multiple other editors agreed with them. Those opposed to them have made multiple unsubstantiated aspersions about them in this very thread. So I could understand if they felt unjustly criticised. The suggestion of taking this to UCOC or Arbcom or a good one, but as they've resolved the content matter by RFC DRN is an odd suggestion. As to taking it to etwiki, many of those casting aspersions in this thread are from etwiki, so I suspect that their request to stop being attacked would fall on deaf ears.
There are plenty of examples provided here and elsewhere (that keep on getting ignored). The user in question got his first ban in October for edits like this. More bans followed for personal attacks and disruptive editing. There is a pretty clear pattern of POV pushing starting from edits like this (that predates birthplace infobox question) and later getting to article content question (like). (And this doesn't just involve Estonia, an early example) This user was not even that active, until he discovered this topic. Ivo (talk) 02:59, 13 January 2026 (UTC)[reply]
None of that changes that the RFC decided the change to how birth places would be listed, not Glebushko0703. That they implemented those changes inline with consensus is not an offence. If you think an editor is engaged in disruptive editing you should take them to an appropriate forum, possibly WP:ANI. -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°03:07, 13 January 2026 (UTC)[reply]
Even that closer wrote there that "In my opinion, an explanatory footnote would be helpful in flagging for readers the complexity of nationality in these circumstances." And that is exactly what has been missing and what Glebushko0703 has been fighting against. So you're slowly getting to the point why this approach has been so much contested: the plain "Estonian SSR" is viewed as misleading (and by many people also as very insulting... thus the NPOV issue). There was only an option of Estonia vs the Estonian SSR, but both of them could be considered equally misleading. Ivo (talk) 04:18, 13 January 2026 (UTC)[reply]
So they tried to change the birth place to Estonia SSR and where reverted, discussions were had and a RFC held. The RFC result was discussed and implemented. A explanatory note was added, it was reverted, so has there been a discussion or any attempt at WP:Dispute resolution? Because it appears one was done the right way, and the other has been met with aspersions. -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°12:48, 13 January 2026 (UTC)[reply]
Also whether people are insulted or upset is not part of the WP:NPOV policy. I think you're mistaking editors having a POV, which is true of all people regardless of where they come from or who they are, with the result of a discussion to resolve what the consensus was on a dispute matter. -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°12:58, 13 January 2026 (UTC)[reply]
An affiliate chapter head actively going on national television to attack a Wikipedia editor for involvement in an RfC (no matter what the involvement is and no matter what the RfC is about) is completely and utterly inappropriate. Robert Treufeldt should be removed as chairman of the Wikimedia Estonia board. And if the board refuses to take such an action, then Wikimedia Estonia should be removed from inclusion as a Wikimedia affiliate entirely. SilverserenC03:59, 13 January 2026 (UTC)[reply]
Absolutely none of that is, or should be, within the purview of editors on the English Wikipedia. If you think the Wikimedia Estonia board should take some action then you need to contact the board of Wikimedia Estonia (links to their contact details have been posted in this discussion). If you think Wikimedia Estonia should be removed as a Wikimedia affiliate then you need to contact the m:Affiliations committee. Thryduulf (talk) 04:08, 13 January 2026 (UTC)[reply]
I also recommend reading the discussion first, or at least getting to know what was actually in the interview, as what has been written here about that is massively misleading. Ivo (talk) 04:22, 13 January 2026 (UTC)[reply]
Then explain it, KruusamƤgi. Did the head of Wikimedia Estonia go on national television and accuse a Wikipedia editor (of literally anything really, it doesn't even matter what the accusation was about) of some claim of malfeasance over an RfC on a Wikipedia talk page? SilverserenC04:32, 13 January 2026 (UTC)[reply]
Short answer: no he did not. This is also not about some user implementing the RFC decision, but about an obvious pattern of POV pushing that started well before the RFC was even made, and what has gone lot further than that. More context is provided by previous comments, and it may not be reasonable for me to repeat that. Blaming a fellow Wikipedian, who explained on television how Wikipedia works, is not nice. So please let's stop that. Ivo (talk) 04:54, 13 January 2026 (UTC)[reply]
Unless we are suggesting the reporter made up the "Tegu on, vƵime ƶelda, suurvene Å”ovinismi maigulise tegelasega" quote, then we should probably assume it was said by the individual interviewed. I find "explained on television how Wikipedia works" to be a deeply euphemistic description of that interview, at best. CMD (talk) 05:12, 13 January 2026 (UTC)[reply]
I don't think that its helpful to think of this issue in terms of "sides". Yes, the occupation of Estonia by the Soviet Union, and its incorporation into that country were illegal, but they happened. We should not attempt to right great wrongs by denying that it happened and that the world was largely indifferent. Phil Bridger (talk) 13:40, 15 January 2026 (UTC)[reply]
I am asking specifically about the incident. What does the editor say happened and what does the chairman of Wikimedia Estonia say happened? Guz13 (talk) 21:16, 16 January 2026 (UTC)[reply]
As I understand the timeline, the statement came not only after the RfC was closed but also after post-close discussion had concluded. Thryduulf (talk) 17:38, 13 January 2026 (UTC)[reply]
I would say the correct value to complain is WMF T&S. This venue is not public; any public discussions of the issue very quickly turn counterproductive as we can see here.--Ymblanter (talk) 23:46, 13 January 2026 (UTC)[reply]
Correct me if Iām wrong, but anecdotally speaking I feel like wikis inlanguages spoken in only one country as the national language tend to suffer from nationalism-related issues for very obvious reasons. English is the most cosmopolitan language on the planet so it doesnāt really have this problem. --Dronebogus (talk) 11:18, 14 January 2026 (UTC)[reply]
Less, anyway. But you have a point: "Haaretz journalist Omer Benjakob said in 2023 in relation to the IsraeliāPalestinian conflict that "Unlike many Wikipedias in languages with a global span, like English, Spanish or Arabic, Hebrew Wikipedia resembles its Polish or Hungarian counterparts in being more of an "Israeli Wikipedia." It can be seen as having an implicit pro-Israeli bias."[1]" GrĆ„bergs GrĆ„a SĆ„ng (talk) 11:23, 14 January 2026 (UTC)[reply]
Yes, that is certainly true. Technically Wikimedia Estonia has nothing to do with the Estonian Wikipedia (one pertains to the country; the other the language) but it in fact very nearly owns it. Phil Bridger (talk) 14:17, 14 January 2026 (UTC)[reply]
FWIW - Before the RFC was even held, there were/are already hundreds of Baltic bios with "city, xSSR, Soviet Union" in their infoboxes. So the RFC basically re-affirmed something already established. GoodDay (talk) 13:49, 14 January 2026 (UTC)[reply]
Before Gigman's implimentations, the inertia was already toward "city, xSSR, Soviet Union". A couple of examples are the NHL & NBA player bios. GoodDay (talk) 16:27, 28 January 2026 (UTC)[reply]
Any proof? Baltic NHL & NBA players born during the occupation period are a VERY TINY subset of all related biographies and should not be used as an example of any "inertia". Most Estonian biographies did not reflect this. - Neptuunium (talk) 17:08, 28 January 2026 (UTC)[reply]
At Friday's meeting, representatives of the Government Office and the non-profit organisation Wikimedia Estonia will map the possibilities of protecting Estonian history from the counterfeits contained in Wikipedia.
In the English Wikipedia, the cyber villain has changed the birthplaces of many well-known Estonians by writing to: Tallinn, Estonian SSR, Soviet Union.
I would just like to ask if this is the sort of thing the WMF allows and endorses? And by "this thing" I mean foreign governments removing/changing what they consider "counterfeits" (machine translation) from Wikipedia.
If this is allowed to happen, Wikipedia can no longer claim editorial independence, and it becomes a mouthpiece of various governments. I guess it was bound to happen sooner or later. TurboSuperA+[talk]09:37, 18 January 2026 (UTC)[reply]
Please don't make everyone guess what the point is. Yes, you gave a link but also outline who/what made the quoted statement and in what context. Johnuniq (talk) 09:52, 18 January 2026 (UTC)[reply]
There are also a couple of ongoing RfCs that followed on from the one that prompted the interview on national television, on roughly the similar topic. CMD (talk) 10:24, 18 January 2026 (UTC)[reply]
The point is that the Government Office in Estonia (presumably at the direction of Kaja Kallas) had a meeting with a WMF affiliate (Wikimedia Estonia), where they discussed ways to influence Wikipedia content (presumably circumventing the normal editorial processes). Is there a way for WMF to ask for the minutes of that meeting from their affiliate? Which "possibilites", if any, have they "mapped" at this meeting? Are there going to be further meetings?
Why is the government of Estonia trying to influnce the English Wikipedia via an intermediary (Wikimedia Estonia)? To me, these seem like reasonabke questions to ask. TurboSuperA+[talk]11:27, 18 January 2026 (UTC)[reply]
Why is the government of Estonia trying to influnce the English Wikipedia via an intermediary (Wikimedia Estonia)? Probably one or both of (1) they think Wikimedia Estonia is a branch of the WMF rather than an affiliate or (2) they think they can more easily coerce Wikimedia Estonia as it's in-country. You also seem to be assuming that the WMF will go along with the Estonian government's demands; if they do at all, it would likely only be in connection to pursuing the matter in relevant courts (cf. the ANI case). Anomieā14:53, 18 January 2026 (UTC)[reply]
While this may be true in some situations, it seems very high-level and doesn't grapple with potential second order effects. The government may be trying to do it because it may work. You can stir up enough people in a niche area to result in consensuses more to your liking, even if the WMF does nothing. CMD (talk) 16:06, 18 January 2026 (UTC)[reply]
At that point you're getting pretty far away from Wikipedia can no longer claim editorial independence, and it becomes a mouthpiece of various governments though. And in such a situation WP:LOCALCONSENSUS may be applied where it couldn't in response to an WP:Office action. Anomieā16:29, 18 January 2026 (UTC)[reply]
I don't disagree with that point on specific wording, but it might not be as far away as we'd like. The development of a localconsensus could reward an influence campaign as it could impede it, it is a tool within our system with its benefits and flaws. CMD (talk) 16:43, 18 January 2026 (UTC)[reply]
But have you got any evidence that any of this will happen? So far we have one newspaper saying that the Estonian government and Wikimedia Estonia will "map the possibilities". It's possible that they will decide to do nothing. Phil Bridger (talk) 16:24, 18 January 2026 (UTC)[reply]
There has been some speculation in this discussion that merits clarification. Over the past few months, a number of disputed changes have been made on the English Wikipedia, and they are not limited to birthplace wording alone, and several of these changes closely mirror well-known Russian state narratives. Some relevant diffs have already been provided in this thread. In that context, it is reasonable to raise concerns about whether Wikipedia may be vulnerable to organized narrative-pushing or disinformation efforts. This would not be unprecedented (see, for example, the Croatian case). These concerns help explain why the issue has attracted attention from the media, the general public, and Wikipedians from the affected countries.
The position expressed by the local chapter has been that the matter would be resolved within Wikipedia's existing processes and that there is no reason to get involved. While Estonian Wikipedians and chapter representatives are clearly dissatisfied with the underlying issues, the situation has also prompted broader public discussion about the edit histories and the transparency they provide. Ivo (talk) 22:41, 18 January 2026 (UTC)[reply]
it is reasonable to raise concerns about whether Wikipedia may be vulnerable to organized narrative-pushing
Indeed! Now is a good time to ask. Were you, as managing director of Wikimedia Estonia, present at the meeting with the Estonian Government Office on Friday, January 9th? [31] What was discussed at the meeting? TurboSuperA+[talk]22:54, 18 January 2026 (UTC)[reply]
I did not attend the meeting in person, but participated virtually. From the state side, the main question was whether there are signs of coordinated narrative-pushing, and what responses would be appropriate if such activities were to be identified. From the chapter, the focus was on explaining how Wikipedia works in practice and how it could be supported more effectively, particularly concerning the Estonian Wikipedia, where, due to the small population of Estonia, it is difficult to cover all topics needed. Some state support could go a long way to increase the quality in areas that otherwise lack editors, and allow more training for people who could make meaningful contributions in the future.
One plan is a broader review of how Estonia-related topics are covered across different language editions, as smaller Wikipedias are even more vulnerable to capacity constraints and systemic issues than the English Wikipedia. We could also try to involve some specialists who could help to review content quality on more complex topics. And there is increased interest in general Wikipedia monitoring and anti-vandalism work, as there are concerns that current capacity in Wikipedia might be stretched too thin, especially while acknowledging that development in LLMs has made it easier to generate seemingly believable text that could make it harder to notice content manipulations and easier to vandalize on scale. Ivo (talk) 23:48, 18 January 2026 (UTC)[reply]
Thank you for your response. I hope you can see how it can be worrying that a State's government is taking interest in how Wikipedia's topics are covered. There is no such thing as a "neutral narrative" and every POV is subjective, which is why we have WP:NPOV. I'm sure you would raise an eyebrow if the government of Russia had meetings with Wikimedia Foundation affiliates asking how edits that they consider to be "counterfeit" can be fixed.
Re: Croatian Wikipedia, the report doesn't mention "coordinated editing", but The evaluation concluded that Hr.WP had been dominated by ideologically driven users who are misaligned with Wikipediaās five pillars The Croatian case was what put Wikipedia on my radar beyond the common understanding of "oh that site where you can look up info quickly", as I mainly used en-wiki and never hr-wiki. The ideologically driven users were fascists who did things like writing that Ante PaveliÄ was merely a "statesman" (rather than a Nazi collaborator), and sanitising articles like Jasenovac, while adding negative epipthets to communist subjects of articles. One doesn't need to coordinate with others to make those kind of edits, editors who follow the same ideology and subscribe to the same narrative about Croatia in WWII will make those kinds of edits.
What you call possible coordinated editing could just be users who also subscribe to the same narrative re: Baltic SSRs. Age could also be a factor, older editors would stick to what they learned in school, while the Soviet Union still existed, while younger editors born after the dissolution of the SU would not have learned the same things. Same is true for the opposite case. I would venture a guess and say that every Estonian editor voted the same in the aforementioned RfC. That doesn't mean they are coordinated and receiving instructions from a single source, it is just a reflection of the dominant narrative in Estonia.
Why should the Estonian government have any influence over the Estonian Wikipedia? The former governs a territory, whereas the latter is based on language. The are plenty of people living in Estonia who don't speak Estonian (mainly the dreaded Russian speakers) and plenty of Estonian speakers living outside Estonia. Phil Bridger (talk) 10:15, 19 January 2026 (UTC)[reply]
Historically, Russian state-sponsored disinformation campaigns have been rather common. And to people not familiar with Wikipedia, "someone making hundreds of edits" sounds very different than to a Wikipedian. This is also why we have tried to explain to the media that this does not mean there is some Russian state hand behind that (even while the edits themselves are clearly problematic... just that there are other explanations, as there is no lack of people holding that kind of worldview in Russia... and this also explains where this "cyber villains" comes from... even as "kĆ¼berpahalane" means more like "cyber vandal" or "cyber baddy").
It would also be important to distinguish between different points of view and clear BS. Just like with this Croatian case, some kind of edits would be clearly problematic and could not be whitewashed with claims that neutrality requires those other claims to be just as prominent. When we would write about the shape of the Earth (to give a very banal example), it might be necessary to mention that there have been some people who have believed in a flat Earth, but there is no sane way to justify that this worldview needs to get the same level of attention as the dominant scientific worldview.
In here, it might also be necessary to explain that in most of Europe, people trust the state. This is not the USA or Russia, where some crazy despot is running the show. For that same reason, "cooperating with the government" has a very different meaning. Like, we are not talking about giving the Estonian government influence over the Estonian Wikipedia or sth. That would be utter nonsense. Ivo (talk) 22:59, 19 January 2026 (UTC)[reply]
I suggest treating like any other POV push whether that's from Russia, India, the US, the UK, or any other country. Be aware but otherwise ignore them. People shouting, screaming, and otherwise having a hissy fit is no way to go about changing the encyclopedia. If they want to talk part in discussion and present their views and sources there are many ways they can do so. -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°19:44, 20 January 2026 (UTC)[reply]
The national media is handling this because the process failed spectacularly on the Wikipedia side. Considering that even in this discussion, a lot of people have failed to notice what the POV push was actually about, it is difficult to be optimistic. Recommendation would be to avoid writing comments about what one does not know anything about. Assumptions are not a good guide, and here we can see a lot of them. Ivo (talk) 17:17, 21 January 2026 (UTC)[reply]
More like "those nasty Wikipedia editors failed to check sources or even look at what the discussion was actually about, and due to that, messed up really badly". But yeah, you just proved my point by totally missing what this has actually been about and failing to check any facts. There is no point in telling how Wikipedia is all about sources and neutrality and stuff, when in reality it is just about what someone thinks who does not even bother do any basic background checks. Ivo (talk) 20:28, 21 January 2026 (UTC)[reply]
I'll ask you to be more restrained to other editors here (including me). I've seen enough bad faith assumptions and aspersions casting coming from you and it's not helping this discussion. Gigman (talk) 14:47, 25 January 2026 (UTC)[reply]
The user who created the thread is asking if they can take legal action: Is there any legal action I can take against Wikipedia for refusing to rectify this? Granted, it can be difficult for subjects of articles to understand how to get things updated that they believe can be proven to be inaccurate. --Super Goku V (talk) 06:40, 28 January 2026 (UTC)[reply]
If he was then he was making even more of a mistake than some people are making in this thread. Russians had no more say over what happened in the USSR than Estonians. Phil Bridger (talk) 21:37, 28 January 2026 (UTC)[reply]
As a Latvian editor, let me explain this in a more nuanced way: this might be a reaction due to the constant stream in many languages from the Russian state-sponsored propaganda machine, which in recent years has been either breathing new life in to unsubstantiated claims that the Baltic states 'joined the USSR voluntarily' and also trying to muffle the term of the restoration (not declaration) of independence in 1990/1991, which also muffles the story of the 3 states being de-iure recognized by a large part of the international community.
The minimization of this nuance, as I'd put it, is what probably led this person and others in the Baltic states to feel like all of this is being denigrated. And, with reports that this is apparently happening in a widespread scale, doesn't help. Ivario (talk) 10:50, 29 January 2026 (UTC)[reply]
On a first read very few details of the partnerships seem to be given. I just hope that it has been remembered that the WMF does not own the copyright to Wikipedia, so doesn't have the right to give it away or sell it. Phil Bridger (talk) 19:40, 15 January 2026 (UTC)[reply]
It can't sell the copyright, but it can sell the content. Anyone can. Our license allows for commercial use and that is a feature of this great project. That's not really what Enterprise is doing, though. It's simply providing a more efficient way for these companies to access the content they're using anyways. Toadspike[Talk]20:25, 15 January 2026 (UTC)[reply]
Those companies, whatever you think of them, are taking Wikipedia's content anyway (and can't be stopped from doing so). As far as I can tell this is simply a way to persuade them to pay for what they are already taking by giving them access to more efficient tools. Mike Christie (talk - contribs - library) 00:15, 16 January 2026 (UTC)[reply]
I'm not sure "Wikipedia inks AI deals with Microsoft, Meta and Perplexity as it marks 25th birthday" is a very good headline for us. I don't really want the public to associate us with either AI or big tech, nor to associate our 25th birthday with these things. āNovem Linguae (talk) 05:54, 16 January 2026 (UTC)[reply]
I don't really want the public to associate us with either AI or big tech -- Wikipedia has been preferred by Google in search results for many years now, that's why Wikipedia is the encyclopedia and not Everipedia or Citizendium or any of the others. That's why the others can't compete. Also, Wikipedia is preferred by Siri (Apple), Alexa (Amazon), and all the LLMs. "Big tech" has donated hundreds of millions of dollars and given us the monopoly on search results in almost every search platform in use. I'm sorry to break the news: Wikipedia is part of big tech, it only exists because of big tech, and it would not exist without big tech's support. And why do you think big tech supported Wikipedia all these years? Because they use it to make money. LLM is just the latest iteration of that, but they used Wikipedia to make Google search, Siri, and Alexa better, too. We are volunteering to write content that is sold by big tech to the world. That's what we've been doing for 25 years, FYI. Levivich (talk) 16:51, 22 January 2026 (UTC)[reply]
...Oh, and if we want to change that, we should change the license from WP:CC-BY-SA to CC-BY-SA-NC, but the community so far has been against doing that. Perhaps because the community realizes that Wikipedia wouldn't survive if big tech couldn't sell our content for profit. Levivich (talk) 16:55, 22 January 2026 (UTC)[reply]
Agree with some others above that while the core idea behind Enterprise is reasonable, the timing is very odd, especially given the importance that brand management seems to have. CMD (talk) 06:06, 16 January 2026 (UTC)[reply]
The timing of this is terrible. With all the terrible decisions the WMF has been making recently, I'm nearly convinced they're either trying to kill wikipedia or are being run by people who see us and our work as free labor for their big tech buddies. Is there any way for a wikipedia to break ties with the WMF? I think it's clear they don't have our best interests in mind mgjertson (talk) (contribs) 15:25, 21 January 2026 (UTC)[reply]
This misrepresentation of our values to the public is frustrating, but certainly does not rise to the level of breaking ties over. Let's turn down the temperature a bit. āNovem Linguae (talk) 16:25, 21 January 2026 (UTC)[reply]
The rollout of TAs proves that they aren't interested in communication or a better encyclopedia, they care about their survival as an organization above all else mgjertson (talk) (contribs) 19:19, 26 January 2026 (UTC)[reply]
well it's either that the WMF sells them API access and makes a couple of bucks or they scrape all of Wikipedia manually and cost the WMF a bunch of money
Very, very bad timing to make this announcement now. The message on W25 should have been the human aspect of Wikipedia, not "AI!!!". Some very worrying statements in that AP article as well.
"While AI isnāt good enough to write Wikipedia entries from scratch, it could, for example, be used to update dead links by scanning the surrounding text and then searching online to find other sources." Please no! At worst post such things to the talk page, but don't let AI loose on articles to add sources. There is no guarantee at all that these would be good sources for the content and not unreliable ones, citogenesis ones, or hallucinated ones. Fram (talk) 09:58, 16 January 2026 (UTC)[reply]
On second and third reads I still can't see any details of the partnership agreements. If the WMF wants to avoid wild speculation about what may be in them then it should be transparent and publish the agreements. If "commercial confidentiality" prevents that then they shouldn't have been signed. Phil Bridger (talk) 11:48, 16 January 2026 (UTC)[reply]
Hi @Phil Bridger. I've got an response in the FAQ page about "what's in the contracts?", if you're interested. Short answer is quite practical things like duration, jurisdiction, uptime/SLA obligations. Many of the things which normally go in such contracts like copyright or content-quality guarantees are not there becuase WMF doesn't own the copyright or have editorial control over the content. This is just part of why it's not a content license but a service contract for access to a high-speed pipeline of data.
Significantly, is the fact that the mainstream media frequently misrepresent and simplify this to being a "licensing" deal. It is not.
As mentioned by many - the content is already licensed freely, and as a consequence WP content is used to train LLMs already (as we all know). This announcement refers to these companies now being customers of the high-speed/volume API service - where they can obtain the same Wikipedia (and sister projects) content, but in a metadata structure more tailored for repurposing (and with Service-level agreements about uptime etc). The API is open source, and the feed is also available for free, for anyone, as per our culture and principles. Moving high-speed/volume users over to this "enterprise grade" service helps address the issue of heavy-impacts on the public infrastructure by crawlers bots. So, now major AI companies can pay for their own heavy usage, rather than being subsidised by our donors. The water's the same, but they're paying for a dedicated pipe - freeing up space for the general public who want to draw water from the well.
Moreover, having these formalised relationships now also means we can have a more proactive conversation with major external reusers of content about such issues as consistent attribution.
And whose idea was it to make this the big announcement for the 25th birthday? It feels disrespectful to your editors and like bad PR to your readers. Fram (talk) 14:26, 16 January 2026 (UTC)[reply]
"one paragraph within a much longer press-release", one of the three subtitles, and one of the two things highlighted by the WMF right at the top ("New video docuseries celebrates the humans who make knowledge on Wikipedia possible; new tech partnerships highlight Wikipedia's value in age of AI."
But I see you also did this: "In honor of this milestone, we interviewed a few volunteer editors from around the world about what moves them to contribute to Wikipediaās pages. " Surprise, the co-founder, who hasn't done any "volunteer editing" worth mentioning in the last decade or so (in a positive way at least) is one of the 8. Again, quite a show of respect for actual editors. Fram (talk) 14:46, 16 January 2026 (UTC)[reply]
Not trying to be aggressive with this point, but it would be helpful for communication to get less boilerplate responses on this noticeboard. No concerns were raised above about this being a "licensing deal". The only mention of licensing was that this action was explicitly permitted by our licence. Meanwhile, an issue that was raised multiple times was not addressed before a follow up question. This gives off the impression, whether true or not, that the existing discussion has not been read or engaged with. CMD (talk) 15:35, 16 January 2026 (UTC)[reply]
Hi @Chipmunkdavis. I didn't mean to come across as "boilerplate" - especially since I wrote that response specifically in the edit window on this page (not copy-pasted from some pre-prepared list of replies) so it is literally the opposite - a bespoke response! And yeah - I've seen a lot of media (and subsequently people reading about the project via that media reporting) referring to this as a 'licensing' deal, so I'm predisposed to notice and react to that critique!
If you're noting that the core concern raised in this comment thread is one of timing rather than content of this announcement... Well:
The reason for the timing is that - as per the naming of customers policy of the WMF - We WANT to name all customers (transparency) but cannot always do so (privacy). The fact of this birthday milestone meant there was an opportunity for all of these organisations also wanted to be able to show their long-term support for Wikimedia - both to financially support it, and technicaly to ingest the content in an ethical/official way. So, this was an excellent moment for them them all to do so, simultaneously.
It is not the 'only' or 'biggest' part of the press-release, nor the most important part of the birthday celebrations - but it is the thing that some (not all) journalists chose to highlight. I've been collecting a list of the news articles that focus on this story over on the 'enterprise' talkpage, but there are many other news stories which discuss other aspects of the 25th birthday celebrations. LWyatt (WMF) (talk) 18:38, 16 January 2026 (UTC)[reply]
It's big news. Although, as has been clarified, this isn't a licensing deal, who and for what AI companies are paying is being heavily litigated and closely watched. voorts (talk/contributions) 01:26, 17 January 2026 (UTC)[reply]
If these are simply purchases of the WMF's Enterprise package then that's fine. The word "partnership" confused me, but it seems that any deal that was done in the last year or two is a "partnership" and somehow linked to our 25th anniversary. This is just marketing hype. Phil Bridger (talk) 17:44, 16 January 2026 (UTC)[reply]
Yeah, "partnership" is just common vocab for this kind of thing. But moreover it's actually an attempt to point out that this isn't a question of a one-time payment for a product (merely a temporary and transactional thing). It's actually building long-term relationships where external organisations have contractually engaged in the development and use of this infrastructure. This is more than just revenue - this means that we can now talk on a regular basis with their engineering teams about, for example, how attribution could be improved. This is about moving from our historical basis of agnosticism of reusers - knowing that big-tech use our content but not overtly assisting them to do it "well" - to being proactive in getting them to [financially and technically] invest in doing so in a sustainable manner. This helps their customers to get access to attributed Wikimedia content accurately. Ultimately, it is in their interest that our content is diverse, up-to-date, cited, accurate, and available in their user's native language.
So... although "partnership" is a wolly word, it is indeed more accurate than merely calling them "customers" - even if that nuance doesn't come across in a press-release or news-story. LWyatt (WMF) (talk) 18:24, 16 January 2026 (UTC)[reply]
Do you really think that the owners of these companies see us in any more than transactional terms? When I was working for various software companies I spewed the party line that deals were partnerships, as you have to, but I knew that they weren't. Phil Bridger (talk) 19:50, 16 January 2026 (UTC)[reply]
In more concrete terms, it could be amazing if we were now able to get concrete reassurances regarding issues like attribution. We do see them as partners, but we want guarantees that this goes both ways and that they're actually willing to negotiate something there, rather than just saying that for the sake of signing a contract. Chaotic Enby (talk Ā· contribs) 00:03, 17 January 2026 (UTC)[reply]
They don't do attribution for clearly copyrighted work, nothing indicates that they will do any attribution for Wikipedia. They pay to get easy access without bringing down our servers, that's about it, and in return they get major headlines on what should have been a celebration of 25 years of volunteer-driven content dissemination (Wikipedia, Commons, ...), and give many people outside Wikipedia the wrong impression that Wikipedia has capitulated for AI as well. Fram (talk) 10:12, 19 January 2026 (UTC)[reply]
I think it's a good thing these deals were made. If they're going to be using our content anyways, might as well have them pay for it. I am a bit curious as to how much these companies are paying for access however, though I suppose that would be revealed in the next financial report. ARandomName123 (talk)Ping me!07:57, 17 January 2026 (UTC)[reply]
The comments I've seen online from Wikipedia's user-base and donors?...they are really really not happy. There is a lot of anger about this partnership or whatever you want to call it. And maybe it looks great and is great and yes all these companies are taking the WP content anyway (that we all create and have created), but people feel betrayed and oh MAN the optics sure do suck. - Shearonink (talk) 02:09, 18 January 2026 (UTC)[reply]
@Shearonink, This is less optics, more survival. The alternative to the partnership (which as mentioned above is just a Wikimedia Enterprise subscription where they give Wikimedia money to offset the load caused on our servers at a high level) in this context is to have significantly degraded experience as these AI companies scrape Wikipedia's content for profit anyway while decimating our bandwidth to serve actual humans. Atleast this way, we can tell me "dude, if you scrape anything on Toolforge.org, we are kicking you out of the subscription". Sohom (talk) 00:36, 19 January 2026 (UTC)[reply]
I think WMF needs to be careful with its PR strategy. The kind of messaging that will generate Wikimedia Enterprise clients may not be the same kind of messaging that will present our values correctly to the general public. Headlines such as "Wikipedia inks AI deals with Microsoft, Meta and Perplexity as it marks 25th birthday" plant a seed in the public's mind that we are all about inking deals with big tech and embracing AI, which I would argue are probably the opposite of our values. āNovem Linguae (talk) 02:15, 19 January 2026 (UTC)[reply]
Yes and no. I see better where you are and can agree that the PR should have been handled better and WMF should take this as a bit of a learning experience, but we also need to keep in mind that TechCrunch in particular (and many journalists in this industry) are "AI-pilled" and have a interest in reading text to be more favorable towards big-tech/AI. Misrepresentation/over simplification is not uncommon even amongst the best RS in the tech industry (I say this as somebody who has written articles about tech, even on a best day, I've found blogposts that are often more factually accurate than what Tech RS churns out). Sohom (talk) 11:04, 19 January 2026 (UTC)[reply]
TechCrunch (which operates in the startup space) is not known for being AI-critical at all. The first article I can see on their site is [32] which needs to be much much more critical of AI, similarly, the journalist that wrote the Wikipedia piece has also written [33] which hides Alexa's AI agent's failing in one small sentence at the end that is immediately followed by a Amazon statement that the complaints are overrepresented. Sohom (talk) 22:51, 19 January 2026 (UTC)[reply]
Because AI is the current moneymaker and that is the point of running a business. Shareholders have eaten the AI hype hook line and sinker. Journalists can't afford to be critical to it mgjertson (talk) (contribs) 19:23, 26 January 2026 (UTC)[reply]
I get all that, but the optics, the PR, are bad. Go read some of the general public's comments, like at the TechCrunch article and elsewhere and take them all in. People areupset. Wikipedia's supporters are upset. Our donors are upset. - Shearonink (talk) 03:16, 19 January 2026 (UTC)[reply]
The timing is just awful and shouldn't have been included in the 25th anniversary event at all. It's causing a large amount of the public to consider Wikipedia to now be taken by AI companies. Even when that's not true, the optics are as such. Whatever marketing person decided this should be at all done now is terrible at their job. SilverserenC18:58, 19 January 2026 (UTC)[reply]
Hi Silver,
As I wrote above, the fact of this birthday milestone meant there was a positive opportunity for all of these organisations who wanted to be able to show their long-term support for Wikimedia - both to financially support it, and technically to ingest the content in an ethical/official way - to do so. So, this was an excellent moment for these companies to do so. As per the naming of customers policy of the WMF, transparency of these names is something we consistently push for (and is a frequent [and very valid!] request from the community), so getting their simultaneous consent to be named publicly was great. It is my professional opinion that it would not have been possible to get permission for naming most of these new names outside of the context of the birthday. Believe me, we tried.
It is not the 'only' or 'biggest' part of the birthday press-release, nor the most important part of the birthday celebrations, but it is the thing that some (not all) journalists chose to fixate on. Which is - as people have pointed out here - not desirable because the focus should have been on the knowledge itself, and the volunteers who curate it. In the end I feel we have a bit of a "damned if you do, damned if you don't" situation where two ideals partially conflicted: transparency (of the finances) and clarity (of the message).
But more fundamentally, while it is understandable that the general public might not grasp the nuances of free-licensing (which meant that all Wikimedia content was already being used in AI/LLM training for commercial purposes without needing further permission), some of the articles I've seen misrepresented the fact of this API service with the outright falsehoods of this being a licensing deal. WMF Comms team have done a valiant effort in successfully request some of the worst-offending and highest-visibility news stories be fixed. Much like the work that goes on at WP:Redirects for discussion, the results of that tiring work is often invisible to the end-user.[34]
I hope this comment helps explain how/why this announcement occurred at this specific time, and that overall you feel that the benefits outweigh that concern: We can now say to the world that big-tech is indeed "paying their own way" for their heavy infrastructure cost and investing (financially and technically) in our long term existence (and improved attribution, improved information-integrity of downstream reuse), rather than Wikimedia's donors subsidising their business model.
So these companies wanted to show their long-term support and their interest to get our data in an ethical way, but only if they were included in the press releases for the 25th birthday? What an incredible way to show how ethical you are and how long-term that support is! Fram (talk) 15:32, 20 January 2026 (UTC)[reply]
@Fram In this context, I think It is my professional opinion that it would not have been possible to get permission for naming most of these new names outside of the context of the birthday. Believe me, we tried. means that they would not have allowed disclosure outside of a press release and WMF in this context, prioritized disclosure over having shadowy backers that were unknown to the community. "Leaked Records Reveal Wikimedia Foundation Quietly Funded by Major AI Firms" is probably a worse PR problem to have in this scenario. Sohom (talk) 16:12, 20 January 2026 (UTC)[reply]
My issue is not with having a press release about this, but that this apparently had to be included in the 25th birthday celebrations or they wouldn't have agreed to it. Which is basically blackmailing WMF into "we want to get attention during the 25th birthday celebrations" (which worked perfectly for these companies). Calling this "long-term support" and doing things in an ethical way (or calling them "partners" in official communications) when it looks more like getting cheap exposure on the reporting of the otherwise ad-free Wikipedia, is dubious. Your "worse PR problem" is a false dilemma. Fram (talk) 16:20, 20 January 2026 (UTC)[reply]
Wouldn't have agreed to disclosure without the press release, they would still have paid for it (which is the long-term support part if that makes sense) (or at-least that's how I read what was written but I might be wrong?) Sohom (talk) 16:38, 20 January 2026 (UTC)[reply]
Your insinuation that the disclosure of the companies' names was contingent on tying it to the anniversary, if true, is less reassuring than is unsettling. Nardog (talk) 01:19, 21 January 2026 (UTC)[reply]
I think that this just demonstrates that the role WMF sees itself as having (as large as possible) conflicts with the role many editors here wish it to have (as small as possible). I don't think we'll get very far by talking in this thread. Personally I give some of my time to Wikipedia, not to brand Wikipedia, or any brand for that matter. Phil Bridger (talk) 19:06, 20 January 2026 (UTC)[reply]
Soon we will able to breathe the word "realistic medieval world" and an AI will be able to comb all the Wikipedia articles and sources related to this topic and generate an entire reconstructed reality of the past and it wouldn't be possible if Wikipedia hadn't thoroughly maintained and built up the knowledge over 25 years, especially the link to (archived) sources so the AI creation tools can simulate an entire reality as realistically as possible while sticking to history and TRUE facts.
Slyceth (talk) ā Preceding undated comment added 01:24, 22 January 2026 (UTC)[reply]
Can anyone point to any concrete results from the proposals[35] generated the last time we did this? Serious question, not trying to be snarky. I am genuinely wondering if actions were taken that I never heard about. --Guy Macon (talk) 16:05, 25 January 2026 (UTC)[reply]
To quote myself from the metawiki talk page, there has also been growth in the right direction with WMF members engaging with the community more directly through discord, onwiki at en:WP:VPT before and after proof of concepts are being built (using a consistent scheme to denote at what stage experiments are) and more recently inviting community comments on the Annual plan before it gets writtenSohom (talk) 17:51, 25 January 2026 (UTC)[reply]
Questions to the community in preparation for WMF Annual Plan
The Wikimedia Foundation's Product and Technology department (the part that develops features and works on code changes) is starting it's Annual planning process (APP) where it decides what it will be allocating resources to/prioritizing over the next fiscal year. To inform WMF's decision making on what to prioritize, they are requesting community members to answer a few questions/provide feedback on what should be considered at this meta wiki page until Feb 10. -- Sohom (talk) 16:51, 20 January 2026 (UTC)[reply]
Thanks @Sohom Datta, I was coming here to post this message and you beat me to it! I'll just highlight for everyone here that the annual planning questions are ones Wikimedia Foundation staff are thinking a lot about these days and deal with some of the toughest challenges facing the Wikimedia projects, including editor support, attracting and retaining readers, and testing features more quickly and effectively. We are really curious how all of you would answer these questions, so thanks in advance to anyone who shares their thoughts! KStineRowe (WMF) (talk) 22:49, 20 January 2026 (UTC)[reply]
The community wishlist is very underattended. Last I checked, it consisted mostly of ~5 editors from enwiki. That is the consequence of turning an annual event with all its fanfare into an ongoing one with zero advertising and zero community awareness. Toadspike[Talk]08:58, 21 January 2026 (UTC)[reply]
What Toadspike said, I think this is the best opportunity at the moment we (the community) have of influencing what the WMF works on. Sohom (talk) 12:25, 21 January 2026 (UTC)[reply]
I suppose, but a new process with the same purpose as an existing process ignoring that existing process doesn't give me much hope for the new process. CMD (talk) 12:48, 21 January 2026 (UTC)[reply]
The two processes have existed side by side for a long time. I think the wmf seeking community feedback on annual planning is a good thing. We should encourage and reward the wmf whenever they solicit community feedback (i.e. give volunteers a seat at the table). āNovem Linguae (talk) 16:30, 21 January 2026 (UTC)[reply]
That, the annual planning process has been around for a while running alongside the Community Wishlist but has typically been a opaque process from the volunteers POV. Last year, besides PTAC's "focus on mobile editing" recommendation, there wasn't community input. This time around, after receiving feedback about it's opaqueness, they are trying to open it up further (to my understanding). Sohom (talk) 17:53, 21 January 2026 (UTC)[reply]
The wishlist is underattended because there are no followups. Whatever the participation is, the developed routinely say they are not interested / do not have resources working on the projects community voted for. After the top voted proposal was turned down a few years back, I lost any interest in voting for new proposals. Ymblanter (talk) 16:34, 22 January 2026 (UTC)[reply]
The leadership has changed significantly since then. The current status quo is that stuff on the wishlist do get worked on, but there isn't too much engagement with the process from the community (not the communities fault though) -- this is something I have been wanting to change, but progress has been slow. Sohom (talk) 11:52, 23 January 2026 (UTC)[reply]
Community-WMF relations
I still care about m:2025 WMF Board reform petition, and when I start something, I try my best to see it through. I can be very persistent in a good way. I've had several conversations behind the scenes, two of which was with our former CEO and current CFO. The main thing I've learned from these conversations is that the WMF does not like generalized statements of discontent but wants us to be more specific. I think it'd be useful to have something to point to in that capacity while I continue to try and improve WMF-community relationships when I have free time in the gaps of my busy life. I don't want to speak for everyone and I have a handful of very specific examples myself, but it'd be good to have more voices that I can point to to demonstrate things are more systemic. So, for people who have opinions about the current status quo, I'm asking:
When did you first feel this way? Was there an inciting incident that caused you to feel this way? Or was it a combination of different ones that eventually resulted in this opinion? If there are different incidents, can you be specific about as many as you can remember?
Did you feel like your feedback was valued? If you felt like it wasn't, why? Did you feel like you had any way to contact people who might be in a position to change whatever was upsetting you?
What are some long term technical issues that have bothered you or have not been prioritized?
Anything else you think may be helpful, whether it's positive or negative. I think it's important to have these conversations and address the elephant in the room.
I'll go first. I generally had a very favourable impression of the WMF as a new editor because they're a non-profit that hosts the project and I thought that was pretty awesome. I also had some naive ideas about how fundraising worked: [36]. I also thought the WMF were more involved than they are when it comes to content at first. I follow a lot of wikipedia related content online and I've noticed that this is fairly common. For example, some people misconstrue their donations as more directly supporting volunteer editors, akin to a Patreon-like process. Others are worried that we're in a more precarious financial situation than our fundraising campaigns let on. I also didn't know anyone from the WMF back when I was new. I was not involved in an affiliate. I was just me, focusing on my own projects within the community. Teen me was skeptical of people in authority as I had a background of seeing people abuse it for their own benefit. I was still somewhat new when the whole WP:FRAM thing happened, and that was what made me aware that there was some long standing tension between the WMF and the community. People were very vocally upset there and it was clear to me that recent events were just a microcosm of the whole thing.
Eventually, I met MMiller (WMF) while he was still on the growth team. I'm not entirely sure how this introduction happened, but I do know that somewhere around this time I was starting to get more active in discussions regarding NPP, where many editors felt frustrated by the lack of technical support. A couple of years later, I had a conversation with Levivich about helping new editors and WYSIWYG, which eventually led to me being inspired to experiment with mobile editing. I had heard of WP:THEYCANTHEARYOU and I was curious what I would observe as an experienced editor. I noticed a lot. I remembered Marshall as the only WMF employee I knew by name and pinged him on my talk page. He introduced me to JTanner (WMF) and I started to know a handful more WMF employees through the process of me messing around for hundreds of hours and giving feedback. I was happy that it wasn't just going into a void and that I could directly voice my concerns to someone who was able to address them, but I have a pretty strong suspicion that my experience here is the exception rather than the norm. The main thing that surprised me about this experience is just how obvious most of my feedback felt. It was odd to be treated like I had some extraordinary insights when I felt like I was giving feedback that would be immediately obvious to any experienced editor. I remember being disappointed to the response to this phabricator ticket, but in general, I felt like the blatant technical issues I was observing were getting fixed, like how the app would crash if I tried to edit the end of a page.
Becoming the 2024 Wikimedian of the Year changed things even more drastically. Suddenly I was someone who was important and people were actively seeking my advice. I was in the spotlight when it came to being a very visible mobile editor, and I remember feeling incredibly betrayed when I learned about this at the closing party. My conscience screamed at me to not just ignore this and do my best to stop it. I felt a sense of moral obligation as a community member, especially since I knew that not a lot of people paid attention to what was going on behind the scenes with the app. And I knew how bad the community reception to this could be if it was actually implemented. Thankfully, it wasn't. I've brought this up a few times since and people tend to be confused about why I care when I got the outcome I wanted. The reason is because I feel like there is a fundamental disconnect between the community and the WMF for people to think that this is a good idea in the first place and not realize that this is the sort of thing that would make people incredibly angry. I've sometimes used to metaphor of a Venn diagram to make this comparison.
After that, I took a break from anything involving the WMF. I'd participate in any research calls that came my way, and I'm glad there seems to be more interest in doing these things, like the research that was done regarding people's interest in being administrators. I know there's been a push from the foundation side when it comes to learning more about what they call "users with extended rights" across various communities. I think that's a step in the right direction, but it's only a step. I think there's a lot of work that needs to be done to repair the relationship between the community and the WMF. The response I usually get to this is something along the lines of how some people won't be happy no matter what. But there's a big difference between that situation and the way things stand now, in my opinion.
One of the things I was asked to give feedback on was the anti-vandalism tool for the app. I remember being confused about why this was being developed. Apparently it is of value to smaller wikis and to areas where more people are reliant on smartphones. I don't have that background, so I can't speak to the truthfulness of that. But I do remember that while I was giving my feedback about this feature wondering why this new thing would be created when the app still doesn't have VisualEditor and it isn't considered a priority anytime soon. It's unclear to me how things become "priorities". I know of countless editors frustrated by certain technical issues that have been afflicting them for years, or sometimes even a decade, who are similarly confused about such pritories. So when I hear people talk about how the foundation is doing work to address technical debt, I wonder how much is getting missed or dismissed. I know there's an incredible reliance on the goodwill and time of many volunteers to maintain certain things.
And of course, there's the matter of the recent board elections. I learned a lot by talking to people before creating my petition. I came across Molly White's timeline of a different scandal. It made reading m:Talk:Wikimedia Foundation Board noticeboard/October 2025 update even more upsetting. I was warned by someone that I'd be "burning my bridges" with the foundation if I created a petition, but I felt like it was the only way to really get across that I was upset and I was not the only one who was tremendously concerned by recent events. I had some hope that being a voice in the room at WCNA might prove useful. m:Talk:2025 WMF Board reform petition#WCNA shows how my initial attempt at that went. It was incredibly discouraging to have the literal CEO treat me like that, but I will state for the record that she has apologized to me, and I appreciate that. But I also recognize that not everyone would feel comfortable calling that behaviour out, and there are probably very few that could expect to receive any type of response. I know it terrifies even me to do such things, but I've been making a lot of progress the past year in being true to myself and speaking up when people would prefer to leave things unsaid.
Something else that disappoints me about WCNA is how hexatekin never got a good response to her question about the board's media checks. I remember physically shaking my head when the question was side-stepped with a response that was incredibly vague and insisted that whatever they checked for was normal for non-profit organizations. It was also incredibly frustrating to hear her insist that they are "listening" when that's not even happening in the same conversation.
And while there's a part of me that feels vindicated by the applause I got in my lightning talk where I said that the projects have succeeded despite the board and not because of it, there's another part of me that feels incredibly sad that people cheer for such a message. I don't think things have to be that way. I hope that more people being open about their experiences might do what my petition did not (as someone recently told me, it "accomplished nothing"), if being specific is what is required to make a difference. Clovermossš(talk)01:36, 22 January 2026 (UTC)[reply]
Clovermoss asked me to comment. My engagement with and respect for the WMF has declined steadily over the years. They seem to be very good at raising and squandering money. I have repeatedly offered my assessments of the shortcomings in how editors working on smartphones are treated and in my opinion, things are still bad and actually getting worse. I wrote My essay on the importance of smartphone editing and its challenges over ten years ago and things are no better. I no longer have any hope that the WMF will make any substantive improvements. Cullen328 (talk) 08:36, 22 January 2026 (UTC)[reply]
The day after my initial remark, I want to add that that I have had a very cordial relationship for many years with one senior WMF staffer and one longtime WMF board member. I also want to say that I am in general agreement with most of the comments below. I am not denying that there have been incremental software improvements here and there. but editing with a phone is still much more awkward than it ought to be. As a matter of principle, I still do 99% of my editing including administrative work on my phone. That's overwhelmingly how ordinary people access the internet these days. Cullen328 (talk) 20:52, 22 January 2026 (UTC)[reply]
I have cordial relationships with a handful of people from the WMF, as well. Unfortunately, I don't think that's the case for a lot of editors, and it's hard for them to feel like the WMF is more than a faceless monolith that doesn't seem to listen to their needs. One positive step that I liked was Vermont's project to have the WMF buy people books to use as sources. But I agree with you that there's so so much that is neglected and we need to do something more than small incremental steps. Clovermossš(talk)20:57, 22 January 2026 (UTC)[reply]
Pretty much the only thing I agree with in Schiste's recent essay is that Wikipedia was based upon desktop editing. Mobile views make up 75% of traffic in 2025. If the mobile editing interface is catastrophically tedious (which it is) then why would any sane reader start doing it for fun? ~~ AirshipJungleman29 (talk) 13:55, 22 January 2026 (UTC)[reply]
The message to the WMF needs to be really simple.
(1) Stop funding influence and politics and outreach using money that was donated because you said you needed it to keep the lights on and the servers running.
(2) Stop hiring people to do influence and politics and outreach. Start to reduce the workforce in that area (but not by firing people who're doing the job they were hired for---only by not renewing contracts and not replacing people who leave).
(3) Use the money you've saved to hire tech staff to work on the community wishlist and fix bugs. There should be a specific team that works on the oldest bugs.
(4) Just as a contingency, make sure there's a fully backed up version of Wikipedia that's shielded from US presidential executive orders by being legally and physically situated in another jurisdiction.
(5) Hire more lawyers. Do meaningful things to protect the editors affected by Asian News International vs Wikimedia Foundation. Tell the community what you've done.
The WMF should really be a bunch of sysadmins running the servers, and developers improving the software, writing add-ons and apps. Anything else is literally a waste of money. I guess the thinking is that the donations and grants have to be justified with new ways of spending it. I didn't begin editing because the WMF ran an outreach program near me. Wikipedia editing attracts certain kinds of people, such collaborative endeavours always have. Alchemy doesn't work. There's no banner, meetup or animated mascot the WMF can come up with that will turn the people who otherwise wouldn't have edited into editors.
I recently installed the Wikipedia mobile app and I didn't hate it, but I'm not sure I like it either. For one, I don't like the flat, material design (give us buttons!) But the thing that stood out to me the most is that the people who designed the app don't understand what Wikipedia readers and editors want. Reading Wikipedia is not like listening to music. Why should one care about "Time spent reading"? We don't need an algorithm to suggest us the next article based on previous reading activity. It's a fundamental misunderstanding of what Wikipedia's utility is. I don't know who needs to hear this, but Wikipedia should not be an infinitely-scrolling engagement machine.
Wikipedia provides a service to millions of people who want to quickly look up information, or want to kill a few minutes by learning about something that has crossed their mind, and to pupils and students looking for a starting point for research for a paper they are writing. Wikipedia doesn't need to be anything more than that and shouldn't aspire to be more than that.
Wikipedia's purpose is at odds with the WMF. Wikipedia is a website that provides a free and indispensible service to millions of people around the world, while the WMF can best be described as a benign tumour trying to justify its continued existence. Looking at editing statistics over on Wikiscan, the User edits/day graph shows that editing has been more or less even since it peaked in 2006/2007, I'm convinced that is despite WMF's actions, not because of them. TurboSuperA+[talk]12:48, 22 January 2026 (UTC)[reply]
@TurboSuperA+ Genuine question: "Why is recommending a next article bad?" I feel like people like Depths of Wikipedia have talked at length about how people fall into "wikirabbitholes" and I feel like encouraging that is a good thing, not a bad one? Sohom (talk) 12:57, 22 January 2026 (UTC)[reply]
Falling into "rabbit holes" on Wikipedia has to do with following Wikilinks on the page. You're reading about something, an unusual or unfamiliar term is Wikilinked and you click on it. Then you find yourself reading that article and you come across another Wikilinked term, you click on that, and so on. Having a recommendation queue removes the reading part and the discovery part: I no longer have to read an article to find interesting Wikilinks, articles will be served to me; I can no longer choose which Wikilinks to follow, I wait for the algorithm to give me an article. The other downside is that since it bases the recommendations on your reading history, it is unlikely to suggest something unrelated to your interests or something "out there", but falling into Wikipedia rabbit holes has to do with exploring topics outside of your interests. TurboSuperA+[talk]13:26, 22 January 2026 (UTC)[reply]
I agree that rabbit holes are interesting, there's a reason I have 1000 tabs open right now. I do think the "time spent reading" metric on the app is fairly harmless and I happen to know that several people who read Wikipedia instead of editing it really like it. But I mainly know people who are obsessed with statistics. They like their Spotify Wrapped etc. That said, Wikipedia is not just another service. Clovermossš(talk)17:53, 22 January 2026 (UTC)[reply]
Fully backed up version of Wikipedia is technically a WP:FORK. WP:NPOV of a proposed backed up data might be 99.9% volunteer input. I would Support any attempt to help serve the Global South. That means we need a new set of sysadmins to operate. Ahri Boy (talk) 01:07, 25 January 2026 (UTC)[reply]
I'm flattered that I was the first of only four editors that Clovermoss asked directly to comment after posting this, before she posted on the centralized discussion noticeboard. I'm feeling much more concerned about my US federal government's responsiveness to the needs and desires of the American community at this moment. In comparison with that, I'm feeling sanguine about the Wikimedia Foundation.
Regarding a more specific idea for Board reform, I suggest having geographically-based community seats. North America, one seat. South America, one seat. Europe, one seat. Africa, one seat. Australasia, one seat. Following the model of sports leagues' "wild cards", a few at-large seats which allow the second-most popular candidate in a particular region to get elected, as they may be more qualified than the top candidate in other regions. Time the elections for soon after the annual regional conferences, so that, for example, North Americans have an opportunity to see and talk with the candidates for their seat, and may have forums with their sitting community member, and not just appointed members, at Wikiconference North America. This will give the community more direct contact, as fewer people from our region attend Wikimania each year. Stagger the elections so that not all regions are electing candidates each year. Some years you vote for your regional candidate and an at-large candidate, other years only an at-large candidate. If the Board votes not to seat an elected candidate, then a special election should be promptly held to fill the open position. Rinse and repeat until the community sends the Board someone they can accept.
Whoever produced this deserves a promotion. Best production from WMF I've ever seen. Though I've been so busy, I didn't notice it until 3 days after it aired. I want to see more of that. Fundraising idea. Create an online game show, similar to Jeopardy! or Who Wants to Be a Millionaire. Rather than gathering contestants in a studio, have them on remotely from their home. Just need a way to make sure they aren't cheating by using ChatGPT to "ask a friend". WMF could even raise money by airing real advertisements between rounds of the competition. ā wbm1058 (talk) 13:17, 22 January 2026 (UTC)[reply]
I'm also here at Clovermoss's request. I've been around a while, long enough to remember when the WMF was less concerned about user conduct than the community was. I took part in the 2009 strategy process and attended five Wikimanias between 2009 and 2015. So I've met quite a few WMF employees, enough to know that they are not a complete monolith. For me one of my most salutary lessons was taking part in the user testing of the visual editor, seeing it get deployed before all the bugs we'd reported were fixed, and then seeing the WMF blame the volunteers who'd agreed to test the software despite us having reported the bugs that gave it such a rocky start. But a more telling and less widely known story was over a handout that the WMF were giving out about fifteen years ago, one of the most jarring stats on it was the claim that 30% of our most active editors had started as vandals. Now my bullshit detector went off the scale as soon as I read this and I knew both how offensive this was to the volunteer community, and how unlikely it was to be true. So I did some digging and found out that it was sourced from a combination of two facts, almost all of the blocks we had issued were for vandalism, and 30% of the thousand editors who then had the highest edit counts had been blocked at some point. Pretty much any Wikipedian would instantly spot the disconnect, most blocks are indefinite blocks of vandals who have made a handful of edits, and when we have the drama of a regular being blocked it is usually for something like edit warring or a compromised account. So I reached out to people I'd met in the WMF and discreetly pointed out that this was both offensive and obviously wrong. To my surprise I met incomprehension, what was obviously wrong and offensive to our volunteers was neither to those staff. So I consulted Kudpung who probably remembers this incident more accurately than me and who was able to persuade Scottywong to do some stats on those thousand, and especially the 300 who'd been blocked. To my surprise it wasn't mostly editwarring and compromised accounts. Half of those blocks were accidentally being blocked by someone else and a quarter were accidentally blocking yourself. Few or none were for vandalism. Eventually the three of us succeeded in convincing the WMF to drop the claim, though I'm not convinced they understood how offensive it was and how it illustrated the contempt that some staff displayed to volunteers. One thing that annoyed me about the whole episode was the nagging feeling that if one of us had simply ridiculed the WMF on a certain off wiki anti Wikipedia site, we'd have had a much faster response from the WMF for much less effort. Much has changed since then, and I'm not naming the WMF people involved as the individual staffers have probably all changed. But I have a strong suspicion that the WMF philosophy is still more "move fast and break things" and mushroom farming than Kaizen, and that the WMF is still more interested in recruiting a different less awkward editing community than in cherishing and working with the volunteers they already have.
Software does incrementally improve, some things do get fixed even if buried on phabricator. I've not yet accidentally blocked myself and perhaps something has changed to make that more difficult to do. I've not yet accidentally been blocked by someone else, and when that eventually does happen I'll bore them with this story and reinforce my own prejudice that the higher your edit count the greater the chance of being accidentally blocked.
More broadly, the WMF would do well to understand and emulate the importance of honesty and accuracy to the volunteer community and our reputation. I get that as marketing statements go, some of the fundraising messages are not unusually hyperbolic. But when your brand is integrity some of our fundraising messages are as damaging as firesale "everything must go" messages would be for a luxury brand.
As I've said elsewhere, structurally the governance side of the movement is in a mess. We haven't made the transition from a US not for profit to a global one. We need to split the WMF into a WikimediaUSA and an international body, and we need to decentralise. Any national chapter capable of getting tax exempt status in their country and a having a board with a majority of active wikimedia volunteers should be able to take over fundraising in their country.
For years we have had a WMF that is too pally by far with silicon valley, and as a result we now find our contents being mirrored by tech companies who know that the WMF won't protect the movement by enforcing the BY and SA parts of CC-BY-SA. The incident on the 25th birthday just illustrates how the WMF doesn't understand the volunteer community or the real long term needs of the movement. Ļ¢ereSpielChequers13:23, 22 January 2026 (UTC)[reply]
There are a couple of structural issues that seem to have naturally emerged. The way that the WMF and en.wiki editors see the systems are different, if you're a WMF staffer working in say technical development (and especially if you were hired with no editing experience) then en.wiki is just one of many projects whose software you are looking at, not only other language Wikipedias but likely also the many sister projects, which again often come in different languages. Editors on en.wiki naturally are focusing on en.wiki. This can build into significant tension because while in some structural way en.wiki may be just one of many projects, it is by other metrics a huge project, arguably the face of what is externally perceived as what WMF works on as a whole. (There are possibly ways to argue Commons and Wikidata are larger than en.wiki in some ways, but they are not the public face.) To look for an analogy, this sort of structural imbalance is the sort of issue that destroys political federations. There is probably also a significant qualitative difference, in that projects with smaller user bases are likely much more integrated into the WMF and its affiliate system than en.wiki, which has sufficient bulk to self-regulate in many ways. A WMF staffer who has to work with all sorts of different projects is going to face difficulties in navigating that different cultural situation. CMD (talk) 13:55, 22 January 2026 (UTC)[reply]
I'm sorry but how can you write something like this on a village pump page literally dedicated to communication between WMF & enwiki? Such a page doesn't exist on any other Wikipedia language version. WMF staff is well aware of the fact the enwiki is special in many ways and treats this community with a level of attention literally no other project ever receives. Johannnes89 (talk) 14:15, 22 January 2026 (UTC)[reply]
My understanding from my brief conversations with people active in other projects is that they have a massive communications gap, too, and feel like we get a lot of the limited attention that there is. From my perspective, the solution to that is everyone being heard more, instead of trying to fight over who gets heard in the first place. I do actively try to have conversations and understand the needs of other communities when I can (for example, I know the recent vector update really caused a lot of issues for the Wikivoyage community and they had a hard time getting anyone to care). I'd like to do more of that sort of thing, but I only have so much free time. I live and breathe Wikipedia but unfortunately that does not pay the bills. Clovermossš(talk)18:33, 22 January 2026 (UTC)[reply]
Vector2022 rollout was an instance where en.wiki was aligned with many other communities, rather than a difference in who was being heard. Perhaps if other projects also have a similar communications gap our board might be replicated, but ultimately such boards are only as good as their integration into WMF workflow. CMD (talk) 06:43, 23 January 2026 (UTC)[reply]
Well, we had Wikipedia:Requests for comment/Rollback of Vector 2022/Discussion. Which pointed out that the WMF oversold support for the new skin. For example, 60 responses saying that the old skin was better for usability versus 37 responses saying that the new skin was better got turned into "The majority of respondents reported that the new experience is easier to use or that the new and old experience are equally easy to use" when they added the 49 responses that were fine with either to get 60 to 86. In addition, they threw out 72.3% of the votes that had been cast. (With so many discarded votes, it is a surprise they didn't check the survey system for bugs and re-run it.) --Super Goku V (talk) 12:55, 23 January 2026 (UTC)[reply]
There was general opposition to Vector2022 here, as with WikiVoyage. Iirc Swahili WikiPedia voted unanimously to revert the change and was ignored. I'm sure there were other instances. Nonetheless, this is an area where the WMF clearly wanted to push some changes through, I would prefer they make that argument honestly rather than overselling support. CMD (talk) 04:31, 24 January 2026 (UTC)[reply]
Ah, I seem to have misinterpreted Vector2022 rollout was an instance where en.wiki was aligned with many other communities as en.wiki supporting the Vector2022 rollout. Sorry for misunderstanding. --Super Goku V (talk) 06:15, 24 January 2026 (UTC)[reply]
Indeed. Enwiki is unique in a couple ways that can put it at odds with other wikis and the WMF.
Enwiki is perhaps the farthest along on its wiki journey (the oldest), so it is no longer in a growth phase (write and approve lots of articles aka "inclusionism") and is instead in a quality control phase (enforce strict notability aka "deletionism", we can see this from notability guidelines such as WP:NSPORT getting stricter).
Enwiki editors tend towards minimalistic spending. You're more likely to find editors here that just want the WMF to spend money on software and servers and keeping the lights on. On the 999 other wikis, in my opinion, editors are much more likely to want the WMF to focus on the charity component, things like funding affiliates, knowledge equity, etc.
There's probably more, but those two spring to mind. I think having self-awareness of these issues can be helpful for working with the WMF and seeing how the wider movement views us. Things like "the WMF should only spend money on servers" may seem like an "obvious" position to us, but I think a lot of folks in the wider movement might disagree. āNovem Linguae (talk) 14:24, 22 January 2026 (UTC)[reply]
Thanks, point 2 puts into words a specific example (effect?) of the "significant qualitative difference" I was trying to convey. CMD (talk) 14:34, 22 January 2026 (UTC)[reply]
I don't know the other communities well enough to judge how many there support minimalist spending. It wouldn't surprise me if there was such a pattern, but if so is this a response to spending patterns? My perception is that EN wiki is the cash cow where a disproportionate share of funding is raised but relatively little is spent. Part of that is down to need, a hundred small wikis likely need more IT support between them than one big wiki, and if the start point is an English language project, any adaptation for right to left languages, different character sets etc is extra expenditure. Part is that if you are mainly on the English language Wikipedia your chances of getting a grant to Wikimania are allegedly much lower than if you are the only applicant from one of our smaller wiki communities. It would be interesting if the WMF surveyed our volunteers and asked about such attitudes, and in particular what sort of things we should be funding. I'm confident that some of us will be surprised by the results, if only because without a survey we don't really know how many think we should spend more on fixing our IT problems or getting different parts of the community to meet each other and talk. Ļ¢ereSpielChequers15:44, 22 January 2026 (UTC)[reply]
projects with smaller user bases are likely much more integrated into the WMF and its affiliate system: at least this statement is wrong for enwikisource (where I am a regular). We've faced the same issues, and perhaps more: any time a change is made for enwiki or wikipedias and it doesn't suit another wiki, the wmf reply tends to be of the essence of either *wall of silence* or "sucks for you". ā Alienā3 3 318:34, 22 January 2026 (UTC)[reply]
I haven't been here for long, but it appears the fundamental issue is diverging interests. But one of the main issues is that far too many people in the WMF just donāt understand the site and the community, and only see it from the corporate point of view. All WMFers should be strongly encouraged to have some experience editing (however small). Basically the WMF should be part of the community, not completely separate from it. Either that, or community representatives need to be in positions of actual authority (though Iād rather the former). Though the WMF's primary purpose seems to be to aimlessly accrue as much money as possible, and the community-WMF dichotomy seems more akin to conflict between capitalist and socialist ideologies. I really like WereSpielChequers's idea above to turn this into a proper international movement, rather than an Anglo-movement with some less-important franchises, which I'm sorry to say (through no fault or ill intentions) has neocolonial overtones Kowal2701 (talk) 16:09, 22 January 2026 (UTC)[reply]
I wonder if its a good idea to split WMF into an outreach organization and a development organization, similar to how Wiki Education was split out of WMF previously. Perhaps Wikimedia Outreach Foundation would have its primary goal to be encouraging the growth of the Wikimedia movement and Wikimedia Foundation would still exist to host the projects and manage the development of MediaWiki.
I also like WSC's idea to hand outreach over to local chapters instead of a centralized outreach organization. These could fundraise and manage outreach in their country/region and would benefit from their knowledge of the local community and what would work best in their area. WMF could maintain control over hosting and development of the projects while also overseeing local chapters and enforcing the UCoC. IsCat (talk) 16:29, 22 January 2026 (UTC)[reply]
I like this idea of spinning off outreach into a separate organization (with less funding than is currently being spent on it), keeping WMF focused on technology and legal (legally owning the assets, legally protecting those itself and its users, etc.). Levivich (talk) 17:25, 22 January 2026 (UTC)[reply]
The WMF spends a lot of time forming committees to issue reports to recommend forming committees to issue reports. These spend a lot of time saying very little, and are squirreled away somewhere on Meta where they will be promptly read by almost no one out of the already tiny minority of contributors who know they exist in the first place. The Foundation would be more of a problem if they were actually effective. GMGtalk17:18, 22 January 2026 (UTC)[reply]
I've been here 7 years now. The WMF has improved over that time. The fundraising banners are better now, Discussion Tools is a significant improvement (albeit it's like moving from 1995 to 2000, but still, that's better than before), V22 was an improvement, Enterprise is profitable, the outgoing administration was the best one so far: there have been demonstrable and significant advances.
And yet. The other day I wanted to add a citation to the New York Times and Washington Post, and the "cite" button in Visual Editor consistently failed to automatically populate the citation template. It's 2026, and I still have to manually type out first name, last name, etc., from sources as ubiquitous as NYT and WaPo. What the heck?
And that's just one of the many defects in Visual Editor. It's been over a decade and VE still doesn't handle ref names (":0", ":1"... very helpful). It handles templates horribly, much worse than, say, the way WordPress or any of its competitors handles templates. The syntax highlighter crashes on any moderately-sized page, even on the latest browsers. There is almost no error checking/correction: if I forget to close a {}, it'll still let me publish without an alert; if I'm careful, I'll notice it on preview, but even then, I sometimes have to guess why the formatting isn't displaying properly. VE isn't even where Google Docs was when it came out 20 years ago. And that's on desktop... it's almost unusable on mobile, even though the entire rest of the web adopted mobile-first design over a decade ago.
And that's just VE. Discussion Tools is better than what we had before but still the worst communication technology on the web. phpBB is 25-year-old open-source software, and it was better 25 years ago than Discussion Tools is today. Nevermind any actual modern website where people communicate, like Reddit or Twitter or take your pick: the thing I'm using to write this message is worse than all of them. We could go on with ancillaries: the graphs debacle (how many years has it been?), the ridiculous system we use to archive talk pages, the rudimentary 1990s-style functions we use for page layout and design (am I |right?), it's all feels like writing an encyclopedia with a typewriter.
Yes, we know: Wikipedia has unique challenges. Orders of magnitude more traffic, pages that change three times a second, everything has to live inside a web browser with minimal cookies and no registration required for readers. Yes, it's harder for Wikipedia to be Google Docs than it is for Google Docs to be Google Docs. And yet: give me 25 years and almost $2 billion dollars (that's how much the WMF has spent all-time!), and I will give you the greatest WYSIWYG Visual Editor you have ever seen. Give me $100 million a year and I'll have it ready for you in less than 2 years and you won't even have to pay me, just let me keep the money I don't spend (WMF: it's a standing offer, call me!). There is ample money available to fix these problems, they just need to dedicate serious money to the effort, like tens of millions of dollars just on remaking Visual Editor. If they have to rewrite all of MediaWiki from the ground up to modernize the website, well they have $200 million/year available to do it, it should have been done already. People make blockbuster software for less.
Even now, they're soliciting input for the annual plan over on Meta, and the web pages they're using for it are all but unusable. Go ahead, click the link to m:Talk:Wikimedia Foundation Annual Plan/2026-2027, and see how long it takes you before you figure out where to write and how to write. Now try doing it on mobile, which is what most people are using these days to browse the web. Even a simple thing like signing the question prompts with ~~~~, which would generate a "reply" link from Discussion Tools, isn't done, meaning you have to open up that crappy Visual Editor (or an even crappier, older editor) in order to submit your feedback. It's a little thing, but it just screams "we are out of touch and have no idea how this website works and we don't care to make it better! we're not trying to make it easy for you to give feedback." In 2026, we should be way beyond that. We should be push-polling editors, we should have one-click voting, and so on--things that have actually been done in the past, but for some reason aren't consistently done.
So about the Board of Trustees... they're really who's at fault here. They should be doing far more than just selecting the next CEO and then kind of rubber stamping everything else. For one thing, they should be setting budget requirements that require the WMF to spend the vast majority of it's money on technology development. Like 70% tech, 20% community, 10% fundraising/administration, should be the split. Currently, it's about 45% tech, 30% community, 25% fundraising/administration... less than half the money is spent on tech when it should be like two-thirds or more.
And the reason the Board is weak is because it's set up to be weak. First of all, WMF and its affiliates (who receive money from the WMF) have way too much influence over the choice of Trustees--we just saw that starkly in this last election.
Second, there are too many Board-selected seats (including the founder seat, which should be abolished) and not enough community-selected seats. No wonder the WMF spends so much money on itself and "building community": half the Trustees are selected by people who rely on that money. All of the Trustees should be 100% elected by the community: one editor, one vote, should be the principle. Let the elected Trustees get their professional advice from a Board of Advisers, which they can select--the Trustees themselves should all be elected in regular, direct elections.
Third, we, the electorate, should start holding candidates to platforms and election promises (just like in the real world). Candidates should be transparent about what reforms they support, and Trustees should be judged based on how well they effectuated their election promises. In the next election, I would like to vote for an entire slate of reform-minded candidates, based on the reforms they're proposing, such as recalibrating the budget to spend most of the money on technology improvement.
The other day I wanted to add a citation to the New York Times and Washington Post, and the "cite" button in Visual Editor consistently failed to automatically populate the citation template. It's 2026, and I still have to manually type out first name, last name, etc., from sources as ubiquitous as NYT and WaPo. What the heck?
I thought that had to do with how the news websites store and transmit metadata, rather than the issues with the Wikipedia scraper. For Reuters links the fields can never be automatically populated either.
one editor, one vote,
The obvious problem there is sockpuppet accounts. What's stopping someone from voting a hundred times for their preferred candidate? They'd have to institute some sort of proof of identity system where you're given a unique key to use in voting. TurboSuperA+[talk]18:08, 22 January 2026 (UTC)[reply]
"They'd have to institute some sort of proof of identity system where you're given a unique key to use in voting" - there are standard checkuser tools; no need for identity verification (which is even not possible with Wikipedia's model). sapphaline (talk) 18:16, 22 January 2026 (UTC)[reply]
Right, we already have elections without proof-of-identity, using m:SecurePoll. It's not perfect -- despite CU, socking is ubiquitous -- and, personally, I've always suspected that election scrutineers are not finding the socks and all of our SecurePoll elections are basically rigged. I can't prove it, but it's the only way I can explain the election results in election after election. We could keep using the election system we have, or we could go to a two-class editor system, where "voting editors" have to submit proof of identity. That system has its pro's and con's as well, the biggest con being that it would disenfranchise voters who would be unable to prove their identity, which would be many voters in the developing world. Levivich (talk) 18:29, 22 January 2026 (UTC)[reply]
we could go to a two-class editor system, where "voting editors" have to submit proof of identity.
Yes, exactly, and yes, it does. This was considered when WMF was initially set up, and has been discussed several times since. It's something we can do, but we've chosen not to (again, there are good reasons not to). Levivich (talk) 18:36, 22 January 2026 (UTC)[reply]
"have to submit proof of identity" - what can you suggest as a mean of proof? Please don't mention blockchain, please don't mention blockchain, please...sapphaline (talk) 18:42, 22 January 2026 (UTC)[reply]
The typical ways. In the US, that usually means taking a picture of yourself and taking a picture of your ID (driver's license, passport, etc.) with your mobile phone, and then having secure login (with 2FA or passkey or whatever the standard tech of the day is). Like what you'd do when you open an online banking account. As you can see, this structure would privilege Westerners (who have gov't-issue IDs and mobile phones) over non-Westerners (many of whom don't have those things). Levivich (talk) 18:54, 22 January 2026 (UTC)[reply]
There's also the very real privacy implications of doing something like that, even if that data isn't saved. But my understanding is generally speaking, that's not information the WMF likes to be anywhere near. I haven't looked into whatever was done for temporary accounts, but theoretically that might be some kind of solution? Or I don't know enough about tech to realize how nonsensical that suggestion sounds. My skills are more people-related, even if I want to understand the technical side of things better. So I try really hard to give people who actually understand those things a chance to speak their minds. Clovermossš(talk)19:07, 22 January 2026 (UTC)[reply]
Exactly; I'm an example of someone who wouldn't join the voting class because I don't want to out myself to the WMF, even though I live in the US, a country where until recently I had freedom of speech rights. Few in China or Russia or Venezuela would likely register with the WMF. The problem is, if you want to make sure it's "one person, one vote," you have to definitively identify the person.
There are some other possibilities to cut down on the threat of sock-voting, like increasing enfranchisement requirements, e.g. must have 10,000 edits to vote. It's harder to run a sock-farm if every sock has to make 10,000 edits. But also, that would disenfranchise the vast majority of editors. The lower the barriers to entry, the more enfranchisement, but the easier it is to game the system. So, a balance must be struck. Right now, that balance heavily favors openness. Maybe it should be rebalanced, perhaps with some kind of super-extended-confirmed status at like 1,000 or 5,000 edits? Idk where to draw the line exactly. Levivich (talk) 19:18, 22 January 2026 (UTC)[reply]
The two main things that concern me from a mobile editing perspective is that doesn't have the "basics". As I said in my long preamble, the app does not have visual editor at all, which is a pretty glaring omission. The app also forces you to edit in source code and memorize the parameters for every template you want to use. I've been using mobile web a lot lately and while VE is technically an option (which it should be!), the source editor also requires people to memorize the markup for the code they want to use. So I'm not just manually typing out titles and website names when I cite something, I'm literally typing up <ref>{{cite web|title=Title|last1=Clover|first1=Hannah|website=Wikipedia|url=Somethingfancy.com|date=January 22, 2026|access-date=January 22, 2026}}</ref> every time. Other things about mobile web I've noticed is that it's impossible to mark an edit as minor, you have to switch to desktop mode if you want to create a redirect, the option to create red linked pages don't show up in search, etc. Clovermossš(talk)18:21, 22 January 2026 (UTC)[reply]
"the source editor also requires people to memorize the markup for the code they want to use" - does opening template's documentation in a separate tab not work? sapphaline (talk) 18:23, 22 January 2026 (UTC)[reply]
while VE is technically an option (which it should be!), the source editor also requires people to memorize the markup for the code they want to use.
I use the source editor because the VE doesn't work well for me. The VE often inserts <br /> tags and other weird formatting that I can't immediately see. The source editor could be improved as well. Right now when you start typing a template with {{ and a letter, the source editor will give you a dropdown menu of matches, so it is easy to select the right name for the template; but that's all it does. There should be a way for it to also give you a list of valid parameters for that template. TurboSuperA+[talk]18:33, 22 January 2026 (UTC)[reply]
Yes, it has to do with how news websites store their metadata. What I'd expect from the WMF is that, after 25 years and $2 billion, somebody would have called up the New York Times by now and said "hey let's put some of our people together to figure out this metadata problem." It's not like the NYT doesn't want to be cited on Wikipedia. This could be done with every major news organization on the planet, we have the money and time, we just aren't trying hard enough. We rely on volunteers and third-party software like Zotero to do it instead. With the money and time they've had, the WMF should have led the development of an industry-standard Request for Comments protocol for website metadata that would allow for a no-fail Zotero system that could be integrated into VisualEditor. Levivich (talk) 18:27, 22 January 2026 (UTC)[reply]
I'm not sure I entirely agree with that. Have you ever tried to write a scraper that handles a lot of different websites? They're not that easy to write; formatting varies wildly, even within a single website, plus formatting changes regularly over time as websites are redesigned. Partnerships with the other websites, or development of a standard RFC protocol, might actually be cheaper/easier. But regardless of which method is cheaper/easier, I don't disagree that they have had enough time and money to develop a scraper, and keep it updated, at least for the NYT website, and probably for many more. We should be able to one-click cite any NYT URL (and WaPo and CNN and BBC etc. etc.). Levivich (talk) 18:33, 22 January 2026 (UTC)[reply]
"Have you ever tried to write a scraper that handles a lot of different websites?" - Wayback Machine-style scraper should be sufficient for 99.9% of our online sources as these are not too complex websites. If parsing JS-heavy websites correctly is really needed, archive.today-style scraper (running real, non-headless browsers) would cover even this niche (in context of Wikipedia) use case. sapphaline (talk) 18:43, 22 January 2026 (UTC)[reply]
They're using web crawlers, not web scrapers. Typically, when you save a copy of the entire web page, that's not called "scraping." Scraping means extracting data from the webpage, not just saving a copy of the whole thing. That's just semantics, though. Levivich (talk) 18:56, 22 January 2026 (UTC)[reply]
Building a web scraper that is able to retrieve meaningful is non-trivial amount of work, especially given the context of Cloudflare being actively adverserial towards web scrapers due to the proliferation of AI scrapers. [38] This is not something that WMF is at fault at, it's just a very hard problem to solve because many of the well known bot detection services will not listen to anyone who is SEO-relevant (read: is a search engine). Sohom (talk) 18:55, 22 January 2026 (UTC)[reply]
Is it just the authors, or everything failing? Back when I was more active, I used to find that news sites would make sure to have metadata for the Facebook and Xitter sharing tiles ā article-title, publication name, thumbnail ā but didn't care about attributing their own authors as much as we do. (If it's everything failing, then it might mean they are blocking the tool as some others have suggested.) ā Pelagic ( messages ) 07:50, 26 January 2026 (UTC)[reply]
The other day I wanted to add a citation to the New York Times and Washington Post, and the "cite" button in Visual Editor consistently failed to automatically populate the citation template. It's 2026, and I still have to manually type out first name, last name, etc., from sources as ubiquitous as NYT and WaPo. What the heck? Those websites are probably blocking the visual editor generate citation thing because they think we're bots. Here's some past tickets where this has been a problem and been fixed: phab:T403799, phab:T362379. But if it's still happening then maybe NYT and WaPo changed their anti-bot algorithm again. Please feel free to file a ticket on Phab and tag it Citoid to get the attention of the correct WMF software engineers. āNovem Linguae (talk) 17:58, 23 January 2026 (UTC)[reply]
Thanks, I reopened phab:T323169, which has tracked this recurring problem since 2022 (during which time the WMF has spent over $500 million; not sure how much of it was spent on fixing the citation tool). Levivich (talk) 01:22, 24 January 2026 (UTC)[reply]
In my experience on English Wikipedia, the community in general is very good at aligning itself with the common goal of building the encyclopedia, which is the first of five pillars. From the pillars, through policies and guidelines, the community has made and keeps improving the process that helps build the encyclopedia. The process is arduous, but volunteer editors believe (either explicitly or implicitly) that the goal is worth it, that building Wikipedia is a Good Thing. Part of the process is community continuously demonstrating the alignment by constantly referencing the policies and guidelines in discussions and edit summaries.Couple of arguments to illustrate my next point (feel free to collapse this stream of consciousness to make my post shorter):
Norway, with its vast fossil fuel reserves has an ethical council which tries to make The Petroleum Fund more ethical. Norwegians, indirectly through their government, try to make sure that this wealth is amassed in some ethical framework.
In the fictional Starfleet, the only person on a ship, who can give orders to the ship's captain is the ship's senior medical officer, who can deem the captain not fit for duty. This usually happens when the captain's judgement is somehow compromised and their orders no longer align with the Starfleet's principles.
Iron law of bureaucracy: "In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals that the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely."
I've encountered a number of controversies related to relations between community and WMF, and resolutions sometimes include the wording along the lines of "here's how we're changing our processes to make sure that <insert bad thing> doesn't happen in the future" (if not interpreted graciously, sounds like damage control), but I don't remember such resolutions ever having "here's how we're changing <insert process here> to make sure it helps build Wikipedia".All of this is to say, that WMF is not good at demonstrating that its actions are aligned with the goals of the community (see also Kowal2701's comment about "diverging interests"). Kudpung below asked for organization charts, but what I would like to see is a dependency graph of incentives and motivations. As an example, if someone in a middle-management position at WMF gets a key performance indicator filled with buzzwords and corporatese, then it should have a clear chain of cause and effect explaining how it helps build a better encyclopedia, with translation to plain buzzword-less language along the way. In general, such sources of information should help outside observes understand and verify that WMF's actions are aligned with the goal of the community.Perhaps it is infeasible at the scale of WMF, I don't know. However, in the absence of a clear display of the alignment, having more members of the board be selected and trusted by the community is what should help steer WMF towards the goal.For a more concrete example, the most visible to me misalignment between WMF and the community of English Wikipedia is the development of tools. The most important of them (of the top of my head: Visual editor, NPP) have perennial issues. I agree with Levivich's comment above that more money should be spent on tech. In particular, I think that there should be more time spent on less glamorous parts of software development such as bug fixing and refactoring, which should hopefully enable further features. Balancing time between these aspects is definitely not a solved problem in software development in general, but WMF could do a better job of being more like other healthy long-lasting software projects (e.g. the Linux kernel).Here's a thing that caught my attention recently. On the surface, including the number of resolved community-submitted tasks in each issue of Tech Newsseems like demonstration of the alignment with the community. However, if the prioritization of these tasks isn't aligned (example ā sarcastic comment by Izno) then this number in Tech News looks like some WMF's employee's metric that fell victim to the Goodhart's law and thus should not be a metric.I'm sorry this got so long, I hope I managed to get my points accross. āā andrybak (talk) 03:18, 23 January 2026 (UTC)[reply]
@Andrybak For note, current KPI's for the WMF are available on the Annual plan (it is filled with corpo-speak but it's there). To give a rough overview, WMF currently has a two pronged approach, one to develop new features (and improve existing ones) to reverse the downward trend of contributor growth, and two to fix and maintain old software as and when required to keep the encyclopedia moving.
Regarding the "community-submitted tasks", I doubt most WMF employees/engineers/product managers are aware of the "community resolved task" metric (evidenced by the fact that I have tickets on my current notification list that are resolved by staff that are subsequently assigned to volunteers/staff volunteer accounts). That isn't a metric folks aim to maximize. @Izno comment in that context of the Tech News update is a (well-deserved imo) dig at the current state of the wishlist system. -- Sohom (talk) 13:30, 23 January 2026 (UTC)[reply]
In regards to that isn't a metric folks aim to maximize, I hope you don't mean relying on volunteers for technical maintenance more than we already do. If anything, we should be offloading people's volunteer workload onto the plate of someone who is actually paid to deal with it. Having people be assigned to work that's already done is somewhat confusing and seems to indicate some lack of communication somewhere, but I think it also hints to how long some of this stuff can take that people feel obligated to fulfil the need themselves. Clovermossš(talk)20:48, 23 January 2026 (UTC)[reply]
@Clovermoss, To my knowledge the metric that we are talking about somewhat under-counts the actual thing it is supposed to count. Multiple employees (TheresNoTime, MusikAnimal, Samwilson, Taavi, Ladsgroup, among other people) use volunteer accounts to work on tasks in WMF capacity. There are also cases like T404910 and T404909 which came from conversations I had with the ModTools team but are not marked as "community submitted". Additionally, the metric as it is currently calculated also does not include the time folks spend reviewing volunteer patches and so on. This patterns of undercounting is not one I would expect of a metric that has been Goodhart's lawed. The metric is purely there (to my understanding) to be a rough indicator to non-tech folks that commmunity-submitted tasks are being worked on. While WMF C-level staff (read: Selena) care about distributing WMF resources to improve software where the community wants them, this is not a/the metric that they optimize for to my knowledge.
Regarding "assigning vs resolving". In Phabricator, when a task gets resolved, the person who closes the task gets assigned the task by default (I assume this is a holdover from Phabricator's Facebook roots). Wikimedia tech volunteers typically do not care too much about this functionality and so sometimes the person assigned on resolving might not even be the person who worked on it. However, looking at the script, it uses the last assigned owner to figure out whether a WMF staff member resolved a bug, which is inherently buggy. Sohom (talk) 00:50, 24 January 2026 (UTC)[reply]
Getting back on track with Community-WMF relations: To condense the main issues, it suffices to highlight the salient points made by others rather than responding with the same things in my own words. The times when we could sit down with the people right at the top and get things done (like Page Curation) are long since gone. There were only 7 paid employees. Nowadays there are 700 and with the lack of transparency in the form of a genuine hierarchical organigramme, no one really knows who is in charge. Sure, there is a CEO, but their positions have become ones that are possibly more that of a roving ambassador than having an essential overview of what the different audiences require and a hands-on approach to what is needed on the factory floor.
The WMF should really be a bunch of sysadmins running the servers, and developers improving the software, writing add-ons and apps. Anything else is literally a waste of money. I guess the thinking is that the donations and grants have to be justified with new ways of spending it. ā TurboSuperA+
They [The WMF] seem to be very good at raising and squandering money. ā Cullen328
'really simple message to the WMF' by S Marshall in 5 no-nonsense points.
From WereSpielChequers: [But] I have a strong suspicion that the WMF philosophy is still more "move fast and break things" and mushroom farming than Kaizen, and that the WMF is still more interested in recruiting a different less awkward editing community than in cherishing and working with the volunteers they already have. and More broadly, the WMF would do well to understand and emulate the importance of honesty and accuracy to the volunteer community and our reputation.
and ...the WMF doesn't understand the volunteer community or the real long term needs of the movement.
From another current thread on the VP 'The Wikipedia sign up page disclaimer idea': Realistically, non-trivial software development requires a budget allocation and then time to actually do the work. It's January now, so the best-case scenario would be to join the annual budget planning process (which is starting now), and to have a team assigned to begin work in July (beginning of the new fiscal year) and then maybe to have something to test next calendar year. But "years" is more likely. - WhatamIdoing
and my response:
This is the fundamental problem when WMF intervention is needed for a just few lines of code on something critically important but because it was a community idea and not their own, they find any excuse not to entertain it. They also appear to have a strong opinion that because they are paid for what they do, nobody among the tens of thousands of volunteers has any technical clue even though some of us have done MediaWiki installations or built extensions ourselves. This comes down to even throwing a simple switch on one of the default prefs on a MedWiki package. AFAIK, the registration page has jealously guarded WMF access only.
I appreciate your initiative to try and summarize things, but the details of what exactly has been the source of frustration for people (and where the conversation has been heading) is exactly what I've been told is needed to make any type of difference. In one of the conversations I had behind the scenes, someone pretty much said that they could do something if I handed them a 10 year plan, but that they can't do anything with a bunch of people saying they're upset and just want things to change. It's also really good to have something to point to when someone who doesn't have that background wants to understand the reason behind people's anger (people aren't just doing it to be haters or because they don't want to help build something up instead of tear it down). I'm hoping having a really solid concrete list of examples to point to will be helpful as I continue to pursue these conversations with people within the WMF. I think you make a good point about how it's difficult to know who is even doing anything. It's a maze, and I've said as much before. I think it'd really help if we had some centralized list of this is how many departments there are, product teams, etc somewhere, along with a list of every affiliate or hub and everything in one place. It's hard to have these discussions when you don't know who to contact. Clovermossš(talk)19:43, 22 January 2026 (UTC)[reply]
On a related note, someone does need to make Wikipedia:Anti-WMF sentiment blue (btw I couldāve sworn a page that described community views on the WMF existed, after searching for a while I asked ChatGPT and it gave me a non-existent page at "Wikipedia:Wikimedia Foundation issues" which it claimed was that :/ ) Kowal2701 (talk) 20:30, 22 January 2026 (UTC)[reply]
Try this: Ask the WMF to pick a Wikimania -- any Wikimania -- and tell us how much it cost with at least a vague indication on what the money was spent on. Go ahead. Try. You will receive a stonewall of silence. You won't even get a response saying that they can't or won't answer the question. --Guy Macon (talk) 00:33, 23 January 2026 (UTC)[reply]
I've had similar questions about various technology projects, like how much they spend on VE v. V22 v. Discussion Tools, etc. Not sure why being transparent about project-level funding is a problem. How do we know if they're spending enough on this or too much on that, if they don't disclose how much they're spending on this and that (just broad level categories like "infrastructure" or "personnel")? I'd like a Board that provides that project-level-spending oversight, but I don't believe the current Board does. I've heard Trustees say that it's not the Board's job to tell the WMF how to spend its money, that that's the CEO's job and the Board's job is to pick a good CEO, but I disagree with that viewpoint. Levivich (talk) 01:46, 23 January 2026 (UTC)[reply]
Every so often someone (never anyone from the WMF; along with the usual WMF silence comes an angry mob of regular editors insisting that you shouldn't question the WMF) claims that my financial transparency proposals are way too much work for the WMF. I then ask a much smaller question that should be easy to answer. Here is how that went last time: Wikipedia:Wikipedia Signpost/2015-03-18/Op-ed#Computer equipment and office_furniture. The reader should feel free to ask the same question and see if they can get an answer. --Guy Macon (talk) 17:29, 23 January 2026 (UTC)[reply]
Well, that does seem like it should have been a relatively straightforward query. It's probably difficult to get answers about that now that it's been a decade (unless records for such things are retained permanently) but that's exactly the sort of concrete example that is useful. Something I've learned is that the WMF and board seem to have a different version of transparency than we do. When I brought up a desire for more transparency regarding board elections, people kept thinking I was asking them to give confidential information. I understand there will always be some degree of confidentiality, but we're nowhere near the level of basic transparency I would expect from an organization that pats itself on the back for it. Maybe that information is accessible in some obscure way, but beyond very generalized details, there doesn't seem to be that much to go off of. And it's concerning how concerning the limited information we do tend to get is. For example, Victoria's depiction of Lane's aspirations here. I don't think trying to work within a system to change it is a problem and I'm also sad that the lesson learned from this seems to be that Victoria should have never said anything at all. If giving reasons makes things worse, the problem wasn't the transparency, and doesn't inspire faith that the other confidential reasons are any better. Clovermossš(talk)18:07, 23 January 2026 (UTC)[reply]
Also, I was wondering if anyone has ever literally told you not to question the WMF? There's been a few times where I think that might have been implied when it comes to my own experiences, but no one has clearly said so. I do think there were a few people who were slightly taken aback by my candor at Wikimania. But I always took that more as surprise regarding my tendency to be unconventional rather than the questions I was asking themselves. I tend to be very sincerely direct. Clovermossš(talk)18:14, 23 January 2026 (UTC)[reply]
This sort of nickle and diming probably costs more money than it purports to save. I used to work at WMF back in 2013. This was a long time ago, but from what I remember there was a lot of waste that boiled down to, we are going to do things the expensive way because the cheap way looks more expensive from the outside and its more important to look like we are spending money responsibly than to actually spend money responsibly. Ask yourself, why does WMF never have any meetings/offsites/etc in Los Vegas despite it being one of the cheapest places in the US to do such things? Bawolff (talk) 04:21, 24 January 2026 (UTC)[reply]
I don't think everything needs to be nickel and dimed, but it makes sense to question expenditures when they seem outside the realm of what you would expect (which the original thread about furniture actually elaborated a bit on when Guy said he'd make allowances if something was categorized where one might not initially expect it). I also don't think it's unreasonable to just have a number for how much certain initiatives/programs cost. I get the point you're trying to make here about how added bureaucracy and avoiding the appearance of impropriety can factor into things, but I don't think the foundation is as great at the latter as they hope to be or that this has to be an either/or situation. Clovermossš(talk)05:43, 24 January 2026 (UTC)[reply]
I would agree they are very opaque, and high level numbers - spent $X on mobile, spent $x on WDQS, etc would probably be welcome [For that matter, I often thought it would be interesting to try and compile guesses ourselves]. I don't think its all that helpful to get fixated though on how much they spent on furniture a decade ago. Especially without a comparison point of how much your average tech company of WMF's size, in that location, in 2013 would have spent on furniture. Naively that number doesn't actually seem that high to me, but i don't know what is normal. Furniture can be an investment, when you're paying people >100K a year, small increases in productivity due to better office equipment can add up to a very large amount of money very quickly.
I think the biggest problem with WMF is most of the criticism of WMF ends up being a little silly. Sometimes people go, look at google's budget, WMF is a pittance comparatively, clearly they can do no wrong. Or they go to the other extreme and suggest basically everyone should be fired and that no software development or server maintenance is required at all (or even the people to plug in the servers). Other times people focus on the tiny things because its something we actually have data for and can talk about, but it really doesn't matter. None of these are really good criticism in my opinion. WMF's budget should be evaluated in terms of if WMF is actually doing the things we want it to do, and what a reasonable cost is to do those things. Bawolff (talk) 06:27, 24 January 2026 (UTC)[reply]
Mr. Marshall has it pretty right above, but to reinterate: 1. Stop lying during fundraising. #BOYWHOCRIEDWOLF; 2. Limit fundraising to two concrete and limited periods during the year. Begging is pathetic, especially when WMF is holding a 9-figure stack of chips. 3. Stop trying to make the WMF millions into a social project to Right Great Wrongs. That's not your role; 4. Bolster legal support of good-faith Wikipedians who are subjected to legal harassment; 5. Stop with the junkets. There is no reason Wikimedia conventions need to be a vacation club for the bureaucracy and their acolytes. Use something called THE INTERNET with a view to actual inclusivity rather than tokenism through travel vouchers. I could go on. That's enough. Carrite (talk) 21:04, 23 January 2026 (UTC)[reply]
I don't think I'd go quite so far as some of the people in this thread who want to abolish outreach/events entirely, but I do think more transparency to donors is crucial. I've pitched this idea in the past because many non-profits actually let you direct your fundraising to where you want it to go. If we had different buckets for technical support and community outreach, I have a feeling more people would prefer to prioritize the former rather than the latter when they specified a preference. There's probably a better dropdown menu of options someone could come up with that would cover all the bases yet not too specialized. Clovermossš(talk)05:50, 24 January 2026 (UTC)[reply]
From what i understand (although I don't know specifics) WMF's track record with restricted grants is pretty bad. From what I've been told, it often resulted in building software that doesn't exactly meet needs or is half finished, because the grant required them to do something that didn't fully make sense or the grant only included provisions for half the project. What you're talking about is probably a bit more high level then that, but there is risk here, for (a perhaps extreme) example if all the money has to be spent on programmers and no money spent on asking users what they want, the programmers will probably end up wasting a lot of time building something useless. Bawolff (talk) 06:02, 24 January 2026 (UTC)[reply]
The WMF historically used to ask for donations in a way that implied the servers might go down if people didn't cough up. We, and notably editors active in this discussion, successfully campaigned to make their donation banners more honest. There's still substantial room for improvement, though. Donation banners appear on a rendered Wikipedia page. Therefore they must present the full facts accurately and without bias.The WMF must be scrupulously neutral. It should not be a politically active organisation. It exists to support websites that it requires to be politically neutral, and it really ought to eat the dinner it serves. Our reputation for neutrality, such as it is, was hard won and will be easy to lose, and I don't want the WMF to lose it for us.āS MarshallT/C10:30, 24 January 2026 (UTC)[reply]
I've seen a few people bring up politics, and I genuinely have no idea what they mean. I've never seen the WMF endorse political candidates or get involved in anything that doesn't directly impact them like Section 230. If we're talking about individual employee opinions, I feel like they should be able to express themselves like anyone else. Clovermossš(talk)13:11, 24 January 2026 (UTC)[reply]
I think they refer to some of the spending on social justice advocacy that significantly increased during Katherine's time as ED. Sometimes the justification was reasonable ("support this org documenting oral history of some group, which will produce reliable sources about that oral history"), sometimes tangential ("support this org that teaches kids in some minority group to code in the hope they'll grow up to contribute to MediaWiki"), and sometimes completely unrelated (IIRC something along the lines of "a free encyclopedia is inherently a radical social project" was actually used at some point to justify something). m:Knowledge Equity Fund got a lot of such criticism, as in the Signpost article Thebiguglyalien linked just above. Internal WMF culture took a similar turn around that time; really, I think the culture still hasn't recovered from Lila. Anomieā15:34, 24 January 2026 (UTC)[reply]
Not sure why we've got a CEO with such a partisan background, at the very least the optics aren't great for a self-described neutral project and risks dragging us further into the American political psychodrama Kowal2701 (talk) 15:44, 24 January 2026 (UTC)[reply]
I don't really care if someone supports human rights, free culture, etc. I'd be a hypocrite if I did have a problem with that. That said, wow I understand why people are concerned about 2023 spending. That hasn't come across my radar before. We're not a philanthropy project, spending donor money to support other projects that are not directly related to Wikimedia projects is incredibly concerning. I'd suggest anyone bringing that up in the future not phrase it a "political" matter. Whenever I hear stuff like that, I think people are skirting around how they don't like projects meant to address content disparities. I think it's perfectly fine to question how such things are done (I know that contests sprung upon us can sometimes have a lot of quality issues and involve a lot of volunteer effort to clean up and that just shouldn't be happening), but I don't think the ideas themselves are bad. They just need to properly managed and have people who know the community being involved in them. To get back to what I was saying as donation buckets, something like that could fall under the umbrella of "content". I do think there are people who genuinely want to support that and already think their money goes directly to volunteers or to keep the servers running, based off what I see across social media. Clovermossš(talk)17:21, 24 January 2026 (UTC)[reply]
And just to be clear, I think the organizations described in the Signpost article sound great on paper, and I don't have a problem with people working towards those causes. I get the general concern that it's hard to cover topics that don't have enough sourcing due to being historically underrepresented. The death or failure for local media to thrive is something that matters, too. But that's something society in general should work to change. But there's a difference between trying to address our own content gaps and directly handing a bunch of money to organizations without strings. At the very least something like that should be more direct (e.g. we're funding a Wikimedian in Residence position at Black Cultural Archives is something I'd personally be okay with). Clovermossš(talk)17:40, 24 January 2026 (UTC)[reply]
I feel like there's a lot that can be done if someone donates to "technology". Given all the technical debt, I doubt we'd have to worry about running out of things to allocate it to anytime soon. Clovermossš(talk)13:08, 24 January 2026 (UTC)[reply]
I watched this unfold with Framgate 6 years ago and now again with the BoT elections, but I think it's fairly consistent every time there is a WMF "controversy", you see the same recurring themes: The WMF makes a decision behind closed doors without consultation. They announce the decision late or not at all before implementation. When the community pushes back, they act like they're the ones being blindsided. They claim confidentiality and make general statements without addressing the community's core concerns. They say they are listening and request questions and feedback from the community, to which they have no intention of responding. They sometimes go as far as to issue a non-apology without accountability or any specific commitments. They claim to want to be more responsive and transparent, but it's just part of the charade. This is their strategy of crisis management: waiting it out, saying as little as possible, making empty promises, taking no direct action, and sequestering the last hardliners in some farce of a listening committee, where their complaints can be ignored more directly. That's the step we're all on now, by the way. The only thing that scared them before was irreplacable veteran wikipedians hanging it up and walking away. āRutebega (talk) 07:21, 24 January 2026 (UTC)[reply]
This is why I think it's important for me to be persistent and not give up. But yeah, there's a pattern here, and I'm not just going to accept the status quo is the way things have to be. We deserve better than that. Clovermossš(talk)13:18, 24 January 2026 (UTC)[reply]
This is my general impression; the handling of the Simple Summaries debacle also comes to mind.
I have a list of recent major WMF disputes (if I'm missing one, please tell me). The pattern is clear: after outcry, the WMF either backs down or quietly proceeds and hopes no-one notices. These are both backdoor options for them, because neither involves actually engaging with us or negotiating. Cremastra (talkĀ·contribs) 01:08, 26 January 2026 (UTC)[reply]
I am not a power user here, but I would like to chip in. I didn't know much, so I would just say simple things. First of all, Wikipedia should be run more as a tech company rather than some giant non-profit company. It is understandable that WMF is a non-profit, but the main offering of WMF is Wikipedia - essentially a technology product. We are not Samaritan's Purse, Salvation Army, or Feeding America where the "work" is tangible and seen. The main product of WMF is Wikipedia, which is not seen physically. Our way of working should be similar to Electronic Frontier Foundation or Tor Project. This means that the main effort of the board (or whoever controlled WMF right now, the structure is too confusing) should be focusing on improving the main offering of WMF, which is the Wikipedia. The energy, resources, and the thought should be focused to improve Wikipedia. Wikipedia is not the "secondary" offering of the non-profit, but the primary offering of the non-profit. For example, while Goodwill Industries have trainings, their main offering is the job at their stores. That didn't mean that Goodwill have to abandon the job training they gave, but their main effort should be about their stores and job creations there, not the job training. I think the principle applies to WMF: Wikipedia as a product should be the main thought of the WMF. As for now, I would see that WMF is focusing more on the "activism" side and projects outside Wikipedia rather than the Wikipedia itself. Secondly, Wikipedia should be run as a professional tech company. This means that WMF have to identify further competitors such as Grokipedia or ChatGPT. As for now, the only one that seems to be concerned with these two are the editors. But a CEO/CTO of a professional tech company should be the one most concerned with competitors. The rise of AI, the use of Gemini in Google search, the speed of Grokipedia, how @grok can be cited in X, etc. should be the concern of the CEO/CTO/whoever in charge right now. I am not saying activism is bad, but if Wikipedia leadership failed to plan for the future, the whole project can be doomed to failure. I didn't see Wikipedia failing in the future, but long-term identification of threats and opportunities should be the CEO/CTO's responsibility. As of now the editors are the one who care more about Wikipedia's future, this is wrong. Third, Wikipedia have tons of money. We didn't need to beg for donation. We need to cut costs. $185 million per year for a tech company is huge. The money should be spent on "technology", not projects to correct some perceived Great Wrongs. Projects such as that must be limited in scope and funding. This goes again with #1 and #2, the priority should lie on the main product - the Wikipedia itself. Money should be spent on hiring more engineers, hiring more coders, more servers, etc. Final point: Legal activism. This is the only activism WMF should care a lot about. WMF should be litigious and vehement in defending Wikipedia and its editors. I would say that WMF should be as vigorous as ACLU (which only receives $50 million annually!) to defend Wikipedia and its editors. I would say that WMF has been quite weak in defending our editors. WMF somehow prefers an editor getting outed (where they can face further problems) than losing the market. I would expect a non-profit like Wikipedia to be blocked by a country rather than letting one of the their editors to be sent into prison. That's activism and non-profit actions, where the value of "free information" given by the editors is more valuable than presence in a market. As of now WMF did provide legal assistance, but I feel like once the chips are down WMF would gladly hand out the PID. There are lots of nuances on this matter that can't be described, but this is what I feel WMF should be focusing on. If Google - a large "evil" for-profit corporation is willing to not enter China market (which will be VERY profitable for them, China is a MASSIVE market!) because of Chinese censorship laws, surely WMF should have more guts as a non-profit company? As of now, I see WMF leadership legal approach is like a giant Wall Street company - protecting the company first. WMF as a non-profit should not be afraid to sue and get sued. It's already too long, but hopefully someone can catch what I am saying. Have a good weekend, people! ā SunDawn ā Contact me!14:14, 24 January 2026 (UTC)[reply]
I would say the rise of LLM generated text does actually seem to be a strong priority on the WMF's radar. The only time I heard anyone suggest we should be trying to "compete" with ChatGPT was Sue Gardner (who hasn't been with the foundation for awhile) in her 2023 WCNA talk, but I remember hearing both Maryana and Selena at different points talk about how more people are staying outside of the "Wikimedia ecosystem" and what that might mean for long term contributor trends (if people are asking chatgpt questions and never go to wikipedia articles directly, they're not going to edit them or make donations). If I'm being cynical, there seems to be more emphasis on the latter, but at least I have heard the former. I have to agree with you when it comes to PII. There's been two very high profile cases that left a lot of people feeling betrayed when it comes to the values the movement is supposed to espouse. Clovermossš(talk)14:51, 24 January 2026 (UTC)[reply]
I disagree strongly - Wikipedia should not be operating like a tech company, and there's a direct line from doing that to enshittifying the product. Gnomingstuff (talk) 19:50, 24 January 2026 (UTC)[reply]
I don't know that a long, diffuse airing of grievances is going to help move relations forward, and probably more likely to intensify the beliefs of those who have the grievances in the way putting a bunch of people who don't like a particular politician serves to intensify beliefs. The framing is about relations, but [almost] none of this thread looks at the other half -- our end. Here's my advice: start there, in a separate thread that focuses exclusively on what's fully under our own control. Come to a consensus about where we could've done better, list some common pitfalls that lead to counterproductive tangents and distractions or otherwise complicate these relations, and set forth some best practices for communicating with the WMF. It might be useful to structure discussions, to avoid counterproductive tangents, etc., not to mention providing some structure for the WMF to go by (which is one of the common problems with these threads). My sense is that the "we always do everything right" perspective is a minority one, and that such a thread might bear fruit if it doesn't turn into another airing of grievances. Find consensus about our end, and use that consensus and any guidelines it lays out as a good faith starting point when we ask for changes from the WMF. Give them a clearer idea of what to expect and what to look for. There's no shortage of complaints for them to navigate as-is, but we never try it the other way -- maybe it's time. ā Rhododendritestalk \\ 18:26, 24 January 2026 (UTC)[reply]
I've been repeatedly asked to be more specific, by more than one person, in these conversations. So it seems pretty clear to me that this is genuinely what they want, a list of problems and possible solutions. It doesn't have to be confrontational, but it's hard to work on problems that are scattered across a million different venues. I'm not saying the community always treats staff all that well (the warnings about civility on this very page exist for a reason), but I think there does need to be stronger action when it comes to WMF side in a systemic way. I don't think most people in this thread hate individual employees or anything. I also don't think criticism means you have to be anti-WMF. This is all being done in good faith. I think it's important to be up front and direct to actually get somewhere, especially since I've been explicitly told that vagueness is not helpful. Clovermossš(talk)18:35, 24 January 2026 (UTC)[reply]
I'm not saying I'm going to go point towards this thread every time I have these conversations, but this thread has been tremendously helpful in trying to figure out "pain points", and I hope people keep contributing to it. When people are frustrated, that doesn't just go away because the controversy itself has sort of fizzled out. I intend to write a more concise outline of different patterns and issues over time, and things that don't seem to get addressed. I've been told repeatedly that people are willing to listen. If that's sincere, I think it makes sense to actually show why so many people don't feel like they have been listened to. I had a long conversation with a staff member at WCNA that seemed genuinely confused that large portions of the community have this pent up distrust. I do think I could write a "communicating with the community" page sometime to help people avoid obvious pitfalls (e.g. ask people what they need or what do you think we could do better instead of just saying we're listening without changing anything). Clovermossš(talk)18:50, 24 January 2026 (UTC)[reply]
@Rhododendrites, @Clovermoss There is the PTAC doc on it which summarizes kinda community concerns and WMF folks concerns for the P&T department. For what it's worth, I see good progress on the general recommendations from the WMF with discord calls, VPT discussions and the recent call for comments for the annual plan (we are slightly lacking on the community side of things, but I hope to recruit more people who are able to do championing of specific features slowly). No idea about the rest of the movement (or even non-P&T entities like Wikimedia Enterprise). Sohom (talk) 19:01, 24 January 2026 (UTC)[reply]
I've noticed the increased reliance on discord. I think it's great that certain staffers can feel more approachable in that way, but I worry about all the stuff that only gets brought up in these sort of inner circles. I was really bothered by the fact that the WCNA board of trustees conversation only recorded the initial information part and not the "breakout sessions" where people asked questions and answers. It makes it difficult for people who are not physically present to engage in those conversations. It also looks bad from a transparency angle. I noticed this trend again with the recent meeting OwenBlacker and I attended. I think we were the main two community members there to my recollection. But none of the Q&A stuff was recorded. I have no idea if the concerns I brought up about how it looks from the outside looking in about getting rid of the Community Affairs Committee is in the minutes or whatever. So, so much important stuff gets relegated to mailing lists which is how I was even aware that this meeting was going on in the first place. Clovermossš(talk)19:51, 24 January 2026 (UTC)[reply]
Can't necessarily comment too much on the BoT stuff, but I think it's been a standard practice (in all orgs) to not record meetings where folks are expected to talk more freely with individual members. Recording discussions/transcripting meetings is akin to being on-the-record.
Wrt to the Product and Technology side, from what I've seen, almost every discord discussion is followed up with a onwiki discussion where a lot of similar points get reiterated (based on the ones that I've been a part of). I don't think discord is being used as a mechanism to evade accountability in the context of P&T but to see if a more younger demographic brings up other points/blind spots. Sohom (talk) 20:18, 24 January 2026 (UTC)[reply]
Standard practice doesn't make it right. We got the "this is standard practice for other organizations" comment when a board member was asked about media checks, which side-stepped the issue. Keeping these things obscure gives the community almost no power when it comes to follow-through. Open public relations like this should not have to be treated as if it's strictly confidential information. And to be quite frank, I feel like if what Maryana had said to me had been livestreamed, there would've been a ton of community pushback and rightly so. People shouldn't have to work their own schedules around being at the right places at the right time to feel like they have a chance to have a say. Clovermossš(talk)20:35, 24 January 2026 (UTC)[reply]
I'd point out a lot of open source projects have the opposite standard practise e.g. Apache's if it didnt happen on the mailing list it didn't happen policy. While Catcham house style meetings can have some advantages - it can allow people to express ideas that aren't socially popular, it has a disadvantage that it lacks accountability. This is especially true when there is mistrust between the parties as there is between community and WMF. The community naturally wants assurance that WMF isn't misrepresenting (or misemphasizing the popularity of a view) the views expressed in the meeting. Anonoymous meetings do little to assure the community that their views are being represented and considered properly. Bawolff (talk) 10:18, 25 January 2026 (UTC)[reply]
our end of "community-wmf relations", which is a different subject from "what has the wmf done wrong over the years". Maybe people want the latter - I just wouldn't expect it to improve relations if that's the intent. If the goal is a todo list, that's worth doing, too. I've advocated for a centralized list with strong consensus in the past, but it's also a different (though obviously related) task than improving relations. ā Rhododendritestalk \\ 18:50, 24 January 2026 (UTC)[reply]
I think a lot of this tends to be a sense of not really having anywhere to go factor to it, if that makes sense? People will say things on noticeboards and what not but not often get a chance to have meaningful conversations unless they have some way to get their foot in the door or have connections. Stuff like the Conversation with the Board of Trustees only happen so often and aren't well publicized. I attended the last one and someone brought up that more participation wouldn't nessecarily be a good thing because there's only so much time for questions. A lot of where someone might go for help beyond trying to figure out how to file a phab ticket can be a bit like walking through a maze, and not everyone is nessecarily technically inclined in the first place. I get the sense that the foundation feels like it's approachable and in a sense, it is, if you know where to go. But even I struggle with that and I'm more immersed than most. I've thrown the idea out of a "community advocate" before because someone really could be having these conversations full time. If people want to repair the relationship between the WMF and various communities, it's not just going to happen on its own. It's going to take time and work to repair those relationships. I'm not saying they're not trying. There has been more attempts to ask for people's feedback in recent years. But it seems somewhat half-hearted to me. There needs to be more on an active push in that direction, from my perspective. Clovermossš(talk)18:59, 24 January 2026 (UTC)[reply]
I think this gives a lot of insight in the communication problem. From the community side, I feel like there's frustration with the WMF's reluctance to engage with discussions on-wiki: now obviously, there is engagement, in the form of various staffers with (WMF) in their usernames. But it generally feels like we're not really having a discussion, because the people sent here to talk to us don't really have decision-making power for the WMF, they're usually just messengers. Which, incidentally, is a literal definition of discussing in bad faith (at least in contract negotiation contexts). WMF staffers have a vanishingly low footprint within the actual editing community, and frankly that's baffling, both by virtue of the amount of resources they have and the ideals that this project and WMF jointly profess. I would expect a much larger contingent of WMF staffers and leaders to at least casually participate in the community, as the community, but in general, they don't. signed, Rosguilltalk19:16, 24 January 2026 (UTC)[reply]
I think this is an important matter as well. The way I see it, WMF staff only comes around when the fire is too hot to handle, and the ones that are coming usually didn't have any authority to effect any changes. I didn't feel that the CEO understand the community as well. If they never edit, never engage in community, never sees what is going on, how come they will understand what is Wikipedia? ā SunDawn ā Contact me!05:17, 26 January 2026 (UTC)[reply]
I feel that way too sometimes, about the lessening overlap. I think that WMF of 15 years ago had a greater proportion of editors on staff, but also, would anyone argue the WMF was more in touch with community attitudes back then? Perhaps it was less formal, with fewer rounds of review for anything posted on-wiki, but given how much scrutiny and how little leeway staff get for their on-wiki comms, it's also hard to blame them for that. I hope that they would recruit from the community of active editors as much as possible, but for anyone who wasn't already an editor, I do get why starting to do so would be intimidating. The hard-line anti-WMF camp is a minority, I think, but a very loud and very vigilant minority. For anyone who thinks it can be intimidating to be a newbie in general here, imagine being a newbie while (a) having your volunteer edits reflect on your job, and (b) your job causing increased scrutiny of your edits. Not so appealing. It's one of those areas where we should actually figure out if there's consensus that we want WMF staffers to edit more, and then to create the conditions for them to do so safely, without holding their job against them when they make mistakes. One of those "best practices" we should figure out on our end that I was alluding to above. YMMV. ā Rhododendritestalk \\ 19:53, 24 January 2026 (UTC)[reply]
I feel like there's frustration with the WMF's reluctance to engage with discussions on-wiki: I will echo what in a stronger manner what @Rhododendrites said. "We, the community" are the reason WMF employees do not engage with the community. The community has a longstanding (and currently ongoing) history of being uncivil to WMF staffers. To quote what I wrote to @Chaotic Enby at some point after Simple Summaries on discord, the problem is that onwiki, WMF feature announcements are effectively feel like a CT but none of the admins treat it as such (and often even turn a blind eye to what would otherwise be blatant aspersions)Sohom (talk) 20:01, 24 January 2026 (UTC)[reply]
(edit conflict)I strongly disagree. I have been stonewalled on multiple issues ranging from the WMF spending decades breaking the laws against discriminating against the handicapped to asking for transparency regarding the least important and easiest to document spending I could think of to asking the WMF to justify ignoring the clear wishes of the community regarding user privacy. Again and again I have been told that it's my fault. If I was only nice enough or asked the right way I would have gotten an answer. So I have repeatedly recruited editors who are incredibly nice and unfailingly polite to ask, and they got stonewalled as well. It is not even remotely plausible that every WMF employee has independently decided to completely ignore and not respond to very gentle and reasonable questions by super nice editors because someone else was mean to another WMF employee in a completely different discussion. You wouldn't like it if I stonewalled you because of the actions of someone who has nothing to do with you.
I invite you to confirm this for yourself. Pick a Wikimania and ask how much it cost, total, and for any information, no matter how vague, on what the money was spent on. Or pick something else -- anything, really -- that you think would be easy to answer. Show us how it is done. Try to get any answer on anything from anybody that works for the WMF. I predict that you too will only get silence and answers from people who are not part of the WMF. --Guy Macon (talk) 20:32, 24 January 2026 (UTC)[reply]
I'd say "I repeatedly called them cancer in many different venues and then they didn't do what I wanted them to do" is a good example of what Sohom and I are talking about in this subthread. Before we go off on a tangent, I support more transparency, and agree that should come even when not phrased nicely; what you're disagreeing with here, however, is the idea that we make it hard for them to participate by creating a hostile atmosphere (by, for example, phrasing financial criticism as "you are a cancer"). ā Rhododendritestalk \\ 22:38, 24 January 2026 (UTC)[reply]
I categorically deny the above accusation. "You have cancer" is not the same thing as "You are a cancer". I say this as a cancer survivor. Also, I find it to be completely implausible that every single WMF employee that gets asked a question -- often by other editors who never mention me -- has read my essay, has never spoken up about disagreeing with it, and yet has decided that the appropriate response is to stonewall the entire Wikipedia editor community no matter how nice and polite they are. It's a theory that goes against everything we know about human nature. --Guy Macon (talk) 03:24, 25 January 2026 (UTC)[reply]
Show me how it is done. Pick anything the WMF has ever spent money on. Big or small, recent or ancient, important or trivial -- your choice. Ask them how much they spent and what they spent it on. Don't just be polite. Grovel. See if you and you alone are able to get any answer other than silence. Then any only then come back and tell me that it is my fault and that I asked the wrong question, asked it at the wrong place, or asked it the right way. --Guy Macon (talk) 03:36, 25 January 2026 (UTC)[reply]
You're on that tangent I was trying to avoid. The point being made in the comment you replied to is just that we make things needlessly hostile, so should not be surprised that the WMF is not excited to engage casually on-wiki. You disagreed strongly, but it's not clear why. As for the cancer framing, when I read More concerning is the fact that since 2005 the WMF has hired hundreds of extra employees and is now spending 1,250 times as much overall, which seems rather excessive considering that the actual amount of work they have to do is pretty much the same. WMF's spending has gone up by 85% over the past three years. Sounds a lot like cancer, doesn't it? - That wording sure sounds like the staff are the cancer. Elsewhere the chapters are [part of/symptom of] the cancer, etc. Regardless of whether it's the people or the organization that's made of people, or merely the way the organization spends money [such as money spent on people], the framing is openly hostile (which is not news - you have been dismissing those objections for the better part of a decade now). That doesn't mean it's a bad essay or that you shouldn't be allowed to write it/host it, or even that I disagree with some underlying points -- just, like, don't be shocked that the cancer doesn't love hanging out in a place where they're being called cancer, you know? ā Rhododendritestalk \\ 04:32, 25 January 2026 (UTC)[reply]
I don't know why you think as a member of a public, grovelling to random staff is going to get you answers. I would welcome more transparency, but that should go through official channels. I'm pretty sure that if a random staff member told you confidential financial data simply because you grovelled, they would at the very least be fired if not facing legal troubles.
In many ways, i think much of your criticism is not very hard hitting because it would still apply even if WMF was actually doing everything right.
To give a literal answer to your question though, I think we do know that the structured data on commons project cost WMF $5,115,000 USD over 6 years, because it was grant funded and the grants are public [39][40] [I can't prove that WMF didn't chip in additional money outside the grant, but my impression is they didn't]. Sadly this does seem a waste to me as the project seems to have failed, largely due to usability issues making it not fit with the needs of commons and still only being half done by the end of the second grant. Bawolff (talk) 07:08, 25 January 2026 (UTC)[reply]
Re: "grovelling to random staff" and "going through official channels", I have asked my questions at every place and to every person anyone suggested and received silence. Give my specifics as to what you believe these "official channels" are and I will do it again and get the same result.
Re: those sloan grant documents, are you seriously claiming that $2,100,000 "To support the extension of structured data from Wikimedia Commons across all Wikimedia content, improving the search function and making it easier to read, edit, and access knowledge" and $3,015,000 "To transform Wikipedia Commons' media files from free text into machine-readable, structured data, enabling new uses for millions of media files on Wikipedia and across the web" is an example of revealing how much was spent on something and what was bought with that money? Show me the proof. How many media files were transformed from free text into machine-readable, structured data? Where can I access the free text versions and the machine-readable, structured data and spot check a few to see how well the conversion went?
I did not say you should go through offical channels, i said "that" as in the disclosures, should be done through official channels. I do not think you as a random member of the public should be able to direct what financial information WMF discloses. Disclosure should be based on policies set by the board and not done on an ad hoc basis. I think its reasonable to petition the board to set better generic policies. However it is absolutely unreasonable to demand WMF answer specific questions about whatever you feel like in the moment.
Re structured data on commons. Based on your response you seem to have no idea what that project is or what its goals are. I would suggest you read the on wiki documentation. is an example of revealing how much was spent on something and what was bought with that money? Its an example of revealing how much money was spent on a project. It is a grant document so it obviously doesn't show what the results of the project was. However the project was to create a software feature for wikimedia commons. The software feature is live on commons. You can use it and see for yourself what the money "bought" (to be clear im not neccesarily defending the project as a great project, as i personally am unhappy with the results. I'm only saying its a project we know the budget of). Show me the proof proof of what? The project was to create specific software and said software now exists. You can use it yourself if you feel like it. How many media files were transformed from free text into machine-readable, structured data? What exactly is the relavence here? The WMF was not transforming files. None of the money went towards that. It is the community's job to edit content not WMF. Arguably this as a metric speaks to how sucesful the project is, but the question was pick a project and find how much money they spent on it and what they spent it on. Questions like if the project was a good idea or if it worked out the way people hoped, are entirely separate (that said, to answer the question, nearly 100% of files have at least some metadata in the new system but adoption of the system for useful metadata is mixed). Where can I access the free text versions and the machine-readable, structured data and spot check a few to see how well the conversion went? Its not a conversion so this question doesn't make sense. However like all edits to a page you can use the history tab to get a diff. Where is the page from 2020 that documents the end of the project, what got accomplished, and whether they went over or under the budget? While I appreciate you might want project reports and whatnot, i think that goes quite a bit beyond what your original question was asking. Bawolff (talk) 08:58, 25 January 2026 (UTC)[reply]
I read the Diff post and it seems like the money the WMF used came directly from a grant elsewhere (the Alfred P. Sloan Foundation)? I've used structured data on Commons when uploading files so I know it exists, although I can't speak to the usefulness of it. It's disappointing to hear that it doesn't seem to have supported the needs of that community. I've heard that Commons has also had trouble getting official support for Upload Wizard. PTAC seems interested in taking some steps to address that, but it's a bit surprising that the main feature of a project didn't seem to have anyone from the WMF who could provide technical support for it for several years, to my understanding. Clovermossš(talk)13:28, 25 January 2026 (UTC)[reply]
@Bawolff: just an aside on structured data on commons: there are people who can say more about this than me, but my take isn't that it's a project that failed but that it's a project that was simply never completed. That's a kind of failure, I suppose. Maybe it turned into a bigger and more expensive project than they thought, but the issue wasn't that the idea was bad; the issue is that it stopped, so nobody got what they wanted. It's the sort of project that has big implications for simplifying/improving volunteer workflows, including potentially better interfaces between commons and wikipedia, better tools, and most of all better usability of media, which isn't always the easiest to find/use on Commons. It got a partial roll out, people asked ~"will this make our lives easier" and heard ~"yes, eventually, but for now it creates additional work until we're done building it". So it didn't get the warmest reception, and that might've contributed to lack of interest at the foundation. One of my biggest criticisms of the WMF over the past few years has been neglect of Commons, but that's obviously a discussion for over there. ā Rhododendritestalk \\ 14:58, 25 January 2026 (UTC)[reply]
On one hand, this is kind of fair, but on the other hand, they worked on this for 6 years. I think running out on money on something you had 5 million dollars over six years to do suggests a planning failure. At the very least, I think they should have put more thought into building things in separate stages that were all minimal viable products so that what was produced would be useful even if it was cut off before being finished. A metadata system that doesn't support querying, even in the most basic form, is not a useful system (I mean that from the end user perspective, yes i know there is a half-maintained sparql endpoint, but i mean there should be something for depicts to get a list of other media depicting the same thing that is equivalent to clicking on a category link. The original pitch was to replace category links after all. If a system lets you organize media but not see the results of that organization, is it really organizing anything?). I honestly think that even with just very minor UI changes, SDC could be a much more effective product. Bawolff (talk) 15:12, 25 January 2026 (UTC)[reply]
I think it's less the engagement when it's a big "community and the WMF" discussion that I'm thinking of here though--I agree that those get contentious and can totally see why the WMF engages with them the way that they do. I wish I saw WMF staffers doing normal editing and governance things, demonstrating that they understand and care about editing--not as the monolithic WMF but as individuals. That's what I meant by "as the community". I think this sort of engagement would aid communication when it is time to do big "community and the WMF" discussions. signed, Rosguilltalk20:04, 24 January 2026 (UTC)[reply]
As someone who was actually present for the Simple Summaries discussion: what was the "incivility" there, specifically? Be specific. Name names and quote it. Gnomingstuff (talk) 20:11, 24 January 2026 (UTC)[reply]
@Gnomingstuff When I say "after Simple Summaries", I don't mean immediately after it or necessarily causally linked to it. I mean "at some point in time after that". But sure, lets see:
WMF staffers looking to pad their resumes with AI-related projects need to be looking for new employers - 1
I think we should start thinking seriously about forking, and hosting the project in a more transparent and hands-off way (and possibly not in the US). The WMF has been showing hostility and disregard towards the community for many years, and it's only a matter of time before the community loses control of the project completely. - 2
I suggest revoking all donation banner permissions until such time as everyone employed by or elected to WMF and affiliate roles with generative AI COI or positive views towards the same are terminated and prohibited from holding elected office. - 3
Are y'all (by that, I mean WMF) trying to kill Wikipedia? - 4
Anybody on the team who thought this was a good idea for even a second should step down. Absolutely braindead. - 5
Now now... are y'all planning on replacing your volunteer editors with AI š? - 6
This was based on a initial scan. I typically shy away from calling specific people out but I think the fact that non of these comments received any pushback illustrates my point. In literally any other situation these would be considered aspersions breaking WP:CIVIL.
For what it's worth, to expand a bit on why I said what I said, anecdotally, a lot of onwiki discussions involving WMF staff take a very adversarial tone which makes it really hard for folks on the WMF side to engage further. (To give a example of one of your comments in the recent semantic search discussion, it becomes really hard to engage with you in a back and forth when you make a remark like (But I guess these are just "Internet pundits" and the feature isn't for them.) which while not explicitly against the WP:CIVILITY policy is definitely less than ideal for starting a fruitful conversation and leads to people not wanting to engage. This is not to say you should not pushback against obvious problems (and I do appreciate you showing up to identify the Google AI-like mockups), but rather the tone and way the pushback is given matters a lot! Sohom (talk) 21:22, 24 January 2026 (UTC)[reply]
And here we just have a fundamental disagreement, I think. Behavior matters as much as words, and usually matters more. Not to relitigate the issue, but acknowledging out loud in public that the community and the press are not going to like or want a feature, and then moving forward with it anyway, is fundamentally uncivil behavior. (Like, even using the phrase "internet pundits" is dismissive from the start! How is this still unclear?) The comments quoted above are a proportionate response; some of them are rather polite given that the inciting event was essentially "we already know you won't like this, but we don't care."Gnomingstuff (talk) 23:23, 24 January 2026 (UTC)[reply]
acknowledging out loud in public that the community and the press are not going to like or want a feature, and then moving forward with it anyway, is fundamentally uncivil behavior not in itself (imo). There are situations where tough technical decisions need to be made (case to the point, Temporary Accounts (privacy over community) or Vector22 (technical UI debt/readers over community) ). As a volunteer dev, I myself had to take a few of these decisions in (including one over Christmas, prioritizing security over community "liking it", check back in mid 2026 to figure out how I did). It is something that comes up in basically every non-trivial community-facing tool. In the case of Simple Summaries, we can say with hindsight the decision made was wrong, and done in a vacuum that saw very little community feedback (and thus created a propensity to assume the community was "generally fine with it"). But that does not make it uncivil and does not excuse those comments.
Wrt to "internet pundit", keep in mind that the person who wrote the ill-worded essay was not any of the people who are interfacing with volunteers. Is it fair for the people interfacing with the community to endure remarks regarding it months afterwards? Sohom (talk) 00:03, 25 January 2026 (UTC)[reply]
While i agree there are times that tough technical decisions need to be made, I don't think most disputes resolve around them. Most (not all) security, performance or legal concerns have work arounds, although they may be expensive or not worth it. In my experience the community is relatively accepting of blockers preventing doing something provided it is clearly explained. Big disputes usually concern product direction and not implementation decisions. Bawolff (talk) 00:38, 25 January 2026 (UTC)[reply]
(edit conflict) I'm very confused about what the problem with example #2 is. I genuinely don't see how you can even say the tone of it is off. We have a right to fork. I find it concerning that you would find that comment specifically uncivil. The internet pundit one seems like someone who is frustrated and genuinely feels like they don't matter. I can agree with you that the others are rude and are not ideal. That said, I personally give a lot more leeway when people question me about my actual actions because I see it as part of WP:ADMINACCT. We may not agree, but people should be able to voice their concerns. Compared to what a lot of admins and even non-admins deal with on an everyday basis from vandals, these comments are very mild in comparison. Admins can see [41], which is a side effect of being a visibly female admin.
The worst example I can think of when it comes to a community member treating a staff member absolutely horrifically was this. I can understand critiquing a lack of being willing to engage with the community, but blaming the cause of all that on the fact that she's a woman is not acceptable. I'm glad that he's no longer on the project.
If the problem is that staff members feel like they're putting themselves in the line of fire, I feel like that speaks to need for some person people feel comfortable going to to act as some in-between. I know I occasionally have had staff tell me things in private because they're afraid that saying so publically will have implications for their career, and that's concerning too. I also don't think it's fair to the individual employees in question who may be trying their best but don't really have any power when it comes to the decision making process because people might wrongly take it out on them simply because they're there. I have a lot of experience with food service jobs and I understand what it's like to stay calm in the face of that, even if it's not fair. If the WMF wanted to tell me absolutely everything that is going on that is affecting every wiki, I'd do my best to get to talk to every community involved, actively solicit feedback, and be a go-between. I don't think that the person in question has to be me, but if the foundation is willing to give me a job for that crazy amount of work, I'd be willing to do it. Regardless of who does it, I think it's something that would be a tremendous step forwards. Clovermossš(talk)00:04, 25 January 2026 (UTC)[reply]
Compared to what a lot of admins and even non-admins deal with on an everyday basis from vandals, these comments are very mild in comparison. If your comparison metric is vandals, then we are obviously better. If the comparison metric is "civil discussion on a talk page" we are in the red. Not every discussion with the WMF needs to feel like a WP:ADMINACCT tennis match. (the fact that it does is kinda the problem)
If the problem is that staff members feel like they're putting themselves in the line of fire, You've hit the nail on the head.
I feel like that speaks to need for some person people feel comfortable going to to act as some in-between. I feel like I do a lot of this at the moment (atleast on the P&T side). Sohom (talk) 00:58, 25 January 2026 (UTC)[reply]
I'm not saying it's good, but I'd say it's at least a sign people are trying to be deferential if normal talk page discussions can have a bit more edge and you take into consideration that what admins consider improper in regards to civility is typically at a higher threshold. The fact that things are so tense is a waving red flag that steps need to be taken to make people feel like something is actually being done, because that's the only "real" way to address the root of that problem. I'm glad you're trying to be an in-between for PTAC specifically, I try my best to be that kind of person myself. But I think it's something that is a lot of work and not something we should feel morally obligated to take on, especially as unpaid labour. I spent about 40 hours talking to people total in the general timeframe around writing my petition on Meta because I genuinely wanted to understand what upset people about the board. There's so much history that's reliant on word of mouth because no one is keeping track of it in a centralized place. There's more than enough existing tension regarding communication for several projects that this could easily be a full time role. I think having an identifiable person to make grievances to would help smooth some of the rough edges out. It'd also help with institutional knowledge. I know one of the first things I'd want someone like that to do is make the maze less of a maze and help create a paper trail akin to Bulletin newsletter. I also think it would be a meaningful gesture that the WMF cares about maintaining a healthy relationship with the projects by actively doing something like this. Clovermossš(talk)01:15, 25 January 2026 (UTC)[reply]
re If the WMF wanted to tell me absolutely everything that is going on that is affecting every wiki, I'd do my best to get to talk to every community involved, actively solicit feedback, and be a go-between - in defense of WMF here, it can be really difficult sometimes to know the right level of detail. If you tell people literally everything they get annoyed quickly because its too much irrelevant information. Most people do not care about most changes because most changes are really boring. If you really wanted to know about every single technical change, you can look at the the list of gerrit merged changes - https://gerrit.wikimedia.org/r/q/status:merged (This is essentially the tech land version of Special:RecentChanges), but its a lot, and it is also a lot of effort to translate the technical change into what it really means. Of course, separately from each individual technical minutia, people want to know the higher level changes in technical plans and goals, which is something I feel WMF has become more opaque with over the last few years (rip ArchCom/TechCom/TDF) Bawolff (talk) 14:29, 25 January 2026 (UTC)[reply]
TechCom would be nice! And yes, there is just too much too do (and happening) in the tech space, my approach has been to only engage the community in larger feature announcements/product direction and such. (Sometimes smaller bugs are relevant, but in most cases they signal a lack of ownership/stewardship of the underlying codebase). Sohom (talk) 14:45, 25 January 2026 (UTC)[reply]
I'd point out though that lack of ownership is in my opinion a management failure from WMF. Its everyone going hot potato. WMF is in a privileged position because volunteers fill in the gaps and do a lot of glue work. Most tech companies can't afford to just throw up their hands and say half the codebase is ownerless. WMF can because the volunteer base protects it from the consequences of that management decision. Bawolff (talk) 05:50, 26 January 2026 (UTC)[reply]
I don't get annoyed at that sort of thing, which is why I think I'd be the perfect fit for that type of role. I love knowing every boring detail possible and trying to organize it. I also think it'd be very useful to know the pain points other communities have because generally speaking I think it'd be incredibly meaningful to these other projects if someone cared because they feel like enwiki gets what limited attention there is. I think a human touch for when people want to get involved and who can actually answer their questions or know where to go to get answers would be a good idea. Clovermossš(talk)16:49, 25 January 2026 (UTC)[reply]
just a correction: the "internet pundit" comment is originally by someone at WMF, not by a member of the community. I just find it breathtakingly dismissive: pre-emptively shutting down the objections of anyone who might disapprove of the feature online (i.e., readers). Gnomingstuff (talk) 23:41, 25 January 2026 (UTC)[reply]
+1 on that. The internet pundit comment originated from WMF folks writing a very badly put-together (and dismissive) essay not from a community member. Sohom (talk) 00:39, 26 January 2026 (UTC)[reply]
While community incivility does play a part, from what I've heard there's also the fact that WMF management has increasingly been telling people that publicly disagreeing with the WMF company line, even with a clear volunteer hat on, is not compatible with continued employment. That's not a good environment for getting staff to contribute to the projects. Anomieā04:26, 25 January 2026 (UTC)[reply]
Yes, I've heard that too. It's what I was implying with I know I occasionally have had staff tell me things in private because they're afraid that saying so publically will have implications for their career, and that's concerning too. I mentioned that some people feel afraid to openly voice criticism when I had my conversation with Maryana (although mostly in an affiliate context) and she said it was hard to talk about fear and what exactly causes people to think bad things will happen. When I brought up this concern when I had my conversation with Selena, she told me that she would investigate such behaviour if people came forward to her with concerns. I'm not the type to want to break people's confidence, but I wanted to say that at least on paper there seems to be some support for that to not be what should be going on. But I admit there's a part of me that's wary of accepting that's the case no questions asked. I've dealt with work environments IRL that are totally against a bunch of stuff on paper when things that are clearly against that were happening out in the open at the same time. When I was at WCNA, Lane told me that he was asked by the WMF not to say anything about the elections. I've brought this up to a few people who seem to think that the board not disclosing things is all about confidentiality, but if that's the case, why was Lane under the impression that he wasn't supposed to talk? He clearly did so before something happened to make him change his mind and I worry about what that might mean when it comes to people's behaviour behind the scenes. Clovermossš(talk)04:41, 25 January 2026 (UTC)[reply]
Also, even if Maryana and Selena were against it, that doesn't mean other people weren't doing it despite them. WMF in my experience has had a big problem with "managers" who seem primarily concerned with managing their own career advancement. Anomieā14:00, 25 January 2026 (UTC)[reply]
Re: "I do not think you as a random member of the public should be able to direct what financial information WMF discloses", in this specific case the "random member of the public" is actually hundreds of the unpaid volunteers who make the encyclopedia possible and "what financial information WMF discloses" is actually zero disclosure except for generalities like lumping desktop computers, servers in the datacenter and office chairs into one huge "money spent on computers and furniture" entry in a required financial disclosure document.
In addition, it is not just financial disclosure I am asking for. For over a decade (others have been asking for 20 years) I have been asking the WMF for a comment -- any comment -- about a specific case where they are clearly violating federal law by discriminating against the disabled. The violation is something that that other organizations have been successfully sued over for millions of dollars for doing. The result: total silence from the WMF and the usual noise from non-WMF individuals who are in no position to answer the question or change the policy. --Guy Macon (talk) 15:56, 25 January 2026 (UTC)[reply]
I assume this is about the CAPTCHA system, and in that case progress has actually been made recently; we're moving toward hCapctha replacing our old text-recognition system. I personally think that's an example of a recent bad trend in which Wikimedia has lately been moving toward doing things in a more corporate way and moving away from its other values of radical open-sourceness and freedom, but it at least will solve that specific issue. * Pppery *it has begun...17:23, 25 January 2026 (UTC)[reply]
For what it's worth the SuggestedInvestigations model and spam/abuse detection is one area where having some non-open things make sense on a case-by-case basis. The hCAPTCHA system was a fair bit different because besides being closed source it was a case where our data was going to third-party providers. I'm yet to see folks outside the abuse detection/PSI space use non-open-source components. Sohom (talk) 19:07, 25 January 2026 (UTC)[reply]
We can hurt their pockets by hiding the donation banners using the common.css file. After all, if they aren't here to build an encyclopedia (or a dictionary, or a free image gallery, etc.), they don't need to make money off our projects and hard work. ChildrenWillListen (š talk, š« contribs) 17:09, 25 January 2026 (UTC)[reply]
I am surprised that Clovermoss has set this up in a way to be a discussion about Community-WMF relations rather than Community-Board relations since that's what the original petition was about. In the same way that our fate as a community is intertwined with the Foundation but we are a separate actor, so too is the Board a separate actor from the Foundation. Now the Board does of course have far more control over the Foundation than we have or the Foundation or the Foundation has over us, but for me when looking at issues and problems conlfating the two makes solving real problems harder. I would say I think the Foundation has moved from a grade of 55-65% to one in the high 80s since 2018 (when I started editing consistently). I have some things I don't like about what the Foundation does (don't get me started on what the Foundation has done to the Wishlist) and I have a dislike of how hard it can remain to stop the Foundation from harming the community at times - in another forum I should really document my experience with the Foundation around the Incident Reporting System - but unlike with the experiences Guy documents below and others have documented above I find the Foundation genuinely listens in the end now. And in places they take a firm line that something needs to happen regardless of what the community thinks they devote real resources to trying to achieve their ends in a way that harms the community the least. I see major progress from Vector 22 - as the last time the Foundation forced a huge change on us - to how they approached IP masking and even with Vector 22 I see real improvement over other similar past initiatives in terms of post implementation support. Things like Simple Sentences are maybe not stopped as early as would be ideal, but they are stopped sooner they have been in the past.
I do, however, have far greater concerns about the Board. It is not clear to me that the board believes in the democratic principles I think the volunteer community (across projects) does. Only in the rarest of circumstances do we get any sense that they vigorously disagree with each other in search of the right path or best idea. They - not the Foundation - are the ones who removed candidates and subsequently told them not to talk. I temper that grave concern with the conversations I had with a couple of board members at WCNA who were genuinely listening and who have a desire to do better. So I hope by the time the next board election rolls around in a couple of years we'll have seen progress on this front. I also hope that we will have seen that the Board has directed our new CEO to continue the positive direction the Foundation has started to take in terms of of allocating resources and being responsive to the editing community. Best, Barkeep49 (talk) 18:11, 25 January 2026 (UTC)[reply]
I started the conversation the way I did because a lot of the time, these two groups are not easily separated from each other when people have discussions. When Rhododentrites was talking about how a to-do list would be more useful than a list of grievances, I was sitting there thinking that those two things are very intertwined for a lot of people. People are naturally more inclined to be upset when there's a lot of things they've been waiting on for ages and no one is listening to them or prioritizing that work. So this conversation is set up the way that it is because I noticed people often complain about the WMF when I talk to them about the board and vice versa. Even I'm not immune to that. I'm glad your experience has been great, but I saw a lot of talk and no action and side-stepping and "nothing can be done" at WCNA. I think Rutebega said it best in their comment. I definitely see a sense a progress in the WMF does whatever they want no matter what transition into they sometimes listen if people kick up enough fuss and sometimes solicit some feedback ahead of time, but even if the latter is better it's not something I'd grade as highly as you do. It's more of a bare minimum to me. I think part of this has to do with how if one is immersed in behind the scenes stuff, the WMF at least feels somewhat approachable in a way that the board does not. But I find most people who do not attend meetups and conferences do not have that impression. They don't know anyone they can talk to and tension just builds up in the background. Problems don't go away just because no one is talking about them. It's impossible to describe how strange it was witnessing this disconnect when I first started going to conferences in the past two years, especially at wikimania. Clovermossš(talk)18:22, 25 January 2026 (UTC)[reply]
I did not write that my experience has been great with either the Foundation or the Board. I certainly agree the Board and the Foundation are intertwined. But so is enwiki and the Foundation. Being intertwined does not change that all three of these groups are their own actors. By doing an airing of the grievances for both, I think it makes it harder to solve the problems identified and actually makes it more likely that things build up in the background because any talk that is had is unproductive. Best, Barkeep49 (talk) 19:00, 25 January 2026 (UTC)[reply]
I was assuming that a high 80s grade meant that you had great experiences, but I guess those two concepts aren't directly related for you given your comment above. I got the impression that you felt like your concerns were at least addressed in some capacity at WCNA, I definitely did not feel like mine were at all. I suppose we'll have to disagree about how productive it is to have conversations about multiple overlapping subjects at the same time. I think it's hard if one doesn't have a holistic view, especially since one directly affects the other, in a way that is much more intertwined than the communication between the WMF and the community can be. At least to my understanding. Clovermossš(talk)19:59, 25 January 2026 (UTC)[reply]
The conversations I had gave me hope that maybe the board does believe in democratic principles and will act differently in the next two years. They do nothing to alleviate the concerns I have around past actions. At least not until that talk turns into new actions.Best, Barkeep49 (talk) 02:27, 26 January 2026 (UTC)[reply]
You're definitely right that editors (myself included) don't often draw a clear distinction between the WMF and the board, but I'm glad Barkeep brought it up. In reading through a lot of historical discussions recently, I would tend to agree that the stonewalling and delay tactics I lamented above predominantly come from the board, and interactions with rank-and-file WMF staff are at least on an upward trajectory. I suspect the board are constitutionally more circumspect when it comes to their public statements, and go to extreme lengths to avoid saying anything they could later have to walk back (the same applies to the legal department, for obvious reasons). It's also relevant that a substantial share of the trustees come from a corporate nonprofit milieu where our standards of openness and mutual good faith are not the norm. As a result, they can be oblivious to the extent to which obfuscation and subversion of the volunteer communityāeven when nominally to defend the foundation's interestsāactually hurts the movement and contravenes their fiduciary duty as trustees.
Theoretically, the existence of community/affiliate board seats should ensure continued observance of the movement's values, as enshrined in WMF:Principles, but evidently this system has broken down. Based on the board's usual strategy of (non)engagement, we can't expect this to resolve itself without the continuing involvement and investment of the editing community. How to proceed with that is probably the most productive direction for this discussion. āRutebega (talk) 23:20, 25 January 2026 (UTC)[reply]
I'm joining Barkeep49's experiences here: There are teams at the Wikimedia Foundation, that listen to you, take your feedback seriously, change workflows, and know where and how to communicate on eye level. So we in our groups do the same (I'm pretty sure that enwiki's ArbCom has much better experiences with the Foundation than average users who don't regularly speak with Foundation staff). ā I have summarized the WMFāstewards relationship in the annual stewards report. Certainly, I too could list countless of things that went wrong in the past, coming from the Board or staff, but that wouldn't help my future activities here. Instead, I want these good cooperations to be a role model for other interactions between Foundation and community. We can only improve our relationship when we improve it together. Certainly, we have to talk about the mistakes that were made in the past, but I hope that we will find a point in the future were we acknowledge that they happened years ago and realize that most of them were made by former employees and that Wikipedia is still running, but we shouldn't lose focus on what we could and should achieve in the future. And I am convinced that we can reach that more easily together than if we would primarily complain about the past, wouldn't treat new ideas coming from the changing world around us fair and respectful, while we still have to communicate our red lines and why we cannot change them. If we listen to each other, we will find more similarities, especially in how we want to make Wikipedia and/or the world better. Certainly, each side has to make a step towards the other and build up trust. That's easier said than done, but from my experiences in a particular area with a particular team I can ensure you that it is possible (and certainly also happens elsewhere). And if it is possible, it can likely also be reproduced somewhere else. Best, āDerHexer(Talk)18:16, 28 January 2026 (UTC)[reply]
I feel like part of the problem is communication style. Putting aside the issue of community hostility for the moment:ā when dealing with a WMF announcement, I often feel like I'm talking to a brick wall. A staffer will post some kind of bombshell announcement filled with PR jargon, then retreat in shock when it turns out to be controversial. We Wikipedians spend about 2 days shouting at each other about it before another staffer steps out, gives a bland, glossy corporate statement on the issue and then disappears again. This is not a good way to engage with people. Some staffers I feel are quite good with engaging with the community casually and honestly, but others I feel are sitting behind their desks looking down at the rabble. This perception is, I feel, a factor in the ongoing civility issues: we feel ignored and can tend to lash out, especially when the WMF continues to trot out meaningless corporate-speak. Cremastra (talkĀ·contribs) 01:01, 26 January 2026 (UTC)[reply]
Wouldn't it be great, if in those situations where an announcement goes tits up, we could send a trusted community member in to have some backroom chats rather than leaving the poor announcee with whiplash and an angry mob they don't understand or know how to deal with Kowal2701 (talk) 01:21, 26 January 2026 (UTC)[reply]
Again, I don't think this is a problem in the style of communication but the thing being communicated. The community is not made up of dogs that only know how to respond to the tone of someone's voice. At least based on the decisions I've seen, when a decision or feature is "controversial," it's because people have identified major problems with it. The solution isn't to be more casual, it's to fix those problems. Gnomingstuff (talk) 14:54, 26 January 2026 (UTC)[reply]
Putting aside the issue of community hostility for the moment:ā when dealing with a WMF announcement, I often feel like I'm talking to a brick wall. I suspect those two things are directly related. Levivich (talk) 15:02, 26 January 2026 (UTC)[reply]
In addition to the way community hostility makes communication harder, I think one limitation we have is that the "community" is amorphous. So if in a preliminary discussion 8 people show up and give mixed but encouraging feedback, the foundation may invest further resources and proceed to a new phase. At which point maybe 40 people show up and the mixed feedback turns negative. This is why ArbCom has become defacto spokespeople to the WMF even for things for outside the T&S realm, simply because it's a trusted group that has some continuity. But ArbCom can't really act or speak for the community on many of the topics that have been discussed here and at least when I was on ArbCom the committee made that clear. The m:Product and Technology Advisory Council addresses the continuity piece, but doesn't address the "can't really speak for the community piece" both in terms of mandate and in terms of the fact that the community gets no input on who is appointed to that group. Best, Barkeep49 (talk) 19:04, 28 January 2026 (UTC)[reply]
And I think it's really demoralizing for the people who give feedback over and over again when they see something that to them is an obviously bad idea. It feels like a million close calls, even if they're listening and change gears. Sometimes the "mixed" feedback is from people who are trying really hard to be polite and it's misinterpreted as if we change a few things it's fine, they just personally dislike it. I know I've met people who said they changed their tactics to be much more direct and clear (which can be more easily perceived as hostile, although some of it is less a matter of a perception... was going through the archives and sometimes people directly respond to these things with comments like "yuck"). I don't think WMF staff are intentionally trying to anger people (there's a reason they chose this job over others), but it's hard not for people not to feel angry when different people keep doing the same things and there isn't a positive pre-existing relationship to begin with. It's not a recipe for success when the only time you hear from someone is when they're proposing something you're worried is going to be the next disaster. ArbCom and people who attend conferences have direct interactions with the WMF in the way the average person does not. They may notice different staff members etc involved but they don't really see much of a difference over time the way people who are more immersed and "in the know" do. For example, I know Selena cares and asks for feedback, but I never met her before WCNA 2023. She has a handful of edits on enwiki. To people who've never met her personally, she's probably as mystifying as any other CTO. And if we want people to not be upset about patterns they notice, there needs to be a place for those feelings to go outside of the occasional product feedback request. I've summarized some of these thoughts on my new subpage: User:Clovermoss/WMF. Clovermossš(talk)19:47, 28 January 2026 (UTC)[reply]
She joined in August 2022, the next WCNA took place only three month later and was fully virtual because of COVID (likely a reason for fewer attendances of meetups as well), she attended multiple events afterwards, and we don't know about volunteer accounts. Maybe we should start with assuming good faith first, and maybe reach out to new WMF employees ourselves first in order to get them to know. I will do so with Bernadette at the Wikimedia Futures Lab, in the same way I said hello to all CEOs and shared my main pain points and how their teams could help us. In general, I prefer to have a close(r) connection to WMF staff that actually improves my work instead of the management that hopefully makes sure that these people have good working conditions (personally but also time, skills and colleagues to reach out to stakeholders like us). Best, āDerHexer(Talk)22:33, 28 January 2026 (UTC)[reply]
@DerHexer: I am assuming good faith. I'm not sure how you could think I'm not? And my whole point here is that I have met Selena at conferences and she's wonderful, but there's a lot of editors who do not attend conferences and do not have the chance to know her because she does not have an active presence here. I had been an editor for five years when I attended my first ever meet-up, and the difference with how approachable people were in that context is night and day. It's very hard for most people to actually have connections with WMF staff or even have any idea what departments there are or how to reach out to them beyond occasional feedback requests. So they're only interacting with them when they're incredibly likely to be upset already. There's no pre-existing relationship and it's hard to communicate all the things that have upset them before and so it goes where people will complain it is not relevant. But from that perspective, it doesn't nessecarily matter if different people are in charge. They're not seeing any of those changes ripple down in their direction. So it's hard to tell people to not care about what someone's predecessors did if it seems like the WMF is making the same types of mistakes over and over again. They don't get to see any changes that happen behind the scenes when it comes to leadership changes, attitude toward community feedback, just knowing people in a general sense, etc. Clovermossš(talk)00:58, 29 January 2026 (UTC)[reply]
I certainly feel - as I noted in my initial comments - And I think it's really demoralizing for the people who give feedback over and over again when they see something that to them is an obviously bad idea. ONe thing I dind't make clear in this comment is that the community didn't do anyting wrong in the "a few people weigh in, work proceeds, and then a larger segement of the community weighs in negatively". One point your comment here also brings up is the asymmetry between the volunteers and WMF staffers. It's impossible for any volunteer to really truly stay abreast of everything the foundation is doing. I get the Wikimedia Foundation Bulletin delivered to my talk page and I regularly find it overwhelming; they regularly run more than 10kb. But a given WMF staffer or team has a much smaller subset of things they need to focus on while volunteers really should be focused more on maintaining and improving our content rather than what the WMF is up to. So we end up having to make our voice heard through sheer numbers of people which I know to be demoralizing for the people getting the feedback. I genuinely don't know how to fix the communication woes because at some level better communication becomes Bulletin level overwhelm. Best, Barkeep49 (talk) 23:59, 28 January 2026 (UTC)[reply]
I agree and have previously written about how the community doesn't have just one viewpoint. This is a challenge for the leadership team of any community: it's impossible to satisfy everyone in the community, scalability problems means it's impossible to engage with everyone in the community, and in most cases it's infeasible to get a representative sample of the community. (Typically there's a large silent majority that's very difficult to reach.) For issues where there are diverse opinions, this inevitably means no matter what decision is taken, there will be a sizeable vocal group unhappy with the result. Somehow, leadership needs to reassure everyone that their viewpoints are being considered, even if in the end, the chosen approach doesn't align with many of them. Unfortunately, I don't have any new ideas on how to achieve this, beyond more understanding from both the leadership and the community of the inherent imperfections and limitations of the decision-making process. isaacl (talk) 23:27, 28 January 2026 (UTC)[reply]
The silent majority isn't always in agreement with those changes, though. I've met quite a lot of people who are upset along with the rest of people saying something, but don't feel like there's any point in even trying to communicate that. They're too jaded and they tune it all out. Obviously different segments of the community disagree with each other on various subjects, but there are some things that have widespread agreement that people that don't have that background regularly miss. Even if it's not out of malice. For example, the repeated debacles with AI experimentation. Different people were involved every time and didn't seem to have any idea how controversial community reception to that would be. I'm sure they thought these were good ideas and were not acting out of malice. If there was a dedicated person to go to to ask "hey, how do you think reception to this feature would go?", it doesn't have to be a hard no or yes all the time, but they could spot what to them would be obvious red flags and save a lot of community drama from happening in the first place. As for impossible to engage with everyone in the community, it doesn't have to be. I'm trying not to shill my idea too hard here, but having that be someone's job would give those feelings a place to go. Time only heals old wounds if they're not being ripped open. But if someone feels heard and like whatever is bothering them is being taken seriously in some capacity, they're more likely to actually be able to move on. Otherwise, the more time goes on, the worse it feels. Clovermossš(talk)01:31, 29 January 2026 (UTC)[reply]
having that be someone's job would give those feelings a place to go Isn't that what answers@ is for? As I understand it editors who email there get substantive replies even if it's a "We don't know how much X costs because we don't do accounting that way" type of answer. If there was a dedicated person to go to to ask "hey, how do you think reception to this feature would go?" have you really never talked to the various tech "Movement Communications Specialists" (how's that for a mouthful)? Best, Barkeep49 (talk) 02:09, 29 January 2026 (UTC)[reply]
I've never heard of answers@. What is that? An email address? I've met some of the movements communications people in various contexts, but the fact that they exist isn't exactly well-known. To my recollection, they've never posted here to say hey I have an open door policy, if anyone wants to reach out to talk about anything, I'm here. And I'm quite immersed in the wikimedia sphere. The WMF is approachable in certain contexts if you know where to look but they do not make it easy to find this stuff out. Clovermossš(talk)02:26, 29 January 2026 (UTC)[reply]
Sure, the challenge of the silent majority is that we don't know its viewpoints, and thus their displeasure is only going to show up after a decision is implemented. It's hard to know what has "widespread agreement" when there are so many people whose opinions we don't know. As Barkeep49 alludes to, there are people whose jobs are to engage with the community. And yet there are still hard feelings. From the unrepresentative sampling of people who complain on pages such as this one, there are many people strongly convinced their preferred approach is the correct one, and thus the only reason for making a different choice is that they aren't being listened to. I understand that feeling on a personal level, but I try to combat it by considering that I could be wrong. Often I don't have the same information that others have, and I may be misunderstanding some aspects of the problem. As we've discussed previously, I agree that more communication and interaction is good. I'm just saying that there are inherent limitations. Government agencies and other organizations hold extensive public consultations, for example, and it helps with some people feeling heard, but it doesn't help with everyone. isaacl (talk) 02:34, 29 January 2026 (UTC)[reply]
They don't really do a good job of engaging with the community when you very rarely hear anything at all from them and it's more reactionary than initiative. I had no idea these people even existed until I had been editing for something like 6 years? I'm not saying they don't do good work, but it's hardly visible, and most people's interaction with them is going to be in the sense of 'I occasionally see them post a meta page asking for feedback'. That doesn't exactly accomplish much in terms of WMF-community relations. We have a serious gap there. I'm not saying I can't be wrong but I think it's impossible to determine that when we've never tried to fix it in a determined and involved way. I really don't think it's surprising there's still hard feelings (look at what everyone is saying about communication from the WMF above, that doesn't seem to me like people feel like they have a chance to be heard). There's a huge difference between committees and public consultations and who knows how many layers of bureaucracy and someone you know and trust to hear you out if you ever need it and who knows where to look for answers or to reassure you that yes people have considered that. It's sort of like the difference between a union representative and a user survey, in my mind. One is a lot more involved than the other. Clovermossš(talk)02:46, 29 January 2026 (UTC)[reply]
Personally, I think the part that bothers me the most about this, is not that WMF rejected it, but that the justification is extremely misleading. It bothers me a lot when WMF misconstrues technical issues to justify a policy decision. For background - there are two potential privacy risks with referrers. (a) [The main one] that external sites can see which website you are coming from, and maybe link together that information with other information it knows about you. (b) [The one nobody really cares about] An on-path attacker might be able to determine what website you were visiting over https by looking at the referrer in requests to non-https websites. In the RFC WMF says that (b) is basically not a practical attack as there are much easier ways to do it. Which is literally true, but the concern is about attack (a) not attack (b), and the way the response was phrased makes it sound like the analysis also applies to attack (a) even though it doesn't. The average Wikipedian is not a technical person, so I think its really important to be honest about the pros and cons of decisions so that folks can be properly informed. I know its years ago at this point, but it is disappointing to see how WMF justfied its response to this RFC [To be clear, it might not be the person who wrote the comment's fault. It may very well be due to a game of telephone between different people in WMF]. Bawolff (talk) 05:44, 24 January 2026 (UTC)[reply]
That's not what I get from the response linked. What I see there is them suggesting that people concerned about your (a) should really be looking into disabling referrer sending in their browser so as to protect themselves on every site, not just Wikipedia. The mention of your (b) wasn't to dismiss (b) itself (they don't actually dismiss it as far as I can tell), it was to point out that concerns about your (a) related to "safety" (versus "privacy") relate to powerful actors who would likely be capable of your (b) as well, so the requested change would provide little protection in that respect. Anomieā16:19, 24 January 2026 (UTC)[reply]
I think this is a reasonable example of progress by the foundation. Rather than imperioualy rejecting community consensus as they did here 9 years ago, with things like simple sentences they take on board the feedback both for the immediate issue and in changing process in an attempt to avoid similar situations in the future. Best, Barkeep49 (talk) 09:48, 25 January 2026 (UTC)[reply]
It isn't too late to listen to the community and stop sending referrer information. I'm just saying.
Perhaps I should post another non-binding RfC for them to ignore. It will be amusing to see the comments saying that asking again nine years later is too soon... :) --Guy Macon (talk) 18:33, 25 January 2026 (UTC)[reply]
The Board specifically
Having a subsection should hopefully be a satisfactory compromise? That way everyone who wants to discuss the board as a separate issue can but comparisons about broader trends can easily be made if one wishes. The board elections are obviously one of the more recent issues, as is the lack of transparency in a general sense. I've noticed that the board brings up their bylaws a lot, so here's a convenience link for anyone not familiar with that: [42]. Here's a link to the Candidate Review Process and the fiduciary duties slideshow.
Clovermossš(talk)01:10, 26 January 2026 (UTC)[reply]
To try and get this part of the conversation going, I'm concerned about how vague the new "reputational risk" part is. What exactly causes the board to think someone would be a reputational risk if elected? This could mean anything from someone has controversial political opinions to we think they'd want to change too much so we won't even give the chance to try. I'm also concerned about a lot of the themes expressed at m:Talk:Wikimedia Foundation Board noticeboard/October 2025 update. Clovermossš(talk)01:22, 27 January 2026 (UTC)[reply]
I'm aware of the general concept. My point is that without guardrails, anything could theoretically count as a reputational risk. I don't entirely trust the board to be sensible about this the way things stand. It might be a different matter if the board doesn't have the issues that it does. Clovermossš(talk)20:04, 27 January 2026 (UTC)[reply]
That's true, but it's also kind of like saying "but rain could fall at any time!" I mean, it's true, it's impossible to predict what may or may not end up as a reputational risk. Nevertheless, all companies (for-profit and non-profit) must take steps to reduce that risk, just like we take steps to prepare for the rain even if we can't predict it perfectly. Both the examples you gave: controversial political opinions, and openly calling for "too much" reform, could be signs of a reputational risk that is too high. It depends on the details, of course, and the ultimate decision is very subjective (how high is too high?), and one of the things Trustees are trusted with is properly weighing reputational risks when vetting new candidates. The "answer" is to elect Trustees whose judgment in these matters we trust. Levivich (talk) 20:11, 27 January 2026 (UTC)[reply]
Which you don't get much of a chance to when vetting narrows your choices down to a handful of candidates to a handful of seats and the board can just remove candidates from the ballot whenever they want. Clovermossš(talk)20:14, 27 January 2026 (UTC)[reply]
Also true :-) And even moreso when half of the Board are appointed by other Board members rather than elected by editors. It's not surprising that appointed Trustees would be both far more conservative in their risk assessments, and far less in touch with the consensus of the editing community, than elected Trustees.
However, it should be noted that the Trustee who was the most vocal about reputational risk in the most-recent round of vetting was an elected Trustee not an appointed Trustee. In my humble opinion, in the election in which this Trustee originally ran, there were better candidates who I believe would have made a different choice, but they were not elected. So we, the community, get the candidates we voted for.
I'm not sure whether, in any election, anybody asked any of the candidates any questions about how they would vet future candidates, and, specifically, how they would judge reputational risk. If we want Trustees to evaluate reputational risk in a certain way, we'll need to vet the candidates ourselves for that--meaning, in the next election, we should ask candidates about how they would evaluate reputational risk in future Board candidates. Levivich (talk) 20:21, 27 January 2026 (UTC)[reply]
If the election process itself was actually an election, I'd be able to agree with that. But the community seats get narrowed down by affiliates, so anyone without a strong affiliate background is unlikely to even be an option. The very process seems designed to offer an illusion of choice to preserve the status quo. Clovermossš(talk)20:41, 27 January 2026 (UTC)[reply]
Yeah I agree with that analysis. And that's for the 8 seats that are even elected; there are 8 more appointed seats (including the founder seat). The current Board gets to appoint 7 and, along with affiliates, pre-select candidates for the other 8. The whole system is designed to ensure a "safe"/non-controversial outcome (from the Board's perspective): we get to choose only from among pre-selected choices. Not the system I would want.
Changing that would require a change to the bylaws, which can only be done by the Trustees. I'd like to see candidates pledge, "if elected, I would vote to change the bylaws to X," and then if I supported the change to "X", I would vote for that candidate. ("X" could mean, for example, more elected seats, ending candidate screening by affiliates, or any number of reforms.) As I said elsewhere on this page, I'd like to see an entire slate of candidates all pledging to support a particular platform of reforms, so I could go vote for all of them. If you get 8 of them on Board (which would take multiple cycles), then amending the bylaws could become a reality. Levivich (talk) 20:47, 27 January 2026 (UTC)[reply]
I'd be repeating myself if I just talked broadly about the institutional problems with the BoT. Instead, it might be worthwhile to laser focus on the Board elections as both a huge source of conflict recently and, ideally, an avenue for reform in the future.
Looking back, there are three elements to what happened with the most recent election that were unacceptable from my POV:
First, the decision to eliminate 2 candidates after shortlisting gave us only 4 candidates for 2 seats, severely limiting the amount of choice we were really given. Doing interviews and background checks before shortlisting (which, to be fair, would cost time and money) would have reduced the number of candidates from 12 to at most 10, meaning there would have been no shortlisting step at all (explained here on meta). That means we would have up to 10 candidates in the final round, depending on how many others besides Lane and Ravan were eliminated. As the Board tried to emphasize, eliminating candidates after they were elected would have looked even worse, but that's not a good excuse to do it the way they did, for reasons I will come to.
Second, they announced the change in procedure during the campaign. This generated confusion, and disrupted candidates' and communities' ability to plan and strategize around the amended selection process. Clearly this subverts both the actual democratic function of the election and general confidence in its fairness and integrity. It is obvious, or should have been obvious, that this decision would be disruptive and unpopular, so I would infer that a competent Board would not have made the change unless it could not wait until the next election and its necessity was not foreseen prior to the campaign. This contributes to my next point.
Third and finally is something the Board will never confirm and I cannot prove, but based on the circumstances appears very likely: the Board had decided already in August that one or more candidates standing for election was unacceptable, and were forced (by their own reckoning) to intervene as early as possible to prevent that person or persons from being in a position to win a Board seat. The decision was made before any background checks or interviews, meaning these were a perfunctory fig leaf for the Board putting their thumb on the scale. The values and commitments these candidates held were what condemned them in the eyes of the Board.
What they found objectionable I can only speculate, but I will highlight two statements I think are revealing: in the first mention of this change on 21 August,[44]Abhishek Suryawanshi of the elections committee cited "increased scrutiny the board faces", which gives the impression of political pressure and a cowed Board. Then, in her announcement of the final ballot on 03 October,[45] Nataliia Tymkiv (Board chair at the time) said "Now more than ever, the Foundation needs a strongly unified board", implying candidates need to demonstrate loyalty to the Board (not the movement) and a willingness to get in line. It's not a complete picture, but I bring it up because the Board has adamantly refused to transparently share its reasoning for this and practically every other decision it makes, and because understanding the Board's motivations is nonetheless strategically necessary for any activism to be effective.
To that end, what can we do about any of this? Here are two simple, modest reforms that we might be able to convince the Board to agree to:
More candidates on the ballot. Allowing that some fraction of eligible candidates may be disqualified before voting, the shortlist should be expanded accordingly. The exact number could be discussed, but for 2 seats I think 8ā10 candidates would be manageable and appropriate, and the same proportion (16ā20) for the 4 seats up in 2027. This would require a modest increase in administrative burden for the foundation over what is now apparently the status quo, but I think it's quite reasonable. On our end, we should do whatever possible to recruit more candidates.
A commitment from the elections committee and (if possible) the Board, not to make any alterations to any part of the selection process while it is ongoing. Obviously the Board has nearly unchecked authority to make its own rules at any time, and there is no mechanism for them to cede that authority to us even if they wanted to. That said, I don't think this should be a big ask, especially if allowances are made for genuine emergencies. The elections committee is independent and made up of volunteers, so we can at least assert an expectation that they not cooperate with election interference from higher up.
I don't have any illusion either of these would address the core problems, but it would be a start. Let me know if you love or hate these ideas, or have other reactions. āRutebega (talk) 04:45, 30 January 2026 (UTC)[reply]
An example: Abstract Wikipedia / Wikifunctions
As an example, do we have any insight on how much money and developer time has been spent on Abstract Wikipedia, and whether this really is a priority for the community at large?
" In Abstract Wikipedia, people can create and maintain Wikipedia articles in a language-independent way. A particular language Wikipedia can translate this language-independent article into its language. Code does the translation."
Basically, the WMF is since 2020 creating a manually written rule-based LLM to automatically create or translate Wikipedia articles into any language, based on Wikidata. Apparently they learned nothing from the Scots and Greenlandic fiasco's and really believe thay can create an all-language article creator this way, and that this is wanted by the community at large instead of many other improvements which could be made with this money and manpower. After 5 years of development, the example functions they have on the Wikifunctions main page[46] is "is this is a substring of that" and "is this a palindrome"... Fram (talk) 11:38, 26 January 2026 (UTC)[reply]
This is a great opportunity for everyone who argues "The only reason you never get an answer is because you [insert random personal attack here], Guy. If only someone asked nicely/went through proper channels/asked the right question/was properly deferential, someone at the WMF would have been glad to show you some financial transparency."
I have heard this from at least twenty different people over the years. Let's see if it is true. You, the reader, can ask the WMF "how much money has been spent on the Abstract Wikipedia project so far? What was it spent on? What has been the end result of that spending?"
These appear to be grants from other organizations. Do we know if the Wikimedia Foundation is using any of its own money towards it? Bawolff mentioned earlier that when we do have program-specific data it's because grants are involved. Clovermossš(talk)15:41, 26 January 2026 (UTC)[reply]
Part of the reason why i thought SDC was entirely grant funded is that the project was abruptly shut down when they failed to secure a third grant. Admittedly this is guess work, but i suspect if WMF was footing part of the bill, the shutdown of the project would have been more gradual. We don't have that signal for abstract Wikipedia. Bawolff (talk) 18:56, 26 January 2026 (UTC)[reply]
The alert reader may have noticed that I always ask "how much money was spent?" and never "where did the money come from?" That's because money is Fungible. When they first tried to sell the idea of a California Lottery to the voters, they made a big deal about an ironclad promise that every dollar of profit would go to the schools. And indeed it does. The catch is that the schools get the same amount of money. The lottery funds are roughly 1% of the total that California spends on education, and the legislature simply spends 1% less on education than they would have spend without the lottery. So the money actually goes to the general fund while technically going to the schools.
The fungibility calculation breaks down if the sources of revenue exceed the amount spent. At that point someone has to explain where the rest of the money went. Or they can simply keep how much was spent a secret with tricks like reporting as a line item "money spent of furniture, computers, legal fees, and lawn maintenance" -- useful if you don't want the peons to know how much you are paying your brother in law to keep the lawn mowed.
Sometimes grants have strings attached. The donor may require that it only be used in certain ways. But guess what? Those conditions, if any, are also a closely held secret! --Guy Macon (talk)
I'm not sure what money being fungible has to do with any of this. Just because money is fungible doesn't mean you can't follow it. Identifying known sources that have to be spent on some project at the very least tells us the minimum that was spent on that project. You can also crosscheck it with headcount assigned to the project (usually sort of public) and see if the number is roughly consistent. Bawolff (talk) 19:06, 26 January 2026 (UTC)[reply]
Anyway, restricted donations, like the Endowments' funding of Abstract Wikipedia, are not fungible. Also, restricted donations aren't a closely-held secret, they're reported on the WMF's financials. Levivich (talk) 20:53, 27 January 2026 (UTC)[reply]
My understanding is this is a new product manager that has only been with the WMF for three months. Again, I want to focus on the systemic problems here (am currently having a conversation with someone who is worried this is going to turn into targeting that employee and that I shouldn't have said anything because people are trying to convince them this is a bad idea behind the scenes), but I do think it's important to have discussions about patterns like this. For example, how a lot of community consultation on most things takes place "off the record" and thus leaves communities vulnerable to not feeling like their opinions have been accurately represented or considered.
The board is a seperate entity but has the same problem. I had someone remind me when I questioned the action of a new trustee that she's new to the movement as well. But if we're having problems like that, it suggests that maybe there's some breakdown in communication. I don't know what's normal for most organizations, but I wouldn't expect to be proposing new features as a new employee in my current career (which is very blue collar, so maybe not a good direct comparison, would appreciate people who are not sailors to opine). I also notice the general trend of how there seems to be a lot of focus in building features for readers and for engagement. I don't like that trend either because it makes us feel like a company trying to get people to pay for the service we provide them. Once again, I don't blame individual employees here, but I feel like to some extent people are systemically set up to fail. People with decision-making authority should understand the community they're working for well. Clovermossš(talk)22:59, 26 January 2026 (UTC)[reply]
If anyone reading this ever identifies any Wikipedia editor who targets or abuses any WMF employee instead of focusing on the system they are in, please email me or bring it up on my talk page. I am not an admin but I know how to report things to admins and how to follow up so that such behavior does not happen. If any WMF employee is reading this, please remember that disagreeing with you is not the same thing as attacking you. --Guy Macon (talk) 23:13, 26 January 2026 (UTC)[reply]
That's another good example - that feature was technically linked to on the Technical village pump a while back, but presented as "introducing semantic search"; they left the AI widget part out. (I realize it isn't part of phase 1 now.) This, to me, seemed a little deceptive; whether intentional or not, it seemed likely to skew feedback in a more positive direction than if they mentioned the AI part, which seems to be a pattern with WMF stuff (see also the Simple Summaries survey, which several people reported didn't contain an option for people to say "no, don't do this") And I'm all for improving the search functionality, too, and I do usually search off-wiki using question format. If the feature was strictly what they told us it was, that would be great.
I don't think this is an issue of one employee. Unless you work at, like, a 4-person startup, major product decisions have the sign-off of many people including the higher-ups. Gnomingstuff (talk) 15:36, 27 January 2026 (UTC)[reply]
Even product managers need sign-offs? Because the new employee is a product manager. I'm not sure what the "higher ups" beyond that would be for the WMF, unless one needs executive sign off for every decision. I suppose it's possible that's normal and I just have no idea because of my blue collar background. Clovermossš(talk)16:04, 27 January 2026 (UTC)[reply]
The general direction "do something to improve reader growth" has executive knowledge, I think the overall direction gets known by folks who are the mid-level managers "improving semantic search", I don't know that the specific products being ideated (that are in Phase 0) necessarily are already being approved by the people at the top. For what it's worth how peeps present things when talking to the community is a Movement Communications team problem and not something the executive team micromanages. Sohom (talk) 16:22, 27 January 2026 (UTC)[reply]
My understanding is that Abstract Wikipedia does not automatically create articles, and the comparison to large language models is inapt. Humans have to create the articles using a language designed to be easily translated to other languages. Instead of using an existing language as a lingua franca, or inventing a language that looks like traditional human languages, the project is inventing a lingua franca patterned after programming syntax. isaacl (talk) 23:39, 26 January 2026 (UTC)[reply]
I think that what people are concerned about is that there will be the same issues that happen when trying to attempt machine translation in a general sense, even if this is technically different. There's a big AN discussion about OKA-funded articles and llm-generated text for a reason, not to mention the scandals that Fram led with in their comment. Language has proven time and time again that it's not as simple as trying to find the right tech and that these efforts can cause actual harm. [55] My understanding is that abstract Wikipedia is also trying to create global versions of templates (so things don't break when one is translating from one project to another) and this is usually the context I've heard about it in. This project wasn't really on my radar until recently because I assumed its other goals had to do with organizing wikidata content in a more longform and structured way. Clovermossš(talk)23:55, 26 January 2026 (UTC)[reply]
I have my doubts that there is a sufficiently large community interested in using programming syntax to write articles, as well as there being problems with developing wikifunctions appropriate for all target languages. Since humans are designing each specific wikifunction implementation, though, I don't have the same concerns about it as I do for program-generated translations. It's more like humans are designing a complicated phrasebook that can be mechanically followed to produce a translation. (As mentioned, I'm skeptical about the feasibility of that approach, but I think it's worthwhile for someone to do research in this area, leaving aside the question of who should fund it.) isaacl (talk) 00:15, 27 January 2026 (UTC)[reply]
If by templates you mean the pages stored in the Template namespace that can be transcluded, I haven't heard of Abstract Wikipedia being involved with global templates. I thought that was a separate initiative? isaacl (talk) 00:17, 27 January 2026 (UTC)[reply]
Yes, I'm familiar with Wikifunctions calls. My understanding was that a separate initiative had been looking at storing traditional templates globally so they could be used across wikis, with localization for parameter names. isaacl (talk) 01:55, 27 January 2026 (UTC)[reply]
That link goes to a page with "There is currently no text in this page." and no page history. Searching for "wikitext output" gives no results at all[56]. Fram (talk) 09:47, 27 January 2026 (UTC)[reply]
That's because you were searching the main namespace, the page is located in the project namespace, that's where you would search for such pages on Wikipedia as well. I fixed the link above. --Johannnes89 (talk) 11:14, 27 January 2026 (UTC)[reply]
Thanks. So their grand plan is to automatically create Wikipedia articles, but the system can't output wikitext? And they don't see any rather basic problems with this? Like I said below, that's $5 million plus down the drain. Fram (talk) 11:19, 27 January 2026 (UTC)[reply]
"Code does the translation." is what their own page says. Not "a human does the translation based on or helped by Wikifunctions". The intention really is that humans create some pattern, some code, to extract the data, and then the code translates this into fully-formed natural language articles in any language you like. Completely utopical in the way they are going about it, and completely superfluous in this time of LLMs who do it badly but still better than this coding experiment will ever achieve. $5 million plus down the drain. Fram (talk) 09:44, 27 January 2026 (UTC)[reply]
"A key hoped-for outcome of the long-term vision for Abstract Wikipedia is to provide short articles and snippets made up entirely of Wikifunctions calls using Wikidata inputs, shown alongside local articles. " So yes, the vision is to have fully automated "articles" by Abstract, not human-created ones aided by Abstract. Fram (talk) 09:53, 27 January 2026 (UTC)[reply]
I think the idea was that statistical AI works best for languages with a huge corpus of work to train on, but is less effective on small languages (not to mention the hallucination & unpredictability issues). So instead they want to take a more logical rules type approach. Will it work and be better than LLMs? Does that idea still make sense now that LLMs have advanced so much recently? I have no idea, seems incredibly speculative to me and i can't help but feel like it seems like the easy parts are being over engineered to avoid working on the hard parts. But i can still understand the appeal of this approach despite the success of LLMs. Bawolff (talk) 12:13, 27 January 2026 (UTC)[reply]
Humans have to write the article using Wikifunction calls, the lingua franca. The Wikifunctions are executed to produce text in different languages. The Wikifunctions are written by humans. So it's much like a giant lookup table, rather than a large-language model that has no explicit rules encoded within it. I agree it is possible to write brief overviews using a generic skeleton of Wikifunction calls that is applied across multiple subjects in the same area (for example, countries). That would not be a replacement for in-depth articles about subjects, as a generic skeleton would be unable to cover their individual aspects.
In essense, the desire is to capture the ideas being expressed by the author in a format that is easily amenable to translation to human languages. I'm also skeptical of the value of the WMF funding this research. I'm only saying that calling it a large-language model is inapt. isaacl (talk) 17:05, 27 January 2026 (UTC)[reply]
But words and their corresponding concepts in one language don't have perfect matches in another, that's going to create all kinds of WP:V failures Kowal2701 (talk) 17:18, 27 January 2026 (UTC)[reply]
The Internet Archive is the most valuable resource I use when writing articles, especially with WP:IAACCESS. It also runs on donations but doesn't have nearly as much reach as the WikiMedia Foundation. While I'm not familiar with the legal or logistical elements here, I'd be interested in knowing whether it's feasible to include an option for Wikipedia donors to send some of their donation to the Internet Archive should they choose to do so. Thebiguglyalien (talk) šø22:14, 26 January 2026 (UTC)[reply]
There is a legal difference between spending money you have already had donated to your own organisation in supporting another organisation and soliciting money (or purporting to solicit money) directly on behalf of that organisation. Whether the WMF should be doing the former is possibly questionable, but they certainly weren't set up as a means to raise funds for third parties. AndyTheGrump (talk) 16:49, 27 January 2026 (UTC)[reply]
As I discussed in an earlier thread, there may be issues with donations being tax-deductible. In Canada, for example, the charity must be carrying out its charitable purposes itself or be in direct control of the work being done by others. That being said, in theory the donation can be split and separate receipts issued by each receiving organization. It would probably be more effective, though, from the receiving organization's standpoint if the donation were made directly. isaacl (talk) 17:48, 27 January 2026 (UTC)[reply]
I'm not a lawyer, but I have been a charity trustee in the UK, including on a grant giving charity. I'd be surprised if one or more charities within the movement couldn't make donations to other charities whose work is essential for Wikipedia. We rely on the Internet archive to archive many of the sources that we cite as references, just as we rely on creative commons for our licences. If a small proportion of Wikimedia funds were maintaining those charities, would that be hard to defend to a donor? Afterall if the internet archive didn't exist, surely we would be creating something similar at least for the webpages we cite as references. Would a donor object to funding the Internet Archive with less money than it would cost the WMF to replicate what the Internet Archive does for Wikipedia? Is it that different to buying electricity for the servers from a utility rather than spending more on generating that electricity ourselves? Ļ¢ereSpielChequers00:03, 29 January 2026 (UTC)[reply]
For those who don't want to click the link, here's a quote from the post:
this campaign presented some challenges as the December banner campaign started off well below our projections. While we anticipated lower traffic yearāover-year and had accounted for this in our planning, the drop we saw surpassed our expectations. While we did manage to raise our set goal, this was partly because those that did give, on average gave more. We saw 14% decline in the number of donors who gave, 20% decline in the number of new donors and 7% less revenue year-over-year.
I am looking for an Wikipedia article to place this picture. It seems that the First National Bank does exist in the presentday US, but maybe this is an old version (1889). In the old days the banks where organised by state. PS: I live in Europe and I havent been to the US, so I am unfamiliar with the US bank landscape and history. Reading the US bank wikipedia articles I get confused. Smiley.toerist (talk) 13:17, 15 January 2026 (UTC)[reply]
It probably will require access to very localized sources to find out anything about that bank. Banks have failed at often high rates, particularly during financial panics, recessions, and depressions, of which there have been 28 in the US since 1890, per List of recessions in the United States. More recently, there have been many mergers of banks. Over a six year period in the 1980s, I had an account with six different banks without ever closing or opening an account, because of successive mergers. Donald Albury00:51, 16 January 2026 (UTC)[reply]
Oh, about the title "National Bank". Any bank chartered by the US government is a National bank (United States), and has to include "National Bank", "National Association", or "N.A." in its name. There could be more than one "National Bank" in a town or city, and "Second National Bank" or even "Third National Bank" was not unheard of. There is no necessary connection between two banks with "National Bank" in their names. Donald Albury01:08, 16 January 2026 (UTC)[reply]
Even banks that stay solvent for a long time change their names, and the cities where they operate change their names, so you have some historical research to do. A quick search found this floorplan for your bank. Good luck finding out more about it. https://texashistory.unt.edu/ark:/67531/metapth1001453/
If you came here because someone asked you to, or you read a message on another website, please note that this is not a majority vote, but instead a discussion among Wikipedia contributors. Wikipedia has policies and guidelines regarding the encyclopedia's content, and consensus (agreement) is gauged based on the merits of the arguments, not by counting votes.
However, you are invited to participate and your opinion is welcome. Remember to assume good faith on the part of others and to sign your posts on this page by adding ~~~~ at the end.
AE Both the Lithuanian SSR and the Soviet Union are defunct, so it makes sense to link to them. I don't think that runs afoul of GEOLINK, which is more focused on extant places. If you didn't know what the Lithuanian SSR was, you would have to copy and paste that into the search because even if you went to PanevÄžys, that doesn't have a link to the Lithuaniun SSR or the USSR. CaptainEekEdits Ho Cap'n!ā20:46, 15 January 2026 (UTC)[reply]
WP:RFCBEFORE advises trying to resolve a question like this in a regular discussion before calling an RFC. As that discussion was proceeding well, this RFC feels a bit premature, especially since the RFC question seems to disregard it rather than using the outcome to refine. -- Beland (talk) 22:02, 15 January 2026 (UTC)[reply]
E per MOS:GEOLINK, which gives very clear guidance to avoid [linking] [consecutive comma-separated sequences of two or more territorial units], and instead suggests to space the links out when feasible. I see no compelling reason to deviate from the suggestion given at MOS:GEOLINK, which is further supported by MOS:OVERLINK which states that Links may be excessive even if they are informative. For example, because inline links present relatively small tap targets on touchscreen devices, placing several separate inline links close together within a section of text can make navigation more difficult for readers, especially if they have limited dexterity or coordination. Balance readability, information, and accessibility when adding multiple links in one section of text.Katzrockso (talk) 23:49, 15 January 2026 (UTC)[reply]
E, F or G. All satisfy MOS:GEOLINK by adding a qualifying phrase between extant and non-extant names. "part of" might be seen as less neutral than the other two, but WP:NPOV concerns would probably be better addressed by a footnote. Indrek (talk) 09:13, 16 January 2026 (UTC)[reply]
E (Summoned by bot) E sufficiently establishes, place name, geographic location and succinctly establishes 'regime at the time', which is pertinent info in most cases. F & G, apart from being over-long, imply that that the place was administered from somewhere else (as a colony) or somehow 'irregularly' ruled. That kind of detail isn't necessary in an infobox and could be confusing.C or D would be acceptable, but lack the clarity of E.Pincrete (talk) 11:26, 16 January 2026 (UTC)[reply]
A, B, C, or D. The other options diverge from one of the most consistent standards we have across en.wiki, consistent enough that readers probably expect it. They are also longer and thus more likely to mess with infoboxes. Give readers credit that they both understand the comma convention that we use everywhere from text to article titles, and that they understand the linear passage of time. "Dallas, administered as part of Texas, United States" is not something that brings the reader additional clarity. CMD (talk) 11:34, 16 January 2026 (UTC)[reply]
E: seems to comply with WP:GEOLINK, is clear and helpful, and allows the user to access the historical area as well as the current place. The two links are all that we need. PamD13:59, 16 January 2026 (UTC)[reply]
A, C, or E. My feelings are generally that, when a place of birth/death in a person's infobox incorporates a no-longer-extant subnational entity, it's useful to the reader to link that entity so that (if they want it) they have access to further context about the location at that time. For that reason, I think the options that link Lithuanian SSR (or its equivalents) are preferable to those that do not. I'm willing to bend the guidance at MOS:GEOLINK for the sake of this point; I read that guideline as mainly focusing on linking in article prose, and I believe that infobox text serves different needs and so does not need to necessarily follow it strictly. However, I'm also open to E as an option that meets the letter of GEOLINK while losing the least amount of concision. I oppose F and G as essentially just more cumbersome ways of achieving the same compromise as E. ModernDayTrilobite (talk ā¢ contribs) 17:06, 16 January 2026 (UTC)[reply]
E seems to me most appropriate to me. While nothing was actually decided in that RFC, there were people in the original discussion who supported the Soviet Union birthplace (including me) that had no problem with a clarifying footnote. This is a good solution, and less cumbersome than F or G, without ceding our preference to the de facto country rather than the de jure one. For the same reason, I don't think the Texas example above is comparable since I don't think the contextualization is as crucial to a typical reader here. CoffeeCrumbs (talk) 05:17, 17 January 2026 (UTC)[reply]
A, B, C, D then E - The first four options are highly common across other bios on Wikipedia. The fifth option is an acceptable alternative. GoodDay (talk) 05:34, 17 January 2026 (UTC)[reply]
E seems like a good compromise, I'd prefer A but can see that will conflict with MOS. I'm less a fan of F and G, rather keep it simple and explain in the related articles. -- LCU ActivelyDisinterestedĀ«@Ā» Ā°ātĀ°20:39, 20 January 2026 (UTC)[reply]
A > C > (E=F=G) >>> D>B We link to things we donāt expect our reader to understand. It would be stupid for GEOLINK to override that. I am neutral on the wordier options, as I do not understand the distinction between them. ā HTGS (talk)06:12, 21 January 2026 (UTC)[reply]
F but all of these are inaccurate as they do not explain the fact that Baltic States were occupied by Soviet Union de facto, but de iure were still considered to continue to exist as sorveign entities due to illegality of Soviet actions. Tallinn, Soviet occupied Estonia or Tallinn, de iure Estonia, de facto Estonian SSR, Soviet Union would be factually correct and short enough for infobox --~~Xil (talk) 15:57, 24 January 2026 (UTC)[reply]
Some discussions I read suggest that some people truly do not understand what the issue is, so assuming good faith, I'll expand on this a bit. Since the first half of 20th century, for reasons hopefully obvious to anyone knowing the slightest bit of history, international law has been discouraging territorial expansion by force. As such an internationally recognised sorveign country being forced to become a part of another country is considered illegal. This includes any acts that attempt to create legal rights and justify land aquisition like establishing puppet states, administrative units etc. From legal perspective such acts are considered null and void, they do not create any rights and are treated as if they do not exist at all. Nobody, of course, is denying that the physical reality is what it is, but it is refered to in terms that only acknowledge the situation on ground, such as that there is military occupation, in this case the occupation of the Baltic states. The non-recognition of Soviet Union annexing the Baltic States is the objective historical reality, not some nationalist fringe view, Wikipedia has multiple, well sourced articles covering the topic , such as State continuity of the Baltic states, which shows that dozens of countries supported this interpretation of the international law during the Cold War. On basis of this being the international law, the Baltic States restored independence during the collapse of Soviet Union and as such it is now part of constitutional laws in these countries. As such options A to E solely listing Soviet Union and its internationally unrecognised Soviet republics are very problematic, and options F and G are only moderately better as they imply that something is up, but don't really explain to the reader that the mainstream view is that de iure the location in question belonged to another sorveign country. Furthermore the Baltic States now have regained contol over their territories, plus it potentialy appears in an article on a living person, who also doesn't think Soviet Union had any right to the land they were born on, there have been multiple cases outside of Wikipedia when such language has been chalanged [57][58][59][60]. Therefore presenting information like this is misleading and can potentially cause problems to people, who whish to actually use Wikipedia as a source ofinformation and copy facts from here. Not to mention that the current debate has gained enough traction to get coverage in the mainstream media in Baltic States, which regard the current state of Wikipedia articles as disinformation and question if this is not a manipulation by Russian propogandists.[61][62][63]. Ignoring it likely will just keep on provoking further controversies. It is far from WP:NPOV to complitely disregard, what entire countries consider the objective historical reality, on basis of having held a strawpoll, the result of which actually did leave otions for further discussion, such as on adding footnotes etc. In addition, Russia currently is using extrely simmilar tactics to what Soviet Union did in Baltics to justify its attempt to gain lands in Ukraine, which is met with very simmilar international reactions, in that case it appears that there is no problem with listing balanced information in the infoboxes, such as stating it is internationally recognised as Ukrainian territory occupied by Russia, adding footnotes, using de iure/de facto. There are plenty of ways to come up with neutral wording that is short enough e.g. PanevÄžys, de facto Lithuanian SSR, Soviet Union, de iure Lithuania or PanevÄžys, Sovietoccupied Lithuania ~~Xil (talk) 16:42, 1 February 2026 (UTC)[reply]
Unfortunetly such option as you are offering is almost never an option to choose from in RFC. And wast majority of editors, wants to stick with maps show, that what we will use. Additionally im amaised of one user who wants to unify all infoboxes, have no idea how he will manage find single solution, to all worlds problems, Balcans, Isreal/Palestine, China/Taiwan, Baltics, Ukraine/Russia and others... BerzinsJanis (talk) 16:58, 1 February 2026 (UTC)[reply]
Personally I do not see a problem with there potentially being a broader policy on contested territories, although not all cases are simmilar to this one, Ukraine is, historically some cases of occupation by Axis powers might be, but issues in Balkans, Isreal/Palestine, China/Taiwan, as far as I know, are not. --~~Xil (talk) 18:17, 1 February 2026 (UTC)[reply]
All of these options are highly biased. The only correct option is "PanevÄžys, Lithuania" as this was the legal state under international law. If you insist to mention the de facto rule at the time, then the only correct option is "PanevÄžys, Lithuania (Soviet occupation)". ~2026-52185-6 (talk) 15:53, 24 January 2026 (UTC)[reply]
C/A - Linking to the administrative subdivision but not the administrative superdivision seems fine style wise, but have both linked isn't a problem either. -- Cdjp1 (talk) 17:39, 30 January 2026 (UTC)[reply]
Hmm, but C is actually not in compliance with GEOLINK, which states that normally only the first element should be linked? Gawaon (talk) 07:51, 31 January 2026 (UTC)[reply]
Be sure to read the last part of MOS:GEOLINK, which says:
If the smallest unit is an extant place, but the largest is not, it is preferable to space the links out when feasible, e.g. Kumrovec, then part of Austria-Hungary ([[Kumrovec]], then part of [[Austria-Hungary]]).
Comment There should be no consideration for the E, F and G options. The infobox person documentation is pretty clear on the three-way formula for listing geos. The previous proferring and edit warring for these has only been driven by off-wiki campaigning by nationalists. Another example: De-facto is how we go, a person born in the Islamic Emirate of Afghanistan is listed as such without consideration for the legitimacy of the government in the 1990s or now. Gotitbro (talk) 08:14, 31 January 2026 (UTC)[reply]
Also, the form E is explicitly suggested by GEOLINK for such cases (where the second-level unit no longer exists), while A, C, D are arguably explicitly forbidden (or at least strongly discouraged) by GEOLINK. That has nothing whatsoever to do with nationalist feelings. Gawaon (talk) 08:37, 31 January 2026 (UTC)[reply]
This RfC would then appear to be mostly semantics. As for GEOLINK and its 'preference', that is one without any major precedent for all the bios and BLPs I have trawled since I first opened Wikipedia haven't come across any major ones following it. It is safe to say we can ignore that preference.
As for nationalist driven canvassing concerns, the only reason I mention it was after coming across the massive off-wiki media and social media campaign in the Baltics attempting to alter how we do things at enwiki (reported at the Signpost). The edit wars, disruptions, discussions et. al. and subsequent RfCs to tackle that, all stem from that very coordinated effort and editors should be very wary of that. Gotitbro (talk) 08:58, 31 January 2026 (UTC)[reply]
Sure, I'm in agreement with the outcome of the earlier RfC. This one is about settling the details. However, E to G are fully in agreement with the outcome of the earlier RfC and are valid options, should one of them manage to gain (relative) consensus. Gawaon (talk) 11:09, 31 January 2026 (UTC)[reply]
"Administered" is often used in lieu of "occupied" on enwiki which was of course rejectes. So no I would not say that these are in consonance with the earlier RfC. Gotitbro (talk) 14:06, 31 January 2026 (UTC)[reply]
Characterizing any outcome as "overwhelming" misrepresents a discussion where significant concerns about WP:NPOV were raised regarding the unique international legal status of the Baltic states - whose Soviet annexation was never recognized de jure by most Western nations, a fact extensively documented in the article State continuity of the Baltic states.
The RFC result remains disputed, and editors who disagree with its application have legitimate grounds for doing so based on policy concerns that were not adequately addressed in the original discussion. Seungsahn (talk) 19:49, 31 January 2026 (UTC)[reply]
I kind of expected as much, though thrice is indeed more than I expected! All right then, so we can well and truly consider the old RfC as settled for good and move on with the discussion. Gawaon (talk) 08:13, 1 February 2026 (UTC)[reply]
The number of times a closure has been challenged doesn't address whether the underlying concerns have merit.
The challenges occurred precisely because the RFC failed to adequately engage with the distinct legal status of the Baltic states under international law - a substantive issue that remains unresolved regardless of procedural outcomes. "Settled" and "correct" are not the same thing. Seungsahn (talk) 17:18, 1 February 2026 (UTC)[reply]
Would you be satisfied with a footnote noting that the occupation was considered illegal by many countries, as proposed on the other RFC? -- Beland (talk) 19:39, 1 February 2026 (UTC)[reply]
A footnote would be an improvement over the current format, but I have concerns that it still places the legitimizing framing ("Estonian SSR, Soviet Union") in the most prominent position while burying the critical legal context where most readers won't see it. The purpose of an infobox is to convey key facts at a glance - if the illegality of the occupation is important context, it shouldn't be hidden in a footnote. I'd prefer the infobox text itself to reflect the reality, such as "Tallinn, Soviet-occupied Estonia," with a footnote providing further detail. But I recognize this is a discussion and I'm open to hearing other perspectives. Seungsahn (talk) 19:50, 1 February 2026 (UTC)[reply]
A, C, or E. per ModernDayTrilobite. Lithuanian SSR should be linked to provide context for those who seek it. Soviet Union is well-known enough that a link can be omitted to reduce consecutive linkage. Options F and G are too cumbersome and we'd probably need another RFC to decide on which (ad)verb exactly we should use (because it's foreseeable that someone will ask for the (ad)verb to be "occupied", like Xil already did above). We can avoid the whole (likely heated) debate about the question which (ad)verb describes the situation most accurate/neutral by simply not including an (ad)verb to begin with. Nakonana (talk) 17:25, 1 February 2026 (UTC)[reply]
F though none of the options listed adequately address the underlying WP:NPOV concern. All options A through E present "City, SSR, Soviet Union" as the primary framing, which implies a legitimacy that was explicitly rejected under international law for over 50 years. The Soviet annexation of the Baltic states was never recognized de jure by the United States, United Kingdom, and most Western democracies ā a position maintained continuously from the Welles Declaration (1940) until independence was restored in 1991. Baltic diplomatic missions operated in Washington, London, and other capitals throughout the entire Soviet period. This is extensively documented at State continuity of the Baltic states. F at least gestures toward the complexity of the situation, but the most accurate and neutral formulation would acknowledge the occupation context directly ā for example, "Tallinn, Soviet-occupied Estonia" - which reflects both de facto Soviet control and the de jure continuity recognized by the international community. An explanatory footnote (as in the separate Kaja Kallas RFC) would be a further improvement regardless of which display option is chosen, as it provides readers with the context needed to understand why this situation differs fundamentally from other Soviet republics such as the Ukrainian SSR or Belarusian SSR, whose incorporation into the USSR was internationally recognized. I also note that this RFC's scope is limited to linking style within an already-contested format. The broader question of whether "City, SSR, Soviet Union" is itself appropriate for the Baltic states ā given their unique legal status ā remains unresolved and warrants a dedicated RFC that explicitly addresses this distinction. Seungsahn (talk) 20:08, 1 February 2026 (UTC)[reply]
My question at MOS:GEOLINK, was about what to link or not link. My questoin was not about altering the 2025 RFC decision or amending MOS:GEOLINK. GoodDay (talk) 19:18, 15 January 2026 (UTC)[reply]
There is a best-of-both-worlds solution, which should've been brought up in the December 2025 RfC.
Why don't ya'll just add both de jure identifiers and de facto identifiers, possibly with a note explaining the irregularities. For example, the birth place of Vilnius, Lithuanian Soviet Socialist Republic should be changed to Vilnius, Lithuania (de jure)/Lithuanian Soviet Socialist Republic, Soviet Union (de facto), along with an explanatory note that Lithuania regained its de facto independence in 1990. The Act of the Re-Establishment of the State of Lithuania restored state continuity throughout the 1940ā1941 and 1944ā1991 Soviet occupation.
Proposed explanatory notes for use:
Estonia: Estonia regained its de facto independence in 1991. Throughout the 1940ā1941 and 1944ā1991 Soviet occupation, Estonia's de jure state continuity was preserved by diplomatic representatives and the government-in-exile.
Hello everyone! I will be monitoring this discussion as an uninvolved administrator, following GoodDay's request at Wikipedia:Administrators' noticeboard. GoodDay, I invite you to briefly read our RfC formatting guidelines, as the current format breaks the automatic transclusions. The RfC question should be signed (or at least timestamped with ~~~~~), and neutrally worded, without making references to policies or guidelines that might support some answers. These can be elaborated on separately, for example in an additional heading providing background context or in your own !vote. Chaotic Enby (talk Ā· contribs) 20:36, 15 January 2026 (UTC)[reply]
I made adjustments to the 'RFC question'. Would appreciate advice on wording. Should I keep or remove mention of the 2025 Dec RFC? GoodDay (talk) 20:41, 15 January 2026 (UTC)[reply]
I also made a bit of an adjustment to note1, which was kind of snarky; it still might be better if it was just removed and GoodDay put a vote with a rationale focused on the problem, or had a background about why this is an issue. CaptainEekEdits Ho Cap'n!ā20:43, 15 January 2026 (UTC)[reply]
It wasn't meant to be snarky (the note), but I thank you for re-writing it. I would be grateful, if you'd re-do the questionaire. GoodDay (talk) 20:47, 15 January 2026 (UTC)[reply]
Seconding these options. Writing an initial !vote that explains your rationale is a common practice in RfCs, and so is the alternative of a standalone background section, separate from the RfC question. Chaotic Enby (talk Ā· contribs) 21:05, 15 January 2026 (UTC)[reply]
In the earlier discussion, that option had some support, which is why it should be included. As explained to you already, the RFC did not specify a particular format, only that the SSR and Soviet Union should be included. This was confirmed by @Beland, who closed the RFC. JƤhmefyysikko (talk) 21:23, 15 January 2026 (UTC)[reply]
The option you wanted included, was excluded because it went beyond the scope of this RFC, per advice from another editor. PS - If I'm given clearance to add your option? I will do so. GoodDay (talk) 21:38, 15 January 2026 (UTC)[reply]
From what I understand, there is a disagreement about the intended scope of the RfC. To make sure we're on the same page, do you both agree that this RfC aims to decide on specific details of the decision achieved at Wikipedia talk:Manual of Style/Infoboxes#RFC: Baltic states birth infoboxes? And the disagreement is on whether this RfC addresses it in part (only being focused on the linking style) or in full, am I correct? Has there been prior discussion about how a follow-up RfC was to be structured? Chaotic Enby (talk Ā· contribs) 21:51, 15 January 2026 (UTC)[reply]
Yes, I agree on the aim. If the choice of options is limited, then this RFC is only partial in that it does not address whether City, SSR, Soviet Union (with the preferred linking) or City, then part of SSR, Soviet Union (or some other variant) should be used. I am not aware of a prior discussion. JƤhmefyysikko (talk) 21:59, 15 January 2026 (UTC)[reply]
As the RfC has just started and there hasn't been substantial voting yet, I am giving you clearance to do so. An alternate suggestion I may offer, although it is not a requirement, is to pause the voting and allow a few days for editors to suggest additional options, then restart the RfC anew. Chaotic Enby (talk Ā· contribs) 22:02, 15 January 2026 (UTC)[reply]
Absolutely disingenuous. None of these options use the word occupied. If the USSR is mentioned at all, it should be "then occupied by the USSR". Otherwise, where are the options for simply PanevÄžys, Lithuania?
I agree. The RFC options were framed in a way that excluded the most defensible neutral position from the start. Where is the option for simply "PanevÄžys, Lithuania"? The United States and most Western democracies never recognized the Soviet annexation of the Baltic states - this wasn't some fringe position, it was the official legal stance maintained continuously from the Welles Declaration in 1940 until independence was restored in 1991. Baltic diplomatic legations operated in Washington throughout the entire Soviet period. Under this interpretation, which was held by the majority of Western nations, Lithuania never ceased to exist as a sovereign state. Excluding this option from the RFC while offering multiple variations of "Lithuanian SSR, Soviet Union" predetermined the outcome toward the Soviet/Russian legal interpretation.
The inconsistency with Wikipedia's treatment of other unrecognized entities makes this even more glaring. Wikipedia consistently uses "Richmond, Virginia" for people and institutions from the Confederate era (1861-1865), not "Richmond, Confederate States of America" - despite the Confederacy exercising de facto control at the time. If de facto control by an unrecognized breakaway government doesn't warrant changing location designations, why should de facto control by an unrecognized illegal annexation? The RFC should have included "PanevÄžys, Lithuania" as an option, or at minimum "PanevÄžys, Lithuania (then under Soviet occupation)" - which would acknowledge the historical reality without adopting the Soviet legal position that Western nations explicitly rejected for 50 years.
It's also worth noting that the previous RFC did not reach real consensus. The closure stated that Option A was "most popular" - but popularity is not consensus per WP:NOTAVOTE. The closer acknowledged "competing interpretations of neutrality, clarity, and accuracy," which indicates genuine disagreement on policy grounds rather than consensus. The arguments grounded in international law and WP:NPOV were never properly weighed against raw participation numbers. And the RFC was initiated by User:Glebushko0703 (now blocked), who had already made mass edits to "SSR" format before starting the RFC - hardly a neutral process. Building a new RFC on top of that flawed foundation doesn't fix the underlying problem. Seungsahn (talk) 18:19, 30 January 2026 (UTC)[reply]
It doesn't matter who opened an RfC as long as it was completed and closed property ā which was the case here, confirmed by subsequent discussion, for all I know. So it's time to respectfully step away from the horse carcass and instead constructively work on filling out the details ā which is what this RfC is doing. Gawaon (talk) 18:31, 30 January 2026 (UTC)[reply]
RFCs do not have to be "closed". They should stay open for as long as necessary to get an answer. If the answer is patently obvious, then nobody should waste time writing an official statement of what everyone else already knew. This is documented in WP:RFCEND. WhatamIdoing (talk) 23:24, 30 January 2026 (UTC)[reply]
Im amaised also at that, as the most neutral would be mentioned both entities and status at that time. Somehow such option is never considered or offered in survey. In fact you don't even need to search for USA examples when there are plenty here in Europe, with far less nuances and legality questions. Yet there are users who push for only solviet narative. BerzinsJanis (talk) 10:40, 1 February 2026 (UTC)[reply]
Feel free to suggest options that haven't been discussed yet. Note that a footnote that would explain the disputed status has already been proposed at Talk:Kaja Kallas#RfC: Footnote in infobox birthplace. WP:AGF requires that we assume other editors have non-nefarious reasons for doing what they do, even if we don't agree with their positions. Editors are allowed to have a specific point of view. When I collaborate with editors who challenge me because they come from a different point of view, if we work for understanding and look at reliable sources, articles come out with stronger sourcing and we create a version we all find fair and neutral. -- Beland (talk) 11:38, 1 February 2026 (UTC)[reply]
What about Crimea option? stating de-jure and de-facto control? Im shure there was extensive RFC for it.
Like "Internationally recognised as Latvia territory occupied by USSR (see State continuity of the Baltic states)"?? Add links where needed. Its neutral, it gives facts, and Baltic situation require it. But im shure there will be people who will talk about maps, de-facto controll, too much text and so one, jsut to keep solviet union there. BerzinsJanis (talk) 17:05, 1 February 2026 (UTC)[reply]
And the RFC was initiated by User:Glebushko0703 (now blocked), who had already made mass edits to "SSR" format before starting the RFC - hardly a neutral process. For an account that has been created a mere two days ago you are surprisingly familiar with wiki processes and things that happened months before your account creation. Nakonana (talk) 17:38, 1 February 2026 (UTC)[reply]
I'd appreciate if we could focus on the substance of the arguments rather than speculating about my account. The point stands: the RFC was initiated by a now-blocked user who had already made mass edits prior to starting it. Whether that concern is raised by a new account or an established editor doesn't change its validity. Seungsahn (talk) 17:44, 1 February 2026 (UTC)[reply]
I would agree if there weren't massive news reports in the Baltic countries and reddit posts that tell people to come to those RfC and "control"* the English Wikipedia (*that word was used in at least one of the news articles). This violates WP:CANVASSING policies and is something that the closer of an RfC needs to be aware of (which you probably already know given your familiarity with wiki processes). You are also not the only new account in this RfC who doesn't have any contributions anywhere on Wikipedia outside the Baltic birth place question. Nakonana (talk) 17:52, 1 February 2026 (UTC)[reply]
Baltic birthplace is sensitive topic in Baltics, its a bit foolish to expect that there wont be any new editors, or reapearing ones when it has gained mainstream media attention in all 3 Baltic states. Like it or not, it will generate new editors, who will want to join topic and there is no way to figure out if they are here on there own wish, or someone asked them. BerzinsJanis (talk) 17:56, 1 February 2026 (UTC)[reply]
Tbh I think you guys are shooting yourself in the foot with this behavior. The more you push, the harder the pushback. This kind of behavior has even the potential to alienate people who'd usually be sympathetic towards you and your cause under different circumstances [65][66]. Nakonana (talk) 18:21, 1 February 2026 (UTC)[reply]
And would your opinion would be in this matter? Please provide neutral opinion on this matter. One that could be acceptable for most.
Please provide neutral opinion on this matter. One that could be acceptable for most. Then are you actually asking for my opinion if you only want to hear a "neutral" opinion? And why would a "neutral" opinion need to be one that is acceptable for most? A third party expert could give their neutral opinion in a court, but that neutral opinion may not be liked ā neither by the accusing party nor by the accused party ā, because the neutral opinion might come to the conclusion that both parties are in the wrong.
Note: I have already voted in the Survey section.
At this point I also note that you are a new account who doesn't have any edits outside the Baltic birthday question and who also appears to be quite familiar with wiki processes despite being a newbie. Nakonana (talk) 18:46, 1 February 2026 (UTC)[reply]
Since wikipedia is place for neutral data sharing, and pushing single point of view is against policies, you should probably re read wikipedia policies.
Ahh how nice, if you would have taken an deeper look at my account you would find that i have made really many policies mistakes at start, because i had no idea what Im doing. Lucly university student council role, did help me to adjust to speak more policy based than feeling based. And since we are pointing things out, I do wounder why you are so against term "Occupied" when it is internationaly recognised fact, see State continuity of the Baltic states, is it because by your own words, you are from russia? You are entitled to your opinion, but please here provide arguments for and/or against it. So far your opinion of rest of variants beeing to "cumbersome" does not hold to well against Crimea example and Im shure it had its own fights in RFC. BerzinsJanis (talk) 18:57, 1 February 2026 (UTC)[reply]
Editors are allowed and expected to have non-neutral opinions. This is actually helpful because readers have non-neutral opinions, and it's necessary to look at any disputed topic from multiple perspectives in order to make sure that our text isn't taking a stand that any of them feel is non-neutral, and to make sure we're giving an overall fair description. -- Beland (talk) 19:47, 1 February 2026 (UTC)[reply]
I'm against "occupied" because this is not how those places are referred to most of the time when they are being talked about outside of the Baltic states themselves. Furthermore, several adverb have been suggested above, so simply for the sake of pragmatism, to not have another debate over which adverb is the most "accurate", most "neutral" one, I'd opt for an option that doesn't use any adverb at all, therefore my preferred phrasing would be "city, then part of xSSR, Soviet Union" with xSSR being a link to the corresponding article. This "then part of xSSR" is also the option that I've seen being used on German wiki for example, so it seems like a good middle ground. Nakonana (talk) 20:00, 1 February 2026 (UTC)[reply]
Ahh I see.... So using simply Latvia, Estonia or Lithuania should be enought, since these were terms used to reffer to them outside strict political setting. So what are we going to do now? Now there are two terms used, unofficial common name and official used only in specific context.
This isn't about "pushing" or "causes" - it's about whether Wikipedia's treatment of the Baltic states complies with WP:NPOV given their unique legal status under international law. The arguments stand or fall on their merits, regardless of who makes them or how many people care about the issue.
If you have concerns about WP:CANVASSING, those should be raised through the appropriate channels, not used to dismiss arguments in this discussion. The same could be said about the original RFC - there was documented off-wiki canvassing on both sides, including editors who were later blocked. None of this changes the substantive point: the RFC was initiated by a now-blocked user who had already made mass edits, and the distinct legal status of the Baltic states under international law remains inadequately addressed.
As for new accounts engaging with this topic - the Baltic birthplace issue has recieved significant media coverage recently, which naturally draws attention from people who care about accurate historical representation. New editors becoming aware of Wikipedia discussions through news coverage and choosing to participate is not inherently improper. I'm here making policy-based arguments supported by verifiable sources. If those arguments are wrong, I welcome a substantive rebuttal. Seungsahn (talk) 17:56, 1 February 2026 (UTC)[reply]
What I'm doing is an appropriate way to address canvassing issues per WP:MEAT: In votes or vote-like discussions, new users may be disregarded or given significantly less weight, especially if there are many of them expressing the same opinion. Their comments may be tagged with a note pointing out that they have made few or no other edits outside of the discussion. I'm not aware of canvassing regarding the original RfC. The now blocked user was blocked for personal attacks iirc, not for canvassing.
status of the Baltic states under international law remains inadequately addressed. ā why does it need addressing by the English Wikipedia though? Crimea also currently has a status of it not being accepted as legit part of Russia, yet wiki Commons is currently applying Russian freedom of panorama laws on contributions from Crimea instead of the more restrictive Ukrainian freedom of panorama laws. Wiki p rojects don't always do what you expect (or demand) them to do. Nakonana (talk) 18:35, 1 February 2026 (UTC)[reply]
I do want to remind that RFC is not a popularity contest and actual voting is discoridged if possible. Also if you look at Crimea info box you will find this text "Internationally recognised as Ukrainian territory occupied by Russia (see Political status of Crimea)" claiming that Crimea is accepted by Wikipedia as being part of russia, is clear missinformation and pushing single point of view. BerzinsJanis (talk) 18:39, 1 February 2026 (UTC)[reply]
On WP:MEAT - noted, but these comments are in a discussion shaping a new RFC, not a vote. Arguments here should be evaluated on their merits regardless of account age.
On "why does it need addressing" - because this is literally what this discussion is for. We're here to shape a new RFC on Baltic bios infoboxes. If the distinct legal status of the Baltic states under international law isn't relevant to that RFC, what is? The Crimea/Commons example doesn't establish that Wikipedia should ignore internationally recognized legal distinctions - WP:NPOV is a core policy of this project and applies regardless of what other Wikimedia projects do. Seungsahn (talk) 18:43, 1 February 2026 (UTC)[reply]
Thanks a lot. Noting that this is a follow-up to the previous RfC, which offered a "PanevÄžys, Lithuania" option. There was consensus there that "PanevÄžys, Lithuanian SSR, Soviet Union" was preferable, and the current RfC is only to figure out the specific linking and wording to implement that option. Chaotic Enby (talk Ā· contribs) 11:30, 31 January 2026 (UTC)[reply]
I know this RFC covers Baltics bios, only. But I'm hoping whatever is decided here, will be applied to bios of all people born and/or died in all 15 Soviet republics. GoodDay (talk) 21:47, 30 January 2026 (UTC)
IMHO, this "not a vote" notice should be deleted, as it may cause tensions. GoodDay (talk) 16:29, 31 January 2026 (UTC)[reply]
Baltic states in solviet union are a bit special (They were never part of it de jure and almost no state recognised there occupation) compared to other solviet republics, to whom you can make arguments about there legality in solviet union. Trying to push for the same solution seams ood at the best, pushing some narative at the worst. BerzinsJanis (talk) 10:43, 1 February 2026 (UTC)[reply]
From offered variants I say F is the best then E. Im still amaised why there are no offers like Latvia, then occupied by solviet union. Especially since no one disputes the occupation fact, and only few countries in the world recognised it. BerzinsJanis (talk) 11:24, 1 February 2026 (UTC)[reply]
I agree with BerzinsJanis. The Baltic states represent a unique case that cannot be treated identically to other Soviet republics. Unlike the Ukrainian SSR, Belarusian SSR, or other constituent republics, the Soviet annexation of Estonia, Latvia, and Lithuania was never recognized de jure by the majority of Western nations.
Applying the same infobox format used for republics whose Soviet status was internationally recognized to countries whose annexation was explicitly deemed illegal creates a false equivalence and raises serious WP:NPOV concerns. The RFC did not adequately grapple with this distinction, and treating the Baltic situation as identical to other SSRs does appear to advance a particular historical narrative rather than reflect the nuanced international legal reality. Seungsahn (talk) 16:53, 1 February 2026 (UTC)[reply]
This isn't a matter of opinion or what either of us personally believes. The non-recognition of the Baltic annexation is a documented historical and legal fact.
The Baltic states kept functioning diplomatic missions in Western capitals throughout the Soviet period. This distinct legal status is extensively documented in the article State continuity of the Baltic states and is not comparable to the status of other Soviet republics. Whether the Baltics are "special" isn't a matter of IMHO - it's a matter of verifiable historical record. Seungsahn (talk) 17:01, 1 February 2026 (UTC)[reply]
I notice you haven't addressed the substantive point. The distinct legal status of the Baltic states isn't something we need to "agree" on - it's documented fact supported by decades of international state practice and extensive reliable sources. If you believe this documented historical record is incorrect or irrelevant to the infobox question, I'd welcome a policy-based argument explaining why. Simply stating we won't agree doesn't engage with the WP:NPOV concerns raised.
This was precisely the problem with the original RFC - these substantive legal and historical distinctions were never adequately addressed, with participants instead treating it as a matter of preference rather than policy. I'll leave it to other editors to evaluate the arguments presented here. Seungsahn (talk) 17:07, 1 February 2026 (UTC)[reply]
The non-recognition of the Soviet annexation of the Baltic states by most Western nations for fifty years is not an "interpretation" - it is documented historical fact. Interpretations vary; the historical record does not. Seungsahn (talk) 17:21, 1 February 2026 (UTC)[reply]
Arguments being previously raised is not the same as arguments being adequately addressed. Throughout this discussion, you have responded to documented historical facts with "IMHO," "we won't agree," and "each editor has their own interpretations" - none of which engage with the substantive policy concerns raised. With respect, if the response to sourced, verifiable facts is simply to express personal opinion without policy-based counterargument, I'm not sure continued participation in this discussion is productive. I remain open to hearing an actual rebuttal to the points raised about the distinct legal status of the Baltic states under international law. Seungsahn (talk) 17:26, 1 February 2026 (UTC)[reply]
If you are not being able to agree that Baltic states were illegaly occupied by solviet union. You should not take part of decision for this topic. If this is you stance, then you are directly pushing solviet union point of view!!! BerzinsJanis (talk) 17:09, 1 February 2026 (UTC)[reply]
Again, its is not my opinion, but internationaly recognised fact that have its own wikipedia article State continuity of the Baltic states its the fact that should be taken in account for this discussion. If an editor simply wants to ignore it, or pretend its not a well documented fact, the said editor should not take part in a discussion where its an important point.
My understanding, is that wikipedia aims to provide netural accurate information, ignoring important facts, or making missleading comments (not aimed at editor at question) about them is definetly not how Wikipedia should work. BerzinsJanis (talk) 18:04, 1 February 2026 (UTC)[reply]
Britannica is not bound by WP:NPOV. What other encyclopedias choose to do is not a policy-based argument for what Wikipedia should do. The point remains: the Soviet annexation of the Baltic states was never recognized de jure by most Western nations, which distinguishes them from other Soviet republics. This distinction has not been addressed. Seungsahn (talk) 18:07, 1 February 2026 (UTC)[reply]
In that case these people for example shouls have there birth place changed to city, Nazi Germany, since they all were born in place while under Nazi Germany occupation.
Thanks for pointing me to the Manual of Style. As I understand it, MOS:Biography "Birth date and place" section does NOT specifically address what to do when a birth country was under illegal occupation that was never recognized de jure by most Western nations. In the absence of specific guidance, WP:NPOV should take precedence. Seungsahn (talk) 18:22, 1 February 2026 (UTC)[reply]
I suppose you are referring to where it says "now Vilnius, Lithuania"? But per the infobox documentation we do not include the modern-day location. Mellk (talk) 18:28, 1 February 2026 (UTC)[reply]
Obviously the Soviet Union did not agree that its annexation was illegal, even if it was not recognized by its enemies. That non-recognition is objectively true, but the fact that the Soviet Union administered these territories is also objectively true. Pointing out the fact of Soviet control is not a moral endorsement of that act, it's an important piece of context our readers need to know. The task here is I think to represent the unusual situation concisely and with regard to due weight. -- Beland (talk) 19:33, 1 February 2026 (UTC)[reply]
Thank you - this is a fair point and I appreciate the substantive engagement. I don't dispute that Soviet control is relevant context. My argument isn't that Soviet administration should go unmentioned, but that presenting Baltic birthplaces in the same "City, SSR, Soviet Union" format as other republics implies a legitimacy that was explicitly rejected under international law. The occupation itself is also an important piece of context our readers need to know - and the "SSR, Soviet Union" format obscures rather than communicates that. A format like "Tallinn, Soviet-occupied Estonia" would acknowledge the de facto Soviet control while also reflecting the de jure continuity that most Western nations maintained, and would accurately convey to readers that this was an occupation, not an ordinary administrative arrangement. This seems more consistent with WP:NPOV. Seungsahn (talk) 19:38, 1 February 2026 (UTC)[reply]
OK, you can respond to the survey and advocate that option. There is also another RFC that asks if we should accomplish the same goal with an explanatory footnote. -- Beland (talk) 19:56, 1 February 2026 (UTC)[reply]
There's other birth/death places of bio infoboxes, that include other former countries, like Yugoslavia & Czechoslovakia. But, that's for down the line. GoodDay (talk) 15:12, 1 February 2026 (UTC)[reply]
To summarize the position I've outlined in this discussion: the Baltic states occupy a unique position under international law. Their Soviet annexation was never recognized de jure by most Western nations for fifty years, they maintained diplomatic missions throughout the occupation, and this is extensively documented in our own article State continuity of the Baltic states. This fundamentally distinguishes them from other Soviet republics and means applying an identical infobox format raises serious WP:NPOV concerns. The original RFC did not adequately address this distinction. I note that throughout this discussion, these substantive arguments have not been engaged with. The responses I've received have consisted of personal opinions ("IMHO," "we won't agree," "each editor has their own interpretations"), questions about my account age, references to what other Wikimedia projects do, and suggestions that raising these concerns constitutes "pushing." Not once has anyone provided a policy-based rebuttal explaining why the documented legal status of the Baltic states is irrelevant to how Wikipedia presents their history in infoboxes.I believe any new RFC on this topic must explicitly address this legal distinction rather than treating the Baltic states as identical to other Soviet republics. I'll leave this on the record for the RFC framers and closers to consider.Seungsahn (talk) 19:00, 1 February 2026 (UTC)[reply]
The argument about state continuity in the Baltics was in fact made in Wikipedia talk:Manual of Style/Infoboxes#RFC: Baltic states birth infoboxes, so I don't see how it could be considered that they haven't been "adequately engaged with". I think it would be more fair to say the choices there were somewhat binary, but that's why participant suggested adding a footnote and that triggered a followup RFC, and that's also why "administered by" etc. are choices offered in this RFC. -- Beland (talk) 20:04, 1 February 2026 (UTC)[reply]
Their Soviet annexation was never recognized de jure by most Western nations for fifty years ā just out of curiosity: what about non-Western nations? Nakonana (talk) 21:11, 1 February 2026 (UTC)[reply]
I have collapsed the "vote" above by Seungsahn. Every comment and response by them has been LLM generated and cannot be engaged with in earnesty. Though I am leaving up comments already there with substantial engagement. Seungsahn, if you want to contribute here do so in your own voice; we are not here to entertain undisclosed chatbots. Gotitbro (talk) 09:02, 2 February 2026 (UTC)[reply]
Sure but we do not need 100% "ironclad proof". When you have enough experience dealing with LLM cruft and the biolerplate nonsense and hallucinations generated by them, you can substantially tell when that is the case as here. And when multiple tools and judgment tell me that is the case, it becomes pretty clear what has been done. WP:MANDY of course can never be defence for editors employing LLMs and then denying them. Gotitbro (talk) 09:47, 2 February 2026 (UTC)[reply]
You may refuse to see what is clearly there in front of everyone others won't, that the editor in question is still running around with boilerplate LLM cruft is all that needs to be said about this. Gotitbro (talk) 04:17, 3 February 2026 (UTC)[reply]
@Gotitbro: I wrote the comments myself. Accusing other editors of using AI without evidence is not constructive and borders on a personal attack per WP:AGF and WP:NPA. So far most of the responses to my contributions have been personal accusations (that my account is too new, that I'm using an LLM), rather than any engagement with the substance of my arguments. If you disagree with my position, address the policy reasoning. Please uncollapse my comment. Seungsahn (talk) 09:15, 2 February 2026 (UTC)[reply]
Highlighting dishonest LLM usage is not a personal attack, neither is noting a new user (though I did not point this out at all) handily wading through contentious topics and obscure noticeboards all the while using LLMs, especially when that user is coming from recent sanctions. If you do not come with clean hands do not expect others to not be wary. Gotitbro (talk) 09:38, 2 February 2026 (UTC)[reply]
AI detectors have well-known problems with false positives, especially for non-native English speakers - e.g. this Stanford study [1] found they misclassified over 61% of essays by non-native speakers as AI-generated. You've now collapsed two of my comments without once engaging with what I actually said. Please address the arguments or leave my comments alone.
I would obviously waste no time in engaging with chatbot responses. Do non-native speakers also generate bulleted, essay, flowy responses exactly like ChatGPT [74], do non-native speakers also make unabated use of em dashes exactly like LLMs, do non-native speakers also show very proficient familiarity with enwiki policies (though of course without knowing how they actually apply as LLMs do not know one thing from the next) despite barely beginning to edit. If the answer to all of that is no, which it is, you should know that absolutely no one is buying the MANDY here. Gotitbro (talk) 10:08, 2 February 2026 (UTC)[reply]
@Gotitbro: I don't think an RFC is the proper place to 'claim' someone is using LLMs. If you're convinced someone is using LLMs? then your concern should be brought to administrators. GoodDay (talk) 15:34, 2 February 2026 (UTC)[reply]
Other editors should fully know when subjected to LLM cruft, the exact reason we make no consideration of AI generated nonsense for consensus (e.g. RfC) and templates like {{Collapse AI}} exist. An ongoing discussion is the most apt place to being it, sorry. Gotitbro (talk) 15:49, 2 February 2026 (UTC)[reply]
Seungsahn should also be reminded that Wikipedia does "de facto", not "de jure". The problem with de jure is that it's inherently not WP:NPOV: it depends whose jus you go by. However much we might not like it the fact is that the Baltic States were incorporated into the Soviet Union, and the rest of the world did nothing about it. Phil Bridger (talk) 09:56, 2 February 2026 (UTC)[reply]
Unfortunetly its not always the case see info box Crimea, also there are multiple policies as use modern names and geolinks and others that give some choice in this matter. And that assuming that every article follows them. While I would prefere using only Latvia, Estonia and Lithuania as places of birth, there are good arguments to use them with solviet union, hell there are good argument to not use solviet union liek Names Latvia, Estonia and Lithuania were commonly used terms link to 1989 news video and not Latvia sssr or solviet union. The biggest problem is that many editors does not want to discuss what showing only solviet union is damaging to Baltic states. Including usage of LLM that harvest data from here. I believe such details about occupation are important to include in info box, or in its foot note. Im more than willing to discuss how it should look like, i'm willing to make compromises to it. BerzinsJanis (talk) 10:13, 2 February 2026 (UTC)[reply]
Thanks, I am aware of that. However ignoring the fact that a significant and well-documented dispute exists is not informative for the reader.
As for "the rest of the world did nothing about it" ā that's not accurate. Most Western countries maintained non-recognition of the annexation for the entire occupation, the Baltic states kept functioning diplomatic missions throughout, and the Welles Declaration was never rescinded. Seungsahn (talk) 13:59, 2 February 2026 (UTC)[reply]
I'm not aware of any policy that favors de facto over de jure. When there's a mismatch between the two, deciding whether to ignore one or neither comes down to how important and relevant the discrepancy is, and policies like WP:DUE. Hardly any laws are fully followed or even fully enforced, and when that matters (and shows up in reliable sources) we should say so. For example, Legality of cannabis maps out where laws are enforced, where they are not enforced, and where recreational use is legal. But on Free trade area and List of countries by tariff rate we don't mention smuggling, even though it's a way of de facto bypassing tariffs. -- Beland (talk) 21:54, 2 February 2026 (UTC)[reply]
Request for Advice After LLM Complaint
I am asking for advice either for what I should do next or for what two editors should do next about a dispute at Demographics of Singapore and Talk: Demographics of Singapore. One editor made some edits, and the other reverted the edits with a short statement. So far, that was consistent with BRD. The first editor then posted a reply consisting of multiple bullet points, and the other editor collapsed it, saying that it was the output of artificial intelligence. I have not tried to analyze whether it was the output of artificial intelligence. There was then a request at the Dispute Resolution Noticeboard. I have closed the DRN request because DRN should be preceded by discussion, not by a rejection of discussion. Pinging @Aleain and Apa1ni:, What is the proper procedure after discussion has failed because of a claim that a large language model is being used? Robert McClenon (talk) 02:30, 16 January 2026 (UTC)[reply]
The issue here is that a very frequent Wikipedia editor (Aleain, who's far more familiar with the tricks of the trade) has simply accused me of using LLM. This was a false and serious accusation for which Aleain provided zero evidence. Aleain used this accusation to collapse my detailed explanations of my edits and prevent any further discussion.
As you can imagine, I am no longer as keen as before in contributing to Wikipedia. I'm a far less experienced and occasional Wikipedia contributor who simply wishes to make some occasional good-faith contributions. I was astonished that my explanations could simply be shut down through this accuse-others-of-LLM trick (which I'd never seen before anywhere on the internet). And I'm sure many other occasional contributors have been similarly subjected to such abuse either by Aleain or others.
May I suggest that this trick (of accusing others of using LLM with zero evidence and collapsing their comments) be appropriately sanctioned/punished? At the very least, Aleain should be given a severe warning to not do this again. Apa1ni (talk) 05:57, 17 January 2026 (UTC)[reply]
You seem to be more experienced. Could you help me make this report? I'm merely an occasional Wikipedia editor and it's just way too complicated to make sure I dot all the i's and t's (I'm sure that if I try making a post there, there'll be all sorts of little details that I missed out on and which will be again held against me). I don't even know what the difference is between all the different pages "WP:ANI", my talk page, the other user's talk page, the article's talk page, "Third Opinion", etc. etc. Apa1ni (talk) 07:47, 18 January 2026 (UTC)[reply]
Just now, Aleain has again reverted many of my edits to the same Demographics of Singapore page, while ignoring all of the information I've repeatedly given at the article's Talk page, my edit summaries, the Dispute resolution page. For example, Aleain incorrectly reinserted the old false statement that "the remaining 1.8 percent, categorised as Other, are largely Eurasians". I've repeatedly pointed out that this is false and now repeat: "In the 2020 Census, only 18,060 of the 129,669 "Others" (in the Resident population) were 'Eurasian'". Aleain has not taken care to read and consider the facts I've provided. It seems clear that Aleain is deliberately edit warring with me. But I am now highly hesitant to edit this (or any other) page lest I be once again accused of edit warring. Apa1ni (talk) 07:59, 18 January 2026 (UTC)[reply]
@Apa1ni, thank you for being cautious and avoiding edit warring.
If the problem still exists, then you might try the "baby steps" approach. Look at all the changes that have been reverted. Pick out a very small change that is simple and high-quality. Make just that tiny change, and see whether that gets reverted. For example, I just split one paragraph into two. See if you can make another tiny change that would improve the article, and see what happens if you do. WhatamIdoing (talk) 23:05, 22 January 2026 (UTC)[reply]
I'm afraid that after this experience I won't ever make another edit to a Wikipedia article. I'm not sure why more experienced (and therefore more powerful) users here are allowed to bully less experienced users, revert their edits wholesale, accuse others of using LLM, and collapse their comments as LLM-generated with zero consequence. Meanwhile, I have to take "baby steps" and be incredibly cautious. Apa1ni (talk) 04:02, 23 January 2026 (UTC)[reply]
Don't get discouraged too quickly! But note that one of Wikipedia's pillars is to Assume Good Faith. We try not to explain other editors' actions by malicious intent unless the evidence for this is very strong ā which does not seem to be the case here. Most likely, the other editor made a honest mistake in interpreting your comment as LLM-generated. As far as I can see, the collapsing of it was the reverted, allowing the discussion to go on. Hence there was no lasting damage and I'd suggest to continue the discussion, trying to resolve the content conflict. Focus on the content, not on any person. Or you might move on to other stuff in Wikipedia you'd like to improve and try whether that works without pushback ā if your edits are neutral, grammatically okay and sourced to reliable sources, most of the time it will. Gawaon (talk) 09:10, 23 January 2026 (UTC)[reply]
Aleain repeatedly and rapidly reverted wholesale all of my edits. Aleain accused me of being "snarky". On my posting of comments at the article's Talk page, within 18 minutes, Aleain had collapsed all of my comments as being LLM-generated and also posted "Nice. An LLM response. This is fruitless." Do these sound like the actions of someone who "Assumes Good Faith" and isn't malicious? Apa1ni (talk) 04:27, 25 January 2026 (UTC)[reply]
It appears that Aleain has said that they no longer believe that you are using an LLM, so I think we may proceed as if that mistake never happened.
About all your edits being reverted: Yes, that happens sometimes, especially if (as you have said) they are not completely perfect. But if you take a baby step ā just one little, carefully checked, less-contentious edit, to add or change just one little thing ā you might find that you are able to make progress. WhatamIdoing (talk) 07:38, 25 January 2026 (UTC)[reply]
All Aleain said was "I have largely stopped assuming that they are using a LLM". Note the "largely". And of course, it's probably too much to hope that I'll ever get a sincere apology or hope that Aleain will in any way be punished or that such behavior will not repeat (whether by Aleain or anyone else). // You say, "I think we may proceed as if that mistake never happened." You are free to be magnanimous (about this wrong done to me and not to you) and proceed that way. I will not do so. The "mistake"āor rather, malicious repeated rapid wholesale reverts of my edits, accusations of LLM-generation (including even posting at the ANI), and collapsing of my comments as LLM-generatedāall very clearly occurred and I will not pretend (as you seem happy to do) that they never happened. And I will never again edit any articles here. // You also state that "the collapsing of it was the [sic] reverted". But this reversion was probably done by some other editor rather than by Aleain. Apa1ni (talk) 08:34, 25 January 2026 (UTC)[reply]
So what? And if you're unwilling to listen to advice, why ask for it in the first place? Also, if you want to reduce your risk of being suspected of using LLMs for your writing, do it like me and manage to introduce lots of typos and small mistakes in most of your edits.Gawaon (talk) 08:55, 25 January 2026 (UTC)[reply]
Unfortunately, like too many Wikipedia editors here, you fail to read carefully before posting and pouncing on others for the slightest perceived transgression. It wasn't I who asked for any advice. Scroll up and see who it was that did. Apa1ni (talk) 09:06, 25 January 2026 (UTC)[reply]
I stand corrected! Even so, listening to advice is maybe not the worst idea ever. Just saying. Also, OP did indeed quickly get the advice they had asked for: "just tell the two editors to move on". Those are still words of wisdom, so let's all just move on. Gawaon (talk) 11:31, 25 January 2026 (UTC)[reply]
@Apa1ni, experienced editors use the "baby steps" approach mainly for two purposes:
As a way of figuring out which, of many changes, the other person actually disagrees with. Sometimes reverting editors only disagree with one source or one sentence, but they decide to take a lazy approach and throw the baby out with the bath water. If you present them with one small change, they may accept it. Then you've made progress both in improving the article (your small change was accepted) and in understanding the dispute (the main objection must be to some other part).
As a way of differentiating between an ordinary dispute and a reverting editor who has certain kinds of behavioral problems (e.g., violating Wikipedia:Ownership of content). In this sense, you should think of "baby steps" less as you being restricted or cautious, and more like you quietly laying a trap for a misbehaving editor. If all of your changes, no matter how small and unimportant, get reverted by the same person, then it's time to address behavior instead of content.
To repeat, Aleain has repeatedly reverted wholesale most of my changes. (Please see the history page on what exactly happened.) In Aleain's latest reversion, Aleain kept only a few of my updates of figures (e.g. replacing old 2015 or 2020 population figures with new ones). Otherwise, Aleain reverted everything else. For example, Aleain incorrectly reinserted the old false statement that "the remaining 1.8 percent, categorised as Other, are largely Eurasians" (even though I've repeatedly explained why this is false). Aleain also removed the facts I gave on Singapore's rapid population growth (more than doubling in 35 years), dismissing this as "undue commentary". Apa1ni (talk) 04:25, 25 January 2026 (UTC)[reply]
Aleain also removed the facts I gave on Singapore's rapid population growth (more than doubling in 35 years), dismissing this as "undue commentary". Because it is? Comparing Singapore's demographics and cherry-picking to other countries that are vastly different in size, political climate and history is not productive or relevant. Singapore is a city-state with its own unique demographics trend that cannot be equated to those of much larger nations. Using tweets from Elon Musk and performing your own analysis of World Bank data to support these claims is inappropriate. It suggests your usage of Wikipedia to soapbox personal views on Singapore's population policies rather than engaging in objective and policy-based editing. Aleain (talk) 14:32, 25 January 2026 (UTC)[reply]
Having a population double in just 35 years is a fairly unusual circumstance. The last time that happened in the US was when the Baby boomers were born. "More than doubling in 35 years" is not comparing against other countries, cherry-picked or otherwise.
I wouldn't cite a tweet, but one of Wikipedia's functions (in practice, not by original design) is to provide correct information to social media users. If the twitterverse (broadly defined) has its facts wrong, then Wikipedia should be a place where interested people can get the facts right. If social media is saying that the population is declining, and the opposite is actually true, then Wikipedia should have the actual, verifiable facts both correct and prominent in the relevant article(s). WhatamIdoing (talk) 18:06, 25 January 2026 (UTC)[reply]
On the other hand, OR (per "performing your own analysis of World Bank data") is not allowed, and the whole debate about what to add or modify in the article in question should probably happen on the article talk page, not here? Gawaon (talk) 19:05, 25 January 2026 (UTC)[reply]
I guess the issue refers to the statement "In the 35 years from 1989 to 2024, Singapore's population increased by 106.0% (more than doubled). In comparison, the same figure was 71.5% for India, 58.6% for Bangladesh, 37.8% for the US, 26.0% for China, 21.3% for the UK, and 0.7% for Japan.", reverted by Aleain, which was sourced to a "SingStat Population Excel file" and some "World Bank Open Data". That is, for sure, somewhat odd, especially the "In comparison" data ā retrieving population figures for seven countries from two databases/spreadsheets and than doing one's one calculations for them seems to go beyond simple CALC (without repeating the same OR, other editors cannot check whether the data is as reported and whether the resulting calculations are indeed correct), and moreover, the obvious question here is: What's the point of the comparisons? Gawaon (talk) 21:37, 25 January 2026 (UTC)[reply]
Probably it doesn't, but I strongly suspect that the point of contention is indeed the second sentence, not (or much less) the first one. Gawaon (talk) 22:16, 25 January 2026 (UTC)[reply]
I believe we have deviated from Robert McClenon's initial questions and concerns and are now more focused on content dispute which is better served at the page's talkpage instead of the village pump.
Robert McClenon's current concerns are whether the allegation, without evidence, of using a large language model to post is a personal attack, and whether the accused party may reasonably report the allegation at WP:ANI so to come back to his concerns, do we want to act on Aleain's not assuming good faith and jumping to allegations of using LLM and should Apa1ni made a post on ANI on Aleain's bad faith and allegations.
I agree with the point about the content discussion better being lead on the article talk page, as I had already said above. As for the other issue, the two ANI threads (linked by WhatamIdoing (talk) 07:34, 25 January 2026 above) ended with "Dispute resolution is the right approach here. No admin action needed", so I think we can consider that settled. Gawaon (talk) 09:12, 26 January 2026 (UTC)[reply]
The ANI thread is filed by Aleain against Apa1ni and conclusion is that LLM is not used and the content better settled elsewhere (basically consensus on Apa1ni is not using LLM). The ANI thread however does not address Robert McClenon 's followup questionson should we do anything about Aleain.
Robert McClenon is effectively asking should Aleain be WP:BOOMERANG-ed. Bad faith assumption of allegations of LLM usage to pile on content dispute? Should we be jumping to conclusions straight away and file an ANI report straight away? Should such editors be warned etc? This is effectively biting newcomers.
If we treat as a case of WP:BITE, did Aleain Apologize, explaining what motivated you to bite. I see indifference and a lack of response by Aleain. ~ JASWE (talk) 10:15, 26 January 2026 (UTC)[reply]
No. My followup question wasn't about Aleain and Apa1ni. I was asking a general question. The answer could then be applied to the specific question. One of my concerns is about various ways of yelling in order to "win" a content dispute. Yelling "Vandalism" in order to "win" a content dispute is sometimes done, but is known to be a personal attack. I was asking whether yelling Artificial Intelligence without evidence is a personal attack. But this discussion is becoming stale, and I will probably ask the question some other time in the near future. Robert McClenon (talk) 00:42, 1 February 2026 (UTC)[reply]
Reposting Robert McClenon's followup questions for clarity and ease, whether the allegation, without evidence, of using a large language model to post is a personal attack, and whether the accused party may reasonably report the allegation at WP:ANI.~ JASWE (talk) 10:20, 26 January 2026 (UTC)[reply]
Robert communicates in a very straightforward style. If he meant "Should we BOOMERANG against this editor?" or "Did this editor make a bad-faith assumption?", he would have asked exactly that.
Instead, he has asked a general question: Is this behavior a personal attack? It's safe to assume that he meant the question he asked.
I think the answer to his question is: Maybe sometimes, but not usually. We don't expect people to provide specific evidence of LLM use, but if someone persists in making accusations of LLM use after others disagree, or if they try to discredit someone generally ("If you need an LLM to write in English, you aren't educated enough to know whether this mathematics article contains errors"), then I think it could be considered a violation of Wikipedia:No personal attacks. WhatamIdoing (talk) 21:06, 26 January 2026 (UTC)[reply]
I agree. We must be able to point out AI slop / likely LLM-generated comments or we'll risk drowning in it. And there'll hardly ever be definite proof ā nobody can know what other editors do on their computers, after all. So such statements, as long as they are made in good faith and not explicitly worded as personal attack, should certainly not be held against the editor who makes them. Gawaon (talk) 21:38, 26 January 2026 (UTC)[reply]
I also think we should separate "assuming good faith" from "being welcoming". Wikipedia:Assume good faith is about reminding yourself that when someone screwed up, they didn't intend to do any harm to Wikipedia (even though you think they did).
I'm not worried about drowning in LLM-generated comments on the talk page. It's pretty easy to ignore them (maybe not on super high-traffic pages, but on most of them). WhatamIdoing (talk) 21:42, 26 January 2026 (UTC)[reply]
First I understand Apa1ni's concerns, and I might agree Aleain is a bit too harsh here and might be jumping the gun in some accusations (particularly about the alleged use of LLMs in replies). However, also reviewing the edits, there are some valid concerns of WP:SYNTH of primary sources. Yes, we can quote primary sources for basic facts and some inferences based on WP:CALC, but to do any comparison is already a form of synthesis/analysis that would require backing up by secondary sources.
GLAM (cultural heritage) has a link to WP:GLAM (code is [[wikipedia:GLAM|GLAMāWiki Initiative]]), which feels wrong. The text itself is fine ā it refers to the GLAM-Wiki project in a neutral, encyclopedic manner, in line with WP:WAWI ā and if we want to link to the project page, of course it's done correctly from a technical perspective. However, the whole idea of linking to a project page seems a bit odd. Aside from disambiguation links (e.g. the hatnote on MOS) and a single link to WP:PP from an article that was already discussing the protection policy (it's been a long time; I don't remember where I found it), I don't remember ever seeing mainspace links to project space. WP:LINK isn't particularly helpful, because its prohibition on non-mainspace links has an exception for project links that pass WP:WAWI.
My question here is the way it's used ā if one clicks a link to Wikipedia's protection policy, or the link in For Wikipedia's Manual of Style (MOS), see Wikipedia:Manual of Style, one expects to reach a project page. In this setting, technically, it's not a WP:EGG violation because WP:GLAM does cover the GLAMāWiki Initiative, but until I clicked it, I anticipated an encyclopedia article about the initiative, not a project page.
Thoughts? I came here rather than the article's talk page because it's little-trafficked; it had just two edits of any significance last year. Nyttend (talk) 02:39, 19 January 2026 (UTC)[reply]
We sometimes put such links in a hatnote ("You may be looking for WP:WHATEVER"), but I don't think they should be in the body of an article. WhatamIdoing (talk) 23:48, 22 January 2026 (UTC)[reply]
Annual review of the Universal Code of Conduct and Enforcement Guidelines
I am writing to you to let you know the annual review period for the Universal Code of Conduct and Enforcement Guidelines is open now. You can make suggestions for changes through 9 February 2026. This is the first step of several to be taken for the annual review. Read more information and find a conversation to join on the UCoC page on Meta.
Help:Find sources is surprisingly useful even for veteran editors (I read it now and I learned some stuff, YMMV). I added a few tips and links there now, but one big gap I am not sure how to handle is the AI research. As most of us know, AI can be used to find sources, with varying results, of course. I don't know if there is a place we discuss this use of AI (arguably, among the least controversial and problematic, assuming, of course, one actually verifies the sources existence and content :P)? And if not, maybe it would be good to brainstorm what folks use, what works, and what we can tentatively recommend on that help page? Personally, I had some luck using ChatGPT deep research, telling it to find sources in languages I don't read (particularly non-latin; and, yes, I did translate and verify content in them myself later). Something like "find sources that would be accepted as reliable by Wikipedia about topic X in languages X, Y and Z" tends to work, but I am sure there is much more than can be done? There are several platforms that claim they can help researchers find sources like https://consensus.app/ but I haven't really done any serious testing. Piotr Konieczny aka Prokonsul Piotrus| reply here05:08, 20 January 2026 (UTC)[reply]
Not sure what you're asking about. LLMs, while often wrong, can sometimes be useful to find some sources, such as some sources to start with or some additional sources or some sources about things which you couldn't readily find sources the usual way. I'm using DuckDuckGo as a search engine and there I can just switch to ask the AI where I can select the model and I don't trust its answers the slightest so I just go to the links and usually they're about what I was looking for. Some specific chatbots may work better for finding sources but they're probably not free to use and there isn't much to say about other to be very vary of what the LLMs write, to not neglect the normal ways to find sources and to ask for something like "high-quality sources" or "sources as good as scientific reviews" etc. Prototyperspective (talk) 19:05, 25 January 2026 (UTC)[reply]
[Research] Preliminary analysis of AI-assisted translation workflows
LLMs were found to be significantly better than traditional tools at retaining Wikicode and templates, simplifying the "wikification" process.
26% of human edits fixed issues already present in the source article (e.g., dead links), showing that the process improves the original content too.
Human editors modified about 27% of the AI-generated text to reach publication quality.
We found a ~5.6% critical error rate (distortions or omissions). This confirms that "blind" AI publication is not suitable; human oversight is essential.
Claude and ChatGPT led in prose quality, while Gemini showed a risk of omitting text. Grok was the most responsive to structural formatting commands.
Acknowleging limitations: We consider these findings a "first look" rather than a definitive conclusion. The study has several limitations, including:
Subjectivity: Error categorization is inherently dependent on individual editor judgment.
Non-blind testing: Editors knew which models they were using, which likely influenced their prompting strategies.
Sample size: While we processed over 400,000 words, the data for specific model comparisons across all 10 language pairs is insufficient.
Our goal is to provide some data for the community as we collectively figure out the best way to handle these tools.
Is there a way to see how the LLMs performed when translating into different languages? I'm guessing LLMs are better at writing English than Polish, just because there is more English content available for them to learn from. It'd be interesting to see how good the prose/accuracy was for each language it translated into. TurboSuperA+[talk]08:11, 21 January 2026 (UTC)[reply]
I have published the raw data in the study itself, so you could have a look at it if interested. However, I wouldn't recommend it because there is a strong editor<>language-pair correlation, which leads to bias. I.e., each editor typically covered only 1-2 language, so when comparing the performance between two languages, it's going to be very hard to remove the noise due to editor's intrinsic differences (e.g., their tendency to overcategorize errors in one bucket) vs effects from the language itself. 7804j (talk) 21:03, 21 January 2026 (UTC)[reply]
Can I ask why the focus is on translating articles from smaller Wikipedias into the largest ones rather than the other way around? Even just one full-time translator on sw.wiki would go a long way Kowal2701 (talk) 12:24, 21 January 2026 (UTC)[reply]
Hi User:Kowal2701, the full report doesn't include this info, but the language translation pairs are available in the raw data (see histogram). Most of the 127 translations are from English into another language. ENāPT is by far the most common language pair (59 articles, 46.4%). Others: ENāPL (25 articles, 19.7%), PLāEN (11 articles, 8.7%), ENāES (10 articles, 7.9%). Only 12% of the article pairs were translating to English. Cheers, Suriname0 (talk) 16:13, 21 January 2026 (UTC)[reply]
Thank you. Those are still fairly big wikis though, I wouldāve thought that prioritising languages with high speakers to wiki-size ratios would be most value for money Kowal2701 (talk) 16:46, 21 January 2026 (UTC)[reply]
In general, OKA prioritizes translations into Wiki languages for which there are many native speakers. So outside of that particular study, we prioritize EN, PT, ES. We also exclude languages that we already know have poor performance in automated translators, due to different character sets and grammar (e.g., Chinese, Arabic, Japanese). We had tested these in the past and saw that it didn't perform well.
For that particular study though, we left it fully up to the editors to pick up articles for any language, in order to move fast but also to have as much diversity as possible (for more generalizable findings). The primary focus was about collecting data about LLMs in general, not necessarily to assess "which language works best" 7804j (talk) 21:01, 21 January 2026 (UTC)[reply]
Hmmm, in my experience, ChatGPT has a 50% or higher chance of omitting text. I use it for translations, but it is LAZY, and very often I have to tell it to complete the task or do it myself. After a kick or two, it will produce a near perfect translation, but at least for me, again, I often have to tell it to finish the job. Maybe it's a prompt issue, shrug. Additionally, it's much better at coding in English than Polish, i.e. it knows English wikicode better than Polish wikicode; it too often tries to "translate" template names etc. from English to Polish, and uses en wiki MoS, not pl wiki. Wonder if the study looked at translations from en, not just to en? Piotr Konieczny aka Prokonsul Piotrus| reply here01:49, 22 January 2026 (UTC)[reply]
Hey Piotrus, most of the translations were from English to non-English languages (see my comment above, since I was also curious about this). Agree that specific model and process is super important for translations. Cheers, Suriname0 (talk) 01:55, 22 January 2026 (UTC)[reply]
@Suriname0 Any data on which tools are best for translations to and from Chinese and Korean? Most of the students I supervise use these languages, and right now I don't have model/tool specific recommendations for them. I'd love to have some, based on hard data (and, before anyone asks, telling them not to use LLM is pointless - they'll do it anyway, this generation/cohort is already AI-native, and fighting with that is pointless, for better or worse, sigh). Piotr Konieczny aka Prokonsul Piotrus| reply here05:29, 22 January 2026 (UTC)[reply]
@Chipmunkdavis It does; however, it is hard to be 100% sure if it is LLM laziness, or the human translator - although from what I see in related discussions, it likely is both (lazy human did not sufficiently check what lazy LLM did). The good news is that based on my experiences, AI tends not to hallucinate with this type of error, it just skips much content. There could, however, be problems with which refs it chooses to keep in such cases. All affected sections need to be redone from scratch. This is not that hard - I've had good results, as I said, just telling AI not to be lazy and redo stuff, although when it come to long articles, this may be challenging (my sample is small and generally consists of reasonably small articles, ones I've written myself, so that makes it extra easy for me to find errors in AI output; and I've noticed AI tends to have issues working with larger blocks of text, which is unfortunate, although I hope this will be fixed in due time, and anyway, these days most articles I write are reasonably short and amenable for AI translation - with a kick or two in the lazy robot's butt). Piotr Konieczny aka Prokonsul Piotrus| reply here06:55, 22 January 2026 (UTC)[reply]
Thanks, I did find one hallucinated source added to a fully translated section, so your concern about which refs it chooses to keep seems a very possible issue. CMD (talk) 07:03, 22 January 2026 (UTC)[reply]
Good to know. Hope these teething problems will go away soon. I think it's best practice to check the ref count and placement. When I see lazy translation, I don't check for hallucinations, I just tell AI to redo the work. I haven't found hallucinations in correct translations, but yes, I wouldn't be surprised they'd make their way to the lazy iterations. Heck, right now I am using AI to do OCR and create some tables, and every second page it gives me hallucinations, then promises not to, rinse and repeat, sigh. (Still, it's saves me a lot of time, and the end output is good - but if one doesn't double check everything, oh my...). Piotr Konieczny aka Prokonsul Piotrus| reply here07:24, 22 January 2026 (UTC)[reply]
LLMs were found to be significantly better than traditional tools at retaining Wikicode and templates, simplifying the "wikification" process. this is one of the main issues with the current translation system/methods.
I think the conclusion shouldn't be to become more fine with LLM-translations (not that you're suggesting that; you mentioned the ~5.6% critical error rate) but instead to improve the translation system (which of course if one doesn't want to waste huge amounts of time and be limited by one's personal vocabulary & skills, involved machine translation).
There also is an alternative approach mentioned there which would also enable templates to be translated properly etc ā however, the normal one-at-a-time translation methodology should imo at least given a proper chance which needs these improvements (especially for non-English Wikipedias where the best & most efficient way to start a new article often is translating from an already existing high-quality article). If it's too long for people to at least glance over it: when I machine translate an article from English WP to another language I speak, I need to spend more exhausting time on fixing all the ref template issues than for actual proofreading and rewording/rewriting. The ContentTranslation tool of course is entirely useless in practice currently.
However, I have to say I have too little experience with and knowledge about the use of LLMs for translation to really say whether things could be improved to a state where using them for translation is a good idea compared to normal machine translation. However, I'm doubtful about it. Thanks for doing this interesting study with useful findings/quantifications. Prototyperspective (talk) 18:55, 25 January 2026 (UTC)[reply]
@7804j, that's fascinating, thanks for sharing the results. Have you tried using LLMs to review translations and flag omissions? Conceptually this task would be similar to the tool I've built which checks whether sources support claims (User:Alaexis/AI Source Verification).
We haven't tried LLMs for reviewing translations, no, though from personal experience they can indeed be quite useful at that (though it leads to editors much more quickly reaching usage limits on free plans, which is why we haven't deployed ot at scale).
We haven't used the open source models because they require some more setup, but given how well DeepSeek performed in this study I also assume they would do fairly well 7804j (talk) 19:19, 27 January 2026 (UTC)[reply]
I have been trying to access Special:Random without it redirecting, and failing. Whenever I try to add the &redirect=no parameter, it just adds it to a random page instead of showing the Special:Random page. Can someone please tell me how to access the Special:Random page without it redirecting, and/or why the normal parameter to do so doesn't work? (If you think this should have been added in tech, that's for bug reports, and this isn't one.) AndyShow1000000 (talk) 14:40, 22 January 2026 (UTC)[reply]
There is no "page" at Special:Random. Redirecting is all it does. What would you expect to happen if it didn't redirect?
That being said, if you're really curious, you could do something like open the developer console in Chrome (I'm assuming other browsers support something similar), go to Special:Random and then look in the network tab to see what came back before the redirect happened. If you're into command-line terminals, you could do the same thing with cURL or similar tools. RoySmith(talk)15:23, 22 January 2026 (UTC)[reply]
Some time ago I asked about this and was directed to the code base where it is implemented. I was favorably impressed, and amused by comments like "Trust me, I'm a mathematician" that appear in the code. Zerotalk00:59, 23 January 2026 (UTC)[reply]
I have come across many accounts with 50k, 100k, etc., that got blocked for a variety of reasons. Is this rare or more common?
How can long time editors get kicked out of wikipedia. šCinarootš¬03:13, 25 January 2026 (UTC)[reply]
Rare, because not many accounts have that many edits to begin with. Just because you have a lot of edits and are an established editor doesn't make you immune to the rules. I personally feel like such accounts get blocked for sockpuppetry (e.g. they have/had another account where they vandalised; surprisingly more common than you'd think for an established editor), bigotry, like outing themselves as a racist, transphobe, homophobe etc which is not tolerated here, or constant fights and disputes with a lot of editors which take a toll on the community, until enough is enough and they are blocked. Side note, read WP:UNBLOCKABLES; it's a page about how, even though the rules should not differ between an established editor and a new one, oftentimes established editors become "unblockable" by the virtue of being well-known and a constructive editor in some areas, leading to people defending them even if they break rules and their conduct is improper in some aspects. jolieloverā„talk03:23, 25 January 2026 (UTC)[reply]
Actually, I'll list out some really interesting blocks I remember, though I'm not sure I should say by name, I personally think it's fine to mention them since this is Wikipedia history and I did find this information from a public page we all can view on WP:Former administrators.
An administrator reveals they are ANOTHER administrator who was blocked after paid editing and NPOV violations. After the admin's OG account was blocked, they created a new one where they cultivated an entirely new persona and became a respected member of the community (again). They also alluded to being an indie Spanish musician (who has a page here), when they were in fact not. Many people were confounded because he genuinely built friendships with people as this indie Spanish musician persona, only for it to be fake; blocked for sockpuppetry.
I think this may have happened on another project (Commons, maybe?) but on a request for administrator, a trusted user (I think admin) comes out as a transphobe and makes a bitter comment about the requester being a man in woman's clothing. People were also baffled by this since they were a trusted user and thought their account could have been compromised; but they refused to double down and it became clear that they were just transphobic.
A former administrator here is noticed to have inappropriate userboxes relating to being a Neo-Confederate. After an ANI discussion they are blocked, though some people objected as they hardly edited anymore and it seemed to be punitive rather than preventive.
Agree 100% - though in CT topics - Fights are unavoidable and probably constant. Its difficult to work in those area's and you need to learn how to be better and keep getting better šCinarootš¬03:37, 25 January 2026 (UTC)[reply]
How can long time editors get kicked out of wikipedia. - Usually because they start thinking their shit no longuer stink and that behavioural standards don't apply to them anymore. Headbomb {t Ā· c Ā· p Ā· b}20:38, 25 January 2026 (UTC)[reply]
And history tends to support that thinking. About 18 years ago, I put on my "To Do" list that I wanted to suggest WP:CIVIL be demoted to guideline as it's obvious from reading various noticeboards that it isn't going to be enforced as a policy. It was always a pointy thought, but nothing has changed my mind about it. Established users get away with things...until they finally don't. Having 50K+ edits shouldn't make you untouchable. --Onorem (talk) 21:33, 25 January 2026 (UTC)[reply]
It doesn't make you untouchable, but it does factor in determining who is WP:HERE and who is WP:NOTHERE. Kicking out an editor with say 75,000 edits, the majority focused on improving content is not something that should be commonplace, unlike kicking out vandals with 38 edits all spamming "MR JOHNSON THE 3RD GRADE TEACHER AT JOHNSONVILLE HIGH SCHOOL IS A POOPYHEAD", which should be done with as little thought as possible. Headbomb {t Ā· c Ā· p Ā· b}22:48, 25 January 2026 (UTC)[reply]
How much is "start thinking", versus that they always thought it and community norms shifted away from tolerating the bad with the good over time? Or burnout of some sort leading to poor decisions? Or re-judging things from 10 years ago under today's norms? Anomieā02:24, 26 January 2026 (UTC)[reply]
Some admins do try to shield long-term users. I was being harassed WP:HOUND by a long-term editor months ago - the admin (summoned by other editor) tried to diffuse the situation and asked them to back off from me (in a nice way) and told me about the good things about them. šCinarootš¬08:55, 26 January 2026 (UTC)[reply]
From what I can see, at least 5 of the accounts listed in the top 100 in WP:NOE are blocked (though one of those accounts is technically an alt account of a user whose main account is not blocked.) Sugar Tax (talk) 20:43, 25 January 2026 (UTC)[reply]
I just checked and it seems that in the last few weeks I must have passed 50K edits. I have never been blocked (although I have been told off a few times for using naughty words) largely because I don't have the attitude that my longevity means that I should be held to a different standard than an editor who is just starting. Phil Bridger (talk) 21:09, 25 January 2026 (UTC)[reply]
I think it also helps to have a WP:DGAF attitude (please, those who don't like the aforementioned naughty words, don't go there). I don't want to be blocked, and wouldn't deliberately do anything to cause it, but if I am then it's not the end of the world, and I would have more time for other things. Phil Bridger (talk) 22:18, 25 January 2026 (UTC)[reply]
Political ideologies, like many abstract concepts in philosophy and related fields, are just not suited to the factoid-style of infoboxes we have. Usually the key aspects cannot accurately, or uncontroversially, be put into a couple of words. Johnbod (talk) 13:03, 28 January 2026 (UTC)[reply]
Note that this post does not concern anything which is important.
Some time ago, I could have sworn I had seen this one specific humorous essay. I really wanted to find it again, but no matter how many times I tried to look it up, I couldn't find it at all. That, on top of the fact that the exact details of the essay elude me, I've come to the conclusion that it might literally be an essay I had encountered in a dream, because I can find no evidence that it currently exists, and I'm sure it would not have been deleted.
If there actually is an essay (or something related on Wikipedia) in existence matching this description, though, let me know!
The content of the essay was simply a joyous, whimsical word salad along the lines of "Lalalala lala! Lalala~ Woohoo! Lalalalala! Yippee! Lalala lala lalalala lala yaaay lalala! Lalalala-la-la~!" for several paragraphs. This constituted all of the text, aside from boilerplate template text. There may have been an accompanying image of a painting, depicting a group of folks holding hands in a line prancing across a meadow.
If it exists as I know it, it's the best humorous essay on Wikipedia and I need to find it again. If it doesn't, then I suppose my waking self continues to be thoroughly entertained by the mischief of my dreaming self. I refuse to entertain the notion that it may have existed at one point but got deleted later. MEN KISSING(she/they) T - C - Email me!23:17, 26 January 2026 (UTC)[reply]
That's crazy. I've never browsed that site, so I must have either somehow seen a version of it reposted elsewhere or seen a similar version posted here then? Or maybe we're thinking of two different things. MEN KISSING(she/they) T - C - Email me!04:07, 27 January 2026 (UTC)[reply]
Hmmm, attempts to look up "lalala" on RationalWiki show mostly people referencing a "LALALA I CAN'T HEAR YOU" style fallacy, with no indications of any sort of essay of whimsy and wonder. I'm afraid I believe that is unrelated. MEN KISSING(she/they) T - C - Email me!04:42, 27 January 2026 (UTC)[reply]
Is there any reason we don't have an equivalent of commons:Template:Art Photo? (Or if we do, what is it called?) It's really useful for clarifying a relatively common, but tricky, copyright situation (one copyright for the photo, another for the underlying artwork). It would be very useful for images that we host here that are PD in the U.S. but still copyrighted in their home country, especially because it means that when their copyright in their home country eventually expires, they would port easily to Commons. - Jmabel | Talk00:47, 28 January 2026 (UTC)[reply]
Don't really know where to talk about this, but couldn't this be both an edit notice and a talk page banner? Consensus would be easier to get for that, right? Sorry if I'm wrong. Nugs | TĀ·C | (they/she)21:36, 28 January 2026 (UTC)[reply]
There was no consensus to delete the talk page banners, so they'll stay. There are no widely used edit notices for that purpose. Gawaon (talk) 21:48, 28 January 2026 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I noticed that Wikipedia is far more likely to say negative things about third-world countries, especially ones the imperialist mainstream media has vilified. I don't see third-world sources like Sputnik and Press TV cited as often as imperialist sources like the BBC and New York Times, even though they are just as (if not more) trustworthy. Wikipedia is also biased against AES (Actually-Existing Socialism). This is evident when comparing its coverage of real ideologies like Marxism-Leninism and Maoism with idealist ideologies like Anarchism, or with vassal states as opposed to independent ones. The language used to describe things in political articles is also highly inaccurate, like describing Euromaidan as an organic "protest" rather than a coup (this happens a lot, actually).
This is, of course, not the fault of any individual editor(s). This is because Wikipedia has limited itself to only spread the narrative put out by western corporate media, in spite of the historical facts and proper dialectical materialist analysis which are readily available to editors, or even just relying on existing sources which are not imperialist or corporate in nature. For example, the BBC is responsible for a large amount of misinformation regarding the 1989 Tian'anmen Square riots which has since been conclusively debunked by more reliable sources. Frankly, I'm infuriated at how so many people have accepted the blatantly false narratives being pushed on us by bourgeois and imperialist media because nobody has bothered to challenge them. It's likely that nobody will listen to me about this. I understand, as a trans woman I am very used to being ignored. However, I am begging for even the simplest explanation of why Wikipedia will not trust perfectly good sources that do not align with the imperialist agenda. I am hoping that this question will at least get somebody to read theory or something. Bunabyte (talk) 06:49, 29 January 2026 (UTC)[reply]
I don't see third-world sources like Sputnik and Press TV cited as often as imperialist sources like the BBC and New York Times, even though they are just as (if not more) trustworthy.
lol, lmao even.
However you said "as often" - please let me know any locations you've seen Sputnik and Press TV being used as sources as I'd like to remove them.
We don't care whether a source is from the Global North or the Global South, but whether it's reliable or not. And we don't reach conclusions on this lightly, but after careful debates whenever there's a need for them. You can find the outcome of these discussion documented at Wikipedia:Reliable sources/Perennial sources. For example, for several of the sources you mention it says:
Press TV: "In the 2020 RfC, editors found a clear consensus to deprecate Press TV, owing to its status as an Iranian government propaganda outlet that publishes disinformation, conspiracy theories, antisemitic content including Holocaust denial, and a host of other problematic content. "
Sputnik (news agency): "There is consensus that Sputnik is an unreliable source that publishes false or fabricated information ... Sputnik is considered a Russian propaganda outlet that engages in bias and disinformation".
So maybe you should reconsider who's really falling for misinformation and whom you can trust more, whom less. Wikipedia is not perfect, for sure, but I think we're generally doing a fairly good job of getting these things sorted out. Gawaon (talk) 08:36, 29 January 2026 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The following discussion has been closed. Please do not modify it.
After multiple blocks for harassment and edit warring, a site ban has been proposed for Glebushko0703 who disrupted hundreds of articles about Estonia and Lithuania. Editors pointed out that many edits of Glebushko0703 violated the NPOV policy, and the overt bias shown by Glebushko0703 against Estonian editors and the associated harassment which contributed to the said blocks. Given the scale of the disruptions, it is not possible to examine every edit made by Glebushko0703 in those articles.
As pointed by the admin who proposed the ban:
I proposed that Glebushko0703 should be banned from the site due to their ongoing harassment of LordCollaboration, their repeated insistence that they needed to call out Estonian editors for sockpuppetry despite having never produced a shred of evidence and after having been blocked for that near the end of December, and because their tendentious campaigning had led two administators to ban them from their talk pages
...
It's rather clear now that nothing will stop Glebushko's bizarre campaign against Estonians, evidenced by this most recent block for the same thing targeted at a different user. Therefore I propose again that they be banned from Wikipedia. And I will revert if someone closes this early again.
In this case, would it be a good idea for trusted editors to be granted rollback rights to revert all edits made by Glebushko0703 in articles about Estonia and Lithuania? If Wikipedia community members are concerned about the credibility of Wikipedia, the prioritization of Wikipedia's protection is necessary. It is equally necessary to make it clear that what happened as a result of Glebushko0703 is nowhere acceptable regardless of the justness of his belief.
The December RFC created by Glebushko was flawed, and so was its close. Initially, I reverted lots of edits by Glebushko in infoboxes of Baltic people. But now I think we should do this in an orderly fashion. The RFC is still accepted by many users. Reverting all edits by Glebushko would cause more harm than good. At the moment, there's a new RFC at Talk:Kaja Kallas#RfC: Footnote in infobox birthplace. I hope it will lead to a more neutral presentation of Baltic birth places, and I hope there will be other RFCs to apply this more broadly. Then we'll have to change lots of birth places in infoboxes again, but maybe not exactly to the old version. Depends on what the community decides. ā Chrisahn (talk) 15:24, 30 January 2026 (UTC)[reply]
Refusal to accept the 2025 Dec RFC decision via reverts of its implimentations? is disruptive behavour which leads to blocks. GoodDay (talk) 15:29, 30 January 2026 (UTC)[reply]
Georgefrank55 I have redacted your contact information for your protection, it is unwise to post it in this very public place. This page is for discussing various Wikipedia matters, it is not a general help desk for the internet. 331dot (talk) 19:14, 30 January 2026 (UTC)[reply]
Great, now more conspiracy theories will latch onto the "OMG Wikipedia is EVIL" train without knowing the very basic information that Wikipedia is free for anyone to edit. jolieloverā„talk11:47, 1 February 2026 (UTC)[reply]
There is no need to "hack" Wikipedia to include true information that is supported by reliable sources, or to exclude false information that is not. You can simply edit it. Phil Bridger (talk) 19:39, 1 February 2026 (UTC)[reply]
It's a Hungarian organization. I've found in multiple wiki article different names/translations, Alliance of Hungarian Associations and Union of Hungarian Organisations - upon crosschecking it turns out both are refering to MESZ. If you go on google translate it spits out Federation of Hungarian Associations. There should be only one name in articles relating to this organization, I don't know which one.Setenzatsu.2 (talk) 20:44, 2 February 2026 (UTC)[reply]
If the sources mentioning this organization favor one name of the organization over all others, then it would be a good idea to stick to it, similar to the WP:COMMONNAME policy for article titles.
If the sources are divided, then it would be a good idea to make sure it is clear in an article that the different translations refer to the same organization. For example, you can add an explanatory footnote to the mention of the organization. Inside the footnote, add regular citations explaining the alternative translations. āā andrybak (talk) 01:15, 3 February 2026 (UTC)[reply]
Polygnotus (talk) 20:21, 31 January 2026 (UTC)
Resolved
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)
Auditorium of the Old Burgtheater, 1888ā1889, Vienna Museum
Auditorium of the Old Burgtheater, 1888ā1889, Vienna Museum -->
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. [24].png)
.png)
. Didn't they go out in 1998? Mathglot (talk) 09:22, 15 January 2026 (UTC)
On Vector 2022...
...and on Minerva Neue
wikimedia.org
_-_Diana_Rennik.jpg){kind=link}
_-_Alexei_Saks.jpg){kind=link}
Moved from WP:VPWMF Ā§ Wikipedia "cyber villains"
.jpg){kind=spacer}
![[69]](https://commons.wikimedia.org/wiki/Commons:Deletion_requests/File:Simferopol_-_train_station_-_Feb_2011.jpg#c-JWilz12345-20220721020900-TentingZones1-2022-07-03T13:41:00.000Z){kind=link}
