Jump to content

Wikipedia:Village pump (policy)

From Wikipedia, the free encyclopedia
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

The policy section of the village pump is intended for discussions about already-proposed policies and guidelines, as well as changes to existing ones. Discussions often begin on other pages and are subsequently moved or referenced here to ensure greater visibility and broader participation.

  • If you wish to propose something new that is not a policy or guideline, use Village pump (proposals). Alternatively, for drafting with a more focused group, consider starting the discussion on the talk page of a relevant WikiProject, the Manual of Style, or another relevant project page.
  • For questions about how to apply existing policies or guidelines, refer to one of the many Wikipedia:Noticeboards.
  • If you want to inquire about what the policy is on a specific topic, visit the Help desk or the Teahouse.
  • This is not the place to resolve disputes regarding the implementation of policies. For such cases, consult Wikipedia:Dispute resolution.
  • For proposals for new or amended speedy deletion criteria, use Wikipedia talk:Speedy deletion.

Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after 6 days of inactivity. To keep this page's size accessible, discussions with more than about 100 comments should be split to a separate page.

Seeking clarification on WP:NEWLLM regarding human-reviewed translations

[edit]

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.
There also exists an ongoing RfC to possibly update that guideline at Wikipedia:Village pump (policy)/Replace NEWLLM with the text of User:Qcne/LLMGuideline which does away with the from scratch verbiage. You're welcome to weigh in there as well. fifteen thousand two hundred twenty four (talk) 15:02, 3 January 2026 (UTC)[reply]
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.
@Piotrus @I2Overcome FYI 7804j (talk) 18:10, 28 January 2026 (UTC)[reply]
@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. I2Overcome talk 23: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 here 01: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]
Wow. And how are you qualified? Did you take any examination to be here? Piotr Konieczny aka Prokonsul Piotrus| reply here 03:35, 22 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.)
At the very least, that section isn't a translation, by definition, as there was nothing to translate. Gnomingstuff (talk) 14:53, 8 January 2026 (UTC)[reply]
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.
Additional source-text WP:V checks:
Other observations:
It would appear that there may have been some miscommunication, as that section certainly is the product of a generative model and there is strong evidence of a lack of adequate review of the output. fifteen thousand two hundred twenty four (talk) 16:33, 8 January 2026 (UTC)[reply]
@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]
In the interest of keeping this conversation on-topic, it would be best to direct any further replies and questions to the pre-existing large language model noticeboard thread at WP:LLMN#Likely AI translations by User:Leeanah with some issues, which also contains some additional information not yet discussed here. fifteen thousand two hundred twenty four (talk) 23:55, 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]
Hi! Thanks a lot for the feedback. I decided to do a quick spot-check of your latest translation, Draft:La Bourdonnaye family, to make sure that everything was going well.
I see that you added a few sources to claims tagged in the French original as missing a source, such as the origin of the La Bourdonnaye family at the beginning of the #History section. The source you added links to the second edition of Nobiliaire et armorial de Bretagne, but gives the date of the first edition (which was published under a different name, so I presume you meant to cite the newer one). However, looking at the provided page number, 147, it doesn't talk about the La Bourdonnaye family at all – instead, the families listed on that page range from Cadelac to Cado.
The actual mention of Bourdonnaye, on page 114, does not talk at all about them originating from a lordship in Trégomar, Côtes-d'Armor. I am worried that you might not have actually checked the sources that you have been adding, and I would be happy to see evidence of the contrary. Chaotic Enby (talk · contribs) 17:02, 11 January 2026 (UTC)[reply]
This reply does very little to assuage concerns about llm-use. CMD (talk) 23:49, 11 January 2026 (UTC)[reply]
"I'm sorry, but I don't believe that". Ummm, WP:ABF much? Piotr Konieczny aka Prokonsul Piotrus| reply here 03:37, 22 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.
I don't speak French, so this is an incomplete and possibly inaccurate review.
I no longer expand or supplement content during translation. My role is strictly limited to translating existing, sourced text ... – The addition of sources which fail verification would appear to contradict this statement, apologies if I've misunderstood. fifteen thousand two hundred twenty four (talk) 20:30, 11 January 2026 (UTC)[reply]
  • I think this is quite complex. The extent to which I think LLM-assisted machine translation is appropriate depends on:
  1. 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.
  2. The topic. For example, the Japanese Wikipedia is credibly alleged to contain bias about the Nanjing Massacre, comfort women, and Unit 731.
  3. 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 Marshall T/C 10: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. -- LWG talk (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. -- LWG talk (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]
This seems to be what's being referred to. Gnomingstuff (talk) 13:46, 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]
@Grudzio240 An RFC was initiated here on this topic -- you may want to add your input there as well 7804j (talk) 12:34, 8 January 2026 (UTC)[reply]
I will just add my sig to what Grudzio said - I fully agree with that. LLM translation is fine, IF checked (proofread etc.) and fixed as necessary by a responsible human. Piotr Konieczny aka Prokonsul Piotrus| reply here 03:45, 22 January 2026 (UTC)[reply]
I’m curious… is there a reason you have not mentioned that your organization uses Grok for all its translation purposes? ExtantRotations (talk) 02:31, 9 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.

That's why they started this discussion in the first place. Mathglot (talk) 02:37, 9 January 2026 (UTC)[reply]
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]
I don't think we should take that too literally. For instance the editor in the case discussed above used ChatGPT at least for adding additional sources (example 1, example 2) Gnomingstuff (talk) 15:28, 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

[edit]

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.

