On 9/2/05, Rowan Collins <rowan.collins(a)gmail.com> wrote:
On 01/09/05, Sy <sy1234(a)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.