Last modified: 2014-11-09 13:18:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2402 - Multiple redirects do not work
Multiple redirects do not work
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
unspecified
All All
: Lowest normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-13 15:32 UTC by M. Creidieki Crouch
Modified: 2014-11-09 13:18 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description M. Creidieki Crouch 2005-06-13 15:32:26 UTC
Mediawiki doesn't allow multiple redirects, even when they are appropriate and
reasonable.  For example, on the English wikipedia, there is no page on the
[[Hydrogen bomb]]; it redirects to [[Nuclear weapon]].  The plural [[Hydrogen
bombs]] should redirect to the singular [[Hydrogen bomb]]; however, due to
technical limitations, it must *also* be a redirect to [[Nuclear weapon]]!

Redirects exist for multiple reasons; sometimes there is not yet an article on
the given topic (i.e., "hydrogen bomb"), and sometimes they exist because of
grammatical or spelling variants (the plural form).  If multiple conditions
exist, there may be valid reasons for a string of several redirects.  By forcing
writers to use semantically incorrect redirects ("hydrogen bombs" -> "nuclear
weapon"), we make things much more complicated whenever an article on the
singular form, "hydrogen bomb", is added.  Furthermore, the Wikipedia contains
the fundamentally incorrect information that the "hydrogen bombs" article is
related to the "nuclear weapon" article instead of the "hydrogen bomb" article.

I think that a system more subtle than "don't allow double redirects" should be
used to detect self-loops, so that we aren't forced to work around valid redirects.
Comment 1 Rowan Collins [IMSoP] 2005-07-30 01:34:06 UTC
One response to your example is that "hydrogen bomb" shouldn't have been a
redirect in the first place - if there is a possibility for an article to exist
there, it should be left as non-existent, or a stub. However, that view isn't
universally agreed, I know, but it does solve that particular problem.

Besides loops, another problem with enabling double redirects is that it would
lead to laziness: when a page is moved, all redirects pointing to it *should* be
updated, but if they carried on working, they might well not be fixed. By your
own argument, the new location is the semantically related one, not the old
abandoned title, and if some of the intermediate redirects were to be changed or
deleted, the whole "chain" would need restructuring.

Also, it's just occurred to me - how would the interface present such a
redirect? "Redirected from [[Hydrogen bombs]] via [[Hydrogen bomb]]"? Could get
kinda confusing... 

On balance, I still think only having one level of redirection is the best way
to go.
Comment 2 David Benbennick 2005-08-31 17:17:22 UTC
(In reply to comment #1)
> another problem with enabling double redirects is that it would lead to 
laziness: when a page is moved, all redirects pointing to it *should* be 
updated

Why?  If the redirects continue to work, what is the problem with leaving 
them alone?  Alternatively, if they all *should* be updated, then the 
software should offer to do it, instead of forcing users to laboriously do 
it by hand.  Software should support laziness; human effort is expensive.
  
> Also, it's just occurred to me - how would the interface present such a 
redirect?

There are of course many possibilities, any of which would be sufficient.  
I would suggest that if A redirects to B redirects to C, and user goes to 
page A, the message should be simply "Redirected from A".
Comment 3 Rowan Collins [IMSoP] 2005-08-31 20:16:23 UTC
(In reply to comment #2)
>> when a page is moved, all redirects pointing to it *should* be updated 
> Why?  If the redirects continue to work, what is the problem with leaving 
> them alone?

Well, as I said, in the context of making redirects "semantically correct" (the
submitter's reason for allowing multiple redirects), a redirect to an article
which has been renamed is more than likely related to the article at its new
title, not specifically to the abandoned one. For instance, if [[nuclear
weapon]] were moved to [[atomic weapon]], it would not be "semantically correct"
to have other pages redirecting to the new redirect at [[nuclear weapon]].

>  Alternatively, if they all *should* be updated, then the 
> software should offer to do it, instead of forcing users to laboriously do 
> it by hand.  Software should support laziness; human effort is expensive.

This I would certainly support - retaining the manual choice, but offering an
automated tool listing all double redirects and allowing you to tick/untick
boxes for each one which should redirect to the final target instead (allowing
you to leave any which should link to a new article you're about to replace the
redirect with, for instance). This IMHO is a tidier kind of laziness-aid than
allowing spaghettis of redirects to form.

> > Also, it's just occurred to me - how would the interface present such a 
> > redirect?
> 
> There are of course many possibilities, any of which would be sufficient.  
> I would suggest that if A redirects to B redirects to C, and user goes to 
> page A, the message should be simply "Redirected from A".

Newbie: "I went to page A, and it displayed C instead; I saw the message saying
"redirected from", and followed the link there, and it referred to article B.
Which article to I have to edit to make A do something else?" People get
confused enough about *single* redirects, without having to manually trace
through intermediate steps to see why the redirection even happened. So,
personally, I don't think such a message *would* be sufficient.

Another interface issue would arise from having explicit loop catching: given a
redirect chain like A->B->C->B, a user visiting A would need to be informed that
"You visited A, which redirects to a loop of redirects involving B and C" in
order to have a chance of rectifying the situation. And then consider
A->B->C->D->B or A->B->C->D->E->C - you'd have to generate some kind of diagram
just to tell people what the chain consisted of. Obviously, that's not
impossible, but it's really not what redirects are *for* - they're simple
aliases there for convenience. 

Some people - including Lee Crocker, who wrote much of the original code of what
is now MediaWiki, as well as policy on how to use it - think we're already using
redirects too often, where it would be better to use stubs that explain the
relationship properly. In his view "There's absolutely nothing wrong with
one-sentence articles."
[http://mail.wikimedia.org/pipermail/wikitech-l/2005-May/029158.html]
Comment 4 anminh2008 2011-07-31 08:51:32 UTC
There is a solution to this problem: You can let the server to "log" every redirect that it was. If the next destination is a duplicate of one already in the log, then stop.
Comment 5 anminh2008 2011-08-02 01:45:18 UTC
When A redirects to B and B redirects to C, it would display as foollowing:
A → B → C
In general, redirect links are separated with arrows (→).
Comment 6 Krinkle 2011-08-04 05:32:30 UTC
The functionality to have multi-level redirects has been in MediaWiki for a long time now:

http://www.mediawiki.org/wiki/Manual:$wgMaxRedirects

Wikipedia however has chosen to set it to 1.
Comment 7 Antoine "hashar" Musso (WMF) 2012-03-03 19:51:45 UTC
Reclosing the issue as wontfix.
Comment 8 MZMcBride 2012-03-03 20:09:12 UTC
(In reply to comment #7)
> Reclosing the issue as wontfix.

Why?
Comment 9 Antoine "hashar" Musso (WMF) 2012-03-03 20:15:07 UTC
Because that bug was originally open for Wikipedia and we choose to limit it to 1 redirect. So it works as intended.
Comment 10 MZMcBride 2012-03-03 20:16:38 UTC
(In reply to comment #9)
> Because that bug was originally open for Wikipedia and we choose to limit it to
> 1 redirect. So it works as intended.

Did you read the opening comments? There is a usability problem here when pages are moved. It currently requires a large amount of manual intervention or the use of outside scripts to make moves efficient. This seems less-than-ideal. $wgMaxRedirects is one possible solution, but given that it hasn't been implemented fully, that doesn't make the problem any less real. Re-opening for now.
Comment 11 MZMcBride 2012-03-03 20:19:26 UTC
One possible idea it to provide checkboxes on the "page moved successfully" page. Something like this...

"Foo bar" has been to moved to "Metasyntactic variable". Would you like to update the following redirects?

[ ] Foo
[ ] Foobar
[ ] Syntactic variable

This is just one idea for addressing the issue. There are surely others. Think big. :-)
Comment 12 MZMcBride 2012-07-07 17:07:31 UTC
(In reply to comment #11)
> One possible idea it to provide checkboxes on the "page moved successfully"
> page. Something like this...
> 
> "Foo bar" has been to moved to "Metasyntactic variable". Would you like to
> update the following redirects?
> 
> [ ] Foo
> [ ] Foobar
> [ ] Syntactic variable
> 
> This is just one idea for addressing the issue. There are surely others. Think
> big. :-)

This is bug 18468.
Comment 13 John Mark Vandenberg 2014-11-09 13:18:47 UTC
The requested functionality exists in the software.

There is no technical consensus to change the configuration of $wgMaxRedirects, and as far as I know no English Wikipedia project community consensus to change this configuration.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links