Jump to content

Wikipedia:Village pump (proposals)/Archive 218

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219

RfC to determine how reflinks are linked or not in the |work= field as done by bot. -- GreenC 20:05, 3 April 2025 (UTC)

User:GreenC bot (WaybackMedic) fixes broken URLs semi-manually per request at WP:URLREQ on a per domain basis. The bot is uniquely programmed for a single domain.

One of the features is incidentally adding reflinks in the |work= field for example converting |work=theguardian.com --> |work=The Guardian. This is done per the MOS WP:REFLINK which states

"Citations stand alone in their usage, so there is no problem with repeating the same link in many citations within an article".

This is done mostly cosmetically, when making other changes within the citation or article. It is not the bot's primary purpose, but since I am making bespoke code specific to a domain, I can easily do this at the same time.

An editor recently requested this feature be disabled. So that I may continue fixing dead links, I complied and set to feature set 2A below. However I would like to see if there is preference from other editors, and to offer a set of features available.

There are 2 choices (bot or nobot), and if bot, 4 choices how:

1. Don't mess by bot
2. Acceptable by this bot, within certain rules.
A) Convert domain names to work name but don't wikilink - template documentation requires name of the work: |work=theguardian.com --> |work=The Guardian
B) Convert domain name to work name and wikilink it: |work=theguardian.com --> |work=The Guardian -- default for the past 5 years it is low volume
C) Wikilink existing work names: |work=The Guardian --> |work=The Guardian - can be high volume
D) Both B and C - recently done for thetimes.co.uk only, that triggered the complaint due to the high volume
E) No opinion
3. Other suggestion. I can not guarantee other suggestions could be programmed. Thus, please include one of the above in addition to any custom suggestions. Custom suggestions without one of the above will default to #2.E the closer will sort it out.

Note: |work= could also be: |website=, |magazine=, |newspaper=, |publisher=

The complainant User:SchroCat at User_talk:GreenC_bot#Stop_linking_newspapers. Others who may be interested based on their knowledge of this tool and CS1|2: @Οἶδα, MrLinkinPark333, Pppery, Chew, Sariel Xilo, Lyndaship, Nemo bis, Kailash29792, Random fixer upper, Headbomb, Trappist the monk, Redrose64, Izno, ActivelyDisinterested, and Lewisguile:

A !vote might look like Option 1 or Option 2B etc.. -- GreenC 20:05, 3 April 2025 (UTC)

  • I don't see why we should stop linking newspapers, etc. Linking is extremely useful. Headbomb {t · c · p · b} 20:08, 3 April 2025 (UTC)
    I !vote 2B, fwiw. Headbomb {t · c · p · b} 16:06, 4 April 2025 (UTC)
  • Option 2B, second choice 2D. Like Headbomb, I am a passionate supporter of linking reference works. In the current information environment, a top question every literate reader should be asking when they look at a reference is "Is this source reliable?" They should not have to blindly trust that it is, and a link to the article about it provides an easy way for them to investigate further. And there is extremely little downside, since references are out of the way at the bottom, and external links are marked as external with the icon, so the source links aren't distracting anyone (thus the guidance at MOS:REFLINK; WP:REFLINK goes elsewhere).
    That said, as much as I urge all editors to make linking the default in their articles, it is something where we allow variation per WP:CITEVAR, and linking only one/some source(s) could create discrepancy. For the situation in B, if an article has not had enough care put into its references to specify the publication name rather than just the URL, I see no issue with updating it to our best practice. (I make a similar call in the AWB task where I correct e.g. |work=New York Times → |work=The New York Times.) But I'm slightly more hesitant to do so for the situation in C. Sdkb talk 20:32, 3 April 2025 (UTC)
  • Option 2B - If it ain't broke, don't fix it. But when it is, may as well kill two birds with one stone. Adding wiki-links to citations is entirely unnecessary unless you are already fixing the citation. I would, at the very least, want it to change from the URL to the name, and if we're already updating it, why not also add a wiki-link? But forcing it to be linked without changing the contents (what is suggested in 2C) doesn't feel super necessary, unless you are already updating the citations.
    The bigger concern here is seeing what should be in the work param in the publisher param. I would, regardless of how it gets changed, make sure the publisher param is moved to work. E.g. changing |publisher=New York Times to become |work=New York Times . And, of course, you can add the wiki-link to this as well when doing so. This might end up being option 3, if the bot doesn't already do this, but I need to make sure I get this comment out. Chew(V • T • E) 21:07, 3 April 2025 (UTC)
  • Option 2A. (Second choice option 1). It should be a decision by editor discretion at page level whether to link newspapers or not. It should not be decided by a few of people here or a bot. Having inconsistently formatted references, which is what this will lead to, is amateurish and second rate; it also clashes with the consistency requirements required for featured articles. The MOS does not require these links, and bots should not be forcing a change if editors have decided on following the MOS to keep them unlinked. - SchroCat (talk) 21:11, 3 April 2025 (UTC)
  • Option 2D or 2B. One complaint in 5 years does not override the clear and demonstrated usefulness of wikilinking reference names. If volume is a concern for 2D I would support rate limiting it (e.g. a maximum number of otherwise unchanged articles per day) Thryduulf (talk) 21:29, 3 April 2025 (UTC)
  • A - please, per SchroCat, or a lot of editors are in for a lot of work undoing well intentioned bot edits. Gog the Mild (talk) 21:34, 3 April 2025 (UTC)
    Which they should not undo if there is a consensus per this discussion. Izno (talk) 21:50, 3 April 2025 (UTC)
    There is no requirement in the MOS for them to be linked, so when editorial discretion follows the line of the MOS in not linking, people will (rightly) revert something that has forced inconsistency into an article. - SchroCat (talk) 01:44, 4 April 2025 (UTC)
    Reverting a bot performing a job with consensus of a level that might be demonstrated in this discussion is simply disruptive behavior and would be worthy of a block. Izno (talk) 18:04, 4 April 2025 (UTC)
    No it isn’t. It is editing within the confines of the MOS. If you think editing within the MOS is worthy of a block, that’s a little on the extreme side that wouldn’t stand up long at a review. - SchroCat (talk) 18:34, 4 April 2025 (UTC)
    I'm not arguing about the MOS though. If a consensus is established here, you have to abide by this consensus also. Not doing so is what earns you the block. Izno (talk) 18:40, 4 April 2025 (UTC)
    I think you’re misunderstanding what this is about. This discussion is about whether to allow a bot to undertake one single step: it is not a discussion that forces all those aspects of the articles to remain like that forever. If this proposal gets consensus I will not stop the bot from undertaking that task (pressing the stop button to stop it, for example, would be against the consensus, and yes, it would be disruptive and blockable). But I am allowed to edit the article afterwards in my way I wish: this discussion does not change the MOS which will continue to allow flexibility on the point that the linking is based on editorial discretion on individual articles. - SchroCat (talk) 18:47, 4 April 2025 (UTC)
    In any way that you wish is in fact not the truth, because that leads to edit warring with the bot. Good luck with your interpretation if the bot's approach becomes consensus. Izno (talk) 16:09, 12 April 2025 (UTC)
    Editing one part of something a bot does that is still within the MoS will not lead to a block, unless the admin rally wants to be dragged to ANI for overstepping any reasonable grounds of behaviour. There is nothing in the RfC that means titles can be unlinked or that all titles must be linked. The MoS says differently and there is nothing in the RfC that will change that. It’s certainly not edit warring either: it’s entirely within WP:BRD to delink the names. I’m not sure why you’re so keen to block people for editing within the bounds of the MoS and our existing editing guidelines, but I hope you try and look at this more rationally before you act. - SchroCat (talk) 16:49, 12 April 2025 (UTC)
    As I said, good luck with your interpretation. Izno (talk) 19:59, 12 April 2025 (UTC)
    My “interpretation” of the MoS and the project norms of editing are the commonly accepted ones. I’m not the one trying to stretch a possible consensus on one bot’s actions to cover an entirely different part of the MoS. - SchroCat (talk) 20:28, 12 April 2025 (UTC)
  • At least 2A. I'm pretty ambivalent about whether something is linked in the work field and have personally disagreed with the practice in the past, mostly because people must eventually figure out what the Guardian is. Izno (talk) 21:54, 3 April 2025 (UTC)
  • Option 2B, or 2D; per Sdkb and Thryduulf. Also per Chew, I have also personally not witnessed the bot adding reflinks ONLY. It is an addition made alongside a different function the bot is already performing, for example the migration of URLs from thetimes.co.uk to thetimes.com. If the bot were "fixing" every article without reflinks then that would absolutely be excessive and would have been complained about already. Instead it is merely performing a useful addition, one which is supported by MOS:REFLINK, and one within and edit that is already being performed. This had certainly already been discussed, but I fail to see how reflinks are not helpful. Look at a recent page creation like If You Only Knew (Acetone album). Not a single reflink, and most sources being ones I am unfamiliar with. I agree with Sdkb. Every reader should be wondering, "Where is this information supported?", and upon hovering/clicking on an inline citation and seeing no reflink (made even worse in the absence of URLs) readers are not helped. On the aforementioned article, I would have to copy and paste 20 work titles to even somewhat determine that these are reliable sources. I also believe most references are now being auto-generated from URLs with tools like the one in visual editor, which does not add reflinks. Οἶδα (talk) 22:25, 3 April 2025 (UTC)
  • 1 or 2A. MOS:REFLINK allows repetition of wikilinks within references, but does not require them. Until that changes (which would be a different discussion), linking or not is discretionary, and consistently not linking (or other consistent approaches, like linking only first appearance) shouldn't be changed without discussion. On top of that, changing it as this bot does - on a per domain basis - would introduce inconsistency in most articles, unless one happens to cite only sources from the domains the bot is working on. Nikkimaria (talk) 00:03, 4 April 2025 (UTC)
  • Option 2B or 2D; the links are useful, especially for sources that users may not know about. For instance, most people who actually read the sources will have some idea of what The Guardian is, but I've edited NZ-focused articles that link to The Post which readers may not be familiar with. I personally only add links to the first mention of a work in citations, but IMO a bot adding redundant links is better than there being no links because humans have better things to do than add them to all articles.  novov talk edits 01:08, 4 April 2025 (UTC)
  • I don't oppose links in work fields, although I haven't been using them myself much recently, but it does feel close to a cosmetic change. It may be preferable for 2C to happen only alongside other changes. CMD (talk) 02:50, 4 April 2025 (UTC)
    I would add as well that I do not find the overlinking arguments convincing. Each reference should be fully functional as a standalone item, as that is how it will be interacted with. MOS designed for article prose will not apply in the same way. CMD (talk) 14:56, 22 April 2025 (UTC)
  • 2A. I don't think it's a big consistency problem if some instances of The Guardian in the citations are wikilinked and some are not, or if The Guardian is wikilinked but The New York Times is not, but I don't think a bot should be making that call. 2A is a useful clean up, though. I would be OK with 2B if an editor specifically invoked the bot for a given article, if there's any way to do that. An edit that just adds a wikilink is not cosmetic, but has the potential to flood watchlists so I would prefer not to see 2C. Mike Christie (talk - contribs - library) 04:06, 4 April 2025 (UTC)
  • 2A I don't understand why we would wikilink the Newspaper if there is a URL linking the actual article that is being referenced, which shows where it comes from. It's also not part of MOS either.Davidstewartharvey (talk) 05:21, 4 April 2025 (UTC)
    @Davidstewartharvey, as I argued in my !vote, the main reason is to help readers more easily evaluate the trustworthiness of a source. Why is an external link insufficient for that? Well, I'm sure The Daily Mail describes itself as a reliable source. Sdkb talk 14:32, 22 April 2025 (UTC)
  • 2A, for the convincing reasons above. Tim riley talk 07:29, 4 April 2025 (UTC)
  • 2B I tend to wiki-link from the work/newspaper/magazine/etc. field when I'm constructing citations, as I think it helps to establish reliability, as well as providing sometimes much-needed disambiguation when titles are similar, if not the same, for several publications. That The New York Times is often referred to as The Times is a good example of why such disambiguation is needed. Dhtwiki (talk) 10:05, 4 April 2025 (UTC)
    But it you sctuslly link the article by URL, it takes you directly, so why would you need a wikilink to show who the works is? Davidstewartharvey (talk) 10:17, 4 April 2025 (UTC)
    You may be assuming that the cited article remains live on the newspaper's main active site. Older newspaper articles are often to be found only on archive sites such as British Newspapers Online, Newspapers.com or Gale. The article is normally paywalled and most readers can't click through; even if they can, the link won't help them find the newspaper's main website. MichaelMaggs (talk) 13:17, 4 April 2025 (UTC)
    For some publications, especially those that are less well known or are published in foreign languages and using non-Latin scripts, it's not easy to discern whether they are legitimate news sources or something less reliable. Dhtwiki (talk) 14:50, 4 April 2025 (UTC)
    @MichaelMaggs and @Dhtwiki That may be the case, however, automatically linking the work of each reference, which in some cases may have been used more than once (I.e. two or three Times articles), would be overlinking. Davidstewartharvey (talk) 15:03, 4 April 2025 (UTC)
    Not when it’s useful, namely in the references. MichaelMaggs (talk) 15:25, 4 April 2025 (UTC)
    How can overlinking of, for example, The Times, been useful? If an article is linked to three different articles, a bit would link every single ref to it. That is overkill. Which is why it should be down to editors to link the article. Davidstewartharvey (talk) 15:44, 4 April 2025 (UTC)
    To help to avoid overlinking is in large part why I voted for 2B, not 2C. Dhtwiki (talk) 15:58, 4 April 2025 (UTC)
    Reflinks stand alone in their usage with regards to overlinking. Whether the bot should do it is another argument which is already being discussed here. But simply put, how many times a work is reflinked is not an instance of overlinking (MOS:REFLINK). Οἶδα (talk) 20:37, 4 April 2025 (UTC)
    I fail to see how reflinks should ever be suppressed in the absence of URLs. Readers are not further directed anywhere for content or context. But as you alluded to, URLs correct that somewhat. However, in my view, readers are still lacking necessary context, as a URL is only a primary source for information about itself, without providing broader context for readers to discern whether the source they are reading is reliable. Unless a source is deprecated or blacklisted, any URL can be added. Also a lot of cited news sources have generic names (“Gazette”, “Herald”, “Star”, “Record”, “Mirror”), often cited without the added context needed to disambiguate, such as location. I understand the argument here is that the bot should not be making the decision to add reflinks, but this is what I find to be true at least with regards to best informing readers. Οἶδα (talk) 22:23, 4 April 2025 (UTC)
    I also find it interesting that WP:CITEVAR states: "The data provided should be sufficient to uniquely identify the source, allow readers to find it, and allow readers to initially evaluate a source without retrieving it." How does one "evaluate a source without retrieving it" in the absence of further context or content? Οἶδα (talk) 05:18, 5 April 2025 (UTC)
    If it were the case that a link is needed to uniquely identify a source or to evaluate it, then the MOS would already insist on the need for such links. It doesn’t and instead leaves the question down to editor discretion at the level of individual articles. If you wish to claim that this is the only was to identify or evaluate a source, then you’ll need to open an RfC to change the MoS to do just that. - SchroCat (talk) 05:56, 5 April 2025 (UTC)
    I was not claming that MOS:REPEATLINK prescibes reflinks as mandatory. I was merely quoting a guideline whose choice of words I found interesting in the context of what I emphasized above. You are correct though, this would require an RfC. Οἶδα (talk) 08:19, 5 April 2025 (UTC)
  • Option 2B, or second choice 2D, per Headbomb, Sdkb, Thryduulf and Οἶδα. I’m particularly unconvinced by the argument that as MOS:REFLINK permits non-linking, the bot should never be allowed to do anything better, and that if it does “people will (rightly) revert”. The MOS no more says it's right to unlink than it does to link. Convenience links to newspapers and other works are extremely useful, and that utility is in my view far more important than trying to enforce essentially trivial internal consistency within a single article's source formatting. The difference, after all, is merely that the names of some works within sources may appear in blue, and some may not. So what? In the longer term, we'd serve our readers better by gradually moving towards linking all works where possible. MichaelMaggs (talk) 11:10, 4 April 2025 (UTC)
    If you wish to rewrite the MOS to insist on links, then you will need to have the discussion there to change it. At present it does not require links to be linked or unlinked: it is down to the consensus of editors at each individual article. Trying to force the issue by having a bot do it is a form of back-door instruction creep by proxy. - SchroCat (talk) 11:17, 4 April 2025 (UTC)
    Bots are permitted to do whatever the community authorises them to do, in discussions such as this. Their actions must be consistent with the MOS, yes, but few would be able to operate if they could do only what is specifically insisted upon by the MOS. We're not addressing here what individual editors must or can do; only what authorisation the bot should have to do something that is generally permitted by the MOS. MichaelMaggs (talk) 11:47, 4 April 2025 (UTC)
    As I've said, it's a back-door instruction creep by proxy. If this rather disruptive measure passes, I don't look forward to reverting these when I see them, but will do so. - SchroCat (talk) 12:00, 4 April 2025 (UTC)
    You have voiced your opinion and it is well-understood. To be clear though, you reverted the bot wholesale, which included the main edit it was performing (migrating The Times URLs). Such a reversion would be disruptive. Οἶδα (talk) 20:41, 4 April 2025 (UTC)
    MichaelMaggs, you say that REFLINK doesn't imply that bots should not link; I'd like to ask you more about that. If one of two options is allowed by the MoS, but the community authorizes a bot to always apply one of those two options, that clearly doesn't contradict the MoS, but doesn't it effectively implement one of those two options to the exclusion of the other? I think the issue here is whether the assertion in the MoS that something is up to editor discretion implies that it should not be changed globally (that is, it should be decided at the individual article level). Do you see this differently? Mike Christie (talk - contribs - library) 14:54, 4 April 2025 (UTC)
    Yes, if what the bot is doing is authorised globally. The point of this discussion is to determine that. MichaelMaggs (talk) 15:31, 4 April 2025 (UTC)
  • Option 2A (second choice option 1). Linking works should not be automatic -- that is antithetical to MOS:REPEATLINK. If the work is referred to repeatedly in the article, it will create unhelpful overlinking. Instead, linking should be a decision made by the editors at each page. -- Ssilvers (talk) 14:11, 4 April 2025 (UTC)
    References are not the article. If I click on reference 3, I want a link in reference 3. If I click a link on reference 49, I want a link in reference 49. That it's linked in reference 3 is irrelevant. Headbomb {t · c · p · b} 15:11, 4 April 2025 (UTC)
    One could make the same strawman argument about wikilinks in general, but we don't link everything, everywhere. - SchroCat (talk) 15:36, 4 April 2025 (UTC)
    Wholly concur with SchroCat. A modicum of common sense is wanted here. Tim riley talk 18:02, 4 April 2025 (UTC)
    @Ssilvers: To be clear, what you said is not correct. As I stated above, and which is actually quoted in the OP, reflinks stand alone in their usage with regards to overlinking. Whether the bot should do it is another argument which is already being discussed here. But it is not correct to suggest this is antithetical to MOS:REPEATLINK. What you are referring to is the guideline for links within article sections, not for citations. Οἶδα (talk) 21:31, 4 April 2025 (UTC)
    To be clear, what you are saying is not correct. It is not necessary or helpful for refs to link the names of works again and again, no matter how many times you repeat that you like it. -- Ssilvers (talk) 00:31, 5 April 2025 (UTC)
    Okay I'm not sure what we're doing here. Yes, I have voiced support for reflinks in this discussion. It appears I misunderstood what you wrote here and for that I apologise. You stated rather forthrightly that repeat links constitute overlinking, but then stated that it is up to consensus. I understood "overlinking" not as a general reference to an article's "citation style", so I again apologise for misunderstanding. No need for snark. Οἶδα (talk) 04:19, 5 April 2025 (UTC)
  • Option 2A (second choice option 1). Linking publications/publishers should not be automatic. We have WP:CITEVAR for a reason; it's disruptive to force a certain citation style using a bot. I had a situation with an article several months ago where there was some controversy over the linking of publishers for book citations; I see no reason why |work= can be thought to be exempt from such differences in opinions. With citation formatting, it is much better to allow human flexibility than to force-format things a certain way with a bot. We should be deferring to human judgment here. This proposal honestly feels like a backdoor attempt to force a certain citation style across a wide range of articles, contrary to common sense. Hog Farm talk 20:11, 4 April 2025 (UTC)
    It is clear the issue is boiling down solely to WP:CITEVAR. So I must ask, to what extent are reflinks actually considered part of a specific "citation style", meaning that they can become part an article's established and consistent stylistic choice, one that must be deferred to and adhered to, with any addition/removal seen as an undue disruption warranting reversion? When I think of WP:CITEVAR, I think of everything outlined at Wikipedia:Citing sources: full citation, short citation (Harvard, MLA), general references, templates, no templates, citation order, etc. Not the "variation" of whether there are reflinks or not. Could an editor also be reverted for adding an author link to a citation because it is not "consistent" in the article or because the most significant contributor of the page decides it goes against their personal/established preference? This seems like a possibly misguided cross-application being that it is not unambiguously supported by WP:CITEVAR or consensus elsewhere. Otherwise, if they are considered a component of "citation style" or the ambiguity skews toward that interpretation, then I suppose 2A really would have to be the way to go. At least until the bot can account for an article's prevailing practice. Οἶδα (talk) 05:26, 5 April 2025 (UTC)
    The broader MOS:VAR indicates: "Sometimes the MoS provides more than one acceptable style or gives no specific guidance. When either of two styles is acceptable it is generally considered inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change...Unjustified changes from one acceptable, consistently applied style in an article to a different style may generally be reverted. Seek opportunities for commonality to avoid disputes over style. If you believe an alternative style would be more appropriate for a particular article, seek consensus by discussing this at the article's talk page or – if it raises an issue of more general application or with the MoS itself – at Wikipedia talk:Manual of Style." With regards to the matter of wikilinking works within references, MOS allows but does not require this be done, bringing VAR into play. Nikkimaria (talk) 13:58, 5 April 2025 (UTC)
    @Οἶδα: Try running an article with inconsistent linkage through FAC and you'll probably see where this gets sticky. Hog Farm talk 17:00, 5 April 2025 (UTC)
    Then an RfC would be appropriate. I understand that the MOS leaves the door open to variety, but this does not appear to be a very common or contentious phenomenon on Wikipedia and as such this exact point does not seem to have been deliberated much before. If such a discussion exists, I cannot find it. In the absence of such discussions, it's hard to not bring these aspects up because CITEVAR is being cited as if a community consensus was determined to remand the issue of reflinks in citations to individual consensus. Rather than a general application of MOS:VAR. Was there ever a discussion to determine consensus for a large-scale disruption of established citation styles by the addition/removal of reflinks? I don't believe so. Again, it's not a very common or contentious phenomenon, nor have I seen bots performing these additions which would trigger such discussions until now. If this discussion indicates anything it is that the community would like a consensus on reflinks, and apparently we are not going to have it through a decision about this bot. There is enough ambiguity with WP:CITEVAR as it makes no prescriptions for reflinks (literally no mention whatsoever) nor does it confirm that reflinks are an established component of an article's "citation style", which is what I was referring to above. Οἶδα (talk) 23:18, 10 April 2025 (UTC)
  • 1 or 2a: per above, and WP:CONLEVELS -- a discussion as to how to programme a bot shouldn't override the MoS, which is to leave this up to individual discretion. We already see good-natured but time-consuming bot edits from various bots which are, by their nature, unable to understand the citation practices established in an article (WP:CITEVAR), and end up acting in ways (such as repeatedly editing an article to change its established citation style) which would see a human editor criticised or sanctioned. 2B, 2C and 2D would all make this problem worse. UndercoverClassicist T·C 20:21, 4 April 2025 (UTC)
    So then if a bot was hypothetically able to determine the "citation practices established in an article" by assessing whether the citations fully or at least consistently (greater than 50%) included reflinks, you would endorse it? Οἶδα (talk) 22:47, 4 April 2025 (UTC)
    It would be easy for the bot to determine a prevailing practice of reflinks: parse all the templates and count how many have links. A bot could be more aware and consistent of prevailing practice than humans. BTW in all my years making millions of edits, not a single editor has ever complained of an edit war, it's not that kind of bot constantly running unattended across 6 million pages. It's targeted based on requests for certain domains only, and I don't usually repeat the same domain. -- GreenC 00:32, 5 April 2025 (UTC)
    I suspect that's because 2B, as you note at the top, includes the conversion of the domain name to the work name, which is a useful thing to do, and because it's relatively low volume. If I had seen one of those edits on an article for which the link contradicted an established consensus, I would not have reverted; I'd have just unlinked. Mike Christie (talk - contribs - library) 09:30, 5 April 2025 (UTC)
  • Option 2B or 2D: as other editors above have highlighted, linking within sources can be useful; I don't think whether or not something is linked is really an citation style issue so much as many editors use automated tools for creating citations to save time which may or may not include a link for them leading to inconsistency. The fundamentals of the citation format doesn't change (ie. WP:LDR vs in-line with the visual editor) by improving existing citations with links. I've mostly seen requests for consistency (ie. either all sources link or all sources don't link) in good/featured article reviews so having an option for the bot to convert one direction or the other on demand would be useful. Sariel Xilo (talk) 21:20, 4 April 2025 (UTC)
  • GreenC, would it be possible for the bot to include an option for the requesting user to ask for all links, no links, or as you suggested above to follow the prevailing practice? That would ensure that the decision is always left to editor discretion rather than being a bot default. MichaelMaggs (talk) 04:01, 5 April 2025 (UTC)
    eh? It wouldn’t be editor discretion, would it? That would be a single editor’s personal preference enforced across several hundred or thousand articles at any one time, regardless of the local consensus at each individual page. - SchroCat (talk) 04:11, 5 April 2025 (UTC)
    With such an option, the editor has discretion to instruct a globally approved bot to follow existing prevailing practice on every page, in perfect compliance with the MOS. Though I’m not expecting that even that will be enough to change your mind, it does at least dispose of all the arguments you have enunciated thus far. MichaelMaggs (talk) 08:26, 5 April 2025 (UTC)
    Sorry, but that's nonsense, and it disposes of absolutely nothing. If there is "an option for the requesting user to ask for all links", it enables a single editor to overrule the status quo on hundreds or thousands of individual pages. That's ridiculous. It would be akin to an editor ordering a bot to add (or remove) every serial comma to their own preference, or change language parameters - not just to one article but to thousands. And that's before you even think about what happens when Editor A asks for links to be added and Editor B comes along with the next request and exercises "an option for the requesting user to ask for ... no links" - ie, asking for them to be removed? This isn't a question that can be determined by this RfC - it would need a more fundamental change of the MOS before it even comes close to this. - SchroCat (talk) 08:37, 5 April 2025 (UTC)
    If I understand correctly, you're not objecting to Option 3: the bot is changed so that it always follows existing prevailing practice on every page. MichaelMaggs (talk) 09:14, 5 April 2025 (UTC)
    There is no option three at present. - SchroCat (talk) 09:26, 5 April 2025 (UTC)
  • I propose the discussion of a new Option 3A: that the bot is changed so that it always follows the existing prevailing reflink practice on every page. GreenC has stated above that this would be easy to program, and it avoids the objection of some contibutors that the editor who instructs the bot could potentially be overriding local page consensus, where that exists. MichaelMaggs (talk) 11:11, 5 April 2025 (UTC)
    I think we should have a clear definition of what the set of "existing prevailing reflink practices" are before this can be considered. Also, a problem I see is that if the practice is being consistently followed already at a given page, there's nothing for the bot to do; and if it's not being consistently followed, it can't determine what the prevailing practice is. It would not be OK to then assume there is no prevailing practice, since a recent edit might have rendered the page inconsistent and not yet been reverted. Mike Christie (talk - contribs - library) 11:29, 5 April 2025 (UTC)
    I am a bit confused by the different uses of "prevailing practice" and "consistently followed" here. I believe you're saying local page consensus might not be reflected in the current revision of an article due to a recent edit. Yes, each article can have their own documented consensus for reflinks and the bot needs to account for that. But in reality, they typically do not. It hasn't exactly been a very common or contentious phenomenon from what I can find. An article's current makeup should be enough for the bot to run. If a revert is already needed then the bot can be reverted as well, at which point the bot will not perform that same edit. If anything, I was more wondering if the bot could account for pages where the reflink style is MOS:LINKONCE. Without mistakenly linking twice, for example. Οἶδα (talk) 05:27, 7 April 2025 (UTC)
  • 2D Per Dhtwiki, when the work is wikilinked, I immediately know that the source is notable, and I can read its article to determine reliability before heading off-wiki. When the work is simply a URL, I am potentially left confused between sources with similar names or wary of heading to an unfamiliar site. When MOS:REPEATLINK exists to avoid a sea of blue in the article text, I agree with GreenC that the current guideline that "citations stand alone in their usage" justifies this new wikilinking function. While I can understand requesting the bot to not wikilink in citation templates that do not support it, the appeal to WP:FACRITERIA is maddening. WP:CITE's discussion of consistency in citation styles explicitly refers to the big choices over templates, not whether some works are wikilinked and some are not, even stating that "the data provided should be sufficient to uniquely identify the source, allow readers to find it, and allow readers to initially evaluate a source without retrieving it." Thanks for maintaining this useful bot work, GreenC! ViridianPenguin🐧 (💬) 16:05, 5 April 2025 (UTC)
  • 2B My personal preference would be 2A, as I dislike the sea of blue that overlooking in references can cause. However other editors appear to find such linking useful, and my distaste of it is not enough to impede other editors. The flip side of that though is that high volume edits such as 2C/D also impact editors, so the lower volume of 2B seems like a sensible compromise. -- LCU ActivelyDisinterested «@» °∆t° 20:44, 5 April 2025 (UTC)
  • 2A per comments above. If someone prefers the "link each one" style, go for it, but the default bot-level option should be the safest option. If a reader is curious about a reference, we generally want them to click on a URL of the article itself, not an article about the work it was published in. There are times when adding such links is good, but let humans do that, not bots. SnowFire (talk) 04:11, 7 April 2025 (UTC)
  • 2B In a multicultural English language encyclopedia, linking to the Wikipedia article for the publication is a benefit for users of this Wikipedia. I know it would be for me when I check a citation to an unfamiliar publication. — Neonorange (talk to Phil) (he, they) 14:53, 8 April 2025 (UTC) —
  • 2B Others have said it better, but I think having the publisher linked to its WP article is good for the encyclopedia, even it I personally don't do so consistently when creating citations. - Donald Albury 15:52, 8 April 2025 (UTC)
    There is no option to link to the publisher and no-one has suggested that would be a beneficial step. That is not what this RfC is about at all! - SchroCat (talk) 04:26, 9 April 2025 (UTC)
  • 2B citevar is not an excuse for avoiding doing something that has a clear, tangible benefit to any reader. PARAKANYAA (talk) 02:32, 9 April 2025 (UTC)
  • 2D or 2B. Wikilinks are very useful in giving context to the citation. I've also found that when the values aren't linked, then there are often times typos in his field which are left uncaught because they aren't linked.