Comments welcomed.—S Marshall T/C 13:58, 4 January 2026 (UTC)[reply]

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]
To note, these are really nitpicks, and your proposal would already be more than welcome as an addition to WP:TRANSLATE. 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 Marshall T/C 14:55, 4 January 2026 (UTC)[reply]
Good points! I had translation source in mind but didn't think of the ambiguity! Chaotic Enby (talk · contribs) 15:01, 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]
What would that standard look like? Draft one for us?—S Marshall T/C 14:43, 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]
I'd swap generated for translated, while there isn't much distinction between the two for the model, there is for the editor using it. The aim is to change one text into another, not to generate novel text. fifteen thousand two hundred twenty four (talk) 14:43, 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 Marshall T/C 14: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]
Apologies for not being more specific with my choice of words, we understand translation the same. Replace novel text with text without precedent. fifteen thousand two hundred twenty four (talk) 15:11, 4 January 2026 (UTC)[reply]
Seems fair, except I don't see why we need to require tagging the origin. We don't ask people what levels of proficiency they have, what exams they passed, etc. Piotr Konieczny aka Prokonsul Piotrus| reply here 03:47, 22 January 2026 (UTC)[reply]

Proposal 2

[edit]

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

d) You've complied with all the usual translation processes including terms of use-compliant attribution.

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.

Revised in the light of the above feedback.—S Marshall T/C 16:42, 4 January 2026 (UTC)[reply]

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 Marshall T/C 17: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]
The comments about the tag don't seem to have been addressed? Thryduulf (talk) 17:01, 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 Marshall T/C 17: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
Closes a possible loophole. WP:V covers this already of course, but stating such explicitly will prevent or alleviate some future issues. fifteen thousand two hundred twenty four (talk) 17:35, 4 January 2026 (UTC)[reply]

Proposal 3

[edit]

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

e) You've complied with all the usual translation processes including terms of use-compliant attribution.

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.

Changelog: Added "b", tweaked "d".—S Marshall T/C 18:58, 4 January 2026 (UTC)[reply]

Looks great! Chaotic Enby (talk · contribs) 19:12, 4 January 2026 (UTC)[reply]
B is redundant to D. It would be better to instead require that the translator explicitly check for and correct LLM-induced neutrality and tone issues. fifteen thousand two hundred twenty four (talk) 19:20, 4 January 2026 (UTC)[reply]
Much better. Some minor tweaks:
  • 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.
Gnomingstuff (talk) 19:23, 4 January 2026 (UTC)[reply]
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 Marshall T/C 20: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.". -- LWG talk (VOPOV) 19:47, 4 January 2026 (UTC)[reply]

Proposal 4

[edit]

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

e) You've complied with all the usual translation processes including terms of use-compliant attribution.

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.

It's important that proposals for further tweaks reduce, rather than inflating, the word count, please.—S Marshall T/C 20:33, 4 January 2026 (UTC)[reply]

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.
That said… I think we DO need a separate WP:USING AI policy to deal with it. Blueboar (talk) 21:08, 4 January 2026 (UTC)[reply]
There was an RfC on that a few months ago; WP:NEWLLM is the result. There's further discussion of it on that talk page. Gnomingstuff (talk) 22:01, 4 January 2026 (UTC)[reply]
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).
I'm just not sure what benefit to the project starting in draftspace over userspace would provide, the translator could always start in userspace, then move the page wherever they desire once it's checked and cleaned. fifteen thousand two hundred twenty four (talk) 22:43, 4 January 2026 (UTC)[reply]
  • 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]
creating rules may give certain editors the green light – This I do strongly agree with, a user rights approach would pose less of an open season issue. fifteen thousand two hundred twenty four (talk) 01:28, 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.
Neither is OK. Make sense now?—S Marshall T/C 01:52, 5 January 2026 (UTC)[reply]
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.

? Katzrockso (talk) 03:02, 5 January 2026 (UTC)[reply]
Ideally, it could be good to remove "dual fluency" from that last line too. Chaotic Enby (talk · contribs) 05:36, 5 January 2026 (UTC)[reply]
Replace 'dual fluency' with 'proficiency in both the origin language and English'. Yours, &c. RGloucester — ☎ 05:39, 5 January 2026 (UTC)[reply]
Additionally, I'm not sure why we would go back to version #1, as it does away with important additions such as checking for AI hallucinations. Chaotic Enby (talk · contribs) 05:41, 5 January 2026 (UTC)[reply]
Agreed. Version № 1 is clearly inferior. Yours, &c. RGloucester — ☎ 05:42, 5 January 2026 (UTC)[reply]

Proposal 5

[edit]

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

d) You've complied with all the usual translation processes including terms of use-compliant attribution.

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.

Basically, a condensed version of proposal 4. Chaotic Enby (talk · contribs) 05:49, 5 January 2026 (UTC)[reply]

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

d) You've complied with all the usual translation processes including terms of use-compliant attribution.

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.

Chaotic Enby (talk · contribs) 06:38, 5 January 2026 (UTC)[reply]
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]
I was thinking of adding it to WP:TRANSLATION, with {{guideline|section=y}}. Chaotic Enby (talk · contribs) 07:44, 5 January 2026 (UTC)[reply]

Iteration

[edit]

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

d) You've complied with all the usual translation processes including terms of use-compliant attribution.

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.

