Search
5 proposals, 162 contributors, 233 support votes
The survey has closed. Thanks for your participation :)



Change default number of search results displayed

  • Problem: Currently, when using the Search Special page, only 20 results are displayed per page by default. This is too small to navigate between pages of results.
  • Proposed solution: There should be a user preference to choose the default number of results per page.
  • Who would benefit: Every user wanting to avoid changing number of results per page for each search.
  • More comments:
  • Phabricator tickets: phab:T215716
  • Proposer:  ◄ David L • talk ► 00:31, 11 January 2022 (UTC)Reply[reply]

Discussion

  • I would use this. Should be relatively simple to implement. · · · Peter (Southwood) (talk): 07:00, 11 January 2022 (UTC)Reply[reply]
  • Yes please. I usually have to bother the servers twice, by retrieving a useless sample of 20 random results then clicking 500 to get the list I wanted. Certes (talk) 18:43, 11 January 2022 (UTC)Reply[reply]
    @Certes Maybe this particular issue could already be solved by allowing the number of results to be configured in the advanced search options at Special:Search. A setting to change the default would then add allow for additional convenience. Also plugging ru:Участник:Facenapalm/highlimits.js in case you want to access over 500 results at once without needing to change the URL parameter manually. ~~~~
    User:1234qwer1234qwer4 (talk)
    20:14, 11 February 2022 (UTC)Reply[reply]
    Yes, if this doesn't happen then I'll simulate it locally with JavaScript, as with Community Wishlist Survey 2022/Watchlists/Preference to set default watchlist expiry, but it would help both us and the servers to build it in. Certes (talk) 22:59, 11 February 2022 (UTC)Reply[reply]
  • I would love to have this, especially for expensive queries (like complex regex queries) that likely time out. It's not just inconvenient for me as a user, it's an unnecessary drain on the search servers to re-do the query (whether to get a second page of results or to go from 20 to 500 results). Either a default user preference or a way to indicate a number of results for a specific query would be useful. Trey314159 (talk) 20:39, 14 January 2022 (UTC)Reply[reply]
  • I also would use this! Thanks for this proposal! — The preceding unsigned comment was added by Dwain Zwerg (talk) 09:25, 20 January 2022 (UTC)Reply[reply]
  • It would be good if this could also be an admin- or user-level setting--Spiros71 (talk) 12:42, 29 January 2022 (UTC)Reply[reply]
  • (edit: posted previous under a wrong suggestion) Yes, 20 results as default is too little. SSneg (talk) 21:16, 29 January 2022 (UTC)Reply[reply]
  • Would have supported if I had known voting ended at 18 UTC. This feature already exists for watchlists/recent changes, so why not for search as well? ~~~~
    User:1234qwer1234qwer4 (talk)
    20:09, 11 February 2022 (UTC)Reply[reply]

Voting

Highlight and scroll to search term on result page

  • Problem: When I search the wiki for a term and select an page to read, I may not immediately see where that term is used on the page.
  • Proposed solution: Highlight and scroll to where the search term is mentioned on the result page
  • Who would benefit: Readers who use the search feature
  • More comments:
  • Phabricator tickets:
  • Proposer: Cinokat (talk) 09:52, 18 January 2022 (UTC)Reply[reply]

Discussion

I think the user means that if they search for a term, and the term is mentioned somewhere in a result, that when opening the result, they want the search term to be highlighted and scrolled to. —TheDJ (talkcontribs) 11:24, 18 January 2022 (UTC)Reply[reply]

That's how that reads to me as well. --Izno (talk) 19:40, 18 January 2022 (UTC)Reply[reply]
I've edited the Problem statement (mostly JI, plus some minor grammar improvements) to reflect this understanding (which is also how I read the origiinal). Trey314159 (talk) 17:38, 24 January 2022 (UTC)Reply[reply]
I have also interpreted it this way and taken it a bit further to fill out all the other fields. Pinging Cinokat. Let us know know if we've misunderstood you. Thanks, MusikAnimal (WMF) (talk) 05:12, 27 January 2022 (UTC)Reply[reply]
When you google a phrase and then click on a link to a Wiki page, the page scrolls to the phrase and the phrase is highlighted. It is probably speicific to Google.com + Chrome browser but definitely a very useful feature. So I guess implementing similar functionality inside wiki engine is welcome. SSneg (talk) 09:49, 2 February 2022 (UTC)Reply[reply]
Google has two features for this. Their snippets do the highlighting, with text fragment highlighting. Next to Chrome, this is currently also in development for Safari, possibly shipping in Safari 16 later this year. In addition, they sometimes use sections results. Here, if they have a highlight in a particular section, they show the multiple subsections in the page (say History, Politics, Geography etc), and then if you click the result for such a section, it takes you there using a normal H2 anchor. —TheDJ (talkcontribs) 16:46, 7 February 2022 (UTC)Reply[reply]

