Wikipedia:Redirects for discussion/Log/2024 February 20

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Redirects for discussion‎ | Log

This is an old revision of this page, as edited by Resident Mario (talk | contribs) at 05:13, 21 February 2024 (→‎Wikipedia:Wikipedia Signpost/Archives/Years: Δ). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

February 20

This is a list of redirects that have been proposed for deletion or other action on February 20, 2024.

B-rail

I do not think people would search up B-rail for this. SNCB, NMBS or even SNCB/NMBS together is more appropriate JuniperChill (talk) 23:01, 20 February 2024 (UTC)[reply]

  • Retarget to B Line, which is a likelier target IMO. - Presidentman talk · contribs (Talkback) 01:01, 21 February 2024 (UTC)[reply]
  • weak keep, definitely don't retarget. This seems to be an older brand used (possibly c.2008-2013) by SNCB/NMBS (see e.g. [1], and was previously their main website URI and pages/forum posts from that era show it was used (e.g. [2], [3], [4], ). However, articles (e.g. this from 2021 and from 2023 state that Barraqueiro Group have a subsidiary called "B-Rail" registered as an open access operator in Portugal, although services are still several years away and we don't have relevant content (yet) so disambiguation isn't sustainable at the moment. I can find no evidence of "B-rail" being used to refer to anything called "B line", just the above and various partial title matches for non-notable products and companies. Thryduulf (talk) 03:58, 21 February 2024 (UTC)[reply]

Hui (animal)

Ridiculous number of redirects for this article. This is not sensible destination for a word that just means 'fox'. PepperBeast (talk) 20:04, 9 February 2024 (UTC)[reply]

  • Delete all. This is an English language Wikipedia. Furthermore, this is basically just spam. If you look at the creator's drafts, they got a bunch of other such spam articles they're working on (all while claiming to be semi retired per their user page). An admin really needs to tell them to knock it off, all they're doing is clogging AfD and RfD. Brusquedandelion (talk) 09:29, 11 February 2024 (UTC)[reply]
  • Keep all : Those are the Meitei language common names of the article's main topic. Besides, those terms are explicitly mentioned as well as discussed in different degrees inside the article, along with due citations. Those are not baseless claims or spamming. --Haoreima (talk) 00:50, 13 February 2024 (UTC)[reply]
    This is an English language Wikipedia. If those terms are not in use in multiple reliable independent English Language sources, then there is no reason a page should exist for them on Wikipedia, whether as a redirect or otherwise. Brusquedandelion (talk) 03:43, 13 February 2024 (UTC)[reply]
    Brusquedandelion, that's really not how WP:RLANG works. 🌺 Cremastra (talk) 21:16, 13 February 2024 (UTC)[reply]
    But it is. That page explicitly gives Common words or concepts as an example of an inappropriate redirect. The creator of these redirects themself tells us, immediately above my comment, that these are the Meitei language common names of the article's main topic. Brusquedandelion (talk) 01:33, 14 February 2024 (UTC)[reply]
  • Delete – I expect this table will not be included after the merge. Possibly keep Hui (animal) itself? However, I don't believe we have a habit of redirecting [animal name] in a language to "[that animal] in [that culture]." ~Maplestrip/Mable (chat) 10:14, 13 February 2024 (UTC)[reply]
    Correct, and indeed such a practice is explicitly contraindicated by WP:RLANG. Brusquedandelion (talk) 01:37, 14 February 2024 (UTC)[reply]
  • Comment: "Ridiculous" isn't a valid reason for the deletion nomination. It sounds like WP:IDONTLIKEIT.— Preceding unsigned comment added by Haoreima (talk • contribs) 10:36, 18 February 2024 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Hey man im josh (talk) 18:52, 20 February 2024 (UTC)[reply]

Dada (Ultra monster) and etc.

Ultraman monsters not listed at the target article, with no substantial history at each. For a lot of these cases, there used to be history at these titles, but many of these redirects were created via page moves, left over from a WP:NOTHERE sockmaster moving the previously-BLAR'd redirects to new titles. Nevertheless, neither the old nor new titles have any mention on the current version of this page. All of these don't seem to have a proper home after the deletion of Ultra Monsters, to which most all of these were redirected and/or BLAR'd to some version of. See also Wikipedia:Redirects for discussion/Log/2023 October 14#Gyango for another such case of a monster redirect created via a page move. Utopes (talk / cont) 19:05, 11 February 2024 (UTC)[reply]

