On 2007.10.18 17:08:03 +0100, Magnus Manske <magnusmanske(a)googlemail.com> scribbled 26 lines: It would be nice, but there a lot more pressing issues to be working on. This problem really needs to just be handed over to someone with OCD or Asberger's equipped with Pywikipedia's selflink.py. -- gwern 2A0120 767 LHI 3848 TRD rail Edens cypherpunk Horiuchi high

Charlotte Webb wrote: I'd guess that about 5% of the times it happens it's some tremendously witty and clever person who's come up with the novel concept of redirecting [[Self-referential humor]] to itself.

On 10/21/07, Gwern Branwen <gwern0(a)gmail.com> wrote: Yes, and a semi-automating tool, when used by people who create large numbers of redirects, would reduce the incidence of this error. You're conflating two different issues here, and the latter has nothing to do with redirects. The matter being discussed is where instead of going "#redirect [[Title of correct target page]]" they go "#redirect [[Title of this redirect]]" (or redirecting [[Self-referential humor]] to itself as Bryan suggested — has somebody actually done that? hehehe) It would be easy to run a bot to identify existing cases like this (a page redirecting to itself), but damn near impossible to determine editor intent. I think the best procedure for a bot would something like: "If a previous version exists (regardless of whether it appears to be a different redirect, or a proper article) revert to that version. Otherwise delete. Notify user in either case." —C.W.

Bryan Derksen wrote: Heh. Could we use a TiredJokeBot? It'd just look for these familiar patterns and automatically revert, leaving a little note on the user's page. Heck, it could even link to the first time it was done, making clear that their joke was hilarious in 2004. William -- William Pietri <william(a)scissor.com> http://en.wikipedia.org/wiki/User:William_Pietri

On 10/19/07, Charlotte Webb <charlottethewebb(a)gmail.com> wrote: Indeed, given that people given admin powers should not be random idiots, one hopes. -Matt

