UESPWiki talk:Deletion Policy/Don't Prod Redirects

This is an archive of past UESPWiki talk:Deletion Policy discussions. Do not edit the contents of this page, except for maintenance such as updating links.

(moved from UESPWiki:Community Portal#Don't_Prod_Redirects)

Wrye 1 and Replies

The problem with prodding redirects is that checks of external usage are simply not reliable. To take a an extreme case: Tes4Mod:Wrye_Bash_Help. There are no longer internal links to this and a check with google reveals no links. However, that check fails to reveal links from here and here, even though both of these are very well indexed pages with google (in fact these two are the top two results of the search results when googling for Wrye bash.) Worse than that... Each downloaded copy of Wrye Bash includes an html documentation page with links to Wrye Bash Help. I don't have exact counts, but that would be (conservatively) on the order of 100k web pages pointing at Wrye Bash Help. In other words, deleting the redirect would break about 100k links.

Now that's an extreme case, but other redirect pages that have recently been prod'ed are also linked to from outside the site. Those links will also be broken by deleting the corresponding redirects.

While I understand the desire to "clean up" the site, the reality is that the checks for external links are not reliable -- and even if they were reliable, they would fail to account for individual bookmarks, local web pages, etc.

Meanwhile, leaving the redirects in place causes no problems for the site and places insignificant load on the site.

Hence, I would suggest that as a matter of policy, that redirect pages not be deleted. (And that any currently prods of redirects be reverted.)

(The only case in which I think a deletion of a redirect makes sense is one in which the original author begins a page and then moves the page shortly after creation and before the page has received external links, and thus knows that no external pages are yet linking to the original page name.)

PS: I've unprodded a few of these redirects for which I'm reasonably aware of external links, but being pretty much retired, I'll stop there. :D --Wrye 20:32, 16 September 2008 (EDT)

One reason why there are a quite few external links that point to the redirect pages instead of the articles themselves is because the redirects were around so long. If a redirect was up for quite a long time, there is nothing wrong with expecting that other sites should have updated their links in that period. Yea, it's a shortcoming that URLs can only point to one specific location, but that's just how it works, and keeping around old pages because of only that isn't generally a good idea. Now I agree that some redirects may be kept in place, I removed a few Prods myself, but for the majority they are only around because no one has bothered to remove them before. The few valid ones shouldn't stop us from cleaning up the site. --Timenn < talk > 01:11, 17 September 2008 (EDT)

Sigh. See Wikipedia:When should we delete a redirect. Of course, we're not Wikipedia, but in this case, the exact same logic applies. There is everything wrong with expecting other sites to update links to adjust for redirects. Most of the point of redirect pages is that they allow you to safely move pages without breaking links to them. Obviously, later deleting redirects, just to make the site "cleaner" in some abstract way breaks the very purpose of a redirect. Quoting the wikipedia article above,

The major reasons why deletion of redirects is harmful are:

a redirect may contain nontrivial edit history;
if a redirect is reasonably old, then it is quite possible that its deletion will break links in old, historical versions of some other articles — such an event is very difficult to envision and even detect.

Therefore consider the deletion only of either really harmful redirects or of very recent ones.

In short, the redirects being prodded are neither harmful nor very recent. Leaving them in place costs nothing. They should be left in place. --Wrye 02:41, 17 September 2008 (EDT)

I agree with Timenn. We've been deleting redirects for months with no complaints and I see no reason to stop now. A glance in the deletion log shows that of the 500 most recent deletions, over 100 have been redirects so I'm not really sure why this is suddenly an issue. Having said that, I can acknowledge Wrye's point. I don't support his change to the deletion policy but may I suggest an alternative? Create a new template specifically for the proposal for deletion of redirects and only delete redirects after a period of six months. This is roughly what's already happening in the Namespace move project. Six months is more than enough time for anybody affected by a duff link to fix it or, alternatively, remove the prod explaining in an edit summary why the links can't be fixed. –Rpeh^{•T•C•E•} 03:15, 17 September 2008 (EDT)

We are not Wikipedia for a good reason. Wikipedia has quite a different environment than us. Where we have the luxury that we have a wide array of official titles availabe (think of NPC names, quest names, etc.), titles of subjects for Wikipedia are usually have none. For us, there is usually only one source, the game files. Wikipedia has to deal, among others, with differences in capitalisation of words. They also have a much larger amount of disambiguation pages than we have (they aim to set up as much as needed, we like to avoid them with our namespaces organisation). In short, Wikipedia has a large amount of redirects that are practical, and are not there simply because old links may point to them; their guidelines were written partly for that reason.

The first argument, that redirects may contain a valuable edit history can be refuted with the fact that many of the Prods for those redirects were deleted precisely for that reason. We are already keeping the pages with a nontrivial history. Most of our redirects were either by move or because of a misspelling, not by design. Just like programming languages, we need to deprecate that that we no longer wish to support. --Timenn < talk > 03:22, 17 September 2008 (EDT)

First off to deal with the Wrye Bash issues; could Wrye not simply change the links on his website? It would take a while for all the mod users to update their links, but it would eventually happen. The other thing is could Wrye not simply have help files on the website itself? I'm not suggesting they should be removed from the wiki, but that they could also be on the site. The majority of people, if they couldn't find help files, would go straight to wryemusings.com to search for them.

Secondly. Although one redirect is hardly going to strain the site, I prodded at least 100 of them and there are probably more. Once one gets into these larger figures, it can start to affect site performance. It also causes our statistics page to be slightly missleading.

As has been said before; this is not wikipedia. Wikipedia's policies were written for wikipedia. Although many of their policies may be similar to UESP's, they aren't identical, simply because the two wikis are organized differently and require different approach.

As Wrye said,

"The only case in which I think a deletion of a redirect makes sense is one in which the original author begins a page and then moves the page shortly after creation and before the page has received external links, and thus knows that no external pages are yet linking to the original page name."

We're in this situation soley because this wasn't done upon movement of the pages. Saying, "As we've left it alone up until now, we might as well never change it", is like saying, "As we've never bothered take this garbage out, let's just leave it where it is". If we never delete redirects, they'll slowly build up, until they start to take a more serious strain on the site. The longer we allow them to build up, the harder it will be to clean them up in the end, which will almost certainly have to be done at some point.

For these reasons I say we should delete the redirects and maybe even add a new policy saying that after a page movement, the mover should check all links, update them, then add a "Prod" tag to the newly created redirect. This would then help solve possible problems in the future. - Game Lord^{Talk|Contribs} 16:25, 17 September 2008 (EDT)

My take on it is that rules...errr...links were made to be broken. Okay, so ideally they shouldn't be, and we should ensure that all internal links get changed accordingly, and do our best to make sure that external ones do as well, but it's not our responsibility to ensure that external sites have valid links in perpetuity. Sometimes links get broken and they'll need to be fixed. Such is the nature of the Internet. So to my way of thinking, Redirect pages should be prodded and then deleted (assuming the prod is seconded by another admin) with no significant concern as to how it affects other sites, provided that the prod is in place for a suitable amount of time. I'm sure if a link gets broken, someone will notice it and either fix it or report it soon enough. --Robin Hood (Talk • E-mail • Contribs) 01:23, 18 September 2008 (EDT)

Wrye 2

You know, I didn't seriously think that you all would condone breaking 100,000 links. So I'm a bit flummoxed that actually seems to be the consensus here. ("Links were made to be broken.") That's crazy. Anyone who thinks that breaking 100,000 ("100k") links is okay has completely lost sight of the purpose of UESP. (Which is to provide useful information to users, not to give admins a way to spend their time.)

Some points:

What's more amazing then the willingness to break 100k links is that there's not even any substantial advantage to be gained. Deleting pages doesn't reduce database size (since even "deleted" pages are kept in the database.) Nor does it have a substantial impact on performance -- the load associated with handling a redirect is trivial -- probably about the same as handling a single image. (Think otherwise? please point to the evidence). And think about this: if a redirect is not heavily used, then it certainly doesn't have an affect on performance. OTOH, if it's heavily enough used that it actually has some affect on performance -- then it's clearly too heavily used to be deleted!

This attitude that it's okay to break outside links, or that outside pages should be "fixed" is just crazy. The very point of redirects is to prevent links from breaking! Redirects allow wiki users to move and consolidate pages in the way that's most useful without having to worry about breaking links. Put another way, if I (as an editor) thought that redirects would be auto-deleted after a while, then I would never move a page! That sort of thinking is undesirable -- it's better to allow people to move pages without fear of breaking things, since that freedom results in a better structured site.

Re Wikipedia vs. us. Of course, (as I've argued before) we differ in places -- but when we use different rules, we use different rules for a reason. E.g. we have more original content that Wikipedia, hence we lack Wikipedia's rules against that. Similarly, we have less people available as admins -- hence the control of the site is somewhat different. But no one above who has given the "we're not Wikipedia" argument has explained how we're not like Wikipedia in this sense. And in fact, we're not -- the relevant factors -- outside sites linking to us, and negligible server load -- are the same for both us and Wikipedia.

"Just like programming languages, we need to deprecate that that we no longer wish to support." I've programmed in more than thirty programming languages (once you hit twenty or thirty, you tend to lose count) -- and I'm well aware of what deprecation is in programming languages and libraries -- and that has nothing to do with a wiki. Moreover, this is not an area in which admins should be deciding that "we don't want to support that anymore". The content was put there by users -- that content should not become broken or "unsupported" by "us" without an extremely good reason. Again, when you start thinking like this, then you've lost sight of the purpose of the UESP (and contracted a bad case of administritis).

A bit more amusing irony here... From the prod note text: "Administrators, don't forget to check the page history (last edit), what links here, and the external links before deletion." The implication of course is that the page should not be deleted if external links exist. Which is in contrast to the policy being suggested here, which seems to be "Delete the page regardless of whether external links exists -- after all links are made to be broken."

Like I said, the Wrye Bash Help page is something of an extreme example. I thought that it would be so obviously crazy to delete that redirect, that it should help make the point that google linking checks are unreliable. The fact that the everyone else here seems to be okay with deleting such a redirect should be sending fire bells off -- what we're looking at here is serious administritis. It makes me wonder where else is someone "cleaning stuff up" regardless of the utility to users.

--Wrye 20:49, 21 September 2008 (EDT)

PS: The number of external links shouldn't matter -- one external link should be sufficient to avoid deleting a redirect page, but in case anyone is wondering about the 100k number, here's the math... Wrye Bash had 13,600 downloads in August 2008 (which is about normal for a month these days). Each download includes an html doc with links to the Wrye Bash Help page. Figure that link has been there for about two years. So, 24 months * 13,600 equals 326,400 pages. But people update Bash (thus resulting in double counting), and Bash's popularity has grown in time (previous month download counts were lower), so cutting that figure down by 1/2 (to 163,200) would be reasonable, and cutting by 2/3 (to 108,800) would be conservative. But even at the conservative count of 100,000 pages, this is very likely the most heavily linked to page on the site. And you all think it would be a good idea to delete it??? Unbelievable. --Wrye 21:01, 21 September 2008 (EDT)

If I'm understanding that right, that's not 100,000 links or 326,400 links or anything of the sort...it's one link on 326,400 documents. Or am I misunderstanding? Assuming I'm correct in my understanding, that means you change the one link today, and all future distributions have the correct link. 6 or 8 months from now, almost nobody has the old link any more, and those that do can readily Google it to find out where things have moved to.

I think the larger point is to remove redirects that are no longer relevant. Redirects that serve a purpose, such as those that are hit heavily from outside sites (assuming we can monitor that) should not be prodded at all.

I think the concept of perserving things like redirects in perpetuity because one outside site still references it is ludicrous. We are responsible only for our own content. At least in my mind, that's where our responsibility ends, and we only maintain compatibility with outside links as a favour to those who are linking to them. Of course, I'm not an Administrator, so my views are just that...my views...not policy in any way. --Robin Hood (Talk • E-mail • Contribs) 21:35, 21 September 2008 (EDT)

Wrye, I'd already suggested that if there's a valid reason for keeping a redirect, somebody can "remove the prod explaining in an edit summary why the links can't be fixed". You've already done that so the Bash links are no longer a problem. The new waiting period of two months for redirects should be more than enough to prevent anybody else being affected by the same thing. Comments on the new suggestion would be welcome. –Rpeh^{•T•C•E•} 01:59, 22 September 2008 (EDT)

Nephele

I'd been hoping this discussion would resolve itself without any need for me to contribute, given that my recent attempts at contributing feedback have mostly been disastrous rather than productive. Nevertheless, I seem to have been dragged in, and I don't feel that I can take the time I would like to carefully edit my contribution. Therefore, please let me apologize in advance for any unintended interpretations of my comments. I am calm. I am simply trying to express my opinions about the issues at hand -- including not just the most recent proposal but also earlier proposals and repeated suggestions.

Overall, my reaction is that we have far too much variety in redirects to come up with any single universal policy about their deletion. There are clearly some redirects that can safely be deleted. On the other hand, it is definitely not true that all redirects are automatic candidates for deletion. The variety of reasons for creating redirects and the range of possible article histories mean that decisions about which ones need to be kept and for how long really need to be made on a case-by-case basis. Those decisions should be based upon what will make the site the most useful for the site's readers -- not merely what is convenient for the site's editors. The people who are linking to UESP from other sites are our site's readers, and their ways of accessing the site should not be dismissed merely because they surf the web and contribute to multiple websites. The fundamental power of redirects lies in their ability to allow the same content to be accessed in many different ways, making the site useful to many different readers with many different ways of using the site.

Extra redirects do not have a negative impact on the site. Wrye beat me to the punch and already provided several valid points about redirects, so I won't repeat those. But there are several other points I'd like to make in reply to previous contributions:

Even 100 redirects are virtually insignificant for the site. There are more than 50,000 pages total on the site, so 100 redirects represents less than 0.2% of the site's pages. Even if redirects did have any overhead, a 0.2% reduction in that overhead is insignificant. A 0.2% reduction of zero impact is completely inconsequential.
Redirects do not in any way cause the site's statistics to be misleading. The number of legitimate "content" pages on the site is (at this moment) 13,279. That number explicitly excludes "...redirects, and others that probably don't qualify as content pages." So we don't need to delete redirects to keep our content count "clean". (In fact, the deletion process does more harm to the site's statistics than the redirects themselves: proposing a redirect for deletion will generally turn that redirect into a "valid" content article. So if statistics were the top priority, we probably wouldn't want to ever delete redirects).
The redirects created from moving pages are insignificant in number compared to the intentionally created redirects on the site, in particular the tens of thousands of redirects covering every single item that exists in the games. If 100 redirects really were such a drain on the site, we would not have created countless item redirects. Short of a bot-implemented page reorganization, there is no way for redirects created from page moves to ever become a significant fraction of the site's redirects, even if left in place for years.

Also, any discussion of how UESP's redirects are used by external sites should take into account the nature of those external sites. The single site with the most links to UESP is Bethesda's official forums, and several of the assumptions made in this discussion really do not apply to the official forums. For example:

Updating old links in forum discussions is not going to happen. The only people who conceivably could edit old threads are the forum moderators; I'm sure the forum moderators have no interest in adding to their workload simply because UESP wants to clean up some redirects.
There is no convenient way to find out which UESP pages the official forums use. Bethesda explicitly prevents most of its site (including the forums) from being indexed by search engines. So the "external links" link that appears in the proposed deletion box is never going to list any forum pages, rendering that list of external links somewhat useless.
The official forums have some quirks that can at times be annoying, such as automatically locking threads after too many posts and deleting old threads. But that doesn't mean that we should make the official forums even more frustrating for Elder Scrolls players by adding new problems. If a player has been desperately searching for a bug fix, there would be almost nothing more frustrating than finally finding a thread discussing the bug -- just to have the vital link in that thread be broken. That player won't report a problem with a missing link (the player won't even know what the correct link is supposed to be); the player is far more likely to conclude that UESP is a useless, broken website.
If we really want forum members to continue using UESP as a resource, and want forum members to continue posting links to UESP articles in threads, I think we should make reasonable efforts to ensure that those links continue to function, at least until the thread is deleted. Otherwise, we are in some ways encouraging forum readers to copy UESP articles instead of posting links to the articles, because we're saying that copy-and-paste is more reliable in the long term than a link to a UESP article. If UESP adopts a policy stating that external links are irrelevant in making decisions about whether or not redirects should be kept, that policy is effectively saying that links to UESP articles from other sites are unreliable. That's not a good way to promote the site in my opinion.

These arguments lead me to believe that we should be cautious when deleting redirects. Any potential use of a redirect means that readers are likely to be helped by the redirect -- and that utility should outweigh abstract arguments with no effects on readers (such as reducing the number of links appearing in various special pages). Nevertheless, it does not mean that redirects can never be safely deleted. It also doesn't (or at least I thought it didn't) imply any fundamental change in existing UESP policy: up until now, we have been preserving redirects when it seems likely that those redirects are used externally. Two large-scale examples are the Tamriel book reorganization done last summer and the Tamriel->Lore namespace move done earlier this year: in both cases, the redirects have been left in place for extended periods of time primarily to prevent broken links on other sites.

A policy change prohibiting deletion (or requiring a universal two-month delay) of redirects would unnecessarily prevent and/or complicate clean up of the dozens of redirects that can safely be deleted. For example:

Many redirects (including the majority of those currently up for deletion) are very unlikely to have any external links:
- /Description and /Author subpages
- Talk page redirects
- Pages that were only created an hour earlier (e.g., pages created with an incorrect name, that were immediately moved to the correct name).
Some redirects will have a negative impact on the site and we should be able to delete them. In particular, main namespace redirects will interfere with searches on the site. Any policy revision needs to accommodate such cases.

Trying to come up with a policy that summarizes which redirects are safe and which aren't seems nightmarish.

The existing proposed deletion process is supposed to provide a way to deal with the variety of UESP articles and allow for a case-by-case judgement call. No single editor is likely to know all the ways in which a given page is being used, so it's probably not possible for individual editors to establish which redirects are safe for deletion and which aren't. However, the week-plus interval before the article actually gets deleted provides an opportunity for everyone else on the site to review the deletion candidates, in case there are issues that were originally overlooked. Similarly, the previously-debated two-admin rule is also in place to help prevent oversights. I basically think that the existing deletion system, if used as intended, provides an effective way to strike a balance. But effective use of the deletion system also means that we should not start second-guessing reasons provided by editors for maintaining a redirect. If Wrye says that there are external links to Tes4Mod:Wrye_Bash_Help, that statement alone should be sufficient reason to keep the link, period. Wrye should not have to justify the external links, or respond to suggestions that he re-write his website and his documentation.

I strongly disagree with the suggestion that we "add a new policy saying that after a page movement, the mover should check all links, update them, then add a "Prod" tag to the newly created redirect." Such a policy would, in my opinion, be reckless and irresponsible. The lifetime of the new redirect is irrelevant in determining whether or not the redirect needs to be kept. Far more relevant is how long any article with that name has existed: if the article had previously been under that name for years, we should not be deleting the article a week after moving it. Readers need to be given some opportunity to find out about a name change before they can adapt to the name change. In many cases, the redirect needs to be kept permanently (alternate spellings used in-game, for example), a possibility that is in violation of this proposed policy change.

If it is imperative to implement a system ensuring that certain redirects will eventually be cleaned up, I think there still needs to be further discussion. I'm not altogether clear on the details of what's being proposed. I don't think we should immediately create a broken redirect by placing a prod tag on the page, even if we're keeping the prod in place for two months. That's just two months of unnecessary inconvenience for the site's readers. I also have concerns about implementing an across-the-board two month interval for all redirects. We're keeping the Lore redirects in place for six months; on the other hand, for many redirects delaying deletion for two months seems unnecessarily long. Why should a fixed two month interval be applicable to all articles, whether they've been in existence for one hour or two years? Finally, I do not think that any such system should override existing reasons for maintaining redirects. --Nephele^Talk 22:11, 22 September 2008 (EDT)

I'd agree that some redirects are safer to delete than others but since the original suggestion was that we should never delete any redirects of any kind I responded in kind. There wouldn't be a problem in suggesting that redirects from Author and Description subpages plus talk pages could be subject to the current seven day rule and others to a longer period. Further, redirects less than a day old should probably come under the Speedy Deletion category as they're almost always down to errors of some kind.

My reason for suggesting a longer period is that it should be ample time for users to spot a potential problem and either relink, remove the prod or deal with it in some other way. My reason for wanting to delete the redirects at all is that we're encouraging incorrectness by keeping them around. People linking to "Adanamuran" should be told that the place doesn't exist. People linking to "Arcturius" should realise that there's no such person. We don't allow common misspelling redirects to be created and I see no good reason why we should leave them around either.

I agree it's different with Daggerfall: the quest names are all made up and indeed, we use some names that are different from the Daggerfall Chronicles. In these cases I think the names originally chosen were so bad ("Scroll"? "Protect Guild"? Ugh!) that we should have fixed them earlier. I'd prefer to see them go, but I can understand if people want them kept. Where redirects need to be kept for reasons such as multiple in-game spellings (e.g. Ienas Sarandus/Sarandas) the redirects can be kept and categorised. GameLord did some of that during his trawl through the redirects as well as sifting out the chaff.

I'm aware of the Forum linking problem but remember that the forum threads get deleted after some time anyway. Also, given that they aren't indexed and we are, people are far more likely to come direct to UESP than via a forum.

In summary, I'm not suggesting a deletion of every single redirect - and neither is anybody else. Delete the rubbish and mark what's required so that we'll know in the future. –Rpeh^{•T•C•E•} 04:38, 23 September 2008 (EDT)

Thanks Nephele. Again, this was the primary concern that I had: "Those decisions should be based upon what will make the site the most useful for the site's readers -- not merely what is convenient for the site's editors." I'm glad to see that point be reinforced.

Now, some brief comments on rules in practice:

As for case by case basis, that's difficult to do, but perhaps some rules of thumb would be useful. Since I'm mostly familiar with the Tes3Mod and Tes4Mod (and familiar with how those are used within the rest of the community), the simple rule that I would suggest for that area: if the access count is less than twenty, then the redirect can be deleted. Otherwise the redirect should be left in place permanently.
- Tes3Mod and Tes4Mod pages are particularly prone to being linked to from other sites (especially the forum) -- oftentimes at the time of creation (e.g. I have several times faced a question on the forum or the CS Wiki, then created a page here and immediately linked to it). Hence even a "moved soon after creation" rule is suspect. However, a particularly low page count should be fairly reliable.
- Note that even forum topics cannot be assumed to be eventually deleted. Since forum members are aware of Bethsoft's deletion policy, many people make a habit of archiving forum topics. Some such archives are available on the web (e.g. Yacoby's archives), others are maintained on user's computers. Also different forums are treated differently (Morrowind forums are cleaned less frequently than Oblivion). And other forums other than official forums exist. In short, it's not safe to make assumptions about links made on forum topics disappearing.
A review process for links (one person proposes for deletion, and deletion is completed if no-one objects) may be unreliable simply because the people who are most aware of the potential problems may be inactive. I'm the most informed person on the site regarding Tes3Mod and Tes4Mod pages -- but I'm "99.5%" retired these days. I don't check the forums or this site nearly as frequently as I used to, and have much less time available to address potential problems. So, a review process that assumes that anyone knowledgeable will see the affected pages and comment on them is problematic.

As I've said, I have less time available to review material these days (in fact time available is almost zero). However, I'll re-review the prods in the Tes3Mod and Tes4Mod namespaces, and unprod the pages that fail the < 20 access rule of thumb. (While I personally would rather have even the < 20 count pages left (given the effectively zero cost), I'll grant that their removal is pretty unlikely to break any links.)

Final note to Rpeh... Page history comments are not the place to: 1) address other users, 2) issue perempetory commands, or 3) make assumptions/implications about the emotional state of other editors. (Actually the last two should not be done even on talk pages.) If you need to address another user, then the current talk page or the user's talk page is the place. Regards... --Wrye 17:42, 23 September 2008 (EDT)