Gonnym (talk) 07:20, 9 April 2025 (UTC)
The issue you are complaining about won't be resolved by a bot adding wikilinks to correctly spelt titles. Traumnovelle (talk) 09:26, 11 April 2025 (UTC)
Yes they would. Linked redirects that are tagged with {{R from misspelling}} appear on Wikipedia:Database reports/Linked misspellings, which then can be fixed. Gonnym (talk) 07:57, 13 April 2025 (UTC)
The bot wouldn't add wikilinks to misspelt names unless it was coded to recognise them, in which case it may as well just fix the spelling. Traumnovelle (talk) 23:07, 13 April 2025 (UTC)
  • 2A definitely oppose 2C/2D. I've only ever once clicked on a wikilink to a work in a reference and it was an accidental click when I was aiming for the url. I have never found these useful, some readers may find them useful but I do not believe their usefulness justifies the the enormous amount of edits this bot would be undertaking to do so. Traumnovelle (talk) 09:23, 11 April 2025 (UTC)
  • 2B – everything should be wikilinked. As Wikipedians, it should be obvious that wikilinks are useful – I use wikilinked source names all the time, for instance when trying to figure out the ownership and biases of the many Hong Kong newspapers. The easiest, most consistent, and only sustainable solution is to link every reference. Linking the only first instance means that whenever the reference order is changed (a very common occurrence) the link has to be moved, which is busywork that nobody should actually bother doing. Toadspike [Talk] 09:30, 11 April 2025 (UTC)
  • 2D with the exception of not converting |work=[url name] to a wikilink. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:28, 11 April 2025 (UTC)
2B - as a reader, my preference is for the work to be wikilinked whenever it can be. This link leads me to an article where I can learn more about the publication and its reliability, which is a crucial and core service of Wikipedia. Helping readers assess the reliability of a work helps readers assess the reliability of a citation and thus the accuracy of a Wikipedia article.
The URL to the work is not a substitute for information about the publication; more information about the publication will often be available in a Wikipedia article about the publication than on the publication's own website (which will inevitable have a pro-publication bias).
Wikilinking the work field in every reference is important, even though that results in repeated wikilinks in the reference section. To understand why, first remember that the vast majority of readers read on a mobile phone. Next, take out your phone and browse (in default mobile mode, not desktop-on-mobile mode) to any article and click on any reference. Note how it just shows you the one reference you clicked on--it doesn't take you to the references section the way desktop mode does. If that one reference you clicked on doesn't have the work wikilinked, you won't see another wikilink on your screen. Even on desktop mode, in articles that have hundreds of references (which most highly read articles do), if the one you clicked on doesn't have a wikilink to the work, it can be hard to find that link amongst the hundreds of other references listed. For both mobile and desktop users, it's important that the work field be linked in every citation. Levivich (talk) 15:46, 13 April 2025 (UTC)
  • 2A would be preferable to prevent further fighting. I appreciate the attention to cleaning up citations, but it would be jarring to introduce linking inconsistency to an otherwise stable article, all at the hand of a bot without a human to sign off on every edit. SounderBruce 00:10, 14 April 2025 (UTC)
  • 2B I find these links useful, especially for lesser known publications. Helps to click them into new tabs quickly especially when reviewing an article, rather than searching for each name individually. seefooddiet (talk) 03:14, 22 April 2025 (UTC)
  • 2B weakly (as it's generally useful, but not all articles that the link might go to are of equal quality), but I do object to the idea that a reversion of the wikilink added by bot could be seen as disruptive based on this RfC outcome. There is a difference between developing a consensus that says it's fine for a bot to add a link in the reference as it's usually more useful than not, rather than having a consensus that states that references should have a link. We are discussing the former, as the RfC question isn't formulated to address the latter and I also don't see the necessary advertising of the RfC (i.e. notifications to relevant MOS pages). In practical terms, anyone who wants to revert the bot addition would merely need to make a reasonable case that the link doesn't benefit the article (BRD) rather than meeting the bar of being an exception to something that editors should "generally follow" as defined in a community endorsed guideline. Scribolt (talk) 07:57, 23 April 2025 (UTC)
  • 2A to make the references more human readable, but do not indiscriminately add wikilinks by bot without general agreement on citation style. —Kusma (talk) 12:38, 23 April 2025 (UTC)
    It occurs to me that this would change |work=whitehouse.com and |work=whitehouse.gov to the same |work= parameter; they used to be very different. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:56, 23 April 2025 (UTC)
  • 2B: MOS:REFLINK allows it so the bot should do it. It's rote grunt work that human editors might not do out of time, so it's the right job for a bot. The whole point of Wikipedia is to be an encyclopedia of hypertext so we should use as much of it as makes sense. Sure it might run afoul of CITEVAR one way but as long as a bot is fixing bad citations, it's better to go overboard than underperform its task. Dan Leonard (talk • contribs) 19:37, 28 April 2025 (UTC)
  • 1 or 2A, and I am strongly opposed to 2C or 2D. Bots should aim for minimal disruption, wikilinking every periodical title is generally distracting and unhelpful but the links can be left if they are an established convention on some page where the local editors prefer them. Bots should not be otherwise disrupting established styles on other pages where non-linked names are preferred or where the links are added by discretion. –jacobolus (t) 16:34, 8 May 2025 (UTC)

The recent changes, related changes and watchlist are able to show 1,000 items. But in order to do that, one has to manually modify the URL. I suggest that there be added "1,000 changes" links to these pages so that one more easily can watch 1,000 changes. Utfor (talk) 20:59, 26 April 2025 (UTC)

  • I also suggest a similar link for What Links Here. Utfor (talk) 21:06, 26 April 2025 (UTC)
    @Utfor, tell me what you're trying to accomplish, that you actually need a thousand articles/edits on your screen at the same time. WhatamIdoing (talk) 21:35, 26 April 2025 (UTC)
    I have a use for 1,000 changes... primarily because my Watchlist covers only the last 8-10 hours at 500 changes. – robertsky (talk) 14:41, 27 April 2025 (UTC)
    There's times I've had to do the maximum changes in separate namespaces too. It can be fiddly. CMD (talk) 15:23, 27 April 2025 (UTC)
    Are you showing all edits separately, or just the most recent, and then going to the history page? During the last week, about 200 pages on my watchlist have had changes, but since I have turned off all the verbose options (like "Expand watchlist to show all changes, not just the most recent"), I can easily see all of them. WhatamIdoing (talk) 17:05, 27 April 2025 (UTC)
    Of course only the most recent, showing all is the way to madness. CMD (talk) 17:27, 27 April 2025 (UTC)
  • You can set watchlist to 1,000 days in your preferences, which adds 1,000 days to the display options in your watchlist filter. Schazjmd (talk) 14:20, 27 April 2025 (UTC)
    That's not very effective if you have many items in your watchlist and/or some have been very busy. I've found I need to set the URL to 1,000 changes to look back a week or two. NebY (talk) 14:55, 27 April 2025 (UTC)
    If you disable "Expand watchlist to show all changes, not just the most recent", then each page will be one line in your watchlist, no matter how many edits have been made recently.
    You can also use the "Unseen changes" filter to hide the pages you've already visited. That will let you check a bunch of edits, and then reload to see additional/older ones. WhatamIdoing (talk) 17:33, 27 April 2025 (UTC)
    Whether all changes to a page are shown as one line (yes, I already use that) or many, only the stipulated number of changes are loaded. The number of pages doesn't affect that. If we set it to 50 changes and the latest page has 49 changes, only 2 pages will be displayed. Visiting each page isn't workable, though hovering to see changes is. Of course, the filters can't respond to hovering. NebY (talk) 19:48, 27 April 2025 (UTC)
    I don't think that's true. I just set my watchlist to 10 (because that's easier to count than 1,000). It shows 10 pages, not 10 edits. Your two back-to-back edits to this page, for example, are counted as one entry in the watchlist, even though it's two edits. WhatamIdoing (talk) 20:03, 27 April 2025 (UTC)
    I have mine set to 50 now and it shows 16 pages, with 1, 2, 7, 7, 1, 9, 6, 1, 3, 1, 1, 2, 4, 1, 1 and 2 edits respectively. NebY (talk) 22:00, 27 April 2025 (UTC)
    I have everything off in Special:Preferences#mw-prefsection-watchlist-advancedwatchlist. I also have everything off in the similarly named section under the Recent Changes tab. How about you? WhatamIdoing (talk) 22:52, 27 April 2025 (UTC)
    You clearly use your watchlist differently; I would not find it useful to leave "Expand watchlist to show all changes, not just the most recent" unchecked and do use the markers. NebY (talk) 14:13, 10 May 2025 (UTC)
    Yes, instead of checking each individual edit in the watchlist, I check each edited page via its history. It makes sense for the limit to count whether you want edits vs pages. The "pages" setting will obviously result in more edits being shown. WhatamIdoing (talk) 17:45, 10 May 2025 (UTC)
  • User:WhatamIdoing Viewing the watchlist after a Wiki Break will be more useful for editors with a huge watchlist. Relatively small wikis, e.g. no.wiki, with lower edit rates are set up to make it possible to patrol all edits, not just new pages as on en.wiki. As known, the recent changes page hasn't got a "next page" button. (I know that unpatrolled edits may be hidden, which will bring more edits up on the list, but sometimes, one might be in doubt and choose not to patrol an edit, then it will be easier to find additional edits to check.) I forgot to suggest a "1,000 edits" link in page history, for making it easier to download or print a large page history. Utfor (talk) 20:25, 27 April 2025 (UTC)
    Presumably, the actual patrolling of edits should be done at a page such as Special:PendingChanges, rather than at Special:RecentChanges or Special:Watchlist. I don't see any mechanism set up for that at w:no: WhatamIdoing (talk) 21:05, 27 April 2025 (UTC)
    Special:RecentChanges is useful for patrolling changes in lesser used namespaces, even on busy projects. — xaosflux Talk 21:10, 27 April 2025 (UTC)
    Yes, but that's not a case of nowiki being "set up to make it possible to patrol all edits". WhatamIdoing (talk) 21:21, 27 April 2025 (UTC)
    For interested parties....
    This piece of JavaScript does the job of setting the limit=1000 parameter.
    javascript:var url = new URL(location.href); url.searchParams.set('limit', '1000'); location.href = url;
    Utfor (talk) 23:34, 9 May 2025 (UTC)

Double redirect creation

Tracked in Phabricator
Task T393825

When I attempt to create a double redirect, I am prompted to manually change the target as specified. Why cannot this be done automatically, by checking a checkbox, like what happens when I try to save a page that was deleted after I clicked the Edit Tab, i.e. while I was editing it? (I assume it can, so I propose it here.) Utfor (talk) 00:53, 10 May 2025 (UTC)

The simple answer is that the code to do this has not been written. That obviously prompts the follow-up question, "why?" and I don't know the answer to that, but it's possible that nobody has ever thought of it (the warning only went live in February this year so its still new). I think Phab:T315016 is related, but I'm not sure it's quite the same so I'll create a new phabricator task. Thryduulf (talk) 01:06, 10 May 2025 (UTC)
I've now created that ticket as Phab:T393825. Thryduulf (talk) 01:32, 10 May 2025 (UTC)
Thank you. Utfor (talk) 02:09, 10 May 2025 (UTC)
In response to the dev's comments on that Phabricator task suggesting that implementation as a software feature might be complex but that it could be implemented as a JavaScript gadget, I've now requested such a gadget at Wikipedia:Village pump (technical)#Gadget request: Button or link to fix double redirects at creation. Thryduulf (talk) 11:50, 13 May 2025 (UTC)

Allow Baidu baike references to get past the edit filter

I often make articles about Chinese topics, which often involve tonnes of dead links.

Now, I do agree that Baidu Baike is generally unreliable (though I have used it in a similar manner to how schools use wikipedia to find leads), there is a certain use. You see, when a reference is added on Baidu Baike, the web page is screenshotted and archived in a similar way to the wayback machine(Though it is a screenshot, not the complete page, this is still a very useful thing). The archive date is recorded down, and the original url can be accessed through blue text marked as 继续 (continue).

An example - https://baike.baidu.com/reference/8484809/533aYdO6cr3_z3kATPffnf7xMyjEM96kvryBBuFzzqIP0XOpT4-rSZJ859gpsPRpWzH8l7MtSvEvuKeEaTEy8Q (the Shenzhen police website)

I have actually began to use Baidu Baike reference pages in a similar way to the wayback machine, such as on Draft:List of Ministry of Public Security police officers killed in the line of duty, however I was still given an edit filter warning(despite the source itself being reliable) and had by edit marked as "use of deprecated sources".

I think that baidu baike references should be allowed to pass the edit filter since many chinese websites turn into dead links, and the wayback machine rarely archive them; Maybe we should allow urls with https://baike.baidu.com/reference/ to be able to pass the edit filter, while still blocking article pages (https://baike.baidu.com/item/). Thehistorianisaac (talk) 10:10, 7 May 2025 (UTC)

I would be extremely reticent to use a Baidu Baike link for an |archived-url= field, since anything under control of the Chinese Communist Party is subject to censorship if the political winds shift. The Wayback Machine allows you to specify specific links you'd like to archive, so I would suggest using that approach to archive the Baidu Baike screenshot and then use that. Sdkb talk 20:12, 7 May 2025 (UTC)
(If you're looking for an instance of Baidu Baike getting short shrift on Wikimedia, I'd point to this instead.) Sdkb talk 20:15, 7 May 2025 (UTC)
But it would still be deprecated. Citing an archive of a deprecated source is still affected by the deprecation. Also, it doesn't appear to work [1]. Internet Archive regularly takes stuff down as well, so I don't really see much issue with using the kind of reference. PARAKANYAA (talk) 22:25, 7 May 2025 (UTC)
If you open the image in a new tab, and archive that (https://baikeshot.cdn.bcebos.com/reference/8484809/5d10429a5fe6dfd3262af753d6a7800c.png@%21reference) both archive.org ([2]) and archive.today ([3]) work on it. The downsides are that it doesn't seem to catch the original archive date or the original URL, which is pretty important. ARandomName123 (talk)Ping me! 17:08, 8 May 2025 (UTC)
@PARAKANYAA@Sdkb My point idea isn't to use Baidu baike to Archive live links, we can use the way back machine for that, what i think the Baidu baike reference Archive can be used for is accessing links that are already dead. Thehistorianisaac (talk) 22:58, 7 May 2025 (UTC)
Just to note that the deprecation filter isn't the same as blacklisting, it's a warning message. You can add links to Baidu baike you just get warned when doing so. You also may have to explain why you're doing so and what the exception is, if you're asked. -- LCU ActivelyDisinterested «@» °∆t° 13:56, 9 May 2025 (UTC)
I understand, but it's just weird when I am only using it for archiving, not using it directly as a source. Thehistorianisaac (talk) 14:32, 9 May 2025 (UTC)
The filter catches the URL not how it's used. -- LCU ActivelyDisinterested «@» °∆t° 16:51, 9 May 2025 (UTC)
I know; Just saying i would rather it only catch urls for references, not archives thanks to this situation Thehistorianisaac (talk) 17:05, 9 May 2025 (UTC)
My point is that it doesn't even know if you are using it in a reference, adding it to an article in anyway is caught. It's not clever enough to know it's in a reference, let alone how it's used in that reference. So it would have to know it's a reference, and then that the link is being used as an archive, and then just for baidu baike. That seems a lot of work for a situation that can be bypassed by pressing 'post' again. -- LCU ActivelyDisinterested «@» °∆t° 17:16, 9 May 2025 (UTC)
My main problem is that it is marked my edit as "use of a deprecated source"; My main point is baidu baike reference urls should be removed from the filter Thehistorianisaac (talk) 17:22, 9 May 2025 (UTC)
There are no significant technical obstacles to allowing references only from Baidu baike. The deprecated source edit filter is clever enough to inspect the entire URL including its path. E.g. the filter currently warns for sciencedirect.com/topics because those page are AI generated while ScienceDirect itself is generally ok. Similarly the filter could only warn for baike.baidu.com/item/ and baike.baidu.hk/item/. The edit filter is in fact clever enough to use boolean operations e.g. to warn for everything from baidu.baike.xxx except /references. It's not a lot of work, just one or two lines of code. Joe vom Titan (talk) 12:09, 11 May 2025 (UTC)
Clarification: Baidu Baike has an in-house version of "internet archive". They are a search engine company after all and it works much like (now defunct) Google snapshot. Many websites, especially government-affiliated websites, actively block connections from outside China. This means that neither Internet Archive nor Archive Today can capture them. It seems that the OP wants to make Baidu Baike Reference Snapshots as an acceptable value for |archive-url= field, while leaving their articles in the filter. MilkyDefer 01:46, 10 May 2025 (UTC)
Yep that's what I'm saying; I don't know how to use the baidu baike snapshots, but I find them on their articles. It's not like the wayback machine can't archive them(really depends on which website it is and which page, though the vast majority of live links I have successfully archived), but the point is what User:MilkyDefer already clarified above; Thehistorianisaac (talk) 05:29, 10 May 2025 (UTC)
@Thehistorianisaac Your request seems reasonable and actionable. I suggest going to the Edit filter noticeboard and requesting this change to be implemented there. As Joe has mentioned above, we just need to adapt the URLs slightly. Toadspike [Talk] 17:44, 13 May 2025 (UTC)
The point of the |archive-url= parameter is to provide a link to a highly stable URL that will persist even if the URL itself goes offline. We absolutely cannot trust the Chinese government not to take URLs offline, so Baidu Baike links should not go in that field. This is a nonstarter. Sdkb talk 18:24, 13 May 2025 (UTC)
This is perhaps not an ideal archive of last resort and I would encourage editors to try to archive these sources elsewhere, as ARandomName has done above. However, there's no reason to generally ban the citation of otherwise reliable sources available only via a Baidu archive, which could then go into the |url= parameter, especially since the archive snapshots don't seem to include the original URL.
Sdkb, I encourage you to slow down with the political arguments; I have not yet seen any evidence that this archive is less reliable than other options, which also "take URLs offline" on a regular basis. Toadspike [Talk] 08:58, 14 May 2025 (UTC)
To be completely honest, I don't even know how to add stuff to the baidu archive, I am purely making this suggestion since I use it to view links that are already dead Thehistorianisaac (talk) 09:10, 14 May 2025 (UTC)
Ok thanks Thehistorianisaac (talk) 23:53, 13 May 2025 (UTC)

Short versions of newsletters

I subscribe to a number of newsletters (Tech News, Signpost, etc) that are delivered to my talk page by bots. My talk page archives are full of them.

I would prefer to simply receive a link to each edition, rather than the full text; effectively, what is seen in this diff.

What would need to be done to our existing tools, to make this an option? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:11, 6 May 2025 (UTC)

One method I (and many) use is to create a /Newsletters subpage of our talk and subscribe to that page. See mine for an example (I archive it after reading, so see that as well). This way, you can browse through without even archiving, but also not clutter your actual human-used main talk page. :) ~/Bunnypranav:<ping> 12:30, 6 May 2025 (UTC)
If you prefer to have it delivered to your main user talk page, you (or at least someone more skilled than me) could programme a bot to delete previous copies of a newspaper after the current one is delivered, e.g. when it sees that Tech News 19 has been delivered it will automatically delete (or archive) issue 18 from the talk pages of the people who have subscribed to it.
Ideally would be to build this functionality in to the mass message extension but a local bot is going to be the much quicker option. Thryduulf (talk) 13:31, 6 May 2025 (UTC)
I've seen some sort of subscription feature on Meta or another wiki that enables you to just get a notification for a new issue. Sdkb talk 21:07, 6 May 2025 (UTC)
@Sdkb: I think you're referring to the newsletter extension — it's in use on mediawikiwiki (mw:Special:Newsletters) but not on other projects (well, aside from testwiki). RAdimer-WMF (talk) 19:43, 8 May 2025 (UTC)
Yes, that's it! Is the ultimate hope for that extension to be rolled out to more wikis? Sdkb talk 19:47, 8 May 2025 (UTC)
WikiProject Yorkshire introduced the option for sending links rather than full newsletters in October 2021. The message (Wikipedia:WikiProject Yorkshire/Newsletter/Link Option) is updated for each issue and sent out using an alternative distribution list. EdwardUK (talk) 23:58, 6 May 2025 (UTC)
I believe that @KStineRowe (WMF) has spent some time thinking about the format for newsletters from the WMF.
Making the right choice is not a simple thing. For example:
  • If it's not placed in front of you, then the number of actual readers goes down. (Every click costs readers.)
  • But if everything is placed in front of you, then the number of actual readers of any given bit goes down. (TL;DR is the law of the internet.)
  • If only some things are placed in front of you then more people will read it, but the thing that "I" wanted to know about was omitted or condensed, so I missed it. (A maximum of five sentences per message has been recommended by various experts/consultants, but what if you have more than five things to talk about?)
In some cases, it's easy to prioritize the messages and reach the relevant audience. "All the bots will break next month" at Wikipedia:Bots/Noticeboard usually gets the relevant people's attention. But if you've got a hundred things to share, or even a dozen, and you're trying to reach a wide audience, then there are unavoidable tradeoffs.
Sometimes you can make the decision based on other factors. For example, if you want to be able to say "See? I announced this on a hundred pages", then you'll make it verbose. If you want instead to say "I know this message was read by a hundred people, because I've got more than 100 page views on this link", then you'll have a strong headline and a short message. And overall I'd say: You probably don't want to make the same choice every time. It's complicated. WhatamIdoing (talk) 23:03, 7 May 2025 (UTC)
Hi WhatamIdoing! As you note, this is something we've been thinking about. The Wikimedia Foundation Bulletin is the primary example here, where we aggregate WMF communications/events/announcements/etc. twice a month. This section's raised some interesting thoughts about the amount of newsletters / options for shorter notifications, which I'll be sure to follow. Best, RAdimer-WMF (talk) 20:07, 8 May 2025 (UTC)
What is used to do that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:02, 14 May 2025 (UTC)

New CVU task force idea

So, I've been part of the Wikipedia:Counter-Vandalism Unit for a while and recently have seen the amount of Wikihate and policy violations in contentious topics.

I have a new idea for a CVU task force: the Peacekeeping task force.

What it does:

The "peacekeeping task force" does exactly what it's name implies. Just like recent changes patrol check new changes, the "peacekeeping task force" monitors contentious topics(especially recent topics) that may likely have edit warring are civility in the talk page. Thehistorianisaac (talk) 14:20, 28 April 2025 (UTC)

But we have truly horrific experiences with "peacekeeping" and "peacekeepers" in the real world; the most infamous example is probably sexual abuse by UN peacekeepers. Polygnotus (talk) 05:38, 29 April 2025 (UTC)
Yeah, I know about that
just could not find a good name Thehistorianisaac (talk) 05:49, 29 April 2025 (UTC)
Rather than a task force, which implies a temporary function, how about requesting/encouraging admins to take a, you know, administrative role in such circumstances as they pop up? Admins get the big money after all, right? Perhaps, for example, they can post a (new?) administrator-derived template on the relevant article Talk page(s) notifying contributing editors about contentious topics, civility, WP:TPG, etc., which can serve as an "official" notification of said issues to everyone involved in the discussion, particularly the first-time IPs that descend upon Talk pages in response to Outrage! and Censors! canvassing threads on Reddit/Twitter/Myface/whatever. At a minimum it would provide an "Admins Are Watching" notice that could help keep temperatures a bit lower in many discussions. Maybe. It would, however, require administrator buy-in. JoJo Anthrax (talk) 13:14, 29 April 2025 (UTC)
Yeah more admin interventions is always the best. Unfortunately, in many of these cases it takes some time for admins to be involved. Thehistorianisaac (talk) 13:20, 29 April 2025 (UTC)
That's an implicit element in my plan - the amount of time required for a task force to become involved. It shouldn't take a single member of the admin corps any longer than a group of editors to respond, if anything it should be a shorter response time. All predicated, of course, on administrators' willingness to perform that simple task. That might be too big an ask. JoJo Anthrax (talk) 14:34, 29 April 2025 (UTC)
  • A WikiProject can set up whatever taskforces or subgroups it wants, whenever it wants, so you don't need to discuss this here.
  • The problem you're looking at probably needs people with tons of time and skills in the "making people feel like someone listened to them, understood their problem, and sympathized with them" category. That particular skill is ...maybe not in great supply in the community.
WhatamIdoing (talk) 04:18, 1 May 2025 (UTC)
...because that is super difficult via text on a screen. Polygnotus (talk) 06:18, 1 May 2025 (UTC)
Also, people who like editing Wikipedia don't necessarily care much about other people's feelings. We're not mean, but we're more interested in Just the facts, Ma'am than in Tend and befriend behaviors. WhatamIdoing (talk) 06:40, 3 May 2025 (UTC)
I care deeply about other people's feelings; I just don't think we should base encyclopedia articles on them. Polygnotus (talk) 06:47, 3 May 2025 (UTC)
the folks most willing to sign up to deal with policy violations and rage in CTOP areas would need to be folks who can stay "neutral" in an area where nobody can agree on neutral.
The parameters for this need to be defined well. Are we mostly policing IP/newbies causing vios? Are folks who are already active and non-neutral in the CTOP area the best candidates? Bluethricecreamman (talk) 04:26, 1 May 2025 (UTC)
Outside editors are very useful in CTOP areas, however designating a group of editors as the official outsiders (even administrators must be wary of INVOLVED) is probably not something that works with our community ethos. CMD (talk) 05:38, 1 May 2025 (UTC)
In the real world, peacekeepers are mostly effective when the parties to the conflict agree that peace is necessary and are willing to enforce discipline on their own sides.
As a frequent editor in the Israel-Palestine topic area, that hasn't happened yet. We need a set of rules to bind editors before we can begin enforcing them. Chess (talk) (please mention me on reply) 20:25, 15 May 2025 (UTC)

Real warning on stale drafts

There's a bit of overefficiency currently going on. Draft articles that are over 6 months since their last edit are eligible to be deleted as stale. When User:DreamRimmer bot II sees a draft that meets that criteria, it slams the appropriate deletion tag on the article in question, then posts a nice message on the page creator's talk page, telling that the draft has been tagged for deletion, and if they want to continue working on the draft, they can a) either do a little editing now; or b) if the article has already been deleted, ask for it to be restored. Thing is, a) almost never happens in my experience, because once the draft has been so tagged, it is quickly deleted. (The example message linked above was posted at 17:26, 18 May 2025, and the deletion occurred at 18:54 -- basically an hour and a half later.) Unless one is constantly hovering on Wikipedia (and it seems to me that many of the articles in draft are from more casual users), this isn't enough warning to expect a) to take place. This requires exercising option b), which while it is relatively technically easy, not only requires and administrator's time but the user is told they are going to be dealing with an administrator. Now, you and I may know that all administrators are warm and kind folks with great mustaches (if, in some cases, merely honorary great mustaches), but to people who are not used to dealing with such things, this may feel like being sent to the principal or having to ask for the manager, intimidating to at least some.

