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