Shouldn't be too hard to implement as long as you don't mind it taking half an hour to load each page as the code has to check every article in the database to see which have an alias which matches whatever you typed in/clicked on. (And that's without addressing the issue of duplicates. A redirect can only point to one article, a given string can match the regexps in many articles. Automated disambig pages, perhaps?) Nice idea, though.

Not using regular expressions, you can't. Regexps are good for telling if a string matches a pattern, they aren't good for producing a list of all strings that match a pattern (which could be infinitely long if you allow arbitrary patterns). A much simplified version of regexps could be used, but I'm not sure if it's worth it.

On 10/22/07, William Pietri <william(a)scissor.com> 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: one would store the raw patterns, and another would expand them, possibly only partially. You could expand say the first 5 characters: "City ","of [Greater ]Melbourne[, Victoria| (Australia)]" "Great", "er Melbourne[, Victoria| (Australia)]" "Melbo", "urne[, Victoria| (Australia)] 3 entries. That way, once a user types an actual request (say, "Greater Melbourne"), you 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. Omg, automated disambig pages. Yes please! Maintaining disambiguation pages is horribly time consuming. You could conceive of another keyword like "{{disambigtext|Second largest city in Australia.}}" that would be shown where necessary. But I'm getting ahead of myself. 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. 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? 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 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. Steve

On 10/22/07, William Pietri <william(a)scissor.com> wrote: 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. go for something more interesting if we wanted to get rid of redirects Oh, I meant to mention, I assume this behaviour would take place after all the other lookups: Greater Melbourne -> Greater Melbourne (fails) -> greater melbourne (fails) -> GREATER MELBOURNE (fails) try the aliases... etc. I'm not sure what the long term role of redirects would be. You can't just delete them because you lose history...though IMHO the history isn't doing a lot of good sitting on a dusty redirect somewhere. Hmmm... There I'd be worried about people not finding it. Probably Yeah, we'll have to see how it works out in practice. I think both should just refuse to save with error messages, sort of Well, it's unlike any behaviour - MediaWiki *never* refuses to save because of bad syntax. Alternatively, it could behave like most other mangled wikimarkup and I think that would be ok. At least you know you've done something wrong and will fix it...or someone else will. It's more difficult if the #ALIASES line is syntactically valid, but illegal due to too many expansions. That's a great point. 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. Hit in what sense? Anyway, I'll propose this on Wikitech and see what they have to say. It's easy to say that it could be implemented, but I haven't hacked on the MediaWiki code. Steve

On 10/22/07, RLS <evendell(a)gmail.com> wrote: I find that very counterintuitive. [Foo|Moo|] to mea reads "Foo, or Moo, or". In other words, Foo, or Moo, or blank - making the whole bracketed text optional. That is, the final pipe/bracket combo would be used to make the Hm. I don't quite agree, but that's not too important. I'm sure if this gets implemented we will come up with an expression syntax that appeals to everyone. expressions. By definition if [X] means X is optional, and [Y|Z] means you must have Y or Z, then [[Foo|Moo]] must mean that you can optionally have either a Foo or a Moo. Steve

Thomas Dalton wrote: What this proposal seems to ignore is the normal use of square brackets in texts. In a quotation like, "He [Bob] was found on the beach" the square brackets are used to add in the name to clarify the pronoun, even though it is not part of the actual quotation. The actual name would have occurred earlier in a part of the source text that is not useful to the quote. The proposal, when parsed, seems as though it would remove the brackets. Ec

Hi, Steve. Looks like we're in broad agreement. A couple of minor things: Steve Bennett 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. 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. 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. Perfect. People are already used to whitespace compression, so I think that is just fine. 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(a)scissor.com> http://en.wikipedia.org/wiki/User:William_Pietri

I think you've pretty much got a solution, so a couple more minor followups. Steve Bennett wrote: Not in the sense I'm talking about here. Most Wikipedia edits have an effect proportional to the effort required. If I put a few naughty words in a page, I've disturbed one page out of millions. Because cleaning up is generally even easier than vandalizing, the balance of power stays on the side of the angels. But when you amplify someone's power, you create opportunities for trouble. A guy with a backhoe can do a lot more damage than a guy with a shovel, often without even knowing it. Well, I you should let the alias creator know when the collide with existing articles, as touching the articles would be wrong, and silent, invisible failure is not so good either. I think you could auto-disambiguate when aliases cross, but you'd probably want a hint to write the needed text. You should also tell people when they encounter the technical limitations of Wikipedia (by by violating WP:NCTR). That's definitely another case. I think our options for all of these are 1. silent failure (accept #ALIASES line but do nothing or do it only partially) 2. noisy rejection (refuse to save, give error message) 3. noisy failure (accept save, but put an error message in the page) 4. special tool (JavaScript widget that gives continuous feedback) And I can make cases for and against any of them. I'd think what really matters is what the core MediaWiki team prefers, but I'd lead towards #3. Overall, though, it sounds like a great feature. I'd say go for it! William -- William Pietri <william(a)scissor.com> http://en.wikipedia.org/wiki/User:William_Pietri

Steve Bennett wrote: Do any of our resident data masters know what article has the most redirects? I'd just take that number, round it up, and multiply it by 2-10. Somebody going a little crazy isn't a problem. It's just that we don't want somebody creating an alias for, say, all 3-8 letter words. :-) Nice. That's a lot more work than I was thinking, but it sounds like a better approach. When you say search, you're thinking direct URLs and the "Go" button in the search box, right? I presume real searches should still search. In that case, I'd strongly recommend #3. #1 is much harder to debug, and probably violates the [[principle of least astonishment]]. William -- William Pietri <william(a)scissor.com> http://en.wikipedia.org/wiki/User:William_Pietri

William Pietri schreef: That would be 1800 to 9000 redirects per page. The ten articles with the most redirects in the August database dump are, according to my count: 199 #REDIRECT [[Myrmica]] 200 #REDIRECT [[List of chess openings]] 212 #REDIRECT [[Enochian angels]] 221 #REDIRECT [[Main Page]] 230 #REDIRECT [[List of Hobbits]] 234 #REDIRECT [[List of Torres Strait Islands]] 281 #REDIRECT [[Consolidated Fund Act]] 287 #REDIRECT [[Appropriation Act]] 301 #REDIRECT [[Coalition military operations of the Iraq War]] 923 #REDIRECT [[Gospel of Matthew]] Most of these are lists, with redirects from the individual entries. These wouldn't benefit much from the new syntax. More interesting are [[Benny Benassi]] (191 redirects) and [[Tsentralny District]] (167 redirects). Eugene

On 24/10/2007, Steve Bennett <stevagewp(a)gmail.com> wrote: Redirects to lists for items not on lists is not uncommon - it usually means we've had the merger in the past and now that section's been wiped. Incidentally, many many redirects to a person can easily occur with authors - quite often, as a makeshift, book titles get redirected to their writer's article. Take a prolific author, add the four or five permutations for a book title, those can rack up fast... -- - Andrew Gray andrew.gray(a)dunelm.org.uk

On 10/23/07, Charlotte Webb <charlottethewebb(a)gmail.com> wrote: I don't think it's possible to say that without talking about a concrete implementation. I mentioned a possible data structure which allow a good tradeoff between size and speed. A partial solution, to eliminate the need for a large percentage of I've raised a very similar issue before. Basically, these three use cases are very different: - User types "least weasel" in the search box and presses "go" (MediaWiki attempts a couple of different capitalisations before giving up) - User directly types /wiki/least%20weasel (MediaWiki converts %20 to space, attempts to match, fails, then takes you to a page letting you search) - User follows a (red) link to [[least weasel]] - link actually goes directly to an edit page. Having consistent behaviour for these three would be great. This way if somebody links to "[[least weasel]]" mid-sentence (because There are problems with this approach. Should the link be red or blue? What if the capitalisation is blatantly wrong? How should a link to [[OATS]] be treated? As a mis-capitalisation for "Oats", or as a non-existent acronym OATS? It might be better to have the redlink return some search results by default, if they are highly pertinent (ie, extremely similar name), then show the "create a new page" screen. a redirect existed or not. For lesser known species where no redirect I really don't like the idea of respelling someone's edit without their knowledge. In my example above, they could really have meant to redlink to [[OATS]] and instead their wikitext is converted to [[Oats]] - very bad. Steve —C.W.