My opinion is nothing that hasn't been stated already, but I will add my voice regardless. Hyperlinking is the fundamental building block of the World Wide Web, of which UESP is, for better or for worse, a part. On the Web, a link should work for as long as humanly possible, and therefore a given URI should point to the same content for as long as humanly possible. We cannot know for certain what links to UESP and where, but we can be certain that we want readers who come from other places---especially first-time readers---to have as pleasant an experience as possible. If one does happen upon a link to UESP and, expecting to find information they crave, instead finds MediaWiki's entirely non-helpful "this page does not exist" placeholder, this is not an auspicious start for the reader in question, and it reflects badly upon us, especially if the content is in fact still on UESP.

As far as I know, it's trivial to maintain redirects. If said redirects are an administrative hassle, this is not a policy problem; it's a software problem, and MediaWiki (or UESP's installation thereof) should be changed so that the software more effectively fulfills its purpose. It is our responsibility as providers of information, as editors of a Web application, to be aware of the wider nature of the Web and not to alienate potential readers.

The only situations in which I would consider a redirect safe to delete are if a) the page the redirect points to ultimately no longer exists, in which case the net result is the same, or if b) the redirect was accidental, in which case the possibility of the redirect being missed are minimal. Everything else should, I think, stay. In perpetuity. For all time, if at all possible: it's how the Web is designed to work. JKing 20:20, 23 September 2008 (EDT)