Perhaps more suitably, it may also be worthwhile to revert all of the moves and to firstly reconsider the outcome for the new titles that got created, as a textbook example of the harms of moving redirects, especially for what used to be previous articles, BLAR'd since 2012 or so, untouched for a decade, and moved without consensus in July 2023. But right now, those new titles have all the page history, which complicates their existence. And none are even mentioned on the page! Utopes (talk / cont) 19:43, 11 February 2024 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, Hey man im josh (talk) 18:52, 20 February 2024 (UTC)[reply]

Wikipedia:Wikipedia Signpost/Archives/Years

I deleted this page as a G6 and it was requested that I nominate it for RfD.

There does not need to be a redirect here. I manually retargeted every incoming link when I retitled this page last October. There is no way for someone to access this internal Signpost page from Wikipedia. There are no inbound links from other websites that I know of. There is nobody trying to access this page. The existence of this redirect provides no benefit and creates additional burden for maintenance of the Signpost, as it is yet another one-off exception that has to be written into every script and template that uses this directory, every external tool that works off a list of pages, et cetera, et cetera. Every additional piece of special-case whoopsie-doozie only-used-for-one-page-ever code increases the maintenance burden for myself, as well as every future maintainer of the Signpost codebase -- there have to be extra lines of code to deal with this single anomalous redirect, and everybody who deals with the code (to modify it, to replace it, to add a feature or to remove an existing one) must spend time going over these additional lines.

The page title got about 16 views total in the months of November and December; a good number of those were probably from me as I was delinking it from other pages. The rest could have come from anywhere; people click on entries in the deletion log, web scrapers give normal browser user agents, et cetera.

The structure of the /Archives/ directory is very simple: Wikipedia:Wikipedia Signpost/Archives/ contains yearly archive pages. It does not contain anything else. The index page for these yearly archive pages is located at Wikipedia:Wikipedia Signpost/Archives. There is no need to have a separate /Years subpage. That's why we don't have one -- it's just at the base URL. Anyone who, for some reason (let's say someday a person clicks a link to this archive page from some external website) gets a 404 from a sub-URL can just follow the URL structure one level up and get to the place they want to be.

For further reference, there have been hundreds and hundreds of useless Signpost pages subjected to speedy deletion in the last year as I've been cleaning up the space, and consensus (whenever a discussion was required) has always been in favor of doing this. Last year someone demanded that I take these pages through formal processes, to prove with complete thoroughness that the community accepted them being deleted. The main outcome of this was that all these maintenance processes and cleanup were brought to a halt for about a month while these noms percolated through XfD, and all of them were approved, and it just consumed a lot of time (mine but also that of all the XfD participants, closers, etc). Here is a list of all of those formal nominations:

