On 05/09/05, Timwi <timwi(a)gmx.net> wrote:
I think most of those questions are quite easy to
answer once you
realise that (a) 99% of people looking for a topic do so via the search
box, not the URL; (b) when someone links to an article, they do it via
the URL, not the search box. Hence:
Ah - this is indeed a distinction I hadn't considered; I guess I'm
just too "stuck" in the traditional wiki concept that internal links
are what holds everything together. Personally, I almost never use the
search box, because I know the naming conventions and the URL form,
and just guess that way; this may be silly of me.
* 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?
The URL should display the article. The search box should give a
selection of both possibilities.
So, an internal link to [[Foo]] would always go to the article "Foo",
if it existed, but typing "Foo" and clicking "Go" might come up with
a
list of alternatives instead; I guess that could work. Of course, this
isn't nearly as related to redirects as earlier discussion suggested,
being more like an enhancement to the search facility (a way of
manually stuffing things into the results) than giving alternative
titles to pages.
* 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?
Caching.
I was referring more to the fact that during the course of a request,
many many titles may be looked up in the database; if they had to be
looked up in a separate 'alias' table as well (not a necessary part of
the implementation, but one some were suggesting), the number of
queries would, AFAICS, effectively double. But this is moot if you're
only talking about search functions, not links.
* If you
abandon the current "redirect created by magic page content",
how do you convert a page to an alias, or vice versa?
You don't "convert" a page to an alias; you just create the alias, and
independently of that, delete the page (if that is what you want to do).
Similarly, removing an alias and creating a page should also be separate
actions.
If no interaction with internal links is implied, then yes, that makes
sense. If you wanted links to be able to point at aliases, too, I
guess you could add an automatic disambiguation message at the top of
the page ("$1 is also defined as an alias for $2[, $3[, etc]]") -
preferably with appropriate links for managing the aliases.
* What happens
when somebody tries to create an alias which is already
a page, or which is already an alias for something else?
The alias gets created as always. Now if someone searches for the alias,
it should (obviously) list all the pages that have this alias. The same
should probably happen to the URL if there is no actual page at that
title; although I wouldn't mind having the URL display the "page does
not exist" screen so that it is easier to create a page at that title.
If these aliases are only intended for searching, they should
definitely not display as though the page existed - they should
probably be displayed in a clear box above the "page does not exist
screen", both for search results and "URLs" (since linking to a page
that doesn't exist is a bit like searching; linking to a page that
does exist is less so).
* What happens
when you remove something from the list of aliases?
The alias gets removed. Duh. :-) We already have this happening with
categories.
Again, I was thinking of aliases as being more similar to redirects -
a way of defining a particular title as being an alias for exactly one
page (many aliases, but each with only one target). In the context of
a many-to-many mapping, of course this is a no-brainer. If other
people were thinking in terms of many-to-many, my apologies for not
cottoning on sooner - as far as I know, you're the first one to make
this explicit.
With this in mind, let's revisit the question of whether these could
replace at least some redirects. It seems to me that if they did, they
would actually end up replacing disambiguation pages as well - if a
title was associated with only one alias, it would redirect, if more
than one, disambiguate. For example, "BT" could be an alias for
various pages which might have that name if they weren't in conflict,
with the summaries stored somewhere with the aliases themselves (and
perhaps editable from both the disambig page *and* the target one).
Some kind of warning or protection *would* then be needed when
creating a page in place of one or more aliases, as this would affect
the operation of all links referencing that title (turning the
redirect into a "See also" message, or the disambig page into a "For
other uses..." reference, akin to current en.wp "see [[<foo>
(disambiguation)]]")
--
Rowan Collins BSc
[IMSoP]