Voting

Close the outdated WiViVi and reintegrate its key features into Wikimedia Stats

  • Problem: WiViVi was discontinued in 2018 after Erik Zachte retired as WMF's Data Analyst and some of its key features are not accessible anymore nor active on Wikimedia Stats. Without this tool, it is currently impossible to assess the outreach of a wiki linguistical community within a country.
  • Proposed solution: Integrate a browsing option that allows to search each wiki-specific pageviews as percentage to language for all worldwide countries. For example: In Spain 72% of the Wikipedia views are in Spanish, while 16% in English —but only 3.8% in Catalan or 0.4% in Basque (as of 2018; Asturian or Occitan are also indigenous languages in Spain but with such low % that cannot even access their proportional views). It is also important to be able to compare it with both native and total speakers, so that it can easily be seen if that wiki receives more or less views than expected by its speakers. The linguistical data can be easily taken by Wikidata, if available. For example: being able to check that only 15% of Wikipedia views in Andorra are in Catalan. Based on this value, if provided by Wikidata that Andorra has a population of 78K people, plus if provided by Wikidata that 40% have Catalan as their mother tongue, it can be seen that Catalan Wikipedia in Andorra is cleary underused (15% views in Catalan vs 40% native speakers of Catalan).
  • Who would benefit: All minoritized languages that really need to know which is the visit share (%) of their wikis as compared to the major or official language that is spoken within the borders of a country. This can help communities to plan their institutional collaborations and language use awareness.
  • More comments: Regional level would be desirable in the future. Percentages should be able to have a low cutoff or filter by specific language, in order to foresee very minoritized languages.
  • Phabricator tickets: phab:T257071, phab:T284294
  • Proposer: Xavi Dengra (MESSAGES) 19:08, 16 January 2022 (UTC)Reply[reply]

Discussion

That is a wonderful wish Xavi, and I like the focus on giving visibility to minoritized languages. I will check in with the Data Engineering team to see if this is something we could get done with one wishlist cycle. KSiebert (WMF) (talk) 13:59, 17 January 2022 (UTC)Reply[reply]
Because WiViVi is outdated I created commons:File:Most popular edition of Wikipedia by country.svg. I used the existing API to do so and this fairly simple piece of code. Unfortunately, it needs to be updated regularly. As you can see, the image is used on several articles in many editions of Wikipedia so I guess this data is considered useful. I opened a Phabricator ticket in July 2020 about this feature request. An interactive map like WiViVi would be better to display countries where a language is not #1 but still often used. For instance French in Canada and Morocco, Romanian in Romania, English in Eastern Europe, etc. As @Xavier Dengra: said regional subdivisions would be great. I opened another Phabricator ticket for that in June 2021. Without regional subdivisions, the map lacks granularity and under-represent "small languages", as mentioned in the ticket: "we have a unit on the map for Malta with 0.4m inhabitants, but not for West Bengal with 180m inhabitants". A455bcd9 (talk) 07:38, 19 January 2022 (UTC)Reply[reply]
That's a great job, thank you for reaching out @A455bcd9! Creating automated maps via Commons to attach to articles is always a good idea, but in terms of basic communication, general awareness, research and data collection is not feasible. If there is a centralized option like Wikimedia Stats, which we all expect to be the "officially mantained" we cannot keep disseminating tools, patches and visualizations along the servers or repositories: neither the general public nor even most of wikipedians will find them. The depart of Erik Zachte and the "still-visible corps" of WiViVi sums up to the many examples of what shouldn't be repeated. There is not even a "last update" of the page and that leads to big confusion, therefore removing it or with a big outdated banner seem the only solution for me. For the interactive map, this is the Wikimedia Stats one that could integrate this Wish. However, it is worth to mention how unacceptable is the WM Stats current map: does not even include, for example, Andorra or San Marino in Europe, and forgets most of the states of the Pacific. At this point, several people in the world cannot even browse the views of Wikipedia in their country. Overall, a very anglocentric point of view not in line with the ongoing equity recommendations. Xavi Dengra (MESSAGES) 08:28, 19 January 2022 (UTC)Reply[reply]
I totally agree that everything should be on Wikimedia Stats, and the map I created is, I hope, only a temporary workaround in the absence of a good and officially maintained interactive map.
I think you could add the two Phabricator tickets I opened in your submission btw ("Phabricator tickets:") A455bcd9 (talk) 10:12, 19 January 2022 (UTC)Reply[reply]
  Done Xavier Dengra (MESSAGES) 23:31, 21 January 2022 (UTC)Reply[reply]