Extended content
  1. Wikipedia:Wikipedia Signpost/Template/Signpost-block-end: nominated at TfD; notified Headbomb (talk · contribs) 23:51, 16 January 2023 (UTC)[reply]
  2. Wikipedia:Wikipedia Signpost/Template/Signpost-block-start: nominated at TfD; notified Headbomb (talk · contribs) 23:51, 16 January 2023 (UTC)[reply]
  3. Wikipedia:Wikipedia Signpost/Template:Signpost-header/Single: nominated at MfD 23:54, 16 January 2023 (UTC)
  4. Template:Signpost/DateCoundown: nominated at RfD; Target: Template:Signpost/DateCountdown (notified); notified FeRDNYC (talk · contribs) 00:03, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  5. Wikipedia:Signpost/Template:Signpost-article-comments-end/preload: nominated at RfD; Target: Wikipedia:Signpost/Templates/Signpost-article-comments-end/preload (notified); notified Resident Mario (talk · contribs) 00:04, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  6. Wikipedia:Signpost/Template:Signpost-article-comments-end/preload-content: nominated at RfD; Target: Wikipedia:Signpost/Templates/Signpost-article-comments-end/commentspage (notified); notified Pretzels (talk · contribs) 00:04, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  7. Wikipedia:Signpost/Template:Signpost-article-start-end: nominated at MfD; notified TheDJ (talk · contribs) 00:05, 17 January 2023 (UTC)[reply]
    • Reason: Obsolete template that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  8. Wikipedia:Signpost/Template:Signpost-article-start v2: nominated at RfD; Target: Wikipedia:Wikipedia Signpost/Templates/Signpost-article-start-v2 (notified); notified TheDJ (talk · contribs) 00:06, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  9. Wikipedia:Signpost/Template:Signpost-snippet/temp: nominated at MfD; notified Bri (talk · contribs) 00:11, 17 January 2023 (UTC)[reply]
    • Reason: Template that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  10. Wikipedia:Signpost/Template:Signpost-header/Single: nominated at RfD; Target: Wikipedia:Wikipedia Signpost/Templates/Signpost-header (notified); notified Funandtrvl (talk · contribs) 00:12, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  11. Wikipedia:Signpost/Template:Signpost-article-header: nominated at RfD; Target: Wikipedia:Wikipedia Signpost/Templates/Signpost-article-header-v2 (notified); notified TheDJ (talk · contribs) 00:18, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  12. Wikipedia:Signpost/Template:Signpost-article-start-v2: nominated at RfD; Target: Wikipedia:Wikipedia Signpost/Templates/Signpost-article-start-v2 (notified); notified TheDJ (talk · contribs) 00:18, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  13. Wikipedia:Signpost/Template:Signpost-block-end-v2: nominated at RfD; Target: Wikipedia:Wikipedia Signpost/Templates/Signpost-block-end-v2 (notified); notified TheDJ (talk · contribs) 00:19, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  14. Wikipedia:Signpost/Template:Signpost-block-start-v2: nominated at RfD; Target: Wikipedia:Wikipedia Signpost/Templates/Signpost-block-start-v2 (notified); notified TheDJ (talk · contribs) 00:20, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  15. Wikipedia:Signpost/Template:Suggestion-featured: nominated at MfD; notified Pretzels (talk · contribs) 00:22, 17 January 2023 (UTC)[reply]
    • Reason: Obsolete template from 2009 that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  16. Wikipedia:Wikipedia Signpost/Templates/Story-preload/N&N: nominated at RfD; Target: Wikipedia:Wikipedia Signpost/Templates/Story-preload/NAN (notified); notified Skomorokh (talk · contribs) 00:41, 17 January 2023 (UTC)[reply]
    • Reason: Template redirect that is not in use anywhere. No incoming links except for Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.
  17. Wikipedia:Signpost/Newsroon: nominated at RfD; Target: Wikipedia:Wikipedia Signpost/Newsroom; notified Adam Cuerden (talk · contribs) 01:00, 17 January 2023 (UTC)[reply]
    • Reason: Redirect that is not in use anywhere. No incoming links except for my own userspace and Wikipedia:Wikipedia Signpost/Omni-index and Wikipedia:Wikipedia Signpost/Omni-index/Linkshere, two pages populated by scripts I wrote to catalog Signpost pages that have no incoming links. One of my major projects as editor-in-chief is to harmonize the use of templates and pages, as the existence of numerous redundant templates (deprecated, never used, or created at the wrong title by typos) poses a large obstacle to navigating or editing Signpost templates. For example, old Signpost articles (from 2005 to 2009) were never properly indexed by the module, because they used strange idiosyncratic header templates, which I recently fixed, allowing me to write a script which updated the module with their titles, authors and tags. Someone has requested that I list these pages at XFD individually rather than nominate them for speedy deletion.

jp×g🗯️ 05:11, 11 February 2024 (UTC)[reply]

  • Keep as an {{R from move}}, for the reasons stated by myself at the deletion review. Prior to being moved to Wikipedia:Wikipedia Signpost/Archives in October 2023, the archives page had been at this title since 2007. Per WP:R#K4, redirects as a result of pagemoves should not normally be deleted without good reason due to the risks of breaking incoming links; and [l]inks that have existed for a significant length of time...should be left alone in case there are any existing links on external pages pointing to them. Given that the page was at this title for over 17 years, and given the >100,000 pageviews the archive page received while at this title, it seems very plausible that offwiki links have been made to the previous archives page of a notable newspaper, which will be broken if this redirect is deleted. With respect to JPxG, there's no way of knowing how many external links have been made to a page, so the statement that there are none from other websites that [they] know of doesn't sway me towards deletion.
    I'm unfamiliar with the Signpost's scripts/templates/external tools and why this page would need to be filtered from them, but I don't think we should be deleting pages on the basis that they will break scripts - we should be building tools around the wiki, not the wiki around the tools. Especially in this case, I don't believe that that is a sufficient reason on its own to delete a redirect when such a deletion might cause harm (in this case, as a result of dead external links). Regarding the previous nominations, I believe that this page is substantially different to the previously nominated redirects, for the reasons I explained in a DRV comment in response to the list. All the best, ‍—‍a smart kitten[meow] 15:43, 11 February 2024 (UTC)[reply]
