Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Search

< Community Wishlist Survey 2016
Search
11 proposals, 130 contributors, 205 support votes



Visible category trees

  • Problem: The allocation of pages to categories is very much subject to individual interpretations, allowing for the development of parallel and/or overlapping categories. For example, there are pages grouped under "forests" - "forests in country XX" - "ecosistems" - "country XX" - "geography of XX" - geography of region YY (within country XX)".
  • Who would benefit: Users making specific researches within a certain sector. Editors with no clear idea about the level of organisation of the categories. Adminstrators and dirty-jobbers willing to improve the organisational framework.
  • Proposed solution: Make the category tree visible including a certain number of levels up and down.
  • Phabricator tickets:

Community discussion

I wonder if it's possible to use mw:Graph to do this (e.g. plugging w:en:Category:Domesticated animals into the API and outputting a Radial tree). @Yurik: is that possible, or can do you know of other ways we could accomplish this with existing tools?
@Lichinga: Please clarify in your proposal above, whether (and why) you think we would need this visualization built into (A) the article page directly), (B) a separate wiki page (perhaps a Special: page) would be ok, or (C) it would be ok if it was on wmflabs, as an external tool. Thanks! Quiddity (WMF) (talk) 00:28, 25 November 2016 (UTC)[reply]
  • I think (A) would be preferrable, my idea is that this may facilitate a correct and logical allocation of pages to categories. When you creat/edit a page, you have no idea of where similar pages have been placed. For instance, you create a page about a Tanzania beverage, then you wonder if that should go under "Alcoholic drinks" - "Alcoholic drinks of Tanzania" - "Alcoholic drinks of Africa" - "Distilled drinks" etc etc, if you have an easy tools to consult existing categories, it would be easier to make an informed decision. --Lichinga (talk) 14:09, 26 November 2016 (UTC)[reply]
  •  
    Kategoriebaum von der Kategorie Rhein in dewiki
  •  
    Category tree of Category Rhine in enwiki

