Community Wishlist Survey 2021/Search

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



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

Voting

  •   Support Dr747 (talk) 18:40, 8 December 2020 (UTC)
  •   Support Imetsia (talk) 18:56, 8 December 2020 (UTC)
  •   Support MarioSuperstar77 (talk) 20:17, 8 December 2020 (UTC)
  •   Support urgently needed. --Braveheidi (talk) 20:52, 8 December 2020 (UTC)
  •   Support Ssstela (talk) 21:20, 8 December 2020 (UTC)
  •   Support Pmau (talk) 21:42, 8 December 2020 (UTC)
  •   Support شادي (talk) 22:30, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 23:03, 8 December 2020 (UTC)
  •   Support Martinkunev (talk) 23:09, 8 December 2020 (UTC)
  •   Support Silver hr (talk) 00:06, 9 December 2020 (UTC)
  •   Support Wikidata also lists alternative names, so they could also be used to help direct search queries to the correct article 5225C (talkcontributions) 00:18, 9 December 2020 (UTC)
  •   Support Eric0892 (talk) 01:10, 9 December 2020 (UTC)
  •   Support BALA. RTalk 01:30, 9 December 2020 (UTC)
  •   Support Keepcalmandchill (talk) 02:00, 9 December 2020 (UTC)
  •   Support Pamzeis (talk) 02:56, 9 December 2020 (UTC)
  •   Support NMaia (talk) 03:16, 9 December 2020 (UTC)
  •   Support JopkeB (talk) 05:46, 9 December 2020 (UTC)
  •   Support Pinerineks (talk) 07:00, 9 December 2020 (UTC)
  •   Support Philbutler (talk) 07:23, 9 December 2020 (UTC)
  •   Support Karbohut (talk) 09:49, 9 December 2020 (UTC)
  •   Support Xavi Dengra (MESSAGES) 12:57, 9 December 2020 (UTC)
  •   Support TheImaCow (talk) 17:14, 9 December 2020 (UTC)
  •   Support Monozigote (talk) 17:18, 9 December 2020 (UTC)
  •   Support Петър Петров (talk) 17:35, 9 December 2020 (UTC)
  •   Support Rafael (stanglavine) msg 18:36, 9 December 2020 (UTC)
  •   Oppose If data from Wikidata is incorporated into the search engine protocol, it's going to end up skewing the sequence of the search results and preclude people from quickly and easily locating and accessing existing material on the site. Tyrekecorrea (talk) 18:56, 9 December 2020 (UTC)
  •   Support TheAmerikaner (talk) 20:33, 9 December 2020 (UTC)
  •   Support Thomas Kinz (talk) 21:12, 9 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:04, 10 December 2020 (UTC)
  •   Weak support Unbeatable101 (talk) 04:15, 10 December 2020 (UTC)
  •   Comment This proposal is less clear. Shall Wikidata search results be used as snippets, like other crosswiki search results? Shall Wikidata be amongst all other Wikipedia (or specific project) search results? Shall Wikidata results be JavaScript pop-ups? How else can Wikidata results be well executed? George Ho (talk) 07:49, 10 December 2020 (UTC)
  •   Support - yona B. (D) 08:13, 10 December 2020 (UTC)
  •   Support Nonahg (talk) 09:01, 10 December 2020 (UTC)
  •   Support Crocodile2020 (talk) 09:27, 10 December 2020 (UTC)
  •   Support Euro know (talk) 11:23, 10 December 2020 (UTC)
  •   Support Tim bates (talk) 15:43, 10 December 2020 (UTC)
  •   Support Libcub (talk) 20:28, 10 December 2020 (UTC)
  •   Support NaBUru38 (talk) 21:08, 10 December 2020 (UTC)
  •   Support Titore (talk) 23:56, 10 December 2020 (UTC)
  •   Support Higa4 (talk) 05:01, 11 December 2020 (UTC)
  •   Support Cryout (talk) 10:05, 11 December 2020 (UTC) great AI addition for better use experience
  •   Support Paucabot (talk) 12:30, 11 December 2020 (UTC)
  •   Support Susanna Giaccai (talk) 16:38, 11 December 2020 (UTC)
  •   Support Szalax (talk) 17:18, 11 December 2020 (UTC)
  •   Support BoldLuis (talk) 18:14, 11 December 2020 (UTC)
  •   Support It wouldn't have to be complicatedRosičák (talk) 18:25, 11 December 2020 (UTC)
  •   Support Anaxial (talk) 18:55, 11 December 2020 (UTC)
  •   Support MathieuMD (talk) 19:06, 11 December 2020 (UTC)
  •   Support Pinnermck (talk) 20:24, 11 December 2020 (UTC)
  •   Support Somej (talk) 21:12, 11 December 2020 (UTC)
  •   Support Stevenliuyi (talk) 22:26, 11 December 2020 (UTC)
  •   Support Tom Ja (talk) 10:04, 12 December 2020 (UTC)
  •   Support Kon Gl (talk) 14:16, 12 December 2020 (UTC)
  •   Support. Meiræ 21:51, 12 December 2020 (UTC)
  •   Support Consulnico (talk) 01:00, 13 December 2020 (UTC)
  •   Support Kew Gardens 613 (talk) 02:48, 13 December 2020 (UTC)
  •   Support Le moteur de recherche actuel est trop médiocre, donc tout ce qui est faisable techniquement pour l'améliorer (et en plus profitons de Wikidata)... (exemple, résultat logique attendu). Nemo Le Poisson (talk) 10:09, 13 December 2020 (UTC)
  •   Support Geagea (talk) 14:25, 13 December 2020 (UTC)
  •   Support Sounds great. Anything to improve search. Bodysurfinyon (talk) 02:34, 14 December 2020 (UTC)
  •   Support Fra4481 (talk) 10:41, 14 December 2020 (UTC)
  •   Support Sadads (talk) 11:52, 14 December 2020 (UTC)
  •   Support Rhetos (talk) 12:33, 14 December 2020 (UTC)
  •   Support good thing to keep on the table for brainstorming (assuming it is as complex/"impossible" as some folks say); it would be useful (as an OPTION) Philiptdotcom (talk) 13:45, 14 December 2020 (UTC)
  •   Support Nurtenge (talk) 06:54, 15 December 2020 (UTC)
  •   Support Anything that improves our search is a good idea, and this would be very useful (often more so than exact-text matches, but it depends on what you're doing). Should be able to turn it off, both in the search form and its results pages, and as a permanent setting.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:18, 15 December 2020 (UTC)
  •   Support β16 - (talk) 09:57, 15 December 2020 (UTC)
  •   Support MTheiler (talk) 15:20, 15 December 2020 (UTC)
  •   Support. Shalomori123 (talk) 17:41, 15 December 2020 (UTC)
  •   Support Utopes (talk) 19:21, 15 December 2020 (UTC)
  •   Neutral I would like to use an improved search engine for Wikipedia, but not specifically via Wikidata, although it is not excluded. TechAcquisitor (talk) 19:42, 15 December 2020 (UTC)
  •   Support Jstalins (talk) 04:25, 16 December 2020 (UTC)
  •   Support Rhymes (talk) 18:18, 17 December 2020 (UTC)
  •   Support Kocgs (talk) 20:46, 17 December 2020 (UTC)
  •   Support ~~ Alex Noble - talk 14:49, 18 December 2020 (UTC)
  •   Support Mmitchell10 (talk) 20:10, 18 December 2020 (UTC)
  •   Support Patsagorn Y. (Talk) 05:01, 19 December 2020 (UTC)
  •   Support 常规搜索页面搜索不到相应内容,需要加强 郑洲扬 (talk) 12:45, 20 December 2020 (UTC)
  •   Support BradChim (talk) 14:51, 20 December 2020 (UTC)
  •   Support S8321414 (talk) 14:37, 21 December 2020 (UTC)
  •   Support Nachtbold (talk) 15:38, 21 December 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)
  • 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)
  • 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)

