Wikipedia:Village pump (policy)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

"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 7 days of inactivity. To keep this page's size accessible, discussions with more than about 100 comments should be split to a separate page.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Recent changes to WP:LLM are too restrictive and actively harm some parts of Wikipedia

Moved to Wikipedia:Village pump (policy)/Recent changes to WP:LLM are too restrictive and actively harm some parts of Wikipedia

 – Page size issues on VPP. Anomie⚔ 23:40, 23 July 2026 (UTC)

Current status of translation tools considered harmful.

Moved from Wikipedia:Administrators' noticeboard § Current status of translation tools considered harmful.

 – voorts (talk/contributions) 21:46, 2 July 2026 (UTC)

First: I DO understand there are reasons Why_machine_translation_is_disabled_in_content_translation. That making it too easy to make crappy LLM-assisted translations is bad. But the current situation is making proper LLM-assisted translation unnecessarily way more difficult than it should be. With the LLM features disabled, the Wikipedia:Content translation tool is worse than useless. It's user-hostile. Felt this strongly at step 7-8 below, and also when citations wouldn't copy over (at step 4-6, below).

Proposal: Wikipedia:Content_translation_tool (uncrippled) should be available. On a limited basis, i.e. one-translation-to-draft-space-at-at-a-time-per-editor-with-1000+-edits.

If rehabilitating the tools is mostly opposed, the tool should be disabled/deprecated.

Post mortem:

1. I noticed a redlink to Stalinon in List of withdrawn drugs. I noticed there was a french version of the page. I decided to translate it.
2. I'm skilled in both the origin and target languages.
3. So, I started with a machine translation from page on French 'pedia I would refine to proper English, adding a {{under construction}} with an explanation.
4. I thought the citations copied over, and it looked like they would, but after saving, noticed they didn't, at all. Ugh.
5. I scratch my head, wondering: "Glitch or are would-be translators being actively prevented from starting with a machine translation?" If intentional, it makes me want to abandon the effort. Is it?
6. I decide that if the references (which I see will need fixing/refinement) can be moved over, I want to proceed. But I don't see how. I don't understand why they didn't make it.
7. I tried to restart, using what Wikipedia:Translation led me to - Wikipedia:Content_translation_tool, assuming it would be helpful, but it's been crippled. With the LLM translation features disabled, the Wikipedia:Content translation tool is worse than useless. It's user-hostile. I see there's a CS1 translator module but I guess it's broken? Crippled? It's stated "all you need to do is copy the citation from the source and paste it into the en-wiki article, preview, fix any errors, and publish " - by this it's meant it has to be done citation by citation? Why? Seems like intentional discouragement - a violation of WP:bite.
8. Very unpleasant feeling. Feeling bitten by editor-hostile documentation/process. I notice I better draftify the page, which I do.

Seems clear to me that blocking the LLM tool for ALL users violates our core principles. e.g. "As always, assume good faith." (WP:DNB guideline and WP:AGF).

I don't think the Wikipedia:Content_translation_tool should remain crippled (I guess I'm proposing revisiting that question I see was decided in 2016). How 'bout we make it available, say on a one-translation-to-draft-space-at-at-a-time-per-editor basis, ? If it is to be kept intentionally crippled (the LLM translation features are to remain disabled) then at least it should be disabled/deprecated so would-be translators don't have to find out the hard way they are being actively prevented from starting with a machine translation?

Support - as proposer. If I hadn't run into all these hurdles, I wouldn't be pissed off and would have finished the translation by now. -- RememberOrwell (talk) 01:39, 2 July 2026 (UTC)

Estimates are that, before machine translation was turned off, 95% of articles created with this tool were unacceptable without significant additional work. That's a very worrying figure, is there any evidence that this has changed over time? If we've only got a 5% usability rate then I really don't think it should be turned back on.

BTW AGF and DNB wouldn't apply to this situation, they're both behavioural guidelines describing the way that one editor should treat another editor. It doesn't mean that we presume editors can use certain tools competently (I think that's what you mean here?) In solidarity, Blue-Sonnet (I'm listening) 03:11, 2 July 2026 (UTC)

The source for this seems to be one user's informal experiment from 2016. Given the very rapid improvement of machine translation over this period, I don't think it's fair to assume we'll necessarily see the same issues. (We may see new ones, if the machine translation now incorporates LLMs that hallucinate instead of just making stupid decisions about idioms and so on). Rusalkii (talk) 15:54, 3 July 2026 (UTC)

Yes, we are seeing new ones. Gnomingstuff (talk) 17:04, 3 July 2026 (UTC)

No articles have been created with an (uncrippled) Wikipedia:Content_translation_tool in years. No?

Re. new ones: OKA "was mostly relying on cheap labor from contractors in the Global South". Relevance?

Also, what was the justification for moving this from where I posted it, and

What was the justification for not notifying me of the move? And Voorts , why exactly didn't it belong at AN? That's where previous discussions on this topic took place. RememberOrwell (talk) 17:47, 3 July 2026 (UTC)

AN is for discussing issues needing administrative attention. I don't know why these past conversations occurred at AN. As for notification, there's literally a link at AN to this thread and moving a discussion doesn't unsubscribe you from it. voorts (talk/contributions) 17:56, 3 July 2026 (UTC)

I was following precedent. Don't see why this isn't an issue needing administrative attention, now, even though discussion of the same issue was appropriate for there in 2016. OK. It seems my alerts/notifications glitched or I missed 'em-I'm getting them now but didn't see any initially. RememberOrwell (talk) 18:09, 3 July 2026 (UTC)

Linking for historical interest WP:AN/CXT. There are still very substantial numbers of unreviewed translations from that era, about which nothing is being done or will ever be done, because the community has made conflicting decisions on this. The speedy deletion criterion has been retired and the speedy draftification process withdrawn. The number of editors willing to follow the current process for dealing with them is exactly zero.

Is it feasible to make access to the AI-assisted content translation tool a granted user-right? I have no idea whether that could work.—S Marshall T/C 08:36, 2 July 2026 (UTC)

Shouldn't this be at WP:Village pump (proposals) rather than AN? -- LCU ActivelyDisinterested «@» °∆t° 10:17, 2 July 2026 (UTC)

I wondered that myself, I think it's because the original 2016 discussions took place at AN? In solidarity, Blue-Sonnet (I'm listening) 10:59, 2 July 2026 (UTC)

Editors can (and do) make bad machine translations in good faith. Taking steps to prevent this is not assuming bad faith since the behavior is not innately bad faith.

It's unclear how equally preventing ALL users from accessing a feature to prevent potential misuse is covered by Wikipedia:Please do not bite the newcomers. fifteen thousand two hundred twenty four (talk) 07:24, 3 July 2026 (UTC)

Intentional hurdles that prevent good machine translations done in good faith is assuming bad faith. Unless 'assuming bad faith' is understood poorly. RememberOrwell (talk) 07:23, 13 July 2026 (UTC)

The content translation tool was somewhat deprecated long before llms became involved, so the reasons were not "making it too easy to make crappy LLM-assisted translations is bad". Given that, I'm not following the framing that disabling llm tools is crippling the tool, or even the particular relevance of llms to this. The use of the machine translation tool is, as you felt, intentionally discouraged, and again this was long before llms became available. That aside, problems with the features of the tool are not under the control of the en.wiki community, as it is maintained by the WMF (mw:Content translation). CMD (talk) 08:41, 3 July 2026 (UTC)

The content translation tool was never deprecated at all. It's only the machine translation module inside it that was disliked, and it was largely disliked because it was accidentally enabled with no warning, and one person made a huge number of bad translations before we figured out what the problem was and stopped it.

The content translation tool itself solves two problems for us, namely getting the source of the translated article properly linked in the edit summary, and getting the article automatically linked in Wikidata. WhatamIdoing (talk) 01:14, 12 July 2026 (UTC)

Do you not understand a particular part of "I see there's a CS1 translator module but I guess it's broken? Crippled? It's stated "all you need to do is copy the citation from the source and paste it into the en-wiki article, preview, fix any errors, and publish " - by this it's meant it has to be done citation by citation? Why*? Seems like intentional discouragement - a violation of WP:bite." ? Your claim about framing isn't reflective of someone who understood that. The Wikipedia:Content_translation_tool - apparently better known as the "CXT tool" or "CT tool" (?) has been crippled. Disabling machine translation tools (including llm tools) the CXT tool generally relies on is crippling the CXT tool. Whether folks acknowledge seeing it or not.

• Are you blaming that on the WMF?

Like the questionable, aggressive removals of my requests at https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#Current_status_of_translation_tools_considered_harmful. which leave me once-again feeling bitten by editor-hostile documentation/process.

Feels like the refusal to see that "As always, assume good faith." (which is policy) is not compatible with what is happening - - the blocking of access to the tool to anyone translating to English!

In other words, insisting my perceptions aren't valid feels like gaslighting. With tortured linguistic semantic claims. RememberOrwell (talk) 07:00, 13 July 2026 (UTC)

Not sure how you're reading gaslighting. Your perception, that there was discouragement, was correct. CMD (talk) 07:07, 13 July 2026 (UTC)

LOL. You're telling me what my perception is, and implying that when I tell you what my perception is, I'm wrong.

OMG. RememberOrwell (talk) 08:03, 13 July 2026 (UTC)

As someone who occasionally uses our Content Translation tool (translating from English) and patrols edits by others who do the same, I have to say that the Google translation service it uses has improved immensely over the last couple of years. Rather than pushing people toward general-purpose LLMs (which we cannot prevent), we should encourage them to use our in-house tool, with its two-column translation interface, instant preview, category editing, reference transfer, and other wiki-specific features. It also flags edits with too much unmodified machine-translated text and requires the user to confirm before publishing them. And yes, restrict machine translation to, say, extendedconfirmed users. The tool feels a bit abandoned, probably because WMF tends to respond best to pressure from this wiki—and there hasn't been much. Ponor (talk) 17:38, 3 July 2026 (UTC)

@Ponor When I try to use the in-house tool, I find no translation tool. What is this Google translation service it uses that you speak of? When I tried to use it, no translation occurred.

https://en.wikipedia.org/wiki/Special:ContentTranslation?from=fr&to=en&targettitle=Stalinon&page=Stalinon is where I tried to use it. Each time I clicked translate, it just copied the French over.

@Fifteen thousand two hundred twenty four: Umm... equally preventing ALL users from accessing a feature to prevent potential misuse is assuming bad faith of ALL users . RememberOrwell (talk) 17:58, 3 July 2026 (UTC)

That's what this req. for comments is about. There's this note on top of the tool on this wiki: »On the English Wikipedia this tool is limited to extended confirmed editors, and the machine translation component is disabled for all users«. See if this one works, @RememberOrwell: CT Croatian to French Ponor (talk) 18:05, 3 July 2026 (UTC)

Ah, so it ( machine translation component ) is only disabled for translation to English? Yes, I see https://it.wikipedia.org/w/index.php?title=Speciale:TraduzioneContenuti&from=fr&page=Stalinon&to=it works. (the link you provided did not work for me - for other reasons - "Il y a une traduction en cours par Ponor. ..."). RememberOrwell (talk) 18:29, 3 July 2026 (UTC)

Yes. On other wikis, the machine translation works as intended. I have used CXT for all of my translations, as I find it saves me more time than it spends, but it's very broken. Even if the initial machine translation bit worked, all the rest of your issues still would happen. In solidarity, asilvering (talk) 01:14, 4 July 2026 (UTC)

Please read my entire comment before pinging me, thank you. fifteen thousand two hundred twenty four (talk) 04:03, 4 July 2026 (UTC)

@RememberOrwell So we should make all editors administrators since denying non-admins access to the admin tools is assuming bad faith? --Ahecht (TALK
PAGE) 21:13, 14 July 2026 (UTC)

It seems the LLM tools have come a long way and https://meta.wikimedia.org/wiki/Community_Wishlist/W55 our policies haven't.

Is it a mod or admin who has intentionally made it difficult for someone, e.g. me, to, e.g. translate Stalinon from French to English. In any case, it's based on an assumption of bad faith that the system was changed to prevent ALL users from accessing a feature to prevent potential misuse.

Wondering if trying dphilipov/wiki-translate (https://github.com/dphilipov/wiki-translate) will help.

Hereby requesting access to the tool that's been disabled. RememberOrwell (talk) 19:51, 4 July 2026 (UTC)

Hello? RememberOrwell (talk) 06:37, 7 July 2026 (UTC)

What is happening technically that breaks (disappears) all the citations? Workarounds other than a manual process that seems more laborious than the creation of the original citations in the first place? RememberOrwell (talk) 06:41, 7 July 2026 (UTC)

Can you explain what you're seeing? WP:CX is intended to preserve citations. WhatamIdoing (talk) 01:16, 12 July 2026 (UTC)

Do you not understand a particular part of "I see there's a CS1 translator module but I guess it's broken? Crippled? It's stated "all you need to do is copy the citation from the source and paste it into the en-wiki article, preview, fix any errors, and publish " - by this it's meant it has to be done citation by citation? Why*? Seems like intentional discouragement - a violation of WP:bite." ? Do I need to be more specific?

I also wrote,"I thought the citations copied over, and it looked like they would, but after saving, noticed they didn't, at all. Ugh." Do I need to be more specific?

I identified the issue was when I tried to translate Stalinon from French to English. You can see the French version and you can see my work at Draft:Stalinon and Stalinon. Do I need to be more specific? Than the contributor note there? RememberOrwell (talk) 07:08, 13 July 2026 (UTC)

In other words, I'm asking: What is happening technically that breaks (disappears) all the citations, when I follow the 8 steps detailed in the OP? RememberOrwell (talk) 08:10, 13 July 2026 (UTC)

Yes, @RememberOrwell, I need you to be more specific. For example: you say "I started with a machine translation", but what exactly did you do? Which website or tool did you use? Did you copy/paste wikitext code into it, or did you copy/paste the whole URL in, or what? WhatamIdoing (talk) 19:29, 13 July 2026 (UTC)

You claim there's a workaround other than a manual process that seems more laborious than the creation of the original citations in the first place. I need you to document it if it exists. RememberOrwell (talk) 01:15, 14 July 2026 (UTC)

@RememberOrwell, please provide a link to that alleged claim. I'm not sure what workarounds are functional these days, and I don't remember saying anything about one.

What I'm offering here is my help to figure out what went wrong when you used machine translation on that article. I can't do that when you won't tell me what you actually did. "I started with a machine translation" isn't enough information to figure out how you ended up with empty ref tags. Something like "I opened the article in the visual editor, selected a paragraph, and used the ExampleTranslation Plug-In to translate it" might be. WhatamIdoing (talk) 01:37, 14 July 2026 (UTC)

"all you need to do is copy the citation from the source and paste it into the en-wiki article, preview, fix any errors, and publish " - I say this doesn't work. I read "WP:CX is intended to preserve citations." as implying it does. edit of revision where I tried. I say this shows it doesn't work. That was all the citations from the source. Fixing the errors seems un- do-able. Past 1st cite, errors are gibberish. Hidden comment (to save space) showing what I see: (see source) RememberOrwell (talk) 03:29, 14 July 2026 (UTC)

You weren't using WP:CX in that edit. Software that you're not using isn't going to do anything for you. WhatamIdoing (talk) 03:51, 14 July 2026 (UTC)

So you bringing it up just derailed the conversation. RememberOrwell (talk) 03:55, 14 July 2026 (UTC)

I have finally tracked down this "all you need to do" line to its origin in Wikipedia:Translation#Citation templates, and clarified that if you want the citation template to be auto-translated on this wiki, then you have to actually copy the wikitext for the citation (the bits beginning <ref>{{Ouvrage|prénom1=Corinne..., not the little blue clicky number in the reader view or the visual editor). WhatamIdoing (talk) 04:15, 14 July 2026 (UTC)

"all you need to do is copy the citation (i.e., the full wikitext code for the template, not the little blue clicky number itself) from the source article and paste it into the en-wiki article, preview, fix any errors, and publish." would be good advice if it worked when a bunch of citations are copied. But as my earlier comment below noted - https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)#c-RememberOrwell-20260714034900-WhatamIdoing-20260714013700 - it doesn't. You seem to have incorrectly assumed that https://en.wikipedia.org/w/index.php?title=Draft:Stalinon&oldid=1362101946 was made using an external website, without looking at it. It wasn't. I did take the full wikitext code for the templates and paste 'em into the en-wiki article. Got hot garbage.

I urge you to accept that I'm not wanting help using a severely crippled tool. I'm wanting a tool that isn't severely crippled. RememberOrwell (talk) 04:51, 14 July 2026 (UTC)

Okay, let me ask this a different way:

• The French original contains this wikitext code:
  • Le Stalinon est conçu au début des années 1950 comme traitement contre la [[furonculose]]. La Stannomaltine, une spécialité pharmaceutique à base d'étain et d'oxyde d'étain<ref name=":2">{{Article|langue=|auteur1=Bonah Christian|auteur2=Gaudillière Jean-Paul|titre=Faute, accident ou risque iatrogène ? La régulation des événements indésirables du médicament à l'aune des affaires Stalinon et Distilbène|périodique=Revue française des affaires sociales|date=2007|issn=|lire en ligne=https://www.cairn.info/revue-francaise-des-affaires-sociales-2007-3.htm-page-123.htm|pages=123-151}}</ref>
• The English draft contains this wikitext code:
  • Stalinon was designed in the early 1950s as a treatment for furunculosis. Stannomaltine, a pharmaceutical specialty based on tin and tin oxide<ref name=":2" />