Voting – Visible category trees

  1.   Support Libcub (talk) 03:02, 2 December 2016 (UTC)[reply]
  2.   Support SamanthaNguyen (talk) 04:11, 2 December 2016 (UTC)[reply]
  3.   Support, see this for a tree-view of categories (however not multiple levels and not the way described very roughly here); see these: [1], [2], [3], [4] for visualizations (none the way described here). However I'm not entirely sure how you'd suggest those trees should look like. --Fixuture (talk) 19:02, 2 December 2016 (UTC)[reply]
  4.   Support --Acky69 (talk) 17:28, 3 December 2016 (UTC)[reply]
  5.   Neutral until I see a mock-up that won't go over the heads of most readers and editors. The basic idea is useful. Stevie is the man! Talk • Work 22:36, 4 December 2016 (UTC)[reply]
  6.   Support, to show related categories. It is an excellent idea, especially to quickly reveal "category abuse" as the typical enwiki zillion-subcategory tree under en:Category:Rhine River, divided into a staggering 350(?) sub-categories on enwiki. -Wikid77 (talk) 00:49/00:56, 6 December 2016 (UTC)[reply]
  7.   Support —Ynhockey (talk) 10:40, 7 December 2016 (UTC)[reply]
  8.   Support--Elmidae (talk) 16:36, 7 December 2016 (UTC)[reply]
  9.   Oppose As noted above, a tool for this already exists.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:53, 11 December 2016 (UTC)[reply]
  10.   Support - Helpful. DPdH (talk) 19:34, 11 December 2016 (UTC)[reply]
  11.   Support--David1010 (talk) 20:43, 11 December 2016 (UTC)[reply]
  12.   Support this is something so basic that it needs to be available by default across the board, rather than provided by an optional external tool. – Uanfala (talk) 01:26, 12 December 2016 (UTC)[reply]
  13.   Support Turn the existing plain-image-generating visualizer (mentioned above) into a proper clickable fly-through interface. (e.g. https://tools.wmflabs.org/vcat/render?wiki=enwiki&category=Domesticated_animals for w:en:category:Domesticated animals). Quiddity (talk) 09:38, 12 December 2016 (UTC)[reply]

Allow user-set split of categories by namespace

  • Problem: Currently, there's no easy way to find pages in a specific category and namepace - e.g an article which is in a user category.
  • Proposed solution: Create a new user setting which will cause namespaces chosen by the user to be listed speparately from all other namespaces.

Community discussion

  • I think having a bunch of checkboxes on every category page that allows limiting the results per namespace (with defaults given in preferences) would be a better solution. I don't want to fiddle around in preferences when I want to do this as a one-off. There's no performance issues, the API already does this. MER-C (talk) 06:37, 20 November 2016 (UTC)[reply]

Voting – Allow user-set split of categories by namespace

  1.   Support Libcub (talk) 03:02, 2 December 2016 (UTC)[reply]
  2.   Oppose As noted by the nominator, the tool already exists. This is not WMF dev job, the tool just needs to be ported to other wikis and enabled.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:55, 11 December 2016 (UTC)[reply]

Alphabetic sort function on category view

  • Problem: Editors who frequently add categories often organize categories alphabetically (and request that others do so). The driver of this is that it is then easier for them check if a certain category they are adding on various articles is already present or not.

The problem is that alphabetic organization of categories is completely counter-intuitive to readers, who typically do not have a pre-ordained Wikipedia category name in mind and instead are better served by having categories organized by importance or theme.

  • Who would benefit: Delivery of a method where both alphabetic and thematic groupings could be viewed would benefit both category contributors and readers alike. This would also increase productivity as there would no longer be edit warring over the thematic or alphabetic category listing styles.
  • Proposed solution: This perennial issue could be avoided completely by the introduction of an alphabetical sort function for categories in the article view mode (similar to how table sorting works). The thematic/importance sorting could then be left in the actual wikitext.
  • Phabricator tickets:

Community discussion

  • This seems like a reasonable proposal, although perhaps it best belongs as a new feature of HotCat. It seems to me that even more important than alphabetizing is a need to resolve how categories on a page's category list should be organized by importance or theme. Stevie is the man! Talk • Work 16:22, 19 November 2016 (UTC)[reply]
  • I remember having seen a discussion between editors who support and editors who reject alphabetical sorting. The argument of the rejectors is that it should be sorted by importance/relevance. This may well solve the problem. Marcocapelle (talk) 13:27, 20 November 2016 (UTC)[reply]

Voting – Alphabetic sort function on category view

  1.   Support Libcub (talk) 03:03, 2 December 2016 (UTC)[reply]
  2.   Support SamanthaNguyen (talk) 04:11, 2 December 2016 (UTC)[reply]
  3.   Support, this would be very useful in that it strips away all those annoying category-sorting edits, frees labor time of those doing such, and makes the sorting actually useful in that it's a) sorted alphabetically and b) allows people to change the sorting in a useful way. By the latter I'm referring to sorting them by relevance and theme (e.g. one basic rule would be that categories with the article being eponymous and/or whose main article is the current article have said article set as first category - that should be done automatically as well actually). I'm not sure what is meant with "on category view" here though? --Fixuture (talk) 19:09, 2 December 2016 (UTC)[reply]
  4.   Support - DPdH (talk) 19:36, 11 December 2016 (UTC)[reply]

Built-in CatScan

  • Problem: Sometimes one wants more advanced search that searches specific content in specific categories, articles with specific templates, etc. Sometimes this is useful for editors, sometimes for readers, and sometimes for developers (through the API).
  • Who would benefit: Everyone (readers, editors, developers) who need better search capabilities
  • Proposed solution: Integrate CatScan (or write a similar tool) into MediaWiki itself
  • Phabricator tickets:

Community discussion

@Ynhockey: As CatScan already exists and works, what would be the exact benefits of integrating it into MediaWiki itself? Is this about 3rd party MediaWiki installations? Or is this about Wikimedia community members who are not aware that CatScan exists at a separate web address? Trying to understand the intention behind this request a bit better... --AKlapper (WMF) (talk) 21:25, 17 November 2016 (UTC)[reply]
Both of these are very good reasons, and IMO enough to justify integration (for example, I recently installed MW at work and the lack of common external tools was painful), but that's not my personal reason for making this request. I am asking for two main reasons:
  1. CatScan (and other external tools) are less reliable than integrated MW extensions. I can't count the times when a tool that was critical for my wiki-related task suddenly went offline when I needed it most, or Labs went offline completely. There was also the time when CatScan was under re-development and it took a long time (months) during which the old tool was either unavailable or had limited functionality. Its output also changed so tools that relied on its API needed to be modified (in some cases), including one of my tools. Things like this are unlikely in MW software unless there's a very good global reason to make a change.
  2. CatScan's core functionality is so basic that it's just something you expect to have built-in, and having to go to a new interface is a major inconvenience. This ties in to what you said about not all users being aware of CatScan's existence—advanced search is a feature that's fundamentally geared toward readers, while CatScan is fundamentally geared toward editors, so the people we want to reach the most with this functionality are actually the ones least likely to know about the current option. You can also compare to other popular websites: categories in MW are similar to tags in StackOverflow for example. Imagine if you needed an external tool to search by more than one tag in StackOverflow—it makes no sense at all.
Hope this explained my reasoning. Thanks for taking your time to look at this request. —Ynhockey (talk) 01:24, 25 November 2016 (UTC)[reply]

Voting – Built-in CatScan

  1.   Support --Jarekt (talk) 03:25, 30 November 2016 (UTC)[reply]
  2.   Support --Gestumblindi (talk) 22:01, 1 December 2016 (UTC) I have long thought that this should be a basic functionality of MediaWiki. The potential of categories really is only used if you can combine them for searching, and MediaWiki users (in Wikipedia and other Wikimedia projects as well as other users) shouldn't be dependent on an external tool such as CatScan for this purpose.[reply]
    @Gestumblindi: I guess that's a support? --Fixuture (talk) 19:18, 2 December 2016 (UTC)[reply]
    @Fixuture: It is indeed, fixed/clarified now :-) Gestumblindi (talk) 23:03, 2 December 2016 (UTC)[reply]
  3.   Support Libcub (talk) 02:53, 2 December 2016 (UTC)[reply]
  4.   Support Ashaio (talk) 07:21, 2 December 2016 (UTC)[reply]
  5.   Support especially intersections of categories would be incredible useful. Currently, users create new categories which are in fact only intersections to handle the problem that this feature is not available (see also this discussion) MartinThoma (talk) 14:01, 2 December 2016 (UTC)[reply]
  6.   Support --Kvng (talk) 16:32, 2 December 2016 (UTC)[reply]
  7.   Support, it's very useful and way too underused, unknown and unintegrated. There are many interesting things that become possible with that (by category intersection etc). Note that it shouldn't just be built in for the sake of it but properly integrated so that users may actually find and make use of it - it needs to be properly incorporated into the search. Also isn't it PetScan and not CatScan by now? --Fixuture (talk) 19:18, 2 December 2016 (UTC)[reply]
  8.   Support -- Aspiriniks (talk) 09:40, 4 December 2016 (UTC)[reply]
  9.   Support We should think about our readers, not just about us, the editors. Cheers •   • hugarheimur 11:17, 4 December 2016 (UTC)[reply]
  10.   Support -- Marcus Cyron (talk) 12:04, 4 December 2016 (UTC)[reply]
  11.   Support MGChecker (talk) 13:13, 4 December 2016 (UTC)[reply]
  12.   Support --Anika (talk) 14:10, 4 December 2016 (UTC)[reply]
  13.   Support This important tool naturally fits in with the category system and should be integrated. Not being always available is unacceptable. Stevie is the man! Talk • Work 22:49, 4 December 2016 (UTC)[reply]
  14.   Support --HHill (talk) 10:50, 5 December 2016 (UTC)[reply]
  15.   Support --Hubertl (talk) 13:19, 5 December 2016 (UTC)[reply]
  16.   Support Karmakolle (talk) 13:40, 5 December 2016 (UTC)[reply]
  17.   Support Chewbacca2205 (talk) 19:48, 5 December 2016 (UTC)[reply]
  18.   Support --Atlasowa (talk) 20:06, 5 December 2016 (UTC)[reply]
  19.   Support SamanthaNguyen (talk) 02:04, 6 December 2016 (UTC)[reply]
  20.   Support --Neon Knight (talk) 09:02, 6 December 2016 (UTC)[reply]
  21.   Support --Vachovec1 (talk) 17:55, 6 December 2016 (UTC)[reply]
  22.   Support --Andim (talk) 07:39, 7 December 2016 (UTC)[reply]
  23.   Support --Geolina163 (talk) 08:54, 7 December 2016 (UTC)[reply]
  24.   Support A great idea, overdue. --LatinumPulchrum (talk) 23:28, 7 December 2016 (UTC)[reply]
  25.   Support --OrsolyaVirág (talk) 11:56, 10 December 2016 (UTC)[reply]
  26.   Support --Waldir (talk) 12:03, 10 December 2016 (UTC)[reply]
  27.   Support --Stobaios (talk) 12:39, 10 December 2016 (UTC)[reply]
  28.   Support --NaBUru38 (talk)
  29.   Support - DPdH (talk) 19:42, 11 December 2016 (UTC)[reply]
  30.   Support, it is rather difficult to explain to newbies that yes, there is a tool available to find that small thing in categories — NickK (talk) 22:47, 12 December 2016 (UTC)[reply]

  • Problem: There is no way to track incoming links to pages that are coming from other Wikimedia wikis. I explicitly ran into this issue while cleaning up from en:Wikipedia:Categories for discussion/Log/2016 September 6#Major US cities, where some of the categories for about 20 major US cities potentially have incoming links from other Wikimedia wikis - including the known link(s) from Commons.