Slightly shortened.—S Marshall T/C 09:23, 5 January 2026 (UTC)[reply]

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]
"Verify" has a technical meaning on Wikipedia. "Check?" "Be certain?"—S Marshall T/C 09:58, 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 Marshall T/C 10: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]
(edit conflict) I know it was me who originally wrote "sufficient proficiency", but I do hope we can converge on something less pompous such as "enough knowledge".—S Marshall T/C 10:59, 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]
You want simple and Germanic, I see. I offer you one final alternative: 'skill'. Yours, &c. RGloucester — ☎ 12:17, 5 January 2026 (UTC)[reply]
If someone's English is not good then they shouldn't be translating articles into English. Gnomingstuff (talk) 17:54, 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 Marshall T/C 11: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 Marshall T/C 11: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?
For example, I have personally created many articles using the Historical Dictionary of Switzerland as a translation input, which is a creative commons source but only available in French, German and Italian. 7804j (talk) 14:25, 5 January 2026 (UTC)[reply]
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]
I presume that could work, it clarifies the intended meaning without changing it. Chaotic Enby (talk · contribs) 14:49, 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 here 03:54, 22 January 2026 (UTC)[reply]

Is this enough RFCBEFORE?

[edit]

Any further rewrites, queries, quibbles?—S Marshall T/C 15:51, 5 January 2026 (UTC)[reply]

In the interest of helping gauge sentiment: My thoughts are that these would be useful rules, for an LLM translator user-right. Were this proposed before a user-right, I'd be inclined to oppose. fifteen thousand two hundred twenty four (talk) 18:04, 5 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]
You don't need to !vote yet, folks, just say if you're happy to !vote on this.—S Marshall T/C 18:20, 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

[edit]

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

d) You've complied with all the usual translation processes including terms of use-compliant attribution.

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

[edit]

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

d) You've complied with all the usual translation processes including terms of use-compliant attribution.

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.

One final proposal. This one adopts the simple, Germanic 'skill' to placate Mr Marshall. Yours, &c. RGloucester — ☎ 21:47, 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

[edit]

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

d) You've complied with all the usual translation processes including terms of use-compliant attribution.

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.

We're very close to getting somewhere we can all agree with, please edit this to make any final changes as you wish. Chaotic Enby (talk · contribs) 23:29, 5 January 2026 (UTC)[reply]

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 Marshall T/C 08:55, 6 January 2026 (UTC)[reply]
That could work too! Chaotic Enby (talk · contribs) 09:06, 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]
I think this is well written and have no further suggestions. -- LWG talk (VOPOV) 15:09, 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
Chaotic Enby (talk · contribs) 18:25, 6 January 2026 (UTC)[reply]
  • 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 Marshall T/C 21: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]
    Sure, but what if you're porting over partially sourced text for a topic you happen to know a lot about? WhatamIdoing (talk) 02:09, 12 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 Marshall T/C 16: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]
That could work! Feel free to suggest that in the ongoing RfC, that would be a helpful wording improvement. Chaotic Enby (talk · contribs) 13:58, 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".
WhatamIdoing (talk) 22:51, 12 January 2026 (UTC)[reply]
The latter could be a quite helpful wording, thanks! Chaotic Enby (talk · contribs) 23:14, 12 January 2026 (UTC)[reply]
Indeed. This makes sense as best practices, not as requirements Piotr Konieczny aka Prokonsul Piotrus| reply here 10:45, 22 January 2026 (UTC)[reply]
I wonder if we'd like to recommend a two-stage editing process, similar to what we recommend for a WP:PROPERSPLIT. The two steps would be:
  1. Translate the article (accurately, with no additions or corrections, though you're free to omit things).
  2. Fix the remaining problems in the article (e.g., add missing sources, update out-of-date information, correct errors).
WhatamIdoing (talk) 02:23, 12 January 2026 (UTC)[reply]
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 here 03: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. Zerotalk 05: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 Marshall T/C 09:28, 22 January 2026 (UTC)[reply]
    I read this as "then we require you to ensure the article meets Featured criteria". Piotr Konieczny aka Prokonsul Piotrus| reply here 10:33, 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 Marshall T/C 11: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 here 11: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 Marshall T/C 12: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 here 12:58, 22 January 2026 (UTC)[reply]
    What? No! If AFCSTANDARDS is in conflict with core content policy, the core content policy prevails.—S Marshall T/C 15:53, 22 January 2026 (UTC)[reply]
    Then you need to demonstrate that conflict, and get AFCSTANDARDS changed - right now it has much more standing than the proposal here. Piotr Konieczny aka Prokonsul Piotrus| reply here 15: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 Marshall T/C 16: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]
    Hmmm. Either the entire AfC community is operating under a misunderstanding of or core policies - or you are wrong. Ockham's razor points in one direction... Piotr Konieczny aka Prokonsul Piotrus| reply here 04:21, 23 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:
    Type of statementPolicy requiring inline citation
    Direct quotationsWikipedia:Verifiability
    Any statement that has been challenged (e.g., by being removed, questioned on the talk page, or tagged with {{citation needed}}, or any similar tag)Wikipedia:Verifiability
    Any statement that you believe is likely to be challenged.Wikipedia:Verifiability
    Contentious material, whether negative, positive, or neutral, about living personsWikipedia:Biographies of living persons
    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 Marshall T/C 09: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]
    The problem is indeed not in the language, it's in the very requirement. People seem to confuse the concept of translating with writing; some effectively want to ban translations and require writing content from scratch. Piotr Konieczny aka Prokonsul Piotrus| reply here 10:44, 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". Zerotalk 12:34, 22 January 2026 (UTC)[reply]
    Then I expect you'll be wanting to pop over to Wikipedia talk:Translation#Request for comment and support "Option A". Personally I don't think anyone should be translating content they can't check. I feel that calls into question their editorial judgment.—S Marshall T/C 12:59, 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 Marshall T/C 13:37, 22 January 2026 (UTC)[reply]
    Yup, I already did (Option A), for the same reasons as explained here. Piotr Konieczny aka Prokonsul Piotrus| reply here 14:55, 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 here 05: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 here 05: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]
    Exactly. Piotr Konieczny aka Prokonsul Piotrus| reply here 07:51, 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 Marshall T/C 09: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 Marshall T/C 22:45, 27 January 2026 (UTC)[reply]
    Not my intention to imply otherwise. fifteen thousand two hundred twenty four (talk) 23:43, 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 here 04: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]
    If I am going to translate an article you wrote to Polish, should I WP:ABF - assume it may be bullshit - and verify each line? Piotr Konieczny aka Prokonsul Piotrus| reply here 01:11, 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 Albury 02: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]
    Not in my experience. Might depend on prompts and models, of course. Piotr Konieczny aka Prokonsul Piotrus| reply here 00:28, 3 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

