Page MenuHomePhabricator

Display links to redirects that link to non-existent pages in red
Open, LowestPublicFeature

Description

Author: xmlizer

Description:
Sometime it is easyer to have information about the different way to call an
idea or a person than to have enough information to create an article, so you
may want to create the redirects to that "future" article.

Another time, when an article has been created, some people add a lot of
redirects, and if this article happen to be deleted, some redirects could stay
and link nowhere

A way to let contributers create redirect without masking the fact that the
article don't/no more exists, could be to give to a redirect the final status of
the last redirect chain

So in A -> B(r) -> C(r) -> D, the link in A to B should be a "blue" link because
even if there is multiple redirects (which is very ugly), the last in the chain
(D) exists

And in X -> Y(r) -> Z(r) -> {T}, the link in X to Y should be a red link because
the last {T} doesn't exists


Version: 1.23.0
Severity: enhancement

Details

Reference
bz378

Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:55 PM
bzimport set Reference to bz378.
bzimport added a subscriber: Unknown Object (MLST).

elian wrote:

This problem is better solved by human intelligence (in german wikipedia there's
the rule that redirects to non-existing articles shouldn't exist, I think in
other projects there may be similar rules).

rowan.collins wrote:

I wouldn't be so hasty at closing this request: there are some decent arguments
for allowing "speculative redirects" to pages that don't yet exist. A good
discussion of this already exists on the old SourceForge RFE tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=594421&group_id=34373&atid=411195

However, the example in comment #0 also assumes another feature that doesn't
exist: handling of redirects to other redirects. This is deliberately avoided to
keep things from becoming "spaghettified".

I'm going to reopen for now, with a better summary.

timwi wrote:

The summary was ambiguous; we already allow redirects to non-existent pages.
Here's my suggestion for a summary.

rowan.collins wrote:

(In reply to comment #3)

The summary was ambiguous; we already allow redirects to non-existent pages.
Here's my suggestion for a summary.

Well, it's a moot point whether we "allow" them; they are currently treated as
normal pages, with no special handling. But I see your point.

wmahan_04 wrote:

To do this, we'd need to check every link to see if it is a redirect
(right now, this happens for users with a stub length threshold
set), and check whether the targets of the redirects exist. I
don't think it's worth it, especially without a clear consensus
for the change.

  • Bug 1756 has been marked as a duplicate of this bug. ***

hardy wrote:

Some of the reasons why PRE-EMPTIVE REDIRECTS ARE IMPORTANT:

It is important to abolish what some have treated as a policy
requiring deletion of redirects whose targets do not exist, which
they have called "broken" redirects. Such pre-emptive redirects
are valuable and important for a variety of related reasons:

  • [[complex societies]] redirects to [[complex society]]. The latter

is the appropriate title. This pre-emptive redirect avoids a future
situation in which two separate articles exist that should be merged,
their authors being unable to cooperate because neither suspects the
other's existence.

  • [[Eastern Sudanic]] redirects to [[Eastern Sudanic langauages]].

The latter title is appropriate as the article title (WITH the plural;
this is an exception to the rule that article titles should be singular
for the same reason that applies to [[Germanic languages]], [[Romance
languages]], [[Slavic languages]], etc.). The term "Eastern Sudanic"
is a standard and appropriate abbreviation in the contexts in which it
often appears, but the article title should not be abbreviated. Again,
this is a valuable pre-emptive redirect because it avoids a future
situation in which two separate articles exist that should be merged,
their authors being unable to cooperate because neither suspects the
other's existence.

  • A misnomer redirects to a correct term. In some cases, this is a valuable

pre-emptive redirect for the same reason. In some other cases, a misnomer may
be a better tite; such a decision requires understanding of the subject and
should be discussed before any proposed deletion is done. In many cases, this
is a valuable pre-emptive redirect because it avoids a future situation in which
two separate articles exist that should be merged, their authors being unable to
cooperate because neither suspects the other's existence.

plugwash wrote:

mmm though if you are going to the trouble of putting a redirect in you may as
well create a stub while you are at it anyway...

hardy wrote:

if you are going to the trouble of putting a redirect
in you may as well create a stub while you are at it anyway...

That often cannot be done, obviously. I know enough to know
that ''Eastern Sudanic'' should redirect to ''Eastern Sudanic
languages'', but I cannot write even a stub on that topic.
A person who knows (from having read a variety of instances)
that ''coupled harmonic oscillator'' is not one of those terms
that are always plural, and could therefore pre-emptively
redirect the plural to the singular, may not know whether the
topic is physics or music or New-Age philosophy, and so could
not possibly write that stub. ~~~~

hardy wrote:

Another thing to consider:

Even if one takes the wrong-headed view that there should be no
pre-emptive redirects, the fact that they will inevitably occur
anyway makes it useful to regard this bug as a bug. If links to
redirect pages whose targets don't exist appear red rather than
green, then people seeing those links will know that they can
write a new article, and that they should not expect to become
informed on the topic by clicking on the link.

hardy wrote:

I've now noticed that both my critics and I were mistaken about what
the long-standing policy actually says.''' What confused us was that
the emphasis in the statement of the policy was misleading. Read the
paragraph starting with "However" after item #6 at
[[Wikipedia:Redirects for deletion]]. In view of the list of exceptions
in the paragraph beginning with "However...", I've revised item 6 at
[[Wikipedia:Redirects for deletion]] in a way that is really just a
changed in emphasis and I hope will avoid some rash deletions-without-
due-deliberation. It now reads as follows:

:#6. If the redirect points to an article that does not exist and does
not help avoid the accidental creation of
[[Wikipedia:Duplicate articles|duplicate articles]], it can be
[[wikipedia:candidates for speedy deletion|deleted immediately]];
'''but first''' you should check whether there is an alternative place
it could be appropriately redirected, and whether any of the exceptions
noted below are applicable.

gangleri wrote:

regarding police on "redirects that link to non-existent pages"

There are wiki's who use these:

see [[lb:User talk:Gangleri#Redirect to nonexisting]]

Regards Reinhardt [[user:gangleri]]

jeroenvrp wrote:

I strongly support the idea to have 'red links' for pages with a redirect
to non-existing pages. It will avoid duplicate entries in the future and
will also solve the problem with left-overs in the form of a redirect,
after a page had been deleted.

I do like the "write a quick stub" idea. Better than having the db recursively query a bunch of crap.

hardy wrote:

Within the last couple of days I created a redirect to the non-existent page [[Kervaire–Milnor formula]]. Contrary to what Aaron Schulz and others suggest, I could not reasonably have created a stub.

In the interests of morality we must remember that the present apparent policy forbidding pre-emptive redirects was not created by proper discussion and consensus, but by person who avoided the usual discussion pages and denied the existence of people who disagreed with them.

It is clear that despite the injustice of the situation, we cannot have any policy discussion aimed at abolishing the prohibition against pre-emptive redirects until this bug is fixed.

Keeping this bug unrepaired and closing this ticket are abusive ways of preventing that policy discussion from happening.

In recent hours I have written to Brion Vibber about this.

hardy wrote:

Brion Vibber has replied that he will look at this.

brion, did you look at this in the last 3 years? :)

There were two parallel discussions here. One was about (en.wiki?) policies. The other one was about software performance.

Since this is a request for MediaWiki Core, the discussion about policies is secondary, and what really matters is this:

(In reply to Wil Mahan from comment #5)

To do this, we'd need to check every link to see if it is a redirect
(right now, this happens for users with a stub length threshold
set), and check whether the targets of the redirects exist. I
don't think it's worth it, especially without a clear consensus
for the change.

(In reply to Aaron Schulz from comment #14)

I do like the "write a quick stub" idea. Better than having the db
recursively query a bunch of crap.

In other words, an expensive price for what seems to be a minor feature.

This report was WONTFIXED almost a decade ago, and it was reopened because it was considered that the policy should be discussed. Looking only at the software side, this looks indeed like a WONTFIX in 2014.

There are 3 separate issues here:

(In reply to xmlizer from comment #0)

And in X -> Y(r) -> Z(r) -> {T}, the link in X to Y should be a red link
because the last {T} doesn't exists

  1. Double redirects. We don't do these at all, and processes exist to automatically fix them. See:

https://en.wikipedia.org/wiki/Wikipedia:Double_redirects
https://en.wikipedia.org/wiki/Special:DoubleRedirects
[Definite WONTFIX. But not seriously considered except in Comment #0.]

  1. Whether we're *allowed* to create/keep Redirects to non-existent targets. At the surface this is guideline/policy issue. However, one major aspect preventing their acceptance is the confusion that would arise if one of these Redirects was linked within an article. It would look blue, but lead nowhere. Hence:
  1. Whether links to Redirects to currently-non-existent targets can technically be colored red.

I.e. X -> Y(r) -> {T}, where {T} doesn't exist, the link in X to Y could be a red link.
This would be quite useful, as Michael Hardy explains best in Comment #7.
They're currently (on Enwiki) speedily-deleted per [[WP:CSD#G8]] (criteria for speedy deletion - General issue #8), specifically: "redirects to invalid targets, such as non-existent targets".

So, the question is:

  • MediaWiki: Is there another (cheaper) method of checking if a redirect targets an existing page?

E.g. Could editors add a template to the redirect, specifying that it's a {pre-emptive redirect}, and thus incoming links should be marked red (until that template is removed)?
Or something else?

A template to style the link, added by the editors manually. Interesting. This might be the way to go.

In any case this would be a WONTFIX from a MediaWiki Core point of view.

Why would this feature be WONTFIX from a core point of view?

We're already doing DB test to see if a page exists. And redirect information is already stored relatively cheaply in the database. What is stopping us from having a simple option that traverses one level of redirects when doing page existence checks?

I was just trying to interpret the opinions of Wil and Aaron posted years ago. I'm happy to be proven wrong.

Is this an EASY report, after all?

It requires a bit of knowledge of our database schema plus it requires looking through our sanity sapping parser, so I wouldn't consider it "easy".
But it should be reasonably implementable.

At the very least I don't see any reason that implementing it would add a notable burden to the database.

It's possible to simply modify the code to use the same color as the links to nonexistent pages after first doing a few conditional checks, but why bother?

I think we should have broader consensus among the other wikis as well, rather than just enwiki's approval, to go ahead with this change. Some wikis like having broken redirects as blue links, so they know they exist and can fix them from Special:BrokenRedirects. Some were originally redirects to pages moved with suppressredirect, so going back through to fix them requires human intervention, not computer logic. And if it's red and someone decides to stub out the article content, we have article duplication.

Alternatively, this could perhaps be done locally via Common.css or Lua modules.

Off-topic sidenote:
(In reply to Quiddity from comment #19)

  1. Double redirects. We don't do these at all, and processes exist to

automatically fix them. See:

I just discovered a current proposal to alter this:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28idea_lab%29#Allow_some_double_redirects
based on discussion at
https://en.wikipedia.org/wiki/Wikipedia_talk:Double_redirects#Some_double_redirects_are_good_or_MDRAG_Redux

epriestley added a commit: Unknown Object (Diffusion Commit).Mar 4 2015, 8:20 AM

Accidental clash. Known issue. Sorry for the noise.

Luke081515 subscribed.

Declined per T124354. There is no consensus for this change yet. Please reopen the task if consensus reached.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:02 AM