Community Wishlist Survey 2021/Search

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to 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 Support Dr747 (talk) 18:40, 8 December 2020 (UTC)
  • Support Support Imetsia (talk) 18:56, 8 December 2020 (UTC)
  • Support Support MarioSuperstar77 (talk) 20:17, 8 December 2020 (UTC)
  • Support Support urgently needed. --Braveheidi (talk) 20:52, 8 December 2020 (UTC)
  • Support Support Ssstela (talk) 21:20, 8 December 2020 (UTC)
  • Support Support Pmau (talk) 21:42, 8 December 2020 (UTC)
  • Support Support شادي (talk) 22:30, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 23:03, 8 December 2020 (UTC)
  • Support Support Martinkunev (talk) 23:09, 8 December 2020 (UTC)
  • Support Support Silver hr (talk) 00:06, 9 December 2020 (UTC)
  • Support 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 Support Eric0892 (talk) 01:10, 9 December 2020 (UTC)
  • Support Support BALA. RTalk 01:30, 9 December 2020 (UTC)
  • Support Support Keepcalmandchill (talk) 02:00, 9 December 2020 (UTC)
  • Support Support Pamzeis (talk) 02:56, 9 December 2020 (UTC)
  • Support Support NMaia (talk) 03:16, 9 December 2020 (UTC)
  • Support Support JopkeB (talk) 05:46, 9 December 2020 (UTC)
  • Support Support Pinerineks (talk) 07:00, 9 December 2020 (UTC)
  • Support Support Philbutler (talk) 07:23, 9 December 2020 (UTC)
  • Support Support Karbohut (talk) 09:49, 9 December 2020 (UTC)
  • Support Support Xavi Dengra (MESSAGES) 12:57, 9 December 2020 (UTC)
  • Support Support TheImaCow (talk) 17:14, 9 December 2020 (UTC)
  • Support Support Monozigote (talk) 17:18, 9 December 2020 (UTC)
  • Support Support Петър Петров (talk) 17:35, 9 December 2020 (UTC)
  • Support Support Rafael (stanglavine) msg 18:36, 9 December 2020 (UTC)
  • Oppose 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 Support TheAmerikaner (talk) 20:33, 9 December 2020 (UTC)
  • Support Support Thomas Kinz (talk) 21:12, 9 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 02:04, 10 December 2020 (UTC)
  • GA candidate.svg Weak support Unbeatable101 (talk) 04:15, 10 December 2020 (UTC)
  • Comment 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 Support - yona B. (D) 08:13, 10 December 2020 (UTC)
  • Support Support Nonahg (talk) 09:01, 10 December 2020 (UTC)
  • Support Support Crocodile2020 (talk) 09:27, 10 December 2020 (UTC)
  • Support Support Euro know (talk) 11:23, 10 December 2020 (UTC)
  • Support Support Tim bates (talk) 15:43, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 20:28, 10 December 2020 (UTC)
  • Support Support NaBUru38 (talk) 21:08, 10 December 2020 (UTC)
  • Support Support Titore (talk) 23:56, 10 December 2020 (UTC)
  • Support Support Higa4 (talk) 05:01, 11 December 2020 (UTC)
  • Support Support Cryout (talk) 10:05, 11 December 2020 (UTC) great AI addition for better use experience
  • Support Support Paucabot (talk) 12:30, 11 December 2020 (UTC)
  • Support Support Susanna Giaccai (talk) 16:38, 11 December 2020 (UTC)
  • Support Support Szalax (talk) 17:18, 11 December 2020 (UTC)
  • Support Support BoldLuis (talk) 18:14, 11 December 2020 (UTC)
  • Support Support It wouldn't have to be complicatedRosičák (talk) 18:25, 11 December 2020 (UTC)
  • Support Support Anaxial (talk) 18:55, 11 December 2020 (UTC)
  • Support Support MathieuMD (talk) 19:06, 11 December 2020 (UTC)
  • Support Support Pinnermck (talk) 20:24, 11 December 2020 (UTC)
  • Support Support Somej (talk) 21:12, 11 December 2020 (UTC)
  • Support Support Stevenliuyi (talk) 22:26, 11 December 2020 (UTC)
  • Support Support Tom Ja (talk) 10:04, 12 December 2020 (UTC)
  • Support Support Kon Gl (talk) 14:16, 12 December 2020 (UTC)
  • Support Support. Meiræ 21:51, 12 December 2020 (UTC)
  • Support Support Consulnico (talk) 01:00, 13 December 2020 (UTC)
  • Support Support Kew Gardens 613 (talk) 02:48, 13 December 2020 (UTC)
  • Support 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 Support Geagea (talk) 14:25, 13 December 2020 (UTC)
  • Support Support Sounds great. Anything to improve search. Bodysurfinyon (talk) 02:34, 14 December 2020 (UTC)
  • Support Support Fra4481 (talk) 10:41, 14 December 2020 (UTC)
  • Support Support Sadads (talk) 11:52, 14 December 2020 (UTC)
  • Support Support Rhetos (talk) 12:33, 14 December 2020 (UTC)
  • Support 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 Support Nurtenge (talk) 06:54, 15 December 2020 (UTC)
  • Support 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 Support β16 - (talk) 09:57, 15 December 2020 (UTC)
  • Support Support MTheiler (talk) 15:20, 15 December 2020 (UTC)
  • Support Support. Shalomori123 (talk) 17:41, 15 December 2020 (UTC)
  • Support Support Utopes (talk) 19:21, 15 December 2020 (UTC)
  • Neutral 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 Support Jstalins (talk) 04:25, 16 December 2020 (UTC)
  • Support Support Rhymes (talk) 18:18, 17 December 2020 (UTC)
  • Support Support Kocgs (talk) 20:46, 17 December 2020 (UTC)
  • Support Support ~~ Alex Noble - talk 14:49, 18 December 2020 (UTC)
  • Support Support Mmitchell10 (talk) 20:10, 18 December 2020 (UTC)
  • Support Support Patsagorn Y. (Talk) 05:01, 19 December 2020 (UTC)
  • Support Support 常规搜索页面搜索不到相应内容,需要加强 郑洲扬 (talk) 12:45, 20 December 2020 (UTC)
  • Support Support BradChim (talk) 14:51, 20 December 2020 (UTC)
  • Support Support S8321414 (talk) 14:37, 21 December 2020 (UTC)
  • Support 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 Support Imetsia (talk) 18:57, 8 December 2020 (UTC)
  • Oppose 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 Support This can be implemented without javascript. I find it very useful. Martinkunev (talk) 23:07, 8 December 2020 (UTC)
  • Oppose 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 Comment Good point, this should be a configuration option. Martinkunev (talk) 14:31, 9 December 2020 (UTC)
  • Support Support --Ciao • Bestoernesto 00:37, 9 December 2020 (UTC)
  • Support Support BALA. RTalk 01:28, 9 December 2020 (UTC)
  • Support Support Петър Петров (talk) 17:34, 9 December 2020 (UTC)
  • Oppose 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 Support TheAmerikaner (talk) 20:32, 9 December 2020 (UTC)
  • Support 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 Support RohMusik (talk) 23:31, 9 December 2020 (UTC)
  • Strongest possible Oppose 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 Support as an option per Silver hr; Oppose Oppose as default/mandatory. George Ho (talk) 07:45, 10 December 2020 (UTC)
  • Support 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 Support no brainer Bodysurfinyon (talk) 02:31, 14 December 2020 (UTC)
  • Support Support Philiptdotcom (talk) 13:38, 14 December 2020 (UTC)
  • Oppose 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 Support No JavaScript required, so... I'm ok! TechAcquisitor (talk) 19:56, 15 December 2020 (UTC)
  • Oppose 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 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 Support MarioSuperstar77 (talk) 20:19, 8 December 2020 (UTC)
  • Support Support Would be useful tufor (talk) 20:40, 8 December 2020 (UTC)
  • Support Support as proposer. Certes (talk) 21:22, 8 December 2020 (UTC)
  • Support Support --Ciao • Bestoernesto 01:31, 9 December 2020 (UTC)
  • Support Support Петър Петров (talk) 17:35, 9 December 2020 (UTC)
  • Oppose 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 Support NaBUru38 (talk) 21:07, 10 December 2020 (UTC)
  • Support Support Izno (talk) 22:41, 10 December 2020 (UTC)
  • Support Support Philiptdotcom (talk) 13:39, 14 December 2020 (UTC)
  • Support Support β16 - (talk) 09:56, 15 December 2020 (UTC)
  • Support Support solitary oppose is frankly incomprehensible – Teratix 06:45, 16 December 2020 (UTC)
  • Support Support Kku (talk) 07:26, 17 December 2020 (UTC)
  • Support 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 Support Sagivrash (talk) 19:16, 8 December 2020 (UTC)
  • Support Support Movses (talk) 19:31, 8 December 2020 (UTC)
  • Support Support MarioSuperstar77 (talk) 20:17, 8 December 2020 (UTC)
  • Support Support very important feature, wanted since long time Akela (talk) 20:38, 8 December 2020 (UTC)
  • Support Support tufor (talk) 20:39, 8 December 2020 (UTC)
  • Support Support Samat (talk) 20:51, 8 December 2020 (UTC)
  • Support Support Hkoala (talk) 20:56, 8 December 2020 (UTC)
  • Support Support --Pagony (talk) 21:04, 8 December 2020 (UTC)
  • Support Support ZorróAszter (talk) 21:12, 8 December 2020 (UTC)
  • Support Support as an option but keep the existing behaviour as default Certes (talk) 21:21, 8 December 2020 (UTC)
  • Support Support Pi.1415926535 (talk) 21:25, 8 December 2020 (UTC)
  • Support Support Palotabarát (talk) 21:39, 8 December 2020 (UTC)
  • Support Support --Dodi123 (talk) 22:20, 8 December 2020 (UTC)
  • Support Support tsca (talk) 22:51, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 23:03, 8 December 2020 (UTC)
  • Support Support — Jules Talk 23:26, 8 December 2020 (UTC)
  • Support Support Alensha (talk) 01:19, 9 December 2020 (UTC)
  • Support Support BALA. RTalk 01:30, 9 December 2020 (UTC)
  • Support Support Hanif Al Husaini (talk) 02:06, 9 December 2020 (UTC)
  • Support Support kennethaw88talk 05:56, 9 December 2020 (UTC)
  • Support Support Teemeah (talk) 09:17, 9 December 2020 (UTC)
  • Support Support Worrida (talk) 11:50, 9 December 2020 (UTC)
  • Support SupportRhododendrites talk \\ 14:33, 9 December 2020 (UTC)
  • Support Support Yes, same as Draceane Ján Kepler (talk) 14:44, 9 December 2020 (UTC)
  • Support Support Pharos (talk) 14:57, 9 December 2020 (UTC)
  • Support Support Mannivu · 15:06, 9 December 2020 (UTC)
  • Support Support Geraki TL 16:39, 9 December 2020 (UTC)
  • Support Support We need this. Петър Петров (talk) 17:26, 9 December 2020 (UTC)
  • Oppose 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 Support Netjeff (talk) 19:17, 9 December 2020 (UTC)
  • Support 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 Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:18, 9 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 02:05, 10 December 2020 (UTC)
  • Support Support as an option per Certes and Jan Dudik; Oppose Oppose as default/mandatory. George Ho (talk) 07:40, 10 December 2020 (UTC)
  • Support Support Ostrzyciel (talk) 13:18, 10 December 2020 (UTC)
  • Support Support Nk (talk) 14:01, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 20:26, 10 December 2020 (UTC)
  • Support Support Bencemac (talk) 16:10, 11 December 2020 (UTC)
  • Support Support OosWesThoesBes (talk) 17:29, 11 December 2020 (UTC)
  • Support Support czar 18:51, 11 December 2020 (UTC)
  • Support Support Oh, DrPizza! (talk) 08:31, 12 December 2020 (UTC)
  • Support Support. Meiræ 21:50, 12 December 2020 (UTC)
  • Support Support ~ Amory (utc) 13:27, 14 December 2020 (UTC)
  • Support 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 Support WhatamIdoing (talk) 19:37, 14 December 2020 (UTC)
  • Support Support WTM (talk) 00:26, 15 December 2020 (UTC)
  • Support 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 Support with keeping the current situation as the default. Tacsipacsi (talk) 10:03, 15 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 13:39, 15 December 2020 (UTC)
  • Support Support MTheiler (talk) 15:23, 15 December 2020 (UTC)
  • Support Support SeGiba (talk) 18:06, 15 December 2020 (UTC)
  • Support Support Michael Childs (talk) 01:42, 17 December 2020 (UTC)
  • Support Support Adam78 (talk) 10:37, 17 December 2020 (UTC)
  • Support 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 Support MarioSuperstar77 (talk) 20:21, 8 December 2020 (UTC)
  • Support Support Pmau (talk) 21:41, 8 December 2020 (UTC)
  • Support Support tsca (talk) 22:50, 8 December 2020 (UTC)
  • Support Support Silver hr (talk) 00:08, 9 December 2020 (UTC)
  • Support Support --Ciao • Bestoernesto 01:36, 9 December 2020 (UTC)
  • Support Support PianistHere (talk) 01:59, 9 December 2020 (UTC)
  • Support Support Kaldari (talk) 02:52, 9 December 2020 (UTC)
  • Support Support OrCer (talk) 11:15, 9 December 2020 (UTC)
  • Support Support Heartbeaz (talk) 11:15, 9 December 2020 (UTC)
  • Oppose 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 Support Rafael (stanglavine) msg 18:53, 9 December 2020 (UTC)
  • Support Support - Darwin Ahoy! 02:04, 10 December 2020 (UTC)
  • Support Support - yona B. (D) 08:12, 10 December 2020 (UTC)
  • Support Support Nk (talk) 14:04, 10 December 2020 (UTC)
  • Support Support 14:24, 10 December 2020 (UTC)
  • Support Support Libcub (talk) 20:27, 10 December 2020 (UTC)
  • Support Support Alexcalamaro (talk) 22:36, 10 December 2020 (UTC)
  • Support Support Dhx1 (talk) 13:22, 11 December 2020 (UTC)
  • Support Support 4nn1l2 (talk) 16:00, 11 December 2020 (UTC)
  • Support Support Arnd (talk) 17:09, 11 December 2020 (UTC)
  • Support Support Good idea. BoldLuis (talk) 18:15, 11 December 2020 (UTC)
  • Support Support Sounds pretty awesome to me! -- Mathieugp (talk) 18:16, 11 December 2020 (UTC)
  • Support Support Anaxial (talk) 18:56, 11 December 2020 (UTC)
  • Support Support MathieuMD (talk) 19:08, 11 December 2020 (UTC)
  • Support Support Tom Ja (talk) 10:06, 12 December 2020 (UTC)
  • Support Support Yiyi (talk) 19:17, 12 December 2020 (UTC)
  • Support Support. Meiræ 21:52, 12 December 2020 (UTC)
  • Support Support Gelli1742 (talk) 20:21, 13 December 2020 (UTC)
  • Support Support — Draceane talkcontrib. 13:37, 15 December 2020 (UTC)
  • Support SupportÉpico (talk)/(contribs) 23:58, 16 December 2020 (UTC)
  • Support Support Golmore (talk) 06:59, 18 December 2020 (UTC)
  • Support SupportOmegatron (talk) 15:03, 20 December 2020 (UTC)
  • Support 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 Support ValeJappo【〒】 18:29, 8 December 2020 (UTC)
  • Support Support Noé (talk) 19:32, 8 December 2020 (UTC)
  • Support 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 Support T. Le Berre (talk) 19:42, 8 December 2020 (UTC)
  • Support Support As a suggestion, it should be located in statistics. MarioSuperstar77 (talk) 20:16, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 23:04, 8 December 2020 (UTC)
  • Support Support — Jules Talk 23:27, 8 December 2020 (UTC)
  • Support Support PianistHere (talk) 01:57, 9 December 2020 (UTC)
  • Support Support Alkari (talk) 03:21, 9 December 2020 (UTC)
  • Support Support Yeenosaurus (talk) 03:45, 9 December 2020 (UTC)
  • Support Support Ottawajin (talk) 05:08, 9 December 2020 (UTC)
  • Support 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 Support Abductive (talk) 09:06, 9 December 2020 (UTC)
  • Support Support This could help us better serve readers by addressing content gaps. {{u|Sdkb}}talk 10:28, 9 December 2020 (UTC)
  • Support Support Xavi Dengra (MESSAGES) 12:55, 9 December 2020 (UTC)
  • Support Support Hb2007 (talk) 13:23, 9 December 2020 (UTC)
  • Support Support TheImaCow (talk) 17:14, 9 December 2020 (UTC)
  • Oppose Oppose due to the privacy concerns mentioned in the discussion section. --Петър Петров (talk) 17:39, 9 December 2020 (UTC)
  • Oppose 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 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 Support dwf² (talk) 23:07, 9 December 2020 (UTC)
  • Support Support Anaxial (talk) 18:57, 11 December 2020 (UTC)
  • Support Support Wanax01 (talk) 16:02, 12 December 2020 (UTC)
  • Support Support SkSlick (talk) 19:41, 12 December 2020 (UTC)
  • Support Support Kew Gardens 613 (talk) 02:48, 13 December 2020 (UTC)
  • Symbol oppose vote oversat.svg 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 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 Support great way to improve wiki content/relevant search terms within articles/titles Philiptdotcom (talk) 13:42, 14 December 2020 (UTC)
  • Support Support in theory, only if the data can be sanitized of an privacy concerns.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:08, 15 December 2020 (UTC)
  • Oppose Oppose per Bilorv. — Épico (talk)/(contribs) 00:00, 17 December 2020 (UTC)
  • Support Support Rhymes (talk) 18:22, 17 December 2020 (UTC)
  • Support 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 Support Imetsia (talk) 18:55, 8 December 2020 (UTC)
  • Support 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 Support --NGC 54 (talk / contribs) 19:59, 8 December 2020 (UTC)
  • Support Support ...Or if that page appears in your watchlist. I definitely support that feature. MarioSuperstar77 (talk) 20:15, 8 December 2020 (UTC)
  • Support Support Pmau (talk) 21:41, 8 December 2020 (UTC)
  • Support Support Good idea شادي (talk) 22:29, 8 December 2020 (UTC)
  • Support Support YFdyh000 (talk) 23:01, 8 December 2020 (UTC)
  • Support Support Eric0892 (talk) 01:09, 9 December 2020 (UTC)
  • Support Support BALA. RTalk 01:29, 9 December 2020 (UTC)
  • Support Support Hanif Al Husaini (talk) 02:06, 9 December 2020 (UTC)
  • Comment 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 Support Baltakatei (talk) 16:54, 9 December 2020 (UTC)
  • Oppose 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 Support BoldLuis (talk) 18:13, 11 December 2020 (UTC)
  • Oppose 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 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 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

  • GA candidate.svg Weak support Why not? MarioSuperstar77 (talk) 20:18, 8 December 2020 (UTC)
  • Support Support --Ciao • Bestoernesto 01:06, 9 December 2020 (UTC)
  • Support SupportOmda4wady (talk) 07:09, 9 December 2020 (UTC)
  • Support Support Frhdkazan (talk) 12:04, 9 December 2020 (UTC)
  • Oppose 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