Wikipedia:Redirects for discussion/Common outcomes

This page summarizes the typical outcomes of past RfD discussions for some commonly nominated types of redirects. This page is not a policy or guideline, and previous outcomes do not bind future ones because consensus can change. All redirects should be evaluated individually on their merits and their usefulness to readers. As guidelines and actual practice change, this page should be updated to reflect current outcomes.

Don't rely too much on these "common outcomes" when stating a case at Redirects for Discussion. Precedent can be useful to help resolve these debates, but editors are not bound to follow past practice. Furthermore, for most examples on this page, counter-examples exist. This page describes some past practices; it does not prescribe mandates for the future.

This page simply attempts to summarize Wikipedia's common daily practice in redirect debates. If you feel that a common outcome for the type of redirect you are discussing does not apply, then give a common-sense reason, or another guideline, for why it shouldn't apply.

One of the purposes of a redirect covers "likely alternative capitalizations." While Wikipedia's search function is generally case-insensitive, these redirects aid linking from other articles and external sites. When there is a connection between the subject and an alternative capitalization, it is usually kept. However, if the capitalization difference is implausible, unnatural, or novel, it may be considered unhelpful and be deleted.

The major exception is with CamelCase. If the redirect was created back when UseModWiki required CamelCase, it is considered a {{R from old history}} and almost always kept.

Another thing to keep in mind is WP:DIFFCAPS. Sometimes, a capitalization may have a distinct meaning. This is especially true for acronyms, which may have a different target from the normal capitalization.

Redirects from one namespace to another have historically been controversial. Arguments for and against them are available in the essay linked above. Especially at RfD, the tendency has been to delete cross-namespace redirects (CNRs) which were recently created, although what qualifies as "recent" may have to be decided through discussion. Long-standing CNRs, or those that are frequently used, are more likely to be kept. Some CNRs may be speedily deleted under criterion R2: see section #From userspace for more information.

If the redirect has a title that suggests an article, whether it is kept often depends on whether the target is intended for readers or editors. Portals are intended for readers, for example, so redirects from article (main) namespace to portal namespace are often kept. Conversely, a redirect from article namespace to a template or Wikipedia page is usually deleted.

Treatment of pseudo-namespace redirects (PNRs) is not as straightforward. A redirect from "P:Foo" to "Portal:Foo" is technically cross-namespace, so some editors believe a PNR should be treated like any other CNR. But because some PNRs are widely accepted, others feel PNRs need to be weighed individually.

Redirects exist for most single emoji characters. When there is an article on an emoji itself (e.g. Face with Tears of Joy emoji), the emoji should redirect there. As of December 2023, there is no consensus as to best practices for other emoji redirects, but emojis with a clear and definite meaning are usually redirected to corresponding articles, and other emojis are usually redirected to pages that disambiguate them, or, if not possible, redirected to lists of symbols such as Miscellaneous Symbols and Pictographs; soft redirection to Wiktionary may also be appropriate. Occasionally, if there is no agreeable target, the redirect may be deleted.

Editors should be aware that emojis are often rendered differently on different systems. Titles that contain multiple emojis or mix emojis and other characters are usually deleted.

Examples

As the above essay states, "Redirects from other languages should generally be avoided unless a well-grounded rationale can be provided for their inclusion." This means redirects in languages other than English are usually deleted. The major exception is for redirects where the language of the redirect relates strongly to the content of the target, such as endonyms and the titles of creative works originally published in another language. It may also be appropriate to keep such redirects if their use is discussed at their target page.

Examples

Redirects from User namespace are a type of cross-namespace redirect. To some extent, the practice of deleting cross-namespace redirects conflicts with the practice of offering "fairly wide latitude" for what can go in a user's own userspace. A redirect from a user page to an article is automatically created if a user makes a draft on their own user page before publishing it, for example. At RfD, these redirects are often deleted or converted into soft redirects to avoid reader confusion. An editor who specifically wants their user page to redirect to an article might be allowed to do so; this does not occur frequently.

