Last modified: 2006-07-12 21:56:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T8650, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 6650 - step 5 of the "go" button description doesn't seem to actually happen but would be quite useful
step 5 of the "go" button description doesn't seem to actually happen but wou...
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
unspecified
Macintosh Mac OS X 10.3
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/MediaW...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-12 13:58 UTC by Rick Block
Modified: 2006-07-12 21:56 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rick Block 2006-07-12 13:58:55 UTC
At the en: help desk, http://en.wikipedia.org/wiki/Wikipedia:Help_desk, one of the more frequently asked questions is "why can't 
I find my article" and the reason is often that the article is not found by steps 1-4 of the description of the go button (link to meta 
provided as reference URL).  Generally the issue is the title has a mixture of uppercase and lowercase initial letters, like http://
en.wikipedia.org/wiki/Norwich_City_player_of_the_year.  According to step 5 of what "go" does, if steps 1-4 don't result in a 
match it then does a case insensitive search (also matching partial page titles).  Perhaps the software might have done this in the 
past, but it doesn't now.  If this behavior could be restored, it would eliminate a fair amount of user confusion.  My general 
answer at the en: help desk is "create a redirect" (in this case either http://en.wikipedia.org/wiki/Norwich_city_player_of_the_year 
or http://en.wikipedia.org/wiki/Norwich_City_Player_Of_The_Year is sufficient), but if "go" could be changed to include what step 
5 says this would not be necessary.
Comment 1 Brion Vibber 2006-07-12 18:48:27 UTC
Fulltext search is case-insensitive. Note that the search 
engine may currently take up to several weeks to update for 
new articles.
Comment 2 Rick Block 2006-07-12 19:42:57 UTC
To clarify, this request has to do with "go", not "search".  I understand
"search" is case-insensitive.  "Go" is not.  If you read the description of what
"go" does (from the link provided above), it includes a step that does not
currently happen but perhaps did in some previous version.  If this "go"
behavior could be reintroduced, it would be helpful. 
Comment 3 Brion Vibber 2006-07-12 19:43:39 UTC
Go performs several case-sensitive checks, then runs search. 
It has never been any different.
Comment 4 Rick Block 2006-07-12 19:52:41 UTC
Would it be possible to add the check described as step 5 at
http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide:_The_Go_button, before
running search but after the case sensitive checks currently made? 
Specifically, the check is described as "try a case insensitive title search
that also matches partial page titles".  I'm less interested in partial page
title matches than the case insensitive search part if that makes a difference.  
Comment 5 Brion Vibber 2006-07-12 19:54:01 UTC
That's what the search does. It can't be run directly against the 
database because the fields are not case-insensitive.
Comment 6 Rick Block 2006-07-12 21:56:30 UTC
(sorry to be a pest about this - I promise this is the last comment) Even though the fields are currently case-sensitive can't 
they have a case-insensitive index - either as a secondary index (I don't know if the DB supports multiple indices to the 
same records) or with a duplicate case-insensitive record?  If neither of these are feasible, I'll update the description at meta 
(and en:) about how "go" works (I'll delete step 5, since the next thing it does is simply "search") and continue 
recommending folks add a redirect as a workaround. 

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links