Forgive me for a moment of bluntness, but I don't expect you to be familiar with the Signpost's scripts, templates, and tools. Nobody is: furthermore, nearly everyone who tries to maintain them eventually becomes burnt out and stops. It's great to think "we should be building tools" in a particular way; if you would like to take a few months refactoring the Signpost's dozens of templates and scripts to reflect this philosophy, I'd love to bring you up to speed at Wikipedia talk:Wikipedia Signpost/Technical. But I do not expect that. What I would appreciate is that, if the person who maintains a codebase repeatedly says "doing this thing will cause a hassle and require additional spaghetti code to handle the stupid one-off edge case", you did not respond with "well I didn't look at any of the code but I bet it wouldn't".
You have not articulated any reasonable way in which this "might cause harm". I have shown the pageviews: immediately after the page was retitled, they dropped to nothing. What is the hypothetical situation in which this causes harm? If somebody clicks a link to the archive page at the old location (virtually nobody has done this, but they might, hypothetically)... they get a "Wikipedia does not have a project page with this exact name" message, and then directly below the page's header, there's a prominently-placed blue link back to the correct location. The page's URL is also obviously formatted in a way that lets you go one level up. But even the situation with somebody sitting there is unlikely. In reality, those pageviews are almost certainly background noise from web scrapers and clicks on the deletion log, and pages (if there were any) which referenced them from an external site either didn't exist or were updated very quickly. The major problem facing the Signpost is not that we're losing a couple pageviews per month to someone who clicks a link to a relocated page and can't figure out how to click up to the main Signpost page and find the archives link from there: it's that we're losing thousands of pageviews per month due to lacking features other newspapers have, having things render incorrectly, et cetera. I have been spending a lot of time on coding stuff, and I haven't written an article myself in ages.
The biggest actual issue the Signpost faces is that everything is built on twenty years of quick fixes and workarounds and weird one-off edge cases. Implementing a new feature (i.e. having bylines on the front page, having images on the front page, retrieving the lost subheadings for ten years of articles) pretty much always requires me to climb over a pile of "one little edge case"s. I realize that for you, "one little edge case" from a random redirect in a directory it doesn't belong in may not seem like a big deal, but they add up quickly for me, especially when there are thousands of Signpost pages to keep track of across multiple namespaces.
I don't think that "Russell's teapot might have a Signpost URL written on the bottom" justifies a blanket prohibition on relocating or renaming Signpost pages unless a full copy of the 2007 directory structure (or the 2013 directory structure, or for that matter the 2022 directory structure) is preserved with redirects on top of the new locations in the same place and in the same namespace. I really don't think it's reasonable to have an open-source software project -- note that the Signpost's software structure is not in fact distinct from its content structure -- where maintainers have to spend weeks writing persuasive essays to justify every time they move a file. jp×g🗯️ 20:13, 11 February 2024 (UTC)[reply]
@JPxG: With the greatest respect, this is a lot of text in response to my !vote; so while I will try not to miss anything in this response, I apologise if I have.
I am not requesting that you writ[e] persuasive essays to justify every time [you] move a file. As I've mentioned before, I think the work you've been doing to clean up Signpost-space is genuinely admirable. I have not previously noticed any similar deletions that gave me cause for concern, and this discussion is about this one redirect in particular. With respect, this characterisation seems like a stretch here.
I appreciate that building in an exception for this redirect may be a hassle. However, my view is that, in this case - given the specific circumstances surrounding this redirect - this does not outweigh the presumption in favour of keeping it given by K4. I do not believe that this is a Russell's teapot-esque reason for keeping - rather, it is applying the Redirect guideline to the current redirect. I am not trying to make an undisprovable statement here; but rather, attempting to apply my best interpretation of wider community consensus (i.e. WP:R) to this specific case.
You also assert that [I] have not articulated any reasonable way in which this "might cause harm", which I disagree with. In my view, it is highly reasonable to think (for example) that a page which accumulated over 100,000 views over the course of its life will have had its link copied - links which will no longer work if this redirect is deleted. The deletion would therefore cause harm by breaking these links to a long-standing historical title (quoting Godsy below) - historical both in terms of the length of time the page was at this name for, and because the page in question is an archive.
Furthermore, I disagree that the log snapshot provided when visiting a deleted redirect is a suitable substitute for the redirect itself - and certainly, the Redirect guideline does not recognise it as such. I also strongly disagree with your assertion that the log links are prominently-placed - they are located in small text, in a log format that I can easily see being confusing to anyone not previously familiar with it.
In addition, there is no evidence regarding what pageviews to the redirect since its undeletion either are or are not; and I am therefore skeptical of your assertion that they are almost certainly background noise. I am similarly skeptical of the seemingly baseless assertion that pages...which referenced [the redirect] from an external site either didn't exist or were updated (which, to give only one example, doesn't take into account blog-type posts made on other websites at previous points in time - which would understandably have low current traffic).
Finally, I don't assert that the deletion of this redirect would be [t]he major problem facing the Signpost. I'm worried that the linkrot left behind by doing so might be a problem for future readers, though.
All the best, ‍—‍a smart kitten[meow] 05:06, 20 February 2024 (UTC)[reply]
I do not need you to admire me; I just want you to not actively prevent me from fixing technical debt.

