FS#12822 - Search in wiki bad.
Attached to Project:
Arch Linux
Opened by kongokris 2 (nut543) - Friday, 16 January 2009, 20:00 GMT
Last edited by Pierre Schmitz (Pierre) - Friday, 27 February 2009, 19:22 GMT
Opened by kongokris 2 (nut543) - Friday, 16 January 2009, 20:00 GMT
Last edited by Pierre Schmitz (Pierre) - Friday, 27 February 2009, 19:22 GMT
|
Details
For example when i search for "scan" i don't get the main
page for
http://wiki.archlinux.org/index.php/Scanner_setup_%26_configure
up except as linked from other pages the first result of
which i see as result 33...
I do get: http://wiki.archlinux.org/index.php/Scanning_tips and http://wiki.archlinux.org/index.php/USB_Scanner_Support But not before search-result 5 & 6 (!) Surely entries specifically about "scanning" need to take precedence to all the other entries? I see two possibilities (granted without knowing the system very well) here: 1. make entries with the titlename of which one is searching appear closer to the top 2. Implement tags or clarify for the user his ability to make tags so the search will get better.. I'm aware that it might be tempting to just suggest that the wiki should just be edited(all those articles merged to one called Scanning for example) and managed better but that would just be treating the symptom because there will always be users who doesn't bother or think to bother before they add to the wiki and there will always be admins/managers of the wiki(do we even have one?) which isn't uptodate with their work.. However if you got an other idea for implementation i'm all ears(google wasn't that much better as wikisearchengine). I sat severity to high since i think finding help is damn important... |
This task depends upon
Closed by Pierre Schmitz (Pierre)
Friday, 27 February 2009, 19:22 GMT
Reason for closing: Won't implement
Friday, 27 February 2009, 19:22 GMT
Reason for closing: Won't implement
Feel free to lead an initiative to get articles consolidated and renamed for ease of finding. In addition, cross-article links can help a lot sometimes.
<ekimmargni> hairball: There have been some recent upgrades to the searching, depending on what you use for that...
<Nikerabbit> hairball: 1) update 2) do 1) first
<ekimmargni> I think we use MWSearch
<Nikerabbit> if that doesn't help you could try lucene
If this bug entry can also hold as "Howto make wiki search better" perhaps the following can also help:
from the mediawiki faq:
…is a search for a short keyword giving no hits?
By default, MediaWiki uses MyISAM's fulltext matching functionality to allow searching page content. The default settings for this mean that words of less than four characters won't be indexed, so results won't be returned for those queries.
To alter this behaviour, MySQL needs to be reconfigured to index shorter terms, and MediaWiki's search index table needs to be repaired, to rebuild the indices.
* For help on reconfiguring MySQL, see http://dev.mysql.com/doc/refman/4.1/en/fulltext-fine-tuning.html
* To repair the search index table, run the query REPAIR TABLE searchindex QUICK; against your database
<ekimmargni> hairball: There have been some recent upgrades to the searching, depending on what you use for that...
<Nikerabbit> hairball: 1) update 2) do 1) first
<ekimmargni> I think we use MWSearch
<Nikerabbit> if that doesn't help you could try lucene
If this bug entry can also hold as "Howto make wiki search better" perhaps the following can also help:
from the mediawiki faq:
…is a search for a short keyword giving no hits?
By default, MediaWiki uses MyISAM's fulltext matching functionality to allow searching page content. The default settings for this mean that words of less than four characters won't be indexed, so results won't be returned for those queries.
To alter this behaviour, MySQL needs to be reconfigured to index shorter terms, and MediaWiki's search index table needs to be repaired, to rebuild the indices.
* For help on reconfiguring MySQL, see http://dev.mysql.com/doc/refman/4.1/en/fulltext-fine-tuning.html
* To repair the search index table, run the query REPAIR TABLE searchindex QUICK; against your database
I just tried google again and for the example in the bug description above and it's even worse than the internal search now..
there seems to be some light in the tunnel however. with the new mediawiki update it's a new option after you've searched which you can use to 'list pages that start with ... ' The problems are however
* it's case-sensitive, which isn't exactly obvious
* you have to make a search first to see this possibility
* it's visibility is low even when the option is on screen
and to top it off it's "hard" to "see" the queryresult when you've done all that..
see for yourself
I won't write another search backend for MediaWiki. This would take a lot of time and is everything but easy. Maybe you want to discuss this with the MediaWiki developers.
I agree with your sentiment that MW development is best left to their team, and anyone that thinks the search is that bad should try to raise the issue with them.
concrete things to do:
disable all of mediawiki's case-sensitivity: it's not clear that the reason your not getting a hit is because you forgot to CAPS your searchresult correctly. Even so, it's no way to know which way an articlewriter decided to cApS his article.
introduce the (all pages starting with "scan") (you know, the link you get *after* doing a search...) as a button under searchbox or atleast if that's not possible include it as a link under the searchbuttons.
http://www.mediawiki.org/wiki/Manual:FAQ
That leaves point nr.2 though which would also help a lot.