[edit]

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]

I think you should reach out to @Ian (Wiki Ed). voorts (talk/contributions) 14:46, 15 January 2026 (UTC)[reply]
Thanks @Voorts. I'll reach out to them. Ian (Wiki Ed) (talk) 15:04, 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]
Spurred? Sparred? Spurned? EEng 02:23, 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]
Also check out the AI cleanup WikiProject. Thank you for doing this. Gnomingstuff (talk) 21:02, 15 January 2026 (UTC)[reply]
Professor of what? M.Bitton (talk) 01:11, 16 January 2026 (UTC)[reply]
Film studies. voorts (talk/contributions) 01:12, 16 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]

Unfortunately, formal group activities in Boston have become less frequent than they were, but still there is Wikipedia talk:Meetup/Boston where your request is likely to find help. Jim.henderson (talk) 21:10, 15 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! :) — Rhododendrites talk \\ 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]

Airport destination lists - sourcing requirements

[edit]
Moved to Wikipedia:Village pump (policy)/Airport destination lists - sourcing requirements
 – Discussion is getting very large, so splitting this off to a separate page. Some1 (talk) 18:56, 31 January 2026 (UTC)

Replace six disclaimer pages with one

[edit]
Moved to Wikipedia talk:General disclaimer § Replace six disclaimer pages with one
 – Per protection notice at WP:GENERAL Szmenderowiecki (talk · contribs) 07:00, 26 January 2026 (UTC)

@Phil Bridger, Katzrockso, Gnomingstuff, and Rutebega: Moved your comments to the talkpage of WP:GENERAL Szmenderowiecki (talk · contribs) 07:01, 26 January 2026 (UTC)[reply]

Upgrade MOS:ALBUM to an official guideline

[edit]

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]

  • I do support this. Camilasdandelions (✉️) 17:03, 26 January 2026 (UTC)[reply]
  • Note the MOS:ALBUM shortcut has been nominated for deletion at Wikipedia:Redirects for discussion/Log/2026 January 21#MOS:ALBUM. I have linked this discussion there and suggested it should be procedurally closed pending the outcome of this discussion, but I don't know how that will be received (I'm not neutral with regards the redirect, but have no strong opinions regarding the essay/guideline). Thryduulf (talk) 17:18, 26 January 2026 (UTC)[reply]
    Link to RfD corrected. Thryduulf (talk) 21:53, 26 January 2026 (UTC)[reply]
  • Oppose not really strong enough to carry the same weight as guidelines, and it lazily tries to give credits a free pass on being unsourced. SNUGGUMS (talk / edits) 17:58, 26 January 2026 (UTC)[reply]
    Where does it give a pass to credits being unsourced?--3family6 (Talk to me|See what I have done) 21:49, 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]
    Even the most reliable of reliable sources only attains 99.973% reliability. Phil Bridger (talk) 14:32, 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]
    "Verifiable" is not the exact same thing as "has a citation". If something does seem questionable and is challenged, then it should have a citation. Regardless of what an essay or an MOS guideline says.--3family6 (Talk to me|See what I have done) 19:57, 27 January 2026 (UTC)[reply]
    "just trust that I got these accurate" or "I don't need anything to back up my insertions of credits/personnel" - is anyone doing this? Refusing to provide a source when asked?--3family6 (Talk to me|See what I have done) 19:59, 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 look at these diffs. The choice to deliberately leave such sections with no sources is careless. SNUGGUMS (talk / edits) 23:03, 27 January 2026 (UTC)[reply]
    Thank you for those. Yes, those are WP:V violations and misusing the essay as well. I'm fine with changing the wording of the essay, if there's consensus for it.--3family6 (Talk to me|See what I have done) 13:38, 28 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]
    Personnell sections should have a citation if any of the people are living, then.--3family6 (Talk to me|See what I have done) 15:45, 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]
  • Weak support I like the idea of this proposal and the page seems fleshed out enough to be a part of the MOS. 3family6, do you have a link to the discussion at VPR? TIA mdm.bla 23:01, 26 January 2026 (UTC)[reply]
    It actually was here at the policy page, I misremembered. That then was moved to WT:ALBUM. Here is the discussion. If you want me to link to the RfCs, I can do that.--3family6 (Talk to me|See what I have done) 23:59, 26 January 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.bla 04: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]
    I've WP:BOLDly added an RFC tag and posted a message at WT:MOS. I would support the proposed page title that you've included, per the current shortcuts for the page MOS:ALBUM and MOS:ALBUMS. mdm.bla 16:31, 28 January 2026 (UTC)[reply]
    Thank you for that.--3family6 (Talk to me|See what I have done) 01:33, 29 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]
    Template:Manual of Style lists a number of subject-specific MOS subpages by topic area; this page is especially comparable to MOS:TV and MOS:VG. mdm.bla 17:52, 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?