For example there is no way to trace Wikisource texts used as citations in Wiktionary. There is no way to trace Wiktionary definitions in Wikipedia.
  • Who would benefit: People removing back-links to deleted pages, or fixing links to disambiguation pages. Readers and contributors can navigate easily from one project to another one. Statistics can be improved by knowing how tied together the projects are.
  • Proposed solution: A cross-wiki "What links here" option. Perhaps expand the scope of Special:WhatLinksHere to include other Wikimedia projects, or a new Special page.
  • Phabricator tickets:

Community discussion

@Od Mishehu: I've copyedited your proposal; please check that I didn't make any mistakes. Thanks. (No reply needed). Quiddity (WMF) (talk) 23:24, 8 November 2016 (UTC)[reply]

Od Mishehu: That's correct as your link isn't a crosswiki-link. And the page says File:Rav Kav.png is not used on other wikis. --Achim (talk) 15:00, 15 November 2016 (UTC)[reply]
Yup, that tool only tracks crosswiki transclusions, not crosswiki links. Quiddity (WMF) (talk) 22:30, 16 November 2016 (UTC)[reply]
  • I can see myself making good use of this. Splendid idea. Stevie is the man! Talk • Work 17:59, 13 November 2016 (UTC)[reply]
  • Waiting for that since years... can at least someone explain why it is not feasible, at least? Or can we at least have something even more basic, like take all the pages that link to a wikidata item, than tell me all the pages that link to them in their respective platform, and put them together in one summary. That's not the same thing as level of depth, and a lot of direct link between platform in the text will be missed, but still it would be something more than we have now. As a skilled user, I could get something useful even from that. Still, cross-wiki connectivity is so difficult to sample for non-commons platforms.--Alexmar983 (talk) 16:40, 16 November 2016 (UTC)[reply]