OK, once again I've watched from the sidelines while this has unfolded. My apologies if I'm just repeating, but I thought I'd add another voice to the cacophony... I'll be honest, originally my thoughts were influenced by my lack of knowledge of the way the wiki software works. At first, I was thinking it was somehow detrimental to site performance. As always, Nephele's post really enlightened me. If there's no negative impact to keeping a redirect, then why delete it? Now, I am not saying that I agree that no redirects should ever be deleted - if a person creates a page with with an obvious error (such as a blatant typo) then it makes sense to go ahead and delete the redirect when the page is moved. If the page redirects to a non-existent page, then the redirect might as well be deleted to avoid misleading readers into thinking that there is a page. In other cases though, to simplify my point of view, I fail to see what would be gained by deleting the redirects, and a couple of good points have been made to show what could be gained by keeping them. I'm all for keeping the site "clean", but I'd rather it be messy and user-friendly than clean and frustrating for readers. --GuildKnight^Talk2me 22:47, 23 September 2008 (EDT)

Timenn

\=> Perhaps it has not been explicitly stated, perhaps it has, but I want to emphasize: I, and I think I speak for the others, do not insist on deleting most redirects, merely opposing the general inhibition of deleting any redirect at all.
I've read all the comments, and it seems to me that in the end everyone agrees, Wrye in his latest post, that there are at least some redirects that should be deleted. Therefore, I think the title of this discussion is misleading, we are not discussing that. What we are discussing is the criteria for deleting a redirect. I think this has put several editors on the wrong track.