[edit]

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]
I wish somone would explain this to the plane people. --User:Khajidha (talk) (contributions) 16:13, 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]
Indeed. Usually when I fly, I positively hope there isn't any infrastructure directly in the path of the plane. Cremastra (talk · contribs) 20:00, 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]
Which is why airports are notable, but flights aren't.--User:Khajidha (talk) (contributions) 16:39, 30 January 2026 (UTC)[reply]
And why just like bus routes, flights should default to having entries on a table rather than articles of their own. J947 ‡ edits 23:46, 1 February 2026 (UTC)[reply]
What Chipmunkdavis said, and also Wikipedia does not strive to create a balance between train-spotters and bus-spotters. Phil Bridger (talk) 10:35, 27 January 2026 (UTC)[reply]
Railway stations include some of the most iconic examples of architectural infrastructure ever built. Bus routes are lines on a map. AndyTheGrump (talk) 16:24, 27 January 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]
Also, bus stations tend to be more permanent and so are often notable. HJ Mitchell | Penny for your thoughts? 20:09, 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 Albury 00: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 Albury 19: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?

[edit]

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. Liz Read! 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]
This also potentially raises issues with things like role accounts (e.g. user:Arbitration Committee) and doppelgänger accounts. See also User:0. Thryduulf (talk) 22:25, 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]
These pages should just be deleted as useless and inherently confusing. See Wikipedia:Miscellany for deletion/User:Command line script. * Pppery * it has begun... 18:21, 28 January 2026 (UTC)[reply]
WP:Reserved usernames is a good idea. One to add there is User:MediaWiki default. MKFI (talk) 12:00, 29 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]

Possible policy issues with a planned DYK set

[edit]

WT:DYK#Pokémon-related set on February 27?: 27 February 2026 is the 30th birthday of Pokemon, and the day they will probably announce the next generation (see e.g. here). Is it acceptable (per WP:SPAM/WP:NOTADVERTISING) to have a whole section of the Main Page dedicated to a commercial product on the day they will most likely start some campaign or have a major publicity announcement? All comments welcome in the section I linked at the start! Fram (talk) 14:04, 28 January 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]
Pokemon is number one on the List of highest-grossing media franchises, and is an extremely important for Japanese soft power political influence. GeogSage (⚔Chat?⚔) 02:08, 29 January 2026 (UTC)[reply]
Importance is relative. It's certainly ubiquitous.--3family6 (Talk to me|See what I have done) 21:19, 30 January 2026 (UTC)[reply]
I think this is fine, as something similar was done for Star Trek at Wikipedia:Did you know/Hall of Fame/Themed sets § Star Trek 50th anniversary, and that was for three consecutive sets within a 24-hour period. — Newslinger talk 08:50, 29 January 2026 (UTC)[reply]
Earlier mistakes don't justify new ones of course. Fram (talk) 11:00, 29 January 2026 (UTC)[reply]
Why is that a mistake?--3family6 (Talk to me|See what I have done) 21:20, 30 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

[edit]
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, Rosguill talk 20: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.

I'd appreciate hearing from others on how we can balance security without accepting this level of systemic bias. Huyrutan (talk) 20:26, 28 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.

Introduce maximum page size and mandatory archiving for pages intended for user communication (accessibility)

[edit]

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:

  1. Establish a minimum number of 10 threads on pages, except on user talk pages
  2. Establish a maximum size of pages (about 200 KB) and page archives (about 150 KB).
  3. 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.
  4. Require pages that will likely routinely fall afoul of the maximum size rule to introduce a short archiving interval
  5. 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
  6. Introduce an enforcement mechanism for users failing to abide by the accessibility guideline (max size)
  7. 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?

A very similar set of ideas was previously discussed at the idea lab section of the Village Pump, where I got some encouraging feedback. Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)[reply]

Changes (talk pages)

[edit]
Collapsed for clarity
Policy/guideline Before After Reason
WP:TALKSIZE 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 user can deploy an archiving bot
  • 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.

Almost 1000 user talk pages exceed 400 KB wikitext weight. There are a couple of pretty bad talk pages, too.

See also WP:CHOKING and Wikipedia:Vandalism#Illegitimate_page_lengthening. Articles have guidance on size.

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.
WP:BLANKING 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.

WP:USERSUBPAGE 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.
WP:USERTALKSTOP 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.
WP:OWNTALK 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.

Non-administrators may request this intervention at the incidents section of administrative noticeboard. Such requests must be granted if any of the above points apply.

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.

Archive tool parameters Upper archive size limit: 512 KB (wikitext) Upper page size limit: 200 KB (wikitext)

Upper archive size limit: 150 KB (wikitext)

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.

Survey (talk pages)