If you actually copied the full wikitext code for the ref and the citation template from the French source article and pasted it into the English draft, then why does the English draft not contain the wikitext code? It only says <ref name=":2" /> without any of the {{Article|langue=|auteur1=Bonah Christian... bits. This is what I would expect to see if you copy/pasted the little blue clicky number instead of the wikitext code. WhatamIdoing (talk) 21:33, 14 July 2026 (UTC)

Umm...

The English draft I linked to contains this wikitext code:

<ref name=":2">{{Article|langue=|auteur1=Bonah Christian|auteur2=Gaudillière Jean-Paul|titre=Faute, accident ou risque iatrogène ? ....|pages=123-151}}</ref>

I don't know why you didn't use the link I provided and specifically directed you to, just above, but if you had, you'd see that code there. But doesn't matter.

What matters is whether you can show us a way to use a tool that isn't severely crippled, or just show us that you can. With steps or a screen recording. If so, great, but I don't think you can -- because such a tool isn't available. RememberOrwell (talk) 04:46, 22 July 2026 (UTC)

In this comment, you directed me to this version of the English draft. That version, which was created in the visual editor, does not contain the wikitext code for the Bonah source. Have a look at the wikitext code for that version yourself.

If the visual editor is randomly deleting sources that you actually put into an article, that really does matter, and for more purposes than translation. WhatamIdoing (talk) 16:33, 22 July 2026 (UTC)

Nope. You keep on with this derailing question: "why does the English draft not contain the wikitext code?" I don't care if it does (or not). This is all more derailing. And it snubs : What matters is whether you can show us a way to use a tool that isn't severely crippled, or just show us that you can. With steps or a screen recording. If so, great, but I don't think you can -- because such a tool isn't available. What I'm wanting isn't what you're offering. What I'm wanting is help to (figure out how to) use machine translation on articles (e.g. Stalinon) in a way that is not less efficient than using the tool if it wasn't crippled would be. I see no need for what you're offering. RememberOrwell (talk) 06:59, 27 July 2026 (UTC)

Okay, it sounds like you really, really, really don't care if refs are randomly being deleted from your articles.

Just so you know, if someone complains that your articles are unsourced, or if someone else gets bitten by this bug, I'm going to tell them that the reason the possible bug wasn't identified and fixed already is because you insisted that randomly removing refs from articles is unimportant. WhatamIdoing (talk) 20:27, 27 July 2026 (UTC)

Big picture: This is just more derailing. What I'm wanting isn't what you're offering. What I'm wanting is help to (figure out how to) use machine translation on articles (e.g. Stalinon) in a way that is not less efficient than using the tool if it wasn't crippled would be. I see no need for what you're offering. RememberOrwell (talk) 05:06, 22 July 2026 (UTC)

It looks like what you ran into is that we can't automatically translate fr:Modèle:Article like we can fr:Modèle:Ouvrage because "Article" is also an English word and Template:Article is used for a different purpose so it's not available for citation auto-translation. For that particular template, you'd need to change the citations to use Template:Cite journal/French or Template:Cite news/French (it's not clear to me which is correct; both claim to correspond). Anomie⚔ 11:24, 14 July 2026 (UTC)

In an early edit comment, I wrote, "If the references (which I see will need fixing) can be moved over, I want to proceed." I don't see how figuring out what went wrong when I used machine translation on that article is going to help when the admins comments and actions indicate they're dead set on intentionally not fixing the problem and shutting down discussion of doing so. No point proceeding. You say I won't tell you what I actually did. Let's say https://en.wikipedia.org/w/index.php?title=Draft:Stalinon&oldid=1362101946 was, to the best of my recollection, the result of "I opened the article in the visual editor, selected the whole article, and used an AI I don't recall to translate it" and pasted the translation, commented " Machine translation from page on french 'pedia I'm about to refine to proper English" and saved. Seems I'm telling you what you already knew. So what's the point? RememberOrwell (talk) 03:49, 14 July 2026 (UTC)

Wikipedia's templates (all of them) are local to each wiki. External websites (e.g., DeepL Translator, chatbots, Google Translate) have no idea what to do with them. You're lucky that it even maintained the HTML description, which is why you got back a little blue clicky number instead of plain old text in the form of [1].

If you'd been using WP:CX, you'd get these benefits:

• Most links would be linked to the correct article at the new language's Wikipedia. For example, in the first sentence of the French article has a link to w:fr:Staphylococcus, and it would have correctly linked to the English Wikipedia's Staphylococcus article.
• Most templates, including all the main CS1-style templates, would not just exist, but 'translate' the parameters. The French Wikipedia's {{Ouvrage|prénom1=Corinne... would become the English Wikipedia's {{Cite book|first=Corinne... with a simple click.
• Formatting is preserved. Some machine translation websites can do most of it, especially if you copy/paste from the visual editor instead of from the ordinary reader's view; however, CX can do almost 100% of it.

What you can't get in CX at this particular wiki is built-in machine translation. I think the community should change that, but in the meantime, have you considered to combining CX's features with copy/pasting each section at a time to your favorite machine translation tool? Given a paragraph of "blah blah blah blah", you could click on the original (full text of the paragraph, plus links and templates), then copy just the "blah blah blah blah" part (leaving the 'translated' citation in place), run it through machine translation, and paste the results in just before the little blue clicky number. It's a bit slower, but you would get your refs.

You could even start the page with just the formatted refs and no other content, and then fill the paragraphs back in. WhatamIdoing (talk) 04:09, 14 July 2026 (UTC)

"What you can't get in CX at this particular wiki is built-in machine translation. I think the community should change that". Glad to hear that.

I urge you to accept that I'm not wanting help using a severely crippled tool. I'm wanting a tool that isn't severely crippled. And disgusted at the prospect of further - and by my actual attempts at - use of one that is. " It's a bit slower" - not seeing that. As I said, with the LLM translation features disabled, the Wikipedia:Content translation tool is worse than useless. It's user-hostile. I'm already many wasted hours behind and many other editors are countless more hours behind because of this ongoing crippling of the tool, IMO. "You could even start the page with just the formatted refs and no other content, and then fill the paragraphs back in" - not seeing that either - and if it did sort of "work", not seeing it as anything but user-hostile.

It feels important to reiterate: I offered two options, one of this was If rehabilitating the tools is mostly opposed, the tool should be disabled/deprecated. It's disturbing to see it ignored.

Admins, by ignoring even that option, are showing they don't value and are happy to squander editor time and intentionally frustrate editors en masse. I don't agree with, but can respect those arguing against going with the other option, which at least can be defended by arguing that it's better to block machine translation edits than improve upon them. Those (not you) arguing that it's OK to squander editor time and intentionally frustrate editors en masse with an 'it's not a WP:AGF violation' argument ... I don't have the words... RememberOrwell (talk) 05:17, 14 July 2026 (UTC)

To add to WhatamIdoing‘s comment, if the “Copy original content” option is used and the text is manually translated without removing the citation, the citation should copy over, provided the reference template exists in both languages. We’d be happy to enable machine translations, but it’s a community decision. The Wishlist mentioned in the conversion is being reviewed, and this ticket has been created. UOzurumba (WMF) (talk) 14:41, 14 July 2026 (UTC)

@UOzurumba (WMF), I think the question is "could machine translation be enabled for specific editors" (a technical question), not "could machine translation be enabled at all" (as you note, a community one). In solidarity, asilvering (talk) 15:26, 14 July 2026 (UTC)

Machine translation can theoretically be enabled for specific editors. It might require a bit of technical work, but I believe it would be small. However, whether to allow such a thing to happen is a community decision. WhatamIdoing (talk) 21:37, 14 July 2026 (UTC)

@Asilvering, enabling machine translation for specific editors would require further development or technical work. We currently have a per-wiki configuration option. As WhatamIdoing said, if there is consensus to allow it, the Language and Product Localization team can consider doing the technical work. UOzurumba (WMF) (talk) 18:47, 15 July 2026 (UTC)

Umm, how can that be true? I said earlier, "Access to the whole tool is already restricted to certain groups." In particular, per https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/CXT#c-Xaosflux-2016-07-31T04:27:00.000Z-Lower/Change_the_5000-Edit_Bar? (already linked to earlier in this discussion) was closed by xaosflux it was restricted to the extendedconfirmed group. I presume it still is, so if machine translation was enabled today, which would require no "further development or technical work", it would re-enable machine translation, but only for everyone with extendedconfirmed. If it was then restricted to admins, it would be available to just that group of editors. If I'm wrong, where is the error in this? RememberOrwell (talk) 03:58, 22 July 2026 (UTC)

Hello? RememberOrwell (talk) 04:58, 27 July 2026 (UTC)

Last I heard, restricting access to the whole tool was done via Special:AbuseFilter, by preventing people from saving finished translated pages into the mainspace. That method cannot be used to restrict access to buttons inside the CX tool.

If we wanted to have a system in which:

• Wikipedia:Extended confirmed editors can use the CX tool without machine translation, and
• a new user right – maybe we call it "authorized machine translation user" – meant that some editors could use the CX tool with machine translation

then that new user right has to be created, and the CX tool has to be adjusted to pay attention to it internally. WhatamIdoing (talk) 20:18, 27 July 2026 (UTC)

I don't think there is any way to grant individual contributors access to the machine-translation aspect of the tool. In solidarity, asilvering (talk) 14:28, 7 July 2026 (UTC)

I'm quite sure there's a way. Access to the whole tool is already restricted to certain groups. Copyable code, surely would get the job done, if nothing simpler. How was it taken away, exactly? RememberOrwell (talk) 07:16, 13 July 2026 (UTC)

I believe the initial approach was an WP:ABUSEFILTER that refused to save translated pages in the mainspace. I believe that the configuration has changed since then. WhatamIdoing (talk) 04:19, 14 July 2026 (UTC)

The current status of the translation tools is harmful. The process is terrible, as my experience and the discussion thereof shows. Who is interested in improving it? Bold enough not to bury their head in the sand? to make or find and document or de-cripple the tool(s) available? RememberOrwell (talk) 01:24, 14 July 2026 (UTC)

Continuation of ANI Discussion About MFD Relisting

There have been some issues raised at a discussion at WP:ANI about relisting of MFD discussions, and the discussion there seems to be winding down because maybe WP:ANI action is not required. I posted my questions a few hours ago to the MFD talk page, but I now see that it is not an active talk page, so I will mark these questions, which were not answered yet, as moved to VPP.

The original issue was that an MFD had been open for a week, and an editor relisted it, and another editor reverted the relisting, and the original editor objected, at WP:ANI. The conclusion appeared to be that the last time there was a discussion of whether MFD discussions may sometimes be relisted as in 2016, and an RFC concluded that relisting is still an option for MFD. There aren't very many MFDs at any given time, so that all of the MFD discussions are available on a single board, MFD. At least one editor objects to the relisting of MFD discussions because it rearranges the paperwork. At least one editor thinks that relisting of MFD discussions is sometimes useful because it rearranges the paperwork.

So I will ask here:

• Should deletion discussions at MFD sometimes be relisted? There has been an RFC which said that MFD discussions may sometimes be relisted, so if there is a view that consensus has changed, is a new RFC warranted?
• Should non-administrators be permitted to relist MFD discussions as a non-administrative closure?
• Should the editor who relists an MFD discussion be expected to provide a comment explaining why they have relisted the discussion?
• Should non-administrators be permitted to revert the relisting of MFD discussions? If so, when and why?

Robert McClenon (talk) 01:43, 3 July 2026 (UTC)

The answer to all of your questions is that MfD should not be treated any differently than any other XfD. Creating bespoke rules makes everything more confusing and there is no good reason for it. voorts (talk/contributions) 18:00, 3 July 2026 (UTC)

+1. Allow relisting. MFD closers shouldn't need to learn different rules about relisting than the other XFD venues. If a discussion has low participation or could benefit from more discussion, and hasn't already been relisted, then relisting is a standard and helpful tool in the toolbox. –Novem Linguae (talk) 03:42, 4 July 2026 (UTC)

When all the discussions fit comfortably on a single page, relists are just needless paper-pushing, which is why they're not the norm at MfD, DRV, or MRV. MfD is different from the other XfDs because it doesn't use daily log pages. I disagree with the 2016 RfC (which I wasn't aware of until a few days ago) and would say as much if someone decides to start a new RfC. Extraordinary Writ (talk) 19:21, 3 July 2026 (UTC)

While I take Voorts' point about consistency across processes, we do already use different layouts/structures for them, and subject nominations to a different set of deletion reasons. I guess I'm just not sure what the function of relisting is when there are only three nominations across the entire process. For reference, here's what MfD looked like on today's date in 2016, when that RfC took place, and here it is today. 62 nominations vs. 3 nominations. Now, 3 is low even by today's standard, but we haven't been anywhere near 62 in a long time, because drafts now have an automatic expiration date that they did not back then. To be clear, I don't think relisting hurts anything, either, but I just don't understand. — Rhododendrites ^talk \\ 19:31, 3 July 2026 (UTC)

I agree that maybe this relist wasn't particularly necessary, but I don't think that it hurt anything. I think reverting it was even less necessary. People shouldn't be getting verklempt over a single relist. voorts (talk/contributions) 19:45, 3 July 2026 (UTC)

I asked four questions. I will summarize what I think is being said:

1. Should MFD discussions sometimes be relisted? This is the main question. The 2016 RFC said that MFD discussions are no different from other deletion discussions and may be relisted. There are reasonable arguments that consensus has changed and a new RFC may be in order.

2. Can non-administrators relist MFD discussions? I think that the answer is that this depends on whether MFDs may sometimes be relisted. Otherwise, we do occasionally see non-administrative closes at MFD, and a relist is a closing action.

3. Should a comment be provided when relisting an MFD discussion? First, this depends on whether MFDs may sometimes be relisted. Second, in my opinion, if MFD discussions should sometimes be relisted, a comment should be provided. I agree that comment-free relistings at MFD are not helpful.

4. Should non-administrators be permitted to revert the relisting of MFD discussions? This was the original topic of the ANI report, but has not been addressed. I think that the answer is an unambiguous no, but I haven't researched whether there are non-admin reverts of relistings at AFD, TFD, or CFD.

It probably doesn't matter that MFD is like AFD in one respect in which they differ from TFD and CFD. Each AFD and MFD discussion is its own page in project space, while the daily logs are the unit pages in TFD and CFD.

Should we have a new RFC on question 1? If not, do we need to address questions 2, 3, and 4?

Robert McClenon (talk) 20:32, 3 July 2026 (UTC)

As a non-contributor to MfD who has read this thread, my answers to your questions are:

1. MfD discussions may be relisted but most often probably shouldn't be, because it achieves little. There may be exceptions to the general rule where a relisting is beneficial so it would be counterproductive to prohibit these.
2. Yes. Everybody may relist a discussion, but in most cases nobody should, per the answer to question 1. For the exceptions to the general rule it makes no difference whether the person relisting is or is not an admin.
3. It depends. If it's unclear why a discussion is being relisted it should be accompanied by a comment, if it is clear then a comment is neither required nor prohibited.
4. No. If someone is relisting inappropriately this is a user conduct issue that should be dealt with as a user conduct issue. I can think of only three reasons why a discussion might be inappropriately relisted and in neither situation does reverting the relisting help:
   • If discussion didn't need relisting because consensus was already clear, then just close the discussion according to that consensus. There is no minimum time between relisting and closing a discussion.
   • If consensus was not clear but discussion was ongoing, then the relisting might have been disruptive to that discussion but unrelisting will be at least equally disruptive. One disruptive event is better than two so just leave it be.
   • If consensus was not clear but discussion was not ongoing, just leave it be. Either the relisting will attract more input (in which case everybody wins) or it won't (in which case nobody loses).

In all cases though, if a relisting breaks any incoming links, create some sort of pointer or redirect so that people following them can find where the discussion now is. Thryduulf (talk) 21:47, 3 July 2026 (UTC)

— Rhododendrites ^talk \\ 22:49, 3 July 2026 (UTC)

@Thryduulf: MfD notices target a discussion subpage (as opposed to dates and anchors at RfD) similar to AfD. Thus—when a transclusion of an MfD subpage moves within the list on the main MfD page, no incoming links are broken and nothing needs to be altered in that regard. — Godsy ^(TALK_CONT) 09:21, 4 July 2026 (UTC)

I agree with this, also as someone who rarely participates in MFD but is a regular at other XFD venues. My one amendment is that relisting comments should perhaps be more strongly encouraged at MFD than at similar venues. They should not be required but if the norm is to generally not relist, a brief explanation will be especially helpful. In one sense, this is the same approach that should be taken with all relistings—when the reason to relist is non-obvious, an explanation should be provided. —Myceteae‍🍄‍🟫 (talk) 16:27, 4 July 2026 (UTC)

Broadly agree with Extraordinary Writ, Rhododendrites, and Thryduulf. At such a small venue the main effect of relisting isn't to encourage further participation. MfD discussions are rarely poorly attended, and rearranging the order of discussions is not a fruitful way of pursuing that end anyway since old discussions aren't forgotten about. Relisting mainly functions to discourage closure for another week. That is generally most helpful where new information has arisen later in the discussion period that is likely to change participants' minds. I think in that instance a comment will always be useful. J947 ‡ ^edits 00:44, 4 July 2026 (UTC)

Granted, it is often not the case in practice, but a relisted discussion may be closed once consensus is determined, without necessarily waiting for another seven days (WP:RELIST). — Godsy ^(TALK_CONT) 09:11, 4 July 2026 (UTC)

MFD is qualitatively different from every other deletion venue (unless you count DRV) in that it doesn't have daily subpages, so moving discussions around doesn't place them on a better-attended page. That's the sole benefit of relisting. With that gone, it's all downside. —Cryptic 00:54, 4 July 2026 (UTC)

I am going to defend relisting at MfD for several reasons:

• Generality - After 7 days, relisting serves the purpose of bringing less-attended discussions, where consensus has yet to be achieved, back to prominence at the top of the page. Many times well-attended or complicated discussions tend to languish at the bottom of the list, despite having achieved a full or rough consensus. Separating these two major archetypes of discussions makes the ones that need attention more likely to get it, especially from contributors more familiar with other deletion venues. Relisting discussions also gives them a non-mandatory (relisted discussions may be closed at any time if a clear consensus develops as I quote from guidance to another comment above) additional 7-day time-buffer of sorts to allow a consensus to naturally develop without the discussion appearing in need of expedited closure in the old business section. Set time periods allow for a deeper, fuller consensus to develop (as opposed to a constant under-the-wire environment where, for example, a sudden change in direction prevails in a tight case where it otherwise would not have).
• Parity with other venues - Driving more participation and expanding ease-of-access for the maximum possible userbase is a boon in general. Relisting is an expected feature of deletion venues; the average user may assume that the old business section consists of discussions ready for closure and wanting of one. This misconception is avoided if a discussion is at the top of the list. Of special note, users also should not be treated poorly or chided if they attempt to relist something in good faith because of such reasonable expectations.
• Timelessness of venue - Whether or not MfD is experiencing a slump or boom, having a functioning relisting system makes the venue future-proof. The architecture of relisting (being slightly different from other venues and less automated) may otherwise decay and be unready when warranted. Take {{mfd relist}} and User talk:Legobot/2025#Miscellany for Deletion relisting which show an example of such deterioration. Right now, relists must be done manually.
• Non-adminstrator relists and comment-free relists - Non-administrators who are (WP:NACD) experienced[,] ... uninvolved[,] ... [and] registered (WP:NADC) may close (or relist) ... discussions (WP:NACD). Relisting is a determination of non-consensus (i.e. that consensus has yet to be achieved). Non-administrators regularly relist discussions at other venues; it should be no different at MfD. It is less explicitly officially documented, but comment-free relists are standard (and perhaps preferred) practice when it comes to relisting. This should also not be any different at MfD than any other venue. The relisting comment field exists for the following reason:

  In general, a discussion should not be relisted more than twice. When relisting for a third (or further) time, or when relisting a discussion with a substantial number of commenters, the relisting editor should explain why they did not consider the current state of the discussion sufficient to determine a closure result (WP:RELIST).

More often than not, on the first (especially the first) or second relist, it is clear that the discussion is being relisted because consensus is (likely) split in different directions (i.e. yet to be achieved due to lack of agreement) and 'no consensus' closure is not yet appropriate. If there is a special circumstance, or something to note, then a relisting comment would certainly be appropriate.

That just about encapsulates my thoughts on the matter (though I may have forgotten some sentiments and will post again later if that proves to be the case).— Godsy ^(TALK_CONT) 08:51, 4 July 2026 (UTC)

Mackensen made an argument regarding relisting comments being generally non-optimal in the discussion that this one stemmed from, which I elude to but do not explain in depth. — Godsy ^(TALK_CONT) 09:46, 4 July 2026 (UTC)

@Robert McClenon: I would draw your attention to my fourth bullet point just above, with the hope of perhaps changing your opinion in regard to relisting comments. — Godsy ^(TALK_CONT) 10:36, 4 July 2026 (UTC)

Generality - After 7 days, relisting serves the purpose of bringing less-attended discussions, where consensus has yet to be achieved, back to prominence at the top of the page

Undesirable, if there is no point in the relisting except to move it back to the top. The pointlessness of the relisting is evident in the lack of relisting comment on why it is being relisted. Moving an MfD discussion back to the top does not get it fresh eyes, but tricks the few regulars, who already saw it, already commented or already ignored it, in to thinking that there is a new nomination.

Godsy has many many good contributions at MfD, but sometimes exercises poor judgement. When challenged, he goes on an on, as previously, and refuses to concede a single point. SmokeyJoe (talk) 14:27, 11 July 2026 (UTC)

User:SmokeyJoe - If you don't know the gender of a user, you can use the singular they, which has been used since early modern English. Robert McClenon (talk) 03:17, 16 July 2026 (UTC)

Given that relisting is presently allowed at MfD per the RfC that has been cited, only a new RfC can overturn the old consensus, not discussion at VPP. I see no reason to discuss further rather than just open an RfC, assuming that nobody is going to change their mind at this point. voorts (talk/contributions) 22:22, 10 July 2026 (UTC)

“Allowed” is a weak defence. Relisting is normal at MfD, but pointless comment-free relisting is not. Only Godsy does it. I object to him doing pointless comment-free relisting. It does no good, and it does some harm. SmokeyJoe (talk) 14:30, 11 July 2026 (UTC)

We all understand your position at this point. Your position is presently against cosnensus established by an RfC. voorts (talk/contributions) 15:52, 11 July 2026 (UTC)

If it's true that only one (1) person does this (e.g., over the course of several months or a whole year), is what that person does really the community's practice? WhatamIdoing (talk) 19:32, 13 July 2026 (UTC)

It's not just one person. I'm fairly certain I've relisted discussions at MfD. voorts (talk/contributions) 20:39, 13 July 2026 (UTC)

Relisting at MfD is normal and fine. But is it normal and fine to sporadically do comment-free pointless relisting, be told that your pointless comment-free relistings are a negative, to insist that it’s “allowed” by some guideline, and to insist on continuing? SmokeyJoe (talk) 21:34, 13 July 2026 (UTC)

Your view that comment-free relistings are inappropriate (especially in general) is a minority viewpoint (if not a vast minority viewpoint). It is overwhelmingly accepted that relists, on the first (or even second), have an inherent purpose that need not be spoken (or rather written) through a comment. I have expounded upon this at-length above. You are seemingly the only contributor that has a (at least major) problem with them, as evidenced here (aimed at others besides me). You have been a contributor at MfD for a long time and have done a lot of good work there. However, your viewpoint in this case does not overrule several well-documented discussion closes and guidelines etc. (again above) established through community consensus. Your view should not be conflated as more than that or be implied to be the view of the community. As far as sporadicity, I have periods of more or less activity, as do many contributors (appropriateness of relisting, however,—bar new community consensus—remains the same). — Godsy ^(TALK_CONT) 01:39, 16 July 2026 (UTC)

My particular view relevant is that most of your (singular you) comment-free relists at MfD are completely worthless, and of negative impact to people who pay attention to the size of the backlog.

I’ve asked you to stop.

You don’t reply to the substance, but respond verbosely off topic, ad nauseam, to use your word choice.

- SmokeyJoe (talk) 01:53, 16 July 2026 (UTC)

Maybe nobody else thought that she needed to stop. Any editor can ask another editor to do anything. Sometimes the asking can be ignored. Robert McClenon (talk) 22:28, 17 July 2026 (UTC)

I acknowledge this point. It is a relatively low level issue. My previous challenge was rebuffed, which is why I felt the revert was justified. And here we are, still with the question unanswered, “why do this relist?”. And I believe that “Because rules allow it” is not a reasonable answer. SmokeyJoe (talk) 23:57, 17 July 2026 (UTC)

I have started an RfC below. If you have already set forth your views in full in this discussion, I suggest distilling them into a concise !vote and referring editors to your comments above. voorts (talk/contributions) 02:06, 16 July 2026 (UTC)

RfC: MfD relists

Should comment-free relists be allowed at MfD? 02:01, 16 July 2026 (UTC)

Notified: Wikipedia talk:Deletion process, Wikipedia talk:Miscellany for deletion and Wikipedia talk:Deletion policy. voorts (talk/contributions) 02:05, 16 July 2026 (UTC)

Background

• Wikipedia talk:Miscellany for deletion/Archive 11#RfC: Should MfD relists be allowed or disallowed?
• Wikipedia:Administrators' noticeboard/IncidentArchive1228#SmokeyJoe - Relisting reversions at MfD and unwillingness to discuss
• See discussion above.

Survey re RfC: MfD relists

• WP:RELIST, which applies to all XfDs, states: "When relisting for a third (or further) time, or when relisting a discussion with a substantial number of commenters, the relisting editor should explain why they did not consider the current state of the discussion sufficient to determine a closure result." Otherwise, a relisting comment is not required. I do not believe there is sufficient reason to treat MfD differently from other XfDs. We shouldn't create arbitrary exceptions to guidelines, particularly procedural ones. voorts (talk/contributions) 02:01, 16 July 2026 (UTC)
• Someone is repeatedly removing my !vote from here. Please stop it.

  Of course. The question is the wrong question. A better question is: What should be done when an editor repeatedly exercises bad judgement in relisting? SmokeyJoe (talk) 02:07, 16 July 2026 (UTC)

  This is a wiki. Many things are “allowed”, technically, even if not a good idea. Good judgement is required. People without good judgement should be less bold. —SmokeyJoe (talk) 06:36, 16 July 2026 (UTC)

  I moved your "!vote" below and responded to it there, where you also responded. This is the "yes" section in response to the survey, not a place for you to continue to make inappropriate comments about other editors. voorts (talk/contributions) 20:13, 16 July 2026 (UTC)

• Yes. Comment-free relists are standard (and perhaps preferred) practice when it comes to relisting. This should not be any different at MfD than any other venue; bringing a discussion to the top of the list is a valuable action which has a net-positive affect on the deletion backlog by being an attention-drawing boon for the vast majority of contributors. The relisting comment field exists for the following reason:

  In general, a discussion should not be relisted more than twice. When relisting for a third (or further) time, or when relisting a discussion with a substantial number of commenters, the relisting editor should explain why they did not consider the current state of the discussion sufficient to determine a closure result (WP:RELIST).

More often than not, on the first (especially the first) or second relist, it is clear that the discussion is being relisted because consensus is (likely) split in different directions or the discussion is under-attended (i.e. consensus has yet to be achieved due to lack of agreement or participation) and 'no consensus' closure is not yet appropriate. Otherwise, a constant under-the-wire environment with no semi-firm time limits is fostered (which serves as an adversary to achieving natural, full consensus). If there is a special circumstance, or something to note, then a relisting comment is certainly appropriate. — Godsy ^(TALK_CONT) 02:52, 16 July 2026 (UTC)

• Yes. The question is whether they are permitted, and they should be permitted. Questions about when various types of relistings should encouraged or discouraged can be addressed later, after the current question is answered. Robert McClenon (talk) 04:18, 16 July 2026 (UTC)
• Yes. Whether they should be encouraged, discouraged or neither are separate questions but there is absolutely no reason to prohibit them. Thryduulf (talk) 08:37, 16 July 2026 (UTC)
• Yes. MfD shouldn't be different from other venues in this regard. FaviFake (talk) 09:26, 16 July 2026 (UTC)
• Yes. As I said during the ANI discussion, comment-free relists are normal and speak for themselves. Mackensen (talk) 10:46, 16 July 2026 (UTC)
• Yes. Allow relisting. MFD closers shouldn't need to learn different rules about relisting than the other XFD venues. If a discussion has low participation or could benefit from more discussion, and hasn't already been relisted, then relisting is a standard and helpful tool in the toolbox. –Novem Linguae (talk) 12:56, 16 July 2026 (UTC)
• Yes, there certainly are cases where a relisting does not need much of an explanation for itself. jolielover♥talk 13:40, 16 July 2026 (UTC)
• Relisting is an unusual action at MfD. Like at DRV, discussions rarely suffer for attention. As such a comment explaining why a particular discussion does in fact warrant further participation is normally helpful. Prescribing a comment serves to discourage thoughtless and otherwise unhelpful relists. I know I have done such relists at MfD, erroneously thinking its situation the same as at any other venue. It is ineffective to inform every editor to fall under this common misapprehension individually. I do not find the argument that the same relisting considerations should apply to all deletion venues convincing. Encouraging unfruitful relists is counterproductive. J947 ‡ ^edits 03:35, 16 July 2026 (UTC)

  What makes a relist helpful or unhelpful? Where do we draw that line? voorts (talk/contributions) 03:39, 16 July 2026 (UTC)

  I am currently drafting User:J947/Essays/When to relist? on that question. J947 ‡ ^edits 03:44, 16 July 2026 (UTC)

  I don't think it's reasonable to ask editors participating in this RfC to read a 700+ word (the page size tool doesn't count items in lists) essay. voorts (talk/contributions) 03:53, 16 July 2026 (UTC)

  (edit conflict) Well I wasn't quite sure what you were getting at. I mean you do plenty of relists yourself; you don't need me to explain which relists are good or bad. (Although, for the sake of others, I'll summarise my position. It's a judgment call of how productive the relister expects the relist to be. Relists shift attention from new discussions to old discussions. Extensions of a discussion by a week or two are usually significantly less productive than the first week, but some discussions are complicated or important enough to warrant a RfC-like amount of time (that is, where there is no consensus or no clear consensus).) J947 ‡ ^edits 04:50, 16 July 2026 (UTC)

  To clarify, an explanation should be required, not merely a comment. Comments like "final relist" and "keep or delete?" -- which pretend to be binding but are not -- are rarely useful. J947 ‡ ^edits 03:44, 16 July 2026 (UTC)

• No. Per my comments above I don't think relisting an MfD is useful at all in the mine run of cases, so I suppose I'd support requiring the relister to explain their reasoning. But whether or not there's a comment is orthogonal to the more important question of when to relist in the first place, and I don't really understand why this RfC is framed around the former rather than the latter. Extraordinary Writ (talk) 06:03, 16 July 2026 (UTC)

  When to relist is already covered by WP:RELIST. voorts (talk/contributions) 19:33, 16 July 2026 (UTC)

• There is no point resisting the incredibly strong human urges for superficial order, symmetry, and conformity, as any such act of resistance is instinctively treated as an act of aggression. In any system that has awoken to a semblance of non-conformity or non-sameness, or to a however vacuously construed internal gap, any person who advocates for that gap not to be bridged is viewed as an enemy. Any individual insisting that the gap has always been there and exists for a reason is labeled a perpetrator of mental violence. Arguing that the structure is not inconsistent, but rather applying legitimate different treatment to different things, is considered even worse, because it implies the existence of multiple gaps and thereby doubles the perceived mental violence. Because a mass society cannot tolerate the cognitive friction of specialized, highly tuned mechanisms, these elite-orientated structures inevitably face a destructive regression to the mean once exposed to the uninitiated public. Since it is impossible to protect fragile internal functions from this homogenizing force, the system must survive by fabricating a flawless public veneer of absolute consistency and "fairness".—Alalch E. 19:30, 16 July 2026 (UTC)

  User:Alalch E. : That paragraph is a philosophically interesting example of the use of language, because the individual phrases make semantic sense, but the overall paragraph has no semantic meaning. Robert McClenon (talk) 05:32, 18 July 2026 (UTC)

  Read Cognitive inertia. SmokeyJoe (talk) 23:26, 18 July 2026 (UTC)

  When the system stops being rational after all its finely-tuned "inconsistent” internal mechanisms are dismantled in succcessive confirmity campaigns, the iron law of oligarchy comes into full effect. —Alalch E. 19:42, 16 July 2026 (UTC)

• I am generally opposed to relisting (at all venues), but I do not believe we should have special rules here. Relisting should be avoided if possible, and "relisting without comment" reflects poorly on the relister, but let us fix that elsewhere, not by making additional rules for one specific venue. —Kusma (talk) 12:54, 19 July 2026 (UTC)

Discussion re RfC: MfD relists

• This is, as previously, not the relevant question. It is a disruptive survey. -SmokeyJoe (talk) 02:05, 16 July 2026 (UTC)

  Your complaint above was that the relists were "pointless" and "comment-free". I apologize if that wasn't the issue you have with the relists. voorts (talk/contributions) 02:08, 16 July 2026 (UTC)

  Actually, this is precisely the relevant question, as you yourself stated:

  The problem is comment-free relisting. All downside, no upside.

  Every question you pose is a red herring. SmokeyJoe (talk) 01:53, 11 July 2026 (UTC)

  voorts (talk/contributions) 02:11, 16 July 2026 (UTC)

  I hold that “comment-free” relisting is a problem. It has a number of problems. I acknowledge that it is widespread at other XfDs. It is not common at MfD. The only repeatedly comment-free relister at MfD is Godsy. I have explained the entirely of the problem to him, but he completely doesn’t get it. So, what to do? SmokeyJoe (talk) 02:17, 16 July 2026 (UTC)

  Can you please stop commenting on editor conduct. This is not the place to do so. I suggest leaving a brief, civil !vote above. voorts (talk/contributions) 02:19, 16 July 2026 (UTC)

  No. This is precisely about one specific behaviour of one specific editor, since about ten years ago. They and you are responding with widespread generalities, and widespread generalising is evasion of the issue. SmokeyJoe (talk) 02:21, 16 July 2026 (UTC)

  No. This is a policy dispute, that has been going on for about ten years, that is largely between two users, and is compounded by the interaction between two users. I mediate article content disputes, and I instruct the editors to Comment on content, not contributors and Discuss edits, not editors. Those two instructions are the same, and are repeated because they need repeating. Often an article content dispute is compounded either by conduct or by conduct allegations. Often resolving the content dispute by focusing on content will alleviate the conduct. One of the two editors, User:SmokeyJoe, objects to content-free relistings, and has been reverting them for about ten years. The other editor, User:Godsy, reported the reverting at WP:ANI. User:voorts is trying to resolve the policy dispute by clarifying the policy by an RFC, and is asking about exactly what SmokeyJoe was objecting to. At this point, objecting to the resolution of the policy dispute is bizarre. Robert McClenon (talk) 04:10, 16 July 2026 (UTC)

  The main dispute is over an editor's judgement, in a relatively small matter. Incidentally, I find I agree with that user's opinions on all other matters.

  I do not want your mediation.

  User:Voorts, who has recently been aggressively involved in these discussions, has unilaterally launched an RfC framed around the wrong question.

  I am very interested in J947's page User:J947/Essays/When to relist?, and I hope to contribute to it. SmokeyJoe (talk) 11:03, 16 July 2026 (UTC)

  I did not offer to mediate. I am not neutral.

  You say that the question is the wrong question. You were complaining about content-free relistings at MFD, so the RFC is about content-free relistings at MFD. What is the right question?

  If you think that the question should be about Godsy's judgment in relisting MFDs, why don't you start a discussion about what you see as the real issue? (Perhaps because you know that you are in the minority?) Robert McClenon (talk) 16:28, 16 July 2026 (UTC)

  User:Robert McClenon, there are threads in multi places, and many questions that are not important, so some good questions like this one can be hard to find.

  The first question, is whether this edit to Wikipedia:Miscellany for deletion/Wikipedia:Userboxes/Apps was a good edit. In my opinion, it was not. The discussion was ready to close, and it belonged in the backlog. I thought my edit summary was not impolite. This is a question of judgment when relisting.

  The more general question that follows that I ask is: What is the point of relisting without comment (or reason), as in when it leaves others mystified as to why it was relisted.

  I hesitate, because I am not sure whether this is a general issue for relisting everywhere, or is particularly relevant for mfd.

  I have posted by thoughts at User talk:J947/Essays/When to relist?, and encourage interested others to read User:J947/Essays/When to relist?. SmokeyJoe (talk) 23:51, 17 July 2026 (UTC)

• Of course. The question is the wrong question. A better question is: What should be done when an editor repeatedly exercises bad judgement in relisting? SmokeyJoe (talk) 02:07, 16 July 2026 (UTC)

  The ANI discussion was archived without action. This is not the place to discuss editor conduct. I suggest you strike your statement. voorts (talk/contributions) 02:09, 16 July 2026 (UTC)

  “Allowed” is also a bad choice of word. Comment-free relists should be discouraged. SmokeyJoe (talk) 02:13, 16 July 2026 (UTC)

  If we "discourage" it, that means we need to create exceptions, which would inevitably be based on personal preference. It should be all-or-nothing. voorts (talk/contributions) 02:16, 16 July 2026 (UTC)

  We don’t need exhaustive rules and exceptions. When someone is told their contributions are negative, they should consider the feedback, not insist that there’s not a rule elsewhere disallowing what they like to do. SmokeyJoe (talk) 02:19, 16 July 2026 (UTC)

  Final warning before I take this to ANI: this is not a conduct noticeboard. Stop making personal attacks. voorts (talk/contributions) 02:21, 16 July 2026 (UTC)

• Pinging @Robert McClenon, @Cryptic, @Extraordinary Writ, @Godsy, @J947, @Mackensen, @Myceteae, @Novem Linguae, @Rhododendrites to this RfC. voorts (talk/contributions) 02:20, 16 July 2026 (UTC)
• I am not sure having separate yes and no sections is the right format for this type of RFC. But probably too late to change that. Ah well. –Novem Linguae (talk) 12:59, 16 July 2026 (UTC)

  I think you're right. @Voorts, I'm not sure why you chose this format, but the having separate support and oppose sections should really only be used when the quality of the arguments is unimportant, and when the options really are binary. In this case, my !vote is mu: I think it should be allowed but should not be common and should normally be explained by some other reason than just "eh, I just wanted more people to comment". There is no place in your format for my response. WhatamIdoing (talk) 03:43, 17 July 2026 (UTC)

  Now it's one survey section. Easy fix. voorts (talk/contributions) 04:05, 17 July 2026 (UTC)

• Generally: Relisting is a problem.

When someone is working on a backlog and they encounter something that's difficult to close, the following options are safe and easy and won't result in a long whiny complaint: (a) Ignoring that discussion and (b) Relisting that discussion.

Closing that discussion is more difficult and requires an investment of thought and work, and randomly, it gets quite needless amounts of stress from aggrieved editors. So over the years we've got into the habit of ignoring or relisting the difficult ones more and more frequently. I can absolutely see why.

But we're stretched too thin. We don't have the volunteer numbers now to process all these discussions. A relist used to be unusual, a second relist used to be remarkable. Now we're unsurprised to see three relists.

We've also got another problem which is the discussions that get no participation. Again, the people working on the backlog tend to relist. But that isn't always the right thing. Some discussions get no participation because we have too few volunteers and too many XFDs, in which case relisting might help. Others get no participation because nobody cares.

I think that where a discussion has had a reasonable amount of participation it should be closed rather than relisted. (If it looks difficult and you're one of those conflict-averse people, just write "No consensus".)

I think that where a discussion hasn't had much participation it should get relisted once. If it gets near-zero participation a second time, then we ought to close it without result.

And I think that by following those principles we would use our volunteer time more productively.—S Marshall T/C 09:57, 23 July 2026 (UTC)

Lack of climate change denialist categories

I noticed that all of these exist and are seemingly widely endorsed and can be seen under Category:Advocates of pseudoscience, including examples like:

• Category:Alternative detoxification promoters
• Category:COVID-19 conspiracy theorists
• Category:Flat Earth proponents
• Category:HIV/AIDS denialists
• Category:Proponents of scientific racism

However, anything like Category:Climate change denialists has been repeatedly and seemingly aggressively eliminated, see here:

• Wikipedia:Categories_for_discussion/Log/2015_October_16#Category:Climate_Change_deniers
• Wikipedia:Biographies_of_living_persons/Noticeboard/Archive231#109_BLP_articles_labelled_"Climate_Change_Deniers"_all_at_once
• Wikipedia:Biographies_of_living_persons/Noticeboard/Archive289#RfC:_Category:Climate_change_deniers
• Wikipedia:Categories_for_discussion/Log/2020_May_22#Category:Climate_change_denialists

Why are we alright with putting people into one set of pseudoscience enthusiast categories, but not the climate change folks? — Very Polite Person (talk/contribs) 22:41, 9 July 2026 (UTC)

It could very well be that some of the other categories are inappropriate, per WP:CATEGORIZATION, WP:BLPCAT and WP:OVERCAT. Some editors really like avidly sorting, labelling, categorizing, and sub-categorizing. This can become problematic when it involves living people. --Animalparty! (talk) 23:05, 9 July 2026 (UTC)

Particularly per WP:OPINIONCAT. Nat Gertler (talk) 01:17, 10 July 2026 (UTC)

A missing canonical case here is Category:Holocaust deniers. Recently, Naomi Oreskes compares climate denial with pro-child labour movement in USA: "It’s a question of freedom. It’s not for the government to decide. A businessman—and it was almost always men—should have the freedom to run his business the way he sees fit without the government intervening. And a father should have the right to run his family the way he sees fit.”.[1] Many people, organizations and corporations are described as deniers in plain text by many RSs. I see a lot of WP:CRYBLP against this necessary category. Ixocactus (talk) 01:05, 10 July 2026 (UTC)

It is not a necessary category. It is not WP's place to WP:RIGHTGREATWRONGS. As editors, I'm sure we all agree that people that deny the Holocaust happened are not very great people, but we can't put that in Wikivoice, unless they clearly self-identify as that. And even then, a category like that is a honeypot for editors to add anyone they want.

Categories that involve these types of labels with BLP are pretty much not workable on WP, because there's no direct way to source their inclusion. They can be included in a list, where we can include sourcing, and where we can arrange the list to make clear its not Wikivoice but attribution (Like a "List of people considered to be Holocaust deniers") with strong appropriate RSes to show that. Masem (t) 01:19, 10 July 2026 (UTC)

RGW is about a lack of sources, not the act of being subjective. Read the policies you link and thus can click, people. LightNightLights (talk • contribs) 18:52, 12 July 2026 (UTC)

As someone who frequently edits about Holocaust deniers I do not think the situations with these categories are anywhere comparable. For most people in the Holocaust denial categories it is their main or a major source for notability, and therefore defining, and also self-describe as a "revisionist" or something. There was a specific movement of activists in question. PARAKANYAA (talk) 19:23, 10 July 2026 (UTC)

If I had to choose, I'd lean toward throwing out much of Category:Advocates of pseudoscience, for the same reason we got rid of Category:Climate change denialists as well as things like Category:Terrorists. Thebiguglyalien (talk) 05:14, 10 July 2026 (UTC)

I think a category for climate change denialists would be useful, but it would not be practical. The category would be for activists. As Nat Gertler noted with OPINIONCAT, it can't be people who simply voiced denialist ideas. To my mind a main hassle will be hardly any activist peddler of denial wants to claim the name. Their Wikipedia articles become the subject of talk page discussion over what euphemism or watered-down locution to use instead. People whose activist careers center on climate change denial have successfully kept their news media coverage largely scrubbed of that term. So maintaining a category simply won't work. -- M.boli (talk) 12:54, 10 July 2026 (UTC)

I think climate change categories would run afoul of WP:CATDEF far more often than those listed. Also, WP:OPINIONCAT. Then again, all of these categories have this problem... PARAKANYAA (talk) 19:22, 10 July 2026 (UTC)

Are you certain about that? We sometimes get this idea that CATDEF bans all cats that aren't "defining characteristics", but it actually says the opposite. According to CATDEF, we should normally add cats for defining characteristics (to the extent feasible), we should normally not add cats for trivial characteristics – it gives "Category:Italian people with dark eyebrows" as an example of a trivial characteristic – and we are allowed to add cats for things in between 'defining' and 'trivial'.

It seems to me that climate denial would be a defining characteristic for some outspoken deniers (e.g., certain politicians, petroleum producers, pseudoscientists) and a non-trivial characteristic for some other living people (e.g., certain celebrities). WhatamIdoing (talk) 01:27, 12 July 2026 (UTC)

CATDEF says this: "Defining characteristics of an article's topic are central to categorizing the article. A defining characteristic is one that reliable sources commonly and consistently refer to in describing the topic, such as the nationality of a person or the geographic location of a place."

Why would it be a defining category for a petroleum producer? Looking at these categories, it doesn't seem defining for most of them. Of more relevance is OPINIONCAT, which says: "Avoid categorizing people by their personal opinions, even if a reliable source can be found for the opinions." PARAKANYAA (talk) 00:47, 13 July 2026 (UTC)

Why would climate change be a defining category for certain (i.e., not all) petroleum producers? Approximately for the same reason that claiming cigarettes don't cause lung cancer is a defining characteristic of certain tobacco manufacturers (see, e.g., Tobacco politics#Significant cases).

Corporations aren't "people", and self-serving claims to promote your business against established science aren't "personal opinions". WhatamIdoing (talk) 04:34, 13 July 2026 (UTC)

Yes, and these are people categories, so they wouldn't go in there anyway? PARAKANYAA (talk) 20:34, 13 July 2026 (UTC)

The cat doesn't need to be restricted to natural persons. WhatamIdoing (talk) 00:12, 14 July 2026 (UTC)

Why would we put companies and people in the same category? And as a subcategory of activists, it would. PARAKANYAA (talk) 01:15, 14 July 2026 (UTC)

Why would it have to be a subcategory of activists? Why not put it under Category:Activism, which includes both people and organizations? WhatamIdoing (talk) 01:29, 14 July 2026 (UTC)

Because this is a discussion about the "advocates of pseudoscience" category and its subcategories. Which are already all in the activists subcategories. PARAKANYAA (talk) 00:46, 16 July 2026 (UTC)

Inside Category:Advocates of pseudoscience, I find categories for organizations, such as Category:Anti-vaccination organizations and Category:Astrological organizations, and in various categories immediately under it, I find individual organizations, such as New York Rescue Workers Detoxification Project, Narconon, and Human Diversity Foundation. If these organizations can be listed in the cats under Category:Advocates of pseudoscience, then so can others. WhatamIdoing (talk) 00:59, 16 July 2026 (UTC)

Climate change denial isn't an opinion. Jerod Lycett (talk) 10:03, 13 July 2026 (UTC)

Opinion: "a view, judgment, or appraisal formed in the mind about a particular matter". Yes, it is. PARAKANYAA (talk) 20:35, 13 July 2026 (UTC)

There are certainly some people for which climate change denial becomes effectively a form of activism. I think a category could be compliant with OPINIONCAT if it was limited to those people. Katzrockso (talk) 00:22, 14 July 2026 (UTC)

Such as folks who WP:RS or WP:SELF folks are sourceable as either activists, lobbyists, "took a stand, paid a price" sorts of people? — Very Polite Person (talk/contribs) 00:49, 14 July 2026 (UTC)

Yeah. I could see American Enterprise Institute being in a hypothetical category too. ExxonMobil climate change denial (an entire article!) would warrant inclusion. Someone like James Inhofe, whose name was immediately followed by "climate change denier" in headlines when he died seems like the kind of article that be worth including, too. Katzrockso (talk) 01:03, 14 July 2026 (UTC)

Then the problem is maybe more with the category name rather than the categorization itself. Maybe it shouldn't be Category:Climate change denialists (which would include people by opinion) but instead it should be more specific: Category:Climate change denial activists. Nakonana (talk) 11:13, 19 July 2026 (UTC)

It should either follow the existing Category:Holocaust deniers or the existing Category:HIV/AIDS denialists, possibly with a unification among all of them re denier vs denialist. Jerod Lycett (talk) 23:56, 25 July 2026 (UTC)

American Enterprise Institute and ExxonMobil are among the 95+ articles in Category:Climate change denial in the United States. Peter Gulutzan (talk) 13:43, 20 July 2026 (UTC)

What's the deal with paid editing?

I've previously started discussion here about my perspective that paid editing would seem to me to be inherently WP:NOTHERE, which people didn't agree with. Increasingly, though, I come across examples of paid editing that absolutely baffle me as to why they're allowed.

My main question is; why do we allow paid editing at all? Why, especially, do we allow freelance paid editors/digital marketing types who engage in paid editing, en masse, for multiple clients? Is it simply a matter of "if we don't allow and police it then they'll just do it surreptitiously and it'll be harder for us to manage?"

I'm not particularly compelled by the idea that this type of editing is tangentially beneficial to the encyclopedia. The sorts of information these editors are focused on adding and maintaining is typically trivial at best and outright promotional at worst.

Additionally, paid editing being openly allowed permits the companies and individuals doing the paying to essentially keep throwing shit at the wall until something sticks. Draft:Kodiak AI is an attempt at recreating an article deleted at AfD. The original article was created by an (ostensibly) unrelated paid editing contractor. After it was deleted and that contractor blocked for sockpuppetry, the company evidently just went ahead and hired a different contractor to attempt to recreate the article. Should this sort of thing be allowed? We speedily delete articles under G5 if they're recreated by a blocked user; but if they're created by a new meatpuppet acting on behalf of the same company, is that fine?

Fundamentally, anybody who spends any length of time at AfC can tell you that the drafts we receive from declared paid editors are, essentially without exception (certainly I have yet to see one), promotional in nature and wholly unencyclopedic; because of course they are. Nobody's going to pay someone to write an article that isn't in some way flattering to them or beneficial to their publicity. Why do we tolerate a category of editing that seems to be fundamentally at odds with our core principles, not to mention universally a drain on the resources of editors who are actually here to build an encyclopedia?

It especially seems absurd to me that we constantly tell these editors in some form or another that what they're doing is at odds with Wikipedia and almost certainly guaranteed to fail, but we won't go as far as to just stop them from doing it?

It seems obvious to me that if an editor came here and outright said "My purpose for being here is to promote [article subject]. I'm not going to break any rules outright, but I will not engage in any editing except for trying to publish an article about the subject I'd like to promote" we'd surely call them NOTHERE and show them the door unless they engaged in productive and non-promotional editing. But when they instead say "[Article subject] has paid me to publish the article" it becomes acceptable, despite the behaviour being the same, and we're then expected to spend our time reviewing their obviously promotional article and trying to help them hammer their square peg into a round hole.

I'm aware this has been a bit scatterbrained and polemic, so here's my attempt at collecting this into some kind of organised thought that people can engage with:

• It seems to me that "being here to build an encyclopedia" and "being here to engage in paid promotion" are inherently at odds.
• It seems to me that one fundamentally cannot be paid to publish an article about a subject without that article being inherently promotional in nature. Nobody's actually paying to get a neutral encyclopedic article about themselves, even if that's what they say they're doing and think they're doing; they have no idea what an encyclopedia article actually is, because if they did they wouldn't be paying for one. The intent is promotion and publicity.
• QED, people here to engage in paid editing are inherently here to engage in publicity, and so are not here to engage in encyclopedia-building.
• That issue aside, the fact that companies can just keep dangling the promise of a paycheck over the heads of successive paid editors despite failed attempts and AfDed articles would seem to me to be meatpuppetry. What else would you call a succession of different people engaging in editing on behalf of the same outside party?
• Maybe being paid to submit edit requests to an existing article to update uncontroversial biographical/corporate facts is fine, but being paid to write new articles from scratch I would certainly argue shouldn't be allowed, because the result is universally promotional cruft which wastes the time of volunteer editors. I don't think we should accommodate some hypothetical editor who's capable of writing an entirely unpromotional, encyclopedic article in exchange for payment; because that hypothetical editor has seemingly yet to show their face.
• If nothing else, we should at least blacklist companies whose articles have been deleted at AfD, rejected at AfC, etc.

Athanelar (talk) 06:03, 11 July 2026 (UTC)

If we ban paid article creation, companies will still submit the articles, they just won’t self-declare. Better to have a label to recognise the reality that paid editors will exist regardless and to help filter out the promotional cruft, even if that makes up the overwhelming majority. Mir Novov (contribs | talk) 06:51, 11 July 2026 (UTC)

I don't find this argument compelling because it's like arguing we should let vandals do a little bit of controlled vandalism because they'll do it anyway otherwise.

Sure, if we have a rule against something people will break that rule, and then they'll be sanctioned for it. Plus, the majority of paid editing is so evidently promotional that it's not exactly hard to detect without a declaration. A great number of paid editors don't know about the disclosure requirements when they first come to AfC, and we end up advising them about it because we can tell it's quite obviously paid (or at least COI). Of course there's survivorship bias there; but if someone wants to do UPE now they can, and if they're good enough to not get caught then they won't be, regardless of whether we permit paid editing or not. Athanelar (talk) 07:55, 11 July 2026 (UTC)

Pretty much a basic element of life. Kids should make mistakes so that they learn. This is an open wiki so that people can make mistakes and we can still collectively move forward. If you want to keep everyone in check, a wiki is the wrong model to use in my opinion. —TheDJ (talk • contribs) 11:23, 11 July 2026 (UTC)

To be fair, we also disallow block evasion, even if the person is transparent about circumventing their block and everything. Chaotic Enby (in solidarity · talk · contribs) 17:07, 11 July 2026 (UTC)

I feel that is somewhat different; block evaders probably know they are breaking a rule from the jump, but from anecdotal experience I've had to tell multiple people IRL that Wikipedia isn't like e.g. Facebook in regards to self-promotion. Mir Novov (contribs | talk) 10:06, 13 July 2026 (UTC)

I am also not certain that everyone agrees with either prong of QED, people here to engage in paid editing are inherently here to engage in publicity, and so are not here to engage in encyclopedia-building. - for one thing, bringing stuff one likes to wider attention is "engaging in publicity" and a major motivation for non-paid edits, for the other thing, they are compatible with encyclopedia-building. Although on the flipside it's true that a lot of paid editing and most of spamming contributes little to encyclopedicity. Jo-Jo Eumerus (talk) 07:04, 11 July 2026 (UTC)

for one thing, bringing stuff one likes to wider attention is "engaging in publicity" Correct, and explicitlyincluded in our policy against promotion; see WP:YESPROMO. A desire for attention should ideally never be part of an editor's motivation. Obviously that may not alwaysb e the case, but a non-paid editor has much less incentive to publicise and promote.

for the other thing, they are compatible with encyclopedia-building. Only theoretically. I'd be very interested to see an example of paid editing, especially paid creation of a new article, which benefitted the encyclopedia rather than just wasting a bunch of editor time reviewing it, deleting it etc. And even if such an example exists, on balance it's just far less common than the alternative. As I said, one only needs to spend a week or two at AfC to see how much of a timesink paid editing is. Athanelar (talk) 07:59, 11 July 2026 (UTC)

I like jawless fish. I'm happy to write about them to bring them to wider attention. This, by itself, is not necessarily bad. Where you're right is that it becomes more questionable when there is a financial incentive (or other conflict of interest) involved, which is the more important aspect rather than wanting to bring something to wider attention in a vacuum.

This can directly affect the content of the edits. If, say, I was selling fish fossils, I would have a bigger incentive to promote the species I have in stock as especially rare or noteworthy. Meanwhile, if I just want to bring a species I heard of to wider attention because I find it neat, I'll be more likely to write about its interesting features without artificially overhyping it.

All in all, I broadly agree with your point, just wanted to recenter the emphasis a little bit. Chaotic Enby (in solidarity · talk · contribs) 17:15, 11 July 2026 (UTC)

Banning stuff just simply doesn't work that well; if there's a demand for it, people will still partake. Just look at drug prohibition as an obvious example.

If we banned paid editing, all we'll be doing is turning every declared paid editor into an undeclared one, which is an even bigger time sink and harder to spot. It's not so much that we accept paid editing, it's more that the current rules are better than the alternatives. As someone with pretty extensive AfC experience, paid editors are the least of my concerns when compared to copyvios and AI-slop. In solidarity, nil ^nz 12:39, 11 July 2026 (UTC)

You could apply this argument to a lot of things, though. Should we let people generate as much AI slop as they want so long as they declare it, because it's harder to catch undeclared AI slop than it is to clean up declared AI slop? "Prohibition doesn't work" seems to be a non-argument on a website where lots of things are already prohibited. Why would restricting paid editing, or at least paid article creation, be less tenable than restricting AI editing, or than restricting vandalism, POV pushing, or any other number of editing behaviours we forbid? Athanelar (talk) 14:18, 11 July 2026 (UTC)

Paid article creation has been an issue on en.wiki for close to 20 years (I participated in the Arch Coal / MyWikiBiz DRV that was one of the first instances: [[2]]). My hot take: declared paid editing, including article creation, is one of the most transparent forms of biased editing. And biased editing in general is absolutely routine on en.wiki. We need ways to combat bias, rather than to try to bar it, which is futile.

I say this because I think most substantive article editing, including article creation is motivated by the editor having some sort of special interest in the subject. That very often leads to a bias, pro- or anti-, and this shows up in many articles. It is an ongoing challenge for the en.wiki community to tone that down through collective review and editing. The paid editor biased by publicity/marketing factors is not that different from the passionate fan of a borderline-notable band, or the keyboard warrior determined to cast light on deep wrongs in society. Or a state-allied, or state-opposed political actor. Any and all of them need policing for the inevitable bias they knowingly or unknowingly bring, but also help grow the encyclopedia.

We shouldn't bar declared paid editing outright, just manage it (as we are doing pretty reasonably now, I think). Because alongside transparent attempts to place nonencyclopedic content, paid editors also bring content we should have but haven't gotten around to adding without them. If we can't put in place reasonable processes to separate their wheat from chaff, we might as well shut up shop and go home, since in that case we definitely won't be doing a decent job addressing other forms of biased editing either. Martinp (talk) 12:41, 11 July 2026 (UTC)

but we won't go as far as to just stop them from doing it - What's your idea for how to do this? Levivich (talk) 16:06, 11 July 2026 (UTC)

For a minimum, we should blacklist paid editing on behalf of companies or individuals which have already had their articles rejected at AfC or deleted at AfD. We don't necessarily need to sanction the editors involved, but we should have a G5-like process to summarily reject/delete repeated creations of these articles by new paid editors, so as to prevent companies from continuously hiring new editors in an attempt to get their article published.

Ideally, I would say we go one step further and ban paid editors from creating new articles. Let them declare and propose edits to existing articles, but just outright forbid the creation of new articles in response for payment, even as drafts for AfC. There's no rush to make any particular article; truly notable companies and individuals can just wait for a volunteer to take notice of them and interest in them enough to write an article about them. If we catch UPEs trying to create articles anyway (which really isn't hard - most peopls looking to make a quick paycheck through UPE vastly underestimate Wikipedia's standards, and their brazenly promotional article isn't likely to last long) then we do what we already do for UPE: block and move on. No more wasting time at AfC and at help forums trying again and again to explain WP:NCORP to people who are just looking to do the absolute minimum to get their article published and collect their paycheck. Athanelar (talk) 16:51, 11 July 2026 (UTC)

To take the first idea: blacklist paid editing on behalf of companies or individuals which have already had their articles rejected at AfC or deleted at AfD ... have a G5-like process to summarily reject/delete repeated creations of these articles by new paid editors

How can that work in practice? Suppose Elon Musk pays an editor to write an article about SpaceX, and it's rejected at afc or deleted at AfD multiple times. We blacklist SpaceX? Like the encyclopedia should just never have an article about that company? Levivich (talk) 17:02, 11 July 2026 (UTC)

We do have WP:G4 for repeatedly recreating the same article that was already deleted at AfD. However, we don't do it when the article is substantially different from the deleted version. Where to draw the line can be a tough question, but I don't think something as drastic as blacklisting the article indefinitely would be helpful. Chaotic Enby (in solidarity · talk · contribs) 17:17, 11 July 2026 (UTC)

Yeah, that's why I'm asking for clarification. I assume "blacklist" and "G5-like process" means something more than G4/G5 but something less than WP:SALTing (which, I assume, nobody would be in favor of). I'm not sure what that in-between would be, but maybe Athanelar or someone else has a new idea for how it could be done. Levivich (talk) 17:36, 11 July 2026 (UTC)

@Levivich I mean that if another paid editor came along and said they're being paid by the same company to create the same article, we'd say no, and if they tried anyway then we'd summarily reject/delete it. An uninvolved editor would still be able to create the article if they so wished, it'd only be blacklisted from paid editing specifically. The purpose would just to be to make sure the company can't keep trying to throw new editors at us in the hopes one of them succeeds. Athanelar (talk) 18:27, 11 July 2026 (UTC)

if another paid editor came along and said they're being paid by the same company to create the same article, we'd say no, which is why when another paid editor comes along, they won't say they're being paid by the same company. So how does that improve anything? The company will continue to throw new editors at us in the hopes one of them succeeds, they just won't disclose paid editing. And so the purpose will not be achieved. Levivich (talk) 18:51, 11 July 2026 (UTC)

So then they'd either end up creating a draft which so obviously reeks of UPE that we easily sanction them for it, or else they go totally unnoticed, which they could very well do now as well.

Like I said: by this logic, why forbid anything? Why forbid AI generated content when people can just lie and maybe you won't be able to detect them? Why forbid POV pushing when people might be subtle enough that you can't detect them? Athanelar (talk) 21:10, 11 July 2026 (UTC)

Because that's not logic, that's fallacy :-) Specifically: not all things are the same. Just because X applies in one situation doesn't mean X applies in all situations. In the examples you give, you're conflating two very different categories of things: content and authorship. (Alan makes the same point below.) We can regulate content very well: noncompliant content is easy to detect and easy to fix or remove. Regulating authorship is an entirely different story: we allow anonymous and pseudonymous editing, and that means we have no way of really identifying the author, and thus it's almost impossible to regulate the author. That's why we ban, for example, creationist POV-pushing, but we do not ban creationists. It would be impossible to do. Similarly, we ban WP:PROMO, which is a type of content, but we do not ban super-fans or paid editors. (And, as you know, many editors apply that same logic to AI. That's why nobody cares that shit flow diagram was written by LLM.) Levivich (talk) 20:15, 12 July 2026 (UTC)

OK, if it's about content v authorship; then we ban sockpuppets and meatpuppets. Why doesn't the same logic apply there? Athanelar (talk) 05:02, 13 July 2026 (UTC)

Same fallacy! :-) That's a third category of thing: neither (1) content nor (2) authorship (as a broad group, e.g. creationists, or paid editors), but (3) individual editors who are banned for their individual actions on-wiki. We don't categorically ban Nazis (hence WP:NONAZIS is an essay, not a guideline or policy), but we do ban individuals for, e.g., publishing racist slurs on-wiki. Sockpuppetry falls in the same category: banning individuals for what they did, for breaking our PAGs. And we similarly ban individual paid editors, and also individual unpaid editors, for, e.g., repeatedly breaking WP:PAID or WP:PROMO.

BTW, why do we block and ban individuals for breaking policies? Because it's the most effective tool we've been able to think of. Some portion of the individuals will reform in order to get unbanned/unblocked, and that's so far the best we can do. Nobody's come up with a better idea AFAIK in 25+ years. But honest, as I asked at the start of our conversation, if you have any new ideas, I'm sure I'm not the only one that's all ears. I've been talking about how things are, but it's not how they have to be, it's just that this being a perennial discussion, this is well-tread ground. I'm sure all editors would welcome improvements for how to deal with all kinds of undesirable edits: paid editing, sockpuppeting, POV-pushing, AI slop, copyvio, and so on. But new ideas are rare, and promising ones are scarce. Levivich (talk) 08:35, 13 July 2026 (UTC)

Yes, but the argument you're making is that it's untenable to block paid editing in certain contexts because it'll just drive them underground. I'm not sure how it's a fallacy to apply the same logic to, for example, people engaging in meatpuppetry to do POV pushing. That's not allowed. Surely the same argument applies? We should just let them do it, provided they declare exactly what they're doing?

You can't just say "blocking and banning people works in all these other cases, but it won't work in this specific case" without specifically explaining why. Sure, I understand that the nature of the offense is different; but why, specifically, should we rule out blocking as a response to this offense? Athanelar (talk) 12:27, 13 July 2026 (UTC)

Nah dude you are bending over backwards to try to make a point. The guidelines are not consistent. Nor do they need to be. We ban authors when there's a consensus to do so. Czarking0 (talk) 06:16, 16 July 2026 (UTC)

I mean, yeah, why not? There's some point at which not having an article about a company becomes silly, but I'd argue that point is pretty far down the line, and there could be something providing an exemption for articles written by genuinely uninterested parties. For example, an article that is instantly submitted to AfD as a condition of its creation. This is not a brilliant idea, but it's something I think would probably work.

A company with worldwide fame, like SpaceX or General Motors or Theranos, would easily survive AfD, and we would have no problem. But a company whose whole history on here is a bunch of paid-for spam articles is only going to be SpaceX 0.02% of the time. The overwhelming majority will be stuff like this, which I just don't think would survive AfD, and I don't think we lose anything by saying "listen buddy, make it through Series C and do something with a substantial impact outside buying billboards in San Francisco and then we'll see". jp×g🗯️ 17:46, 21 July 2026 (UTC)

It is true that Wikipedia loses out by failing to have an article about some company that barely scrapes past GNG, but the company loses out way more than we do. "You will never be able to have an article" is an actual consequence that will affect people's decisionmaking, whereas "you get unlimited retries" is not. jp×g🗯️ 17:52, 21 July 2026 (UTC)

(edit conflict) You seem to be assuming that paid editors exclusively want to create articles about the organisation that is paying them. We know that is not true - see Wikipedia:Administrators' noticeboard#Anna's Archive Wikipedia bounty program, pattern across multiple articles for just one recent example showing that it's not as simple as that. Thryduulf (talk) 17:08, 11 July 2026 (UTC)

Around the time that the UPE rules were created, I had been thinking about hiring someone to make a series of a few hundred tedious edits from an excellent source I'd found ("___ is a rare disease"). I gave up on the idea, and it never happened. I don't think anyone would say that's WP:NOTHERE.

We've had several government agencies (e.g., National Institute for Occupational Safety and Health) and charitable organizations (e.g., Cancer Research UK) hire editors to improve articles. I don't think anyone would say that's NOTHERE, either. WhatamIdoing (talk) 01:44, 12 July 2026 (UTC)

I was actually thinking about the NIOSH guy myself, reading through this thread. I reviewed a couple of his DYK submissions, they were great. jp×g🗯️ 17:47, 21 July 2026 (UTC)

To address the second idea, banning new page creations by declared paid editors: If we catch UPEs trying to create articles anyway (which really isn't hard..., how do you know it really isn't hard? What is the total number of UPEs, and what percentage have we caught, and how could we possibly know the answer to those two questions? Levivich (talk) 19:20, 11 July 2026 (UTC)

Indeed, any undisclosed paid editors who write and/or maintained quality content about notable subjects will (and almost certainly do) go completely undetected. Nobody investigates people who add or maintain good content, and it would benefit nobody to change that because, well we want good content. Thryduulf (talk) 20:32, 11 July 2026 (UTC)

The UPEs who we already don't detect will continue to go undetected; but we're already not detecting them, so nothing changes.

The declared paid editors whose work is generally obviously paid may become UPEs if we forbid declared paid editing, but we'll be able to detect those editors because their work is already detectable as paid editing even without declaration; as evidenced by the fact that we constantly have to inform people about the declaration requirements because they don't know about them but their work is still evidently paid. Athanelar (talk) 21:12, 11 July 2026 (UTC)

And we'll continue to have false accusations, especially from editors who struggle to differentiate between "paid promotional content" and "information that doesn't particularly interest me". I remember a particularly unpleasant round a while ago, in which the terrible, horrible, no-good, very bad allegedly "UPE" editor just turned out to be an ordinary person who had attended a notable festival and decided to improve the Wikipedia article to the best of her ability. WhatamIdoing (talk) 01:52, 12 July 2026 (UTC)

The very first article I created was about a commercial tourist attraction. I could very well have been accused of being a paid editor based on that (people have been accused of such with far less justification) despite having no more connection than having recently visited. Fortunately this was way back in the days when adding content about notable subjects was viewed as a Good Thing so I wasn't and I'm still here 21 years later. Thryduulf (talk) 10:50, 12 July 2026 (UTC)

I think you're on the right track with this observation, but the relevant categories aren't just "detected" and "undetected," that's an oversimplification. If you're thinking detected paid editing is bad (because we can detect it) and undetected paid editing is OK (because we can't detect it), and if you're using the word "detect" to actually mean "PAG-compliant" (because if we detected paid editing that is fully PAG-compliant, it would be OK, not bad), there are four relevant categories:

1. PAG-compliant disclosed paid editing
2. Non-PAG-compliant disclosed paid editing
3. PAG-compliant undisclosed paid editing
4. Non-PAG-compliant undisclosed paid editing

Yet even those four categories are oversimplifying what's actually going on, because it's a continuum, not an either/or. An article can be more, or less, compliant than another. An article that violates the MOS by not having the article title in bold in the first sentence may not be PAG-compliant, but a hoax article is far less PAG-compliant. One of those two things is a real problem, and the other one isn't.

So the answer to the question why do we allow paid editing at all? is "because we have no way to prohibit it." And that leads to the next question that you implicitly ask, which is why "then why do we require paid editors to disclose at all?" And the answer is: so we can talk to them (and, through them, to their clients). So we can teach them how to move from category #2 to category #1. If they're in category #4, that becomes harder for both us and them. We encourage them to declare so we can teach them how to do it right (when they do it wrong), and that means (hopefully) they'll do it right from then on, and so it actually reduces category #4 by moving them to category #2, which helps us reduce category #2 by moving them to category #1. 25 years of testing tells us this works better than just leaving all the problematic paid editing into category #4. Levivich (talk) 20:39, 12 July 2026 (UTC)

Here's another POV: Some editors think that the rules are supposed to be idealistic. The practicality of the situation (e.g., whether we can actually prevent rule violations) is irrelevant. In this black-and-white way of thinking, it'd be far better to say "____ is bad, and we can't stop bad people from doing bad things, but we draw a line in the dirt here and say NO! to bad people doing bad things, because taking a public stand for good values is what good people do." And then when people do break them, you get to be outraged about how bad the bad people are (cue the dopamine hits from the internet outrage machine).

Here's a third POV: Some editors are looking for a sense of belonging. One of the not-so-obvious things about a community is that you cannot have a community without defining some people as being outside the community. It's "us against them", which isn't possible unless "they" exist. "We" say that "they" aren't part of the community, so why should we let "them" be present here, in our community's virtual home? They're polluting our community and our space.

I have more sympathy for some of these POVs than for others, but I think the main point is that different people will always have different values and therefore different views. WhatamIdoing (talk) 19:57, 13 July 2026 (UTC)

We basically have to allow some degree of paid editing, in that companies have a reasonable right to request correction of erroneous information about themselves, and correction of misinformation does indeed serve encyclopedic purpose. If I see an error regarding myself, I can edit the Talk page of the relevant article to request an article edit; indeed, I have done this very thing. That is not viewed as a paid edit. However, if there are errors about a corporation, which can reasonably want to have errors ("the date of founding is wrong") or omissions ("that lawsuit was withdrawn") addressed in serving the accuracy of the article... but any employee in position to make that request on the behalf of the company would be viewed as paid.

That is, of course, a different situation from starting a page on how Yumyum cookies are the best-tasting cookies because they are made from the finest ingredients. -- Nat Gertler (talk) 19:08, 11 July 2026 (UTC)

I think the fundamental dilemma is 'focus on the content not the editor'. I think, we determined a long time ago we can't control people's motivations, we can try to channel them, at best -- but we do want people to be motivated to edit. At any rate, this has been hashed out for decades, and although perhaps, a new consensus could form, I doubt it. I might even like a policy of a total ban (on article creation?), just for the feels. The present policy has costs, but any new policy will too, and likely unintended consequences. Alanscottwalker (talk) 11:26, 12 July 2026 (UTC)

I agree with you that paid editors are fundamentally NOTHERE to build an encyclopedia (with some exceptions, as WAID notes); they're here because their boss told them to be here. However, I still think that allowing paid editing with guardrails is a net benefit. Requiring PE disclosure allows us to review content before it makes its way into mainspace and ensures that comapnies can request that content of interest to our readers, such as revenues figures, leadership changes, or important mergers, be updated. The only harm from paid editing (other than the ideological harm of having editors who are NOTHERE) is some level of slop, but that problem wouldn't go away if we banned paid editing; I'd still be patrolling Category:Candidates for speedy deletion as spam from time-to-time. In fact, I think the problem would arguably be worse because we wouldn't be able to track paid editors as easily without the formalized COI edit request structure. Finally, as @NatGertler said, I think we'd run into serious issues if we didn't allow companies to request corrections to outdated (or even mis-) information. voorts (talk/contributions) 21:10, 13 July 2026 (UTC)

The greatest contribution of paid editors on Wikipedia is disclosure. Accesscrawl (talk) 07:42, 14 July 2026 (UTC)

The problem is that "misinformation," to a PR flak, often means "anything that does not glaze our company." Gnomingstuff (talk) 19:49, 14 July 2026 (UTC)

I meant literally incorrect information. voorts (talk/contributions) 20:38, 14 July 2026 (UTC)

You do not hear about the paid editors that do not cause problems. I do a lot at the COI backlog so I see probably more than others would. I have also been working on Flock Safety recently I find their paid edits to be worth discussion. Czarking0 (talk) 06:11, 16 July 2026 (UTC)

I feel like one of the major incentives for paid editing is that we have an extremely half-assed approach to consequences, and we also have a very dumb lopsided set of procedures that make it impossible to follow the rules. For example, if you want to "follow the rules", you have a single contractor submit something to AfC with their whole deal disclosed, in which case you wait several months for a review, it probably gets instantly rejected, and you have no recourse. Most people would consider this a punitive response. Meanwhile, if you just hire people to sockpuppet and break the rules, you get a review nearly instantly (either the article gets speedied or it doesn't). You also get unlimited retries, because every time you hire a spammer to write an article, we will treat it as a new isolated incident, and there's always a possibility it just survives NPR and AfD, and then you win.

One time, a friend of mine messaged me to ask how he would go about having an article made for some famous guy he knows, knowing and agreeing that we hate paid articles and you're supposed to follow a process to do it legitimately. This is someone who is actively trying to follow the rules. The subject seemed like he might have actually passed GNG. so I asked around with some other admins and other highly knowledgeable people to see if anybody knew what he was supposed to do. Everyone's best suggestion (including mine) was "they need to have the person writing it make an account and do the CoI declarations and throw it in the jungle of AfC and then after 3 months some random person will decline it on a lark". Contrariwise, I have had a great deal of experience with people who paid for drafts, and then they got rejected, and they just kept trying to do it with different accounts, and it actually worked (until I screwed them over by going back to find all the previously-declined submissions and draftified everything).

My proposal to even things out would be that we just, like, institute a policy that any time there's out-of-process submissions for a company/organization/businessperson, they are put in a "go to hell forever" category where it doesn't matter if you pass AfC later. That is the only thing I can think of that would actually make a rational person try to submit anything to our process rather than just hire paid editors over and over until one got through. jp×g🗯️ 17:38, 21 July 2026 (UTC)

I think that would harm Wikipedia at least as much as it would harm the company tbh - we want content about notable topics and this would prevent us from having that in some cases. The one that thing would actually encourage doing things by the book is to fix AFC so that reviews happen in a reasonable timeframe (days at most) and reliably reflected the actual state of the article and topic (i.e. stub-class or better articles about notable topics would get accepted, stub-class or better articles about borderline notable topics would be accepted subject to an AfD or equivalent community discussion). Unfortunately both of those are hard problems to solve. Thryduulf (talk) 12:24, 26 July 2026 (UTC)

Additionally, blocks/page deletions are not designed to be used for punishment/deterrence. Even if they were, I think this line of reasoning overestimates how much people actually give a shit about being blocked or having a page deleted on Wikipedia. voorts (talk/contributions) 12:32, 26 July 2026 (UTC)

another reason not to blacklist topics like this is that it would be very easy to do a joe job on a competitor. There's not very much more stick we have to use - we've got to make the carrot more acceptable. one possible idea i have had is reducing the workload for COI edits by having something like "pending changes", so a COI reviewer can say yay or nay to specific changes rather than having to pore through prose edit requests which can often be quite fiddly to implement. this won't help for AFC though of course. Morwen (talk) 13:10, 26 July 2026 (UTC)

Display of legend notes

Hi, Myself and user 4TheWynne (talk · contribs) have a difference of opinion (as seen here). As far as I know, when we have a legend, such as the one in this template, we show only the relevant notes (such as c and vc in this case currently), while 4TW thinks we should display all the legend regardless (including for example injuries and pregnancies even though Collingwood don't have any currently). Can anyone here please chip in and point me to the relevant policy about such a question? In all cases I've seen (for example on national football team pages on recent call-ups section) we only show the relevant notes. --SuperJew (talk) 06:23, 15 July 2026 (UTC)

For context, late last year I fixed the formatting across the 72 AFL/AFLW squad and personnel templates, as many were formatted incorrectly/inconsistently and/or out-of-date, and this included tweaking the legend in the personnel templates; I don't see how displaying the full legend is an issue, particularly given they are only visible on two pages each and nowhere in MOS:LEGEND (or even in MOS:TABLES as a whole) does it state or advise against doing this. SuperJew, for the record, 1. the legend has been fully displayed for over six months, which would make this the stable version, and you only hid the legend for the first time two days ago, which I then reverted, so I'd rethink your position on who is the B and who is the R in BRD, and 2. it wasn't blind reverting, as I had deliberately formatted the columns so that the first and far right (coaches/legend) columns were the same length, as I've always done. 4TheWynne (talk • contribs) 07:40, 15 July 2026 (UTC)

You're bringing up points that are not related at all to this discussion - consistency and editing history of BRD. This discussion is net about the policy of displaying legends. Having notes for things which aren't relevant just begs questions of the reader and is confusing. There is no need to include unnecessary content. --SuperJew (talk) 18:43, 15 July 2026 (UTC)

Those points are the reason we are having this discussion at all. I did give my stance as well, including that the visibility is extremely low anyway, but on your other point, displaying the full legend and each of its elements, which have very clear uses, isn't likely to confuse readers in and of itself (and if anything can be useful/interesting to show the different categories/management of players), at least nowhere near as much as elements appearing on the templates which weren't in the legend (which used to happen every now and then). 4TheWynne (talk • contribs) 20:30, 15 July 2026 (UTC)

I have to agree. As a reader, I often "work backwards" from the legend, and having legend entries that aren't in the chart is simply confusing. If there is a technical hurdle to trimming the legend, then fine, but it sounds like that's not the case here. --Ahecht (TALK
PAGE) 16:35, 16 July 2026 (UTC)

I agree with 4TheWynne's position. Given the formatting is consistent across all similar templates in the project, displaying a consistent legend is desirable – because it unambiguously communicates that there are no long term injured or pregnant players in this specific team. The alternative of omitting legend leaves the reader unsure whether the team is injury/pregnancy-free, or the editor of the page in question has simply given no consideration to including that designation. I think Ahecht's comment above makes sense for a standalone table, but 4TheWynne's position makes more sense for a related group of tables, even across multiple pages if in the same context or category. Aspirex (talk) 11:52, 20 July 2026 (UTC)

As far as I'm aware there isn't any policy for this, besides the general MOS pointer of "have a legend". Subjectively though, I'd tend to agree with 4TheWynne too - especially given the case that these template receive frequent updates (or at least should, in theory), having a consistent legend I think is important for stability. The relevant legend entries might not always appear, but the conclusion from there would be none of them currently apply. With respect to Ahecht's comment though, it might be pertinent to reconsider what information is important for inclusion in the legend for the purpose of minimising confusion. Is highlighting pregnancy/retirement/LTI worth it, when all three ultimately fall under the already-listed Inactive list, for example? Empole1 (talk) 23:04, 22 July 2026 (UTC)

Empole1, I do understand where you're coming from, but none of those are likely to cause confusion; I feel it could be useful to distinguish between different playing absences in a way that the squad (navbox) templates don't to fill in the gaps better and further set the two template types apart. 4TheWynne (talk • contribs) 15:34, 24 July 2026 (UTC)

I wasn't aware of this discussion, but 4TW has repeatedly reverted me for removing unused legend items, and previously reverted my balancing of the length of the columns in the table because he wanted the first column to match the length of the last column, which is extra long due to the extraneous legend entries! i made my recent edits after doing some edits for golfers, and in their articles, they only list the relevant legend entries, not all possible win types. Simplicity is best. There's no need to show legend entries for items that aren't in the attached table. The-Pope (talk) 16:36, 24 July 2026 (UTC)

WP:You don't want an article about yourself

I saw some discussion at WP:MNB that a number of mentees will ask only a single question, how they can get themselves or their business on Wikipedia. Some mentors mentioned that pointing them directly to WP:AUTOBIO can be intimidating, as it's a long policy page and somewhat hard to read for an entirely new user. Is there interest in writing a much shorter Wikiessay summarizing the key points? I think for something like this, it would be best to avoid talking about notability and instead just write a short paragraph (maybe 2 at the most) simply trying to dissuade the reader. guninvalid (talk) 03:16, 17 July 2026 (UTC)

We do have Wikipedia:An article about yourself isn't necessarily a good thing, although a shorter and punchier version probably wouldn't be a bad idea at all. Extraordinary Writ (talk) 03:21, 17 July 2026 (UTC)

I'm not sure we need an essay for that. It's entirely valid for a mentor to respond to that question with "You don't, at least not without getting experience being a regular Wikipedia editor first."

I wrote WP:PAIDADVICE in the same spirit. A lot of people respond to paid editors with links to WP:BOSS and WP:PRPEOPLE and advice on why they shouldn't do what they're doing, and then follow it up with "...but if you want to try anyway, then follow these steps:" The inevitable result being that they're going to ignore all of your warning preamble and just skip to the part that tells them how to do what they want to do.

Sometimes the correct approach to an editor who obviously has no chance to succeed in what they're trying to do is just to tell them not to do it, plain and simple. Just because they're technically allowed to doesn't mean we have to go to lengths trying to teach them how rather than steering them in a better direction. Athanelar (talk) 06:20, 17 July 2026 (UTC)

I think the reason this line of argumentation isn't persuasive is because it's not true. Having a Wikipedia article about yourself is almost universally considered a highly positive thing, which people have paid thousands of dollars for over the course of more than two decades. This is basically the same idea as a police department trying to deter car theft by running commercials where a cop explains that cars are loud and break down all the time and it's hard to find parking and you're actually better off not having one. jp×g🗯️ 06:20, 19 July 2026 (UTC)

I think it's a perspective thing. It's safe to say most Wikipedia editors probably wouldn't want an article about themselves, but that's because we've all seen how the sausage is made. For the layperson they just see the idea that they could Google their name and have the first result be a Wikipedia page about them and they think it's like a badge of fame. Athanelar (talk) 06:48, 19 July 2026 (UTC)

I'd estimate that the modal case of someone having an article about themselves, the effect on them somewhere between neutral and overwhelmingly positive. Clicking Special:Random to get a few: Erick Lonnis, Helena Gellerman, Mira Falardeau, Koche Munda, and Girolamo Sirchia. The cases in which it has a negative impact are pretty rare and easy to foresee, e.g. if you are a politician and have a documented history of corruption or major criminal convictions, which most of them don't. The one IT consultant whose vanity article I supported deletion for, who subsequently went berserk and started sending me threatening emails (which he still does every once in a while) seemed to think that an out-of-date Wikipedia bluelink was absolutely critical for his career. Most people who buy them, I think, have a realistic concept of the whole thing. jp×g🗯️ 17:25, 21 July 2026 (UTC)

Revision of WP:BIDI

Proposed revision of WP:BIDI:

−

Whether to include navboxes, and which to include, is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]] at each individual article. Per the bidirectionality principle above, this may also affect inclusion of a particular article in a navigation template. If a disagreement should arise, please centralize discussion at the article talk page, not that of the template (which may be [[Help:Watchlist|watchlisted]] mostly only by template coders).

+

Whether to include navboxes, and which to include is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]]. Community consensus can be arrived at by starting a discussion at the talk pages of each contested article in the navigation template, or through discussions in the template's talk page to make an exception to BIDI as it applies to all articles on the template if starting a discussion on each contested article's talk page would create an unreasonable burden on editor time that can better be resolved in a single discussion. If the discussion is started on the navigation template's talk page, additional measures should be taken to ensure the discussion receives attention (such as by posting to a noticeboard), as navigation templates are often [[Help:Watchlist|watchlisted]] only by template coders.

I will describe the problem I am trying to solve with this revision.

I maintain multiple large-scale sidebars that have encountered the same type of conflict. I will talk about Template:Gaza genocide sidebar, the most illustrative example, where a good-faith editor cited WP:BIDI and deleted 33 articles from the sidebar [3] that I believe are conducive to the sidebar but do not technically have the sidebar on their article pages. Edit: Mentioning this is not a means to win any specific dispute, but instead to provide a case study where BIDI has caused friction and would benefit from being updated. After contesting this at the template's talk page, consensus found that per BIDI and WP:ONUS, the inclusionist editors are expected to start individual discussions for all 33 removed articles and create consensus for each individual sidebar re-addition on each individual page, because the sidebar had been (in most cases) removed from each of those individual 33 pages after being initially added (this specific point may be contested, but I believe this is an accurate characterization). ZLEA summarized this conflict well, saying Centralizing 33 discussions into one may sound like a good idea in theory, but I believe it does go against the principle of WP:BIDI.

Using BIDI as a rule-of-thumb rather than an absolute is the norm for large sidebars, as according to this comment, Template:LGBTQ sidebar has 245 articles linked but 38 of those articles do not have the sidebar linking them back. I could theoretically go to Template:LGBTQ sidebar, delete all 38 links, and cite WP:BIDI, forcing editors to start an individual discussion on the talk pages of each of the 38 removed articles (as opposed to having one centralized discussion where we can agree it's probably okay not to have to follow BIDI absolutely on this sidebar). This would tire out editors maintaining Template:LGBTQ sidebar to the point where they would likely give up on adding the content back because the centralize discussion at the article talk page, not that of the template provision in BIDI makes inclusionists do an unreasonable amount of work in many instances.

There are many reasons why a page might not use a sidebar, including the page just not having much space or a person removing it by accident (which I've seen happen, although I forget the exact location) which is only noticed later down the line. These reasons that have little to do with the relatedness between a sidebar and its articles should not be a reason to prohibit the sidebar from linking non-BIDI articles on the sidebar if doing so makes sense for the sidebar. That is why I am expanding the centralize discussion at the article talk page, not that of the template provision to include an option for one centralized discussion on the nav template's talk page. Alexandraaaacs1989 (talk) 22:41, 2 July 2026 (UTC)

Pinging additional editors who were involved with related discussions:

PARAKANYAA, Sirfurboy, ScrubbedFalcon, WhatamIdoing, The Gnome, SnowRise, CNC, Katzrockso, Cdjp1, David A Alexandraaaacs1989 (talk) 22:45, 2 July 2026 (UTC)

x2 SecretName101, Tryptofish Alexandraaaacs1989 (talk) 22:45, 2 July 2026 (UTC)

It is seldom wise to make a proposal to change general policy as a means to win a specific dispute. AndyTheGrump (talk) 22:51, 2 July 2026 (UTC)

Please do not assume bad faith. Even if this proposal is passed, it would not "win" me any dispute. I am here making a good faith suggestion I believe would improve Wikipedia. Alexandraaaacs1989 (talk) 23:01, 2 July 2026 (UTC)

There is an open RfC on Template talk:Gaza genocide sidebar regarding this issue, which you started. AndyTheGrump (talk) 23:12, 2 July 2026 (UTC)

That RfC has expired with presumed consensus against my proposal. Alexandraaaacs1989 (talk) 23:13, 2 July 2026 (UTC)

Then why would you start a new discussion at a different forum if your proposal doesn't have consensus? SuperPianoMan9167 (talk) 20:39, 3 July 2026 (UTC)

I'm responding to the ping. I think it might be reasonable to interpret the existing language as permitting discussion at a particular article talk page, chosen so as to be a potential best "fit" for the discussion, but also to post notifications elsewhere. One way to accomplish that would be to post a link to the discussion at the article talk pages of the other affected pages, although of course this might require a very large number of such notifications. Alternatively, one could post only at those pages seen as most likely to be significantly affected, or at a WikiProject that would be interested in the particular topic. Or one could ping interested editors, as was done here.

An alternative option might be a discussion at templates for discussion. When a template is discussed there, I believe a bot or some sort of automated process puts an (annoying) message alongside the template on every page where it is used.

I also think that it's a potential misreading of ONUS to say that only the "inclusionist" editors are obligated to issue the notifications. If, hypothetically, a template has been used for "a long time" (I'm not going to attempt to define that precisely) at a page, then the "deletionist" editor who wants that template removed from that page has an obligation to justify changing that page from the status quo. --Tryptofish (talk) 23:13, 2 July 2026 (UTC)

Whether a particular article should be listed in a navbox is not within the scope of TfD and I don't see the benefit to centralizing these types of discussions there. voorts (talk/contributions) 23:23, 2 July 2026 (UTC)

That's a valid point, I guess, although I was thinking about discussions at CfD, where there is sometimes a decision to partially purge the members of a category, so I think one could propose limiting the scope of a template without proposing its deletion. --Tryptofish (talk) 23:28, 2 July 2026 (UTC)

I like all the suggestions you made, and I think writing them into the policy as possible ways to go about starting one centralized discussion would be an improvement over the current wording. But I disagree that it's clear these options are available (as opposed to it seeming like we're expected to start a unique discussion on each individual article talk page), since BIDI specifically says discussions must be started at each individual article, don't you think?

The ongoing ONUS vs NOCON debate seems to currently be trending against introducing a "long time" constraint (or expectation for deletionists to ever have to be the ones to issue a notification) affecting whether WP:ONUS triumphs over WP:NOCON when there's a contradiction between the two, so I wrote this proposal under the assumption that WP:ONUS takes precedent when the inclusion of any content is contested. Your interpretation of ONUS may win the dispute though, in which case this proposal would not be as useful as it would be otherwise, but regardless I think BIDI is overdue for some clarifications in wording even if we take your assumptions about one centralized discussion being an option to be true. Alexandraaaacs1989 (talk) 23:28, 2 July 2026 (UTC)

−

Whether to include navboxes, and which to include is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]] at each individual article. Per the bidirectionality principle above, this may also affect inclusion of a particular article in a navigation template. If a disagreement should arise, please centralize discussion at the article talk page, not that of the template (which may be [[Help:Watchlist|watchlisted]] mostly only by template coders).

+

Whether to include navboxes, and which to include is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]]. That discussion should generally occur on the talk page of the affected article with notification to the template talk page and other affected articles, if any. It may also occur on the template talk page with notification to the affected article.

