Hi, Steve. Looks like we're in broad agreement. A couple of minor things:
Steve Bennett wrote:
On 10/22/07, William Pietri william@scissor.com wrote:
True. Although we could do it with no database changes if we just go through and update the existing redirects on page save.
My first reaction is that that's kludgy. I guess the downsides are that you end up with actual redirect pages, and lots of them, inflating our page count, and possibly other bad things.
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.
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.
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.
Well, it's unlike any behaviour - MediaWiki *never* refuses to save because of bad syntax.
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.)
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 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).
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 news}} does that if you leave the article title out. Perhaps that's the approach most consistent with the current model.
Taking the aliases to a separate UI would solve this, too, of course.
IMHO:
A [Foo] Bar = A Foo Bar, A Bar A [Foo|Moo] Bar = A Foo Bar, A Moo Bar A [Foo|Moo|] Bar = A Foo Bar, A Moo Bar, A Bar A [[Foo|Moo]] Bar = same as previous, but discouraged.
It keeps the total syntax down to three elements: [], |, and an escaping mechanism, presumably . Fortunately [, ], | and \ are all extremely uncommon in (Wikipedia) page titles.
Perfect. People are already used to whitespace compression, so I think that is just fine.
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 the most I think you can ask for. :-) Consider this page, for example:
http://www.sidereel.com/The_Office
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 idiot filter, so I think vandalism went up some.
Now that we're adding things like user ratings and user reviews, we followed the same pattern. We feel like our experience there confirms that approach, at least for things that are metadata-ish.
William