[edit]
  • Yes to all as proposer. Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)[reply]
  • 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. Danners430 tweaks made 15: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]
    Could you elaborate on why 1 is not good enough? Aaron Liu (talk) 17:26, 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]
    I guess I just disagree that one discussion is pretty empty. Aaron Liu (talk) 17:34, 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. --tony 16: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 all, including B because you can have a single discussion going over that limit. Just check ANI for easy samples. --SarekOfVulcan (talk) 17:04, 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]
  • Oppose. This is a disproportionate response to the basic issue of Eeng's ludicrous talk page.—S Marshall T/C 17:07, 29 January 2026 (UTC)[reply]
    Also, snow closes exist.—S Marshall T/C 17:09, 29 January 2026 (UTC)[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. —Cryptic 17: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. -- GreenC 18: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]
  • Yes to all I believe this is sorely needed for accessibility reasons, though I'm sure it will be opposed by people as too restrictive. ᴢxᴄᴠʙɴᴍ (ᴛ) 19:38, 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.
  • Thanks, Mathglot (talk) 21:06, 29 January 2026 (UTC)[reply]
    • 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]
    This is not the case I'm asking about. Nobody is saying that we accommodate Nokia 3310 users. Szmenderowiecki (talk · contribs) 23:04, 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]
    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? Why as opposed to? Por qué no los dos? Also, volunteers don't have to do anything at all, and yet they do.
    Your attitude just kicks the can down the road. And I don't have to remind you that WMF has had quite a few fumbles about their coding. In this thread, just look at the 03:31, 30 January 2026 (UTC) comment. Szmenderowiecki (talk · contribs) 11:31, 30 January 2026 (UTC)[reply]
    if you're proposing sanctions then it does make it compulsory, at least if one wants to participate Gnomingstuff (talk) 18:25, 30 January 2026 (UTC)[reply]
    Does this recommendation work? Yes.
    The subject of archiving comes up nowhere in the W3C acessibility guidelines.
    You just gave the reason yourself why this Rfc was unnecessary and a gigantic waste of time; quote:

    We already have a recommendation [about] [l]arge talk pages...

    Details in the discussion below. Mathglot (talk) 02:58, 30 January 2026 (UTC)[reply]
    Bad performance impacts accessibility and user experience. State of California, University of St Andrews. I thought this was obvious.
    The long pages talk report would at most have a few entries above let's say, a cutoff of 250 KB. It not the case. So no, the recommendation doesn't work. Szmenderowiecki (talk · contribs) 11:19, 30 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.
    You and I could think up half a dozen ways to cope with this, but a newcomer can't, and nobody should have to. WhatamIdoing (talk) 05:22, 30 January 2026 (UTC)[reply]
    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]
  • support b, good compromise between a maximum size and accessibility. ltbdl (love) 00:49, 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. Jumpytoo Talk 01: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. BD2412 T 04:52, 30 January 2026 (UTC)[reply]
  • Oppose all: WP:OWNTALK, "Oppose the creation of this unnecessary and complicated rule for a very uncommon situation that could just as easily be solved by editors using their best judgment..., and WP:BURO -- Otr500 (talk) 05:14, 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. -- LWG talk (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. — Rhododendrites talk \\ 00:53, 1 February 2026 (UTC)[reply]
  • UM WHAT? All pages with discussions limited to 10 topics? So how do you suggest Wikipedia:Administrators'_noticeboard/Incidents, Wikipedia:Village_pump_(technical), Wikipedia:In the news/Candidates, etc get handled @Szmenderowiecki:? — xaosflux Talk 00:58, 1 February 2026 (UTC)[reply]
    No, their proposal is to have all pages have a minimum of 10 topics. SuperPianoMan9167 (talk) 00:59, 1 February 2026 (UTC)[reply]
    @Xaosflux: You misread their proposal. They are proposing for all talk pages to have a minimum of ten topics at all times. (Which still doesn't make a whole lot of sense.) SuperPianoMan9167 (talk) 01:01, 1 February 2026 (UTC)[reply]
    I am flexible as to the minimum number, so long as it's not 0 Szmenderowiecki (talk · contribs) 01:11, 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). — xaosflux Talk 01: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]
    Regarding 0 threads: there appear to be more than 1.9 million user talk pages with no discussions on them. No doubt many are inactive, but not all; what happens to them if this passes? Mathglot (talk) 06:44, 1 February 2026 (UTC)[reply]
    Nothing, because this proposal discourages manual interference with the archives unless it is due to bot error. Szmenderowiecki (talk · contribs) 09:04, 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]
    See "Proposal #2" section below. sapphaline (talk) 10:23, 1 February 2026 (UTC)[reply]
  • Oppose absurd talk-page bureaucracy. —David Eppstein (talk) 18:34, 2 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

[edit]
  1. EEng is asked to archive his talk page.
  2. 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.

The end.—S Marshall T/C 20:36, 31 January 2026 (UTC)[reply]

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]
We generate an encyclopaedia collaboratively, and this facilitates collaboration by making sure users can talk to each other.—S Marshall T/C 21:03, 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]
I don't want trouble for anyone, man. I don't have a beef against EEng, but his page is a problem and he's not the only one with this problem. It would be unfair to EEng to punish him but not the others in Wikipedia:Database reports/Long pages/User talk (no subpages).
The whole point of my proposal was to avoid any banhammer deployment. Szmenderowiecki (talk · contribs) 21:03, 31 January 2026 (UTC)[reply]
Being unwilling to archive your talk page is a user-level problem and the solution is at user level.—S Marshall T/C 21:20, 31 January 2026 (UTC)[reply]
Counter-Counterproposal:
Common snipe [a]
  1. S Marshall is asked to stay on topic, avoid personalizing discussions, and stick to general principles of Wikipedia.
  2. 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)
Corollary: Mathglot to be trouted for failing to take their own advice. Mathglot (talk) 21:14, 31 January 2026 (UTC)[reply]
Bargain-Countertenor Proposal: Everybody here should go and work on some content, and give this a rest. --Tryptofish (talk) 19:48, 1 February 2026 (UTC)[reply]
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
seriously guys (Polygnotus excepted for actually doing something productive), what the fuck Gnomingstuff (talk) 02:59, 1 February 2026 (UTC)[reply]
Let's agree that it should have been hatted, because it sure ain't making Wikipedia great again. --Tryptofish (talk) 19:31, 1 February 2026 (UTC)[reply]
But that snipe sure does have a big beautiful bill! --Tryptofish (talk) 19:45, 1 February 2026 (UTC)[reply]
  • 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. — Rhododendrites talk \\ 23:12, 31 January 2026 (UTC)[reply]
    Hard cases make bad law. Polygnotus (talk) 23:37, 31 January 2026 (UTC)[reply]
  • I tried to WP:BOLDLY hat this discussion, but of course I'm involved, and S Marshall reverted it. I still think this section is counterproductive. --Tryptofish (talk) 23:32, 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 Marshall T/C 23: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 Marshall T/C 23: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 Marshall T/C 23: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 Marshall T/C 23: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 Marshall T/C 23: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 Marshall T/C 09:52, 1 February 2026 (UTC)[reply]
    @S Marshall I think you mean It's not about EEng personally. Polygnotus (talk) 00:11, 1 February 2026 (UTC)[reply]
    I did mean that my proposals are about EEng personally. I didn't misspeak in that respect.—S Marshall T/C 00:13, 1 February 2026 (UTC)[reply]
    Oh, then I misunderstood, sorry. Polygnotus (talk) 01:03, 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]

