[WikiEN-l] Tool announcement: Alternative names redirect

[William Pietri]

Hi, Steve. Looks like we're in broad agreement. A couple of minor things:

Steve Bennett wrote:
> On 10/22/07, William Pietri <william at 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


-- 
William Pietri <william at scissor.com>
http://en.wikipedia.org/wiki/User:William_Pietri