Voting

  •   Support Imetsia (talk) 18:57, 8 December 2020 (UTC)
  •   Oppose It would require javascript to interact with one's cursor, a better alternative is to use a keyboard shortcut to quickly activate the search bar. I do not support your idea specifically. MarioSuperstar77 (talk) 20:21, 8 December 2020 (UTC)
  •   Support This can be implemented without javascript. I find it very useful. Martinkunev (talk) 23:07, 8 December 2020 (UTC)
  •   Oppose I wouldn't mind this being an option that's turned off by default, but I do not support this being the default behavior. It would interfere with finding text in pages for those people who have enabled the Search as you type option in their browsers. Silver hr (talk) 00:03, 9 December 2020 (UTC)
      Comment Good point, this should be a configuration option. Martinkunev (talk) 14:31, 9 December 2020 (UTC)
  •   Support --Ciao • Bestoernesto 00:37, 9 December 2020 (UTC)
  •   Support BALA. RTalk 01:28, 9 December 2020 (UTC)
  •   Support Петър Петров (talk) 17:34, 9 December 2020 (UTC)
  •   Oppose I don't spend nearly as much time searching Wikipedia as I spend moving from one article to another using links, and there are a lot of them. Tyrekecorrea (talk) 18:34, 9 December 2020 (UTC)
  •   Support TheAmerikaner (talk) 20:32, 9 December 2020 (UTC)
  •   Support this should be a configuration option JackPotte (talk) 21:38, 9 December 2020 (UTC)
    @JackPotte: There's a similar gadget on many Wikipedias, for example on the English Wikipedia it's "Focus the cursor in the search bar on loading the Main Page"; this could be modified to extend to all pages if desired. It doesn't appear to be on the French Wikipedia, but it could be easily copied over. --Deskana (talk) 23:30, 9 December 2020 (UTC)
  •   Support RohMusik (talk) 23:31, 9 December 2020 (UTC)
  • Strongest possible   Oppose. No. Please. You can use the accesskey shortcut if you want to get to the search bar fast. In addition, due to the current layout on the Vector skin, the search bar is actually after the main content, and I absolutely do not want to spam my tab key just to focus on the link I want to navigate to. H78c67c (talk) 01:15, 10 December 2020 (UTC)
  •   Support as an option per Silver hr;   Oppose as default/mandatory. George Ho (talk) 07:45, 10 December 2020 (UTC)
  •   Support Pour en option dans les préférences. C'est mieux que des gadgets perso où seuls quelques wikis les connaissent. Nemo Le Poisson (talk) 09:49, 13 December 2020 (UTC)
  •   Support no brainer Bodysurfinyon (talk) 02:31, 14 December 2020 (UTC)
  •   Support Philiptdotcom (talk) 13:38, 14 December 2020 (UTC)
  •   Oppose, except as an option, and one that is off by default, since in many browsers this will interfere with keyboard-based page control, in-page searching, hotkeys, etc. I would also need to be a per-skin basis (one might want this in a mobile view but not desktop). Mostly just opposed, because the likely utility of this will be very low and for a small number of people, so the devs should not waste resources on it.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:11, 15 December 2020 (UTC)
  •   Support No JavaScript required, so... I'm ok! TechAcquisitor (talk) 19:56, 15 December 2020 (UTC)
  •   Oppose for the Google homepage, or a login page, this makes sense. However there are lots of other things going on in Wikipedia apart from search, and this would be unexpected/unwelcome for most users who interact frequently using keyboard, eg PgDn would be broken. Jdpipe (talk) 05:48, 17 December 2020 (UTC)
  •   Oppose: please, please, no. Mainly because it hijacks keyboard page scrolling as mentioned by others. But note also that on a touch-screen system like a tablet or kiosk this would cause the soft keyboard to pop up every time a page is opened. Pelagic (talk) 13:00, 18 December 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)
  • 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)