@Noé and Alexmar983: I've merged part of the description, and part of the other details, plus the 1 comment, from this duplicate. Quiddity (WMF) (talk) 22:53, 16 November 2016 (UTC)[reply]
FYI, I didn't receive the ping but thanks Quiddity (WMF).--Alexmar983 (talk) 06:37, 17 November 2016 (UTC)[reply]
Oh, whoops, probably because I edited parts above, as well as adding content. Ping @Noé: to confirm the above message. Quiddity (WMF) (talk) 17:19, 17 November 2016 (UTC)[reply]
Ok, thanks for the merging. It is a similar suggestion, from different perspective, and that is great. I meet some wiktionarians yesterday (to share a cake for 3M page milestone in French Wiktionary) and someone (@JackPotte: ?) suggests this feature to be very useful for admin to check broken links from other projects when a page is renamed. Noé (talk) 12:36, 21 November 2016 (UTC)[reply]

  1.   Support. I think seeing this new WLH page on particular articles would be eye-opening, and this could lead to fixing issues we can't see today. Stevie is the man! Talk • Work 02:26, 28 November 2016 (UTC)[reply]
  2.   Support Noé (talk) 15:12, 28 November 2016 (UTC)[reply]
  3.   Support JAn Dudík (talk) 22:12, 28 November 2016 (UTC)[reply]
  4.   Support Gareth (talk) 03:06, 29 November 2016 (UTC)[reply]
  5.   Support IKhitron (talk) 12:20, 29 November 2016 (UTC)[reply]
  6.   Support KPFC 💬 14:34, 29 November 2016 (UTC)[reply]
  7.   Support --YMS (talk) 16:30, 29 November 2016 (UTC)[reply]
  8.   Support Guycn2 · ☎ 19:13, 29 November 2016 (UTC)[reply]
  9.   Support - Many times we actually break links by deleting or renaming pages on one wiki, while links forom an other wiki exist. עוד מישהו Od Mishehu 20:32, 29 November 2016 (UTC)[reply]
  10.   Support --Matthiaspaul (talk) 00:26, 30 November 2016 (UTC)[reply]
  11.   Support especially it it includes Wikidata links. --Jarekt (talk) 03:27, 30 November 2016 (UTC)[reply]
  12.   Support Ainali (talk) 10:16, 1 December 2016 (UTC)[reply]
  13.   Support SucreRouge (talk) 18:39, 1 December 2016 (UTC)[reply]
  14.   Support Jsamwrites (talk) 18:49, 1 December 2016 (UTC)[reply]
  15.   Support --Achim (talk) 20:18, 1 December 2016 (UTC)[reply]
  16.   Support → «« Man77 »» [de] 21:56, 1 December 2016 (UTC)[reply]
  17.   Support Oliv0 (talk) 22:46, 1 December 2016 (UTC)[reply]
  18.   Support NMaia (talk) 00:51, 2 December 2016 (UTC)[reply]
  19.   Support Libcub (talk) 02:54, 2 December 2016 (UTC)[reply]
  20.   Support Draceane (talk) 10:35, 2 December 2016 (UTC)[reply]
  21.   Support —Jc86035 (talk) 11:19, 2 December 2016 (UTC)[reply]
  22.   Support --Lam-ang (talk) 16:28, 2 December 2016 (UTC)[reply]
  23.   Support. Matiia (talk) 00:27, 3 December 2016 (UTC)[reply]
  24.   Support Jo-Jo Eumerus (talk, contributions) 09:51, 3 December 2016 (UTC)[reply]
  25.   Support Pamputt (talk) 10:59, 4 December 2016 (UTC)[reply]
  26.   Support --Yeza (talk) 10:03, 5 December 2016 (UTC)[reply]
  27.   Support --HHill (talk) 10:52, 5 December 2016 (UTC)[reply]
  28.   Support --10:17, 9 December 2016 (UTC)
  29.   Support --OrsolyaVirág (talk) 11:57, 10 December 2016 (UTC)[reply]
  30.   Support --Plogeo (talk) 19:20, 10 December 2016 (UTC)[reply]
  31.   Support --Lyokoï (talk) 23:23, 10 December 2016 (UTC)[reply]
  32.   Support --Plagiat (talk) 19:05, 11 December 2016 (UTC)[reply]
  33.   Support - Useful. DPdH (talk) 19:44, 11 December 2016 (UTC)[reply]
  34.   Support – Uanfala (talk) 01:28, 12 December 2016 (UTC)[reply]
  35.   Support Quiddity (talk) 09:26, 12 December 2016 (UTC)[reply]
  36.   Support--Mikheil Talk 21:25, 12 December 2016 (UTC)[reply]
  37.   Support — NickK (talk) 22:48, 12 December 2016 (UTC)[reply]

  • Problem: The "what links here" for a given page "A" lists pages containing templates with link to the page A in addition to pages having direct link to the page A. This produces unwanted extra results in the search list and causes difficulty in detecting links that are incorrectly indicating to page A. For example links to en:Sun Zhigang should be fixed to en:Sun Zhigang incident in some pages such as Weiquan movement, Cui Yingjie and 3 others. To check links to en:Sun Zhigang one has to either open 99 pages or temporarily remove links from 3 templates (which costs ruining their history), wait 20 min to update the search list, then check only 13 remaining pages having real link and finally revert the edits on the templates.
  • Who would benefit: users fixing incorrect links
  • Proposed solution: adding "hide links through templates" to "what links here"

