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.
Perhaps at a later stage aliases
could completely replace redirects. Are there uses of redirects which
are distinct from aliases?
I'm assuming the concept of aliases owned by the article is easily understood.
Andrew Dunbar (hippietrail)
On 8/31/05, Rowan Collins <rowan.collins(a)gmail.com> wrote:
On 30/08/05, Tels <nospam-abuse(a)bloodgate.com>
wrote:
is an interesting one. Changing the system so
that you keep the list of
redirects inside (at end) article A would have the benefit that you see
them at once and can maintain them better. Currently someone reading A
doesn't (easily) see all the redirects to it.
I agree that this could be a useful feature, but I think it would need
to be a little more subtle, and I can foresee some major issues with
implementing it. Perhaps a separate box on the edit page listing
"pages that redirect here" - generated dynamically, not stored with
the page's content, as that could easily lead to inconsistencies.
Another related question is how to deal with double redirects,
particularly those caused when moving a page: Should the software fix
them automatically [or implicitly do so, as it would if they were
stored with the content]? Probably not, since a page move is sometimes
to make way for a more suitable article at the old title, so the
redirects may belong to one or the other. But in that case, how do you
display such double redirects in the "backwards" list? Perhaps you'd
not list them at all, and people could copy-and-paste them from the
new redirect's edit page if appropriate.
If two articles have the same article name in
their synonym list, an
disambigition (sp?) page could be automatically created (with a warning
issued to the editor that the current saved article asks for a redirect
which an already existing article also has).
This is an important problem with editting the list backwards like
this - an edit is usually considered "complete" when you click save,
whereas this would be more of an interactive process, where you need
to look at the feedback to see whether the software has actually
allowed your changes.
And what happens if I *remove* a redirect from the list - does the
page get deleted, even though I don't have deletion rights? Or perhaps
just changed to a blank page? Remember it might have history from
before it was a redirect...
Perhaps in the end what is needed is a move-page like function that
lets you say "if any of these articles don't exist, make them redirect
to X", which would then tell you which ones it had been unable to
create so you could do them manually.
Of course, even that would be open to abuse, since it potentially
allows a user to create tons of junk redirects in very little time...
In the future one could even do away with each
redirect to be it's own
article (which always seemed a bit awkward to me, you end up having to
not count these in a lot of places (redirects arent articles in the sense
of a real article, so they are no short articles, no real articles etc).
However, this would be a quite a change.
The thing with this is that it just creates special cases elsewhere
instead - if redirects weren't articles, then every time the software
"follows" a link, it would have to first check if there was an article
with that name, and then check if there was a redirect with that name.
And any places where you *do* want to count redirects -
Special:Wantedpages, for instance - would then have to explicitly
include them. So I think this would be rather a case of swapping "six
of one for half a dozen of the other".
Also, what would happen to an article which was turned into a
redirect? Would it have to be deleted, so that the text didn't mask
the redirect - or perhaps it could still exist, but be hidden by the
fact that the redirect existed; in which case, how would you revert it
back to being an article? Although it seems weird editting the text of
an article to turn it into a redirect, it does make sense to store
that action in the edit history along with everything else, even if it
has a *side-effect* of creating better metadata than we have now.
--
Rowan Collins BSc
[IMSoP]
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l