voorts (talk/contributions) 23:20, 2 July 2026 (UTC)

Don't make things more complicated than they need to be. PAGs rarely require, rather than encourage, notification of affected editors or pages. For example, editors are required to place a template on the target page of a merge discussion. We should not extend those requirements to whether a particular page is included in a navbox. voorts (talk/contributions) 23:22, 2 July 2026 (UTC)

I like that proposed revision, and I agree that it's good to keep things simple. --Tryptofish (talk) 23:29, 2 July 2026 (UTC)

Me too, I'm happy with this simpler proposal. Alexandraaaacs1989 (talk) 23:33, 2 July 2026 (UTC)

Minor nitpicks:

−

Whether to include navboxes, and which to include is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]]. That discussion should generally occur on the talk page of the affected article with notification to the template talk page and other affected articles, if any. It may also occur on the template talk page with notification to the affected article.

+

Whether to include navboxes, and which to include, is ultimately determined through [[Wikipedia:Consensus|discussion and consensus among the editors]]. That discussion should generally occur on the talk page of the affected article with notification to the template talk page and other affected articles, if any. If multiple articles are affected, the discussion should generally occur on the template talk page with notification to any affected articles. Notifying related discussion pages, like [[Wikipedia:WikiProject|WikiProject]] pages, may also be appropriate.