For redirects, I've deduced the following three categories from the above comments, that should represent our concern for the more often used redirects:

Redirects that are at all not necessary, think of /Description pages.
Redirects that may or may not be used with external links.
Redirects that are in place to ensure that multiple titles direct to the same content.

It would seem to me that redirects in the first category can follow the normal Proposed Deletion procedure. It's highly unlikely that they're used outside this site. Redirects in third category should not be deleted, as they are likely in widespread use. What we need to focus on is to define what redirects fall into the second category, and what to do with them. Deleting them all is not a good idea, but neither is not having a procedure for them at all. I disagree that we cannot handle redirects case by case, it allows for consensus rather than premature deletion.

Let me first explain why I think some redirects should be deleted. My concern is not the site's technical performance, but the amount of mistakes that linger around. A misspelled page is a mistake, and if it can be deleted it should be. It's just like that we fix spelling mistakes in articles, it allows better readability. In this case it's the ability to navigate the site properly. If I put up an external link on some page, I check whether it works. Now there are some people who don't check it all, but we can't support them if they don't check whether a link even works in the first place. We should focus on the many people who know to check a link, but are not aware they are linking to a redirect. If we can guide them to link to the correct article in the first place, than we accomplished helping our readers.

Now for the second category of redirects, I read some interesting ideas on how to track and deal with questionable redirects, and I would like to propose the following measurements:

We can measure the amount of page visits over a certain period. As far as I'm aware, you can even tell how many of those came from an external site. Now if see that over a period, let's say two months, nobody has used that redirect, than we can safely assume that the redirect is not in use externally.
If a redirect is suspected to be linked to in text documentation (Like Wrye Bash), it should stay. I believe this is only applicable to mods.

I'm aware this proposal is not complete, but hopefully it will give us something to start with. --Timenn < talk > 03:52, 24 September 2008 (EDT)

I think it's time I spoke again in this discussion, as my views have been swayed in various directions after reading what's been said here and I'd like to clarify things for everyone.

This discussion has been blown entirely out of proportion. It started off by Wrye saying that in a few cases, mainly in Tes4Mod, redirects should not be deleted. Somehow this has transfored into a huge debate about the general existence of redirects.

I am 99.9% certain that no one here thinks of redirects as a bad thing. They are one of the most important parts of any wiki, UESP included. There are, however, some cases where redirects simply are unnecessary. Quite a few people here have asked the question, "Why not keep the redirects? They aren't doing any harm." Of course they aren't, some are even very helpful. In all honesty when I proposed these redirects for deletion I came across a huge number of redirects which I knew shouldn't be deleted. The ones I added "Prod" tags to, where the ones that I thought were unnecessary at the time. Since then I have discovered that many of the redirects do indeed have uses and should be kept.

