On 6/1/06, Steve Summit scs@eskimo.com wrote:
No good for accents, punctuation etc.
No? It tends to work for me -- must be a browser thing. (But I think I agree, the "Go" box ought to work just like the address bar.)
Heh, you're right - I never tried that. Firefox switches the accents back to %52 type notation.
Without looking, do you know whether "Bell Tower" is the same thing as "Bell tower"? (no, I don't either).
Well, the simplistic answer (but I would think the answer to go with) is that if they both exist they're different, but if not they're probably the same.
Maybe [[Bell Tower]] is a redirect to [[bell tower]]? I still haven't looked. :)
On the other hand, there are definitely cases where case should be more significant: I noticed today that someone had linked to [[foreland]], whereas [[Foreland]] came up.
But of course there, if nothing else, you're butting up against Wikipedia's special-casing (er, special uncasing) of the first character.
Yep.
You either have to unlink it entirely, link it and hope that someone will realise that they're not at the right article, or go to [[Foreland]] and add a red dablink (a very weird concept). All bad solutions.
I see what you mean, although I have to wonder if perhaps this is a problem that's not worth solving (law of diminishing returns, and all that).
I never said all of this was a *big* problem. Though it is one of those things that if it even affects 1 in 10,000 articles, that's 100 articles on the English Wikipedia...
Strictly speaking there are at least four cases: the search box when hitting "Go", the search box when hitting "Search", wikilinks, and incoming external links (or, equivalently, users typing directly into the address bar). At some point I want to sit down and map out exactly how these are the same and different, and exactly which sorts of fuzziness ought to apply where. (It's tempting to suggest that three out of the four ought to be identical in every respect, but there are enough weirdnesses lurking nearby that I'm not ready to make that assertion yet.)
Sounds good. I've previously expressed my frustration that "search" isn't even smart enough to return a direct match if it exists. The response given on this list was "use the go button". We could start by mapping out what kinds of fuzziness exist already.
There are also nuances depending on how likely it is that the user is searching for something that ought to exist, versus preparing to create something that doesn't exist. (This distinction is mostly aligned with wither the user is hitting the Noarticletext or Newarticletext page.) For example, if you map case too aggressively in the case where only one variant exists, you can make it impossible for anyone to ever create the other ones.
That's a good way of describing my original problem.
Well, when I go fishing in that way and get a false positive, it's always from the Go/Search box, and I just go back and hit Search instead of Go.
Oh, hadn't thought of that. Pleased to hear that Search's, uh, limitations, have a use. But the ramifications are a bit bizarre: "lyon metro" with Go button -> silent redirect "lyon metro" with Search button -> no match found, blue (!) link to "Lyon metro" which tells me that there's no article of this name, with another blue link to "Start the Lyon metro article". [[lyon metro]] in page text -> redlink to edit the page. http://en.wikipedia.org/wiki/Lyon_metro -> same effect as clicking the "Lyon metro" link in the Search case given just above.
Four different behaviours for the four different ways of trying to get to the same article with the same search text. Quite remarkable.
Steve