Community discussion

  1.   Support -Nocowardsoulismine (talk) 19:10, 28 November 2016 (UTC)[reply]
  2.   Support Gareth (talk) 03:05, 29 November 2016 (UTC)[reply]
  3.   Support provided that a checkbox to enable/disable this filter would be added as well --Matthiaspaul (talk) 00:13, 30 November 2016 (UTC)[reply]
  4.   Support with option to turn it on and off --Jarekt (talk) 03:30, 30 November 2016 (UTC)[reply]
  5.   Support – Fayenatic london (talk) 22:42, 1 December 2016 (UTC)[reply]
  6.   Support Oliv0 (talk) 22:48, 1 December 2016 (UTC)[reply]
  7.   Support with on/off option. —Patrug (talk) 00:16, 2 December 2016 (UTC)[reply]
  8.   Support Libcub (talk) 02:56, 2 December 2016 (UTC)[reply]
  9.   Support Dalba 04:49, 2 December 2016 (UTC)[reply]
  10.   Support Very useful. With opt-in/out. Draceane (talk) 10:38, 2 December 2016 (UTC)[reply]
  11.   Support --Barcelona (talk) 14:19, 2 December 2016 (UTC)[reply]
  12.   Support --Kvng (talk) 16:25, 2 December 2016 (UTC)[reply]
  13.   Support, it should be noted that a page can be linked from a template AND within an article so this needs to be considered when excluding. --Fixuture (talk) 19:19, 2 December 2016 (UTC)[reply]
  14.   Support only with an on/off option,   Oppose otherwise. Jo-Jo Eumerus (talk, contributions) 09:37, 3 December 2016 (UTC)[reply]
  15.   Support --Yiyi (talk) 15:48, 3 December 2016 (UTC)[reply]
  16.   Support With an on/off feature. -- Kndimov (talk) 22:20, 3 December 2016 (UTC)[reply]
  17.   Support MGChecker (talk) 13:13, 4 December 2016 (UTC)[reply]
  18.   Support -- the wub "?!" 14:03, 4 December 2016 (UTC)[reply]
  19.   Support Stevie is the man! Talk • Work 23:24, 4 December 2016 (UTC)[reply]
  20.   Support --Tbennert (talk) 06:54, 5 December 2016 (UTC)[reply]
  21.   Support --Yeza (talk) 10:04, 5 December 2016 (UTC)[reply]
  22.   Support --Continua Evoluzione (talk) 10:15, 5 December 2016 (UTC)[reply]
  23.   Support 4nn1l2 (talk) 18:36, 5 December 2016 (UTC)[reply]
  24. Mild   Support with lower priority, and only with on/off. --Tryptofish (talk) 00:30, 6 December 2016 (UTC)[reply]
  25.   Support with opt-in/out. --Cobblet (talk) 05:02, 7 December 2016 (UTC)[reply]
  26.   Support — Rhododendrites talk \\ 14:34, 8 December 2016 (UTC)[reply]
  27.   Support Very high necessary, with on/off --Tractopelle-jaune (talk) 15:44, 8 December 2016 (UTC)[reply]
  28.   Support Ayack (talk) 12:00, 9 December 2016 (UTC)[reply]
  29.   Support Much needed. --Waldir (talk) 12:05, 10 December 2016 (UTC)[reply]
  30.   Support This problem is definitely a hassle.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:57, 11 December 2016 (UTC)[reply]
  31.   Support --Plagiat (talk) 19:06, 11 December 2016 (UTC)[reply]
  32.   Support - DPdH (talk) 19:46, 11 December 2016 (UTC)[reply]
  33.   Support Tdslk (talk) 20:08, 11 December 2016 (UTC)[reply]
  34.   Support Will be very helpful. – Uanfala (talk) 01:30, 12 December 2016 (UTC)[reply]
  35.   Support Quiddity (talk) 09:27, 12 December 2016 (UTC)[reply]
  36.   Support, very useful and will reduce complaints about "those navboxes flooding What links here" — NickK (talk) 22:49, 12 December 2016 (UTC)[reply]

Improve user suggestion in Special pages

  • Problem: Special pages such as Special:ListUsers or Special:ActiveUsers have the ability to suggest users based on partial input. Unfortunately, the current suggestions are done alphabetically. Instead, a system similar to the one used for site search should be used.
  • Who would benefit: Users of those special pages
  • Proposed solution: Sort users by number contributions and/or last contribution date

Community discussion

none

Voting – Improve user suggestion in Special pages

  1.   Support – Good idea Guycn2 · ☎ 19:14, 29 November 2016 (UTC)[reply]
      Oppose, aren't there pages for this already? Please see w:Wikipedia:List of Wikipedians by number of edits. --Fixuture (talk) 19:21, 2 December 2016 (UTC)[reply]

List of ______ <- Keyword Issue

  • Who would benefit: Researchers, Users
  • Proposed solution: Throughout the late 20th century, it was never known whether or not Africa had more than "children starving" which broadcasted horrid generalizations. Those who "think outside the box" may attempt these sorts of keywords, and should be able to locate the page without as much effort.
  • Phabricator tickets:

Community discussion

  • @Twillisjr: You're right that the search box at the top right of pages doesn't help with that query. That box perform a prefix search, which means it matches what you're typing to the start of article titles. Since those articles start with "List of", if you jump right to typing the middle section then it doesn't work. As with my reply in an above section, hard coding a solution is a bad idea. We're also not changing away from prefix search any time soon because of server performance reasons. At the very least, I can offer you the consolation that your query, "supermarket africa", actually has pretty awesome results if you run it as a full text query. :-) --Dan Garry, Wikimedia Foundation (talk) 21:59, 21 November 2016 (UTC)[reply]
    • @Deskana (WMF): While I typically agree that hardcoding exceptions to prefix search is bad idea, I'm wondering if this one might be worth an exception. There are about 200,000 list articles on English Wikipedia and most of them start with "List of". I wonder how discoverable they currently are via search. Ryan Kaldari (WMF) (talk) 21:56, 22 November 2016 (UTC)[reply]
      • I don't think it is. For the example given, if you type "supermarket chains in africa" and hit enter you get taken to the search page which has the relevant article as the first result. This situation is exactly what full text search is for. The completion suggester is not meant to be the answer to every kind of search query, and starting to hard-code in exceptions to try to turn it in to that is going to cause a lot of pain further down the line. --Dan Garry, Wikimedia Foundation (talk) 18:57, 28 November 2016 (UTC)[reply]
        • Sure, we don't want this kind of approach to get out of hand, but I think it has been clearly explained how special a case this is. This would be very beneficial to many searchers, who won't necessarily choose to click through to a full search. Stevie is the man! Talk • Work 19:03, 28 November 2016 (UTC)[reply]
          • It's not nearly as much of a special case as you'd think. There is an incredibly large volume of searches on-wiki with an incredibly long tail. In all of our analyses of search query data, this issue has not come up once. The exception will cause more trouble than it is worth. This is especially true when considering that this exception would need to be localised to improve any non-English wikis, thereby increasing the complexity further. Single-case exceptions are generally not the way to solve search relevance problems. --Dan Garry, Wikimedia Foundation (talk) 20:53, 28 November 2016 (UTC)[reply]
            • My vote isn't based on whether the issue has come up for others in research. My vote is about how to make search easier for me as a user and for others, based on my long experience in the Wikipedia. Sometimes we have to go on strong hunches, and yes, this is a common search trip-up...for me. As for implementation on non-en wikis, I would say that unless anyone on these wikis has brought up a similar concern, then just leave them be. Obviously, since this proposal exists and at least one person agrees with it, there is an issue that exists. Voters can decide how much weight to give to it. Stevie is the man! Talk • Work 21:05, 28 November 2016 (UTC)[reply]

Voting – List of ______ <- Keyword Issue

  1.   Support I can see this improving search a lot. Many new users may not even think to type "List of" while searching for particular subjects. And for the not-so-new, we may find more useful articles via the serendipity this proposal would enhance. Stevie is the man! Talk • Work 02:32, 28 November 2016 (UTC)[reply]
  2.   Support -Nocowardsoulismine (talk) 01:38, 29 November 2016 (UTC)[reply]
  3.   Support create an list namespace (list:supermarket chains in Africa)? Strictly speaking, list is not article--Shizhao (talk) 03:30, 29 November 2016 (UTC)[reply]
  4.   Support Semmendinger (talk) 20:07, 1 December 2016 (UTC)[reply]
  5.   Support -- Haku (talk) 00:15, 2 December 2016 (UTC)[reply]
  6.   Support Libcub (talk) 02:57, 2 December 2016 (UTC)[reply]
  7.   Support SamanthaNguyen (talk) 04:11, 2 December 2016 (UTC)[reply]
  8.   Support And what about localization? Draceane (talk) 10:40, 2 December 2016 (UTC)[reply]
  9.   Support, if for server-performance reasons it's currently not possible to implement this for the live-suggestions the partiality of the live-results should be hinted at with a small note like "Full results are shown when pressing enter" with a hoverinfo or something alike. Also redirects to list pages etc should be created (maybe by a bot?) appropriately so that even those lists are shown in the live-results. --Fixuture (talk) 19:27, 2 December 2016 (UTC)[reply]
  10.   Support --Acky69 (talk) 17:21, 3 December 2016 (UTC)[reply]
  11.   Support Pamputt (talk) 11:00, 4 December 2016 (UTC)[reply]
  12.   Support. - Mailer Diablo (talk) 06:56, 7 December 2016 (UTC)[reply]
  13.   Support --Elmidae (talk) 16:38, 7 December 2016 (UTC)[reply]
  14.   Support Miniapolis 20:47, 9 December 2016 (UTC)[reply]
  15.   Support --NaBUru38 (talk)
  16.   Support Would be helpful to readers.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:58, 11 December 2016 (UTC)[reply]
  17.   Support - DPdH (talk) 19:48, 11 December 2016 (UTC)[reply]
  18.   Support FoCuSandLeArN (talk) 23:02, 11 December 2016 (UTC)[reply]
  19.   Support--Mikheil Talk 21:25, 12 December 2016 (UTC)[reply]
  20.   Oppose Cannot be done by CommunityTech and would be much easier to do by a bot. For instance, in Ukrainian correct names will be Список мереж супермаркетів Африки with List and Мережі супермаркетів Африки and without List (different grammar forms), thus one cannot simply omit "list of". This technical feature will have to know grammar of all Wikimedia languages, but I don't think this is a good project for Community Tech — NickK (talk) 23:00, 12 December 2016 (UTC)[reply]

Search recursively in specified categories, to a specified depth

  • Problem: The search function is powerful and can do many things. One thing it cannot do is search "recursively" in subcategories. If one wants to include only pages in certaiwn categories, each category has to be explicitly stated. There are external tools (eg PetScan) that can do this to some extent, but these tools cannot perform other search functions simultaneously (eg look for a certain word in the text etc). Therefore users who want to perform such searches currently have to resort to scripts or home-made programs of some sort (which most users cannot do).
  • Who would benefit: Editors trying to better organize the categories, editors looking for a group of articles lacking sources, etc.
  • Proposed solution:
  • More comments: (There is a user javascript, "Deepcat", which sort of implements this, but it lacks the possibility to specify how deep to search, and this should really be a function of the platform itself.)
  • Phabricator tickets:

Community discussion