The practice of redirecting a user page to the user's own talk page is not uncommon. User talk pages themselves should always primarily be a way of contacting that user. So while a user talk page may redirect to a current page from an old username, or to another Wikipedia where the user is primarily active, user talk pages should never redirect to another namespace.

Examples

Redirects containing a mixture of Latin and non-Latin characters are often implausible search terms because characters from different scripts generally never appear on the same keyboard. A common example is the substitution of a Latin letter with an identical-looking non-Latin letter (e.g. Greek capital alpha ⟨Α⟩ for Latin ⟨A⟩), which also amounts to an implausible typo (see below).

Most types of mixed-script redirects (e.g. titles with both Cyrillic and Greek letters) are forbidden by the title blacklist. Note that mixed-script redirects are generally acceptable for names and terminology containing Greek letters. For example, Η Carinae (beginning with Greek capital eta ⟨Η⟩) is an acceptable redirect to Eta Carinae.

Examples

In some cases, there's broad consensus against an existing redirect, but editors disagree as to whether it should be deleted, retargeted, or another action taken. Although an outcome of no consensus usually means no change to the status quo, this can be nonsensical when there is broad consensus that some sort of change should occur. Because we are encouraged to seek alternatives to deletion, it may be appropriate to retarget a redirect in these circumstances, even absent explicit consensus for the retarget.

Though this results in a final outcome of retarget, it is still useful to record the close as "no consensus, retarget", just as we would say "no consensus" rather than "keep" in a typical no-consensus close with no change to the status quo.

In some cases, such as when editors are suggesting multiple retargeting options, it may be best to close the discussion as "no consensus, disambiguate" with the disambiguation page listing the various options as applicable. Other times, it may still be appropriate to give a simple no-consensus close. This is especially true when there is no scope for disambiguating and/or there is some appetite for the status quo.

Examples

• Formation (album) (discussion)
• Redirects pointing to List of Gaon Digital Chart number ones of 2019 (discussion)
• Developed (discussion)

The default outcome of any request for change which receives no other discussion is to approve the request. Thus, a redirect nominated for deletion in good faith and in accordance with RfD policy will always be deleted if the nomination is unopposed, even if no one else participated in the discussion. Compare to the proposed deletion process, in which even a mainspace article can be deleted without objection after a week.

An administrator may consider such a close a soft deletion, and be more willing to restore the redirect on request. Best practice is still to contact the closer first.

Examples

Related template: {{R from non-neutral name}}

While a neutral point of view is one of Wikipedia's Five Pillars, redirects are meant to help readers, who may use non-neutral terms in searches. Non-neutral redirects may still be deleted if they appear to be pushing a specific point of view. Especially if they are terms in common usage, however, they may be kept.

Examples

Related template: {{R from misspelling}}

Redirects from plausible typographical errors are usually kept, except in template space, where consensus is that typos in template names should be corrected. These can include spelling errors, and extra or missing punctuation. However, if a single redirect contains multiple typos, it may be considered an unlikely search term and deleted. Recently created redirects from typo may be subject to speedy deletion under criterion R3 if they are considered implausible.

Examples

Related template: {{R with possibilities}}

One common type of redirect is from a subject which could be expanded to its own article in the future. The template {{R with possibilities}} exists to tag such redirects. However, Wikipedia:Redirect/Deletion reasons #10 says such redirects should be deleted if "the target article contains virtually no information on the subject." (In RfD parlance, "Delete per WP:REDLINK" refers to the latter.) While distinguishing between constructive and misleading redirects of this type can be quite simple, other cases may be more nuanced.

Examples

Redirects in the form "X and/or Y" that could equally point to multiple targets are commonly deleted, as there is no way to determine which topic a reader is searching for. In these cases, search results may be more helpful, allowing the reader to make the decision. It may be possible, however, for such redirects to point to a location in which both topics are discussed. In some cases a disambiguation page is a suitable replacement.

Examples

• Wikipedia:Redirects are cheap
• Wikipedia:Redirects are costly