DreamRimmer bot II clearly has the tools needed to find drafts that have not been edited in X amount of time and to post a message on the draft creator's talk page, as that is a subset of what it is doing after 6 months. (pinging @DreamRimmer: this is correct?) If we also set it to, after 5 months, post a message that the article will be deleted if it's not edited within the next month, that will skip this problem and should encourage in many cases actual progress to getting a usable article. (I am open to other methods of effectively warning, of course.) -- Nat Gertler (talk) 02:16, 19 May 2025 (UTC)

User:FireflyBot should already do that. I'm not sure why it didn't here - possibly because FireflyBot and DreamRimmer bot disagree over whether notifying indefinitely blocked users is a good idea. * Pppery * it has begun... 02:20, 19 May 2025 (UTC)
Is that a relatively new thing? Because part of what I'm going on here is the same thing having happened to me, but that was a few years back. (I've never been indefinitely blocked.) -- Nat Gertler (talk) 02:34, 19 May 2025 (UTC)
It's been around for a while, but the bot has repeatedly died and needed to be restarted (often by a different operator) so it's possible your memory is in one of the gap periods. * Pppery * it has begun... 02:38, 19 May 2025 (UTC)

Abortion terminology

I've noticed over the last few months that to describe a person's views on abortion on Wikipedia, there are two available terms: "pro-choice" and "anti-abortion." I hardly ever see "anti-abortion" or "pro-life." I myself am steadfastly pro-choice, but I feel that discrepancy paints people opposed to an abortion in a more negative light. Being in favor of "choice" sounds better than being against abortion. Therefore, I propose that we stick to either of these pairs: "pro-choice" and "pro-life," or "pro-abortion" and "anti-abortion." Then again, this is just an observation; I don't have any precise data to back this up. DannyRogers800 (talk) 00:24, 15 May 2025 (UTC)

I wouldn't be surprised if there are some rfc:s/discussions on this somewhere, but I don't know where they are. Gråbergs Gråa Sång (talk) 15:03, 15 May 2025 (UTC)
Quick search found two discussions related to this wording question: an AE action appeal and article talk page, "Anti-abortion or pro-life?" Schazjmd (talk) 21:34, 15 May 2025 (UTC)
Talk:Anti-abortion movements/FAQ has good text as well. Anomie⚔ 23:29, 15 May 2025 (UTC)
Anti-abortion advocates are most definitely not pro-life. If they were actually pro-life they would want the woman to have prenatal care. They would want the child to have food, shelter,and education. But their interest stops as soon as it leaves the birth canal. The term "pro-life" is Orwellian doublespeak. --User:Khajidha (talk) (contributions) 15:54, 15 May 2025 (UTC)
Then there are people like me pro-choice anti-abortion. I believe that the government should allow abortions but remove as many as possible of the factors that make an abortion necessary with such measures as:
  • Free prenatal and neonatal care.
  • Free day care
  • Free birth control
  • Expedited but thorough screening for adoption, and support for adoptive parents
I'm sure that there are many things along those lines that they would support if they truly were pro life. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:55, 15 May 2025 (UTC)
I think the problem with what @Khajidha wrote is evident in the first pronoun: "they". "They" are apparently a monolith. About 30 years ago, I knew an American woman who was a small-time anti-abortion advocate. I would describe her as pro-life, since her advocacy included not only opposition to abortion, but also – listing only things I'm certain about – prenatal care, anti-poverty measures, an end to the death penalty, organic farming (to protect farmworkers' health), and a vegetarian diet (or at least low-meat diet, for a more equitable food system, because how could she eat meat, when that means that the environment is being destroyed and poor people will go hungry?). Her interest definitely didn't stop as soon as the baby was born, and yet someone like her gets lumped in with "them", even though "they" and "their" views are quite different from her and her views.
I think there are a lot of complexities in this area, so when talking about an individual BLP, I think it is either best to use their self-identification (Paul Politician says he is ____), or to provide specific information (Paul Politician voted against ____ and for ____). Sometimes, the best description will be something like anti-abortion or abortion rights supporter; rarely (in the US) it could be pro-life or pro-abortion (e.g., for someone whose real goal is population reduction).
Overall, I think these articles are too heavily influenced by American politics. That includes the fact that it's particularly difficult right now for "pro-abortion-rights" editors from the US to remember that there is a world outside the US. It must be very strange for people from countries where abortion rights are ordinary to the point of being unremarkable to read our articles (e.g., in India, where abortions are not just legal, but usually free).
Also, if I could wave a magic wand and make one permanent change, it would be to re-write Abortion#Types to clearly state that a miscarriage is not actually an abortion. The conflation of unintentional, involuntary pregnancy loss with "induced" abortions has been publicly condemned by OB/GYNs for almost half a century now, and we need to quit pretending that lots women have had "an abortion" just because lots of them have had miscarriages. WhatamIdoing (talk) 22:33, 15 May 2025 (UTC)
I agree that there is too much emphasis (especially here, but also elsewhere) on American politics. In nearly all of the world abortion is not seen as a party political issue. I disagree with the analysis of Abortion#Types. It makes clear that in popular usage the word "abortion" usually means "induced abortion", but technically, such as in usage by a gynacologist in an academic paper, its meaning is wider that that. Phil Bridger (talk) 22:33, 18 May 2025 (UTC)
Except that gynecologists don't normally use that language. In English-speaking medical schools, they are trained not to use it.
More importantly, the subject of the article is "induced" abortions. The subject of the article not "anything that happens to get labeled by this term". It's important not to confuse an article's title with its scope. The article that we have titled Abortion is not a WP:SETINDEX of everything ever called abortion. The scope is induced abortions, and the scope determines the title. WhatamIdoing (talk) 23:50, 18 May 2025 (UTC)
while I agree with you, do note that this is not the place to state opinions (especially if it does little to progress the conversation like yours did) mgjertson (talk) (contribs) 18:59, 20 May 2025 (UTC)
I think there was an edit filter at some point that warned users of "pro-choice" and "pro-life" to use "in favor of abortion rights" and "anti-abortion" respectively. "In favor of abortion rights" is better than "pro-abortion" since "pro-choice" people don't necessarily think abortion is morally good, just that it should be legal. JJPMaster (she/they) 14:27, 21 May 2025 (UTC)
Yes. I think I'm probably in agreement with most men outside the US or Poland or the small number of other places where this is a party-political issue in that I certainly don't regard abortion as a moral good (there are better ways to avoid unwanted children being born), but I wouldn't dream of telling a woman what she may or may not do with her body. Phil Bridger (talk) 15:11, 21 May 2025 (UTC)

Space tourists: "crew" or "passengers"

Our spaceflight articles seem to continue to call the paying passengers without duties on recent spaceflights "crew", despite the fact that this doesn't match the normal meaning of the word. While this glorifying of what these actually do (spend 1 minute in actual space, have no duties at all on board), is uncritically repeated by too many news reports, I don't think Wikipedia should contribute to such incorrect promotalk. We clearly use the distinction in every other type of article (e.g. for airline crashes, we list "crew" and "passengers" separately), and no one would dream of calling themselves crew simply for boarding a plane or train. Can we please bring back some accuracy to our spaceflight articles as well? Fram (talk) 16:48, 14 April 2025 (UTC)

  • Personally I agree, but what matters is what terminology sources use and how. It's possible that "crew" in reference to a spaceflight means "anyone on board a spacecraft" while with aircraft it means "those tasked with operating the aircraft". 331dot (talk) 16:57, 14 April 2025 (UTC)
  • We could use quotes around crew, as did you. O3000, Ret. (talk) 17:05, 14 April 2025 (UTC)
    WP:SCAREQUOTES might be a reason not to. Sdkb talk 17:45, 14 April 2025 (UTC)
    I don't think that applies in a case where the word is used metaphorically. We're not making an accusation. O3000, Ret. (talk) 17:53, 14 April 2025 (UTC)
    Quotes would still suggest doubt in this scenario. .cynthialune (talk) 17:13, 28 April 2025 (UTC)
  • I agree with Fram (which doesn't happen often!). Six people who take a boat on a pleasure cruise are no "crew" and nor are these people. In the same way that we don't uncritically repeat other neologisms from press releases, we shouldn't stretch the plain-English definition of a term here and there's nothing in policy that binds us to the exact wording used by the sources. HJ Mitchell | Penny for your thoughts? 17:28, 14 April 2025 (UTC)
  • I'm inclined to agree here, but I would like to know a little more about how much safety training etc. is involved for paying voyagers on spacecraft. Another way to look at the promotionalism concern is that these companies may want to minimize how much preparation is required to make the flights seem more routine than they actually are yet. Sdkb talk 17:49, 14 April 2025 (UTC)
Might be worth using the NASA definition Mrfoogles (talk) 19:22, 14 April 2025 (UTC)

Crew. Any human on board the space system during the mission that has been trained to monitor, operate, and control parts of, or the whole space system; same as flight crew.

Passenger. Any human on board the space system while in flight that has no responsibility to perform any mission task for that system. Often referred to as "Space Flight Participant."
— NASA Procedural Requirements 8705.2C, Appendix A: Definitions

I don't know if those are the right NASA definitions, but using NASA definitions or other scientific/academic expert definitions, rather than promotional media spin, seems to be the better choice for wikivoice. Levivich (talk) 20:03, 14 April 2025 (UTC)
Have you got an example as to when this comes up? Can we not just say that eight people were "on-board" rather than give them a job. Lee Vilenski (talk • contribs) 20:07, 14 April 2025 (UTC)
Every article about a human spaceflight names the participants, currently called the "crew". Having passengers not involved in the operation of the craft is a relatively recent development. 331dot (talk) 20:11, 14 April 2025 (UTC)
First let me say that I know everyone working on these articles has been doing so with good intent and every effort at NPOV, it's just that language evolves very quickly sometimes and there may not be good models on how to write about very recent innovations, and thus Fram has identified a received weakness in existing published matter on this topic.
In any case: If you pay for a ride you are a passenger; if you get paid for going on a ride, you are crew.
I personally think we should use Fram's first phrase in his subhed and just should call them space tourists. Why? Because they're not even passengers on a journey to a destination in the sense that the spaceship is going from a port on Earth to a port on the Moon. They're going on a canned tourist cruise to see whales in the bay or look at that famous rock formation or view the reef by glass-bottom boat, and then return from whence they began. Similarly, people who pay for passage on submersible trips to shipwrecks should be referred to as deep-sea tourists.
FWIW, there is already sitcom-theme-song canon law on this issue:
The mate was a mighty sailing man,
The skipper brave and sure.
Five passengers set sail that day
For a three hour tour, a three hour tour.
So yeah I vote passengers over crew (although I would personally prefer tourists over both although I'm simultaneously concerned it has a slightly disparaging connotation).
jengod (talk) 20:50, 14 April 2025 (UTC)
You mean Tina Louise and Jim Backus weren't crew members? O3000, Ret. (talk) 21:15, 14 April 2025 (UTC)
For those three hours, they were just passengers. But then the weather started getting rough... oknazevad (talk) 18:04, 15 April 2025 (UTC)
We call Dennis Tito a "space tourist", Donald Albury 22:59, 14 April 2025 (UTC)
Did I mention that I'm an official part of the crew of planet Earth? O3000, Ret. (talk) 23:01, 14 April 2025 (UTC)
Tito was a space tourist, who was a member of the 3-Man SM-24 mission crew*, people can be multiple things at the same time. (According to NASA NASA - NSSDCA - Spacecraft - Details JeffUK 17:25, 15 April 2025 (UTC)
You still call people on boats passengers though even if the route is a circular sightseeing one. Same goes for other forms of transport, cf. Mount Erebus disaster. In this case I think passengers is the best term  novov talk edits 00:52, 15 April 2025 (UTC)
Wait, does this mean that the flight was "uncrewed"? We have been using that term for robotic missions. Hawkeye7 (discuss) 01:04, 15 April 2025 (UTC)
We could say the Blue Origin flight earlier today was "unmanned". (Duck and run.) Donald Albury 01:23, 15 April 2025 (UTC)
I would just urge some caution here. I wouldn’t count the passengers of the New Glenn flight as crew. It’s a fully-automated capsule on a suborbital flight. They get basic training on “safety systems, zero-g protocols, and execute mission simulations”. They’re tourists/passengers.
However, the occupants of the recent Fram2 mission trained for months and while the Dragon is highly automated, it’s not fully automated. They still had a lot to learn. They’re definitely a crew.
The problem with the term spaceflight participant is that the Russians define pretty much everyone who’s paying them for a ride as a spaceflight participant… including those who undergo extensive professional training and for whom conducting scientific research is the primary reason for their spaceflight. RickyCourtney (talk) 07:03, 15 April 2025 (UTC)
They are as much made crew by the safety briefing as my going to muster drill on a cruise ship makes me a member of its crew. If they are a) not paid for their services aboard ship and b) take no real part in controlling the craft or operating onboard equipment, I don't see them as crew. That being said, there is always going to be a gray zone.Wehwalt (talk) 13:10, 15 April 2025 (UTC)
Notified: Wikipedia talk:WikiProject Spaceflight. Sdkb talk 17:50, 14 April 2025 (UTC)

I dropped a note about this discussion at Talk:Blue Origin NS-31#"Crew" or "passengers", which has so far fewer participants but a quite different point of view... Fram (talk) 13:25, 15 April 2025 (UTC)

Crew is clearly the common term. NASA refer to the 'participants' on a missions who's only purpose was tourism as 'crew' here The Soyuz MS-20 and Expedition 66 crews - NASA
The European Space Agency refer to the 'tourists' amongst the crew here too.
'Crew' is clearly just 'the people on board' when talking about spaceflight. Maybe that will shift if the distinction between 'crew' and 'passengers' continues but it hasn't yet. The recent 'all-female crew' aboard the latest Blue Origins flight are referred to in all reliable sources as 'A crew', as are the crew-members of all previous blue origins flights. JeffUK 17:11, 15 April 2025 (UTC)

I am going to drop out of this convo now bc I realized I might reinforcing or enabling misogynist presumptions that "if a bunch of women can do it must not be hard work." And that's absolutely on me because I have long-standing bitter POV feelings about Lauren Sanchez dating to So You Think You Can Dance. ANYWAY, my take is that the bifurcation is very clear and has been so since humans first started offering to ferry other humans across the river on janky rafts:

If you pay for a ride, you're a passenger. If you get paid to give a ride, you're crew. Participation in tasks onboard is not the determinant.

If we have reliable sources stating that someone paid money or items of equivalent value (publicity valued at X?) to go on a space trip or were sponsored to go on a space trip, they are passengers (and space tourists).

If we have reliable sources stating that someone is getting paid money by any space agency or rocketship-owning private company to go on a space trip, they are crew.

If we have no reliable sources about the financial/funding arrangements that determined which people are getting onboard a rocket ship, it seems fine to fall back on the default and current practice of using crew. But also don't let marketing practices and publicity stunts fool you.

This debate is a legacy of the Space Age when all space flight was quasi-military, government-sponsored, and "exploration." The transition to commercial space flight and private exploitation of extra-atmospheric travel is obviously well underway and will require a transition in perspective, including perhaps additional skepticism about motive.

Good luck on your debate and I hope you all have a wonderful April!!

jengod (talk) 17:57, 15 April 2025 (UTC)

Space tourists are barely one step up from luggage and are not crew, are not astronauts, are not exceptional except perhaps in the size of their bank accounts. Simonm223 (talk) 20:13, 15 April 2025 (UTC)
Some might qualify as “experiments”… so “equipment”. :) Blueboar (talk) 20:17, 15 April 2025 (UTC)
Participation in tasks onboard is absolutely a determinant.
I’d argue that if you have an active role in the operation of the craft, you’re part of the crew… even if you’re paying for the privilege.
If you’re paying to be there and you’re just along for the ride without any active operational duties (and knowing what to do in an emergency doesn’t count)… you’re a passenger. RickyCourtney (talk) 00:21, 16 April 2025 (UTC)
As Jengod says, choosing the moment that Blue Origin first send an all-female contingent into space to start referring to them as 'equipment' does not pass the smell test. All the relevant articles make it very clear that they are paid participants, and describes them as 'tourists' so I really don't see a reason to rush to change this immediately. JeffUK 08:58, 22 April 2025 (UTC)
We don't need specific rules for this, we should follow what the reliable sources say, regardless of what we think about what they say as we do in other situations. If reliable sources disagree, either just go with the majority or note and/or explain the disagreement as we usually do. Thryduulf (talk) 09:46, 16 April 2025 (UTC)
  • We should follow what reliable sources say, but perhaps we do need clarifying guidance that this doesn't mean we have to or should follow the particular wording they use. That's mimicry, not neutral point of view. It's not so unusual for otherwise reliable sources to use terminology in an incorrect or misleading way, especially in niche topics. This is a good example of that. If reliable sources say that a person did something that meets the commonly understood definition of a 'passenger', then we can and should call them a 'passenger', even if the source itself (for whatever reason) uses the word 'crew'. – Joe (talk) 10:15, 16 April 2025 (UTC)
    I think what we do already is a perfect balance between those. We refer to the people on board as 'Crew' in aggregate, then describe the role of each crew member (Tourist, Space Participant, Payload Specialist) etc. JeffUK 08:52, 18 April 2025 (UTC)
    The word crew implies assigned duties. A passenger has no assigned duty. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:57, 18 April 2025 (UTC)
    Some airline passengers are given assigned duties. Hawkeye7 (discuss) 09:50, 22 April 2025 (UTC)
    That sounds rather odd to me. Passengers on a ship, train, etc. aren't usually described as crew members or part of the crew in aggregate. – Joe (talk) 09:23, 22 April 2025 (UTC)
