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.