Simetrical & Steve Bennett quotes intermixed:
> Foo\[Moo - matches the literal string Foo[Moo
You don't need to. [ will never appear on a title, as [ is reserved for
[[links]]. It also skips the need to escape the \ (see the long thread
about an escape char).
I'd prefer the syntax to be
[Foo] matches Foo or nothing (also match blank?)
{Foo|Bar} matches Foo or Bar.
[Foo|Bar] matches Foo, Bar or nothing (or blank?)
Which is an already existing syntax on program parameters. Making []
also match blank could be an acceptable extension.
a) If it's
feasible (ie, is not computationally too expensive)
It looks so. Ultimately I'm not seeing it as much different from
current redirects, implementationally.
b) How much work is required to implement it
Probably a reasonable amount.
c) If it was implemented, whether it would be
enabled at Wikipedia
I don't see why not.
> Instead of having redirects that point to a page, have the page itself
> specify aliases which can be used to find it. This is specified as a
> pattern, like a very cut-down regexp: #ALIASES Thomas[-]Fran[รง|c]ois
> Dalibard
>
> The proposed syntax would be as follows (but is debatable):
>
> Foo - matches Foo
> [Foo] - matches Foo or blank.
> [Foo|Moo] - matches Foo or Moo.
> [Foo|Moo|] or [|Foo|Moo] - matches Foo or Moo or blank.
This would essentially be like regexes, but defined *without* the
operation of iteration: only catenation and union are allowed. This
is a large benefit because it means there are a finite number of
possible patterns, and so they can be stored in enumerated form.
All whitespace is equivalent to a single space.
So "Boo [Foo]
[Moo] Woo" matches "Boo Woo", rather than
"Boo<space><space><space>Woo" for instance.
Generally speaking I would like to see titles that differ only up to
compression of whitespace to be considered identical. If this were
the case, the searchable forms of all titles would be
whitespace-normalized, and this point would be resolved automatically.
Until then, I suggest that this aspect of it be brushed under the
carpet for aliases as for anything.
Agree. Are multiple spaces really used? If not, there could be a flag to
join them.
- Search term
matches one real page, some aliases: takes you to real page.
(Arguably gives you a "did you mean...?" banner, but not critical)
- Search term matches one alias, no real page: takes you to page.
- Search term matches several aliases, no real
page: either an automatically generated disambiguation page, or shows you
search results with the matching aliases shown first.
I see. Possibly this is better than having the aliases be unique, yes.
* Since
pattern matching is prone to abuse, the total number of matching
aliases should
be restricted in some way, perhaps to 10 or 20. The best way to handle
an excessively broad query (eg, [A|b|c|d|e][A|b|c|d|e] etc) is left
as an open question. Possibiliies include silently failing, noisily failing
(with error message in rendered text), a special page for bad aliases...
It can create exponential database rows in the length of the alias
string, yes, so that needs to be dealt with -- if we're doing explicit
storage, anyway. I think 20 is probably too low.
If we're going to store them enumerated, it's trivial to stop at
$wgMaxNumberOfAliases.
I don't understand this. Why don't you simply create an alias table
that mirrors the redirect table, like
alias_to
alias_namespace
alias_title
What about adding a new field to the redirect table to differenciate
between aliases and redirects?
Why not auto delete redirects?
> Because when articles get merged, one is turned into a redirect with
> the history of all the edits that were made. If we kill
> that redirect, we lose that history, including attribution. Ergo,
> non-compliance with GFDL.
You could autodelete them if they were autocreated. The creator would be
preserved somewhere on the history page. The redirects you talk are
"hard" redirects, created placing a #REDIRECT statement on a page.
We could create with this system "soft redirects", which are shown as
such on checking the redirect table, with fake history (autoredirect
from Foo). If it's edited, the REDIRECT is automatically preloaded and
saving makes then hard.
Problem: Complicates the process for little benefit.
What we're looking for is a way to easily create
and maintain
redirects, not some totally new feature, and despite my suggestions
above and below, I think that's how the problem should be posed. A
special page to easily manage all redirects to a page, including to
batch-create and -delete* them, is probably the best way to handle
this. Grouping on this redirects page by category would be a good
feature to have, for instance, and category management from it as
well. But to start with, reversible batch creation and deletion is
all that's needed.
A Special page changing the tables seems better than changing the page,
which only has the benefit of the integrated history. A special page
allows to reject pages, show (readable) lists of alias, select based on
language...
But splitting from traditional redirects also means more work for
integration.