Voting

  •   Support MarioSuperstar77 (talk) 20:19, 8 December 2020 (UTC)
  •   Support Would be useful tufor (talk) 20:40, 8 December 2020 (UTC)
  •   Support as proposer. Certes (talk) 21:22, 8 December 2020 (UTC)
  •   Support --Ciao • Bestoernesto 01:31, 9 December 2020 (UTC)
  •   Support Петър Петров (talk) 17:35, 9 December 2020 (UTC)
  •   Oppose I have a feeling this is going to just result in a lot of things being linked incorrectly, since a lot of media uses the same terminology. Tyrekecorrea (talk) 18:43, 9 December 2020 (UTC)
  •   Support NaBUru38 (talk) 21:07, 10 December 2020 (UTC)
  •   Support Izno (talk) 22:41, 10 December 2020 (UTC)
  •   Support Philiptdotcom (talk) 13:39, 14 December 2020 (UTC)
  •   Support β16 - (talk) 09:56, 15 December 2020 (UTC)
  •   Support solitary oppose is frankly incomprehensible – Teratix 06:45, 16 December 2020 (UTC)
  •   Support Kku (talk) 07:26, 17 December 2020 (UTC)
  •   Support Golmore (talk) 06:59, 18 December 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)
    • 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)

Voting

  •   Support Sagivrash (talk) 19:16, 8 December 2020 (UTC)
  •   Support Movses (talk) 19:31, 8 December 2020 (UTC)
  •   Support MarioSuperstar77 (talk) 20:17, 8 December 2020 (UTC)
  •   Support very important feature, wanted since long time Akela (talk) 20:38, 8 December 2020 (UTC)
  •   Support tufor (talk) 20:39, 8 December 2020 (UTC)
  •   Support Samat (talk) 20:51, 8 December 2020 (UTC)
  •   Support Hkoala (talk) 20:56, 8 December 2020 (UTC)
  •   Support --Pagony (talk) 21:04, 8 December 2020 (UTC)
  •   Support ZorróAszter (talk) 21:12, 8 December 2020 (UTC)
  •   Support as an option but keep the existing behaviour as default Certes (talk) 21:21, 8 December 2020 (UTC)
  •   Support Pi.1415926535 (talk) 21:25, 8 December 2020 (UTC)
  •   Support Palotabarát (talk) 21:39, 8 December 2020 (UTC)
  •   Support --Dodi123 (talk) 22:20, 8 December 2020 (UTC)
  •   Support tsca (talk) 22:51, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 23:03, 8 December 2020 (UTC)
  •   Support — Jules Talk 23:26, 8 December 2020 (UTC)
  •   Support Alensha (talk) 01:19, 9 December 2020 (UTC)
  •   Support BALA. RTalk 01:30, 9 December 2020 (UTC)
  •   Support Hanif Al Husaini (talk) 02:06, 9 December 2020 (UTC)
  •   Support kennethaw88talk 05:56, 9 December 2020 (UTC)
  •   Support Teemeah (talk) 09:17, 9 December 2020 (UTC)
  •   Support Worrida (talk) 11:50, 9 December 2020 (UTC)
  •   SupportRhododendrites talk \\ 14:33, 9 December 2020 (UTC)
  •   Support Yes, same as Draceane Ján Kepler (talk) 14:44, 9 December 2020 (UTC)
  •   Support Pharos (talk) 14:57, 9 December 2020 (UTC)
  •   Support Mannivu · 15:06, 9 December 2020 (UTC)
  •   Support Geraki TL 16:39, 9 December 2020 (UTC)
  •   Support We need this. Петър Петров (talk) 17:26, 9 December 2020 (UTC)
  •   Oppose I don't see the point of it. a lot of articles don't have that many connections, and people can just sort out what they need for themselves. Tyrekecorrea (talk) 18:31, 9 December 2020 (UTC)
  •   Support Netjeff (talk) 19:17, 9 December 2020 (UTC)
  •   Support there are options to include/exclude redirects, transclusions and links. This shoul be new otion. JAn Dudík (talk) 20:19, 9 December 2020 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:18, 9 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:05, 10 December 2020 (UTC)
  •   Support as an option per Certes and Jan Dudik;   Oppose as default/mandatory. George Ho (talk) 07:40, 10 December 2020 (UTC)
  •   Support Ostrzyciel (talk) 13:18, 10 December 2020 (UTC)
  •   Support Nk (talk) 14:01, 10 December 2020 (UTC)
  •   Support Libcub (talk) 20:26, 10 December 2020 (UTC)
  •   Support Bencemac (talk) 16:10, 11 December 2020 (UTC)
  •   Support OosWesThoesBes (talk) 17:29, 11 December 2020 (UTC)
  •   Support czar 18:51, 11 December 2020 (UTC)
  •   Support Oh, DrPizza! (talk) 08:31, 12 December 2020 (UTC)
  •   Support. Meiræ 21:50, 12 December 2020 (UTC)
  •   Support ~ Amory (utc) 13:27, 14 December 2020 (UTC)
  •   Support yes, seems very useful; however, always good to allow an option (checkbox?) to preserve current functionality Philiptdotcom (talk) 13:41, 14 December 2020 (UTC)
  •   Support WhatamIdoing (talk) 19:37, 14 December 2020 (UTC)
  •   Support WTM (talk) 00:26, 15 December 2020 (UTC)
  •   Support As this will really mostly be of use for maintenance purposes, "The current functionality should remain an option and perhaps as the default", per Certes.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:15, 15 December 2020 (UTC)
  •   Support with keeping the current situation as the default. Tacsipacsi (talk) 10:03, 15 December 2020 (UTC)
  •   Support — Draceane talkcontrib. 13:39, 15 December 2020 (UTC)
  •   Support MTheiler (talk) 15:23, 15 December 2020 (UTC)
  •   Support SeGiba (talk) 18:06, 15 December 2020 (UTC)
  •   Support Michael Childs (talk) 01:42, 17 December 2020 (UTC)
  •   Support Adam78 (talk) 10:37, 17 December 2020 (UTC)
  •   Support GiFontenelle (talk) 18:37, 17 December 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)