Alexandraaaacs1989 (talk) 01:07, 3 July 2026 (UTC)

Also, see WP:NOTIFIER. voorts (talk/contributions) 23:26, 2 July 2026 (UTC)

I think this proposed change undermines the very principal of WP:BIDI. I won't pretend to know what specific circumstances led to determined through discussion and consensus among the editors at each individual article being included in the guideline, but its not hard for me to imagine the purpose of that exact wording. First of all, I do think discussions should be as centralized as reasonably possible to prevent misunderstandings and to simplify decision-making processes. However, there comes a point where too much centralization can hinder such processes and prevent a consensus from forming. To use the Template:Gaza genocide sidebar example you mentioned, a centralized discussion on whether to include 33 links creates a serious problem. Each editor who wants to weigh in on the issue now has to go through each of the 33 articles and individually justify their decisions about all of them. This can become extremely complicated and potentially heated very quickly, and would be nothing less than a nightmare for the closing user to sort through. And let's be real, I doubt very many editors have that kind patience, and most will probably do a blanket "support" or "oppose" vote on all articles in question without taking a close enough look at them (which opens the door for another serious problem I'll cover below). Meanwhile, 33 individual discussions would be far more manageable. Users who watch the articles or are more knowledgeable in the topics can easily weigh in without having to worry about other articles they either don't care or know enough about. Likewise, closers don't have to spend unreasonable amounts of time sifting through each users' arguments for dozens of articles.

As I stated above, the most likely outcome of a centralized BIDI discussion is that editors choose blanket support/oppose votes rather than taking the time to comment on each article individually. This potentially opens the door for bad faith editors to sneak articles that probably should not be linked in the template (similar to the concept of rider legislation in politics). This would be especially troublesome for templates that could reasonably be perceived as allegations of crime, including and especially genocide, where just one wrong link could trigger WP:LIBEL. - ZLEA ^TǀC 02:08, 3 July 2026 (UTC)

Hi Zlea, thank you for your in-depth response and explanation. I think there's some miscommunications between us at play here:

• I think this proposed change undermines the very principal of WP:BIDI. I agree. I'm seeking to change its principle.
• Regarding when there's one centralized discussion when many articles are removed from a template: some individual article removals may be debated in the centralized discussion, but overall the purpose of centralizing the discussion is that you can talk about the disputed content in groups, rather than as individuals, whereas in your example, you talk about it as if the centralized discussion would be going into depth about all 33 individual links even though this would not usually be the case (unless deletionists took the time to start discussions about each of the individual 33 disputed articles). I.E. this policy change seeks to expedite things by not necessitating that all 33 links disputed are spoken about individually which is what the policy mandates right now. Respectfully, 33 individual discussions would be far more manageable sounds oxymoronic to me as a statement in general, which is what this change is seeking to address.
• the most likely outcome of a centralized BIDI discussion is that editors choose blanket support/oppose votes rather than taking the time to comment on each article individually. This potentially opens the door for bad faith editors to sneak articles that probably should not be linked in the template The problem is that right now, the opposite is true: that currently if you decide to remove dozens of articles from a sidebar, it is nearly impossible to challenge said removal without devoting weeks of time to each individual discussion. There needs to be a balance struck between the two, and I think this subtle change to the wording of this policy will accomplish this.

Alexandraaaacs1989 (talk) 03:59, 3 July 2026 (UTC)

I agree. I'm seeking to change its principle. Most good (and successful) proposals to change policies and guidelines are made with the intention to clarify and/or strengthen their principals. Their principles are things that should very rarely, if ever, be messed with, as changing them without considering all the possible ramifications can lead to very unpredictable outcomes.

...but overall the purpose of centralizing the discussion is that you can talk about the disputed content in groups, rather than as individuals... That's exactly my point. Such discussions should be the exception, not the rule, and as such should only be done with exceptionally good reasoning.

Respectfully, "33 individual discussions would be far more manageable" sounds oxymoronic to me as a statement in general, which is what this change is seeking to address. That only tells me that you have never been involved in any actual over-centralized discussions. There's a reason that the immediate response of many editors to your discussion was to oppose it as a bad RfC. Most of them have probably seen the results of similar over-centralized discussions, understand why guidelines such as BIDI explicitly discourage them, and want to avoid them at all costs.

The problem is that right now, the opposite is true: that currently if you decide to remove dozens of articles from a sidebar, it is nearly impossible to challenge said removal without devoting weeks of time to each individual discussion. The problem is that users are adding links to sidebars without regard for the relevant guidelines. Had they followed the guidelines to begin with, this issue would have never happened in the first place. There needs to be a balance struck between the two, and I think this subtle change to the wording of this policy will accomplish this. First of all, there's nothing subtle about rewriting half a paragraph to undermine or change the principals of a guideline. Second, we shouldn't change guidelines to conform to nonconformity of said guidelines. That's like declaring an unreliable source to be reliable simply because it's already used on thousands of articles and would take too long to fix. Yes, fixing rampant policy/guideline nonconformity sucks, but that's no reason to move the goalposts to make noncompliance acceptable. - ZLEA ^TǀC 05:07, 3 July 2026 (UTC)

I shouldn't have so hastily stated I'm seeking to change its principle - that was a poor choice of words so I take back what I said about seeking to change the policy's principle. I only meant I am seeking to change the policy to make it easier to start centralized discussions that allow many unidirectional links to be added to a navbox. This would affect the policy's implications, but not its underlying principle.

WP:BIDI, as of right now, de facto precludes the sidebar from including unidirectional article links even though we are de jure allowed to include as many unidirectional articles as you'd like to be added to a navbox. The de jure aspect, in my view, represents the principle of the policy, whereas the de facto aspect represents a disconnect between the policy's principle and practice.

What's more, technicalities in the policy's wording should not override the capacity for editor discretion in deciding how they would like to run discussions about disputed content. There are reasons an article might not include a sidebar that do not imply the sidebar wouldn't benefit from a unidirectional link from that article, and discussing these cases shouldn't be technically allowed, but practically impossible when there's more than 3 articles in question.

If editors are adding links to sidebars without regard for the relevant guidelines, that's something that can be addressed by deleting the contested content from the navbox for reasons other than BIDI and expecting the editors seeking to include the disputed content to start a discussion if they'd like to contest the content's deletion (assuming WP:ONUS overrides WP:NOCON). The proposed revision in no way prohibits us from debating the inclusion of any individual articles on the navbox. It only prevents the necessitation that we debate the inclusion of each unidirectional article even when editor discretion finds that doing so is an exorbitant and unnecessary time sink. If editors can agree that being forced to start 33 individual discussions is less efficient than what could instead be the same quality of conversation across one or multiple centralized discussions, then BIDI should not override editor preferences and force them to go about a potentially highly-inefficient way of running discussions about a set of related articles. Alexandraaaacs1989 (talk) 11:32, 3 July 2026 (UTC)

I only meant I am seeking to change the policy to make it easier to start centralized discussions that allow many unidirectional links to be added to a navbox. This would affect the policy's implications, but not its underlying principle. That sure sounds like you're trying to change its principle, or at the very least attempting to make it easier to undermine it. That's not even considering the fact that over-centralization of discussions is detrimental to consensus building. (Some context for my next point, the removal of links that violate the guideline is nothing more than housecleaning. It's not "deletionism" or whatever you want to call it. There's a sharp contrast between the removal of guideline-violating links and the mass removal of links that do not violate the guideline.) The mass addition of non-bidirectional links or the mass removal ofbidirectional links is not supposed to be easy because such proposals could be easily abused.

There are reasons an article might not include a sidebar that do not imply the sidebar wouldn't benefit from a unidirectional link from that article, and discussing these cases shouldn't be technically allowed, but practically impossible when there's more than 3 articles in question. Again, those should be the exception, not the rule. If an unreasonably large number of articles cannot include a sidebar for whatever reason, then that's an entirely separate problem that would be swept under the rug by your proposal.

If editors are "adding links to sidebars without regard for the relevant guidelines", that's something that can be addressed by deleting the contested content from the navbox for reasons other than BIDI and expecting the editors seeking to include the disputed content to start a discussion if they'd like to contest the content's deletion (assuming WP:ONUS overrides WP:NOCON). That's not how policies and guidelines work. Blatant violations of the both the letter and spirit of the rules should not be kept just because they don't appear to violate any other rules. Exceptions to the rules can and should exist if it benefits the overall goal of Wikipedia, but they must be individually justified.

It only prevents the necessitation that we debate the inclusion of each unidirectional article even when editor discretion finds that doing so is an exorbitant and unnecessary time sink. That "time sink" isn't exorbitant or unnecessary, but rather by design. As I explained above, processes that are too easily abused are not supposed to be easy and will take time. - ZLEA ^TǀC 15:31, 3 July 2026 (UTC)

You said: If an unreasonably large number of articles cannot include a sidebar for whatever reason, then that's an entirely separate problem that would be swept under the rug by your proposal. But why is is that necessarily an entirely separate problem, when I explained There are reasons an article might not include a sidebar that do not imply the sidebar wouldn't benefit from a unidirectional link from that article?

You point to the risk of abusability meaning editor discretion (regarding whether to centralize discussions) should be prohibited and editors should be forced into decentralized discussions. But how precisely might this policy be abused? Because what this process would look like is that before someone would like to add non-BIDI links to a navbox, they would be expected to make a list of non-BIDI links they'd like to include and start a consensus-building discussion on the navbox talk page. Then the community would decide whether the navbox merits a template-wide exception for BIDI depending on the scope of the navbox and the articles seeking to be added. No exceptions to BIDI will be made without explicit discussion, and the exception still needs to be individually justified - just on a template-wide basis rather than a per-article basis. Setting the standard as needing to be set on a per-article basis rather than a per-template basis feels arbitrary. Can you really say that two non-BIDI articles of the same category need to have completely separate discussions for inclusion 100% of the time, mandated by Wiki policy, banning the capacity for editors to merge the two discussions into one? Alexandraaaacs1989 (talk) 23:27, 4 July 2026 (UTC)

But why is is that necessarily an entirely separate problem, when I explained "There are reasons an article might not include a sidebar that do not imply the sidebar wouldn't benefit from a unidirectional link from that article"? Because those reasons are few and far between and should be relatively easy to work around in a vast majority of circumstances. I've lost count of how many times I've repeated "the exception, not the rule", it's practically become my catchphrase.

You point to the risk of abusability meaning editor discretion (regarding whether to centralize discussions) should be prohibited and editors should be forced into decentralized discussions. But how precisely might this policy be abused? Alright, here's an example. Let's consider a hypothetical scenario involving a sidebar template about communism. A bad-faith user with an extreme dislike of one of their local left-wing politicians wants to insinuate some sort of similarity between said politician and figures like Joseph Stalin or Fidel Castro. To accomplish this task, the user proposes adding 35+ links to articles on what they claim to be "prominant communists", but sneakily includes the name of their local politician somewhere in the middle. They know that most users will probably give the list of links a glance, see a few well-known names, and focus on the merits of such a list being included in the sidebar rather than scrutinize the proposed links themselves. This scenario is similar to the concept of rider legislation in politics. Right now, such a scenario is thankfully next to impossible because the very principle of BIDI stands in the way. Even if all the benefits you envision from changing the principle are guarenteed to come to pass, you still have to weigh them against the potential consequences. The example I have is just one hypothetical scenario or how your proposed change could be abused, but the actual outcome of your proposal will almost certainly be something neither you not I could predict. As I said before, there is a reason the principles of policies and guidelines are rarely, if ever, messed with.

Now that I have given just one example, I'd like to hear from you, as the proposer, what other potential consequences of the proposed changes you have considered, and why you believe the benefits outweigh them. How confident are you that any unforseen consequences would also be outweighed by the benefits?

No exceptions to BIDI will be made without explicit discussion, and the exception still needs to be individually justified - just on a template-wide basis rather than a per-article basis. I already explained why this is a bad idea, so all I have to say at this point is good luck convincing anyone who has been involved in overcentralized discussions otherwise.

Can you really say that two non-BIDI articles of the same category need to have completely separate discussions for inclusion 100% of the time,... Yes, that would be ideal. I'd say maybe 99% of the time, though. There may indeed be circumstances where a more centralized discussion would be beneficial, but I'm sure you know my catchphrase by heart by now. ...mandated by Wiki policy,... BIDI is a guideline, not a policy. There arguably should be a policy on the overcentralization of discussion if avoiding such is so controversial, but from what I'm seeing from everyone else's responses here, we're not at that point. ...banning the capacity for editors to merge the two discussions into one? "Banning"? No. At least not unless it's absolutely necessary because users keep overcentralizing discussions to the point that it's a major burden to the community. - ZLEA ^TǀC 05:19, 5 July 2026 (UTC)

I'll also give my thoughts on your use of "inclusionist" and "deletionist" labels in this discussion. Our policies and guidelines are written with the sole purpose of guiding users on how to build and maintain an encyclopedia. A user's "-isms" are an informal reflection of their interpretations of said policies and guidelines, but these labels are not supposed to define a user's identity or behavior on Wikipedia. Attempting to change the rules to benefit a specific "-ism" runs counter to the purpose of P&Gs; "-isms" aren't supposed to act like or be treated like political parties. Therefore, it is my opinion that such labels are best left out of discussions on policies and guidelines as they can lead to false assumptions about the motivations of entire groups of editors. - ZLEA ^TǀC 05:37, 3 July 2026 (UTC)

I'm simply using the terms as shorthand for "editor who wants the content removed" and "editor who wants the content included", nothing deeper. But I understand how it might sound a little WP:BATTLEGROUND. If you have alternative shorthand phrasing ideas, I'm all ears and am open to improving my choice of words. Alexandraaaacs1989 (talk) 10:51, 3 July 2026 (UTC)

That's my point. You're thinking in terms of "editor who wants the content removed" and "editor who wants the content included" without considering the underlying reasons. I'll reiterate that policies and guidelines are written with the sole purpose of building and maintaining an encyclopedia. If they are written or changed to cater to any specific "-isms", then they stray from that purpose. - ZLEA ^TǀC 15:31, 3 July 2026 (UTC)

In all honesty, in many cases where Alexandraaaacs1989 refers to a hypothetical "inclusionist editor" and "deletionist editor", you can replace "inclusionist editor" with "Alexandraaaacs1989" and "deletionist editor" with "Sirfurboy" and the meaning of the comment will remain largely unchanged. See my comment below. SuperPianoMan9167 (talk) 20:45, 3 July 2026 (UTC)

I am not saying we should understand the disagreement as a conflict between two opposing "isms". I'm simply using the "isms" as shorthand words that are more effective at conveying which side (no, not side in the battleground way) each editor is on in the disagreement than saying "editor A" and "editor B". Whenever I read "editor A" and "editor B", I lose track of which one is which. But the "inclusionist" is the editor trying to include the content, and "deletionist" is the editor trying to delete the content, and those labels are much easier for my brain to understand. If you'd like to continue this line of discussion, let's bring it to my talk page. Like I said I am all ears to suggestions, but this feels a bit like a semantic nitpick with my choice of phrasing that I'm not sure is conducive to this policy discussion. Alexandraaaacs1989 (talk) 23:12, 4 July 2026 (UTC)

I do not wish to continue arguing about this. I think you've explained what you meant quite well here. - ZLEA ^TǀC 05:19, 5 July 2026 (UTC)

I think that "undermining the very principle of WP:BIDI" is exactly what's needed for sidebar navboxes only. The sidebars are supposed to be short lists of links to a handful of key articles. Some of them instead link to more than 150 articles, because someone enforced BIDI by adding all the articles that were transcluding the main template. I think that Template:Psychology sidebar, as shown here, or even a more concise version of it, could legitimately have 25 links in it, and correctly/usefully/relevantly appear on more than 1,000 articles.

I'd suggest a rule that says something like:

• Sidebars should link to a small number of key articles, with a limit of n links.
• The sidebar should be placed in any article where editors agree that it's relevant and desirable. Display considerations (e.g., preferring it in an article without an infobox) are acceptable reasons for including/excluding.
• The goal should be for a sidebar to be placed/potentially place-able in at least 10 times as many articles as are linked in the sidebar. It should be "psychology" with 25–50 links in a thousand or more articles about psychology, not "quantum psychology subtype 2" with 10 links in just those 10 articles. If you want BIDI or if it can realistically only be placed in a few articles, then it should be formatted as a footer navbox instead of a sidebar navbox.

WhatamIdoing (talk) 21:16, 4 July 2026 (UTC)

I don't disagree with you, but I'm not sure that would be "undermining the very principle of WP:BIDI". If we were to consider such sidebars to be an accessory to navboxes (all links in the sidebar must appear in the navbox at the bottom of the page), then the principle is already satisfied by the latter. - ZLEA ^TǀC 05:19, 5 July 2026 (UTC)

That would result in stacks and stacks of navboxes. The article Psychology would have to have navboxes to basically every article that's about psychology. Having links to thousands (or tens of thousands) of articles is IMO an anti-goal.

Instead, I think that editors ought to be able to decide between specific/BIDI (footer) and short, general, non-BIDI (sidebar) navboxes, based on their editorial judgment about the needs of the article. If editors decide that some minor sub-article should have a sidebar that offers our desktop (minority) readers a quick path back to the key articles in the subject, then let them. Don't try to force a link in the Psychology article's navboxes to that minor sub-article. WhatamIdoing (talk) 16:46, 5 July 2026 (UTC)

Oppose. Why? What does this add? Why is this an improvement? Sidebars are not supposed to be all inclusive by their very nature, this would go against that. PARAKANYAA (talk) 03:20, 3 July 2026 (UTC)

It's an improvement because it would allow navbox-wide exceptions to BIDI to be made without needing approval for every single article in the navbox. Forcing editors to seek approval dozens of times in order for non-BIDI articles that otherwise belong in a navbox to be included in that navbox places a nearly-impossible burden on inclusionists seeking to dispute the deletion of non-BIDI articles from the navbox. It isn't in favor of being "all-inclusive". It's simply in favor of preventing BIDI from functionally prohibiting exceptions that would enable non-BIDI articles to be added en masse to navboxes. Alexandraaaacs1989 (talk) 04:11, 3 July 2026 (UTC)

And why would we want that? PARAKANYAA (talk) 10:07, 3 July 2026 (UTC)

I explain here. Alexandraaaacs1989 (talk) 11:05, 3 July 2026 (UTC)

Oppose - Per ZLEA above, this is an attempt to undermine the very principle of WP:BIDIRECTIONALity. It would allow sidebars to become complete editor curated taxonomies by discussion on the sparsely watched template talk pages, which is not what they are designed for, and would have deleterious effects. Sirfurboy🏄 (talk) 06:45, 3 July 2026 (UTC)

The current work-in-progress proposal addresses your second concern by providing guidelines that help ensure the discussion isn't domineered solely by template talk page watchers, e.g., by making "best practice" suggestions like notifying the talk pages of all individual articles affected in a centralized discussion. As for your first concern about the principle, I address it here. Alexandraaaacs1989 (talk) 11:16, 3 July 2026 (UTC)

How hard is it for you all to use the notifier userscript to notify relevant pages of discussions? This whole dispute seems massively overblown. voorts (talk/contributions) 18:02, 3 July 2026 (UTC)

Is nobody going to answer this question? voorts (talk/contributions) 15:18, 4 July 2026 (UTC)

I've been trying to leave room for others to reply, but I can respond with my thoughts on this since no one else has. If you're suggesting we use the notifier userscript as a substitute for amending BIDI, I don't think this would address the central concern about the current wording of WP:BIDI seeming to prohibit the centralization of discussions about multiple articles, which de facto bans navboxes from using many non-BIDI links (even when doing so is appropriate). If we amend the policy's wording to allow centralized discussions, then using the notifier userscript seems like it would be a very useful tool. That's my current understanding of things. But if I'm completely missing the mark and you're just talking about using the notifier userscript to attract attention to the current page, it's something I noted for future use but felt was redundant since I already notified 12 users from related discussions, but feel free to correct me if using the template would still be useful in some other way. Alexandraaaacs1989 (talk) 22:59, 4 July 2026 (UTC)

Mutual agreement to collapse the discussion

I agree with Voorts. As far as I can tell, the whole dispute ultimately stems from a long-running disagreement between two editors: @Alexandraaaacs1989, who personally objects to WP:BIDIRECTIONAL being applied to the sidebar templates they created ({{Authoritarian drift during the second Trump administration sidebar}}, {{Immigration policy of the second Trump administration sidebar}}, {{Gaza genocide sidebar}}), and @Sirfurboy, who was generally the first to remove many links from their templates. While there are often more than two editors involved, it's essentially a two-party dispute. When Sirfurboy carried out a large removal on the Gaza genocide sidebar after a dispute at the authoritarian drift sidebar, Alexandraaaacs1989 immediately reported them to ANI. For the record, Sirfurboy was originally called in when another editor pinged them saying Sirfurboy is knowledgeable about what is and is not allowed in sidebar templates, and Sirfurboy responded saying So the main issue here is that these are WP:SIDEBARs that are being used as exhaustive taxonomies, where a category or a footer template should be used. This was March 19. This mainly personal dispute between two editors has been disrupting Wikipedia for nearly four months now. It derailed the ONUS vs NOCON discussion (read through the collapsed part to see it), in which Alexandraaaacs1989 specifically objects to what they call "drive-by ONUS deletionists" (in other words, Sirfurboy removing links from their templates). I participated in that discussion and called this out as ownership behavior. This current discussion looks very much like an attempt to game the system by changing the guideline in order to win a content dispute. It is also forum shopping because a discussion is already open about WP:BIDI at Template talk:Gaza genocide sidebar#RfC: Only include bidirectional links in sidebar?. When asked about this, Alexandraaaacs1989 replied That RfC has expired with presumed consensus against my proposal. So why open a new discussion at a different forum if your proposal doesn't have consensus? I think this matter should be referred to ANI because of the disruption. SuperPianoMan9167 (talk) 20:36, 3 July 2026 (UTC)

While I think it would have been more appropriate to discuss this on my talk page before making a public accusation, I guess I will respond here, as much as I am skeptical this is the best place to be having this discussion. Sirfurboy and I have been perfectly civil with one another in this discussion, and the extent of our past conflicts has been resolved. While yes we have had issues in the past (which I admit are largely the result of my own actions), we discussed a potential self-imposed two-way interaction ban in a discussion mediated by Trypto, but we decided against it and have not had any problems since. I am here making a good faith suggestion I believe would improve Wikipedia. Accusing me of forum shopping, disruption, gaming the system, and ownership behavior while pointing to ANI personalizes and escalates the situation, relitigating drama that has since been resolved while distracting from a concrete policy suggestion that is clearly not meritless, even if you disagree that it should be implemented. This is my first and last suggestion related to BIDI on VPP, and if it fails I have every intention of accepting the discussion's outcome, as I have for every discussion on Wikipedia that has not gone my way (of which there are many). Prior to this comment, I'd stopped responding in this discussion to ensure there's room for others to participate and have made multiple edits [4] [5] intended to make my comments take up less space, specifically out of concern for not being disruptive. Let's please not escalate things. If this VPP proposal fails, that's fine, and mistakes are allowed. Alexandraaaacs1989 (talk) 02:24, 4 July 2026 (UTC)

I realize after the fact that I probably should not have said some of the things I have said, and I am not trying to drag out old grudges just for the sake of being a troll. In fact, I was about to edit my comment to clarify that the two of you have been civil to each other since May. But I have to ask: why open another discussion about bidirectionality on a different page if your first proposal failed? If you are not trying to change the guideline to win a specific dispute, why mention said dispute at all? SuperPianoMan9167 (talk) 02:30, 4 July 2026 (UTC)

The reason why I started the discussion here after the RfC failed is because the RfC changed my mind: I realized I was in the wrong in the RfC precisely because BIDI's current wording supports the conclusion those editors came to in that discussion. Starting a discussion here is not a relitigation of the same issue, but an acknowledgement that other editors' arguments in the previous discussion about what BIDI implies were correct, and that my fundamental disagreement is actually with the current conception of BIDI rather than anything particular to that discussion, which is why I'm now advocating here for an amendment to the policy. Not out of objection to anything particular to myself, but out of objection to the current wording of a policy I believe could use improvement. Does that answer your question and can we now put this line of discussion to rest? Alexandraaaacs1989 (talk) 03:00, 4 July 2026 (UTC)

Yes. Feel free to collapse this thread. SuperPianoMan9167 (talk) 14:03, 4 July 2026 (UTC)

Unarchiving this discussion. Hoping to reach some form of consensus. Alexandraaaacs1989 (talk) 20:30, 19 July 2026 (UTC)

• Oppose There's no good reason provided to change anything. Jerod Lycett (talk) 00:00, 26 July 2026 (UTC)

WP:POPULATED

Does a Tehsil meet Populated, legally recognized places for notability, or does the Tehsil need to establish notability itself? It seems somewhere below a county and above a municipality level of division, with the Districts they are divided from being the equivalent of a county. I think it's attempting to inherit notability. Jerod Lycett (talk) 05:14, 21 July 2026 (UTC)

I suggest asking this at Wikipedia talk:Notability (geographic features). Note, however, that there has been a long running and contentious debate, spread over many sections on that page, about what "legally recognized" means, and how it applies outside the United States. I thought an RfC was about to open, but, not quite yet. Donald Albury 20:59, 21 July 2026 (UTC)

I was only focused on getting the guideline clarified for Tehsil (hence asking here where changes are made in the hopes that some level of division was determined through consensus), but it seems the phrase itself is what is problematic. I'll edit this to expand when I have time tomorrow. Jerod Lycett (talk) 23:50, 21 July 2026 (UTC)

RfC: NPOL & sub-national leaders of major political parties

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is overwhelming consensus against WP:NPOL covering sub-national party leaders. Chaotic Enby (in solidarity · talk · contribs) 10:16, 23 July 2026 (UTC)

---

Should sub-national leaders of major political parties (e.g., the chair of a U.S. Democratic or Republican state party) be covered by WP:NPOL? 20:38, 21 July 2026 (UTC)

See RFCBEFORE discussion.

Notified: Wikipedia talk:Notability. voorts (talk/contributions) 20:40, 21 July 2026 (UTC)

Survey (NPOL)

• No The purpose of NPOL is to ensure that we have complete coverage of national and sub-national elected officials legislators, judges, and executive officials. State or province-wide party leadership should continue to be judged by GNG/NBASIC. voorts (talk/contributions) 20:38, 21 July 2026 (UTC)

  Just a note, NPOL does not mention "elected", only "legislative bodies". A recent example is Darline Graham who was not elected but is serving in the US legislature. I think the point of NPOL is those who represent and can make laws impacting their constituents at the state or national level, regardless of party affiliation (i.e. their decisions impact the represented group, not just the party). S0091 (talk) 20:58, 21 July 2026 (UTC)

  Clarified. voorts (talk/contributions) 21:04, 21 July 2026 (UTC)

• No. These are often not public-facing and public-elected so they do not have the automatic visibility of national and subnational leaders. They can continue to be covered by GNG. —David Eppstein (talk) 20:57, 21 July 2026 (UTC)
• No severely lacks a global view of various political systems. many which are not democratic much less a two-party systems and gets us into the quagmire of what is a "leader" and a "major party". S0091 (talk) 21:11, 21 July 2026 (UTC)
• No They usually sit in meetings and talk people to death. Not public enough. GNG is enough. Yesterday, all my dreams... (talk) 21:14, 21 July 2026 (UTC)
• No. I agree with voorts, David Eppstein, S0091, and Yesterday. These individuals are often obscure even within their own state. There is no presumption of notability and they should be held to GNG. —Myceteae‍🍄‍🟫 (talk) 21:17, 21 July 2026 (UTC)
• No NPOL is too broad as it is. Covering people who do not make law nor governmental decision is exccessive. If they are truly notable, they will meet WP:GNG. If their position is notable, the position can have its own article with list of position holders. -- Nat Gertler (talk) 22:03, 21 July 2026 (UTC)
• No per voorts, David Eppstein, S0091, and Yesterday. Many party leaders will meet GNG and there is no reason to presume notability for holding this party office (especially for someone who is temporary). --Enos733 (talk) 22:18, 21 July 2026 (UTC)
• No, unless evidence is presented that these people overwhelmingly pass WP:BASIC, including historically and globally. pburka (talk) 23:57, 21 July 2026 (UTC)
• No. I haven't seen an articulation of what problem is being solved here. Are we lacking meaningful content because there are many state party leaders who have not received significant coverage in reliable sources that are independent of the subject? Davidwbaker (talk) 00:59, 22 July 2026 (UTC)
• No I'd add that an implicit point of NPOL (which applies equally to members of the judiciary) is that it accords notability because of the universal (jurisdictional) power vested in persons within specific offices; something clearly absent in the role of a political party chair. Regards, Goldsztajn (talk) 10:26, 22 July 2026 (UTC)
• No I have to agree with everyone else, this seems unclear and unnecessary. -- LCU ActivelyDisinterested «@» °∆t° 11:44, 22 July 2026 (UTC)
• No NPOL is fine the way it is and I agree that most people covered under this guideline would be incredibly obscure. Lynch44 13:58, 22 July 2026 (UTC)

Discussion (NPOL)

• Is this going to be WP:SNOW or supersnow? Yesterday, all my dreams... (talk) 01:30, 22 July 2026 (UTC)

  Waiting for the 24 hour mark to snow it. Chaotic Enby (in solidarity · talk · contribs) 12:24, 22 July 2026 (UTC)

  Thanks Yesterday, all my dreams... (talk) 15:36, 22 July 2026 (UTC)

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.