Page MenuHomePhabricator
Search Advanced Search

Advanced Search
Use Results
Hide Query

Use the application-specific Advanced Search to set additional search criteria: Tasks, Commits. (More information)
  • T94830: Track down missing regex search results on commons
    • Task
    https://www.mediawiki.org/wiki/Thread:Help_talk:CirrusSearch/Incomplete_search_results_%282%29 When searching for insource:/\{\{Information.*\{\{Information/i we don't get a page with the information template twice, https://commons.wikimedia.org/wiki/File:YAMAHA_%28headquarters_1%29.jpg
  • T93075: MediaWiki search result should render full math tags
    • Task
    For example https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=insource%3A%2F\\reals%2F&fulltext=Search should render the math tags in the result list.
  • T92477: Get open search results as an rss feed
    • Task
    We installed the opensearchxml extension onto our mediawiki version 1.19.2 hoping we could return search query results in rss/atom format to be used by other organisations who need them in thins format. This appears to be a fundamental aspect of Open Search that is missing from the extension. Is there any way around this?
  • T91975: clarify the message shown when an exact search query wasn't found
    • Task
    The English Wikipedia doesn't have the article "Arun Ganesh". When I search for it, I get the following message on top of the results: You may create the page "Arun Ganesh", but consider checking the search results below to see whether the topic is already covered. ("Arun Ganesh" is a red link.) This is technically correct, but a bit too immediate. Experienced users know that clicking the red link will take them to creating the new article. But the inexperienced users don't quite understand what happened. The current message doesn't seem to be very good neither at clarifying that an article with this title doesn't exist nor at inviting a user to create an article. It does say "You may create the page", but from observing inexperienced users for years my impression that it they don't understand this message. Also, this appears after 29 checkboxes for namespace selection, which seems to me to complicate things much further. Here are some proposed solutions: - Clarify that an article with this title wasn't found and the results further down (if there are any) are articles in which the search query was found. - Clarify that the user can create a new article if no results are relevant. (Yes, the current message says this already, but as I said, my impression is that it's far from perfect.) - Redesign the namespace selector in a way that will take into account that most Wikipedia don't need any namespaces except the main one, but experienced users and especially editors do need it. - [ Shameless plug for a product that I am developing: ] Something like the "New contributions" button from the ContentTranslation extension can be here. This is just a start of a proposal. The implementation will require professional design and user testing. The goals are supposed to be: - Helping the readers to get to the article - more clickthrough to results would be a success. - Converting readers to editors - more articles are created by new users and not speedily deleted would be a success. (See T91973 for a somewhat related issue in the Android app.)
  • T91926: Search: Namespaces to be searched by default should not be the same as "content pages"
    • Task
    $wgNamespacesToBeSearchedDefault defines which namespaces are searched by default. It is also uses as NS array for the "content pages" tab. That's misleading. In $wgNamespacesToBeSearchedDefault I define content namespaces (text) and other useful ns like FILE and TALK. Under the "content pages" tab I expect $wgContentNamespaces. Also the tab has at least 3 different names in the code (content, dfeault, articles). Best might be to * In the code rename "articles" and "default" for the "Content pages" tab to "content" > Use $wgContentNamespaces * Add a new tab "Default" > Use $wgNamespacesToBeSearchedDefault
  • T89151: SearchHighlighter::highlightText() should not be checking if Cite is installed
    • Task
    ``` // @todo FIXME: This should prolly be a hook or something // instead of hardcoding the name of the Cite extension if ( \ExtensionRegistry::getInstance()->isLoaded( 'Cite' ) ) { $spat .= '|(<ref>)'; // references via cite extension $endPatterns[4] = '/(<ref>)|(<\/ref>)/'; } ```
  • T87606: ApiQuerySearch: Allow searching title AND text together
    • Task
    Allow ApiQuerySearch searching title AND text together so the 2 queries result it 1 list.
  • T87548: Full text search needs to split words on dashes
    • Task
    Searching for Sapulpa-Beggs should find "U.S. Route 75 Alternate (Beggs–Sapulpa, Oklahoma)". Without splitting words on dashes it has no chance.
  • T86854: Better handle natural language questions in search
    • Task
    Could we leverage search referer queries as metadata on pages as a way of improving natural language queries on our own site? compare https://www.google.com/?gws_rd=ssl#q=who+is+albert+einstein to https://en.wikipedia.org/w/index.php?search=who+is+albert+einstein%3F&title=Special%3ASearch&go=Go If "who is albert einstein?" as metadata could be stored on the article for albert einstein so that it that natural language search query would result in albert einstein being the top result.
  • T85770: multi term search does not return expected results
    • Task
    The query for "us car production" nor "us auto production" does not result this page as expected: http://en.wikipedia.org/wiki/U.S._Automobile_Production_Figures Exact queries (from URL): https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=us+auto+production&fulltext=Search https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=us+car+production&fulltext=Search Ticket was prompted by Tweet (https://twitter.com/asymco/status/551788812888965120)
  • T85597: SpecialSearchResults hook, num/total counts aren't adjusted after hook execution
    • Task
    As of [0] it is possible to apply post-filtering on $titleMatches/textMatches (using the SpecialSearchResults hook) but unfortunately after the [1] hook is called the "textMatchesNum", "numTextMatches", "titleMatchesNum", "numTitleMatches", and "num" aren't adjusted and therefore can lead to misinterpretation of the result display (e.g. prevnext is displayed even though the post filter has removed all matches from $titleMatches/textMatches or some SearchResult has been removed during the hook call therefore the total count number no longer add up etc.). [0] https://github.com/wikimedia/mediawiki/commit/421a7f1175dda6f75ec4efba44e320c49e94d117 [1] https://github.com/wikimedia/mediawiki/blob/96dd55fde17f13f61060c5786ef4076742af9272/includes/specials/SpecialSearch.php#L368
  • T84856: Searching for "File:" shows no results, yet a result count is shown
    • Task
    On <https://commons.wikimedia.org/w/index.php?search=File%3A&title=Special%3ASearch&fulltext=1>, "Results 1 - 20 of 23,135,741" is shown, though the 20 results that are supposed to be on the page are not there. It turns out that SpecialSearch does the following check: ``` $filePrefix = $wgContLang->getFormattedNsText( NS_FILE ) . ':'; if ( trim( $term ) === '' || $filePrefix === trim( $term ) ) { // Empty query -- straight view of search form return; } ``` The `$filePrefix` part of this was added in <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/44252>, though it's unclear why. However, it is not present in the SearchEngine classes, and SpecialSearch performs the "search" even when it is not going to show the results.
  • T78485: At Vietnamese wikis, Special:Search should not redirect based on case-folding
    • Task
    At the Vietnamese Wiktionary, searching for “[trường hộp](https://vi.wiktionary.org/wiki/Special:Search/trường_hộp)” redirects to “[trường hợp](https://vi.wiktionary.org/wiki/trường_hợp)”, which is incorrect and potentially confusing to readers (because they might not notice the circumflex being replaced by a horn). At Vietnamese wikis, the search engine should perform case folding only for search suggestions, results, and Did You Mean; it should never redirect the user to a page that only matches due to case-folding. (There is one case where this behavior is useful: things like “xóa” and “xoá” are interchangeable. But we already have redirect pages for all these cases.) The impact on Vietnamese wikis is high because most words have completely unrelated lookalikes when ignoring diacritics.
  • T76363: [Task] add hook to SpecialAllPages to allow batch lookups for title link formatting
    • Task
    SpecialAllPages could use a hook, similar to ChangesListInitRows, to allow extensions doing customized formatting in the Linker hooks (onLinkBegin) to do prefetched lookups before rendering each link. this would be helpful, for example, for formatting Wikibase titles with labels instead of ids (Q42 or whatnot).
  • T75862: Update and/or enable custom entries for Hebmorph dictionary
    • Task
    The original specific description is below, but the required solution is much more general: we would need to find a way to upgrade the [HebMorph](https://github.com/synhershko/HebMorph) dictionary to a newer version of [Hspell](http://hspell.ivrix.org.il/) and/or be able to add custom entries to the dictionary. _____ In the Hebrew language the prepositions and the conjunctions are usually prefixed to the beginning of the word. For example, "טריפלקס" means "triplex" and "וטריפלקס" means "and triplex". The letter "ו" was added in the beginning. Ideally, the search engine should be smart enough to know about morphology and understand that "טריפלקס" should also yield results with "וטריפלקס". The situation with Arabic is very similar, and possibly there are more such languages.
  • T73977: Search: Ignore namespace prefix and truncate left
    • Task
    "bar" should suggest * Foo Bar * Extension:Bars * Help:Foo baring -------------------------- **Version**: unspecified **Severity**: enhancement
  • T73976: Search suggest: Prioritize namespaces
    • Task
    Once the multiple namesspaces are enabled from T26214, it would be good if namespaces could be priorized. Example: On my wiki categories are more important as articles. So I'd like to give categories a higher prio on the suggestions. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T72899: Search box needs some normalization for Arabic Family languages
    • Task
    We have some langues such as Arabic, Persian, Urdu, Kurdish,... which uses common characters and they have similar geliphs with different Unicode number for example: for ک (Kaf) ك Arabic U+0643 ڪ Urdu U+06AA ﻙ Pushtu U+FED9 ﻚ Uyghur U+FEDA ک Persian U+06A9 for ی (ya) ی Persian U+06CC ي Arabic U+064A ى Urdu U+0649 ۍ Pushtu U+06CD ې Uyghur U+06D0 for ه (heh) ہ Pushtu U+06C1 ە Kurdish U+06D5 ه Persian U+0647 we have these characters which have different Unicode number and different keyboard. Now many users does not access to Persian keyboard or urdu keyboard by default in their OS (like windows xp, android (low versions), IOS ,...). so when they search for an article they can not find it in wikipedia searach box but it is existing in local characters. For example if you search at fa.wikipedia for article ويليام شكسپير (characters are in Arabic ي , ك) you can not find it and the article in Farsi is ویلیام شکسپیر (characters are in Persian ی , ک). for farsi please add a possibility for search tool to assume U+064A or U+0649 or U+06CD or U+06D0 or U+06CC > U+06CC U+0643 or U+06AA or U+FED9 or U+FEDA > U+06A9 U+06C1 or U+06D5 > U+0647 -------------------------- **Version**: unspecified **Severity**: enhancement
  • T71063: AJAX search suggestion shows non-existent page "Meta:Speedy Deletions" on meta.wikimedia.org
    • Task
    **Author:** `KilliondudeWP` **Description:** To reproduce: 1) Go to meta.wikimedia.org 2) Type in "Meta:Speedy" into the search bar 3) Note that "Meta:Speedy Deletions" is suggested The suggested target page does not exist nor is there record of it having existed. See screenshots: http://imgur.com/a/irWIg -------------------------- **Version**: 1.24rc **Severity**: minor
  • T69920: Database Error when searching for term which includes parenthesis characters
    • Task
    **Author:** `asokratis` **Description:** searching on the wiki with characters such as ")" or "(" (maybe there are more?) will show a page with the following: Database Error. A database query error has occurred. This may indicate a bug in the software. Examples of Search: test) test( If a ticket for this has already been open, please close this ticket and refer to me where the issue so I can be monitoring it. -------------------------- **Version**: 1.23.1 **Severity**: normal
  • T69914: SearchResult is bad for adding properties
    • Task
    Adding new attributes to SearchResult and subclasses is a royal pain in the ass. Special:Search has to be screwed around with to handle this metadata in some UI way. So this bug is two things. Clean up SearchResult to have a useful way of returning $randomMetadata and a way to display it. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T69702: If a filename begins with a capital letter, filelist search fails
    • Task
    **Author:** `atlantonius` **Description:** in 1.22, if a filename begins with a capital letter, searching fails if your search criteria includes the capital letter. If you omit the first character, it works fine. I found this to be because of the following line in /includes/special/SpecialListfiles.php, Line 138: $conds[] = 'LOWER(' . $prefix . '_name)' . If this is changed to the following, you can now search using a capital letter: $conds[] = 'CONVERT(' . $prefix . '_name USING latin1)' . Originally found by Fereal in a previous version, I simply adopted their solution for the new function in 1.22. Link to that discussion below: http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Search_function_in_File_list_doesn't_work_properly -------------------------- **Version**: 1.22.0 **Severity**: normal **OS**: Linux **URL**: http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Search_function_in_File_list_doesn't_work_properly
  • T69250: Special:PrefixIndex should return a count of results.
    • Task
    The request is for Special:PrefixIndex to return a count of the number of pages it finds and is able to return that number through the API and the magic word... The special page should show "Showing results 1-50 of 115" so people can see how many (sub-)pages there are with this prefix. This would allow for something like: {{#ifexpr:{{Special:PrefixIndex/Wikipedia:Requests for adminship/User:Example|count=yes}}>1|[{{fullurl:Special:PrefixIndex|prefix=Requests+for+adminship%2FUser:Example&namespace=4}} RfAs]}} to only show the link if there are actually results. So, this number should be available to access through the magic word and the API as well. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T69234: PowerSearchBox stopped respecting custom search namespace names from SearchableNamespaces hook
    • Task
    **Author:** `jlemley` **Description:** PowerSearchBox stopped respecting custom search namespace names from the SearchableNamespaces hook. This change happened between 1.21 and 1.23. In SpecialSearch.php, the powerSearchBox function changed this line: $name = str_replace( '_', ' ', $name ); to $name = $wgContLang->getConverter()->convertNamespace( $namespace ); The SearchableNamespaces hook allows the searchable namespaces array to be identified as: $arr[ns] => $name However, the new code in powerSearchBox ignores the ability to use custom names from this hook, and forces only the system names to be used. -------------------------- **Version**: 1.23.0 **Severity**: normal
  • T68570: Default MediaWiki search engine does not specify if a page is redirect
    • Task
    Blah is a redirect page When i search for a redirect page in MediaWiki 1.24wmf9 should the search result show that the page is a redirect? Also, should it be classified as something else other than a content page? -------------------------- **Version**: 1.24rc **Severity**: minor **Attached**: {F14075}
  • T68342: Make "Remember selection for future searches" checkbox prettier
    • Task
    The "Remember selection for future searches" checkbox in the advanced search tab is on its own line (div) below the slate of namespace checkboxes. Originally I wanted it to be next to the "header" of the namespace selection, possibly next to the All / None buttons added via JavaScript, but there may be other prettier options. (In reply to Quiddity from bug 52817 comment 40) > I think the problem with the new version, is the physical distance, or > dis-connection, of the checkbox from the search button... This is true of all the namespace checkboxes and tabs; on a wiki with several namespaces, and/or a small screen, they can take the entire screen space, making the search results not visible. A separate bug should probably be filed for that. -------------------------- **Version**: 1.24rc **Severity**: enhancement
  • T67753: Provide way to override the behavior of default search box
    • Task
    I can't find any non-ugly way to alter the default search box suggestion functionality. I would like to change the namespaces and change rendering format a bit. I checked how Wikidata does their thing, but even they override the whole search box with their own one. -------------------------- **Version**: 1.24rc **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=24214
  • T65975: Search results do not respect DISPLAYTITLE
    • Task
    1. Go to en.wikipedia.org 2. Search for 'iO' Expected: Top result is displayed as 'iOS' Seen: Displayed as 'IOS'. This is set with {{DISPLAYTITLE:iOS}} in the page, and should probably show up here the same way. -------------------------- **Version**: 1.23.0 **Severity**: normal
  • T65852: When the search term is an interwiki link, the "Go" suggestion is missing
    • Task
    Go to e.g. https://www.mediawiki.org/wiki/Search?useskin=vector&uselang=en and type "en:Test". The only suggestion displayed will be "containing... en:Test". There should be also a bold suggestion to go directly to en:Test. Indeed, if I click in the "containing... en:Test" I'm redirected to https://www.mediawiki.org/w/index.php?search=en%3ATest&title=Special%3ASearch&go=Go&fulltext=1 where there is a message saying There is a page named "en:Test" on this wiki. See also the other search results found. -------------------------- **Version**: unspecified **Severity**: normal
  • T65764: Strip surrounding quotation marks from search parameters before testing for page existence.
    • Task
    **Author:** @capmo **Description:** Searching for "foo bar" (with the quotation marks) results in a suggestion to «Create the page ""foo bar"" on this wiki!» which, if followed, leads to the creation of a page with the title [["foo bar"]]. This message appears EVEN if the page [[Foo bar]] already exists. Although this behavior is occasionally desirable (in those very few situations in which the quotation marks should indeed be part of the title), I'd say that in 99% of the times it's not. Most people search with quotation marks in order to narrow down search results, and the average wiki user would not expect them to become part of the title of a newly created article. Even experienced users end up creating new articles with the suggested title and only later realize it (I've done it a couple of times myself). The large list of redirects starting with double quotes on the enwiki attests to the high frequency of occurrences of this situation: http://en.wikipedia.org/w/index.php?title=Special%3APrefixIndex&prefix=" My suggestions: 1) If a page does not exist with the quotes, check if one exists without the quotes; 2) In affirmative case, display message «There is a page named "Foo bar" on this wiki!» ([[MediaWiki:Searchmenu-exists]]) 3) In negative case, display [[MediaWiki:Searchmenu-new]] without the inner pair of quotation marks around the searched term or expression. If a person really needs to create an article titled [["foo bar"]], s/he can still do it by typing the quotation marks in the URL or by following the red link to [["foo bar"]] in an article. This would greatly improve the user experience with the search functionality. -------------------------- **Version**: unspecified **Severity**: normal
  • T65629: Allow adding wiki logos to interwiki search results boxes
    • Task
    Example screenshot of it.wiki search Request from it.wiki: allow wikis to specify a logo/icon for each interwiki prefix. <https://it.wikipedia.org/w/index.php?title=Wikipedia:Bar/Discussioni/Lanciamoci_nel_futuro_motore_di_ricerca_interno&diff=65143693&oldid=65127666> I'm not sure what's a way that could scale. Just add image markup to the system message(s) "locally", i.e. on WikimediaMessages for Wikimedia wikis? Add the feature once said system message is split as discussed in https://gerrit.wikimedia.org/r/#/c/121910/2/i18n/wikimedia/en.json,cm ? -------------------------- **Version**: 1.23.0 **Severity**: enhancement **Attached**: {F13940}
  • T62976: Prefix Search: Would be nice if search engine could highlight the result rather than js
    • Task
    Sometimes we see weird results in the prefix search because Cirrus uses different matching rules then the jquery.suggestions library. In English, for example, Cirrus flattens high ascii. Searching for "resume" will return "résumé". Cirrus is quite capable of highlighting the result properly, but it has no way to tell the front-end what the result should look like. I don't believe it would be practical to replicate Cirrus's logic on the front end because it can change and it is different for different wikis.
  • T61627: incomplete search results for phrase enclosed in double quotes
    • Task
    **Author:** `rybec` **Description:** screen capture of incomplete results page I noticed this today on the English Wikipedia. I searched for "April 22, 2003", enclosed in double quotes (as documented in the Help:Searching page on that site). The search results show only two pages: https://en.wikipedia.org/wiki/Penn_State_Abington --where the phrase appears in a caption--and https://en.wikipedia.org/wiki/Eastern_Michigan_University_Department_of_Special_Education which contains the phrase in a reference. When I search without the double quotes, https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=all&search=April+22%2C+2003&fulltext=Search the results page informs me that "There is a page named "April 22, 2003" on Wikipedia" and shows other pages containing the phrase: https://en.wikipedia.org/wiki/April_2003 https://en.wikipedia.org/wiki/Felice_and_Boudleaux_Bryant https://en.wikipedia.org/wiki/Martha_Griffiths https://en.wikipedia.org/wiki/Andrea_King https://en.wikipedia.org/wiki/143622_Robertbloch https://en.wikipedia.org/wiki/Rendezvous_in_New_York https://en.wikipedia.org/wiki/John_Paluck https://en.wikipedia.org/wiki/Sick_of_Modern_Art etc. The site says it's running version 1.23wmf8. -------------------------- **Version**: 1.23.0 **Severity**: normal **URL**: https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=all&search=%22April+22%2C+2003%22&fulltext=Search **Attached**: {F12031}
  • T61082: Searching for userpages of nonexistent users (or users with no userpage) should not forward you to their userpage with &go=Go
    • Task
    For example, [[Special:Search/User:global.js]] should return results like [1], not forward the searcher to a nonexistent page for a nonexistent user. [1] https://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=user%3Aglobal.js&fulltext=Search -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=45255 https://bugzilla.wikimedia.org/show_bug.cgi?id=46491
  • T60698: Enable fulltext search in edit summaries (and logs)
    • Task
    The search engines should enable to scan texts of edit summaries and some types of logs (page deletion etc.). (Sub-request split out into {T137762}) ---- (Merged duplicate description) I would like to be able to get a list of all edits made with a specific editsummary (but not limited to one specific editor, like [[http://tools.wmflabs.org/jackbot/snottywong/commentsearch.html|this tool]]). -- The Quixotic Potato (talk) 06:41, 29 September 2015 (UTC) This card tracks a proposal from the 2015 Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey This proposal received 30 support votes, and was ranked #33 out of 107 proposals. https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Search#Search_editsummaries
  • T58830: Provide API access for search terms which do not yield title or fulltext results
    • Task
    Allow api access for list of terms which do not yield matches in as article titles or full text queries as a means of coming up with content which is looked for but not found. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=3437
  • T58604: Add checkbox to Special:AllPages to hide pages lacking page summaries
    • Task
    Add checkbox to Special:AllPages to hide pages lacking page summaries. A few possible implementations: (1) hardcode this feature into SpecialAllPages.php, perhaps with a configuration setting turning the feature on or off; (2) add hooks to SpecialAllPages.php allowing additional Xml labels, GET values, SpecialAllPages::showChunk() SELECT conditions, etc. to be added by extensions; or (3) create an entirely new special page, extending the SpecialAllPages class, with the desired functionality. The goal is to enable page metadata extensions (e.g. Extension:BedellPenDragon) to add more options to AllPages. Options #1 and #2 above could reduce the amount of code duplication. -------------------------- **Version**: 1.23.0 **Severity**: enhancement
  • T56836: Redirect pages with all-uppercase words don't get picked up when searching in lowercase
    • Task
    If a page contains an all-uppercase "word" and is a redirect, the search Go function will not take you to the redirect page if you search in lowercase. For example, say the page "Test ONE" redirects to the Main Page. Searching "test one" and using Go will not catch the redirect, it will take you to the search results page. If the page is NOT a redirect page, then it works as it should. If you search "test one" and "Test ONE" exists as a non-redirect, you will be taken to the page. It should be noted that the opposite situation works fine. If a redirect page is called "Test one" and you search for "test ONE", the redirect will catch like normal. So there is a very specific case where it does not work that should be fixed. -------------------------- **Version**: 1.22.0 **Severity**: normal
  • T54213: Add way to simplesearch for adding multiple "containing..." style blocks.
    • Task
    We currently have: "Containing..." in the search drop down. I think it would be a good idea to be able to add additional block(s) there. Primary function that I have in mind would be to add a: "Search Wikipedia Help" Apparently people have a lot of trouble actually "searching" our help pages. They don't easily arrive at the "advanced" tab of the search page, they miss the "Help" link in the toolbar etc.. I think it is crucially to provide proper search ability of our Help and guidelines pages and this might help. -------------------------- **Version**: 1.22.0 **Severity**: enhancement
  • T51466: Display category list for items in search results
    • Task
    **Author:** `paul.boal` **Description:** Mock up showing the category list for this search result. When search results are displayed, it would be very helpful to have category information displayed as part of each result. This will give the viewer information, at a glance, about what type of page each search result is. The recommendation is to put that information in brackets on the line showing KB/words and last revision date. Mock-up shown in attachment. -------------------------- **Version**: 1.22.0 **Severity**: enhancement **Attached**: {F11000}
  • T50246: Special:PrefixIndex's input field should support autocompletion
    • Task
    Special:PrefixIndex's input field ("Display pages with prefix") should support autocompletion. -------------------------- **Version**: 1.22.0 **Severity**: enhancement
  • T42821: PostgreSQL searches do not treat Unicode full width characters as their normal counterparts
    • Task
    The search engines for MySQL and SQLite treat "ＡＺ" (that's #xff21 and #xff3a) as "AZ" (cf. [[Halfwidth and fullwidth forms]]), PostgreSQL does not and thus fails testFullWidth(). One idea would be to TRANSLATE() them in ts2_page_text() and ts2_page_title() and use a similar technique in SearchPostgres::parseQuery(). If so, we need to describe in the release notes how to regenerate the tsvectors after an update or detect if ts2_page_text() or ts2_page_title() has changed and then regenerate them ourselves (I prefer the former). Of course, another imaginable approach would be try to push this normalization into a text search configuration for to_tsvector(), but I don't know whether this is even possible. -------------------------- **Version**: 1.21.x **Severity**: enhancement
  • T41456: Searchmenu-* messages are given $1 HTML-encoded, unable to urlencode it
    • Task
    “searchmenu-*” messages (e.g. searchmenu-exists) are given the searched title in $1, so that they display something like “There is a page named "[[:$1]]" on this wiki.” However SpecialSearch::showCreateLink() escapes the search query using wfEscapeWikiText. This means e.g. quotes are escaped as HTML entities when received in searchmenu-new, and you are unable to use the original query in links (e.g. to search in other namespaces) in the message, like “[{{fullurl:Special:Search|search={{urlencode:$1}}&ns14=1&fulltext=Search&advanced=1}} Search categories]” since the urlencode leads to the HTML-encoded quote in the URL (and OTOH, omitting the urlencode would break queries containing e.g. an ampersand). See https://commons.wikimedia.org/wiki/MediaWiki_talk:Searchmenu-new#Quotes_get_destroyed Maybe we could have an alternate parameter $2 containing the original unencoded query? -------------------------- **Version**: unspecified **Severity**: minor
  • T40395: It should be possible to choose the default search (tab/profile) on Special:Search
    • Task
    For instance on translatewiki.net most users will actually want to look for translations only, but it's hard to find the feature. <https://translatewiki.net/wiki/Thread:Support/New_search_features> -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: https://translatewiki.net/w/i.php?title=Special:Search&search=&fulltext=Ricerca&profile=translation&redirs=1 **See Also**: {T24774} {T30660} {T23988}
  • T40121: Special pages titles suggestions in search come from fallback languages too
    • Task
    Copied from http://translatewiki.net/wiki/Thread:Support/Fallback_language. Long time ago I noticed that in Galician (gl) projects when you start typing the name of a special page in the search box you get both suggestions of Galician names and Portuguese (pt) names, as it is our fallback language. However, even when special pages names are translated is it really necessary to have the other ones as suggestions? I think that native and English versions are enough as suggestions. [...] I don't know if this happens in other languages. I think that having such suggestions from fallback language is completely redundant and irrelevant. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T39223: Add ability to restrict number of search terms
    • Task
    **Author:** `afeldman` **Description:** Steps to reproduce: 1. Go to [[ https://www.mediawiki.org/wiki/MediaWiki | MediaWiki ]] 2. In the upper right corner, click on the search field. 3. Make a search query with a string so long that the whole search URL has a length of 8912 bytes. I. Observed: The search will be accepted. This shows that no regulation is applied, just the standard URL length regulation of Apache exists which does not process URLs longer than 8912 bytes. II. Expected: Bots frequently submit huge spam documents as search queries. In order to limit system impact, there should be a config option to set the maximum number of terms used in a search. Terms > than that should be stripped off transparently. -------------------------- **Version**: 1.20.x **Severity**: normal
  • T39197: Filter out invisible characters from search string
    • Task
    **Author:** `harriv+mwbz` **Description:** Invisible characters included in search string should be filtered out. When copy-pasting search term other sources, it can include invisible characters (eg. soft hyphen). If such characters are included in search string, seach will currently fail. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T38332: The searchdisabled message does not work with custom styling (at least not directly)
    • Task
    As tested on the Beta cluster (verified on en and simple), when I attempted a search, I get the exact content of the [[MediaWiki:searchdisabled]] source, not how it should be rendered. I tried some modifications, including using ":" to indent, but that failed as well. -------------------------- **Version**: unspecified **Severity**: normal
  • T38159: For category search results, provide an image preview
    • Task
    **Author:** `rd232` **Description:** Category search results would be more useful if each category was provided along with an image thumbnail preview. The image could be the first one in the category, chosen at random from the category, or there could be some way to specify the preview within the category page (eg a magicword). There may even be space for several images - 3-5 say. -------------------------- **Version**: 1.23.0 **Severity**: enhancement
  • T37636: User profile search
    • Task
    I propose a search system, where user's could be searched based on the combination of their user templates and babel. E.g. I live in UK and speak Gujarati, Hindi and English. Someone searchin Hindi speakers in UK, could easily find me out and contact me. This is because, I am thinking to start indic wiki meetups in UK, and looking for the users speaking Indic languages and contributing to wiki. But there is now way today I could know who is an indic wikipedian in UK. If such facility is made available, tasks like mine can be very easy. -------------------------- **Version**: 1.21.x **Severity**: enhancement
  • T37043: PostgreSQL: "syntax error in tsquery" when search term contains apostrophes
    • Task
    **Author:** `roberthend15` **Description:** I found a SQL injection in the search form. If you enter a single quote into the form the postgreSQL server respond with the following error: Warning: pg_query(): Query failed: ERROR: syntax error in tsquery: "'" in <FULLPATH>\DatabasePostgres.php on line 584 Sorry, that was not a valid search string. Please go back and try again Wich means the server is vulrnable to an SQL injection. Reproduce: 1. go to the main wiki page 2. Enter the single quote into the search form Shortcut to the bug: https://wiki.<WEBSITE-NAME>.org/en/Special:Search?search=%27&go=Go Note that the %27 is the single quote character ! Originaly found at: https://wiki.mageia.org/en/Special:Search?search=%27&go=Go (Already told them about this) Robert Hendriks -------------------------- **Version**: 1.20.x **Severity**: normal **Platform**: PC
  • T36468: Show links to create a page and a link to Special:PrefixIndex if search is disabled
    • Task
    On normal search pages there are the messages searchmenu-new / searchmenu-new-nocreate to show a link to create the page, and searchmenu-prefix with a link to Special:PrefixIndex. Both these messages are missing when the search is disabled, though they are useful in this case, too. -------------------------- **Version**: 1.19 **Severity**: enhancement **URL**: http://en.wikipedia.beta.wmflabs.org/w/index.php?search=asdf&title=Special%3ASearch
  • T36255: MySQL search for titles without Lucene does not find filenames
    • Task
    In the default search (MySQL search without Lucene) 'foo' doesn't find "File:Foo.jpg" (only 'foo*' or 'foo.jpg' does). But 'bar' finds "File:Foo Bar Baz.jpg". Is there a solution for this? Don't say users should truncate, the search should find it ;) -------------------------- **Version**: unspecified **Severity**: normal
  • T35488: Defining namespaces in SearchableNamespaces is double work
    • Task
    The SearchableNamespaces hook http://www.mediawiki.org/wiki/Manual:Hooks/SearchableNamespaces requires double work: array( NS_MAIN => 'Haupt', NS_USER => 'Benutzer', ... NS_CUSTOM => 'Custom', ... } That's redicilus. Better would be array(0, 1, ..., 100, ...) -------------------------- **Version**: unspecified **Severity**: enhancement
  • T33697: in languages where the "User:" space has more than one gender flavor, autocomplete suggests pages from user space even before user types ":"
    • Task
    Autocomplete functionality is supposed to show only pages from article space (namespace 0), at least until one enters the first ":". In Hebrew, when you type in "משתמ" (the first 4 character of the localized word for "User"), autocomplete suggests pages in user page, and shows only pages in the user space of users who have set their gender to "Female" in preferences. IOW, users whose "User:" translates to "משתמשת:" rather than the "standard", which is "משתמש:". -------------------------- **Version**: 1.21.x **Severity**: normal **See Also**: https://rt.wikimedia.org/Ticket/Display.html?id=2160
  • T32954: mwsuggest should support a .mw-search classname instead of hardcoded ids
    • Task
    Currently mwsearch only supports the ids #searchform, #searchform2, #powersearch, and #search. We should update mwsearch to use jQuery and add support for a .mw-search class name on the form to indicate a search form intended to search the wiki instead of requiring that custom skins use these hardcoded ids. mwsearch looks a little big for me to just pickup and convert. It's also fairly focused around id's so it doesn't look easy to just convert to using a class without going ahead and converting most of it to jQuery. Also, instead of hardcoding the ids of search inputs we should be using <code>$( theForm ).find(':input[name="search"]')</code> to fetch the search input. -------------------------- **Version**: 1.20.x **Severity**: normal
  • T32855: Option to list Special:Prefixindex top to bottom instead of left to right
    • Task
    Personally I dislike the left to right listing on Special:Prefixindex. Mostly because the eye wants to scan lists from top bottom (like on category pages), esp. on prefix lists... not to mention wide monitors... I don't want to discuss what's better, but MW shopuld offer an option to set the direction and maybe even the number of columns. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T32754: Use correct sorting for in prefix searches
    • Task
    Once the system is in place ({T32673}), we should start figuring out a way to use the collations. This one is a reminder to use it in the PrefixIndex system (used on Special:PrefixIndex as well is in ApiOpenSearch and perhaps other APIs supporting "things" by prefix (user contributions ?) -------------------------- **Version**: unspecified **Severity**: minor
  • T32229: Allow extensions to append stuff to search queries, e.g. for search by prefix
    • Task
    It should be possible to somehow search by prefix through the search box. It's possible through inputbox. (Note that this is only possible in Lucene search, but that is used on WMF wikis anyway.) It would be extremely useful for Incubator to be able to search within a specific test wiki. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T32060: Search page should offer choice of namespaces in a more ranked fashion
    • Task
    On advanced search (and perhaps other places) all namespaces are listed without regard to their relative prominence within the wiki. Users get frustrated when they search through a lengthy list of namespaces many of which are devoid of content. Suggestion is to have several lists, eg "Content namespaces", "Top-10 namespaces", "Talk namespaces", "Other namespaces". It'd be great if the namespaces listed in "Content namespaces" would match the wiki-specific configuration per $wgContentNamespaces, and the "Top-10" namespaces were ones rank ordered by their size or popularity statistics. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T31890: Cannot search for parser functions (like #ask, #ifexist, etc) due to #
    • Task
    I don't know anything about this bug other than I've never been able to search for a hash tag on any mediawiki-based site. Semantic mediawiki, and related extensions, make extensive use of hash tags and search for documentation of them is virtually impossible if the keyword part of it is not something fairly unique like "arraymap" (for #arraymap). Searching for one like "ask" (for #ask) just can't be done due to the number of false hits. -------------------------- **Version**: 1.21.x **Severity**: enhancement
  • T31532: Increase search functionality of Special:Listusers & site logs by allowing wildcard searches
    • Task
    **Author:** `thor.malmjursson` **Description:** I'd like to request an enhancement to searches on parts of MW software, as noted in the bug title - what I'm essentially looking for, is the ability to search for users (either already registered or in Special:Log/newusers) whose usernames contain specific words. This could be accomplished by using wildcard searches based on existing REGEX signs, for example - *sheep* to search for any users containing the word "sheep". Other wildcards could have functionality within the searches too, it's purely to widen the scope of available searches when looking for specific things, such as socks (which I often do, patrolling the user creation log). Thoughts and comments welcomed. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T30660: SpecialSearchProfiles hooks is not documented well enough
    • Task
    The array format is not documented. Should probably be assigned to Werdna who added the hook. -------------------------- **Version**: 1.18.x **Severity**: minor **See Also**: {T40395}
  • T30110: Search suggestions don't include thread namespace for suggestions in thread namespace (when using LQT)
    • Task
    Some search suggestions I got on enwikinews: :Comments:Curfew imposed in Jammu and Kashmir, three injured and four killed/Comments from feedback form - "security men? i think u mean p..." :Comments:Hong Kong 'tutor king' applies for bankruptcy/Comments from feedback form - "nice.." They should be prefixed with Thread. I got these when I started typing Comments into the search box (So really its questionable if thread namespace things should show up at all). If I start typing thread into the box, I get the pages being prefixed with "thread:" as appropriate. -------------------------- **Version**: unspecified **Severity**: minor
  • T29974: Add a configuration setting which disables search completely
    • Task
    It seems I can disable Special:Search somehow but cannot remove link to opensearch_desc.php and the search box in HTML generated by default skins. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T29411: Search Suggest bugs (tracking)
    • Task
    This is just for tracking Search Suggest bugs. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T27407: Make SearchResultSet, and hence, subclasses, implement Iterator
    • Task
    It'd be useful for looping! -------------------------- **Version**: unspecified **Severity**: enhancement
  • T27399: Search suggest shouldn't offer unlisted special pages
    • Task
    The suggestion of unlisted special pages confuses users. This is similar to bug 20868: Search suggest shouldn't offer special pages with limited access to users who don't have such rights. -------------------------- **Version**: unspecified **Severity**: normal
  • T27062: Implement search operator for finding section titles (e.g. "insectiontitle:" )
    • Task
    **Author:** `penbat2001` **Description:** I find the "intitle" and "lookfrom" Wikipedia search options (as in '''<nowiki>intitle:"search phrase"</nowiki>''' and '''<nowiki>lookfrom:"search phrase"</nowiki>''') to be very useful to find articles relating to a subject of interest. However it would also be useful if I could look for section titles within articles using "intitle" and "lookfrom" rather than just article titles. I bet there are plenty of sections tucked away which would be of interest to me and i might llke to link to. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T26591: Search suggestions: Arrow+down not announced in screen reader, often speaks results of one letter less
    • Task
    The suggestions shown under the search field are not accessible via the screen reader. It's not announced, and it does not get read. Ideally, when a term is entered, the screen reader should announce that a list of suggestions is available, and give the user some hint as to how to navigate there (down-arrow works, tab closes the suggestion box and moves the focus away from the search field). This report results from feedback from the German Central Library for the Blind (DZB). Please see http://www.mediawiki.org/wiki/Accessibility#Feedback_from_the_DZB.2C_July_2010 for some background. -------------------------- **Version**: 1.22.0 **Severity**: minor
  • T26209: Make case-insensitive 'Go' button half/fullwidth-insensitive as well
    • Task
    U+FF01 ~ U+FFEE characters. -------------------------- **Version**: 1.17.x **Severity**: enhancement **See Also**: T58080
  • T26059: OpenSearch should check all available variant
    • Task
    On a wiki with language converter enabled, opensearch can try to convert the search keyword to all available variant, and do opensearch with them individually as how OpenSearch does currently, then combine the results and send the user. Some algorithm may be needed to sort the results. -------------------------- **Version**: 1.17.x **Severity**: enhancement
  • T25772: Link to search the keyword after redirect from GO
    • Task
    When the user is redirected from the GO feature, add a message in the contentSub (breadcrumbs) section on the landing page: "You have been redirected here. Search [keyword]." The last part would be a link to search the user's keyword(s). Maybe extend the message: You have been redirected here because [keywords] exists as page title. You can search {{SITENAME}} for "[keywords]". But shorter is better imo. This would solve multiple problems: - People just type and hit return, so they're often redirected without wanting it. So you in old monobook you used to go back and hit search again (becuase the keyword is lost in the search box after the GO redirect). - In Vector GO is forced (by return and the icon). The official solution is to pick it from teh drop-down, but seriously: Who does that and 99% of the users even don't know that, they're just annoyed and confused. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T25675: Back-button script blocks normal browser behaviour
    • Task
    **Author:** `michael` **Description:** I routinely edit, preview, and use the back button to check where I've been. My browser (Safari 4.0.5/Mac) saves the state, including text entered in the Subject/headline and edit field. It also warns me, when necessary, that I may lose entered text, as when closing a window or tab. Vector overrides this behaviour by trapping the back button with a modal dialogue box (blocking access to ''all'' browser windows and tabs), providing an erroneous and unnecessary error message. > Are you sure you want to leave this page? > > Leaving this page may cause you to lose any changes you have made. > If you are logged in, you can disable this warning in the "Editing" section of your preferences. > > Click OK to continue, or Cancel to stay on this page I don't want to blanket disable this warning, if it is useful in some browsers which I may use at some times. But it is worse than useless in my main browser, Safari, so please don't throw it up in Safari. -------------------------- **Version**: 1.22.0 **Severity**: normal
  • T25108: SearchHighlighter::highlightSimple() doesn't escape regex chars in input, leads to PHP errors about unbalanced ( )
    • Task
    Observed the following error message on the WMF cluster: Apr 9 09:38:58 10.0.2.231 apache2[22312]: PHP Warning: preg_match() [<a href='function.preg-match'>function.preg-match</a>]: Compilation failed: missing ) at offset 52 in /usr/local/apache/common-local/wmf-deployment/includes/search/SearchEngine.php on line 1212 Apr 9 09:39:06 10.0.2.231 apache2[22312]:last message repeated 102 times Some quick testing indicates this is very likely to be caused by a literal '(' in the $terms parameter, which is thrown into a regex unescaped. The attached patch fixes this by escaping regex chars in $terms ; I submitted it here rather than committing it straight to SVN because I wasn't sure about the semantics of this function and whether regex chars in $terms being interpreted was a feature or a bug. -------------------------- **Version**: 1.16.x **Severity**: enhancement
  • T24776: MySQL UTF8 escaping doesn't escape u
    • Task
    When updating the searchindex for MySQL, dots in names like "example.com" are encoded. Thus, "exampleu82ecomu800" is what gets stored in search index. The problem, here, is that if you add the plain text "anexampleu82ecomu800" to the page and then search for "anexample.com", you'll get a match. -------------------------- **Version**: 1.16.x **Severity**: enhancement
  • T24774: Should be possible to customize the search profiles.
    • Task
    **Author:** `conrad.irwin` **Description:** It would be nice if the namespaces available to be searched could be customised easily, either by the server-folk or the wiki's Sysops. I envisage a $wgSearchNamespaces to deprecate $wgNamespacesToBeSearchedDefault and $wgNamespacesToBeSearchedHelp in favour of a more flexible configuration (A Wiktionarian suggested that they'd like: $wgSearchNamespaces = array( 'dictionary' => array( NS_MAIN ), 'thesaurus' => array( 110 ), 'appendices' => array( 100, 102, 106 ), 'help-project' => array( NS_HELP, NS_PROJECT ), 'everything' => SEARCH_ALL, 'custom' => SEARCH_CUSTOM ); Obviously, being able to remove the Multimedia option is useful for any site that uses commons for all its media; and adding options is beneficial for any site with custom namespaces) An alternative would be a set-up like [[MediaWiki:Sidebar]] where the message can be read and parsed (and cached!) - would require less precious sysadmin time. This might be possible using an extension to Hook into 'SpecialSearchProfiles', but it would be cleaner to fix SpecialSearch::getSearchProfiles() directly (particularly for a configuration variable). -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=38395 https://bugzilla.wikimedia.org/show_bug.cgi?id=61053
  • T24251: Magic word to remove page from internal MediaWiki search results
    • Task
    One of the perennial debates (on the Hungarian Wikipedia, at least) is whether to delete redirects from old names in the project namespace. On one hand, even when links are updated, it destroys some navigation pathways (bookmarks, external links etc.), makes old revisions of pages (where the links are not updated) less readable and annoys some people; on the other, the old (and often erroneous or misleading) names clutter up the search suggestions dropdown, which is by far the most user-friendly navigation method currently). There is a similar problem with redirects from misspelled names of articles. It would be very useful to have a `__NOSEARCH__` magic word which would suppress indexing of such pages by the internal search engine (or maybe just adding a flag so that the page is only returned when such pages are explicitly requested).
  • T23555: Special:Log should support keyword (or non-exact title) search
    • Task
    **Author:** `wiki0007` **Description:** It is now necessary to have to enter the '''''exact title''''' of an article - exact ''including punctuation'' - in order to find an article in any of the logs. This search would be much more user friendly and would be more like what most people are used to if the LOGs search would search for a key word instead of requiring an exact title. This is especially a problem for the deletion logs, as a lot of people looking at the deletion logs are new to wikipedia and usually trying to find out why their article got deleted. You can see many people at the help des asking "what happened to my article" because they can't find it in the deletion log. I couldn't find a title because I searched for "Searching for the Wrong Eyed Jesus" [http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=delete&user=&page=Searching+for+the+Wrong+Eyed+Jesus] instead of "Searching for the Wrong-Eyed Jesus" [http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=delete&user=&page=Searching+for+the+Wrong-Eyed+Jesus]. Ack! I asked rainman about this, and he said, "This is because the logs search is separate from fulltext search and is using the default mysql engine. The problem you describe could in principle be solved by adding a stripped version of the article title and then search that via mysql." So, I thought it might help if a solution was presented along with the problem. Thanks. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://en.wikipedia.org/wiki/Special:Log
  • T23299: Search results link jump to search term on page
    • Task
    **Author:** `david` **Description:** Currently if you do a search, the links presented for all results are for the wiki page that contains the specified search terms. An excerpt showing the location of the search term is also presented. If a page is long, it can be a problem trying to find the location on the page where the search term was found. It would be a nice enhancement if clicking on the search result link took you to the wiki page and scrolled down to the location where the text was found. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T23019: "Did you mean..." doesn't shows "Special" for the namespace -1
    • Task
    When we type "Special:PrefixIndex/Test" in the search box and click the Search button, it is shown the following line: Did you mean: [-1]:Preference/Test I don't think "[-1]" should be here, because Did you mean: Special:Preference/Test is more understandable for this case. Helder -------------------------- **Version**: unspecified **Severity**: minor **URL**: http://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=Special%3APrefixIndex%2FTest&fulltext=Search
  • T22460: Search should be capable of providing multiple "Did you mean..." suggestions
    • Task
    **Author:** `seahen123` **Description:** When I search en.wikipedia for Tanelon, MediaWiki suggests Taelon as a correction. The user making this search could just as easily mean Tanelorn, as I did. Since no one guess as to what the user means will be reliably correct, the best course of action would be to suggest both. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://en.wikipedia.org/wiki/Special:Search?search=Tanelon&sourceid=Mozilla-search
  • T22237: OpenSearch: Add support for getting titles of in-title matches (instead of just prefix)
    • Task
    **Author:** `mr.primus` **Description:** Please provide a $wg... configuration setting or a user preference to give the AJAX autosuggest feature the ability to search not only in the beginning, but anywhere in the article name. reason 1: example article: Pixar's Disney Toy Story search for: Disney current result: no result You currently only would get results with typing: Pi... reason 2: This would also important when searching beyond namespaces... example: The category "Disney" exists but no article "Disney" search for: Disney current result: nothing You only would get results with typing: Category:D... reason 3: The autosuggest feature currently does not replace the[http://www.mediawiki.org/wiki/Extension:Search_Suggest Extension:Search Suggest] for this functionality like stated on the page of this extension. But this extension was unfortunatly only able to search in articles without namespace preposition. Configuration setting here was: $location = 1; //set to 1 to search anywhere in the article name, set to 0 to search only at the begining reason 4: requested by another user at [http://www.mediawiki.org/wiki/Manual_talk:$wgEnableMWSuggest#Extend_the_search] It can not be a good solution to set redirects for alternative or incomplete terms, especially not when #16145 (mwsuggest.js should not return redirects) get into the core. Thank you. -------------------------- **Version**: 1.13.x **Severity**: enhancement
  • T22166: Support title prefix query on Special:Log
    • Task
    **Author:** `gangleri` **Description:** Dear friends, As far as I understand there is no easy way to identify log entries for a subjectpagename, its talkpagename and related subpages. Example: http://usability.wikimedia.org/w/index.php?title=Special%3ALog&type=delete&user=&page=Environment+Survey%2FMediaWiki+Extensions%2FResults&year=&month=-1 http://usability.wikimedia.org/w/index.php?title=Special%3ALog&type=delete&user=&page=Talk%3AEnvironment+Survey%2FMediaWiki+Extensions%2FResults&year=&month=-1 http://usability.wikimedia.org/w/index.php?title=Special%3ALog&type=delete&user=&page=Environment+Survey%2FMediaWiki+Extensions&year=&month=-1 The main problem is that [[special:Log]] requires accurate titles compared to [[special:PrefixIndex]]. Best regards Reinhardt [[user:Gangleri]] -------------------------- **Version**: unspecified **Severity**: enhancement
  • T22165: Show both subject & associated talk namespace on PrefixIndex/Allpages
    • Task
    **Author:** `gangleri` **Description:** Dear friends, from bug 20163 Today http://usability.wikimedia.org/wiki/special:PrefixIndex/Environment_Survey and http://usability.wikimedia.org/wiki/special:PrefixIndex/talk:Environment_Survey show some differences about the available pages. Showing a combination of subjectpagenames and talkpagenames (only "Talk" link) would make it much easier to realise that today http://usability.wikimedia.org/wiki/Environment_Survey/MediaWiki_Extensions is missing (deleted) and http://usability.wikimedia.org/wiki/talk:Environment_Survey/MediaWiki_Extensions is available. Best regards Reinhardt [[user:Gangleri]] -------------------------- **Version**: unspecified **Severity**: enhancement
  • T20401: Implement "did you mean" suggestions for similar pages in core search
    • Task
    **Author:** `ravi.badam` **Description:** I dont how to put it in simple terms, but here is what happened. As usual i was reading a wiki article, on Video Graphics Array (VGA) connector. I wanted to see what is the difference between VGA and DVI. But when i entered DVI in search box it led to a Disambiguation page instead of going to the DVI connector. Is it ok to handle this as a internal link in wiki article would be handled. i.e., go to directly the DVI connector page instead of disambiguation page. Just a thought. You are doing a great job. Thanks, Badam ---- * With CirrusSearch, searching "cesarè beccaria" gets "Did you mean: cesaré beccaria" https://en.wikipedia.org/wiki/Special:Search?search=cesaro+beccaria&sourceid=Mozilla-search * MediaWiki core search should offer such a functionality. -------------------------- **Version**: unspecified **Severity**: enhancement **Whiteboard**: aklapper-moreinfo
  • T20181: Prune unneeded redirects from SimpleSearch's autosuggest dropdown
    • Task
    Auto-suggest (skins/common/mwsuggest.js) is fantastic for users, but it also confuses users when redirects are displayed. When someone types "tree frog" into the Wikipedia search box and pauses, they see four redundant entries in the dropdown: Tree Frog Tree frog Tree frogs Tree Frogs This redundancy is confusing to users -- "Which one do I choose?" they ask. I see this all the time at my company. People are actually afraid they might choose the wrong one, not realizing that they all lead to the same article. I'm NOT suggesting you remove redirects from the dropdown - they are very important when the redirect is very different from the article title. But surely this list can be pruned to reduce confusion? I suggest that a redirect should be OMITTED from the autosuggest dropdown if BOTH of the following are true: - The target article's title also appears in the dropdown; AND, - The redirect's title is highly similar to the target article's title What is "highly similar"? - Identical except for upper/lower case - Identical except for 1-3 trailing characters? - Other clever rules? I also suggest this pruning feature should be controlled by a global variable ($wgMWSuggestPruning = true) and a user preference. -------------------------- **Version**: 1.25-git **Severity**: enhancement
  • T19132: New AllpagesWithContent = Allpages - redirects - disamb - categories
    • Task
    **Author:** `peter.drier` **Description:** I'm looking to get a list of all pages with actual content.. Not including redirects, categories or disambiguation pages. Given these pages already exist: All pages Categories Disambiguation pages Redirects The request is for the first filtered out by the rest.. Thanks, Peter -------------------------- **Version**: unspecified **Severity**: enhancement
  • T17587: Add class for suggested redirects in search suggest box below search field
    • Task
    It would be handy if suggested titles had their own class, perhaps by default displayed as italic so user could immediately recognize it without loading. -------------------------- **Version**: unspecified **Severity**: enhancement **Whiteboard**: usability
  • T17280: Search (or AJAX Suggestions) should try expanding/contracting ordinals (e.g. Fourteenth should find 14th)
    • Task
    **Author:** `happy_melon` **Description:** From the discussion at http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=233712687#expansion_of_numerical_ordinal_searches , it would be nice if the alternative forms of ordinals ("1st" vs "first") could be considered in the search feature. I think the most efficient way would be if it were handled in the same way as capitalisation - the exact string the user enters is searched first, then capitalisation variants, then (if an ordinal like "1st" or "first" was present) try its alternative form. I know that this is only the tip of the iceberg in terms of what 'alternative forms' the search tool *could* be considering, and it's probably opening a whole can of worms to start chipping bits off that iceberg, but if the goal is to make the search feature more 'intelligent', then stuff like this is probably a good place to begin... -------------------------- **Version**: unspecified **Severity**: enhancement
  • T17018: Limiting which namespaces can be searched
    • Task
    As suggested on the talk page in the URL field. Could be set with a variable, $wgSearchOnlyContentNamespaces, which would default to false, of course. On the other hand, the default doesn't count Project: as a content namespace, and people might want to search it without changing that, so maybe it would make more sense not to couple this with $wgContentNamespaces, and instead make it as flexible as possible with a new variable, $wgSearchableNamespaces, which would default to including all namespaces. This might not work too well with extra namespaces, though, so maybe it would be better to have $wgUnsearchableNamespaces. -------------------------- **Version**: 1.16.x **Severity**: minor **URL**: http://www.mediawiki.org/w/index.php?title=Manual_talk:%24wgContentNamespaces&oldid=203869#Namespaces_without_real_content_in_search
  • T13380: "Go" search should check if page exists in namespaces other than main
    • Task
    **Author:** `chris` **Description:** Steps to reproduce (on Wikipedia, but I think it is a problem with MediaWiki): 1. Go to your user preferences page and click on the search tab. 2. Uncheck the (Main) namespace and check the Wikipedia namespace. 3. Click save. 4. In the search field on the left panel, type "columns" without quotation marks. Result: You are taken to the (Main namespace) article, Column Expected result: Articles in the Wikipedia namespace that explain how to format wiki text into columns. Speculation: It seems that the "I'm feeling lucky"-esque functionality is interfering with the namespace exclusion. -------------------------- **Version**: 1.12.x **Severity**: normal
  • T12808: Introduce Special:Suffixindex
    • Task
    **Author:** `eep` **Description:** Is this possible? Some requests/discussions about it (and the problems caused by NOT having it): http://meta.wikimedia.org/wiki/MediaWiki_Ideal#Suffixindex http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style_%28disambiguation_pages%29/Archive_29#All_pages_beginning_with... Of course, wildcard search (such as implemented in http://www.mediawiki.org/wiki/Extension:Wildcard_search ) would probably work too, but it would be nice if MediaWiki had that functionality by default. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://en.wikipedia.org/wiki/Wikipedia_talk:Special:PrefixIndex#SuffixIndex
  • T12421: "Goto" search fallback using language links
    • Task
    I got an idea, that if a "Go"-search fails, a some sort of reverse search, based on language links on articles is made. So if you for example enters "Osthyvel" in the search box on the English wikipedia, you will end up on [[w:en:Cheese slicer]], as it has a language link to [[w:sv:Osthyvel]], even though there are no redirect at [[w:en:Osthyvel]]. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47979
  • T9184: Optionally exclude subpages from Special:Allpages and Special:Prefixindex
    • Task
    Listings generated from Special:Prefixindex and Special:Allpages tend to be messy, hard to read, and unneccessary lengthy when many subpages are listed. I suggest a checkbox: "[ ] exclude subpages" or a pulldown or number input field: "include subpages up to level [___]". in order to make listings more usable. Arguably, the preset could be, not to include subpages, but although I usually would not want them listed, my preference is to include them all, so as not to change default behaviour for those doing nothing, and not to break programs using the pages. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T8653: Highlight search terms when viewing pages from search results
    • Task
    **Author:** `david_q_zhang` **Description:** One can put a word in the search box and find a list of articles containing that word. If one click one found article, he will find that this word is not colored in the article. It would be nice to have it colored so that a user can quickly find where the search word is located. -------------------------- **Version**: unspecified **Severity**: enhancement
  • T7992: MySQL-Search should sort results by relevance
    • Task
    MySQL-based search engine used per default does not appear to sort results in any meaningful way. I have written a small extension that extends SearchMySQL4 to use sorting by relevance (attachment follows), but the data set on my personal test wiki is not well suited to test it. I'm a bit confused about MySQL fulltext search, and thus this extension may be completely pointles. The relevant documentation is at <http://dev.mysql.com/doc/refman/4.1/en/fulltext-search.html>. A few observations: * SearchMySQL4 uses the IN BOOLEAN MODE modifier (http://dev.mysql.com/doc/refman/4.1/en/fulltext-boolean.html). This appears to cause MySQL to report the relevance at 1.0 for anything that matches, making my patch pointles. The documentation confirms this behaviour: " They do not automatically sort rows in order of decreasing relevance". This also confirms the problem this bug report tires to address. * After some testing, the way to get a weighted search result with boolean matching appears to be this: SELECT page_id, page_namespace, page_title, MATCH(si_text) AGAINST('Quux') as rank FROM `page`,`searchindex` WHERE page_id=si_page AND MATCH(si_text) AGAINST('Quux' IN BOOLEAN MODE) AND page_is_redirect=0 AND page_namespace IN (0) ORDER BY rank DESC * For some reason though, this "sometimes" gives a rank of zero (but still a boolean match) on entries that contain the search string (maybe a wordlength limit? seems unlikely though for the things i've tried). Consequently, not using the BOOLEAN modifier at all causes some matches (the ones with rank 0) not to show. As I said, I'm a bit confused, but this is probably worth looking into. The search feature would be vastly more useful with decent ranking. -------------------------- **Version**: 1.7.x **Severity**: enhancement
  • T7711: Support MySQL >= 4.x boolean logic in search
    • Task
    **Author:** `foxden` **Description:** The current code in 1.6.3's SearchMySQL4.php is really close to allowing full Boolean logic in searches. These are things like: +ninja -pirate (to match all articles with "ninja", but not "pirate") "ninja pirate" (to match all articles with "ninja" followed immediately by "pirate") ninj* (to match ninja, ninjutsu, ninjato) However, the "special" characters +, -, *, etc. are stripped by SearchEngine's method legalSearchChars. In addition, SearchMySQL4.php currently always adds '+' before each word to be searched if no Boolean operators are present. The attached patch (against MediaWiki 1.6.3) adds two config options to change this behavior: 1) $wgSearchMysqlStrictMatch = true; This keeps the current default behavior to prepend '+' to all searches that don't otherwise specify a Boolean logic operator if set to 'true', but allows admins to set it to 'false' to default searches to Boolean 'OR' (where pages matching multiple words are ranked higher) 2) $wgSearchMysqlBooleanLogic = false; This keeps the current default behavior to strip MySQL Boolean logic characters (-, +, <, >, ~, *) if set to false. If set to true, it changes SearchMySQL4.php to override legalSearchChars() to include the Boolean logic chars. I'll attach the patch to this bug as soon as it's submitted. -------------------------- **Version**: 1.6.x **Severity**: enhancement
  • T7466: Add "suggest redirect" option to article not found pages
    • Task
    **Author:** `mediazilla` **Description:** In the following two situations, * Search results when "No page with that title exists" (e.g. http://en.wikipedia.org/wiki/Special:Search?search=z-transforms&go=Go) * When trying to go directly to a non-existent page via a bookmarklet, e.g. from the URL bar ("http://en.wikipedia.org/wiki/%s" -> "http://en.wikipedia.org/wiki/Z-transforms") It would be nice to have an option to suggest a redirect target to an existing page. For example, there is no page titled "Z-transforms" but there is a page titled "Z-transform". It would be useful for later searchers to be redirected automatically or be given a "Did you mean..." link. -------------------------- **Version**: unspecified **Severity**: enhancement **Platform**: Macintosh
  • T4285: Restrict search by category, or set of categories (e.g. range of date categories)
    • Task
    **Author:** `kbaas` **Description:** possibly a search _page_ advanced options would be: *specify categories *specify date range (for wikinews) -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=22269
Prev
1
2
3
Next
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL