Wikimedia Meta-Wiki

Community Wishlist Survey 2021/Search

< Community Wishlist Survey 2021
Community Wishlist Survey 2021
Search
9 proposals, 192 contributors, 245 support votes
The survey has closed. Thanks for your participation :)



  • Problem: The current search function is quite poor unless you know exactly what article you are searching for, and what it's title is. If you're searching based on a category (say, "French films of the 1970s"), the search is quite useless.
  • Who would benefit: Everybody using the search function.
  • Proposed solution: Use Wikidata to find search results. This would work by comparing terms in the search query against the Wikidata profiles of pages. So searching for "French films of the 1970s" in Wikipedia would find articles which are categorized as a "film", as "French", and as related to the "1970s". Those articles which would have all three would then be in the top search results if no article had a title with a close match.
  • More comments:
  • Phabricator tickets:
  • Proposer: Oijsdaio (talk) 03:34, 30 November 2020 (UTC)[reply]

Discussion

  • Having an interface to easily make semantic queries to execute on Wikidata would be very useful. Silver hr (talk) 02:12, 1 December 2020 (UTC)[reply]
  • If this were possible, we would already be doing it at Wikidata Query Service. Mapping English language phrases into Wikidata claims is impossible with some very serious AI. And even if it were possible, it would be much too slow for the regular search interface. Kaldari (talk) 02:47, 9 December 2020 (UTC)[reply]
    Do any support voters have a response to this? I see that this request is gaining a lot of traction, but if that's just since we all wish search functioned better rather than since this would actually be a good idea, it might not be the best thing to push to the top. {{u|Sdkb}} talk 10:32, 9 December 2020 (UTC)[reply]
    • only because who's working on this right now couldn't figure out a way to do it doesn't mean it's impossible. if enough people think this should be done, there might be a threshold of collective brain power which is able to find a solution. and, if not, at least we'll have a better case for the impossibility of it today. that being said, i don't know enough of the technical policies, but i also don't believe there's any such search problem that can't be solved with a bigger index and less updated results. it is, after all, how every web search work in the end. (ps: i'm probably unable to support this idea any further. wished to vote for integration with fossil because of offline search among other things, but got in too late. this is my only contribution for the 2021 wishlist, though. cheers! 😘) --cacawee (talk) 07:55, 13 December 2020 (UTC)[reply]
  • WMDE is making a UI for 'easy queries' right now so I wonder if that suits the need. --Izno (talk) 14:57, 11 December 2020 (UTC)[reply]
  • I am running a website (German, non-profit) covering some 60000 pages on basic maths and physics. A search field takes a query and first looks for exact matches based on file names. The query then looks for similiar matches, mixing two algorithms (Levenshtein and the PHP similar-function). Finally, a list of search results with short preview texts is displayed. The search-engine is self-programmed in PHP, but not at a professional level. One (big) shortcoming is lack of speed. I'd gladly share any ideas and experiences. --Rhetos (talk) 12:51, 14 December 2020 (UTC)[reply]

Voting

Start Wiki with cursor focus in search field

  • Problem: When starting the Wikipage one has to click the search field before entering the search text
  • Who would benefit: All persons who would like to search the Wikipedias - no disadvantage for users who use the links on the page (where a click is necessary anyway)
  • Proposed solution: Set the FOCUS of the cursor to the SEARCH field upon loading the Wikipedia page(s).
  • Phabricator tickets:
  • Proposer: Toko~dewiki (talk) 17:22, 23 November 2020 (UTC)[reply]