Voting

  •   Support MarioSuperstar77 (talk) 20:21, 8 December 2020 (UTC)
  •   Support Pmau (talk) 21:41, 8 December 2020 (UTC)
  •   Support tsca (talk) 22:50, 8 December 2020 (UTC)
  •   Support Silver hr (talk) 00:08, 9 December 2020 (UTC)
  •   Support --Ciao • Bestoernesto 01:36, 9 December 2020 (UTC)
  •   Support PianistHere (talk) 01:59, 9 December 2020 (UTC)
  •   Support Kaldari (talk) 02:52, 9 December 2020 (UTC)
  •   Support OrCer (talk) 11:15, 9 December 2020 (UTC)
  •   Support Heartbeaz (talk) 11:15, 9 December 2020 (UTC)
  •   Oppose there are privacy and safety issues, and then there's the issue of a delay in data updates resulting in images which don't reflect the status of searched locations in real time. Tyrekecorrea (talk) 18:36, 9 December 2020 (UTC)
  •   Support Rafael (stanglavine) msg 18:53, 9 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:04, 10 December 2020 (UTC)
  •   Support - yona B. (D) 08:12, 10 December 2020 (UTC)
  •   Support Nk (talk) 14:04, 10 December 2020 (UTC)
  •   Support 14:24, 10 December 2020 (UTC)
  •   Support Libcub (talk) 20:27, 10 December 2020 (UTC)
  •   Support Alexcalamaro (talk) 22:36, 10 December 2020 (UTC)
  •   Support Dhx1 (talk) 13:22, 11 December 2020 (UTC)
  •   Support 4nn1l2 (talk) 16:00, 11 December 2020 (UTC)
  •   Support Arnd (talk) 17:09, 11 December 2020 (UTC)
  •   Support Good idea. BoldLuis (talk) 18:15, 11 December 2020 (UTC)
  •   Support Sounds pretty awesome to me! -- Mathieugp (talk) 18:16, 11 December 2020 (UTC)
  •   Support Anaxial (talk) 18:56, 11 December 2020 (UTC)
  •   Support MathieuMD (talk) 19:08, 11 December 2020 (UTC)
  •   Support Tom Ja (talk) 10:06, 12 December 2020 (UTC)
  •   Support Yiyi (talk) 19:17, 12 December 2020 (UTC)
  •   Support. Meiræ 21:52, 12 December 2020 (UTC)
  •   Support Gelli1742 (talk) 20:21, 13 December 2020 (UTC)
  •   Support — Draceane talkcontrib. 13:37, 15 December 2020 (UTC)
  •   SupportÉpico (talk)/(contribs) 23:58, 16 December 2020 (UTC)
  •   Support Golmore (talk) 06:59, 18 December 2020 (UTC)
  •   SupportOmegatron (talk) 15:03, 20 December 2020 (UTC)
  •   Support Pstaudt-fischbach (talk) 17:32, 20 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)
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)
  • 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)
  • 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)

