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.