Discussion (talk pages)

[edit]

Pinging all participants of the deletion review that precipitated the discussion, the idea lab thread and the talk page guideline thread. I have reason to believe that these participants will be likely interested in this discussion. Pings: @Voorts, OwenX, GreenLipstickLesbian, SuperPianoMan9167, Katzrockso, Tryptofish, SmokeyJoe, Bradv, XtraJovial, Jumpytoo, EEng, SportingFlyer, ~2025-43151-08, Sugar Tax, Cryptic, Jclemens, S Marshall, Spartaz, LakesideMiners, Alalch E., Skynxnex, Schazjmd, WhatamIdoing, ActivelyDisinterested, Aaron Liu, Gnomingstuff, Anomie, ~2025-31733-18, Ritchie333, Mathglot, CapnZapp, Rolluik, Zxcvbnm, Locke Cole, Guy Macon, Vanamonde93, Cremastra, Rchard2scout, Polygnotus, JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, and ~2025-35132-06: @JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, ~2025-35132-06Swordman97, Rutebega, SunDawn, Stifle, Toadspike, Andrew Davidson, Alpha3031, Chipmunkdavis, Coining, Otr500, Andrybak, Andrew Gray, and Wbm1058: Szmenderowiecki (talk · contribs) 14:29, 29 January 2026 (UTC)[reply]

@Szmenderowiecki I didn't receive a ping from this that I can tell. I believe it is because you included more than 50 and possibly since the edit that had these had multiple sections (WP:MENTION). Skynxnex (talk) 16:06, 29 January 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]
They can contain more than one, but if they do, nobody will receive the ping. FaviFake (talk) 16:27, 29 January 2026 (UTC)[reply]
Please stop pinging large groups of people. Thanks. Polygnotus (talk) 16:29, 29 January 2026 (UTC)[reply]
Why? I appreaciated the ping FaviFake (talk) 16:32, 29 January 2026 (UTC)[reply]
@FaviFake Because pinging large amount of people to bad RfCs is a waste of valuable volunteer time. Polygnotus (talk) 16:34, 29 January 2026 (UTC)[reply]
I agree. However, that's not what Szmenderowiecki has done. This RfC looks fine. FaviFake (talk) 16:36, 29 January 2026 (UTC)[reply]
Resending first batch @Voorts, OwenX, GreenLipstickLesbian, SuperPianoMan9167, Katzrockso, Tryptofish, SmokeyJoe, Bradv, XtraJovial, Jumpytoo, EEng, SportingFlyer, ~2025-43151-08, Sugar Tax, Cryptic, Jclemens, S Marshall, Spartaz, LakesideMiners, Alalch E., Skynxnex, Schazjmd, WhatamIdoing, ActivelyDisinterested, Aaron Liu, Gnomingstuff, Anomie, ~2025-31733-18, Ritchie333, Mathglot, CapnZapp, Rolluik, Zxcvbnm, Locke Cole, Guy Macon, Vanamonde93, Cremastra, Rchard2scout, and Polygnotus: Szmenderowiecki (talk · contribs) 16:20, 29 January 2026 (UTC)[reply]
And second batch @JoJo Anthrax, Ltbdl, Odysseus1479, LaundryPizza03, Andrew Gray, GreenC, Levivich, SnowFire, FaviFake, Blueboar, ~2025-35132-06, Swordman97, Rutebega, SunDawn, Stifle, Toadspike, Andrew Davidson, Alpha3031, Chipmunkdavis, Coining, Otr500, Andrybak, Andrew Gray, and Wbm1058: Szmenderowiecki (talk · contribs) 16:20, 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]
@Szmenderowiecki
This is just a bad RfC in 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 ago addressed in the table. Maybe, but this is still a problem.
which is probably why people don't respond to it We 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]
This might sound a bit too aggressive. Aaron Liu (talk) 17:32, 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]
also WP:RFC specifically states "neutral and brief", this is neither. Polygnotus (talk) 16:46, 29 January 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]
@Szmenderowiecki you 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]
RfC asks for the question to be neutral and brief. This is easy to fix; we would move the neutral and brief "Do you support these changes as presented in the table below? If not, which specific parts of the changes do you not like?" to the top. From time to time, RfCs include background information. See for example Wikipedia talk:Please do not bite the newcomers#RfC: Rewriting specific sections. Aaron Liu (talk) 17:31, 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]
This proposal has not been up for a month, you just started it today, hours ago. I have no idea what proposal was up for a month on a high-traffic page, but it's not this proposal. – wbm1058 (talk) 17:43, 29 January 2026 (UTC)[reply]
I agree that one ping is a non-issue. But wbm and Polygno are right to recommend reducing the number of options/changes an RfC proposes (see also Wikipedia:Writing requests for comment#Best practices). You definitely can do that if you think it's best, but if so, you should expect the possibility that most of the parts would be met with chaos, confusion, messy discussion, and disgrunt, especially if you didn't hash them out first: Half of your proposals were not put forward at your Idea Lab thread, especially the change from recommendation to enforced rule. Aaron Liu (talk) 17:44, 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 (talk · contribs) 10:36, 30 January 2026 (UTC)[reply]
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]
    Try c:User:Jack who built the house/Convenient Discussions.
    Both moving topics and automatic retrying after edit conflict sure included. Aaron Liu (talk) 17:47, 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]
    sounds like they should hire some engineers then, I hear there are a lot of people looking for work Gnomingstuff (talk) 20:04, 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]
    There's no need for a Phab ticket. Go to Special:Preferences#mw-prefsection-betafeatures and turn on "DiscussionTools". Go to Special:Preferences#mw-prefsection-editing-discussion and make sure that "Show discussion activity" is enabled.
    If we want this enabled by default, then an RFC and a config change request would be enough. WhatamIdoing (talk) 20:02, 31 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.
