On 10/23/07, William Pietri william@scissor.com wrote:
Yeah, I was going for the minimum change in suggesting that. It would also allow us to easily remove the feature, and reduces the need for immediately reducating people and adjusting third-party tools that might deal with redirects. Ideally, though, later revisions would unify the two models.
I think I'm advocating having both redirects *and* aliases, but over time reducing the need for redirects to special cases. So there would be no immediate need to reeducate or modify third-party tools, as redirects would still exist, and the use aliases would gradually creep in, as references did for example.
If we were going for unconstrained rearchitecture, I've got plenty of
notions, but none that I'd have time to code and support on my own nickel.
That's really the biggest issue here, of course.
Agreed, and that worries me some. Wikis are great for novices because
errors are visible without error messages. Plus, the way Ward coded the original wiki, giving syntax error messages would have been drastically more work. (He didn't actually parse anything; it was just a bunch of regex magic. Having written an actual parser for wiki markup, it was probably ten times the effort for me.)
Ah, I didn't know that. Yeah, I've written "parsers" that way - very quick to get going, but quickly becomes diabolically complex to debug.
Here we're extending the user's power, so that the effect of their work
is out of proportion to the effort. That's a classic opportunity for
Yay for wikis.
trouble. The effect is also almost invisible; you can see that a page is
bad, but a possibly overlapping network of millions of aliases is hard to grasp. So I the obvious choices are between noisy rejection (which is almost never done now) or silent failure (which would be painfully mysterious).
Can you give me a concrete example? What's the worst that can happen? Say you have two separate articles with two sets of aliases, but they happen to create an overlap. That's just a standard case of disambiguation, isn't it? A searching user just types "John Smith" and that matches 30 different aliases - so you get shown a page with those 30 different choices. Sounds like a good, useful behaviour, not a disaster?
Or are we still talking about the case of an overly broad aliases pattern, which I think we agreed should be rejected by the software?
I guess we could also go for noisy failure, where an error message
appears in the page itself. I think this happens when you don't substitute a template when you should, for example. And I think {{cite
That's actually the template itself producing that message, rather than the software.
news}} does that if you leave the article title out. Perhaps that's the
approach most consistent with the current model.
You're talking about Wikipedia. I'm really talking about MediaWiki. The only time I know that MediaWiki prints error messages midstream is when MathTeX fails (which is, of course, an extension). But there could be others.
Perfect. People are already used to whitespace compression, so I think
that is just fine.
I hadn't thought much about the whitespace issue. You would treat all whitespace as equivalent to a single space, except first or last? So I guess the behaviour of this:
"[Dr] John [Wilson] Smith"
is any of "John Smith", "Dr John Smith", "John Wilson Smith", "Dr John Wilson Smith" - ignoring the fact that you technically have "<space>John<space><space>Smith".
That seems good.
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.
Hit in what sense?
A hit in the sense that users now complain about other things. That's
Oh! Heh, totally missed that meaning. Was thinking "database hit", "performance hit"...:)
We originally kept the related links in the wiki markup. But especially when there are hundreds of them, too many users had a hard time managing the links. Now they are stored outside the article text, and there is custom JavaScript UI for managing them. Participation is up, and grumbling is down. The only drawback is that wiki markup acts as a mild
Wikipedia could do with a lot more of this.
idiot filter, so I think vandalism went up some.
That's ok. Vandalism is easy.
Steve