Last modified: 2014-11-09 13:18:47 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.
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.
(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".
(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]
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.
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 (→).
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.
Reclosing the issue as wontfix.
(In reply to comment #7) > Reclosing the issue as wontfix. Why?
Because that bug was originally open for Wikipedia and we choose to limit it to 1 redirect. So it works as intended.
(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.
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. :-)
(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.
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.