I strongly support Timenn's solution to the problem of knowing when a redirect can be deleted; when it hasn't been used for two months.

For Wrye's mod links, I think that the same is applicable, but only if Wrye updates the links so that they now link past the redirect. I know that Nephele has already said that Wrye shouldn't have to do anything of the sort. But I think that if he can, then he definately should. In no way can we, or should we, force him to. Instead we should ask him in a civilised manner whether he would be able to update the links on his help files. As a member of UESP, I'm sure he would be happy to help the site, which he will be doing if he updates the links.

If we can solve the issues I talked about above, then as far as I can see, the discussion of those redirects is over, meaning that we can now turn to the other problems which have been brought to light. To summarize:

Categorization of redirects.
Treatment of newly created redirects.

These should not, however, be discussed under this title. They are a seperate issue, and deserve a seperate section. - Game Lord^{Talk|Contribs} 09:34, 24 September 2008 (EDT)

Wrye 5: Redirect Page Count is not Useful:

In my previous post I said that it would be okay to delete redirect pages where the page count is below 20. However, this was under the assumption that each time you access a redirect page, it increases the page count for the redirect page. Since I was surprised by the low page counts on the redirect pages I was checking, I just tested, and... It doesn't work that way. Here's what happens:

When you move the page, it seems that the page in entirety (along with page count statistics) is moved to the new location, and then a completely new page with the old name is created and set to redirect to the moved page. This newly created page (with the old name) will have a page count of zero.
If you then load the old title (resulting a redirect to the moved page), the page count of the old page is not incremented. However, the page count of the moved page is incrementened.
The only way to increment the page count of the redirecting page is to load it with "noredirect" argument (e.g. to use the backlink from the moved page).

