Community Wishlist Survey 2021/Search

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Search
11 proposals, 32 contributors
The proposal phase has ended.
Come back on December 8 at 18:00 UTC to vote on proposals!



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

Edit proposal/discussion

  • 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)

Discussion

  • This is a request for a "recently-viewed pages" feature, with weighting by the number of visits, yes? That would be nice. Johnbod (talk) 19:31, 20 November 2020 (UTC)

Start Wiki with cursor focus in search field

Edit proposal/discussion

  • 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)

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)
  • 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)
  • 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 (talkcontribs) 09:30, 24 November 2020 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)

Tags (ala evernote, searchable, catagorizing)

Edit proposal/discussion

  • Problem:
  • Who would benefit: everyone
  • Proposed solution: tag-icons with word with max number of letters (compare evernote)
  • More comments:
  • Phabricator tickets:
  • Proposer: Raven rs (talk) 01:08, 18 November 2020 (UTC)

Discussion

automatic tag-suggestions (already made tags pop up) tag search section combine search with compatible tags (tags associated togheter with a topic Egypt; Pharaohs; New Kingdom) —The preceding unsigned comment was added by Raven rs (talk)

@Raven rs: Could you fill out the problem statement above? That will give context as to what you're trying to solve. Thanks! MusikAnimal (WMF) (talk) 02:30, 3 December 2020 (UTC)

Search own tracking pages

Edit proposal/discussion

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)

Discussion

Preference settings to modify crosswiki search results

Edit proposal/discussion

  • 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)

Discussion

Use Wikidata to improve search

Edit proposal/discussion

  • 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)

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)

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

Edit proposal/discussion

  • 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)

Discussion

  • I like this idea a lot. I could see the functionality expanding over time—there will be some search terms that we'll want for whatever reasons to keep as redlinks, and we'd need to start filtering those out or otherwise they'd soon start to clog the top of the list. {{u|Sdkb}}talk 03:16, 19 November 2020 (UTC)
  • Awsome idea for redirects and/or new articles! Strainu (talk) 09:48, 19 November 2020 (UTC)
  • enwp has a Most-wanted articles list but it's out of date and obviously of no use for other wikis. Certes (talk) 14:45, 19 November 2020 (UTC)
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)
  • 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)
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)
  • Please make this happen, it would be so great. Abductive (talk) 18:28, 20 November 2020 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)

linksfrom: filter

Edit proposal/discussion

  • 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)

Discussion

  • Example uses:
    1. linksfrom:"List of foo" -Foo: find list entries which may be wrong, e.g. a list of singers linking to Prince rather than Prince (musician)
    2. Foo -linksfrom:"List of foo": find list entries which may be missing
  • Certes (talk) 16:06, 19 November 2020 (UTC)

Search Commons images by (approx) coordinates

Edit proposal/discussion

  • 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)

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)
    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)
    @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)

more accurate search

Edit proposal/discussion

  • Problem: when I am searching for things sometimes it gives me multiple results and it's confusing.
  • Who would benefit:anyone who wants a more accurate search.
  • Proposed solution: when you click on the search bar a dropdown menu for categories will pop up, you can search within a category to get better results you can select a category from the dropdown menu or just search without a selected category.
  • More comments:
  • Phabricator tickets:
  • Proposer: Keelanscanlan (talk) 16:18, 20 November 2020 (UTC)

Discussion

  • @Keelanscanlan: You can search by category now. Go to Special:Search, and under "Advanced search options" look for the "Categories" section. There are also many other options that can help you find what you're looking for. Does this satisfy your wish? MusikAnimal (WMF) (talk) 20:12, 20 November 2020 (UTC)
  • When I am searching for pictures in Commons sometimes and I want to work with these (categorizing images etc.), I first get a long list of proposals, eg. re. "Iceland " + 2020 and categorize one image in the middle of the search list/page, afterwards I have to start searching the list of possible images again to know where I was last because the courser goes up on the page; it would be better to get back to the last picture I was working with. Hornstrandir1 (talk) 16:18, 20 November 2020 (UTC)

Suggest to Exclude Indirect Linked Articles from "What links here"

Edit proposal/discussion

  • 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)

Discussion

  • phab:T14396. I am also pretty sure this has been discussed in a previous year. --Izno (talk) 06:00, 18 November 2020 (UTC)
  • Yes, this would be very useful. However, the actual state should be kept as an option. — Draceane talkcontrib. 20:10, 20 November 2020 (UTC)
  • 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)
  • 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)