set $wgMaxRedirects = 2 on en.wiki
Closed, InvalidPublic

Description

Author: happy_melon

Description:
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


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/w/index.php?oldid=276064013#Double_redirects

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz17888.
bzimport created this task.Via LegacyMar 9 2009, 4:59 PM
bzimport added a comment.Via ConduitMar 9 2009, 6:04 PM

bugzilla.wikimedia wrote:

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.

bzimport added a comment.Via ConduitMar 11 2009, 1:01 PM

russblau wrote:

Bug 17934 is related to this.

Anomie added a comment.Via ConduitMar 21 2009, 12:21 AM
  • Bug 18074 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMar 21 2009, 3:10 PM

ipatrol6010 wrote:

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.

brion added a comment.Via ConduitMar 26 2009, 5:18 PM

This is one we probably want to start on test, pre-announce, and have people poke it a bit.

bzimport added a comment.Via ConduitMar 26 2009, 5:48 PM

happy.melon.wiki wrote:

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)??

bzimport added a comment.Via ConduitMar 27 2009, 8:27 AM

catlow wrote:

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.

bzimport added a comment.Via ConduitMar 27 2009, 1:34 PM

russblau wrote:

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.

bzimport added a comment.Via ConduitMar 30 2009, 2:55 AM

ipatrol6010 wrote:

(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.

bzimport added a comment.Via ConduitSep 3 2009, 1:43 AM

nykevin.norris wrote:

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

Catrope added a comment.Via ConduitApr 19 2010, 8:22 AM

Mass-unassigning shell bugs from myself to Rob; I used to do them once, but I
don't have time for them any more.

RobH added a comment.Via ConduitMay 13 2011, 10:46 AM

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.

Nemo_bis added a comment.Via ConduitMay 13 2011, 10:51 AM

I think this is still desired pretty much on every wiki, as pointed out above.

bzimport added a comment.Via ConduitMay 13 2011, 5:18 PM

bugzilla.wikimedia wrote:

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.

bzimport added a comment.Via ConduitMay 13 2011, 9:09 PM

ipatrol6010 wrote:

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.

Nemo_bis added a comment.Via ConduitMay 14 2011, 6:55 AM

(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.

bzimport added a comment.Via ConduitMay 14 2011, 9:07 AM

Amalthea.wikimedia wrote:

(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?

Reedy added a comment.Via ConduitJul 8 2011, 11:40 PM

Closing per above

bzimport added a comment.Via ConduitJul 9 2011, 12:39 AM

Amalthea.wikimedia wrote:

Reedy: What "above" are you referring to?

$wgMaxRedirects is still set to 1. Double-Redirects do not work. Where does this "work for you"?

Reedy added a comment.Via ConduitJul 9 2011, 12:40 AM

(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.

bzimport added a comment.Via ConduitJul 9 2011, 12:49 AM

Amalthea.wikimedia wrote:

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.

Reedy added a comment.Via ConduitJul 9 2011, 12:52 AM

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 ;)

bzimport added a comment.Via ConduitJul 9 2011, 8:12 AM

Amalthea.wikimedia wrote:

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.

Nemo_bis added a comment.Via ConduitJul 9 2011, 10:10 AM

(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.

bzimport added a comment.Via ConduitJul 12 2011, 11:11 AM

Amalthea.wikimedia wrote:

(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.

aaron added a comment.Via ConduitAug 10 2011, 5:22 PM

I can't say that's enough people for a consensus.

What are the drawbacks of this?

Reedy added a comment.Via ConduitSep 7 2011, 2:58 PM

Come back when this actually needs some action

Nemo_bis added a comment.Via ConduitNov 14 2012, 12:19 PM

Switching from LATER to the second most relevant resolution for fear of information loss. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/65116

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.