Voting

  •   Support ValeJappo【〒】 18:29, 8 December 2020 (UTC)
  •   Support Noé (talk) 19:32, 8 December 2020 (UTC)
  •   Support This is a great idea that can be really helpful for creating redirects and new pages ThadeusOfNazereth (talk) 19:33, 8 December 2020 (UTC)
  •   Support T. Le Berre (talk) 19:42, 8 December 2020 (UTC)
  •   Support As a suggestion, it should be located in statistics. MarioSuperstar77 (talk) 20:16, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 23:04, 8 December 2020 (UTC)
  •   Support — Jules Talk 23:27, 8 December 2020 (UTC)
  •   Support PianistHere (talk) 01:57, 9 December 2020 (UTC)
  •   Support Alkari (talk) 03:21, 9 December 2020 (UTC)
  •   Support Yeenosaurus (talk) 03:45, 9 December 2020 (UTC)
  •   Support Ottawajin (talk) 05:08, 9 December 2020 (UTC)
  •   Support While most would probably either be mere misspellings or be non-notable, this does sound like a good idea. Opalzukor (talk) 08:12, 9 December 2020 (UTC)
  •   Support Abductive (talk) 09:06, 9 December 2020 (UTC)
  •   Support This could help us better serve readers by addressing content gaps. {{u|Sdkb}}talk 10:28, 9 December 2020 (UTC)
  •   Support Xavi Dengra (MESSAGES) 12:55, 9 December 2020 (UTC)
  •   Support Hb2007 (talk) 13:23, 9 December 2020 (UTC)
  •   Support TheImaCow (talk) 17:14, 9 December 2020 (UTC)
  •   Oppose due to the privacy concerns mentioned in the discussion section. --Петър Петров (talk) 17:39, 9 December 2020 (UTC)
  •   Oppose It seems like this would be really big and difficult to maintain; there'll be complaints about difficulty managing it next. The preceding unsigned comment was added by Tyrekecorrea (talk • contribs) 19:03, 9 December 2020‎ (UTC)
  •   Oppose Requires a lot of code writing and more complex skills. If not required, then the whole idea would take years and years to complete. I don't think the TechCom would reach to the pars of Google in one year. Ah, I see that filtering is considered. However, Google's firing of an AI ethicist who have challenged algorithm bias makes me doubt that the filtering would be effective in eliminating algorithm bias, even when it may filter out offensive words. Also, I can imaging many more VP discussions and Phab tickets, like this one. Furthermore, I don't think implementing this idea as an option for registered users would erase the idea's potential problems. George Ho (talk) 21:54, 9 December 2020 (UTC)
  •   Support dwf² (talk) 23:07, 9 December 2020 (UTC)
  •   Support Anaxial (talk) 18:57, 11 December 2020 (UTC)
  •   Support Wanax01 (talk) 16:02, 12 December 2020 (UTC)
  •   Support SkSlick (talk) 19:41, 12 December 2020 (UTC)
  •   Support Kew Gardens 613 (talk) 02:48, 13 December 2020 (UTC)
  •   Strong oppose for privacy reasons and attack vector reasons, but this is somewhat academic in that I expect this proposal would be rejected as infeasible/too high risk even if it were #1 on the wishlist. To quote Deskana from phab:T8373#1856037, which they bring up above, Search data, and in particular the search queries that users enter, is assumed to contain personally identifying information unless proven otherwise.. I actually had this concern before reading their words - what happens when I go onto an obscure wiki and paste something in the search bar, thinking it's the text I just tried to copy, but I accidentally didn't and the last thing on my clipboard is my name and contact info? Not an unreasonable scenario that this could be on the list for any reasonably obscure wiki and reasonably long list. Or if we set a threshold of how many times something has to be searched for, we're still storing doxxing info by malicious actors who immediately realise that this feature is a good attack vector. Or even if the information is not PID, as soon as undeclared paid editing companies learn about this they can use bots and other behaviour to make terms appear frequently enough that we'll do their job for them and write about something that otherwise wouldn't get an article (maybe even one that's notable, but it's the fact that someone is duplicitiously bypassing our normal process for financial gain that's an issue). — Bilorv (talk) 00:09, 14 December 2020 (UTC)
  •   Support This will make WIkiPedia more useful overtime. The use of the term "common search terms" means that this will NOT be a threat to privacy!!! And picking those up and guiding them to good pages will be great for making us more accessible. As Kevin Kelly wrote in Out of Control "Honor your errors". If people keep making the same mistake, they will keep making it, so, make it not a mistake or... Bodysurfinyon (talk) 02:43, 14 December 2020 (UTC)
  •   Support great way to improve wiki content/relevant search terms within articles/titles Philiptdotcom (talk) 13:42, 14 December 2020 (UTC)
  •   Support in theory, only if the data can be sanitized of an privacy concerns.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:08, 15 December 2020 (UTC)
  •   Oppose per Bilorv. — Épico (talk)/(contribs) 00:00, 17 December 2020 (UTC)
  •   Support Rhymes (talk) 18:22, 17 December 2020 (UTC)
  •   Support Mmitchell10 (talk) 20:10, 18 December 2020 (UTC)

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)
  • It can be collapsed, when not used.--BoldLuis (talk) 18:13, 11 December 2020 (UTC)