Voting

Enable negation for tag filters

Discussion

Voting

Search bar with gear toggle

  • Problem: There is no way to quickly configure different search results, with the toggle settings you can see a variety of results in the shortest time With this button, you can add a variety of suggested settings to the search bar to find the article or topic in the shortest time.
  • Proposed solution: Add a gear toggle to the Wikipedia search bar
  • Who would benefit: Readers, users, editors, and all people will benefit
  • More comments:
  • Phabricator tickets:
  • Proposer: Mohammad ebz (talk) 16:33, 11 January 2022 (UTC)Reply[reply]

Discussion

  • Doesnt Special:Search have a whole host of different options for people ? I'm really confused about what these settings that you are proposing should be doing and why it would benefit users. —TheDJ (talkcontribs) 13:22, 12 January 2022 (UTC)Reply[reply]
    @Mohammad ebz: I think I understand your problem, you want to be able to specify options when doing a search. It sounds like the workflow you are suggesting is:
    1. Click on new gear Icon
    2. Fill out search parameters
    3. Click Search
    If so, you may not be aware that this workflow is already available, for step 1: under the search box click "Search" without putting any values in the search box, this will then leave you at step 2 above. — xaosflux Talk 16:02, 14 January 2022 (UTC)Reply[reply]
    @Xaosflux But it is longer, it should be easier and more beautiful, it should open like a bootstrap model or a small window in the form of a tool Twinkle. مهدی بهرامی مطلق (talk) 07:41, 5 February 2022 (UTC)Reply[reply]

@Xaosflux and TheDJ: I meant that when you type words in the search bar (of course I mean in the new search bar, which is not yet embedded in all Wikipedias and other wiki, {For example, you can try the new search bar on the French Wikipedia page}) the results are displayed in a certain order; The toggle tool, for example, makes it possible to arrange the preview of articles quickly, in fact the goal is to add much more useful features in the form of a small button next to the search bar (a useful part of the advanced search tool in it), In addition, the advanced search page has its proper use in its place, the goal is to facilitate the search based on the desired layout and simple and practical tools for the small menu at the top of each wiki page. It will take more time if we want to go to the advanced search page for simple searches (Remember that the overall purpose of this offer is to facilitate and speed up the search)

  • Similar to above, same number of clicks - if you click "Search" while the box is blank it shows the additional options, same as if you would click on a new "gear icon" - not sure what I'm missing here other than possible UI improvement? — xaosflux Talk 15:36, 17 January 2022 (UTC)Reply[reply]
  • Aside comment 1: Using Safari/iOS12 the new-Vector search box on w:fr: doesn't appear, just a right-aligned magnifying-glass icon. On iOS15 it is present and works as expected. I imagine there is some reason that it is disabled on certain older OSs? Is this going to affect future Vue.js widgets also? Pelagic (talk) 01:36, 30 January 2022 (UTC)Reply[reply]
  • Aside comment 2: Special:Search doesn't work for me on mobile/Minerva, it just renders the title “Search” with no text box or widgets. (Multiple OS, with and without AMC.) Pelagic (talk) 01:36, 30 January 2022 (UTC)Reply[reply]
    This page works [1], but without profile=advanced, this doesn't [2]. The latter is what I'm taken to if I do an empty search on mobile. Pelagic (talk) 02:00, 30 January 2022 (UTC)Reply[reply]
    I filed phab:T300451 and phab:T300452 for this second issue. Pelagic (talk) 04:55, 30 January 2022 (UTC)Reply[reply]

Voting