Steve Bennett wrote:
Yeah, I did some more thinking about this in bed and
thought about a
possible implementation.
The wiki code would be a single line, like #ALIASES [City of ][Greater
]Melbourne[, Victoria| (Australia)]
Two tables would store all the aliases [...]
just look up the first 5 characters ("Great"), then iterate over the
matches there. There are lots of algorithms and data
structures that would help here.
True. Although we could do it with no database changes if we just go
through and update the existing redirects on page save. I think I'd only
go for something more interesting if we wanted to get rid of redirects
altogether in favor of aliases. I haven't looked at the request routing,
code, though, so maybe I'm just being a bit chicken.
From a user
experience perspective, I'd be a little worried about
putting more mysterious Wiki markup at the top of
a page. On another
wiki I'm working on, we're moving more of this metadata outside the
markup and to specialized UIs, so that it doesn't clutter the edit box.
So put it at the bottom, next to {{DEFAULTSORT}}. I do agree that
location-independent metadata should
be separated from content though. Categories and interwikis fall into
that category too.
Hmmm... There I'd be worried about people not finding it. Probably
better to do actual user testing, but my guess is that sticking it in at
the top is the best easy implementation.
I think the
only real abuse potential comes from either putting in a
giant list or trying to redirect in a bunch of existing articles. But
one you can catch with a size limit, and the other you could fix by
refusing to mess with real articles.
Most likely from having a redirect which expands to too many possibilities,
like [A|b|c|d|e][A|b|c|d|e][A|b|c|d|e][A|b|c|d|e]. But that would be easily
catchable. The trouble is what to do about it, besides failing silently.
Perhaps reject it into a special page that admins can browse from time to
time?
I think both should just refuse to save with error messages, sort of
like the behavior now if you ask it to nag you about edit comments.
Alternatively, it could behave like most other mangled wikimarkup and
just render it as plain text if it doesn't like it. Although that's more
consistent with the current model, I think the not-visible-on-the-page
nature of redirects would make that approach wrong for #ALIASES.
Well the great thing with such a limited expression
language is that there's
very little to learn, and very little to stuff up. And even better, users
can just use the most naive approach imaginable. So, while a CS major would
readily write an expression like:
#ALIASES [Dr] Grace [Smith|Jones]
A beginner user might simply write:
#ALIASES [Dr Grace Smith|Dr Grace Jones|Grace Smith|Grace Jones]
or even:
#ALIASES Dr Grace Smith
#ALIASES Dr Grace Jones
#ALIASES Grace Smith
#ALIASES Grace Jones
That's a great point.
Would we need a little more in the syntax to suggest whether blocks
could be optional?
A UI tool would obviously help, but that would be a
slight departure for
MediaWiki. There's nothing else like that atm (afaik), so it's hard to
picture how it would fit in exactly.
Yeah, it would be a departure for sure. On the other Wiki-driven project
I've been working on, which we coded from scratch, we've been adding
more JavaScript UI for metadata and it has been a big hit, especially
for things that have complicated structure.
William
--
William Pietri <william(a)scissor.com>
http://en.wikipedia.org/wiki/User:William_Pietri