deepcat is not a user script, but an offical tool by the WMDE. You can change the search deepth by setting a javascript variable. The low default value is there because of compability with very old web browsers. However nearly nobody knows about this even in german wikipedia. This should be made a gadget available to all WMF projects. --𝔊 (Gradzeichen Diſk✉Talk) 16:09, 7 November 2016 (UTC)[reply]

Yes, that is correct. Maybe "user script" was a wrong term. Anyway, it is a user script in the sense that it has to be activated by each user, and cannot be used by non-logged in users. Of course, it could be put in the global javascript. Also, setting a javascript variable is not very convenient for most users. To search recursivly in subcategories, at a suitably chosen depth, in combination with other conditions, should be a feature of the search function itself. Maybe the "Deepcat" gadget could be a model for the technical solution, I don't know. /NH 18:37, 7 November 2016 (UTC)[reply]
Suggesting to change a javascript variable is no solution for 95 percent of the community, if not more than that. --oSeveno (talk) 13:32, 14 November 2016 (UTC)[reply]
One thing you can do: Make a list from other tools, save it in your userspace. Have PetScan do a deep scan for the category tree, looking only for pages which are linked from your userspace list - see the templates and links tab. עוד מישהו Od Mishehu 12:47, 15 November 2016 (UTC)[reply]
That is one way. Another one is to download a database dump, and somehow extract the information from it. But very few users can do this. /NH 17:26, 15 November 2016 (UTC)[reply]

Wiktionary: Discussing that with some wiktionarian mates, it appears this feature may be very suitable for Wiktionaries as it offer a way to search only words in one language. Every Wiktionary project have entries in several languages (more than 4.000 in French Wiktionary) and it is not possible nowadays to search only words in one specific language. As every language section title categorize in a language related category, we wonder how adaptable can be your proposal to make it useful for providing a language-specific search tool. Noé (talk) 12:40, 21 November 2016 (UTC)[reply]

Wikisource: This would help with searching all works in the author category, no matter if they are individual editions (like novels) or parts of a collection (like poems in an anthology). Ashaio (talk) 07:21, 2 December 2016 (UTC)[reply]

One problem though: what if someone starts to search the root category with full depth? Wouldn't it consume too much resources? Ashaio (talk) 07:21, 2 December 2016 (UTC)[reply]

AWB and I believe PetScan already handle this. And there's a proposal to integrate PetScan into MediaWiki. Am I missing something? Stevie is the man! Talk • Work 23:14, 4 December 2016 (UTC)[reply]

PetScan cannot "search" (for keywords etc), it can only list categories. I assume AWB can, but that is an external application. /NH 20:55, 8 December 2016 (UTC)[reply]
Thank you for the clarification. Stevie is the man! Talk • Work 15:50, 10 December 2016 (UTC)[reply]

Voting – Search recursively in specified categories

  1.   Support --Telaneo (User talk page) 22:09, 29 November 2016 (UTC)[reply]
  2.   Support Libcub (talk) 02:58, 2 December 2016 (UTC)[reply]
  3.   Support Ashaio (talk) 07:21, 2 December 2016 (UTC)[reply]
  4.   Support, as a side-suggestion category-pages could get an additional search-box for category-searches. --Fixuture (talk) 19:31, 2 December 2016 (UTC)[reply]
  5.   Support MichaelSchoenitzer (talk) 10:09, 3 December 2016 (UTC)[reply]
  6.   Support Pamputt (talk) 11:01, 4 December 2016 (UTC)[reply]
  7.   Support MGChecker (talk) 13:12, 4 December 2016 (UTC)[reply]
  8.   Support SamanthaNguyen (talk) 02:04, 6 December 2016 (UTC)[reply]
  9.   Support. - Mailer Diablo (talk) 06:55, 7 December 2016 (UTC)[reply]
  10.   Support. -- FriedhelmW (talk) 18:36, 9 December 2016 (UTC)[reply]
  11.   Support where one is specifying categories to search in. This seems like an obvious improvement to searching in category trees. Stevie is the man! Talk • Work 15:50, 10 December 2016 (UTC)[reply]
  12.   Support, with a customizable depth level. --NaBUru38 (talk)
  13.   Support Especially for the improvement to Wiktionary functionality, though I can see this being very useful on WP, too.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:00, 11 December 2016 (UTC)[reply]
  14.   Support - with a default depth. DPdH (talk) 19:50, 11 December 2016 (UTC)[reply]
  15.   Support – Uanfala (talk) 01:31, 12 December 2016 (UTC)[reply]
  16.   Support — NickK (talk) 23:00, 12 December 2016 (UTC)[reply]

Semantic search inside Wikipedia using Wikidata

  • Problem: In Wikipedia, I can only search for an item if I know its name. Suppose I want to find an American artist who's born in 1927 and is known to play guitar. How can I find him in Wikipedia ? I think that it would be possible to build a search interface which use's wikidata to build such a tool.
  • Who would benefit: Anyone who likes to look at Wikipedia
  • Proposed solution: The idea would be to build a tree of question. What are you looking for ? a human, a movie, a book, etc. If it's a human, you can ask another question : do you know its gender ? Do you know its bitrthdate ? etc. This could be something similar to the famous akinotor website.
  • Phabricator tickets:

Community discussion