In other words, the page count on the redirect page is essentially useless for determining usage -- it could be extremely heavily used and stay at zero. :shrug:

Re this: I've read all the comments, and it seems to me that in the end everyone agrees, Wrye in his latest post, that there are at least some redirects that should be deleted. No. You'll note that I said in my last post: (While I personally would rather have even the < 20 count pages left (given the effectively zero cost), I'll grant that their removal is pretty unlikely to break any links.) I.e. I think that the best solution is too simply leave the redirects in place. I was only okay with deleting the page counts < 20 under the assumption that the low counts indicate that redirect is not being used -- but as the tests indicate, this is not the case. And as I've demonstrated at the very beginning of this discussion, google's back link service is not reliable. Hence there seems to be no way of determining whether a given redirect is actually being used or not. (Perhaps the info could be extracted from the wiki software -- I don't know.) And again, the cost of the redirect is negligible.

Another note. On another site of mine I have fifteen year old docs of a few old games (primitive RPGs for Genesis). Believe it or not, I still get emails about these occasionally. Along the same lines, several folks are now actively (yes, with releases) working on a project to fix the long standing bugs in the Morrowind game engine. Not the data file -- the actual engine! And an old doc of mine on this site surprisingly turned out to be useful for this. In other words, my own experience is clear that the utility of old information does not go to zero. It gets small -- but people still poke around this stuff. In other words, if you assume that people will quit using information or a given link after a while -- then there's a good chance that you're wrong.