It's a lot of text because I am the editor-in-chief and primary technical maintainer of the Signpost, and you are asking that maintenance be subordinated to individual committee discussions on each page based on some entirely hypothetical notion that somebody might click on a page link and you think the text that tells them to go somewhere else isn't big enough.

The text that's displayed, when the page tells somebody that the resource has been moved, is not big enough. Can you explain why this -- in the current situation -- justifies adding a page to the directory permanently, without simply gesturing to a guideline?

You say that there were "100,000 views over the course of its life", but in reality there were 16 views (including me viewing the page) the month after it was moved. The number we should be discussing is less than sixteen. These less-than-sixteen page loads the month after the page was moved is the thing that you are requesting that I be forced to write additional code (and permanently make the directory structure more useful) in order to handle.

In a comment below, I have explained how this kind of thing messes up queries and scripts. Yes -- I understand -- it can be worked around. I understand this. I am saying that working around it requires additional lines of code to be crammed into everything that handles it, and makes the overall codebase incrementally more difficult to deal with.

Since the Signpost is entirely a volunteer project, and technical maintenace on the Signpost is a subset of an already-niche area of the project, adding arbitrary "trivial" obstacles to doing it results in even fewer people being willing or able to undertake it. I do not enjoy doing this anymore; I am extremely burnt-out, and discussions like this are the main reason why. You may think you are heroically maintaining the legibility of the archives to future generations. That's fine. But it was technical maintenance that retrieved all the previously-inaccessible subheadings from articles between 2011 and 2023; it was code that got every article from 2005 to the present indexed in the module; it was code that made it possible to read the archives in full. If you want to create arbitrary roadblocks to technical maintenance, and you think it's extremely easy to write and maintain all the scripts for the project within a directory structure that's forced to be confusing and redundant, please feel free to do that. jp×g🗯️ 17:27, 20 February 2024 (UTC)[reply]
I was pinged here by something, probably one of the deleted/obsolete pages. I think JPxG should have some leeway to do the cleanup deemed necessary. The Signpost archives are a bit of a mess. I don't care about saving any prior archive layout or any legacy scripts/templates. ☆ Bri (talk) 19:02, 12 February 2024 (UTC)[reply]
  • Delete. Due to my belief that JPxG has the qualifications necessary to determine the necessity of such a page due to being a frequent contributor, and the explanation above. Cheers, UnexpectedSmoreInquisition aka USI (talk) 19:08, 12 February 2024 (UTC)[reply]
  • Keep. I applaud the nominator's effort to clean up subpages in a way that makes sense, as I tend to get in the weeds of the project namespace myself in the same manner from time to time. However, since this is a {{R from move}}, I cannot validate me supporting the deletion of this redirect. In addition, unless this redirect is intended to be reused for something else, WP:CHEAP applies. Steel1943 (talk) 21:50, 12 February 2024 (UTC)[reply]
    I have explained why it does not apply. If the price of being applauded is to be actively prevented from fixing issues, I would prefer obscurity. Every single issue that gets published involves about a half-dozen pages being moved without creating redirects.

    In this case, /Archives/ is a suburl of the main Signpost page, which should be something you can query to see how many archive pages there are. Since the Signpost was never subject to any sort of actual architecture decisions, there is a substantial amount of validation required to keep it functioning. For example, the number of issues is calculated by a database query for pages WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/____-__-__". How might we see if there are issue pages that don't have archives? Well, we can see how many archive pages there are total; maybe we will use SELECT COUNT(*) as "Number of archives" WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/Archives/%" AND page_title NOT LIKE "Wikipedia_Signpost/Archives/____" AND page_title LIKE "%SPV%", or use {{#expr: }} parser functions to subtract the output of a different template. I mean, I don't know -- I haven't written the software yet.
    It should noted that the /SPV/ pages in the archive index are redundant to the /Single/ pages in the normal index which I've created for them, so I hope to deal with those in the future, and there would only be one NOT LIKE in this statement. It's true that I could put an additional NOT LIKE in the statement to account for the lonely /Years/ redirect, or add another clause that selects based on the page_is_redirect entry in the page table. But if you look at mw:Manual:page table you can see that features are often added, removed or changed (the actor table has had a lot of changes over the years, for example). The fewer moving parts that a database query has, the less it needs to be maintained in the future (and the easier it is for someone else, who didn't write it, to do so when necessary). Moreover, there could become bogus redirects (i.e. from pagemove errors) that would be excluded from the metrics if we just say AND page_is_redirect = 0.
    One would expect it to be possible to get a full list of archive issue titles by SELECT COUNT(*) WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/Archives/____-__-__", but what I have learned in the course of writing software to deal with this stuff is that the simple tasks will sometimes unexpectedly become complicated due to unforseen edge cases -- so it is best to keep open as many options as possible by using simple, consistent conventions wherever possible.

    Here is a concrete example -- last January I went through the index of all pages, and found that there were upwards of a hundred useless redirects with no incoming links. Article names had been originally created with typos, or they were postponed, and whoever retitled them forgot to check the button to move without a redirect (or didn't have extended pagemover). This meant that SQL queries for e.g. {{Signpost/Number of articles}} was inaccurate by about a hundred, and that the module indices had hundreds of entries in them for nonexistent articles (and, similarly, that PrefixIndex results for Signpost articles would give incorrect results). Any attempt to analyze or graph output by year/issue would be inaccurate. Any attempt to make a list of articles would include nonsense. It took most of an afternoon to fix these, but now they are fixed and the problems no longer exist. Note that it did not take a month to engage multiple people in a formal discussion process to seek approval for each individual item, nor was the work prohibited on the basis of an abstract idea that redirects are always good. They were not "cheap", they made it impossible to do many tasks so long as they existed. Now, however, you can see the output of {{Signpost/Number of articles}} which is obtained using SELECT COUNT(*) as "Number of articles" FROM page WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/____-__-__/%" AND page_title NOT LIKE "%/SPV"; and produces an accurate number of (currently) 5,503. Note, furthermore, that this is four lines of SQL, and not five, or six, or ten, because there are no workarounds necessary except for the /SPV pages (which I am working on anyway; when these are fixed the report should only be three lines of SQL).

    Another example: I found a bunch of ghost articles in 2023, i.e. titles Wikipedia:Wikipedia Signpost/2006-09-12/News and Notes when there was no corresponding issue at Wikipedia:Wikipedia Signpost/2006-09-12. There were also ten ghost issues -- issue pages that had no subpages, corresponding to daily editions that weren't actually published, or created in error, or at the wrong location and moved. Again, these caused inaccurate statistics and broke some features. Any code that generated a list of issues was giving a list of nonsensical ghost issue links. Here, too, the pages were fixed without issue. This process was made possible by the fact that the number of redirects in Signpost article space was zero. Some backlinks did need to be fixed, which I was happy to do. As a result, {{Signpost/Number of issues}} returns 690, and not some other incorrect number. Similarly to the other template, it is a very small SQL query (SELECT COUNT(*) as "Number of issues" FROM page WHERE page_namespace = "4" AND page_title LIKE "Wikipedia_Signpost/____-__-__"). This is a very small query, that requires virtually no documentation or specialized knowledge to understand. If there were a bunch of random unrelated crap pages in the directory, it would be a longer query, with confusing one-off edge-case handling.

    jp×g🗯️ 17:06, 20 February 2024 (UTC)[reply]
  • Keep - I do not see a reason to delete a long-standing historical title (e.g. broken external links, the preservation of wiki. history, etc.). I am, however, sympathetic to the idea that this would need to be deleted on technical grounds to prevent undue maintenance; if anyone can articulate that a bit more clearly and briefly, I would consider changing my opinion (please ping me as well). Could it not simply be ignored in such code? — Godsy (TALKCONT) 03:27, 20 February 2024 (UTC)[reply]
    @Godsy: See my comment above; I've tried to explain how inconsistent directory structures can cause issues. jp×g🗯️ 17:28, 20 February 2024 (UTC)[reply]
  • Keep per A smart kitten, Steel1943 and Godsy. There are well articulated reasons to keep this content easily accessible via these titles and clear potential harm from deletion that combined far outweigh the reasons presented for deletion. Thryduulf (talk) 05:23, 20 February 2024 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: While I do think there is currently enough of a consensus to keep, I want to give this more time to play out based on the nominator and their rational.
Please add new comments below this notice. Thanks, Hey man im josh (talk) 18:49, 20 February 2024 (UTC)[reply]

@Hey man im josh: I'm confused - the last three !votes have been to keep. I'm not seeing how there's currently consensus to delete. All the best, ‍—‍a smart kitten[meow] 19:06, 20 February 2024 (UTC)[reply]
Sorry @A smart kitten, I wrote it backwards. I've corrected this mistake. Hey man im josh (talk) 19:08, 20 February 2024 (UTC)[reply]
  • Delete. My first Wikipedia edit in a long time as I was pinged on this as the original creator of some subset of the pages under discussion. I don't understand why something that is clearly administrative in nature requires a wall of text of justifications to satisfy old-timers obsessed with pedantic details of links you can't even prove exist. ResMar 05:13, 21 February 2024 (UTC)[reply]

Qatar 2023

"Qatar 2023" is not unambiguously affiliated with the 2023 AFC Asian Cup and I propose retargeting to 2023 in Qatar. I've tried to change the target, as has another editor (Significa liberdade), and instead of edit warring I'm seeking feedback on this.

It is my belief that "CountryName Year" redirects should be pointed to YYYY in CountryName. I made a similar nomination here, where I nominated a number of CountryName Year redirects. Hey man im josh (talk) 18:44, 20 February 2024 (UTC)[reply]

  • Retarget per nom. Google search gives a couple different results, and the first one is the 2023 Qatar Grand Prix rather than the AFC cup. No clear primary topic, and even if there was it seems somewhat wrong to declare that a search for country + year gets some specific sporting event. Rusalkii (talk) 19:45, 20 February 2024 (UTC)[reply]
  • Retarget per nom in the absence of a primary topic. - Presidentman talk · contribs (Talkback) 20:22, 20 February 2024 (UTC)[reply]

List of "Cops/COPS/C.O.P.S." episodes

Previous RfDs for this redirect and similar redirects:

I know we just had a discussion for List of Cops episodes (and I participated in the respective discussion), but I made my comment in that discussion prior to noticing the existence of List of COPS episodes. The problem here is that WP:SMALLDETAILS probably does not differentiate the two topics enough, given that Cops (TV program) can be stylized as "COPS" and COPS (animated TV series) is apparently stylized as "C.O.P.S.". In addition, at Cop#Television, there are additional TV show/program subjects listed which include an inline list of episodes. So, with all that said, I'm not sure what is the best path here. (I've also added List of C.O.P.S. episodes for completion of this nomination so others know of its existence, but I'm "weak keep" on that per my previous statement about the "C.O.P.S." stylization; either way, List of C.O.P.S. episodes is a {{R with history}}.) Steel1943 (talk) 18:18, 20 February 2024 (UTC)[reply]

January 6 hostage crisis

Misleading/POV redirect. — Rhododendrites talk \\ 18:31, 4 February 2024 (UTC)[reply]

Please correct me if I'm wrong, but I didn't see mention of "Jan 6 hostage crisis" in the citations. Could it belong on one of the Trump articles? DN (talk) 18:48, 4 February 2024 (UTC)[reply]
Retarget. Some section about Trump's comments (or those of other Republican politicians) about "January 6" might be a better redirect target. Shankar Sivarajan (talk) 18:52, 4 February 2024 (UTC)[reply]
@Darknipples: Please be aware that your !vote is actually a proposal to "retarget", and not to "refine", as the article you're suggesting is completely different from the present target. CycloneYoris talk! 03:15, 12 February 2024 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Delete, retarget, or refine?
Please add new comments below this notice. Thanks, CycloneYoris talk! 03:04, 12 February 2024 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: Also notified of this discussion at the talk page of the proposed targets.
Please add new comments below this notice. Thanks, Jay 💬 15:34, 20 February 2024 (UTC)[reply]

List of Cogs

There is no list of cogs at the target article. Perhaps in the past (and before the offshoot into List of Gears of War characters that's currently a redirect), but now this redirect has very little to offer readers. Utopes (talk / cont) 04:40, 23 January 2024 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, CycloneYoris talk! 08:40, 30 January 2024 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, 🌺 Cremastra (talk) 21:22, 8 February 2024 (UTC)[reply]

  • Delete per nom. I see no value in having this redirect, particular where there is no list of cogs in target. - Dyork (talk) 00:51, 9 February 2024 (UTC)[reply]
    Which is why I initially suggested retargetting to a page that has such a list, and Duckmather is suggesting disambiguating between a list of COGs and the page with a list of cogs. Thryduulf (talk) 04:19, 9 February 2024 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: One more try…
Please add new comments below this notice. Thanks, CycloneYoris talk! 03:15, 20 February 2024 (UTC)[reply]

Philippines Disputed Territories

The following is an archived discussion concerning one or more redirects. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review). No further edits should be made to this section.
The result of the discussion was withdrawn/retarget to Territories claimed by the Philippines. No point leaving this here when my nomination rationale was faulty and no-one has supported deletion or anything else. An obvious suitable target does exist. A7V2 (talk) 23:36, 20 February 2024 (UTC) (non-admin closure)[reply]

There is no discussion of the Philippines at the current target, nor was there when this redirect was created back in 2005 [5]. The Philippines seems to be involved in several territorial disputes, both past and present, and many are listed on List of territorial disputes, and some have their own articles such as Territorial disputes in the South China Sea. There is also the article List of internal boundary disputes in the Philippines. I had expected to find an article called something like Territorial disputes of the Philippines, but no such article exists. I'm unsure what should be done with this redirect, but given lack of a clear best choice I'm leaning towards delete. Certainly the current target is not suitable. A7V2 (talk) 01:25, 20 February 2024 (UTC)[reply]

The above is preserved as an archive of the discussion. Please do not modify it. Subsequent comments should be made on an appropriate discussion page (such as the redirect's talk page or in a deletion review).

Template:R from project

Potentially ambiguous rcat redirect, considering that {{R to project}} redirects to {{R to project namespace}}. I'm also not sure that one thing being a project of another thing necessarily implies that the former is a subsidiary of the latter - for example, a person could be said to have a project, but such a project wouldn't be considered a subsidiary of that person. For these reasons, I propose deletion. All the best, ‍—‍a smart kitten[meow] 00:16, 20 February 2024 (UTC)[reply]

1792 presidential election

I'm looking at the target, and there appears to be exactly one Presidential election in 1792: the 1792 United States presidential election. As such, I don't think this is an ambiguous search term, so I'm bringing it here seeking a retarget. — Red-tailed hawk (nest) 00:06, 20 February 2024 (UTC)[reply]

  • information Note: Bundled Presidential election of 1792 into this nomination (courtesy ping Red-tailed hawk). All the best, ‍—‍a smart kitten[meow] 00:35, 20 February 2024 (UTC)[reply]
  • If there had been other presidential elections in 1792 for which there were articles then at the least these should be refined to the section on 1792, but as that is not the case, retarget to 1792 United States presidential election per nom. A7V2 (talk) 01:28, 20 February 2024 (UTC)[reply]
  • Retarget per nom. Not only do we not have articles about other presidential elections in that year, I can't find any evidence there were others we could have articles about. Eventually, using the search term "1792" "presidential election" -"United States" -Washington -"college" -"US" -"U.S." I got a few hits related to something other than US presidential elections on page 2, these related to a battle in 1792 that The Independent speculated may have some meaning for the 2006 French presidential election, the 2019 Nigerian presidential election (in which one candidate received 1,792 votes), the president of a company called "1792 Wealth Advisors", Marie Antoinette (who was imprisoned in 1792), a list of Early Day Motions in the UK House of Commons that includes motion #1792 and a motion related to the 2009 Iranian presidential election and an alternate history wiki. Thryduulf (talk) 04:02, 20 February 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Redirects_for_discussion/Log/2024_February_20&oldid=1209289800"