On 6/1/06, Steve Summit <scs(a)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