Discussion

  • This is as simple as adding "autofocus" in the HTML search field <input type="search" ... autofocus> Geert Van Pamel (WMBE) (talk) 23:00, 23 November 2020 (UTC)[reply]
  • This can also be achieved by simple userscript (e.g., this one for when you are on the wiki's main page). --Matěj Suchánek (talk) 09:04, 24 November 2020 (UTC)[reply]
  • This historically has been controversial on en.wp. Most editors (as opposed to readers) find this autofocus behavior annoying and there have been several discussion on this topic in the past there. I do think those discussions haven't been had in a while however. —TheDJ (talk • contribs) 09:30, 24 November 2020 (UTC)[reply]
  • The same problem occurs in Wikidata after you request the creation of a new item; I would expect the cursor to be in the Label field, so I can start typing immediately? Geert Van Pamel (WMBE) (talk) 18:36, 26 November 2020 (UTC)[reply]
  • One problem with this is that the keyboard would no longer work for page navigation using the arrow keys or Page Down (at least on Mac OS). This would be better as a user script. Jonesey95 (talk) 14:31, 29 November 2020 (UTC)[reply]
  • This isn't a good idea as it'd significantly reduce the accessibility rating of every article on-wiki by interefering with keyboard navigation, as all keypresses would go into the search box. Auto-focus works well where the auto-focused action is intended to be the primary or only action on the page and no keyboard navigation is necessary, neither of which are true on articles. --Deskana (talk) 23:33, 30 November 2020 (UTC)[reply]
  • I agree that this wouldn't be a good default for all users. I, for example, have the "Search as you type" feature enabled in my browser which enables me to simply start typing to find something in a web page. This proposal would interfere with that when I'm reading Wikipedia. Silver hr (talk) 02:16, 1 December 2020 (UTC)[reply]
  • This will affect accessible users. Users who frequently use the search box only need to press the Tab key or an enabled widget/userscript.--YFdyh000 (talk) 23:03, 8 December 2020 (UTC)[reply]
  • I am frustrated due to this proposal's complete ignorance of users with accessibility issues. This function exists as gadgets that can be enabled on some wikis (which can be ported to other wikis easily), or you could make use of the accesskey keyboard shortcut, or use the "Jump to search" function on Vector. There are just so many existing ways that won't affect accessibility. H78c67c (talk) 01:25, 10 December 2020 (UTC)[reply]

Voting

linksfrom: filter

  • Problem: It can be difficult to find articles linked from a page which satisfy other criteria.
  • Who would benefit: Readers using, and editors maintaining, list articles, navboxes, etc.
  • Proposed solution: Give search a linksfrom: filter, like linksto: but checking the other end of the wikilink. Following redirects would probably be helpful.
  • More comments: incategory: and PetScan work for some cases but it can be hard to combine link checking with other filters efficiently.
  • Phabricator tickets: T253642; possibly rTSVN5206
  • Proposer: Certes (talk) 16:06, 19 November 2020 (UTC)[reply]

Discussion

  • To answer Tyrekecorrea's comment below: this enhancement may result in us discovering a lot of things which were already linked incorrectly. I think that's a good thing, as finding a problem is the first step to fixing it. Or have I misunderstood your point? Certes (talk) 22:11, 16 December 2020 (UTC)[reply]

Voting

  • Problem: Currently, when I click the "What links here" of an article, there will be some indirect linked articles in the results via some templates. E.g. an article preferrences a template, which has 100 links in it. When I click the "What links here" of this article, all of the 100 links will be listed in the results, which I really don't want and make me feel boring.
  • Who would benefit: All
  • Proposed solution: Exclude those indirect links from the results. If follow the example above, only list the template, and don't list all of the 100 links.
  • More comments:
  • Phabricator tickets:
  • Proposer: Ma3r (talk) 05:47, 18 November 2020 (UTC)[reply]

Discussion

  • phab:T14396. I am also pretty sure this has been discussed in a previous year. --Izno (talk) 06:00, 18 November 2020 (UTC)[reply]
  • Yes, this would be very useful. However, the actual state should be kept as an option. — Draceane talkcontrib. 20:10, 20 November 2020 (UTC)[reply]
  • Very useful for fixing links to moved pages, where most links are via a navbox which has been fixed but has yet to update its transclusions. The current functionality should remain an option and perhaps as the default. Certes (talk) 22:57, 22 November 2020 (UTC)[reply]
  • It would be very usefull, allthgough a solution allready exists. It only is a hell of a job to implement: Put all the stuff a navbox is linked to into a catagory and create a link to the catagory. It works very well. The problem is to translate the huge amount of navboxes into such a structure, or write a bot which does the job (I am not able to do so). Maybe it even is possible to implement the code of a navbox in such a way that it shows the linkes, while actually it is displaying the content of the catagory. T.vanschaik (talk) 23:47, 22 November 2020 (UTC)[reply]
    • Every time I tried to get rid of a huge navbox with the "this should be a category" argument, the community fought tooth and nail to keep it :/ sometimes they agreed to delete the navbox but such a discussion lasts for weeks, while creating a huge navbox can be done within half an hour, without previous discussion... Alensha (talk) 01:23, 9 December 2020 (UTC)[reply]

Voting

Search Commons images by (approx) coordinates

  • Problem: Images can not be searched efficiently by coordinates.
  • Who would benefit: Generic users of Commons, not familiar with categorization logic, to retrieve geolocated photos without puzzling with categories. Expert users of commons willing to put order in categories.
  • Proposed solution: The search should be based on two Earth coordinates defining a quadrangole (through the northmost, eastmost, westmost, soutmost coordinate in the couple): the result should be any geolocated file in Commons with coordinates falling within such quadrangole. Max differences in degrees may be set to prevent abnormal number of result. Alternative approach could be to ask for a single coordinate and provide as result any gelocated file separated by a "no more than" degrees given value.
  • More comments:
  • Phabricator tickets:
  • Proposer: Ysogo (talk) 22:33, 18 November 2020 (UTC)[reply]

Discussion

  • Please find here a Wikidata Query that provides part of this functionality based on images that are registered on Wikidata https://w.wiki/nGd. Maybe an equivalent query could be done in the future using Structured Data on Commons (SDoC) for any media file that would have geocoordinates? Geert Van Pamel (WMBE) (talk) 20:21, 19 November 2020 (UTC)[reply]
    Hi Geert. Thank you. Nevertheless such query only retrieves images that are referenced in a wikidata element. Actually the ratio between "non referenced" and "referenced" images is largely in favour of first ones: hence we are still blind on the largest slice. That's why I think that the functionality is important and it can be realised already today without waiting for SDoC. --Ysogo (talk) 20:37, 19 November 2020 (UTC)[reply]
    @Ysogo: This isn't an outright solution, but you might want to check out wikimap on Toolforge; this provides a map of geotagged Commons images. It's not exactly a search, but it can get some of the same functionality. Vahurzpu (talk) 02:22, 20 November 2020 (UTC)[reply]

Voting

Maintaining a list of the most common search terms which do not correspond to an article name

  • Problem: Not knowing which search terms are failing in directing users to an article.
  • Who would benefit: All users and editors who like to make redirects and new articles.
  • Proposed solution: Maintain a list which shows the most common search terms that do not successfully direct or redirect to an article.
  • More comments : This list would allow editors to easily see which terms require a redirect or a new article the most. A filter for common or offensive words such be applied, and the list should remove words that have subsequently had articles made, either by refreshing or redlinking.
  • Phabricator tickets:
  • Proposer: HappyMihilist (talk) 16:04, 18 November 2020 (UTC)[reply]

Discussion

Also this is about searching, not redlinks, so that page didn't list them, so I don't think there has been a system like this. Dreamy Jazz talk to me | enwiki 00:13, 20 November 2020 (UTC)[reply]
  • Really good idea. Although it would require storing search histories, this data can be anonymous. A way to filter out intentional redlinked search results would be good, as unlike Wanted categories or counting redlinks, there is no way it can be removed from the list by editing. A way to filter out I think is needed, especially if an LTA decides to spam. I suggest this data should be time limited (so that it drops of the list without needing to filter) and that entries should be removed if the page is created. Dreamy Jazz talk to me | enwiki 00:13, 20 November 2020 (UTC)[reply]
Yes, I think some kind of management of the list is definitely necessary to avoid offensive or too common words in being on the list. I'm sure there already exists lists of such words to use. I actually do think however that the list could redlink the items by default, as this would allow for quickly removing unnecessary entries. Or it just gets updated daily, in which case those entries automatically disappear. HappyMihilist (talk) 06:17, 20 November 2020 (UTC)[reply]
I caution on “offensive” however. If a word pops up enough to be included on such a list it’s obviously in use enough to be of interest. Also to mind is what offends some doesn’t others. The British use of C—- is even heard on the floor of parliament at times. Use on the floor of the US a House or Senate would be national news. Using god in any exclamation is extremely problematic in many southern areas of the US, yet commonly used elsewhere. Etc.
  • Please make this happen, it would be so great. Abductive (talk) 18:28, 20 November 2020 (UTC)[reply]
  • The data required for such a summary appeared in 2012. I think it rapidly disappeared for privacy reasons. The technology is (or was) available; perhaps a summary could be released again. I promise not to have my PC search continually for The Certes Garage Band before claiming it to be our most wanted missing article. Certes (talk) 22:52, 22 November 2020 (UTC)[reply]
  • Love this idea. Should be easy enough from a data perspective and would be high impact, as it would give editors a list of the most important articles or redirects that are yet unwritten. One extension could be some way of handling misspellings of the same query and bundling those into one "search term". —Shrinkydinks (talk) 22:35, 24 November 2020 (UTC)[reply]
  • From a Wiktionarian perspective, it sounds very useful to. People may look for neologisms and we may track them with this list! Noé (talk) 12:09, 29 November 2020 (UTC)[reply]
  • phab:T8373#1856037 and [1] have some more information about why this hasn't been done before. The core of the issue is that it's difficult from a privacy perspective and it's also not very useful data, which made overcoming the privacy concerns not seem worth it. --Deskana (talk) 23:31, 30 November 2020 (UTC)[reply]
  • I use Wikipedia a lot with maths and physics students aged 18 or above. Many of them opt out soon for two mainly two reasons: a) the first lines of an article are unintelligible as they directly address experts. And b) searching for a specific topic often leads to confusing and non-specific search results. Collecting dead-end search words to create redirects has the potential to increase usability for well-educated but not expert users. Rhetos (talk) 08:07, 15 December 2020 (UTC)--Rhetos (talk) 07:13, 15 December 2020 (UTC)[reply]