Voting

  •   Support Imetsia (talk) 18:55, 8 December 2020 (UTC)
  •   Support This would make anti-vandalism patrol a lot easier as well by reducing the number of tabs we need to manage. ThadeusOfNazereth (talk) 19:32, 8 December 2020 (UTC)
  •   Support --NGC 54 (talk / contribs) 19:59, 8 December 2020 (UTC)
  •   Support ...Or if that page appears in your watchlist. I definitely support that feature. MarioSuperstar77 (talk) 20:15, 8 December 2020 (UTC)
  •   Support Pmau (talk) 21:41, 8 December 2020 (UTC)
  •   Support Good idea شادي (talk) 22:29, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 23:01, 8 December 2020 (UTC)
  •   Support Eric0892 (talk) 01:09, 9 December 2020 (UTC)
  •   Support BALA. RTalk 01:29, 9 December 2020 (UTC)
  •   Support Hanif Al Husaini (talk) 02:06, 9 December 2020 (UTC)
  •   Comment I would support this if were based on watchlist rather than page viewing history. Otherwise, we'll end up needing a whole new interface for editing and purging our page viewing history. (Imagine you're about to give a Wikipedia presentation to 1000 people at Wikimania and you recently had to revert vandalism at erotic asphyxiation.) Kaldari (talk) 02:33, 9 December 2020 (UTC)
  •   Support Baltakatei (talk) 16:54, 9 December 2020 (UTC)
  •   Oppose it seems practical at first, but that could get really irritating if I only want to check something out a few times and it gets in my way when I'm looking to go somewhere else. Tyrekecorrea (talk) 18:46, 9 December 2020 (UTC)
  •   Support BoldLuis (talk) 18:13, 11 December 2020 (UTC)
  •   Oppose I do not believe we should be tracking user behaviour in this much detail, for privacy and data rights reasons. I don't quite know what information the WMF currently gleans from us but I would discourage them storing more data without good reason. Kaldari points out one unintended consequence, but I argue that a much more common one would be that of a parent going on a shared family computer and learning via this mechanism that their child is gay or trans or anything else that a person's reading history tells us about them that they wouldn't expect another person using the same device to discover by accident. — Bilorv (talk) 23:58, 13 December 2020 (UTC)
  •   Oppose, per Bilorv and Tyrekecorrea, and because this is redundant with browser bookmarking, and with just creating a user-spaced favorites list.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:14, 15 December 2020 (UTC)
  •   Neutral Ok if it is based on the watchlist, not our habits TechAcquisitor (talk) 19:53, 15 December 2020 (UTC)

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

