Don't delete redirects

From Meta, a Wikimedia project coordination wiki
(Redirected from DDR)
(English) 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.
Translate
Other languages:
Shortcut:
DDR

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 wikis 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).
    • (Wiki pages) Search suggestions include redirects. The creation of duplicate articles can be (partially) prevented if (an) alternative title(s) exists as a redirect. The fact that the redirect was created or that the article used to have a different name is itself a proof that one or more persons were looking for the article under the name from the redirect.
    • 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 one person has already made that mistake.
  5. Cool URIs don't change.
  6. 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 that 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 return 404 (T37721).
    2. For duplicate files:
      • Files may not have any local or global usage, nor local links to it. But just like in the points above, there can be links from anywhere (talk pages, Phabricator tasks, 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's 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 under a different title, you should create a redirect from the old title to the new one on Commons (or it won't work).
    3. For other files on Commons: 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, after all, be deleted:

  1. If the redirect is broken, e.g.:
  2. If the redirect is wrong or misleading (e.g. "Penguins" to "Christmas").
  3. If the redirect's target is in another namespace (mostly when linking from the main namespace to the File:- or Project:- namespace).
  4. If the redirect is a case of vandalism (e.g. "John is bad" to "John").