Don't delete redirects

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search
Crystal wordprocessing.png This is an essay. It expresses the opinions and ideas of some Wikimedians but may not have wide support. This is not policy on Meta, but it may be a policy or guideline on other Wikimedia projects. Feel free to update this page as needed, or use the discussion page to propose major changes.
Languages: English  · português

Don't delete redirects. Just don't. If you really want to, please read why you shouldn't.

This essay is inspired by "Nooit redirects verwijderen" written by Jelte at the Dutch Wikipedia. It was written with Wikipedia in mind, but may be applicable to other MediaWiki sites as well.

Why?[edit]

  1. One can never know if a redirect is still used.
    • External parties could still link to that redirect (books, blogs, articles, archives, forums, flickr, emails etc.)
    • The redirects could be used in edit summaries or log action summaries (both on the local wiki and on other wikis).
    • Search suggestions include redirects. The creation of duplicate articles can be (partially) prevented if a alternative title(s) exists as a redirect. The fact that the redirect was created, or if the article was renamed is itself proof that one or more persons were looking for the article under that name.
    • The redirects could've been bookmarked in people's browsers, shared through social networks, or included in link lists.
    • (Templates) The redirect could be commonly used with subst: and thus does not show up as "usage" of the template.
    • The redirects could still be used in older versions of pages (especially important for templates).
  2. There is little to no technical gain in terms of speed or disk space.
    • Deleting a redirect results in it being archived (not "deleted"), everything can, and sometimes will, be "restored".
    • See also Don't worry about performance.
  3. The (few) maintenance tasks that emerge by having redirects are mostly taken care of by bots.
  4. Redirects from spelling mistakes prove their usefulness with their own existence: at least somebody has made that mistake in the past.
  5. Redirects prevent duplicate articles from being created. See Law of Ellywa (Dutch).
  6. Cool URIs don't change.
  7. For files:
    1. Usage outside public Wikimedia Foundation wikis. Though pages that embed files on public wikis by the Wikimedia Foundation can be tracked via Special:GlobalUsage, the following cannot be tracked:
      • usage on private wikis (officewiki, internalwiki, otrswiki etc.),
      • usage on third-party wikis (through InstantCommons),
      • hotlinks from other websites (e.g. blog.wikimedia.org) One could argue in case of non-wikis, the site should host a copy of the file. Especially because the image will still break if a redirect is kept since the redirect only applies to the MediaWiki API, the direct HTTP url will still become 404 (bug 35721).
    2. For duplicate files:
      • Files maybe don't have any local or global usage, nor local links to it. But just like the points above, there can be links from anywhere (talk pages, bugzilla reports, bookmarks etc.). When someone visits a link to a file that was deleted on Commons from a local wiki, there will be no log message or any knowledge at the local wiki that this file once existed on Commons. There's a technical story behind that, but the point is that it is the way it is. Please always leave redirects otherwise there is no way (not even an ugly way) for users on other wikis to find the file under the name!
      • Also, when you delete a file locally because it has a duplicate on Commons but other a different title, you should a create a redirect from the old title to the new one on Commons (or it won't work).
    3. For other files: because Brion will desysop you, «it's extremely user-hostile and makes the project less useful».

Exceptions[edit]

In some of the following cases a redirect could however be deleted:

  1. If the redirect is broken, such as:
  2. If the redirect is wrong or misleading (eg. Site to Milk).
  3. If the redirect's target is in another namespace, mostly the case when redirecting from the main namespace to the File:- or Category:- namespace.
  4. If the redirect is created from a vandalistic point of view (eg. John is a moron to John).