On 01/09/05, Andrew Dunbar <hippytrail(a)gmail.com> wrote:
Perhaps a new feature of "aliases" which
belong to an article, as a
separate feature to redirects
but built on top of the redirect feature in a well-thought-out way.
Well, isn't that what we're discussing - how to make it
"well-thought-out"? Like I say, I agree with the usefulness of the
idea, but I'm not yet sure how to deal with the subtleties of it.
Perhaps at a later stage aliases
could completely replace redirects. Are there uses of redirects which
are distinct from aliases?
Well, some would say there *shouldn't be*, but in practice redirects
also get used for things like redirecting a sub-topic which doesn't
deserve its own article to a wider topic which contains it.
Personally, I think this is rather useful in cases where there will
probably *never* be an article just about the sub-topic ("List of
minor characters in X" are one example of this set-up) as it saves the
user an extra click. Such uses aren't really "aliases", but then
there's no real reason to separate them technically.
I'm assuming the concept of aliases owned by the
article is easily understood.
Yes, I get the idea of having them conceptually attached to the
article, but in terms of implementation this raises some complex
issues:
* How do you deal with the fact that a given title can be both an
article in its own right, and an alias defined by another article?
* How do you keep the code efficient if it has to check two places
(the list of redirects and the list of actual pages) every time it
wants to look up a title?
* If you abandon the current "redirect created by magic page content",
how do you convert a page to an alias, or vice versa?
* What happens when somebody tries to create an alias which is already
a page, or which is already an alias for something else?
* What happens when you remove something from the list of aliases?
The last three boil down to "where is the central point of control for
aliases" - given the title "Bar" which may or may not redirect to
"Foo", the current system requires all changes in that state to happen
on the "Bar" edit page. Being able to edit a separately-stored alias
called "Bar" via "Foo" would necessitate some way of the two edits
suppressing each other (you can't create an alias, because there's a
page there / you can't create a page, because there's an alias there)
and then some mechanism for overriding that (delete the page? blank
it? tick a 'notify watching users and create alias anyway' box? / edit
"Foo" to remove the alias? tick a special 'notify and confirm' box?).
So, like I say, maybe the most sensible thing would be to leave the
data-structures mostly as they are, but create some user-interface
tools which let you manipulate redirects en masse - "fix these double
redirects for me", "create redirects at these pages for me", and even
"edit the destinations of this list of redirects" are all features
which could be fairly straightforwardly automated within the existing
scheme. [They'd have to act like a kind of built-in bot, leaving
automatic edit summaries behind like moving pages now does.] Like I
say, who gets to do it would be an important question, because it
could potentially create a vandal's playground, but that's doable too
- indeed, more doable with a Special: page than with some voodoo built
into ordinary edit pages.
--
Rowan Collins BSc
[IMSoP]