Voting – Semantic search inside Wikipedia using Wikidata

  1.   Support Great idea to use Wikidata for improving search on Wikipedia (and other projects)! Spinster (talk) 15:30, 29 November 2016 (UTC)[reply]
  2.   Support Shyamal (talk) 06:22, 30 November 2016 (UTC)[reply]
  3.   Support Libcub (talk) 02:58, 2 December 2016 (UTC)[reply]
  4.   Support SamanthaNguyen (talk) 04:11, 2 December 2016 (UTC)[reply]
  5.   Support --Acky69 (talk) 17:24, 3 December 2016 (UTC)[reply]
  6.   Support Pamputt (talk) 11:01, 4 December 2016 (UTC)[reply]
  7.   Support in principle, although based on the Petscan example above, I wonder if this can be made easy enough to use for the common reader. Stevie is the man! Talk • Work 23:02, 4 December 2016 (UTC)[reply]
  8.   Support --Continua Evoluzione (talk) 10:16, 5 December 2016 (UTC)[reply]
  9.   Support Karmakolle (talk) 13:39, 5 December 2016 (UTC)[reply]
  10.   Support even when WD doesn´t convince me. --Hubertl (talk) 16:27, 5 December 2016 (UTC)[reply]
  11.   Support --Ambre Troizat (talk) 11:04, 8 December 2016 (UTC)[reply]
  12.   Support Miniapolis 20:50, 9 December 2016 (UTC)[reply]
  13.   Support --Plogeo (talk) 19:22, 10 December 2016 (UTC)[reply]
  14.   Support  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:01, 11 December 2016 (UTC)[reply]
  15.   Support - I didn't know of those tools sfter a decade so imagine the casual reader. Please improve searches. DPdH (talk) 19:54, 11 December 2016 (UTC)[reply]
  16.   Support – Uanfala (talk) 01:33, 12 December 2016 (UTC)[reply]
  17.   Support Michal Lester לסטר (talk) 11:52, 12 December 2016 (UTC)[reply]
  18.   Support We really need an interface for such search. I tried to explain a non-technical person how to find a person born exactly on the same day as they on Wikidata. No need to explain that they failed to understand how a Wikidata query works — NickK (talk) 23:01, 12 December 2016 (UTC)[reply]

UncategorizedPages should ignore hidden categories

  • Problem: Special:UncategorizedPages does not show articles which include a hidden category. This leaves some articles with only maintenance categories but no sorting categories.
  • Who would benefit:
  • Readers and editors: having sorting categories in an article allows better browsing around a topic because more articles are accurately included in category
  • AWB users: additions to categories allows for finding groups of articles for updates, common changes
  • PetScan users: if articles are placed in categories results can be more beneficial
  • Vandalism checks: potential to find partial blanking of articles. Those with tags left in place will still show as having a category. Articles that have been blanked on the bottom half will be alerted as having no categories.
  • Proposed solution: Make Special:UncategorizedPages ignore hidden categories
  • More comments: All pages should fit into at least one sorting category. Proposal would benefit both large and small language wikis.

Community discussion

Problem is: When a category is tagged as uncategorized, we want it out of that report; yet the category it is placed in is a maintanence category, so it should be hidden. עוד מישהו Od Mishehu 04:44, 20 November 2016 (UTC)[reply]
I've definitely (recently) run into articles tagged for other maintenance issues that also did not have a category, which is what prompted my request. It may be a rare instance and so my request would create a bigger problem. Perhaps there is a solution in PetScan that could exclude pages tagged for lack of categories but included in other hidden categories. --Tbennert (talk) 06:43, 26 November 2016 (UTC)[reply]

Voting – UncategorizedPages should ignore hidden categories

  1.   Support JAn Dudík (talk) 22:11, 28 November 2016 (UTC)[reply]
  2.   Support Kaldari (talk) 23:53, 28 November 2016 (UTC)[reply]
  3.   Support Nocowardsoulismine (talk) 01:42, 29 November 2016 (UTC)[reply]
  4.   Support Gareth (talk) 02:53, 29 November 2016 (UTC)[reply]
  5.   Support Anthonyhcole (talk) 09:48, 29 November 2016 (UTC)[reply]
  6.   Support IKhitron (talk) 12:19, 29 November 2016 (UTC)[reply]
  7.   Support They should be at least somehow distinguished. Matěj Suchánek (talk) 16:53, 29 November 2016 (UTC)[reply]
  8.   Support Guycn2 · ☎ 19:12, 29 November 2016 (UTC)[reply]
  9.   Support --Telaneo (User talk page) 22:10, 29 November 2016 (UTC)[reply]
  10.   Support --Matthiaspaul (talk) 00:04, 30 November 2016 (UTC)[reply]
  11.   Support --Vachovec1 (talk) 20:39, 1 December 2016 (UTC)[reply]
  12.   Support --WTM (talk) 00:46, 2 December 2016 (UTC)[reply]
  13.   Support Libcub (talk) 03:00, 2 December 2016 (UTC)[reply]
  14.   Support Draceane (talk) 10:40, 2 December 2016 (UTC)[reply]
  15.   Support only if it's a checkbox option. MER-C (talk) 02:26, 3 December 2016 (UTC)[reply]
  16.   Support Pamputt (talk) 10:57, 4 December 2016 (UTC)[reply]
  17.   Support MGChecker (talk) 13:11, 4 December 2016 (UTC)[reply]
  18.   Support Stevie is the man! Talk • Work 22:33, 4 December 2016 (UTC)[reply]
  19.   Support --Similartothissimilartothat (talk) 18:24, 11 December 2016 (UTC)[reply]
  20.   Support if it will be a checkbox — NickK (talk) 23:02, 12 December 2016 (UTC)[reply]
  21.   Support --Yann (talk) 23:42, 12 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Search&oldid=24950205"