Voting

  •   Weak support Why not? MarioSuperstar77 (talk) 20:18, 8 December 2020 (UTC)
  •   Support --Ciao • Bestoernesto 01:06, 9 December 2020 (UTC)
  •   SupportOmda4wady (talk) 07:09, 9 December 2020 (UTC)
  •   Support Frhdkazan (talk) 12:04, 9 December 2020 (UTC)
  •   Oppose I suppose I don't use the search engine often enough or broadly enough to think this a big deal, as I hadn't even noticed the search protocol change, but if the issue is that the scope of results has gotten out of hand, maybe it's better if things just went back to the way they were before. Tyrekecorrea (talk) 18:39, 9 December 2020 (UTC)
    @Tyrekecorrea: This proposal also allows you to disable the snippets all together, the same way that enwiki's gadget does. If this proposal fails to impress and attract TechCom, then you can use enwiki's gadget to disable them. George Ho (talk) 20:02, 9 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

Voting

  •   Support Support for convenience. MarioSuperstar77 (talk) 20:15, 8 December 2020 (UTC)
  •   Support --Ciao • Bestoernesto 01:09, 9 December 2020 (UTC)
  •   Comment it's a good idea if the focus of your work on the site is to be really narrow. Tyrekecorrea (talk) 18:59, 9 December 2020 (UTC)
  •   Support Philiptdotcom (talk) 13:36, 14 December 2020 (UTC)
  •   Support Would be a very handy w:en:WP:GNOME and maintenance tool.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:05, 15 December 2020 (UTC)
  •   Support I don't know why I'd be against that! TechAcquisitor (talk) 19:45, 15 December 2020 (UTC)
  •   Support LS9974 (talk) 21:23, 16 December 2020 (UTC)
  •   Support Risk Engineer (talk) 15:52, 17 December 2020 (UTC)