As a matter of convenience it can be useful to describe the humans on board a 'crewed spacecraft' as the crew of that spacecraft. We just don't have readily available terms like 'passenger spacecraft' or 'human-occupied spacecraft' in common use. (— 𝐬𝐝𝐒𝐝𝐬 — - talk) 03:03, 17 April 2025 (UTC)
How about 'autonomous spacecraft' or 'pilot-less spacecraft'? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:57, 18 April 2025 (UTC)
We already have autonomous spacecraft. Also known as uncrewed spacecraft or robotic spacecraft. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva 00:30, 24 April 2025 (UTC)
  • I support the principle of using "crew" for people who operate the spacecraft, and "passenger" for those who have paid for the privilege of going into or near space, or had it gifted to them, and who do not operate the spacecraft. BastunĖġáḍβáś₮ŭŃ! 10:43, 24 April 2025 (UTC)
    On commercial flights, stewards are considered crew but do not operate the aircraft. Similarly, on military aircraft there are important crew members who do not operate the aircraft. Isn't the situation with spacecraft analogous? There are people who operate the spacecraft, there are mission-critical people who do not operate the spacecraft, whom I would consider crew. I would use passenger for those who do not have any assigned support role. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:53, 24 April 2025 (UTC)
    It sounds like you would classify a Mission specialist as a crew member. WhatamIdoing (talk) 21:01, 26 April 2025 (UTC)
    Bastun, Chatul, I am curious as to whether you would also retroactively apply this standard to payload specialist astronauts like Christa McAuliffe, who fall within the definition but have been considered "crew members" for decades. McAuliffe "had the privilege of going into space gifted to her (in her case, via the Teacher in Space Project) and did not operate the spacecraft". McAuliffe was also objectively not "mission critical"; under your definition she was technically a "passenger" who was invited aboard as part of an initiative to honour teachers, as opposed to any scientific experiments. If this discussion results in a consensus to change our terminology, would we need to modify her article and those of other non-operational NASA payload specialists (like doctors, biologists, veterans, etc)? FlipandFlopped ㋡ 16:47, 29 April 2025 (UTC)
    If she has assigned duties then she's crew; the duties don't have to be operating the craft. If she's only a guest then she's a passenger. Preumably a payload specialist has assigned duties, and thus is crew. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:46, 29 April 2025 (UTC)
    Sorry, yes, to clarify, per Chatul - if you have a job, you're crew. Mission specialists are absolutely crew. Space tourists are passengers. BastunĖġáḍβáś₮ŭŃ! 08:44, 30 April 2025 (UTC)
    So the principle isn't 'using "crew" for people who operate the spacecraft'; it's 'using "crew" for people who are onboard because it's their job to be in space'.
    I suspect that this distinction will feel wrong a century from now, bu for the present decade, this IMO sounds like a good place to draw the line. WhatamIdoing (talk) 04:15, 1 May 2025 (UTC)
  • I'm a little late to the party, but I strongly oppose this proposal. Essentially all of the top independent news sources refer to folks on board as "crew", even if they are not directly operating the spacecraft: see e.g. Vanity fair, NYT, BBC. Our personal opinions about space tourism do not negate that "crew" is objectively the descriptor which is commonly used by all space agencies and reliable sources. Moreover, NASA has always used the term "crew" inclusively to all those aboard, regardless of whether you are "operating" the vessel. For example, most NASA missions have mission specialists or payload specialists who are considered part of the crew by NASA despite not "operating the spacecraft". Technically, those specialists are passengers who are being taken up in to space to perform a mission completely unrelated to the physical operation of the ship. If civil rights activists like Amanda Nguyen and engineers like Aisha Bowe sent to space are not "crew" because they are only there for a social purpose as opposed to operating a spacecraft, then neither are NASA Astronauts like Christa McAuliffe or neurologists like Roberta Bondar who are not trained in how to operate the spacecraft. Unless we are just going to openly treat space tourist flights differently out of subjective disdain for space tourism, this proposal means we would need to go in to all of these astronaut articles and remove all instances of "crew" being used, even despite every single major national space agency and reliable news source continuing to use that term. FlipandFlopped ㋡ 16:33, 29 April 2025 (UTC)
    @Flipandflopped: ... "crew" is objectively the descriptor which is commonly used by all space agencies ... every single major national space agency and reliable news source continuing to use that term What space agencies called them "crew"? AFAIK, NASA has not, and they wouldn't per their definitions, which I posted above. Nguyen and Bowe on Blue Orgin had "no responsibility to perform any mission task", that's why they were "passengers," and McAuliffe and Bondar were "crew," according to NASA's definitions.
    Unless we are just going to openly treat space tourist flights differently ... Differently than crew, yes. That is what we should do. ... out of subjective disdain for space tourism ... No, out of wanting to accurately use words even if the media uses them inaccurately. Out of wanting to follow the definitions of the best sources -- NASA, for example -- over the definition of less reliable sources on this subject, such as mainstream news media (NYT, BBC... though I wouldn't call Vanity Fair "top" news when it comes to space travel). ... we would need to go in to all of these astronaut articles and remove all instances of "crew" ... No, because astronauts, unlike passengers, have a responsibility to perform mission tasks, making them crew. Levivich (talk) 21:15, 29 April 2025 (UTC)
  • My thoughts:
    1. I agree with Shmuel that, for myself, I would tend to describe as "crew" anyone who has assigned duties, whether or not they involve flying the ship. A tail gunner does not fly the bomber, but it would be odd to describe him as a "passenger". This is not completely binary. If I sit in the exit row, they ask me to agree to help if the plane goes down, but I'm still a passenger. Common sense applies, and there could be borderline cases.
    2. I don't think it has anything to do with who pays. That's a very superficial criterion. It's probably strongly correlated with whether you're a passenger or not, but I can imagine someone being willing to shell out big bucks to be an honest-to-goodness crew member performing essential functions, and of course a passenger might have been gifted a free trip for some reason.
    3. But I agree with Flipandflopped that we should not be substituting our own judgment about who is crew, however correct it might be. That's not really in our remit.
  • --Trovatore (talk) 18:29, 29 April 2025 (UTC)
  • Ultimately we have to adhere to what the best-available sources say, but I'd tend to agree with what some people have said above - breaking news stories (especially human-interest ones) about these topics are often promotional in nature and shouldn't be given much weight in that regard; and we do have some leeway to use words according to their common definition. So I would say we should default to "passenger" unless there's really good sourcing indicating otherwise, and avoid using "crew" just because of a few passing mentions in more fluffy coverage or the like. It's also worth pointing out that news sources often don't use the terms in a rigorous manner; see eg. [4]: Dave Limp, a former Amazon executive who was tapped to run Blue Origin in 2023, shared a photo of himself with the six female passengers who made up today’s New Shepard crew. Or [5], which refers to six paying passengers but also The six crewmembers on today's flight... That said, the more staid coverage tends to be more clear about passengers, eg. [6][7] My take, reading them - the use of "passengers" clearly distinguishes someone from crew in the sense meant above; but there's also a broader usage of "crew" that can cover everyone onboard. Therefore, I would use "passenger" if any significant percentage of sources does, because even if sources that use "crew" exist, they don't necessarily contradict it - only sources that overtly say eg. "not a passenger" or wording that is flatly incompatible with them being a passenger would make it a contradiction. --Aquillion (talk) 00:34, 30 April 2025 (UTC)
  • Like any ship, the crew drives the craft and more so have a duty of care to ensure the vehicle is operated in a safe manner. Passengers just sit there, look out the windows and enjoy themselves. I tend to agree with Fram all the time and in this instance they are passengers. The NASA definition seem to understand the difference. scope_creepTalk 11:37, 6 May 2025 (UTC)
  • I agree with Levivich above that we should be looking for sources like the NASA definition. The NASA definition above (where crew do tasks relevant to the mission of the spacecraft and passengers do not) seems to be the best to me from what we've got, but I'd like to see if there are other reliable sources about this.
I also agree that we have no obligation to use the exact wording of the source but I would like to gently push back on the notion that all the people referred to as "crew" in a press release necessarily are not crew or that we should be extraordinarily skeptical about the use of the term "crew" as applied to people who paid to be on a spaceflight. One can easily imagine a future scenario where, say, a company has research that can only be done in space so they pay for their experiment to be sent up along with a representative to supervise the experiment. To me that seems clearly like the representative is "crew" and not a "passenger" because they have a mission-relevant task to do on board. Loki (talk) 00:53, 16 May 2025 (UTC)
  • Back in the 1980s, Feynman was wryly observing that most of the flight operations for the Space Shuttle were automated and that the only vital manual operation was lowering the landing gear; he implied that that this was kept manual to justify the existence of the pilots. Looking at the one example cited above, the main issue seems to be the template {{infobox spaceflight}} which only provides parameters for crew. Note that the traditional phrase for the total number of people on board a craft is "souls on board (SOB)" but it's now the more prosaic "people on board (POB)". Andrew🐉(talk) 20:21, 20 May 2025 (UTC)
  • I would agree, that we should use a definition from a source like NASA or ESA. Media can make and has been making mistakes, so we should, in part, use a different designation, when these are supported by other specialist RS, like NASA. One Example for such a situation would be the current one. Synonimany (talk) 20:41, 21 May 2025 (UTC)

Allow <details> and <summary> tags

Moved to Wikipedia:Village pump (technical) § Allow details and summary tags
 – MinervaNeue (talk) 15:57, 22 May 2025 (UTC)

RfC: Date-fixing bots

OPTION 1
Status quo upheld. -- asilvering (talk) 19:29, 17 May 2025 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I would like to formally understand what the community would think of a date-fixing bot. Such a bot would fix dates in articles to conform either {{Use dmy dates}} or {{Use mdy dates}}. To be clear, this bot would not revert any good faith changes that add content and dates of the wrong format; instead, it will just change the date format. In my opinion, there are a few different ways such a bot could be implemented (or not):

  • Option 1: no bot, everything stays as is
  • Option 2a: a supervised bot (so every edit is manually reviewed before publication) that would have to pass BRFA to be implemented. I think this would alleviate any concerns of the bot creating errors based on context (such as changing date formats in quotes, links, references, etc.)
  • Option 2b: an automatic bot that does something similar in proposal 2a, but wouldn't actually have its edits be checked before implementation
  • Option 3: some other solution; no guarantee that this is actually feasible

Thanks for your consideration – PharyngealImplosive7 (talk) 02:35, 19 April 2025 (UTC)

I'm an extensive user of a script that automates date style fixes. My experience has been that it's crucial to spend time reviewing the edits both to fix errors and to ensure that I am not making a purely cosmetic edit (e.g. by only changing dates in citations which are automatically rendered in the preferred style identified by a "Use XXX dates" tag). I have some doubts that it would be possible to create a date-fixing bot that wouldn't have the same issues, so I I would be unlikely to support 2b. That said, I'm happy to hear from those with more techincal capability.
On a procedural note, is the goal here just to see if this effort is supported by the community? Any bot created would still need to go through BRFA, right? Firefangledfeathers (talk / contribs) 02:41, 19 April 2025 (UTC)
Yes, the goal here is to see whether the community supports the creation of such a bot. A BRFA would still be necessary to ensure the technical competence of any bot. – PharyngealImplosive7 (talk) 03:18, 19 April 2025 (UTC)
  • Option 1: no bot, everything stays as is. Experience indicates that bot edits that are supposed to be manually reviewed don't actually get reviewed. Just look at the never-ending complaints at User talk:Citation bot. --Jc3s5h (talk) 02:44, 19 April 2025 (UTC)
  • Strong oppose option 2b. There are many examples of contexts where dates should never be altered, articles about/discussing different date formats, including but not limited to direct quotations, version numbers, timestamps, and things that look like dates but aren't. Many, probably the vast majority, of these will not be able to be correctly identified by bot. If something supervised is desirable (and I am presently unconvinced it is) then adding to something like AWB would seem a more useful and safe option. Thryduulf (talk) 03:32, 19 April 2025 (UTC)
  • It's difficult to evaluate this in the abstract. I could theoretically be persuaded to support 2a or even 2b if the error rate is shown to be low enough, but we can't know the error rate until implementation gets farther along. If fixing dates to conform with an article's tag doesn't turn out to be feasible, I think there might be potential in having a bot assist with identifying articles to tag with formats based on their categories. Such a bot would have to be tuned to handle exceptions, but I think it could be tailored to an uncontroversial set that'd still be quite large. Sdkb talk 04:30, 19 April 2025 (UTC)
    I guess you raise a chicken-and-egg type problem: you want to see the error rate, but to start a bot trial we need consensus first. – PharyngealImplosive7 (talk) 06:42, 19 April 2025 (UTC)
    A supervised bot working on a limited sample of pages, with human review, could be a good way to evaluate whether such a bot can actually be fit. Chaotic Enby (talk · contribs) 10:59, 19 April 2025 (UTC)
  • Option 1, because option 3 has already happened. The dmy and mdy templates already transform citation display. CMD (talk) 05:00, 19 April 2025 (UTC)
  • BAG note... 2B is a non-starter per WP:BOTPOL. All bots have to go through BRFA, and a bot like this would definitely need testing and review. Headbomb {t · c · p · b} 07:21, 19 April 2025 (UTC)
  • Option 1 no bot. This proposal assumes that all {{Use dmy dates}} and {{Use mdy dates}} tags are correct and should be enforced throughout the article. It ain't so. Yesterday I spent too long checking and reverting a new editor's mass additions of these tags, almost all contrary to MOS:DATERET and/or MOS:DATETIES, seemingly made without having read Template:Use mdy dates/doc or Template:Use dmy dates/doc, and otherwise inappropriate. A bot of this sort would have made that a considerably more tedious task.
    Dates within quotations should never be changed. The technical difficulty of doing this, catching quotes between quotation marks as well as in {{blockquote}}, has defeated other autoformatting attempts and I see no suggestion here that a solution has been found. NebY (talk) 09:11, 19 April 2025 (UTC)
    Would your concern be somewhat alleviated if the bot checked that the "use xxx dates" template was on the article at least 6 months prior to the revision it checks? – PharyngealImplosive7 (talk) 19:15, 19 April 2025 (UTC)
    Not really. Many of the tags I corrected yesterday were on low-traffic articles; many of our articles are, and the tags are invisible to readers and to editors reviewing the article in reading mode or editing a specific section of the article; and even those editing the lead may have no reason to pay any attention to the tag. I was also reminded yesterday how long errors can survive, when I examined and corrected a factual error in the text of a high-traffic article (105,213 page views in 30 days); that one had survived over 3500 edits since 2011. NebY (talk) 19:39, 19 April 2025 (UTC)
  • Option 3, have a supervised trial, similar to option 2a (with human review) but on a limited sample of pages, to evaluate the error rate and find out whether it is fit for deployment. Chaotic Enby (talk · contribs) 11:02, 19 April 2025 (UTC)
  • Option 1 Uniformity is a vastly overrated condition. It's small value, if any, is not worth the downsides of having a bot mess with dates. North8000 (talk) 13:22, 19 April 2025 (UTC)
  • Option 1 Thanks for thinking about this but experience shows that automated edits lead to disruption. As outlined above, exceptions exist and many good editors become highly agitated when bots repeatedly fiddle with article style without an understanding of context. No significant benefit would result, for example, from protecting readers from the horror of encountering "April 1, 1725" in an article on a British monarch. Johnuniq (talk) 04:19, 20 April 2025 (UTC)
  • Option 1 As per Johnuniq, to many issues with bots, and would hate to see American dates on pages fir any article that should be DMY.Davidstewartharvey (talk) 06:30, 20 April 2025 (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.

Community sanctions for "Assyrian" topics

GENERAL SANCTIONS ENACTED
The community authorizes the standard set of contentious topic restrictions as general sanctions for topics related to Assyrian, Chaldean, Aramean, and Syriac identity, culture, and politics, broadly construed. The use of "and" here should be understood inclusively, meaning sanctions may apply to any, multiple or all of these ethnicities and listed topics. --qedk (t 愛 c) 19:30, 24 May 2025 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There is an ongoing dispute regarding the naming of a group or groups of people that are variously described as Assyrian, Chaldean, Aramean, and/or Syriac. Some background on the topic can be found at Terms for Syriac Christians. One of the editors currently involved in the dispute has also started Draft:Assyrian identity crisis with an intent to focus on this dispute more specifically.

  • The subject is currently at ANI here. Also at ANI, involving some of the same editors, in March-April here and here. One editor was briefly blocked (by me) for edit-warring, and there have been accusations of sockpuppetry and off-wiki canvassing.
  • The current dispute is focused on defining "Assyrian" vs "Aramean", but Chaldean and Syriac have similar issues. At present, there is a draft article at Draft:Aramean people; this has been asserted to be a pov-fork of Assyrian people.
  • The dispute is extremely longstanding. Wikipedia:Articles for deletion/Aramean-Syriac people, for example, is from 2008. RoySmith closed a deletion review for that article in 2014, observing that There is obviously a politically-driven content dispute going on here. In that same discussion, Future Perfect at Sunrise called it the focus of one of the most ridiculously entrenched ethnic POV wars I've encountered during my time on Wikipedia.
  • For other examples of disruption, see the protection log for Arameans and the page history of Syriac Orthodox Church. Individual place and biography articles are also affected. For an example, skim the page history of Shamoun Hanne Haydo and you'll find many references to the dispute, going back years.
  • To my knowledge, this dispute does not fall into any current GS/CTOP regimes, and never has.

Accordingly, I propose the community adopt the standard set of restrictions as WP:GS for this topic area. We could simply call the topic "Assyrian naming dispute", but this strikes me as both privileging a pov and as overly narrow. Better (though admittedly a mouthful) would be "Assyrian, Chaldean, Aramean, and/or Syriac identity, culture, and politics". WP:GS/ACAS, unless someone wants to pitch in with a better shortcode. -- asilvering (talk) 06:13, 8 May 2025 (UTC) bold added for clarity asilvering (talk) 19:03, 8 May 2025 (UTC)

  • Support. This dispute is too complex for me to fully understand, but there clearly is are problems and GS might help. Toadspike [Talk] 11:47, 8 May 2025 (UTC)
    After reading over the comments below, I oppose a sunset clause per Robert McClenon. This has been going on sporadically for fifteen years. I would be in favor of some kind of official review in a few years' time, but the default outcome of that review (status quo) should be to keep the GS, not remove them. Toadspike [Talk] 17:42, 13 May 2025 (UTC)
Oppose. "Assyrian naming dispute" would be extremely POV. It would basically assert that they all are Assyrian in reality, which is contested by the the people. There is more than enough notability and WP:RS on this topic advocating for a Aramean notability. I do not see how Draft:Aramean people is a POV-fork? What is taken/copied from Assyrian people. It has been decades on this issue and yet nobody wants to fix the main issue itself? Why drag it out and keep feeding the fire? Take note of the Dutch and German pages, they are by far not as subject to as much edit-warring as on the English WikiPedia. Literally decades, its 2025 and the undermining of others is still present. Wlaak (talk) 12:58, 8 May 2025 (UTC) Support - i misinterpreted the proposal, i am supportive for and have a preference for WP:GS/ACAS, it has all names included: Assyrian, Chaldean, Aramean, Syriac and is the most WP:NPOV. Wlaak (talk) 16:07, 8 May 2025 (UTC) original second comment was placed as a second !vote, I moved it up here and did the s/u bit asilvering (talk) 19:00, 8 May 2025 (UTC)
@Wlaak, That is what @Asilvering said? It would be something along the lines of Assyrian, Chaldean, Aramean, and/or Syriac identity, culture, and politics. CF-501 Falcon (talk · contribs) 13:22, 8 May 2025 (UTC)
I'd agree with that label, not "Assyrian naming dispute" as was also mentioned. A few months ago, the article about Chaldeans was also deleted by a involved editor. Currently on Wikipedia, only the Assyrian name, identity, history, culture is prevailing. It needs to change, its been this way for decades. What is the issue with having three articles, describing the three peoples historical narratives, culture, tradition, and everything surround them? While still be linked to the Assyrian, Chaldean, Aramean, and/or Syriac identity, culture, and politics.
A comment from Wikipedia:Articles for deletion/Aramean-Syriac people really struck me, it explained it very good:
"I have no intention of judging what is the true name or nature of an ethnic group, and neither should Wikipedia. For what appears to be the same group, different parts of it describe and name it different ways, its good reason to have two articles. In a practical sense, its the way of settling the continuing conflict about what to call it."
Keep in mind, at the end of the day, we are talking about different ethnic identities, all meeting WP:NOTABILITY, WP:RS etc. and it would be the best for WP:NPOV and avoid disputes like this. Currently sanctions are placed on people, this will never stop. Instead, fix the issue, the issue isn't even going against the guidelines of Wikipedia.
I do not want to Wikipedia:BLUDGEON, will not write any further in this section. Wlaak (talk) 13:33, 8 May 2025 (UTC)
@Wlaak, that label is the label I've proposed. -- asilvering (talk) 15:50, 8 May 2025 (UTC)
Support given the level of conflict caused by this issue, with a strong preference for WP:GS/ACAS as it doesn't privilege a specific name (although the main article Terms for Syriac Christians itself has a similar problem). I don't really understand Wlaak's oppose, as they seem to agree that this has been a long-standing source of conflict. Chaotic Enby (talk · contribs) 13:41, 8 May 2025 (UTC)
I just reread it, I too have a strong preference for WP:GS/ACAS. Sorry for the misunderstanding. Wlaak (talk) 13:45, 8 May 2025 (UTC)
Support - I would like to suggest "Assyrian-Chaldean-Aramean identity" as an alternative shortcode. Being one of the primary editors involved, I feel that the disputes don't center around community politics or culture when the roots of them are tied to identity and the ongoing naming conflict. It factors in all identities while also making it clear that the bulk of these disputes center around designations between these labels in particular.
Whatever the decided label is, though, imposing GS would be the first of many steps towards finally resolving these debates once and for all, and I am in support of it. Surayeproject3 (talk) 15:52, 8 May 2025 (UTC)
@Surayeproject3, that would be a different definition of the topic, not a different shortcode (the shortcode is the WP:GS/whatever bit). I see you've removed "Syriac" from the set - is there a reason for that or is it an oversight? -- asilvering (talk) 15:58, 8 May 2025 (UTC)
The term "Syriac" has different interpretations depending on who is using it. Some say it's a theological term, others say it unites the three names listed, and those who advocate Aramean identity believe it is synonymous with the label. I omitted it as an assumption that the label is synonymous with "Aramean" since it appears to be widely used in this context.
A short code I would use in this case then is ACS to represent "Assyrian Chaldean Syriac". Surayeproject3 (talk) 16:07, 8 May 2025 (UTC)
this way you're omitting the Aramean name? Many use Syriac ethnically. Wlaak (talk) 16:09, 8 May 2025 (UTC)
Well I don't really know anymore Wlaak, why don't you tell me? Does Syriac mean the same thing as Aramean, or is Syriac suddenly a new identity with a completely different claim that needs to be factored in? Your draft says "Arameans...frequently referred to as Syriacs or Syriac-Arameans?" so that implies to me or anyone reading it that they are synonymous. Surayeproject3 (talk) 16:13, 8 May 2025 (UTC)
it doesn't matter if Syriac is often used with Aramean or not. point is that Syriac is a very, very common identification amongst people. in Sweden, Syriac is only used, they do not say Aramean, Chaldean or Assyrian. Syriac is just as common of a self-identification as Aramean, and is not bound to the Aramean name.
Chaldean is often used with Assyrian, Chaldean Assyrian, Assyrian Chaldean etc. they are not bound to each other, they still serve as own identifications. Wlaak (talk) 16:19, 8 May 2025 (UTC)
Given this thread, it appears that it's important that we include all four, to avoid misunderstandings. Better to make the topic a bit too broad than to invite haggling over whether particular edits count, or to cause offense to editors whose preferred term is left out of the set. -- asilvering (talk) 19:02, 8 May 2025 (UTC)
+1, we can't even agree; how will we expect others to do so? CF-501 Falcon (talk · contribs) 19:03, 8 May 2025 (UTC)
i agree. well said, asilvering Wlaak (talk) 19:13, 8 May 2025 (UTC)
Sure, that's not an issue. In that case we can have the code potentially be ACSA and the identifier "Assyrian-Chaldean-Syriac-Aramean identity". Surayeproject3 (talk) 22:52, 8 May 2025 (UTC)

Those search results indicate that there were at least two flare-ups of contention on that topic (without searching for any other name), one in 2020, and one in 2025 that is ongoing. The two requests for dispute resolution in March 2025 were declined because there were also already disputes at WP:ANI

An examination of

  • Talk:Arameans/Archive 2 shows the prior discussion that led to the two earlier DRN requests, which is largely uncivil.

I think that is more than enough evidence to show that this has been a battleground topic for at least five years, and that administrators should have an additional toolset to deal with disruptive editing. Robert McClenon (talk) 00:52, 12 May 2025 (UTC)

  • Question for User:asilvering or anyone else - Am I correct that the purpose of this proposal is to give uninvolved administrators an additional toolset to impose restrictions on disruptive editors in this topic area? Robert McClenon (talk) 01:13, 12 May 2025 (UTC)
    Yes. That's the point of most GS/CT proposals is to give the admins more tools. Sennecaster (Chat) 20:46, 12 May 2025 (UTC)
  • Comment: no one has pointed out any kind of fatal flaw in this proposal, so I've listed it on CENT for some more eyes. -- asilvering (talk) 22:30, 12 May 2025 (UTC)
  • Support: Bigger jobs need bigger tools. The blade that cuts your steak is a poor option to cut down the tree in your backyard. As history has shown, this area is one of those bigger jobs. I'd be in favor of a 24-month sunset as was suggested, but I'd rather not have the sunset clause rather than not have the sanctions at all. CoffeeCrumbs (talk) 01:23, 13 May 2025 (UTC)
  • Support Common sense. Area of long-term disruption. Curbon7 (talk) 06:04, 13 May 2025 (UTC)
  • Support given the nature of the ongoing dispute and how long it's been going on for. A sunset clause with allowance for renewal, as mentioned by others, would be a good idea. -- LCU ActivelyDisinterested «@» °∆t° 11:09, 13 May 2025 (UTC)
  • Comment - I strongly disagree with the sunset clause. The dispute has popped up in 2008, 2012, 2020, and 2025. With any sunset clause, the status would have expired between flare-ups. A sunset clause would overlook the established history, in which the dispute hibernates for several years and then pops up again. Robert McClenon (talk) 14:08, 13 May 2025 (UTC)
  • Comment - It seems that most of those long-standing disputes are related primarily to modern communities (modern Arameans, modern Assyrians, modern Chaldeans) or in general to modern Syriacs (adherents of Syriac Christianity). In principle, non of those modern disputes should have a retroactive impact on articles related to ancient peoples (ancient Arameans, ancient Assyrians, ancient Chaldeans). Therefore, it might be useful to include that distinction in the initial proposal, thus making it explicitly focused on current disputes between modern communities, while leaving articles on ancient peoples out of the primary scope of the proposed WP:GS, that could be more precisely named: Identity and politics of modern Arameans, Assyrians, Chaldeans, and/or Syriacs (terms optionally given in alphabetical order). Since it is not disputed anywhere (even here on EW) that ancient peoples (ancient Arameans, ancient Assyrians, ancient Chaldeans) were three very distinctive peoples, subjects and articles related to them should not be directly impacted by the proposed WP:GS. Problems do exist, but only between modern communities, so lets focus on resolving those issues, without retroactively impacting the entire ancient history of the Near East. Sorabino (talk) 18:01, 13 May 2025 (UTC)
    @Sorabino, I think adding "modern" to the scope is a good idea, thereby modern Assyrian, Chaldean, Aramean, and/or Syriac identity, culture, and politics. However, I do want to be clear that this will be interpreted, like any other sanctions topic, as broadly construed; that is, it will apply to ancient topics where appropriate. Regarding your slightly different formulation of the wording beyond just adding "modern", I personally prefer the "adjective noun" format over "noun of nouns" format because (imo, and in-group editors may wish to weigh in here) adjectives describe people but "noun of nouns" literally reifies them - that is, I think "noun of nouns" implies that there are four extant groups of people in a way that "adjective noun" does not. Regarding the order, I picked ACAS because it's pronounceable and because I've seen "Aramean-Syriac" as a unit, and no other reasons. ACSA and ASCA also work for that purpose. If everyone prefers AACS because it allows the alphabet to decide the order for us, I shall only grumble a little bit. -- asilvering (talk) 18:16, 13 May 2025 (UTC)
    I've also seen "Assyro-Chaldean" (or "Chaldo-Assyrian") as a unit, so it does make sense to group them together too. Chaotic Enby (talk · contribs) 18:22, 13 May 2025 (UTC)
    Assyro-Chaldean is often grouped together and Syriac-Aramean is often group together, it should be ACSA/ACAS in my opinion Wlaak (talk) 18:43, 13 May 2025 (UTC)
    @Asilvering, that is right, various questions, related to ancient peoples, also have a specific relevance for modern communities (for example, questions such as: Aramean continuity, Assyrian continuity, Chaldean continuity). On subjects such as those, the proposed WP:GS is indeed applicable, and it might be useful to emphasize that questions of continuity between modern communities and ancient peoples are among the most disputed, both in scholarly circles and here on EW, not to mention heated discussions and disputes on those specific questions between representatives of modern communities. Regarding the order of terms in the title, that is quite optional, but it seems to me that simple alphabetic order would be the most elegant solution. Sorabino (talk) 11:59, 14 May 2025 (UTC)
  • Support for the restriction, titled with the four-name option. Wordiness is better than POV-forking. JuxtaposedJacob (talk) | :) | he/him | 18:36, 13 May 2025 (UTC)
  • The problems in this area have been ongoing for several years. Whether sanctions would help is unclear, but one can hope. (t · c) buidhe 01:03, 16 May 2025 (UTC)
  • Support for the restriction, ACAS is fine, bit I don't have an opinion on it really. I am aware of the contentiousnes of this topic, and have witnessed it occur in some articles, while we won't be able to "solve" it, hopefully such restrictions may temper it. -- Cdjp1 (talk) 12:26, 16 May 2025 (UTC)
  • Is the community just adopting the standard set or all the stuff around the standard set such that this could be enforced at AE and not just AN? And is it the standard set as it exists at time of passage or is it the standard set, as updated by ArbCom? I think the community struggles to manage GS as well as arbcom manages CT and it's because both these wording nuances are not decided at time of implementation and because fixing issues that arise are much harder. Best, Barkeep49 (talk) 15:33, 16 May 2025 (UTC)
    @Barkeep49, thanks so much for this. It was my understanding that only arbcom-defined CTOPs could be handled at AE. I gather from your comment that this isn't the case? I'd very much be in favour of allowing disputes to be heard by AE instead of AN. And "the standard set, as updated by ArbCom" is probably best, for the sake of keeping things simple for future admins. -- asilvering (talk) 18:46, 16 May 2025 (UTC)
    See the last bullet point here. In the conversion of DS to CT, the committee created a way for the community (if it wanted) to plug in to AE and other arbitration created structures. Best, Barkeep49 (talk) 18:49, 16 May 2025 (UTC)
    There was some discussion a year ago regarding what it would take for the community to start designating topic areas as contentious topics. (In my opinion, it would be best for the community to use the existing contentious topic procedure to develop a common base procedure, with the arbitration committee's customizations added on top. This would continue to take advantage of the committee's greater agility in trying out new remedies.) There hasn't been any progress, as only a few number of editors have shown any interest in generating a consensus to adapt the contentious topics process for use by the community. It's hard getting a sufficient number of editors engaged, as most people aren't that interested in process development work. I agree with Barkeep49 that it would be better to work out the details in advance, or else we can end up in the same situation as with community-authorized discretionary sanctions, where the process is defined in relation to the defunct arbitration committee process. isaacl (talk) 22:18, 17 May 2025 (UTC)
    For the reasons you describe regarding how it's difficult to get consensus to make really big changes, I think it's better to keep this simple and tightly focused on the "ACAS" topic area specifically for now. If the community then wants to take it as evidence that this works and wants to apply it more broadly, that can be a second discussion, and hopefully it will be easier for that one to come to consensus if there's some examples from this topic area to point to. -- asilvering (talk) 22:30, 17 May 2025 (UTC)
    I think it needs to be made clear if the community-authorization for discretionary sanctions process is being followed, which has implications on notification requirements and how long sanctions can be imposed. Additionally, as Barkeep49 discussed, is the standard set of sanctions from the contentious topics process being copied as they currently stand into the page describing the new community authorization, or will it point to the contentious topics page and thus automatically include future changes? If there is a desire to follow the contentious topics process instead of the discretionary sanctions process, then there's some additional community-specific changes that need to be made. isaacl (talk) 22:41, 17 May 2025 (UTC)
    Right, we're in that discussion right now. So if there are "some additional community-specific changes that need to be made", now is the time to say what they are. -- asilvering (talk) 22:56, 17 May 2025 (UTC)
    If the answer to question one is that community authorization for discretionary sanctions is being proposed, then the last question is moot, and the second question needs to be answered. isaacl (talk) 23:07, 17 May 2025 (UTC)
  • Support - a useful tool for maintaining order and civility among impassioned editors editing a contentious topic. --A. B. (talk • contribs • global count) 01:50, 17 May 2025 (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.

RFC on extended confirmed

Please see Wikipedia:Requests for comment/Extended confirmed definition. It is a proposal to change WP:XC from 500 edits + 30 days to 500 edits + 90 days. WhatamIdoing (talk) 20:16, 25 May 2025 (UTC)

Split "additional considerations apply"/"marginally reliable" from "no consensus" at RSP

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.
I am not seeing a consensus for this proposal. RSP is too highly watched and used to make a change like this in the face of a healthy amount of opposition and on the basis of a small discussion (13 editors). Ed [talk] [OMT] 15:12, 11 June 2025 (UTC)

Currently, the "additional considerations apply" and "no consensus" statuses have the same "MRel" yellow grouping at WP:ReliableSourcesPerennial. This has caused some confusion for closers and those unfamiliar with what RSP actually is: a summary of past consensus and not any sort of guideline; "no consensus" makes a source's status "no consensus" instead of preserving the previous status. This also makes it a bit harder to differentiate "consensus for additional considerations" from "no consensus".

Thus, I propose we split out "additional considerations apply" and "marginally reliable"—as the new version of MRel colored Codex's purple200 (#d9d0e9)—away from the now-separate "no consensus" category that retains its yellow color. This purple provides sufficient color contrast against foreground text and seems the most friendly to colorblind people. This proposal would update the RSP legend, change the options in future source-reliability RfCs, and sort existing MRel sources.

Pinging participants of the idea lab discussion: @LokiTheLiar, @Thryduulf, @Headbomb, @David Gerard, @Toadspike. Aaron Liu (talk) 16:03, 10 May 2025 (UTC)

Against This was proposed recently, I was against then, and I still am. Yellow means some variant of "stop and think, consider if this is really the best source for the information", the distinction between "no consensus" and "marginal reliability" is effectively the difference between pale bright yellow and faded bright yellow. Headbomb {t · c · p · b} 16:13, 10 May 2025 (UTC)

One has full consensus behind spending time thinking about this one and detailed directions on how to, as opposed to the far more general "we're not sure if this source is reliable, double-check".

This is what I said when you said this during the "proposed recently" you mention, which is an idea lab workshop and not a proposal. Aaron Liu (talk) 16:30, 10 May 2025 (UTC)
I agree that these two terms should be seen differently. I've thought about the colors (which should be yellow and which purple) and think it makes sense to make MRel purple, since MRel sources are reliable in specific cases, while "no consensus" sources are not necessarily reliable for anything. Thus, I support this proposal. Toadspike [Talk] 16:46, 10 May 2025 (UTC)
To me "no consensus" is a subset of "additional considerations apply", the consideration being that there was no consensus on the sources reliability. If a close is unclear it can be discussed with the closer, and updated if necessary.
The issue as I see it is how editors interpret MRel. The currently colour gives the idea it's between generally reliable and generally unreliable, which isn't true. MRel means you need to read the entry as it's not as simple as GREL/GUNREL, not some gradient between the two. Maybe the solution is to change the colour for all MRel entries. -- LCU ActivelyDisinterested «@» °∆t° 16:47, 10 May 2025 (UTC)
Removing the stigma of MRel could also help with other inconsistencies in the list. At the moment sources that are reliable in general, but not in specific situations, are listed as green or yellow depending on the source. These could both be moved to the new colour that indicates nothing other than you must read the sources entry. -- LCU ActivelyDisinterested «@» °∆t° 16:50, 10 May 2025 (UTC)
I agree with what you say about MRel besides the part on "no consensus". No consensus means there was disagreement between which of options 1-4 to pick. Almost always, this is disagreement between options 1 and 3, making the source's reliability somewhere between these indeed. "No consensus" does not mean participants realized a part of the summary that you need to read, unlike "additional considerations apply". Aaron Liu (talk) 16:54, 10 May 2025 (UTC)
No consensus is just another additional consideration, what would be best in such cases would be to summarise the majority opinions in the discussion so later editor could see a quick overview. -- LCU ActivelyDisinterested «@» °∆t° 09:53, 11 May 2025 (UTC)
Still, we should differentiate "no consensus, no guidance save for universal reminders" when there's consensus that a source is reliable save for an agreed-upon area. Aaron Liu (talk) 20:10, 13 May 2025 (UTC)
No we shouldn't. Such entries should not be green, the desire to have them green is because editors try to abuse the MRel status (as shown in the diff about the Telegraph). Only sources that have a consensus that they are reliable in all areas should be green. Arguing that as it's green it's reliable is as bad as arguing it's yellow it must be removed. Per my comment below anything without a clear consensus for the whole source should just have its colour removed. -- LCU ActivelyDisinterested «@» °∆t° 11:01, 14 May 2025 (UTC)

Only sources that have a consensus that they are reliable in all areas should be green.

That goes against the plethora of sources split into several entries by topic, some of which are green.
If "arguing it's yellow it must be removed" means we should drop yellow, why shouldn't we drop green as well? They are the same level of useful. Aaron Liu (talk) 01:58, 15 May 2025 (UTC)
Green should be for sources that there is a definite answer for, that could include a definite answer for a certain aspect of a source. It is obviously different than an slee of sources that are all different for different reasons. -- LCU ActivelyDisinterested «@» °∆t° 12:54, 28 May 2025 (UTC)
Green is not a definite "reliable". Green status has misled editors into keeping a source no less than yellow has removing. Besides Jacobin back in the eons it was green, see also A.V. Club's consideration to identify AI-generated content, BBC's many different sections some of which are questionable, and Aon whose common different types of data is often different from what editors believe it is. Those (except BBC, which should maybe just have a separate entry) would benefit from an "additional considerations" status but did not receive one—I say due to stigma. That these aspects were from consensus is irrelevant to the fact that green is no more definite than additional considerations in what to do with a source.
Additional considerations can also include a definite answer for a certain aspect, and I haven't heard from you yet why those should be lumped with entries that are just boilerplate no-con text with standard reminders should. Separation would make it much more distinguishable at-a-glance. Aaron Liu (talk) 01:03, 29 May 2025 (UTC)
You misunderstood not 'definitely reliable:, but that there is a 'definite consensus' about the source. -- LCU ActivelyDisinterested «@» °∆t° 08:11, 29 May 2025 (UTC)
Why shouldn't we separate "definite consensus on certain aspects and definite consensus it is otherwise generally reliable" in MRel from "no consensus"? Aaron Liu (talk) 11:23, 29 May 2025 (UTC)
Disruptive editing based on "no consensus" or other "additional considerations" closes are unfortunately common, but the misuse of "no consensus" closes is no less common than the other MRel closes. The issue is how editors misinterpret the whole class, not a subjection of that class. -- LCU ActivelyDisinterested «@» °∆t° 14:19, 12 May 2025 (UTC)
I believe that's only because "no consensus" and other MRel closes are grouped in the same class, which is why we should separate it. Aaron Liu (talk) 19:38, 13 May 2025 (UTC)
I would suggest removing the colour from all the MRel entries. Editors are just going to start to assume purple is not green, in the same way they treat yellow. Splitting out 'no consensus' results from other similar 'additional considerations' results won't change this behaviour. The "'Green' -> 'Any other colour it doesn't matter' -> 'Red'" spectrum is the issue. Instead change it so that only those with a consensus that the full source is either generally reliable/unreliable have a colour (green/red), and all other don't. -- LCU ActivelyDisinterested «@» °∆t° 10:54, 14 May 2025 (UTC)
"No color" (grey?) is quite hard to differentiate from the deprecated statue's dark grey in dark mode. Aaron Liu (talk) 11:01, 14 May 2025 (UTC)
Grey is a colour, they should not have a colour. -- LCU ActivelyDisinterested «@» °∆t° 11:03, 14 May 2025 (UTC)
I'm saying no color for WikiTables looks grey. Try it, toggle dark mode in Vector 2022, go to User:Aaron Liu/sandbox, and see if you can dfiferentiate-by-color OpIndia and La Patilla, the latter of which had its color removed.
(Let's discuss whether no-consensus-and-nothing-beyond-normal-reminders stuff should be yellow at #c-Aaron_Liu-20250513201000-ActivelyDisinterested-20250511095300.) Aaron Liu (talk) 01:54, 15 May 2025 (UTC)
Then change the grey colour that's currently used, that's hardly difficult. -- LCU ActivelyDisinterested «@» °∆t° 12:52, 28 May 2025 (UTC)
Ah for some reason I hadn't thought of that lol. After looking around a bit I think gray600 for dark-mode blacklisted entries might work alongside ActivelyDisinterested's compromise, which I support while preferring my proposal.
On "Editors are just going to start to assume purple is not green,"—which I just realized I hadn't addressed—I say they're not and will not have the same connotations with purple as with yellow, as there's nothing with purple that suggests caution. It's a value-neutral and distinct color. The same logic applies to why people won't assume no-color is not green. And in the end, this proposal is reversible. Why not give it a try and see the response and impacts? Aaron Liu (talk) 00:52, 29 May 2025 (UTC)
How could the logic be the same you suggestion is to separate out how certain results are recorded, thereby changing there status. Mine was to have all those results remain as one category but modify how they are all recorded. As I said seemingly so long ago now purple will become value laiden because of it's use, that it isn't now isn't the point. -- LCU ActivelyDisinterested «@» °∆t° 08:09, 29 May 2025 (UTC)
The same reason grey won't become value-laden in your use applies to purple as well. In fact the only value purple could get is "there's a caveat to the source's general reliability" instead of yellow's connotation, while the latter's far more negative value would transfer to grey in your proposal, no? Aaron Liu (talk) 11:21, 29 May 2025 (UTC)
As I think I said last time, there isn't any practical difference between "consensus that additional considerations apply" and "no consensus that the site is either generally reliable or generally unreliable" so I don't see the benefit in making the list more complicated. Especially as it would lead to arguments about what happens if there is a discussion that leads to no consensus between MREL and either generally reliable or generally unreliable? Thryduulf (talk) 16:53, 10 May 2025 (UTC)
There is. For example, Jacobin is generally reliable for its reporting but almost always publishes opinion pieces and thus needs additional considerations. Here's another example:

Editors consider Social Blade, a social media analytics website, reliable when it comes to objective statistics and data. This does not apply to the site's "grades", "rankings", and "estimated earnings" information, which have dubious methodologies. There is consensus that Social Blade is ineffective in determining notability as it is a primary source.

These very much cannot be replaced by "no consensus".

what happens if there is a discussion that leads to no consensus between MREL and either generally reliable or generally unreliable?

I don't see how such a scenario could occur; if it did, it should probably be "no consensus" while noting the consideration that some editors supported. And even leading to such arguments is better than the current case where "no consensus" and specific considerations and warnings are conflated. Aaron Liu (talk) 17:01, 10 May 2025 (UTC)
I didn't say there was no difference, I said the was no practical difference - i.e. what the person evaluating a source currently marked in yellow needs to do/know is the same: The source is neither generally reliable nor generally unreliable, you need to read the entry (and possibly the associated discussion) to understand why and in what way.
I don't see how such a scenario could occur when you have two groups of editors, one arguing that it's of medium reliability and the other arguing that it's generally (un)reliable, with neither group's arguments gaining consensus. Thryduulf (talk) 17:11, 10 May 2025 (UTC)
There is usually little more value found in reading "no consensus" statements than reading "generally reliable" statements. With a few exceptions, the bulk of those do not specify topics (except specifying "don't use for contentious topics" for no consensus, a designation which effectively already says that). As a result, editors often just take either just "GRel" or "no consensus" at face value. This contributed to The Telegraph (which has a separate entry for trans topics) being blanket removed from all citations within GenSex in the initial fallout chaos of that RfC. Meanwhile, it is absolutely required to read "additional considerations" statements. That's the practical difference.

one arguing that it's of medium reliability and the other arguing that it's generally (un)reliable

I don't see how an argument between "additional considerations apply" and GUnRel would happen. Instead, wouldn't the two groups have consensus that Source is unreliable in Topics, and debate between GRel and GUnRel for the other topics? Aaron Liu (talk) 17:21, 10 May 2025 (UTC)
  • Agree with Thryduulf and Headbomb that this is unnecessary. I feel that it's likely to lead to more red tape and arguments over what each color means; and in general RSP seems to be working as-is, so I'm opposed to major suggestions for revisions unless there's a very clear need. The distinction would imply a degree of sweeping certainty that I don't think RSP ought to assert. The basic point is that if something is yellow its use is debatable; the degree to which guidance is provided by the discussions differs and has to be decided on a case-by-case basis. I also don't agree with the assertion that a no-consensus outcome cannot provide useful guidance; in fact, many of the existing yellow RSP entries say something along the lines of "there's no overall consensus about its reliability but many people who weighed in do agree on [basic guideline boundaries]", eg. definitely don't use it for X or its fine for Y. --Aquillion (talk) 18:40, 10 May 2025 (UTC)
    Pressure of need can be found at Wikipedia talk:Reliable sources/Perennial sources/Archive 10#No consensus versus mixed consensus (should I ping these participants?).
    I had the same position as @Thryduulf until Chess convinced me: To answer "What's the practical difference?",

    Because many people wanted to impose additional considerations as a mechanism to prefer other sources when possible, which is what WP:MREL means in practice. Immediately after the entry was added to RSP, editors began removing [The Telegraph] from articles. Special:Diff/1233432855
    — User:Chess 16:29, 7 August 2024 (UTC)

    Anecdotally, such removals were very widespread.

    I also don't agree with the assertion that a no-consensus outcome cannot provide useful guidance

    Indeed they can and there's many examples, but NoCon entries at RSP overwhelmingly do not provide useful guidance beyond "no consensus". Out of the 6 no-consensus results for entries from U to Z, 4 do not. It's all at most basic reminders of "expert-authoreds are reliable", "don't use this for exceptional claims", "prefer other sources", etc., which apply to all sources at such levels of community trust. Aaron Liu (talk) 11:52, 12 May 2025 (UTC)
  • If anything, we should get rid of green. The major problem I think, is green becomes: 'go, don't think about it, how its used, or what for.' Alanscottwalker (talk) 18:51, 10 May 2025 (UTC)
    • The purpose of green is "stop bringing querulous arguments to RSN" - since the purpose of RSP is to document consensus from RSN. Obviously this won't work on the sort of person who needs to hear it, but at least others tell them to go away in fairly short order. It's also useful for cases like Sky News Australia (fringe source) versus Sky News UK (normal NEWSORG) - David Gerard (talk) 21:22, 10 May 2025 (UTC)
      None of that requires green. Alanscottwalker (talk) 21:54, 10 May 2025 (UTC)
  • Like I said at the idea lab, apart from the detail of the specific colors used I support this proposal, and disagree strongly with the suggestion that no consensus is the same, either formally or practically, as a consensus that additional considerations apply.
    "No consensus" is a lack of guidance either way as to whether a source is reliable. "Additional considerations apply" is not just not a lack of guidance, it's often much more and more specific guidance than we have for most sources. They are total opposites and do not in any way imply the same thing, and the fact that some people appear to have the misconception that they do is in my view even stronger evidence for splitting them. Loki (talk) 21:44, 11 May 2025 (UTC)
  • If we decide that there is no consensus on how to rate a source, then it seems to me that is covered by Option 2, having a specific no consensus option will just result in many sources being labelled as that, which I don't think is particularly helpful in resolving the question of whether the source is usable, if people think the source is not reliable then !vote that, if reliable, that and if not sure, then option 2 works. Selfstudier (talk) 12:21, 12 May 2025 (UTC)
    I don't want a specific no consensus option either. I thought the current predominant RfC options list included "No consensus" as option 2 (as seen in the 2024 Telegraph RfC) instead of "Additional considerations apply"/"Marginally reliable". Also, this would probably change the number of option 2 since it's a different scale. We would probably see something like "Option 1: GRel, Option 3: GUnRel, Option 4: Deprecate, Option A: Additional considerations". Aaron Liu (talk) 13:24, 12 May 2025 (UTC)
  • Still not sure if this would be improper, but hopefully it isn't; Pinging participants of August 2024 discussion: @Barkeep49, Levivich, Chess, Selfstudier, and Barnards.tar.gz:. Thryduulf, ActivelyDisinterested, and LokiTheLiar also participated but are already here.
    Another example of the stigma associated with the current combination can be found in a discussion on Vox's opinion content. Most participants later rejected the premise that there was an additional consideration for Vox, but that doesn't make exchanges like these any less exemplary of the hesitance to label additional considerations as additional considerations thanks to its current grouping that seemingly makes it insinuate, emphasis mine:

    I agree Vox tends to wear its opinions on its sleeves, but when you distill out the facts, they are still reliable and engage in proper editorial practices. As more and more sources take this type of accountability journalism approach, I think we can't rule out their reliability, just know when the writer is speaking in a subjective voice versus an objective voice (eg per WP:YESPOV). We need editors to be fully aware of how to use such articles, not only from Vox but other sources in the future.
    — User:Masem 15:03, 3 December 2021 (UTC)

    Do you think it should be yellow to alert editors to this? I fear if it's green, editors will just adopt it in wikivoice without question, and any editor who questions that will be told it's green at RSP, end of discussion.
    — User:Levivich 15:21, 3 December 2021 (UTC)

    Given that what's happening with Vox is indicative of many other nominally reliable sources, I don't think it should change as the source is still good, but one just has to be more careful of what's included in wikivoice.
    — User:Masem 16:05, 3 December 2021 (UTC)

    The current grouping also causes newcomer confusion in reading things; when Jacobin was changed to no consensus, TarnishedPath said: I've changed it back to Green, as your own close found no consensus for additoinal considerations. Aaron Liu (talk) 20:10, 13 May 2025 (UTC)
    TarnishedPath's action there was objectively wrong, per the explicit description on the page and the outcome of the various Telegraph discussions. If someone does not understand rules written in plain English then that is a problem with the person not the rule. Thryduulf (talk) 23:21, 13 May 2025 (UTC)
    Like I said, newcomer confusion. It's not too hard to assume—from the current RfC options layout of "1: GRel, 2: Additional considerations apply, 3: GUnRel" combined with the "traffic lights" coloring scheme—that yellow means considerations apply. Aaron Liu (talk) 01:06, 14 May 2025 (UTC)
    People should familiarise themselves with the instructions and descriptions before commenting. If someone does comment before doing so and gets it wrong then we should educate them that they have got it wrong. If they don't read the current simple plain English descriptions why should we assume they would read the descriptions for the proposed, more complicated system? Thryduulf (talk) 01:38, 14 May 2025 (UTC)
    Because it's purple, which is not a color between red and green. Aaron Liu (talk) 01:59, 14 May 2025 (UTC)
    You're going to have to try something other than complete non-sequiturs if you want to convince me that more complicated ways of conveying the same information will improve problems caused by people not bothering to read plain English descriptions of a very simple system. MREL and no consensus are both between red and green: they are neither generally reliable nor generally unreliable. Thryduulf (talk) 02:11, 14 May 2025 (UTC)
    Indeed it is below GRel, but practically it's too different from "no consensus" to get the removal treatment; nearly always the additional considerations want one to treat a source the same as GRel with exceptions, while yellow indicates that the source as a whole should be treated below GRel. For example, no-consensus sources should not be cited by exceptional claims nor preferred over other no-consensus sources, and GRel sources are preferred over no-consensus sources. Such is not the GRel treatment deserved by sources with additional considerations while a usage does not fall under an exception.
    This yellow grouping lumped with the no-con treatment is a misleading signal, and this proposal's purpose is to address this misleading signal, while making additional considerations less stigmatizing for RfCs to conclude in. With purple, there is no way to assume—from the [proposed] RfC options layout of "1: GRel, 2: Additional considerations apply, 3: GUnRel" combined with the "traffic lights" coloring scheme—that yellow means considerations apply. Yellow would not be assumed to be additional considerations as the latter's no longer on the scale of survey options. This solution does not introduce additional pathways for assumptions. I see no way one could infer a wrong meaning and skip the legend when seeing the purple color, while as described above it's natural to assume if additional considerations is put on the traffic-lights scale. You could describe a way that TarnishedPath could plausible stumble into. Aaron Liu (talk) 03:05, 14 May 2025 (UTC)
I support this proposal.
The purpose of "additional considerations apply" is editor can't oppose the use of a source solely because it's WP:MREL, an editor has to explain why the "additional considerations" apply in this situation to make the source unusable.
For example, MREL for WP:XINHUA means avoiding it if the Chinese government might have a motive to use it for propaganda or disinformation. It would be disruptive to remove it from articles where that wasn't present.
However, the current practice of "no consensus = WP:MREL" is any editor can oppose the use of a source solely because it is WP:MREL and give no further justification, because the "additional considerations" were never agreed upon. Chess (talk) (please mention me on reply) 05:13, 15 May 2025 (UTC)
Support per Chess. One is a consensus for (more or less specific) acceptable uses, the other is a lack of consensus, and they play out very differently in practice. Chaotic Enby (talk · contribs) 17:37, 15 May 2025 (UTC)
Support per Loki and the convincing arguments of the nominator throughout the discussion. Choucas0 🐦‍⬛⋅💬⋅📋 23:05, 28 May 2025 (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.

Stale Drafts in User Space

I see that about a week ago there was a discussion about notification of stale drafts in draft space. There are also stale drafts in user space. There are currently about 39,500 pages in user space that are labeled as drafts but have not been edited in twelve months (and so would have been purged from draft space). I have proposed at Bot Requests that a bot notify the originators of these drafts, if the originators are in good standing, and produce a report listing stale userspace drafts by blocked users (some of whom may be subject to G5). Robert McClenon (talk) 16:21, 27 May 2025 (UTC)

What problem are you trying to solve here? AFAIK there has never been a consensus for anything like G13 applying to userspace. Thryduulf (talk) 16:42, 27 May 2025 (UTC)
Two of the three cases for use outlined at WP:G13 involve userspace. 204.111.137.20 (talk) 04:07, 30 May 2025 (UTC)
Not for the vast majority of userspace content. Thryduulf (talk) 09:35, 30 May 2025 (UTC)
True, but when labeled as drafts with the AFC submission template, or containing nought but the article wizard text, they are. That is the problem that Robert McClenon is trying to solve. 204.111.137.20 (talk) 16:41, 30 May 2025 (UTC)
No those aren't the problem @Robert McClenon is trying to solve, because they are already deleted under G13. This must be for content that isn't eligible for an existing process and I'm asking what problem these pages are causing such that we need a process to deal with them (and haven't received an answer). Thryduulf (talk) 17:18, 30 May 2025 (UTC)
Well I must be misunderstanding then, because generally unless explicitly labelled as something more specific, userspace content is merely treated as random miscellany, sandboxes, essays, collections of links etc. 204.111.137.20 (talk) 18:37, 30 May 2025 (UTC)
Pages such as User:Arilang1234/Draft/Comrade Chiang Ching are clearly drafts of articles (I have not even attempted to evaluate that example for quality, notability, etc). It's entirely unclear to me though what problems pages like that are causing such that they need to be dealt with, nor what Robert McClenon is proposing to do with them. Thryduulf (talk) 19:40, 30 May 2025 (UTC)
I know that people already receive notifications for stale draftspace pages they created, if that isn't already being done for userspace pages with the AFC submission template it should be. For other userspace pages I agree that even if clearly a draft of some kind that notifications would be without a clear purpose except perhaps to nag. Though it may be I'm missing something that came up in the discussion that prompted this post which is not linked and I have no ability to find. 204.111.137.20 (talk) 02:38, 31 May 2025 (UTC)
The prior discussion referred to might be #Real warning on stale drafts further up this page, but I don't see anything there that answers the questions we have here. Thryduulf (talk) 02:46, 31 May 2025 (UTC)
I'll just note that I recently moved an article (Pine Island Canal) to main space that I started as a sub-page (although not labelled with a "draft" template) 11 years ago, and which went un-edited for 6 years. I presume that by your standards it should have been deleted long ago. I do not believe I ever abandoned that draft, I just often had trouble finding the time and interest to work on it. Donald Albury 18:01, 27 May 2025 (UTC)
I think we should be deleting less drafts, not more of them. If a page has no useful encyclopedic information, then sure I'd understand deletion. But our wiki is a work in progress and if someone can only make a draft, then they make the stepping stones for the next editor. JackFromWisconsin (talk | contribs) 18:25, 27 May 2025 (UTC)
What do you (Robert McClenon) propose that such originators in good standing do with the notifications? Didn't we used to recommend that users move draft articles to user space if they want to avoid WP:G13? Don't we still do that? I know what I would do with such a notification from a bot, but I don't think it would be very civil. Phil Bridger (talk) 19:55, 30 May 2025 (UTC)
I am being asked by several editors what problem I am trying to identify, and what I am proposing to do. I think that I have identified one interesting situation, and, in a way, two problems. The interesting situation is that there are 39,525 userspace drafts that have not been edited in one year. I am not labeling it as a problem. One of the two problems is that some editors think that the existence of 39,525 stale drafts is a problem, and want to do something about it, such as review the drafts manually and send some of them to MFD. That is a problem because it wastes the time of the reviewers at MFD, many of whom also improve articles or review AFC drafts or gnome categories, and many of whom also have day jobs. The only solution that I know for that problem is for the reviewers at MFD to Keep the drafts and to tell the nominators to stop ragpicking. The problem that I am proposing to address is that some of the drafts have been forgotten by their authors, who may either want to take another look at them, or realize that they don't have a use for them any more. The purpose of the bot is to notify the authors of the forgotten drafts that the drafts are there. I know that I sometimes start work on things and forget about them. I am not proposing that the drafts be deleted, unless the author chooses to tag them with U1 and/or G7. Robert McClenon (talk) 02:47, 31 May 2025 (UTC)
User:Phil Bridger writes: I know what I would do with such a notification from a bot, but I don't think it would be very civil. Why not just delete it? Deleting a notification from a bot isn't uncivil. I can see that some authors would want to opt out of receiving the notifications, and that is a feature that can be discussed in the bot approval process. Robert McClenon (talk) 02:47, 31 May 2025 (UTC)
Does that answer the questions? Robert McClenon (talk) 02:47, 31 May 2025 (UTC)
So to be clear, you are proposing a bot to provide periodic notifications to the creator of every page in Category:Stale userspace drafts? 204.111.137.20 (talk) 02:54, 31 May 2025 (UTC)
Does the theory of change sound something like this?
  • I'll post a note on the User talk: page that says "Hey, you haven't edited User:Example/sandbox in a long time",
  • So they will notice the message,
  • So they will improve the article,
  • So they will remove the AFC template,
  • So Category:Stale userspace drafts will have fewer pages in it,
  • So some editors will stop complaining about the existence of unfinished drafts,
  • So I won't have to listen to complainers complaining about other people not finishing everything they start.
Because even if I thought that last one was worthwhile, the second one probably isn't going to work in a large fraction of cases.
In terms of a BOTREQ, I suggest not spamming long-inactive editors and/or accounts with no e-mail address. There's no point in trying to reach inactive editors by posting on their talk pages.
The process that I think would actually be effective is:
  • Edit Category:Stale userspace drafts to clearly explain that the purpose of this category is to help currently active editors (e.g., anyone complaining about the existence of drafts in that cat) find drafts that they might want to adopt and finish themselves. Perhaps we could even rename the cat to something like "Userspace drafts that may be available for adoption".
WhatamIdoing (talk) 03:13, 31 May 2025 (UTC)

On redirect from mis/other capitalization tags

Sometimes editors have a disagreement about whether a redirect would be more appropriately categorized as R from other capitalisation or R from miscapitalisation. This proposal is for a guideline to help decide which to use when there are such disagreements:

For articles that have been through an RM or similar discussion on capitalisation, considering various factors such as WP policies and guidelines, common and official name usage in sources, etc., and a consensus on the title capitalization has been reached, redirects from different discussed capitalizations should be tagged R from miscapitalisation. Where such discussions have occurred without reaching a consensus, the redirects should be tagged R from other capitalisation. Where no such discussions have occurred, changes from one to the other should not be done without a solid reason and discussion, at least with the editor who originally placed the tag.

Dicklyon (talk) 18:29, 19 May 2025 (UTC)

I don't necessarily agree, some redirects can be valid alternate capitalisations but not be the primary one or the one Wikipedia ends up favoring (thinking of "official" examples at MOS:TM for instance), and they shouldn't be tagged as "miscapitalisations" just because they went through a RM. Chaotic Enby (talk · contribs) 18:45, 19 May 2025 (UTC)
That's essentially what I've been trying to say. But for some reason there's an obsession with adding redirects to a specific maintenance report, and completely ignoring WP:NOPIPE. Additionally, Dicklyon has now created a new template that adds redirects to the miscapitalization category while using language that is already reflected in the R from other capitalization template. Hey man im josh (talk) 17:28, 21 May 2025 (UTC)
That was more or less the intent, and pretty much as Thryduulf suggested, though the language around "non-preferred" is significantly different from that at "other". Dicklyon (talk) 01:36, 22 May 2025 (UTC)
Prior discussion was at Template talk:R from miscapitalisation#Template intent. In context, we're talking about something that matters to approximately zero readers, so the calculation here should be to maximize usefulness to editors. If an article links a redirect that is an error according to Wikipedia style, the error should be fixed, regardless of how the capitalisation would be classed by some other style guide. The proposal here would make the miscapitalisation rcat useful for tracking and fixing those errors.
As a distant second choice, I would support a proposal to clarify that the miscapitalisation rcat is only to be used for errors that would be erroneous under any reasonable style, like Gospel of mark. The option I oppose most here is the unclear status quo, which has led to too much strife over something that matters to zero readers. Firefangledfeathers (talk / contribs) 18:53, 19 May 2025 (UTC)
In context, we're talking about something that matters to approximately zero readers, so the calculation here should be to maximize usefulness to editors. +1—Bagumba (talk) 09:01, 20 May 2025 (UTC)
I agree, however, in this case, it's very clear far too many redirects that are very clearly not errors in capitalization are being tagged as such. Hey man im josh (talk) 17:30, 21 May 2025 (UTC)
I agree with Chaotic Enby. Just because there has been an RM doesn't mean that capitalisations not chosen are wrong - not even if you define "wrong" as "not in accordance with the English Wikipedia's style guideline" rather than "always wrong". Iff there is some value to editors (who? why?) in tracking things that are incorrect in the eyes of editors who deeply care English Wikipedia's style guidelines (which is a very small subset of all editors) regardless of what the real world says, then there should be three categories of redirect - one for capitalisations that are always wrong, one for capitalisations that are (sometimes) correct in the real world but not on Wikipedia and one for capitalisations that are (sometimes) correct in both places. If there is no desire for a three-category system, then the only correct answer imo is the status quo. If people are being disruptive about it then the solution is topic bans and similar until they learn not to waste editors' time on something that has approximately zero benefit to readers. Thryduulf (talk) 20:30, 19 May 2025 (UTC)
When a redirect such as Computer Science that is tagged as R from miscapitalization is linked in an article, it shows up in a category and maintenance report. Sometimes the right fix to get if off the list is not to simply lowercase it. For example, in "Department of Computer Science", the capitalization is correct (assuming that's from the proper name of a department), but the fix would be either to restructure the link (avoiding linking words within a proper name is generally a good idea), or to pipe the link, avoiding the miscapitalized redirect. The other alternatives are less satisfactory: (a) not tagging the redirect as a miscapitalization would mean many errors would be harder to find and fix; (b) leaving the link as is would mean it keeps showing up in the maintenance categories and reports, diluting their usability. Many redirects from moves are like this. Marking them as miscapitalizations is still the usually best thing to do. And this guideline was really only for cases where editors disagree; if there's a general consensus that "other" is more appropriate than "mis", of course that's what will be used. When well-intentioned editors disagree which is best, as with NFL Draft, it seems better to stick with previously established consensus than to make a big deal about it and start a new big argument. Dicklyon (talk) 04:14, 20 May 2025 (UTC)
Per WP:NOPIPE, it is generally not good practice to pipe links simply to avoid redirects. Certes (talk) 10:00, 20 May 2025 (UTC)
No, and I'm not suggesting "simply to avoid redirects". I'm suggesting it as a way to avoid a miscapitalized redirect, or any redirect that shows up on a maintenance report if there are links to it. Those are worth changing, if we want maintenance reports to be useful. Dicklyon (talk) 14:34, 20 May 2025 (UTC)
It's absolutely not worth changing and it's floods watchlists unnecessarily. It's not a productive use of time, and it's literally why WP:NOPIPE exists. Hey man im josh (talk) 14:29, 21 May 2025 (UTC)
There is literally nothing in WP:NOPIPE that bears on this question. Dicklyon (talk) 15:15, 25 May 2025 (UTC)
Then the maintenance report should be changed to avoid listing cases where WP:NOPIPE tells us that the current wikitext is correct and no change is desirable. If that's the report's sole purpose, bin it. There are plenty of actual problems of other types to find and fix. Certes (talk) 09:30, 25 May 2025 (UTC)
I support that idea of fixing the report to ignore piped links, which would make it more useful for its main purpose. This is only tangentially related to the question that brought us here. Dicklyon (talk) 15:15, 25 May 2025 (UTC)
But that's what Dicklyon does @Certes, they frequently do so in order to make the numbers go down on the maintenance report they're obsessed with. Hey man im josh (talk) 14:28, 21 May 2025 (UTC)
No, I (almost) never pipe links to avoid redirects. See if you can find an example of me doing that. Dicklyon (talk) 17:47, 27 May 2025 (UTC)
Department of Computer Science: Tangential to the main purpose of this discussion, but MOS:LINKINNAME says: "Do not place a link to a name within another name. For example ... Do not write: [[Gilbert du Motier, Marquis de Lafayette|Lafayette]] Avenue → Lafayette Avenue —Bagumba (talk) 10:13, 20 May 2025 (UTC)
  • This is not very complicated. Here was an RfC I'd suggested at Dicklyon's talk page: "If a lowercased page name, such as NFL draft, has an uppercased redirect (NFL Draft) which is the actual official name of the topic, should the official name be labeled a 'capitalisation error' by Wikipedia?" Any guideline should include clear language to not label official names, well-sourced names, or names often uppercased, as "capitalisation errors" in Wikipedia's voice. Randy Kryn (talk) 03:27, 20 May 2025 (UTC)
    Obviously the basis of that RFC wording presumes something about "Wikipedia's voice" telling others that they are wrong to capitalize. This is not at all what these maintenance templates are for. They put things in categories to be worked on. They do not put anything into the reader-visible article space. Dicklyon (talk) 03:54, 20 May 2025 (UTC)
Since an uppercased redirect appears in visible space at the top of the article (see NFL Draft's redirect to NFL draft, top of page just under the title), some readers undoubtedly click on it. At that point the redirect page becomes, automatically, visible space, with text in Wikipedia's voice. Randy Kryn (talk) 04:05, 20 May 2025 (UTC)
Obviously a reader can get to it if they click the right places. If that's bothersome we could tweak the messaging in the template to clarify that it's the wrong capitalization for Wikipedia, with no implication for the outside world. Dicklyon (talk) 04:17, 20 May 2025 (UTC)
Also, your inclusion of "actual official name of the topic" seems like a re-hash of an argument lost to consensus. A very biased RFC proposal, imho. Dicklyon (talk) 04:19, 20 May 2025 (UTC)
Would the following wording be more neutral?

Should redirects from official names that do not match Wikipedia title guidelines (such as NFL Draft redirecting to NFL draft) be tagged with {{R from other capitalisation}} or {{R from miscapitalisation}}?

Chaotic Enby (talk · contribs) 06:08, 20 May 2025 (UTC)
@Chaotic Enby Yes, that is neutral, though I would replace the word "title" with "capitalization" to be clear. Toadspike [Talk] 06:45, 20 May 2025 (UTC)
That does sound clearer indeed! Chaotic Enby (talk · contribs) 06:46, 20 May 2025 (UTC)
I see "official" causing problems in future. "Not an obvious error" or something similar would be better, i.e. NFL Draft (= other) vs NFL dRaFt (= incorrect). Scribolt (talk) 06:50, 20 May 2025 (UTC)
No. First off, it's about more than official names. Sometimes the article is at the official name and there's still disagreement over the redirect with different capitalization. Second, the MOS is already clear that official name is not part of determining WP's capitalization style. Third, there's often disagreement about what the official name is, with some editors claiming "official name" status for terms just because they appear in a list capitalized somewhere. Giving "official" names special status is contrary to the guideline of avoiding unnecessary capitalization. Fourth, sometimes the "official name" is not really the topic (e.g. the official name of the televised show "NFL Draft" is real, but the NFL draft topic is not really that; as mentioned above, in the rare event that a capitalized version of the name is needed and is linked, a pipe to avoid the miscapitalized redirect can be used, as the best alternative that doesn't destroy the whole purpose of these maintenance categories). Dicklyon (talk) 06:51, 20 May 2025 (UTC)
Thanks. I'm less focused on the arguments for or against the change, and more on how to properly word the RfC question if it comes to that, but I see that the "official name" thing might be a bit of a red herring.

Should redirects from names that are not obvious errors but do not match Wikipedia capitalisation guidelines (such as NFL Draft redirecting to NFL draft) be tagged with {{R from other capitalisation}} or {{R from miscapitalisation}}?

Chaotic Enby (talk · contribs) 06:59, 20 May 2025 (UTC)
I'd stay away from mentioning specific templates, as that is just one possible solution. Perhaps there's alternatives outside of reusing those templates, as some editors seem to attribute an ideological "right" or "wrong" from a grammar perspective. {{R from miscapitalisation}} says:

Pages that use this link should be updated to link directly to the correct form without using a piped link hiding the correct details

For Wikipedia maintenance purposes, how can we track such links—where the Wikipedia consensus is to change the case—for attention? If not "R from miscapitalisation", what are alternatives? —Bagumba (talk) 09:16, 20 May 2025 (UTC)
Yeah that's pretty clearly not an error in capitalization. This is exactly why we have the r from other capitalization template. Hey man im josh (talk) 14:24, 21 May 2025 (UTC)
  • This clearly has nothing to do with RM. Also, "miscapitalised" is different from "does not follow Wikipedia's current style guide". 2 june is a miscapitalisation, Qixiaying Railway Station (the article has been moved both to and from that version) is not. —Kusma (talk) 10:39, 20 May 2025 (UTC)
    I understand that difference, but it's not very relevant to the purpose of the miscapitalization tag, which is to put things in maintenance categories and reports so they're more likely to get fixed. Maybe there's a better name for it? Dicklyon (talk) 14:34, 20 May 2025 (UTC)
    And the point of RM and such discussions is just that that's where consensus may have been established for which capitalization is right for Wikipedia. It becomes relevant when editors otherwise disagree and a record of consensus exists (e.g. with NFL Draft being wrong for Wikipedia). Dicklyon (talk) 14:36, 20 May 2025 (UTC)
    No, that difference is very relevant. I was leading the charge for clearing out Wikipedia:Database reports/Linked miscapitalizations before you came along there. Back on 13 January 2023 I had the list down to as few as only ten items. It had over 1,000 items in September 2022, before I started my last push to clear it out. Now, since you've pushed your extreme MOS interpretation of proper names that aren't proper names, and prohibition of uses of title case that are widespread outside of Wikipedia – and formerly common on Wikipedia – onto the list, I've abandoned the project. Just as well, the editors tagging misspellings are pushing the project's limits on gnome capacity so as to take away any time I might have had to systematically fix miscaps in the past. – wbm1058 (talk) 16:05, 20 May 2025 (UTC)
    I'm sorry that you abandoned it @Wbm1058, but I appreciate your efforts to focus on actual miscapitalizations and correct them, as opposed to over inclusion of what are actual legitimate alternative capitalizations. Hey man im josh (talk) 17:54, 21 May 2025 (UTC)
    You've not made these more likely to get fixed. Quite the opposite. You had to bump the report limit from 1,000 to 2,000 to make room on it for everything. If everything is broken, then nothing is broken. Project abandoned. – wbm1058 (talk) 16:16, 20 May 2025 (UTC)
    I actually had it down to a pretty small number for a while, too, when I was using JWB (down to 295 last September compared to 518 last May and over 1500 now). Recently Hey man I'm Josh has been pumping it up with things that I don't consider to be errors (at the same time as not letting me add thing that there is a consensus are not right). And there's still a lot of move cleanup pending, which few people are helping with, and this report helps track that, if we use it right. Dicklyon (talk) 05:00, 21 May 2025 (UTC)
    I'm always available to discuss what may be perceived as an error, but you had it nowhere close to being finished when I started tagging more redirects. Additionally, your usage of JWB, and your refusal to actually listen to the criticism offered and adjust your usage caused you to be banned from automated tool usage altogether. Your subsequent appeal a month or two ago was also denied by the community.
    Additionally, there's obviously been no consensus that a name regularly used by others that doesn't conform with Wikipedia's style guidelines is an error. Hey man im josh (talk) 17:52, 21 May 2025 (UTC)
    Yeah I'm struggling to see where the confusion comes from @Kusma.
    {{R from other capitalisation}}: From other capitalisation: This is a redirect from a title with another method of capitalisation. It leads to the title in accordance with the Wikipedia naming conventions for capitalisation, or it leads to a title that is associated in some way with the conventional capitalisation of this redirect title. This may help writing, searching and international language issues.
    {{R from miscapitalisation}}: From a miscapitalisation: This is a redirect from a capitalisation error. The correct form is given by the target of the redirect.
    They seem pretty straight forward already, one is a clear error and the other is meant to conform with Wikipedia guidelines, but may be acceptable in other situations. This is why I oppose a third category. I've had a tough time understanding the issue for over a year now, except that Dicklyon wants to bypass a lot of redirects and one template encourages this while the other says not to do so (WP:NOPIPE). Hey man im josh (talk) 17:38, 21 May 2025 (UTC)
    @Hey man im josh: I have never particularly cared about the categorisation of redirects. Anyway, I looked through the "miscapitalisation" category and found many redirects that seemed to be from perfectly acceptable other capitalisations (I gave one example of a Chinese railway station above), so should anyone care about these categories, they would need to be cleaned up before they can be mechanically used. Generally, systematically bypassing redirects (even those where this would be an improvement) seems to be an activity that can wait until Wikipedia runs out of serious multi-year backlogs, so putting an infrastructure in place for this probably can be safely postponed for another decade or two. —Kusma (talk) 22:30, 21 May 2025 (UTC)
    ... seems to be an activity that can wait until Wikipedia runs out of serious multi-year backlogs ...: Wikipedia is not compulsory—there's no schedules, no assignments, no KPIs for page views per characters added, etc. Nobody is obligated to get vital articles to FA first, nor is anyone a slave to edit in relation to project importance assessments. —Bagumba (talk) 04:58, 22 May 2025 (UTC)
  • Any redirect that uses capitalisation different from the target is alternative capitalisation - including miscapitalisation. I don't think we need an extra template/category. I don't think we need both of the ones we have. We should just modify the "alternative capitalisation" - that it includes a multitude of sins of varying degrees. Cinderella157 (talk) 11:26, 21 May 2025 (UTC)
    But not every alternative should be "fixed". The "miscapitalization" tag has always been to track the ones that should be, typically as part of RM cleanup. Personally, I don't see a need for any further discrimination of alternatives. Dicklyon (talk) 15:31, 21 May 2025 (UTC)
    Yes, {{R from miscapitalisation}} requires an action:

    Pages that use this link should be updated to link directly to the correct form without using a piped link hiding the correct details.

    {{R from other capitalisation}} doesn't necessarily need a change to the link.—Bagumba (talk) 18:22, 21 May 2025 (UTC)
    Dicklyon, as I understand it then, the template (miscapitalisation) and associated category is used to amend links in articles so that they link directly rather than through a redirect. Does this not equally apply if a link in an article is to an "alternative capitalisation"? Cinderella157 (talk) 00:21, 22 May 2025 (UTC)
    It doesn't directly amend links, but lets interested editors know what they can work on. Many of the ones marked "other" really should be marked miscapitalization (or non-preferred capitalization) and should get fixed. But not all. In particular, a huge number of "other capitalization" redirects from lowercase have been created for article titles that are over-capitalized and have never been discussed (because, sadly, many article creators don't know to choose sentence-case titles, and then when people try to link they get red links, so they create the redirects). Sometimes when I find those I move the article title to lowercase and mark the over-capitalized redirect. But until someone actually looks at or discusses the capitalization question, it's just "other". And some others may genuinely have both lowercae and uppercase correct forms (though I don't recall why right now). Dicklyon (talk) 00:31, 22 May 2025 (UTC)
  • FYI, here's an example case I fixed, when I was working this beat: 30 links to jpegjpeg. Not everything is miscapitalized when it's using uppercase that the MOS patrol want to downcase. Some cases are where lowercase redirects should be bypassed to capitalize them. But I consider this work to be lower priority than correcting actual A–Z misspellings. – wbm1058 (talk) 18:39, 21 May 2025 (UTC)
    Indeed, fixes in that direction (e.g. United states -> United States) are still widely needed, and uncontroversial. I do a lot of those, too. But recently Josh has been tagging lowercase things as miscapitalizations even when a discussion has taken place and there's clearly no consensus for his claim of proper name status. He wants his way, both ways. E.g. List of schools in the Auckland region, where there's no consensus that "Auckland Region" is a proper name, just because an administrative unit of the name exists. The RM discussion close was very clear that there was no consensus (after an earlier close in which a consensus to lowercase was found). Dicklyon (talk) 00:52, 22 May 2025 (UTC)
    tagging lowercase things as miscapitalizations: Those are more likely to be "other capitalisation" and not errors, because a lot of them can be linked as basic English phrases using common nouns. Consider: Green Bay Packers quarterback Aaron Rodgers, a four-time N.F.L. most valuable player ...[9] While there is capitalized NFL Most Valuable Player, editors can choose to write it with basic English, without capitalization, and it reads just fine in lowercase. A lowercase redirect there could legitimately be "other capitalisation", not a miscap, if we are going to consistently apply this "outside Wikipedia" argument. (I still argue that these redirect cats are hidden categories for Wikipedia internal use only.)—Bagumba (talk) 03:39, 2 June 2025 (UTC)

Three categories?

I'm actually warming up to Thryduulf's suggestion of having a third category, capitalizations that may be OK in other styles but are not in accord with WP's capitalization guidelines. If someone is willing to work on creating such templates, and fixing up the reporting machinery to make a report on "linked not-ideal capitalization redirects" or whatever we'd want to call it, I'd be willing to help and give it a try.

That doesn't solve all the problems here (e.g. where Josh wants to label Water supply in the Wellington region as a miscapitalization, even though there has never been a consensus for capitalizing Region there, and even though the lowercase is dominant in the outside world, just because there is an official name Wellington Region, for which there is also no consensus for capitalization, after discussion at RM). Should we have yet another category for that kind of thing, whatever it is? Links to these don't need to be on a maintenance report, since there's no reason to change them. Dicklyon (talk) 14:53, 20 May 2025 (UTC)

I suppose it would be helpful at this point to agree on what types of capitalisations differences exist (numbered for ease of reference only)
  1. Capitalisations that are always incorrect (e.g. 4 june)
  2. Capitalisations that are always incorrect in some contexts but always correct in others, examples include
    Where a phrase is both a proper noun and a common noun (sometimes there is disagreement about whether something is or is not a proper noun)
    Where something is a term of art in some professions but not others
    Differences between different (national) varieties of English
    Differences between audiences, e.g. legal English will correctly capitalise some terms that are correctly not capitalised in lay writing (even by the same author)
    Different cultural contexts, e.g. an adherent of a particular religion may capitalise a term that non-adherents do not
  3. Capitalisations that are always incorrect in some contexts but about which there are differing opinions in others (e.g. NFL Draft is correct for the TV programme, but opinions differ regarding the event).
  4. Capitalisations that are correct or incorrect depending on stylistic choices (e.g. SEE MONSTER vs See Monster)
    For some of these there is disagreement on which is correct on Wikipedia
    This means there are cases of capitalisations that are unambiguously incorrect on Wikipedia but correct in (some) real world contexts (e.g. for trademarks)
  5. Multiple capitalisations are in free variation, with none being particularly more common
  6. Multiple capitalisations, one is significantly less common but not incorrect where it is used
    This can vary over time, in both directions.
We don't need six (or more, I may have missed some) categories but as long as we have more than one we need to decide which belong in which. Thryduulf (talk) 18:07, 20 May 2025 (UTC)
It really boils down to two categories:
  1. Capitalisations that are always incorrect (e.g. 4 june) – these the gnomes will correct.
  2. Capitalisations that may be incorrect in some contexts (this is for all the MOS-enforcement stuff, i.e. uses of title case and disputed proper names) – these the gnomes will ignore.
Because gnomes will ignore #2, there was no need to create such a category before, but apparently now there is a need. – wbm1058 (talk) 18:26, 20 May 2025 (UTC)
OR… Gnomes simply need to remember the banner at the top of every MOS page… the one where we say “exceptions may apply”.
Gnomes do wonderful work (thank you), but they do tend to get myopic. When they get pushback on an edit, we need consider that we may have bumped into one of those “exceptions”. Blueboar (talk) 19:00, 20 May 2025 (UTC)
Hey, if you wanna see some of the somewhat annoying "pushback" I've gotten lately, checkout the bottom of my talk page at the moment. I stick to the maintenance categories that the non-administrator executive editors have declared to be "always incorrect", and sometimes push back by changing their categorization of the redirect to make it a valid alternative form rather than incorrect. – wbm1058 (talk) 19:43, 20 May 2025 (UTC)
Speaking as a capitalization gnome, I can assure you I don't ignore things that are incorrect in WP, and I'm generally alert to exceptions. I rely on the categorization/reports to keep me in over my head with work to do. Dicklyon (talk) 04:55, 21 May 2025 (UTC)
If the categories are hidden then it would be best to leave discussion to the people who actually use them, rather than the rest of us tell them how they should use them. Phil Bridger (talk) 20:07, 20 May 2025 (UTC)
You're such a dreamer. Yes, it would be nice. Dicklyon (talk) 21:04, 20 May 2025 (UTC)

I made a new "R from non-preferred capitalisation" template, and tried it out (see Midland Line, New Zealand). It still populates the same category and gets picked up on the same reports, but avoids doing what Randy is complaining about. Seems to work. So I'll just use that for now for the things where the consensus is that they're not right caps for WP. Dicklyon (talk) 05:37, 21 May 2025 (UTC)

If that's the needed compromise,then c'est la vie. I never perceived the issue that some others did. These types of categories read:

This is a maintenance category, used for maintenance of the Wikipedia project. It is not part of the encyclopedia and contains non-article pages, or groups articles by status rather than subject ... These categories can be used to track, build and organize lists of pages needing "attention en masse" (for example, pages using deprecated syntax), or that may need to be edited at someone's earliest convenience.

They never seemed to me to be a universal grammar reference. —Bagumba (talk) 05:59, 21 May 2025 (UTC)
Ahem. The title of this section is Three categories? Not three templates. If you just have Template:R from non-preferred capitalisation populating Category:Redirects from miscapitalisations, you haven't solved anything from a maintenance standpoint. You need to make that template populate Category:Redirects from non-preferred capitalisations to make this a substantive difference. If you do, I might find time to work Category:Redirects from miscapitalisations again. I'm highly unlikely to ever help clear Category:Redirects from non-preferred capitalisations as my time is oversubscribed and I need to get better at setting priorities. It's too bad that you can't clear this category without using bull–in-a-china-shop meat-bot editing tactics. wbm1058 (talk) 13:19, 21 May 2025 (UTC)
... you haven't solved anything from a maintenance standpoint ... But it solved the non-maintenance issue some raised about the mere presence of the word miscapitalisation if a reader actually clicked on the redirect. —Bagumba (talk) 07:37, 22 May 2025 (UTC)
@Wbm1058: I'm ready and willing to make the trivial edit to change what category the template populates, when you or someone is ready with the report making. Let's talk. Dicklyon (talk) 16:00, 30 May 2025 (UTC)
  • capitalizations that may be OK in other styles but are not in accord with WP's capitalization guidelines That's literally what the R from other capitalization is meant to be for, so a third template is entirely unnecessary. R from other capitalization and R from miscapitalization are already in existence, their usage cases are quite clear. Hey man im josh (talk) 14:24, 21 May 2025 (UTC)
    I think putting all the "R from other" redirects with incoming links on a report of things to fix would be not what's intended for those. But I do agree than many of those would be better as "R from non-preferred" so we'd track links to them in those categories and reports of things worth fixing. Dicklyon (talk) 15:27, 21 May 2025 (UTC)
    The documentation says that pages tagged are added to miscapitalization category it's pretty clearly gaming and not appropriate to add many of these to that category, especially just for your pet obsession of one report. Hey man im josh (talk) 16:37, 21 May 2025 (UTC)
    It was easier to use the existing category than to rewrite the report to draw from a different category that could be called non-preferred. This was the minimal fix to address Randy's complaint. I agree that not every "other" capitalization should be put into this category. I would not object if you or someone wanted to help migrate to something more evolved, as long as it still supports the maintenance reporting. Dicklyon (talk) 06:12, 22 May 2025 (UTC)
  • This new template is inappropriate, as it still tags pages as miscapitalizations instead of alternative capitalizations... I strongly oppose it's usage, especially considering it states that redirects pointed to these redirects should be bypassed. What are you not understanding about what defines an error??? This is so fucking exhausting and clearly WP:GAMING. Hey man im josh (talk) 16:35, 21 May 2025 (UTC)
    Why are you so opposed to fixing things like NFL Draft over-capitalization, yet so insistent that Auckland region needs to be capitalized? Certainly it would be better to adopt my consensus-based guideline than go with your pure opinions. Exhausting it is. Dicklyon (talk) 06:07, 22 May 2025 (UTC)
  • Personally, I think we should use {{R from miscapitalization}} for cases that are always erroneous (e.g. Barack obama), and {{R from other capitalization}} for all others; I don't really see a need to introduce a third redirect category into the mix. Separating out "non-preferred" capitalizations from other alternative capitalizations doesn't seem like a useful distinction to draw; almost any redirect that differs solely in caps will be non-preferred, because the capitalization that is preferred should just be the page title. ModernDayTrilobite (talk • contribs) 16:53, 22 May 2025 (UTC)
    See my comment of 00:31, 22 May to Cinderella above, for why quite often the one in the redirect is the preferred one, and the title capitalization is non-preferred, but it's just that nobody has noticed and fixed it yet (you find a few thousand examples if you review my move log). In general, it would often be wrong to assume that the "other" is "non-preferred". It would be safer to think of "other" as meaning not yet determined which might be preferred or non-preferred or wrong. Dicklyon (talk) 02:26, 23 May 2025 (UTC)
    Another bunch of examples are the <year> National Soccer League Grand Final articles. Josh recently created a bunch of redirects from lower case and tagged them miscapitalized, for who knows what reason. Anyone who looks at sources can see that the lowercase is preferred on WP, and the capped are over-capitalized. So I changed them to "other", and since he has made it controversial I opened an RM instead of just fixing them. So these "other" are not "non-preferred", unless the RM generates a consensus that capitalizing is correct, which seems very unlikely. Dicklyon (talk) 00:48, 24 May 2025 (UTC)
    Having looked (so far) only at the first page of Google Books results you link to in that RM, I'm seeing a mix of capitalised and non-capitalised uses so it's unlikely that either can be accurately described as "always incorrect". Thryduulf (talk) 01:08, 24 May 2025 (UTC)
    MOS:CAPS reads:

    Wikipedia relies on sources to determine what is conventionally capitalized; only words and phrases that are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia.

    From the MOS's perspective, it's irrelevant whether the capitalisation is considered "always incorrect" or not. —Bagumba (talk) 04:08, 24 May 2025 (UTC)
    Certainly nobody is proposing calling either version "always incorrect". Dicklyon (talk) 06:15, 24 May 2025 (UTC)
  • If I'm following this right, there are three outstanding potential issues:
    1. The new template still categorizes the redirects as "miscapitalisations", which some people oppose
    2. The new template could instead point at a new category, but this would still need to be created and targeted by reports that collect linked non-preferred capitalisations
    3. Some people object (in some or all cases) to the way editors are using the reports currently. They would similarly object to editors using the new reports.
    Is there a compromise possible where we focus on addressing #2? It addresses some of the concerns about categorizing non-preferred capitalisations as errors while still enabling work on fixing non-preferred capitalisations. Firefangledfeathers (talk / contribs) 03:08, 24 May 2025 (UTC)
    Yes, it's good to regroup and avoid TLDR for newcomers. I'll add for #1:
    • The category in question, Category:Redirects from miscapitalisations, reads:

      This is a maintenance category, used for maintenance of the Wikipedia project. It is not part of the encyclopedia and contains non-article pages, or groups articles by status rather than subject.

    • The category is part of Category:Hidden categories, and not readily visible to readers.
    —Bagumba (talk) 04:03, 24 May 2025 (UTC)
    Josh did a mod in this edit (which I reverted), indicating some problem with this concept. He suggests that piped non-preferred redirects should not be fixed, which would make the related category and report useless for maintenance and improvement of the encyclopedia. Same problem he has with marking non-preferred capitalizations as miscapitalizations, or partly the same. That is, Thryduulf's suggestion of having a third category does not address his problem that brought us here. Maybe someone else can try to talk to him, as I'm running out of ideas. Dicklyon (talk) 07:11, 24 May 2025 (UTC)
    We generally shouldn't use piping in these cases per MOS:NOPIPE. —Bagumba (talk) 07:24, 24 May 2025 (UTC)
    Josh also cited WP:NOPIPE in his edit summary of the edit I linked above. In truth, I don't see how it applies one way or the other here, but I agree that piping through a miscapitalized (or non-preferred capitalization) redirect is a bad idea, and fixing them is part of process of working on the reports of links to such things. If someone is able to refine the reporting to ignore links that are piped, then they wouldn't need to be fixed to make the reports useful, but until then, fixing them is pretty much needed.
    I went ahead and applied the new tag to a bunch of redirects with "in the NFL Draft" in their titles. If we decide to make this template do something a bit different, that will be done in one place, so I'm pretty sure there should be no reason for Josh or anyone else to object to those. There are a lot more to do. Dicklyon (talk) 05:30, 25 May 2025 (UTC)
    Yes, it's consistent with Wikipedia:Requests for comment/Capitalization of NFL draft article titles that "NFL draft" is preferred on Wikipedia over "NFL Draft". —Bagumba (talk) 07:01, 25 May 2025 (UTC)
    "Not preferred on Wikipedia" and "incorrect" are very much not the same thing. "NfL Draft" is correct in some circumstances, even if that's not many, so it should editors should not be instructed to always "fix" it. We need either two categories and two templates, one for redirects that are always incorrect and one for everything else; or three categories and three templates, one for redirects that are always incorrect, one for those that are always non-preferred on Wikipedia, and one for those that are true alternatives. Three templates with two categories is doesn't help anybody. The longer this discussion goes on, the more I favour the two-category solution with strong guidance that miscapitalisation is only for redirects that are always incorrect. If that makes it harder to deal with something as trivial as possibly incorrect capitalisations then so be it. Thryduulf (talk) 09:33, 30 May 2025 (UTC)
    Thryduulf is correct that it'd be better to amend the documentation of Template:R from non-preferred capitalisation to say that incoming links should sometimes/often be fixed, rather than imply they always need fixing. In a sentence like "James said 'my greatest dream was to be picked last in the NFL Draft'", the best link style option is to link the non-preferred cap redirect instead of piping to the article. Most links won't be in situations like that, but some will.
    T, can you explain why you might object to a three-template, three-category solution? Firefangledfeathers (talk / contribs) 13:58, 30 May 2025 (UTC)
    I have amended it to say "usually". I have no objection to having a third category to go with the third template; that needs to be worked out with someone who is willing to help with the corresponding report(s). Dicklyon (talk) 14:53, 30 May 2025 (UTC)
    @Firefangledfeathers It's not that I object to the three-three option it's just I'm not really convinced that it actually adds enough value over the two-two option for the ongoing maintenance load.
    @Dicklyon that needs to be worked out with someone who is willing to help with the corresponding report(s) Why? If nobody is interested in fixing an error, you have to consider whether it is actually an error at all? Thryduulf (talk) 15:13, 30 May 2025 (UTC)
    Thanks for clarifying. I continue to favor the three-three solution. People are interested in fixing the errors, and it seems like the next steps are creating the third category and then requesting for help with the reports. I presume this should happen at Wikipedia talk:Database reports. I'll wait to see if there are objections. Firefangledfeathers (talk / contribs) 15:20, 30 May 2025 (UTC)
    It won't be hard to get this implemented; I can probably figure it out myself. But I'm also not really convinced that the three-category solution is needed. I don't see any problem sticking with the two-category solution, or even the two-tag solution, if we go back to business as usual, tagging non-preferred capitalizations as miscapitalizations so they get on the report of things to fix. I still don't see what's Josh's reason for objection is, and Randy's objection that the redirect can show up in a hatnote and therefore a user might stumble on the otherwise hidden tag seems pretty trivially weak. Nevertheless, I'm willing to try your suggestion of a compromise third tag/category. Dicklyon (talk) 15:36, 30 May 2025 (UTC)
    I am also not convinced by the objections, but the people doing the objecting are numerous. We could have a big ol RFC about it—which will surely generate many pages of "why does this matter?" comments—or we can compromise. Firefangledfeathers (talk / contribs) 15:39, 30 May 2025 (UTC)
    Likewise, I think we should not lose track that these are redirect categories are documented as being for internal WP maintenance only, and are more or less hidden from the outside. They're not intended as grammar references for the masses outside WP, nor do I believe anyone realistically uses them as such. Yet, we must acknowledge that MOS is polarizing, and these objections exist. —Bagumba (talk) 15:55, 30 May 2025 (UTC)
    if we go back to business as usual, tagging non-preferred capitalizations as miscapitalizations so they get on the report of things to fix this is the fundamental thing people are objecting to: Just because a capitalisation is non-preferred doesn't mean it is incorrect. Thryduulf (talk) 15:50, 30 May 2025 (UTC)
    Then "people" should be more clear what aspect of this maintenance process bothers them. Maybe all we have to do to fix it is change a few words in the documentation or category names. But it's hard to know what solution will be most satisfying if people won't be clear. And I do appreciate your idea of the third/middle way, as it seems to address as much of the objection as I can see. Your waffling by saying you're not sure it's worth it just takes us back to square one, which is also an alternative. Dicklyon (talk) 15:55, 30 May 2025 (UTC)
    I'm genuinely not understanding what you are finding unclear about this. Only capitalisations that are actually incorrect (not just non-preferred) need correcting. Don't "correct" things that don't need correcting. Thryduulf (talk) 16:03, 30 May 2025 (UTC)
    OK, that sounds like my hypothesis number 1: "You don't want to see more downcasing of NFL Draft (and other links containing that phrase) where it appears in articles." (not just NFL Draft, of course, but other non-preferred capitalizations that appear in articles). I appreciate the clarification of your position, and I strongly object to it. These things should be corrected, even if you don't want to label them as errors. Dicklyon (talk) 17:57, 30 May 2025 (UTC)
    These things should be corrected, even if you don't want to label them as errors. This is the fundamental disconnect - capitalisations that not incorrect in context (and things that are non-preferred are not incorrect) are not something that can be "corrected". Making such trivial style changes such as NFL Draft to NFL draft without substantial changes to the article are, in the majority of cases, both pointless and disruptive (e.g. watchlist spam), [[NfL Draft|NfL draft]] even more so. Spend your time and effort fixing things that are actually incorrect (e.g. john smith → John Smith) and you should get no pushback and thanks for improving the encyclopaedia. Thryduulf (talk) 19:17, 30 May 2025 (UTC)
    I get a ton of thanks already for my case fixing work. I realize that you, as a long-time opposer of capitalization fixes, are not among those thanking me. I find your effort here to sabotage the case-fixing process by declaring style errors to be not worth fixing is way out of step with consensus in such things. Dicklyon (talk) 00:17, 31 May 2025 (UTC)
    I don't oppose capitalisation fixes, I oppose fixing capitalisations that do not need fixing. From my perspective, consensus is a lot closer to my position than it is to yours given how much opposition implementing the outcomes of discussions attended almost entirely by MOS regulars attracts. Thryduulf (talk) 01:15, 31 May 2025 (UTC)
    There's a disconnect with MOS:CAPS advising to avoid capitalisation except when they are consistently capitalized in a substantial majority of independent, reliable sources are capitalized in Wikipedia versus fans of individual institutions (like the NFL) that choose to overcapitalise. But projects' WP:LOCALCONSENSUS needs to convince the wider community that the general MOS is to be IAR ignored, or that the MOS needs modification. —Bagumba (talk) 01:56, 31 May 2025 (UTC)
    Thryduulf, you do oppose capitalization fixes, frequently, by saying they're not necessary. But guidelines say they're not right. There's essentially no pushback on case fixing as move cleanup after a consensus to change case, and also relatively little on all the other case fixing I do without discussion. There's always Randy arguing that caps are better, but he doesn't object to the cleanup fixes once consensus is achieved. Josh mostly doesn't object either, he just doesn't like the labels. So when you say "given how much opposition implementing the outcomes of discussions", I think you're hallucinating; or show me what you're talking about. Dicklyon (talk) 06:08, 31 May 2025 (UTC)
    If nobody is interested in fixing an error ... It's more that it's not for the faint of heart and few dare. Witness the pitchforks even after RfCs reach a consensus. —Bagumba (talk) 16:12, 30 May 2025 (UTC)
    @Firefangledfeathers: Is the concern here that it's a quotation, and the original source capitalized "NFL Draft"? If so, we should not hold non-preferred capitalizations to a higher standard than we do with non-preferred spellings. While MOS:PMC reads: In direct quotations, retain dialectal and archaic spellings, including capitalization (but not archaic glyphs and ligatures, as detailed below in § Typographic conformity), but MOS:CONFORM says A quotation is not a facsimile and, in most cases, it is not a requirement that the original formatting be preserved. Formatting and other purely typographical elements of quoted text should be adapted to English Wikipedia's conventions without comment, provided that doing so will not change or obscure meaning or intent of the text. I question the blanket need to always retain non-preferred capitalizations for quotes, and I'll note that nobody is similarly clamoring about {{R from misspelling}} and the need for {{R from non-preferred spellings}}. There is a double standard. A few one-off IAR cases to pipe, as you suggest, seems reasonable. —Bagumba (talk) 15:46, 30 May 2025 (UTC)
    I'd rather not get too in the weeds on exceptions, but I grant that they might exist. Firefangledfeathers (talk / contribs) 15:52, 30 May 2025 (UTC)
    Plus the way this specific example is written, since the quote is from a spoken comment, the written capitalization is a style choice by the publication, not the speaker. That being said, it's standard for publications to alter the style of written or spoken quotations to conform to their own style guidelines, and the quoted Wikipedia guideline aligns with historical writing practice. isaacl (talk) 16:55, 30 May 2025 (UTC)

Probing the objections

@Hey man im josh: – I'm trying to understand your position better. I have several conjectures about what you might be trying to say, some mutually contradictory and some not:

  1. You don't want to see more downcasing of NFL Draft (and other links containing that phrase) where it appears in articles.
  2. You do want to see more downcasing of NFL Draft where it appears in articles, but don't want the current "miscapitalization" categories and reports to be used for that.
  3. You have some alternative suggestion for a method of maintenance that would be more appropriate here.
  4. You object to downcasing links piped through NFL Draft (and other redirects that appear on maintenance reports), since they affect only the maintenance cat and report but have no effect on the article appearance.

If you can let us know which ones of these, if any, characterize your position, that would be useful. Also if the answers are different for other redirects with non-preferred capitalization, such as List of Railway Stations in Japan, Association Football, Chibcha Terrane, etc., or, replacing "downcasing" by "upcasing", Covid-19, Zip code, Allmusic, Wrestlemania 25, it would be good to know what kind of considerations make some of these different. Currently these are all tagged as "miscapitalizations", so I wonder if you think some of those should not be, and if not, then what. Dicklyon (talk) 22:16, 26 May 2025 (UTC)

@Hey man im josh: Maybe my ping attempt didn't work? Dicklyon (talk) 02:48, 29 May 2025 (UTC)
Or did you just decide to ghost us? I guess I'll go ahead without your input from now. Dicklyon (talk) 23:21, 29 May 2025 (UTC)
There's WP:SILENCE (and WP:NOTCOMPULSORY), but at the same time, I think there's enough of a quorum here where one person won't cause a stalemate. —Bagumba (talk) 00:48, 30 May 2025 (UTC)
Well, yes, if anyone else has any objections to using the miscapitalization and/or non-preferred capitalization tag on any of these or other specific redirects, I hope they'll let us know, perhaps with reference to those hypothesized positions. Dicklyon (talk) 04:33, 30 May 2025 (UTC)

@Thryduulf: you seem to have objections. Maybe say more clearly, e.g. whether any of these conjectured positions describe where you're coming from? Dicklyon (talk) 15:28, 30 May 2025 (UTC)

  1. Partly. There are places where "NFL Draft" is correct and so should not be changed. There are places where it is entirely non-problematic so it should only be changed as part of a substantive edit (and even then doesn't matter if it isn't changed).
  2. See #1. Using the current miscapitalisation categories/reports for things that are not always incorrect is what is problematic.
  3. See extensive discussion elsewhere in this section.
  4. [[NFL Draft|NFL draft]] and equivalents should not be changed unless a substantive change is made to the article at the same time, or it is a situation where "NFL Draft" is actually correct. See WP:NOTBROKEN, WP:COSMETIC and similar.
Thryduulf (talk) 15:58, 30 May 2025 (UTC)
Do you know what type of situation "NFL Draft" would be correct in? ~WikiOriginal-9~ (talk) 16:08, 30 May 2025 (UTC)
Quotes and titles of works/programmes/etc, are the first situations that come to mind. Thryduulf (talk) 16:13, 30 May 2025 (UTC)
Hypothetically, but most WP pages would write, "ACME televised the 2025 NFL draft", not "ACME televised 2025 NFL Draft" (assuming that was also the exact name of the program). MOS:LINKINNAME discourages links to partial names like a book History of the NFL Draft. —Bagumba (talk) 16:27, 30 May 2025 (UTC)
Most is not all, and this is about the entire class of redirects not just one redirect. Thryduulf (talk) 17:20, 30 May 2025 (UTC)
Most is not all: Sure, but in a large extent, they are independent issues. One is whether conceptually there are use cases for {{R from non-preferred capitalisation}}, the others are specific redirects, and whether or not it is applicable, which is decided on a per-case basis. —Bagumba (talk) 17:34, 30 May 2025 (UTC)
The draft itself is lowercase… but the name of the TV program that airs it (but also contains commentary, bio segments and other bits and pieces) would be upper case. Blueboar (talk) 17:27, 30 May 2025 (UTC)
I'm not aware of a TV show called "2025 NFL Draft" or "2025 NFL Draft on ESPN". Could someone please locate a reliable source that has the official name of this hypothetical TV program? ESPN airing the 2025 NFL draft doesn't mean it's an officially named TV program like most people would think of.
Official NFL style guides always have Draft uppercased. Not this Wikipedia-style "d" and "D" stuff. ~WikiOriginal-9~ (talk) 17:44, 30 May 2025 (UTC)
The shows are usually branded, e.g. 2019 NFL Draft on ABC.[10]. And WP prose is typically "ABC aired the 2019 NFL draft" and not with the program like "ABC aired 2019 NFL Draft on ABC" —Bagumba (talk) 18:09, 30 May 2025 (UTC)
Thanks for the quick source find. Fair enough. ~WikiOriginal-9~ (talk) 18:11, 30 May 2025 (UTC)
Repeating a related point, WP:LINKINNAME would anyways discourage a partial name link like 2019 NFL Draft on ABC. —Bagumba (talk) 18:15, 30 May 2025 (UTC)
I found one recently with NFL Draft in a list of shows that some network aired, so I put [[NFL draft|NFL Draft]] to avoid linking the miscapitalized redirect, so I wouldn't end up back there again from the report. But that's the only one I've seen so far. Dicklyon (talk) 06:12, 31 May 2025 (UTC)
I saw Harry Connick Jr., with the draft listed in his filmography. Since it's the show, I linked it instead to NFL Draft on ABC.[11] If there really was a TV show called NFL Draft, it should link to NFL Draft (TV program) (naming consistent with WP:NCTV). It could also probably be tagged with Category:Redirects with possibilities, as a possible standalone page. That aside, it's similar to disambiguation pages only being linked from the main space with titles ending in (disambiguation) (WP:INTDABLINK), so we can distinguish an accidental link that should be changed to preferred capitalisation versus one that we consciously want to remain capitalised. —Bagumba (talk) 10:36, 31 May 2025 (UTC)
And here's a TV listing showing NFL Draft on ABC airing on ESPN.[12]—Bagumba (talk) 09:09, 31 May 2025 (UTC)
@Thryduulf:, you say "3. See extensive discussion elsewhere in this section." as "some alternative suggestion for a method of maintenance that would be more appropriate here." I'm not sure what part of this extensive discussion has proposed an alternative way forward, other than your three-category suggestion, which I've partly implemented. What else might you be referring to? Dicklyon (talk) 03:26, 1 June 2025 (UTC)

This is a ridiculous tempest in a teapot. "Mis-capitalization" or "incorrect capitalization" in this context really, really, really obviously means "capitalization that is unnecessary and undesirable per WP's own style guide and previous consensus decisions". It literally is not possible for it to mean "incorrect according to all usage and every source in the world". There is no agreement on capitalization, of anything, across all sources, publishers, writers, editors – beyond things universally treated as proper nouns (and proper-noun phrases) like "Assyria", "Oprah Winfrey", and "the Arctic Ocean". So it simply is not rationally conceivable that the meaning is anything like "universally considered incorrect by off-site publishers". If people are going to continue to pitch pointless, obstructive, and editorial-time-wasting hissyfits about this stuff, just change the wording of the category to "unnecessary capitalization" or "over-capitalization" and be done with it. This kind of bikeshedding over trivia has been long-term corrosive to editorial productivity and goodwill.

To the extent "NFL Draft is sometimes properly capitalized" ... [And why does this always seem to be about that f***ing subject over the last year or so? GIVE IT A REST. STOP OBSESSING. This subject, like all other subjects, do not "belong" to you.]: That's only going to be true when it appears in a proper name, that WP consensus agrees is a proper name, such as the title of published work (when given in title case). So the issue simply isn't an issue.

These "objections" are a patently manufactured drama, and attempt to drag out indefinitely a matter already settled by RfC (after failures multiple times to settle it via RM and MR), and re-settled by AN. Just drop the stick before you beat the horse corpse all the way to center of the earth. I can't read minds, so I cannot prove motivations, but it is very difficult to not come away with an impression of "me and my little WP:FACTION are going to fight against everything that DickLyon in particular does, until the end of time." This needs to stop. It needed to stop several years ago.  — SMcCandlish ☏ ¢ 😼  11:28, 2 June 2025 (UTC)

"Mis-capitalization" or "incorrect capitalization" in this context really, really, really obviously means "capitalization that is unnecessary and undesirable per WP's own style guide and previous consensus decisions". given that multiple people in good faith believe differently to you, and have explained why in detail, this is clearly not correct. The rest of your bad-faith rant castinging multiple unfounded aspersions is something that I encourage you to self-revert before it becomes an ANI matter (this is not your first warning). Thryduulf (talk) 11:34, 2 June 2025 (UTC)
Quite frankly, I'm with SMcCandlish in thinking that your opposition to my case fixing work is not in good faith, and that it has been ongoing very obnoxiously for years. It's OK that you don't think case fixing is important or "necessary", but in general, whatever your feelings, you should not fight attempts to improve the encyclopedia's compliance with its own guidelines, which is what you're doing here. And it's you that has made it personal, here and numerous times before. Dicklyon (talk) 14:32, 2 June 2025 (UTC)

 You are invited to join the discussion at Wikipedia:Templates for discussion/Log/2025 May 26 § Template:R from non-preferred capitalisation. Thryduulf (talk) 19:04, 26 May 2025 (UTC). Thryduulf (talk) 19:04, 26 May 2025 (UTC)

Wouldn't it be better to keep the conversation here for a while? Dicklyon (talk) 21:54, 26 May 2025 (UTC)
I and others, including you, have argued there for doing just that - and that is the correct venue to make that argument. However the discussion remains open and so people following here should be aware that it is happening. Thryduulf (talk) 22:07, 26 May 2025 (UTC)
Got it. It seems odd that you'd "invite" instead of "notify", but we're in agreement. Dicklyon (talk) 22:24, 26 May 2025 (UTC)
I used the standard template with the standard wording (I just suppressed the default header because I couldn't figure out any way to get a level 3 header) to make sure the notice was neutrally worded. Thryduulf (talk) 23:49, 26 May 2025 (UTC)

Allow editing the edit summary after you publish it

I suggest that contributors be able to edit their own(not the ones of other editors, for quite obvious reasons) edit summaries in the article history after they publish it(Also, there should be a record of edit summaries edited), so that in case of bad edit summaries, the contributor can go back and change their edit summary.

This solves the problem where people forget to add edit summaries(or accidentally press the publish changes button before finishing writing) or when a user realizes the edit summary probably wasn't good enough. Thehistorianisaac (talk) 01:02, 28 May 2025 (UTC)

Tracked in Phabricator
Task T15937
This would require a significant software change, and similar requests have been declined before. phab:T15937 is open (and has been since 2008) and contains some discussion and links to older discussions. Thryduulf (talk) 02:13, 28 May 2025 (UTC)
That is just not happening. If we allow one, we risk ending up with a situation where we create a infinite turtles of edit summary of edit to edit summary of edit of edit summary of edit of edit summary. Sohom (talk) 21:25, 28 May 2025 (UTC)
I don't see how this would work, there would have to be an edit summary log implemented for administrators as well as some sort of reverting, however I see how this could also be malicious if there isn't a time limit (timer) for these edits. Also, if there was a record for this, there would need to be at least some filtering to exclude blank summaries and spam to not clog up the logs. Gonna eatpizza (talk) 17:07, 30 May 2025 (UTC)
I sometimes forget an edit-summary or accidentally mis-state some detail. Easy enough to make a WP:DUMMY EDIT to fix it. Or better yet, I've started a habit of making an actual good edit to that article, where the ES mentions the current edit and also the preceding one with the bad ES, to atone for my mistake:) DMacks (talk) 17:17, 30 May 2025 (UTC)
Yes, dummy edit seems fine. You could see it as a flattened version of the proposal where the revision comment history that would be required by this proposal is flattened into the revision table and stored there. Sean.hoyland (talk) 17:24, 30 May 2025 (UTC)
Actually it would not be rocket science to have a facility to merge adjacent edits superficially. All the best: Rich Farmbrough 21:24, 2 June 2025 (UTC).
It feels like this suggestion has been made repeatedly during the last year or so. Should we add this to PEREN, perhaps right after Wikipedia:Perennial proposals#Automatically prompt for missing edit summary ? WhatamIdoing (talk) 01:31, 4 June 2025 (UTC)

Proposal: Reimplement the births and deaths in the pages after 1980

I would like to propose that we reimplement the births and deaths of people of people born after 1980. As a reader, I've always enjoyed reading about which famous people were born in a particular year, and I was hoping that we could bring this back. I could say that there are too many people to be included, but if we set clear criteria on who is included and not included, I think would be better. Interstellarity (talk) 01:29, 2 June 2025 (UTC)

I am not sure what exactly you are proposing, but does categories like Category:2011 births and lists like Deaths in April 2024 serve your purpose? Ca talk to me! 01:49, 2 June 2025 (UTC)
Somewhere along the lines of 1900#Births and 1900#Deaths which is within the article rather than separate pages. Interstellarity (talk) 01:53, 2 June 2025 (UTC)
My browser would struggle to load such massive pages. The death lists are already split into months, with reduced citations. Ca talk to me! 02:04, 2 June 2025 (UTC)
How is it determined who gets to go on those pages anyway? Category:1901 births has thousands of pages, while 1901#Births has... far fewer than that. —pythoncoder (talk | contribs) 05:55, 2 June 2025 (UTC)
How is it determined who gets to go on those pages anyway? The only guidance I've found so far is Wikipedia:Timeline standards#Births section which states There may be other restrictions as to who may appear, but absent other consensus, the person must have a Wikipedia article. That text was added by Arthur Rubin with this January 2017 edit that also changed "The Births section list all births in that year" to "The Births section lists births in that year". The edit summary cites a "consensus at WT:YEARS" but I haven't been able to identify the relevant discussion in the archives. I did find a link to Wikipedia:WikiProject Years/criteria#Births and Deaths that states in its entirety At the least, the person must have an individual Wikipedia article. "Death of John Doe" or "Murder of John Doe" does not qualify. Possible exception for the birth of twins or multiples.
The essay Wikipedia:Recent Years exists but is marked as inactive and it's not clear how much consensus it has. That states it applies only to the years 2002-2025. The Births section states One method of determining which births could be included is if there are Wikipedia articles in English and at least nine non-English languages about the individual in question. Prince George of Cambridge, for example, has several non-English articles on him, listed on the left sidebar. Although inclusion may then be automatic, it will not necessarily be permanent. and the Deaths section reads Persons who are internationally notable are included, as demonstrated by reliable sources. Heads of state or government (other than interim/acting leaders) are typically considered internationally notable..
I'll leave a note at Wikipedia talk:WikiProject Years about this discussion, hopefully someone more knowledgeable than me will be better able to answer the question. Thryduulf (talk) 10:06, 2 June 2025 (UTC)
There's a lot of context behind it; User:InvadingInvader/Against international notability is a short write up. In brief, the Recent Years essay was rejected by the community a long time ago but was nevertheless enforced in the topic area until about two years ago when I asked the community to weigh in and things got sorted out. Wikipedia:Village pump (proposals)/Archive 199#RFC: split births & deaths from year articles is the current consensus on births and deaths. My position now is the same as it was then, in that these lists are both unwieldy and entirely subjective in their inclusion standards, and that separate lists or categories accomplish the same thing better. Thebiguglyalien (talk) 🛸 16:27, 2 June 2025 (UTC)
If you go back long enough (c.2005), I remember once seeing a recommendation to always add newly created articles to the relevant year/day pages! If we kept that up now, there would be 18,000 entries on some of the 1980s pages.
I had a poke through the WT:YEARS archives as well and I think this may be one of those practices that emerged without an explicit discussion about it - certainly we must have been being selective by the time we hit 2-3 million articles in 2010, just on practical grounds. Andrew Gray (talk) 22:34, 4 June 2025 (UTC)

Font

I was wondering if there is support to change the article font to one that has a clear difference between big i and little L, to avoid confusion on articles like Type Ia supernova. CoolDino1 (talk) 21:45, 6 June 2025 (UTC)

English Wikipedia doesn't specify a specific font to be used for article text. It just uses the one configured in your browser for sans-serif text, so you can change your browser to use a different sans-serif font. isaacl (talk) 21:59, 6 June 2025 (UTC)
Ok, thanks. I'll change that. CoolDino1 (talk) 22:20, 6 June 2025 (UTC)
Note that you can even set your browser to use a serif font in situations where the site calls for a sans serif one. I've got mine set to use Times New Roman in all situations. --User:Khajidha (talk) (contributions) 13:09, 9 June 2025 (UTC)

Official Launch of The Million Wiki Project

We are thrilled to announce the official launch of The Million Wiki Project!

Our mission is to enrich Wikimedia projects with high-quality and diverse content related to the Middle East and North Africa (MENA) region. This initiative focuses on creating new articles, multimedia, structured data, and more, covering topics from MENA countries, communities, and diaspora worldwide.

Who Can Participate?
All registered Wikimedians are welcome to join! Whether you're an individual contributor or part of an organization, your support is valuable. We encourage content creation in any of the six official UN languages (Arabic, English, French, Russian, Spanish, and soon Chinese).

What Kind of Content Are We Looking For?

  • New Wikipedia articles focused on MENA topics
  • Multimedia contributions on Wikimedia Commons (photos, videos)
  • Structured data for Wikidata
  • Language entries on Wiktionary
  • Public domain texts on Wikisource

Note: Make sure your content follows local Wikimedia guidelines and licensing policies, including Freedom of Panorama for media files.

Join us in bridging content gaps and showcasing the richness of the MENA region on Wikimedia platforms!
Stay tuned for more updates and participation guidelines. Reda Kerbouche (talk) 09:08, 23 May 2025 (UTC)

Per both the header at the top of this page and the editnotice, This page is for concrete, actionable proposals. As written, it sounds like the "proposal" in question here is "go create new articles", which is what we've been doing for the past two decades and plan to continue doing indefinitely into the future.
There is a lot of community skepticism of affiliate activities after we've seen numerous flashy announcements of ambitious-sounding projects filled with vague corporate buzzwords (e.g. Building strategic relationships with key stakeholders, identify growth opportunities) and funded by expensive grants that ultimately do little or nothing to improve the encyclopedia. I assume that there is more detail/planning to your initiative than is described in your note above and on the project landing page (where you may wish to fix the broken header tabs), but it may behoove your interests to craft announcements that assuage rather than exacerbate the aforementioned fears. Sdkb talk 15:00, 23 May 2025 (UTC)
Thank you for your feedback; it’s both valid and appreciated. And we took time to discuss all the questions with the whole team.
We understand that from a first read, this may seem like a broad or familiar call to action. However, the Million Wiki Project is not just about encouraging content creation, it’s about coordinating and resourcing communities in multiple regions (some are underrepresented) to increase content equity across multiple Wikimedia projects. If you think the details are insufficient in the landing page; we can expand it based on the feedback we receive.
We’ve seen firsthand that in many MENA countries, editors face barriers like limited outreach, infrastructure, or access to local events. This project provides logistical and financial support (e.g. internet stipends, local editathons etc.) to empower them to organize impactful campaigns.
At its heart, this project is about inclusion; bringing everyone along on this journey, even those who haven’t had the chance to participate before. While the name may highlight a numerical goal (a million contributions), our true aspiration is to ensure that every Wikimedian feels they have a place and a voice in this movement.
This project has been co-designed by experienced editors, supported by the grant committee of the Project, and built on the feedback received from the community organizers. It's an ongoing process; and we’re learning every step of the way. Abbas 14:00, 3 June 2025 (UTC)
I'm confused about what this is actually about. Does create one million new contribution and content pieces mean one million edits or one million articles? Does it include images on Commons and documents on Wikisource? Why does any of this need funding? If you are paying editors, it may slow things down (on enwiki), as draft articles would have to go through the Articles for Creation review process. Toadspike [Talk] 16:18, 23 May 2025 (UTC)
Thank you for raising these valid questions. The “one million” target includes meaningful contributions across Wikimedia projects: new additions/articles, structured data, Commons uploads, Wikisource documents, and more. Full details are available here.
To clarify: we are not paying editors for content creation. Instead, we provide microgrants to communities and affiliates who want to run campaigns, editathons, similar to other movement grants. These are needs-based, and only support logistics, internet costs, etc.
We're especially encouraging experienced editors to lead these initiatives, precisely to maintain quality and alignment with Wikimedia’s standards, including AfC processes when required. Reda Kerbouche (talk) 17:36, 2 June 2025 (UTC)
Why is this project restricting its support to content in "official UN languages", the majority of which have limited, if any, connection to the MENA region? Is such blatant discrimination normal practice? AndyTheGrump (talk) 16:25, 23 May 2025 (UTC)
English does make sense as the international lingua franca, and of course (Modern Standard) Arabic as the standard language used by half of the Middle East, but it misses on relatively large wikis (such as Persian, Hebrew, Egyptian Arabic and Turkish Wikipedias), which are all more relevant to the region (and likely have more native speakers who might be able to help on MENA topics) than Spanish or Russian. Chaotic Enby (talk · contribs) 16:37, 23 May 2025 (UTC)
Thank you for your questions @AndyTheGrump and Chaotic Enby:; it's important to clarify this point.
At this stage of the Million Wiki Project, we’ve chosen to focus on contributions in the six UN official languages (Arabic, English, French, Spanish, Russian, and Chinese). This was a strategic decision made by the organizing team and the grant committee to ensure consistency in tracking, reporting, and coordination across different regions and communities.
The choice is based on practical reasons:
  • These languages already have strong foundations across many Wikimedia projects.
  • They are widely spoken or used in official or educational contexts in several MENA countries.
  • They provide a shared framework for documentation and collaboration with international partners and communities.
The scope of the project is limited to the mentioned languages; which reflects the priorities and capacity of this phase. However, we will consider other languages as the project evolves. Reda Kerbouche (talk) 17:43, 2 June 2025 (UTC)
And while we're discussing languages, does WMF think that Chinese is not yet an official language of the UN ("soon Chinese")? It has been an official language since 1946. Caeciliusinhorto (talk) 20:10, 23 May 2025 (UTC)
To give them credit where credit is due, it is explained in their FAQ that it is because of a technical issue. Chaotic Enby (talk · contribs) 20:43, 23 May 2025 (UTC)
FWIW - for most parts of West Asia and North Africa you're far more likely to be able to communicate in French over Hebrew, Farsi or Turkish. Oh... and Russian these days will stand you in pretty good stead in the Gulf. Regards, Goldsztajn (talk) 03:34, 28 May 2025 (UTC)
I agree with @Sdkb that the project page does read as corporate-written (or possibly AI-written, with little concrete difference between both). It could be good to clarify it in more concrete terms on the landing page, although there seem to be more detail on meta:The Million Wiki Project/FAQ (to reply to @Toadspike's query, it seems to count new page creations on all projects).
Concerningly, neither that page nor meta:The Million Wiki Project/Funding Guidelines talk about how this meshes with our policies on paid editing, despite repeatedly talking about "transparency". Chaotic Enby (talk · contribs) 16:29, 23 May 2025 (UTC)
Looking deeper into it, it is definitely AI-written. Common catchphrases such as upholds Wikimedia's commitment to quality and reliability are everywhere, and there is even a piece of generated markup left on meta:The Million Wiki Project/Eligibility Criteria#Wikimedia Commons. Chaotic Enby (talk · contribs) 16:46, 23 May 2025 (UTC)
@Chaotic Enby, can you clarify what the generated markup is? Sdkb talk 21:18, 23 May 2025 (UTC)
Original Media:** Photos, audio, or video content taken or created by the uploader(s).
ChatGPT very often generates bullet point lists of the form **Short Title:** Longer explanation of what is meant by the short title. (as it uses **this syntax** to bold text). This very much looks like a remnant of that syntax that wasn't correctly removed, especially since the asterisks don't seem to be referenced anywhere. Chaotic Enby (talk · contribs) 21:36, 23 May 2025 (UTC)
That's quite concerning. Jtud (WMF), the WMF Grants team should probably be aware of this whole thread (if you're not the right point person, I'd appreciate you forwarding this or letting us know who the right person would be). Sdkb talk 19:18, 24 May 2025 (UTC)
The very bottom of that page states that AI-generated content is not accepted. The irony... Helpful Raccoon (talk) 01:38, 25 May 2025 (UTC)
@Same answer as the previous question ^^ Nehaoua (talk) 17:23, 2 June 2025 (UTC)
All major decisions, structures, and policies were drafted by human contributors — the grant committee members — many of whom are seasoned Wikimedians; we made sure no policies were breached. As everybody does, we consulted AI tools to proofread the English draft, e.g. grammar checks and language structure. We understand the importance of human tone and accuracy in Wikimedia spaces, and we truly welcome community edits to improve clarity or remove awkward phrasing or markup remnants. cordially Nehaoua (talk) 17:22, 2 June 2025 (UTC)
From Meta:The Million Wiki Project/Eligibility Criteria: This effort covers a wide range of countries, including Algeria, Bahrain, Egypt, Iraq, Jordan, Kuwait, Lebanon, Libya, Mauritania, Morocco, Oman, Palestine, Qatar, Saudi Arabia, Somalia, Sudan, Syria, Tunisia, the United Arab Emirates, and Yemen, as well as topics relevant to their diaspora communities worldwide.. There is an obvious omission here, which I hardly need spell out. Can I ask why the 'MENA' region appears to have a hole in it? AndyTheGrump (talk) 16:35, 23 May 2025 (UTC)
Given how Iran, Israel, and Turkey are all missing, while Somalia is there, it looks like the list of Arab League members was used for some reason (although for some reason Djibouti and the Comoros were excluded but not Somalia). Chaotic Enby (talk · contribs) 16:40, 23 May 2025 (UTC)
Combined with the requirement that submissions be in a UN official language, I'm not sure this looks like an evenhanded approach to the Middle East. Wehwalt (talk) 17:37, 23 May 2025 (UTC)
It isn't. Not remotely. And given the issues the English-language Wikipedia already has with partisan editing with regard to many 'Middle East' topics, the last thing we need is to look like we are endorsing such a perspective. This ill-thought-out project should never have been approved in the state it is. AndyTheGrump (talk) 19:37, 23 May 2025 (UTC)
Are there links to the proposing, discussing, and approval of this matter? Wehwalt (talk) 21:29, 23 May 2025 (UTC)
I couldn't find any. AndyTheGrump (talk) 21:37, 23 May 2025 (UTC)
It is likely the "The million project" mentioned at meta:Grants:Conference/ARE/Wikiarabia 2022 in Dubai/Report and so was likely discussed then, although I have not been able to find a specific grant request. CMD (talk) 02:42, 26 May 2025 (UTC)
This ill-thought-out project should never have been approved in the state it is. – They should make this the collective slogan of wikimedia projects. Thebiguglyalien (talk) 🛸 21:31, 25 May 2025 (UTC)
That could be said about Wikipedia itself, especially when it started, but kinda still today. Good thing that ill-thought-out project didn't need anyone's approval to get started.
My fellow editors, I never cease to be amazed at the reflexive and vehement opposition so many of y'all have to experimentation and ideas and change in general. It's a wiki, for fuck's sake, it's supposed to be iterative, not perfection. Levivich (talk) 20:34, 10 June 2025 (UTC)
Having an Arabic logo isn't an obviously evenhanded approach to the Middle East either. NebY (talk) 14:11, 26 May 2025 (UTC)
Other than Arabic, Farsi, Pashto, Urdu, Kurdish etc is written using Arabic script. It is *the* most representative script across the entire region, including other scripts would not be "even-handed". Regards, Goldsztajn (talk) 03:51, 28 May 2025 (UTC)
Thank you for your question, please check our answers above. Reda Kerbouche (talk) 17:52, 2 June 2025 (UTC)
@AndyTheGrump and Chaotic Enby:, we understand that geopolitical or regional classifications can differ. For example, countries like Turkey, Iran, and Other countries, while geographically part of the broader Middle East, are classified under different regions by the Wikimedia Foundation’s regional structure (e.g. CEE, Northern & Western Europe).
The countries listed were selected based on a few practical factors:
  • Existing connections with local Wikimedia communities and affiliates
  • Participation in the WikiArabia conference
  • Inclusion in the League of Arab States, which formed a cultural basis for our first project phase
That said, this is not a political exclusion (it's a reflection of community capacity and scope). We’re open to expanding this framework in the future as our network grows. Reda Kerbouche (talk) 17:51, 2 June 2025 (UTC)
As far as I know, Iran is very much classified as MENA by the Wikimedia Foundation. Also, that wording of "Turkey, Iran and Other countries" is a bit weird given that there was only one other country mentioned.
It could be much better to present it as a contest about Arab countries, not about MENA countries. Chaotic Enby (talk · contribs) 20:19, 2 June 2025 (UTC)
@Reda Kerbouche I'm looking for a specific answer here, if possible: would Israeli participation be welcome? Could they be included in the project upon request, either by the their chapter, a wikiproject, or individual editors? FortunateSons (talk) 08:04, 10 June 2025 (UTC)
I would guess that all the countries on the list are more underrepresented on Wiki than Israel is. I completely support the WMF focusing its efforts on areas that are underrepresented, although who knows what they are thinking here. (t · c) buidhe 21:49, 26 May 2025 (UTC)
+1 Regards, Goldsztajn (talk) 03:45, 28 May 2025 (UTC)
  • FYI
     – There is a request to run a CentralNotice banner campaign on the Million Wiki Project at meta:CentralNotice/Request/The Million Wiki Project. Interested editors are invited to comment. Sdkb talk 18:45, 2 June 2025 (UTC)
  • Hi Reda - sorry that you had to face this intense scrutiny all at once, it's really worth trying to get the community on board before launching stuff like this, then these issues will be dealt with in advance. One more point, you say "we are not paying people for editing" (paraphrase) but the funding page says "Contributors performing significant verified work (e.g., high-quality editing, multilingual translation, metadata curation)." I'm fine with that (a lot of people might not be), but concerned that you gave a different answer. All the best: Rich Farmbrough 21:16, 2 June 2025 (UTC).
    It perhaps would have been better received had it been posted at WP:VPW or WP:VPM, since this is really just an announcement to the community about an available resource rather than a proposal for the community to implement. signed, Rosguill talk 14:15, 3 June 2025 (UTC)
  • Sorry again for the bother, but I haven't gotten any response on how the payment might work regarding our paid editing policies. It could be good to clarify what is meant by contributors being paid for "significant verified work". The FAQ page (item 19) currently states that funds could go to targeted contribution campaigns, is there any information about what they might be? How much involvement do the project's partners (which I assume are providing the funding) have in the selection and organization of these campaigns?
    As you state that the project is committed to transparency in its funding, it could be great for Wikimedia volunteers to have more information about these points. Chaotic Enby (talk · contribs) 22:41, 2 June 2025 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_218&oldid=1297043826"