Voting

for logged in users: if you go to a certain page multiple times it shows up automatically

  • Problem: needing to type the same long title a ridiculous number of times
  • Who would benefit: all users who need to go to the same page multiple times
  • Proposed solution: a user history section and having pages show up by relevance
  • More comments:
  • Phabricator tickets:
  • Proposer: Seak knowlage (talk) 20:50, 19 November 2020 (UTC)[reply]

Discussion

Voting

Preference settings to modify crosswiki search results

  • Problem: Since 2017, crosswiki search results have been implemented. However, the results have been also centralized, especially for various communities. The crosswiki search results at enwiki have been limited per community consensus. For example, crosswiki snippets of Wikimedia Commons are suppressed from enwiki search results (phab:T163463), but the results from Commons in enwiki can be found only while using "File:" namespace. Wiktionary (phab:T163463) and Wikivoyage results in enwiki have been restricted as well to exact title matches. Currently, AFAIK only enwiki has a gadget to disable/enable the snippets all together. I don't know which other projects have the similar gadgets; a user script can be found at enwiki's Signpost article, but I don't know whether other projects are aware of such user script.
  • Who would benefit: Registered users who would like to decide for themselves which snippet(s) they want to either see or disable. (Either registration is required, or users must sign-in for that benefit.)
  • Proposed solution: Add settings for crosswiki search results preferably in the "Search" tab of User preferences. They would also decide which results from any sister project to display. They can also decide whether to disable or enable the snippets. They can also reorder the snippets from top to bottom (i.e. highest to lowest priority).
  • More comments: I proposed this back in 2017, but that was under the older "top 10" format. Maybe the TechCom can give this into consideration as part of the backlog. Furthermore, as I wrote in a Phabricator task, default settings for English Wikipedia should reflect wishes of the enwiki community (phab:T163463, phab:T171803, phab:T185250).
  • Phabricator tickets: phab:T266726 (tagged as Low-priority)
  • Proposer: George Ho (talk) 21:28, 18 November 2020 (UTC)[reply]

Discussion

Voting

Search own tracking pages

Original title (fr): recherche dans ses propres pages de suivi

  • Problem: be able to find words or expressions only in the pages that I follow in order to improve these articles.
  • Who would benefit: all Wikipedia contributors
  • Proposed solution: allow with the search tool in Wikipedia to limit results to a set of pages.
  • Other comments: When I discover an article on Wikipedia that I did not know I would like to be able to make a link with it in the articles that I follow or that I have created. Example, tomorrow I create the article 'Maison seigneuriale', the simple search "seigneurial house" gives 733 articles. So I would like to be able to embed this link already on my tracking pages before considering linking the 733 posts.
  • Phabricator tickets:
  • Proposer: Thierry74 (talk) 12:54, 24 November 2020 (UTC)[reply]

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2021/Search&oldid=20877431"