after some tests, it seems that #redirect works only once (1.5)
that is
test1 redirect to test2 redirect to test3
clicking on test1 send the user on test2, not on test3
is that what is wanted ?
I mail fail, but I had already renamed a page more than once (due to excess typos :-() and I think a got the last page from the first on the same clic (1.4)?
thanks jdd
Am 31.08.2005 um 09:44 schrieb jdd:
after some tests, it seems that #redirect works only once (1.5) … is that what is wanted ?
Absolutely. Imagine:
Article A -> Art. B -> Art. C -> Article A
Of course it's easy to prevent such loops by remembering where the redirect started but for reasons of performance MediaWiki decides for the simple way of allowing only one redirect.
ciao, tom
-- http://de.wikipedia.org/wiki/Benutzer:TomK32 http://www.tomk32.de
On 8/31/05, Hínandil hinandil@freespirits.org wrote:
Absolutely. Imagine:
Article A -> Art. B -> Art. C -> Article A
And don't forget to tell him that Special:DoubleRedirects lists such problems with redirects, all the easier to fix them with. :)
Special:DoubleRedirects is a pretty inane concept. There should just be an admin bot to go ahead and fix all those links.
At the very least, that special page should have a series of links (or preferably checkboxes and a submit button) to fix each double/triple/whatever redirect.. making them all redirect to the final target.
Frankly I would see value in an automatically self-healing setup where redirects adjust themselves after being followed to point down the chain to that final target page.
This A -> B -> A nonsense is just silly.
A > B > A when followed once A becomes just A with no redirecting.
A > B > C > B when followed once, A becomes A > B
There's overhead, but not that much overhead, for a self-healing redirect concept.. just do the overhead the first time a user visits a redirect and ends up with a redirect.
It might indeed be too much overhead for every redirect to check if it ends up with a redirect every time it is visited. One simple admin function to just "go fix all of that crap" would work though..
/rant
(Btw, yes, I have to learn to program so I can do it myself..)
On 01/09/05, Sy sy1234@gmail.com wrote:
At the very least, that special page should have a series of links (or preferably checkboxes and a submit button) to fix each double/triple/whatever redirect.. making them all redirect to the final target.
This much I agree with; it could make the edit automatically, and leave an appropriate note in the edit history/watchlists/etc.
Frankly I would see value in an automatically self-healing setup where redirects adjust themselves after being followed to point down the chain to that final target page.
This I'm less sure of - sometimes, people will move a page so that they can create something else at the old location; in this case, at least some redirects to the old location *should not* be fixed. If they were automatically "healed" as soon as someone followed them, they would come to point to the wrong location. I think automating / assisting in the *process* is fine, but the decision to carry out the action should still be left to a human.
A > B > A when followed once A becomes just A with no redirecting.
Why is it not fixed at A->B, with B not redirecting (since you could equally describe the loop as B->A->B)? And what does "just A with no redirecting" mean - a blank page? How is this an improvement on the current situation, since it still needs someone to work out why it's gone wrong and fix it. And by arbitrarily manipulating the redirects like this, you've lost some of the information about the original situation - it is no longer as easy to see that A was a redirect to B in order to work out what it *should* be.
A > B > C > B when followed once, A becomes A > B
What is actually changed in this situtation? A already redirects to B, but you imply that it is A that changes; in fact, what needs changing is B and/or C, presumably to a blank page - but then you've lost any feedback that there is a broken connection. As I've said elsewhere [1] you'd end up needing to draw a diagram just to explain what chain of redirects the user had stumbled upon - it ought to be obvious that A->B->C->D->E->C is a bit of a mess, and *all* those should be changed; an 'auto-heal' algorithm might set A->E, B->E, C->E, D->E and E blank, but has that really '"fixed" anything?
One simple admin function to just "go fix all of that crap" would work though..
Agreed, that would be useful.
==Refs== [1] -> http://bugzilla.wikimedia.org/show_bug.cgi?id=2402#c3
See also the other current discussion of redirects on the other list, at http://mail.wikimedia.org/pipermail/wikitech-l/2005-August/thread.html#31232 and http://mail.wikimedia.org/pipermail/wikitech-l/2005-September/thread.html#31...
On 9/1/05, Rowan Collins rowan.collins@gmail.com wrote:
On 01/09/05, Sy sy1234@gmail.com wrote:
Frankly I would see value in an automatically self-healing setup where redirects adjust themselves after being followed to point down the chain to that final target page.
This I'm less sure of - sometimes, people will move a page so that they can create something else at the old location; in this case, at least some redirects to the old location *should not* be fixed. If they were automatically "healed" as soon as someone followed them, they would come to point to the wrong location. I think automating / assisting in the *process* is fine, but the decision to carry out the action should still be left to a human.
Aah, I totally missed this.. good point.
A > B > A when followed once A becomes just A with no redirecting.
Why is it not fixed at A->B, with B not redirecting (since you could equally describe the loop as B->A->B)? And what does "just A with no redirecting" mean - a blank page? How is this an improvement on the current situation, since it still needs someone to work out why it's gone wrong and fix it. And by arbitrarily manipulating the redirects like this, you've lost some of the information about the original situation - it is no longer as easy to see that A was a redirect to B in order to work out what it *should* be.
Yes, it means just a blank page.. no, it won't make the problem of missing content go away.. it's just another dead-end page.
A, as (A > B > A), becomes just A B stays (B > A)
You could have A have a reference that it was (A > B) but that B is (B
A), so there's no loss of knowledge there. This concept solves the
double-redirect problem, but it can't be much smarter. Another panel to describe lost pages like would be a help for that though.
A > B > C > B when followed once, A becomes A > B
What is actually changed in this situtation? A already redirects to B, but you imply that it is A that changes; in fact, what needs changing is B and/or C, presumably to a blank page - but then you've lost any feedback that there is a broken connection. As I've said elsewhere [1] you'd end up needing to draw a diagram just to explain what chain of redirects the user had stumbled upon - it ought to be obvious that A->B->C->D->E->C is a bit of a mess, and *all* those should be changed; an 'auto-heal' algorithm might set A->E, B->E, C->E, D->E and E blank, but has that really '"fixed" anything?
Hmm.. I see your point. Maybe the answer is that when a page is first turned into a redirect page the editor is told that it's a double and they can act on it immediately.
Then the page that tells them about the existance of that double-redirect could be the helper concept being mulled over.
example:
---
You just specified this page "foo" as a redirect to "bar". Unfortunately, "bar" is also a redirect (to page "baz"), would you like to change your mind?
Redirect page to: [_________bar]
---
Then if they changed "foo" to redirect to "baz" they can be again told if there is a conflict, etc.
Blah, but I don't have much interest in the problem of redirects, because my primary editing experience is with my solo wiki.. I just needed to vent a little. =)
On 01/09/05, Sy sy1234@gmail.com wrote:
A > B > A when followed once A becomes just A with no redirecting.
[...]
Yes, it means just a blank page.. no, it won't make the problem of missing content go away.. it's just another dead-end page.
So how does this improve on the current system, where it is obvious that it's a broken page, because you get redirected to a redirect rather than an article?
A, as (A > B > A), becomes just A B stays (B > A)
Why? Just as A is A->B->A, B is B->A->B - the only reason one seems more natural is because we're discussing them with labels which have an obvious sequence to them. In reality they might be "color" (#redirect [[colour]]) and "colour" (#redirect [[color]]); according to your system, whichever a user happened to visit first would become blank, and the one they happened not to visit would continue redirecting, to that blank page. Surely it makes more sense to change either both or neither?
You could have A have a reference that it was (A > B) but that B is (B
A), so there's no loss of knowledge there.
Why not leave the reference that's already there - i.e. the redirect?
This concept solves the double-redirect problem, but it can't be much smarter. Another panel to describe lost pages like would be a help for that though.
It doesn't "solve" the problem at all - it detects it, and replaces a broken redirect with a note that "this was a broken redirect". Certainly, if multiple redirects were allowed, loop detection is necessary, but I don't see what is gained by having that detection change the content of the pages in question - all it needs do is present a message to the user that a loop has been detected, listing the redirects involved in the loop.
Hmm.. I see your point. Maybe the answer is that when a page is first turned into a redirect page the editor is told that it's a double and they can act on it immediately.
That's reasonable, but I think most double redirects are created the other way round: a page has redirects pointing to it, and then becomes a redirect itself, often through use of the Special:Movepage function. So it would more often be "you've created a redirect [[Foo]] which has the following redirects pointing to it; these will no longer work..."
Then the page that tells them about the existance of that double-redirect could be the helper concept being mulled over.
An interesting point - moving a page or creating a redirect could warn users about double redirects, and offer a mass-edit interface for those linking into or out of the redirect just created. As I've mentionned already, we'd have to think about how much power this would give users, and how to make it hard to abuse and/or easy to revert...
Blah, but I don't have much interest in the problem of redirects, because my primary editing experience is with my solo wiki.. I just needed to vent a little. =)
Fair enough, but perhaps you now realise that the current setup isn't as daft as it might seem - lack of on-wiki mass-edit tools not-withstanding ;)
On 9/2/05, Rowan Collins rowan.collins@gmail.com wrote:
On 01/09/05, Sy sy1234@gmail.com wrote:
Hmm.. I see your point. Maybe the answer is that when a page is first turned into a redirect page the editor is told that it's a double and they can act on it immediately.
That's reasonable, but I think most double redirects are created the other way round: a page has redirects pointing to it, and then becomes a redirect itself, often through use of the Special:Movepage function. So it would more often be "you've created a redirect [[Foo]] which has the following redirects pointing to it; these will no longer work..."
I totally understand where you're coming from with what you've been saying. A lot of the over-automation i was suggesting is completely misplaced. I like what you're saying when you talk about how the problem is created in the first place.
One solution I see is when moving a page, it picks up the list of things redirecting to it and displays them in a list.
Then the user can choose all/some/none of those items to have the redirects adjusted to the new move location.
So basically this amounts to a move control panel.. instead of just a "what do you want to name this?" prompt it would have a series of redirect links for optional automated adjusting.
Also, I like the idea that redirect chains which end in content could have a similar feature to bring up a similar all/some/none checkbox list for admins to repair them to all point at the destination.
Everything else can be left as-is, worked with by a person pulling up the double-redirects list.
As I've mentionned already, we'd have to think about how much power this would give users, and how to make it hard to abuse and/or easy to revert...
This would be an interesting dillema. I suppose if someone hacked in this functionality what would appear right now if a person moved a page and moved associated redirects to is there would be a mess of edits.. one for the original move, and one edit for each adjusted redirect page.
I suppose one "revert" function to put everything back in place would be handy, but not necessarily.. uh, necessary. =)
--
veering a bit:
Personally, I like the idea of an article having metadata: * article aliases * article description
Then people can make articles, specify aliases and alias collisions automatically generate disambiguation pages with the article description.
Descriptions could also allow clearer listings for categories, backlinks and the like.
Concepts:
* If a page has no description, it is summarized out of the first paragraph. * Aliases are automatically generated with the various case combinations. * An alias which collides with an existing article will appear as a polite sidebar or header, so that a visitor can get an automatically-generated/maintained "there is also an article on foo.."
Mind you, my beliefs are that wikis will eventually mature to absorb concepts like these found in content management systems, while keeping its notible agility: ease and speed.
Thomas Koll wrote:
but for reasons of performance MediaWiki decides for the simple way of allowing only one redirect.
ok, thanks jdd
On 8/31/05, Thomas Koll tomk32@gmx.de wrote:
Am 31.08.2005 um 09:44 schrieb jdd:
after some tests, it seems that #redirect works only once (1.5) … is that what is wanted ?
Absolutely. Imagine:
Article A -> Art. B -> Art. C -> Article A
Of course it's easy to prevent such loops by remembering where the redirect started but for reasons of performance MediaWiki decides for the simple way of allowing only one redirect.
Actually not THAT easy, consider:
Article A -> Art. B -> Art C -> Art. B
To detect a cycle each 'new' article in the cycle needs to be checked against all previously visited articles.
On 31/08/05, Thomas Koll tomk32@gmx.de wrote:
Am 31.08.2005 um 09:44 schrieb jdd:
after some tests, it seems that #redirect works only once (1.5) … is that what is wanted ?
Absolutely. Imagine:
Article A -> Art. B -> Art. C -> Article A
Consider also that a "redirected from [link]" message is provided to go back and edit the redirect (although the monobook skin makes it too small, imho) - with a chain of redirects like A->B->C->D->E, this would have to become "Redirected from [[A]], via [[B]], via [[C]], via [[D]]." or "Redirected from [[D]], which was redirected from [[C]], which was redirected from [[B]], which was redirected from [[A]]."
Although it creates work because people have to find and fix them (although arguably they should anyway, in most cases), not obeying multiple redirects makes them much more manageable in a more general sense. I believe Brion or Tim or somebody once described it as avoiding "spaghetti", but I can't find the reference.
Cf http://bugzilla.wikimedia.org/show_bug.cgi?id=2402 and I'm sure other discussions, here, there, or on the old SF.net bug-tracker...
mediawiki-l@lists.wikimedia.org