I'm against all the points. LakesideMinersCome Talk To Me! 21:18, 29 January 2026 (UTC)[reply]
@Szmenderowiecki, what's your plan for handling individual discussions that exceed 200K? For example, Wikipedia:Requests for comment/Rollback of Vector 2022 is 910K. Wikipedia:Requests for comment/Merging merge discussions with AfD is a currently active RFC that is over 230K so far. WhatamIdoing (talk) 22:06, 29 January 2026 (UTC)[reply]
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]
So firm rules, except for exceptions. WhatamIdoing (talk) 22:47, 29 January 2026 (UTC)[reply]
IMHO better than no rules at all. Making a carveout where necessary is a sacrifice I'm willing to make. Szmenderowiecki (talk · contribs) 22:49, 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]
Also, the difference is that libel can get you sued and long talk pages can't. Gnomingstuff (talk) 04:01, 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+.
  • We don't know what the "other pages" are.
  • 30 seconds to be able to interact with a page element is absolutely unacceptable performance. Anything over 4 s of basic rendering (LCP) and 500 ms of response between click and action (INP) is poor performance on Chromium-based browsers. That user may put up with it but there's a reason Google says it's poor performance. If I were a random user I would have never tried to interact with that page again. This is a problem.
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.
Szmenderowiecki (talk · contribs) 07:56, 31 January 2026 (UTC)[reply]
@Szmenderowiecki
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.
  1. Find a page on which the problem is reproducible (ANI?)
  2. Visit that page in an incognito (sic) window, without logging in. Does the problem still occur?
  3. In a non-incognito window: disable your scripts and DiscussionTools in preferences, then try again. Does the problem still occur?
  4. Enable your scripts and DiscussionTools again and capture a performance profile (not the HAR file) and post a link.
Polygnotus (talk) 11:41, 31 January 2026 (UTC)[reply]
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 reading User 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 ms
with 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]
@Szmenderowiecki DOMs 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]
Since talk page size and number of DOM elements is strongly correlated, then reducing talk page size would actually solve these problems. WhatamIdoing (talk) 20:11, 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]
Just confirming that I have seen these pings and am passing along the request for technical investigation - [EDIT: Done at phab:T416247.] Quiddity (WMF) (talk) 20:04, 2 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. -- LWG talk (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. -- LWG talk (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. -- LWG talk (VOPOV) 18:57, 1 February 2026 (UTC)[reply]

LONG PAGES

At Wikipedia:Database reports/Long pages/User talk (no_subpages) I see a bunch of users who were indefed long ago and are obviously never coming back. Would anyone object if I or someone else set up archiving on those pages? --Guy Macon (talk) 02:17, 1 February 2026 (UTC)[reply]

Yup, because that is a database report, not a backlog. Anyway that stuff is always outdated; if you run Quarry 100159 you get fresh data. Polygnotus (talk) 02:21, 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

[edit]

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]

What shall we do?

A – request closure
B – let it run
C – something else (specify)

Your choice? Mathglot (talk) 03:49, 1 February 2026 (UTC)[reply]

C Take it behind the barn, close it out right, this has been a drain. LakesideMinersCome Talk To Me! 00:46, 3 February 2026 (UTC)[reply]

Proposal #2

[edit]

I propose the following change to Wikipedia:Talk_page_guidelines#Archiving:

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 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.

sapphaline (talk) 10:22, 1 February 2026 (UTC)[reply]

Interesting idea. Among concerns:
  • 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.
Szmenderowiecki (talk · contribs) 10:36, 1 February 2026 (UTC)[reply]
"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 textNew 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.
sapphaline (talk) 10:54, 1 February 2026 (UTC)[reply]
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.
The reason I'm asking all these questions is to test the proposal against wikilawyering. Szmenderowiecki (talk · contribs) 11:27, 1 February 2026 (UTC)[reply]
  • 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]
You don't need user talk pages to collaborate. We have article talk pages for collaboration. Levivich (talk) 14:41, 1 February 2026 (UTC)[reply]
Article talk pages are here solely for content dicussions. sapphaline (talk) 14:43, 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]
"You don't need to talk to people on their user talk pages in order to collaborate with them" - yes, you need. Conduct issues exist. sapphaline (talk) 14:51, 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.)[Citation Needed]
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]

Reasons and ways to end RfCs

[edit]

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

[edit]

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]
Just like AfDs, it just goes into a long list https://en.wikipedia.org/wiki/Category:Wikipedia_conflict_of_interest_edit_requests
Anyone can pick any item for any reason. Graywalls (talk) 19:06, 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]
By "within rules" I meant by declaring their paid editing and making neutral edit requests per the TOS. voorts (talk/contributions) 01:16, 3 February 2026 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(policy)&oldid=1336350233"