Last modified: 2012-11-14 12:19:27 UTC
Per the discussion in the URL (http://en.wikipedia.org/w/index.php?oldid=276064013#Double_redirects), there is clear community support for permanently enabling at least double redirects. Assigning to Brion 'cos the next scap will close the loophole (bug17570, r47512) that currently allows double redirects on all Wikimedia wikis; this config change should be done before or together with the next scap. Severity != enhancement because we've already *got* the feature, we now don't want to lose it! :D
I suggest to think over setting $wgMaxRedirects=2 (minimum) on all Mediawiki wikis, if cost warrants it. The current setting has imho turned out quite nicely to keep technicalities out of the ordinary users sights while we are waiting several days before we get a new list of 5000 duplicate redirects (:only:) which we then can eliminate. Thus we can count this setting as yet another small step towards better usability.
Bug 17934 is related to this.
*** Bug 18074 has been marked as a duplicate of this bug. ***
I think that all the effort, confused readers, and toolserver resources used to fix double redirects is patently pointless. All that needs to be done is to disable all bots used to fix double redirects and change the setting. Triple redirects are very rare and are a bad idea anyway to ever have. However, this isn't a very important problem and if the devs have more pressing matters to work on, let them do those first.
This is one we probably want to start on test, pre-announce, and have people poke it a bit.
As long as it gets onto the carousel, that's ok. But I expect some people are going to be unhappy when they realise that the 'Golden Age' of double redirects working on wikipedia is already over... :D There is some thought on en.wiki about asking for very long chains (eg 10) to be allowed so we have more flexibility in building chains with semantic clarity. Are there performance and/or security considerations with that, or is it something we can legitimately think about (and potentially ask for)??
I'm not sure I understand what Brion is suggesting. Surely this has been tested, since it's a feature of the software, and has in effect been operative on en.wp for some time because of the other bug. Since the community has clearly expressed the will for the change (i.e. for the current effective setting to continue after the other bug is fixed), and making the change presumably takes no effort at all on the part of the devs, I don't see any reason for it not to be done.
Regarding Comment #4: Triple-redirects are very rare ''because'' bots now fix all double-redirects soon after they are created. Once double-redirects are allowed, triple-redirects will no longer be rare. If we allowed septuple-redirects, eventually we would start accumulating octuple-redirects. Whatever level of redirection is allowed, we still need (a) a mechanism for identifying those redirects that exceed the maximum level, and (b) a protocol for fixing them.
(In reply to comment #8) > Regarding Comment #4: Triple-redirects are very rare ''because'' bots now fix > all double-redirects soon after they are created. Once double-redirects are > allowed, triple-redirects will no longer be rare. If we allowed > septuple-redirects, eventually we would start accumulating octuple-redirects. > Whatever level of redirection is allowed, we still need (a) a mechanism for > identifying those redirects that exceed the maximum level, and (b) a protocol > for fixing them. > We could continue the use of the double redirect bots, which will minimize disruption (as many bots fix double redirects as a side task) and triple redirects. On en.wp, the abuse filter could also be set to disallow moves or edits resulting in triple redirects, or possibly even both. I still think that as long as we aren't asking for the impractical, consensus and its occasionally twisted logic should be the guiding force.
Out of idle curiosity, does the zero-one-infinity rule apply to (number of levels of indirection for redirects)? http://www.catb.org/jargon/html/Z/Zero-One-Infinity-Rule.html
Mass-unassigning shell bugs from myself to Rob; I used to do them once, but I don't have time for them any more.
Ok, going to ping about this. We are ok to put it in, but we want to ensure it is still wanted/required as this bug is INSANELY old. I am putting this in for request, and resolving the bug. Please do not hesitate to re-open it if it is indeed still wanted.
I think this is still desired pretty much on every wiki, as pointed out above.
Not only old. It's outdated. Any number redirects are possible per $wg(someting) parameter, and it as been set to 2 on most or all WMF wikis.
I think it's safe to say we're done here. Though the bots will likely continue to fix them, our readers will no longer encounter the pervasive problem with double redirects. With the fix in place, I suggest that if anyone wants to add a comment, they should also reopen this bug.
(In reply to comment #14) > Not only old. It's outdated. Any number redirects are possible per > $wg(someting) parameter, and it as been set to 2 on most or all WMF > wikis. Can someone provide some example? Redirects on [[Special:DoubleRedirects]] are not working on all wikis I checked.
(In reply to comment #14) > Not only old. It's outdated. Any number redirects are possible per > $wg(someting) parameter, and it as been set to 2 on most or all WMF > wikis. $wgMaxRedirects is still set to 1, see http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/DefaultSettings.php?view=markup I'm sure increasing the number of allowed redirects is still desired -- at least 2, personally I would like to have it at 3 to allow for some frequent, valid redirect chains. Rob, do you require another straw poll from the community, or is support here sufficient?
Closing per above
Reedy: What "above" are you referring to? $wgMaxRedirects is still set to 1. Double-Redirects do not work. Where does this "work for you"?
(In reply to comment #15) > I think it's safe to say we're done here. Though the bots will likely continue > to fix them, our readers will no longer encounter the pervasive problem with > double redirects. With the fix in place, I suggest that if anyone wants to add > a comment, they should also reopen this bug.
Ok, what about comment #16 and comment #17? :) I just tried it again at [[User:Amalthea/rd1]], thinking that I'm missing something, but no, still doesn't work.
There's no "consensus" at the moment, so it's not actionable... Changing the number to fix it is easy enough, when we decide what we want to do ;)
Right, you closed it as WORKSFORME though. Whether there is still consensus is a different question, and exactly the one that I asked in comment #17: enWP had a straw poll 28 months ago, when this issue was opened. I've seen no objections here or anywhere (except maybe that bug 17934 should be worked on first), but if you don't consider this enough, say the word and I'll go ask again at enWP.
(In reply to comment #23) > Right, you closed it as WORKSFORME though. Whether there is still consensus is > a different question [...] Until we have the answer, let's remove "shell" keyword.
(In reply to comment #24) > Until we have the answer, let's remove "shell" keyword. Hmm, that will only delay resolution of this issue, someone with shell access will have to say whether the poll we had is sufficient.
I can't say that's enough people for a consensus. What are the drawbacks of this?
Come back when this actually needs some action
Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116