Again, I'm going to limit myself to Tes3Mod and Tes4Mod parts of the site, and will recheck redirects (given that the page count test is not useful), but the only basis for checking now seems to be a guesstimate that the redirect isn't used. And as I've argue before, that's hard to guesstimate -- there's always a good chance that someone linked to the page almost immediately on creation.

I'll let other folks worry about other parts of the site, but for the modding namespaces, I would strongly suggest that you simply leave redirects in place. The cost of reviewing such links and trying to figure out whether they're in use or not far outweighs any miniscule gains that might be derived from deleting it. Again, I'll do a second review now. --Wrye 01:44, 25 September 2008 (EDT)

Okay, done with review. I've unprodded some pages, but in the interest of peace left some others which I thought were either reasonably likely to be unlinked, or for which the users would almost certainly be able to find their way to the correct page on the their own. But again, IMO, this sort of analysis is not worth the effort. Much simpler to just leave the redirect in place. If no one ever uses it, then there's no cost. But if a link is in use and is removed, you break that link. In other words, deletion is all cost, no gain. Simpler to just leave it be. --Wrye 02:12, 25 September 2008 (EDT)

Interesting and valuable research - thanks. Can I ask one favor for when you go through unprodding? Add a category to any redirects that don't already have one (say, Redirects from Alternate Names - or maybe create a new one called something like Redirects from Former Organizational Structure?). I know it's going to be a pain but if people can find out easily why redirects are present, this sort of thing is less likely to happen. –Rpeh^{•T•C•E•} 03:23, 25 September 2008 (EDT)

Even in the case that there is no way of measuring redirect usage, it doesn't mean we need to prohibit deleting any redirect. I believe the redirects from the first category I mentioned earlier can always safely be deleted.

There are more ways to measure the page visits than what's stated beneath the page. I can imagine it doesn't update because the wiki software covers that instead. The url requested, when asking for a redirect page, doesn't change, no forwarding. So the site statistics should reveal the actual page requests for that url. Now if we can sift out those requests that came from another site, we have our way of measuring redirect usage. --Timenn < talk > 10:53, 26 September 2008 (EDT)

Rpeh. Hmmm... The problem is that it if you establish a policy of adding signs (category labels) that indicated that a given redirect should not be deleted, then that strongly suggests that redirects without such labels are okay to delete. Which would be (usually or at least oftentimes) incorrect.

I did check on the possibility of doing this, but thinking over it, I think that in the end it would not be good policy since it would tend to lead to incorrect redirect deletions. --Wrye 22:32, 26 September 2008 (EDT)

Okay, let's talk numbers here. According to List redirects, we have a total of 14550 redrirects on the site. (Change it to 500, then increase the number in the URL line in your browser to display more at a time if you don't want to take forever getting to the end of that list.) The majority of those (8235 by my count) are in Redirects to Broader Subjects. Another large group (1279) are in Redirects from Alternate Names. Add in the handful of redirects in the less-used categories, and you get a grand total of 9584, leaving just under 5000 redirects presumably uncategorized. I think it would be a fairly simple job for a bot to generate a list of these redirects, such that we could go through and add categories as necessary. (Heck, if there's large numbers of redirects resulting from a single event, we could even get the bot to do the category adding. I suspect this is probably the case, as there's probably a very large chunk of that caused by the Tamriel->Lore move alone, among other such things.) After the easy chunks are taken care of, I doubt there will really be that many uncategorized redirects remaining, and they can be dealt with on a case-by-case basis, I'd say with a bias towards keeping anything that's potentially useful. (There's probably a bunch that can be safely deleted, leftovers from misspelled/redundant page names and such.) Then in the future, we just try to make a habit of adding categories whenever creating a redirect. (Would it be possible to add code such that all redirects caused by page moves would have a category added to them automatically? Say "Redirects from Page Moves" or something like that? That'd make things a lot easier in the long run.) Seems like a reasonable compromise to me. --TheRealLurlock ^Talk 00:00, 27 September 2008 (EDT)

Ahhh... I didn't know that such categories already existed and were in use. If the barn door is already open, then my argument fails. I think that "Redirects from Page Moves" will work. --Wrye 00:34, 27 September 2008 (EDT)

Okay, done for pages that I'm aware of in tes3/4mod spaces (Category:Redirects_from_Moves. I've left uncategorized my previous "probably okay to delete" pages. --Wrye 00:59, 27 September 2008 (EDT)

UESPWiki β