I have an idea for an improvement to the system of redirects, by using pattern-based aliases. We've discussed it a bit on wikien-l where it has some support, so I'm posting here to find out: a) If it's feasible (ie, is not computationally too expensive) b) How much work is required to implement it c) If it was implemented, whether it would be enabled at Wikipedia d) If anyone is interested in actually implementing it. If not, I may have a go myself. The problem: Many pages require a largeish number of redirects, to cope with differences in spelling, optional words, accented characters etc. It's a surprising amount of work to create and maintain these, when the value of each individual redirect is so low. For example, [[Thomas-François Dalibard]] might be spelt four ways, each requiring a redirect: Thomas-Francois Dalibart, Thomas François Dalibard, Thomas Francois Dalibard. General solution: 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. Foo\[Moo - matches the literal string Foo[Moo 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. When a user searches for a term (using "Go"), MediaWiki would perform a normal query first, and if that fails, do an alias-based search. Thus: - Search term matches no real pages, no aliases: takes you to some search results. - Search term matches one real page, no aliases: takes you to real page. - 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. An automatically generated disambiguation page could make use of some other hypothetical keyword like {{disambig|A 19th century novelist best known for ...}}. So embedding in search results might be simpler, and would work well if it could be forced to show the first sentence or two from the article. Unresolved issues: * 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... * Whether there should just be one #ALIASES statement, or whether multiple would be allowed. Allowing several would be much more beginner friendly - they could simply state all the intended redirects explicitly. * The role of redirects once this system is in place. One possible implementation would simply create and destroy redirects as required. In any case, they would still be needed for some licensing issues. Possible implementation: Without knowing the MediaWiki DB schema at all, I speculated on a possible implementation that would be a good tradeoff between size and speed. Two new tables are needed: AliasesRaw would contain a constantly updated list of the actual aliases patterns used in articles. Each time an article is saved, this would possibly be updated. AliasesExpanded would contain expansions of these aliases, either fully or partially. So an expansion of #ALIASES [City of ][Greater ]Melbourne[, Victoria| (Australia)] to 5 characters would lead to three rows: "City ","of [Greater ]Melbourne[, Victoria| (Australia)]" "Great", "er Melbourne[, Victoria| (Australia)]" "Melbo", "urne[, Victoria| (Australia)] This means that if a user searches for "Greater Melbourne", then the search process would go something like: - Look for an article called Greater Melbourne, GREATER MELBOURNE, greater melbourne (as present) - assume this fails. - Look up "Great" in the AliasesExpanded table. Now iterate over the matching results, finding one that matches. Obviously the number of characters stored in the expanded aliases could be tuned. I look forward to any comments, Steve