Wikimedia Meta-Wiki

Community Wishlist Survey 2019/Categories

< Community Wishlist Survey 2019
Community Wishlist Survey 2019
Categories
12 proposals, 215 contributors, 363 support votes
The survey has closed. Thanks for your participation :)



Create possibility to sort images in categories

  • Problem: Current default sorting in categories is filename and no other sorting is possible.
  • Who would benefit: Everyone.
  • Proposed solution: Create a possibility to sort and display images in categories by filename, image size, file size and upload date.
  • More comments:
  • Phabricator tickets: phab:T71417 and phab:T42870
  • Proposer: Jürgen Eissink (talk) 00:35, 4 November 2018 (UTC).[reply]

Discussion

Jheald Would depend on the category size. :) Having worked on category sorting previously, I am personally not too optimistic about this. However I would totally love to see this feature come to life. -- NKohli (WMF) (talk) 00:00, 6 November 2018 (UTC)[reply]
Also see this proposal. --NaBUru38 (talk) 18:47, 7 November 2018 (UTC)[reply]

Voting

CategoryTree improvement

  • Problem: CategoryTree serious limitations
  • Who would benefit: all Wikipedia where installed
  • Proposed solution:
    1. add listitem="normal" or similar option to display category items w/o italic style
    2. add some visual hint "not a full list" when the category exceeds the default 200 items
    3. add option from="ItemName" or start="ItemNumber" to be able to display something other than 200 first items in a large category
  • More comments:
    1. First posted at Russian Techforum with actual samples - w:ru:Википедия:Форум/Технический#CategoryTree
    2. (Re)consider how actual is the limitation of DynamicPageList "any small to medium sized Wikis (It is known to have scalability issues with very large wikis)". Wikipedia should be a rather big baby by now :-) to hold it properly.
  • Phabricator tickets:
  • Proposer: NeoLexx (talk) 15:46, 10 November 2018 (UTC)[reply]

Discussion

Voting

Display Multi-column sorted categories

  • Problem: Currently categories are displayed at the bottom of the page as one big concatenated sequence of (unsorted) categories. It is very complicated for the user to search for the correct category to click on, especially with long lists of categories. The user has as only option as to scan sequentially the list left to right until the end before deciding one finds any matching category, or not.
  • Who would benefit: All MediaWiki users (so basically everybody).
  • Proposed solution: Display Multi-column sorted categories. Instead of an unreadable old-style, concatenated, unsorted, long list of categories you can now choose to display your page categories as a modern, multi-column, sorted table. A really nice and readable layout for MediaWiki page categories. Very easy to implement. This way one can scan from top to bottom and left to right in sorted columns, just like e.g. in a multi-column Linux directory list...
  • More comments: A few lines of code needs to changed in Skin.php. And one single line of CSS code to be added: .mw-normal-catlinks { column-count:6; -moz-column-count:6; -webkit-column-count:6 }
  • Phabricator tickets: See mw:Snippets/Multi-column sorted categories for a working example
  • Proposer: Geert Van Pamel (WMBE) (talk) 15:30, 4 November 2018 (UTC)[reply]

Discussion

  • I note that currently the categories are displayed in the order they're added by the wikitext. For visible categories on the page, editors sometimes take advantage of this feature.

    I also note that the linked "change" loses semantic formatting that is likely useful for people using screen readers, although it seems likely that loss isn't a required part of this proposal. Anomie (talk) 16:39, 5 November 2018 (UTC)[reply]

Voting

Display all images of a category and of all sub-categories

  • Problem: Currently, you can see the images directly linked to a category but you need to open each sub-category (for example : if I would like to see all pictures of statues in Antwerp (c:Category:Statues in Antwerp), I need to open 13 sub-categories).
  • Who would benefit: everybody
  • Proposed solution: A button "Display all media in this category and its subcategories"
  • More comments:
  • Phabricator tickets:
  • Proposer: Delsaut (talk) 15:39, 4 November 2018 (UTC)[reply]

Discussion

  • Hello, the new search allow to see pages in subcategories with the keyword "deepcat" (see here). However, it has issues with big categories. And in your case, the search results has very small image thumbnails. --NaBUru38 (talk) 18:57, 7 November 2018 (UTC)[reply]
  • A way to not only look down (subcategories), but also up (higher categories) at the top of the category page would also be welcomed. Sometimes, if not often, when trying to find the correct higher category, one has to go through four or even more pages, where on every page one has to scroll down to the bottom to find the higher category, which can be very time consuming. Jürgen Eissink (talk) 20:22, 13 November 2018 (UTC).[reply]

Voting

Improve HotCat

 
  • Problem: Commons HotCat only shows 5 lines at a go. When a category has numerous subsections (100-200 or more) to select from, this makes hitting the right one very difficult, as a tiny movement of the mouse scroll wheel and you flick past 20 or 30 subcategory names.
  • Who would benefit: HotCat users at Commons
  • Proposed solution: Make HotCat show 50 lines at a go, instead of just 5
  • More comments:
  • Phabricator tickets:
  • Proposer: MPF (talk) 09:49, 4 November 2018 (UTC)[reply]

Discussion

Voting

  • Problem: There are thousands of broken links pointing from Wikipedias to Commons' category pages. Many of them are caused by the fact that someone who renames or deletes a category page on Commons is not aware of these interwiki links. Two examples:
en:1999 FIFA Confederations Cup → c:Category:Confederations Cup 1999
en:2,4-Dinitrotoluene → c:Category:Dinitrotoluene
  • Who would benefit: Users of all wm projects
  • Proposed solution: Either add a table globalcategorylinks to the Commons db similar to globalimagelinks or extend/replace the existing globalimagelinks so that at least the category namespace is covered as well.
  • More comments: In addition, the whole thing could then be handled easily and fast by scripts or bots. At this time one had to look up all of the projects for to detect a broken link what can take up to a few minutes per check and thus is not practicable.
  • Phabricator tickets:
  • See also: Lists on en:wp and de:wp
  • Proposer: --Achim (talk) 20:45, 9 November 2018 (UTC)[reply]

Discussion

@Achim55: Is this more or less the same as Community Wishlist Survey 2019/Bots and gadgets/category-redirect, or do I misunderstand / ignore some aspects? --AKlapper (WMF) (talk) 22:31, 9 November 2018 (UTC)[reply]

AKlapper (WMF), no, that's completely different as this deals only with interwiki links pointing to Commons. --Achim (talk) 22:36, 9 November 2018 (UTC)[reply]

@Achim55: This is something that is gradually being solved by Wikidata. When a commons category is moved, the commons sitelink on Wikidata updates (or if the category is deleted, the sitelink is removed). Ideally the templates on Wikipedias would display the link from Wikidata, so they would automatically update as well. The technical tools to do that exist, it's mostly just a community issue to do the migration. Thanks. Mike Peel (talk) 12:54, 10 November 2018 (UTC)[reply]

Mike, if you've had a closer look to the given examples above, you might have noticed the two reasons why that doesn't work in practice: a) There are very many categories Wikidata doesn't know about nor their links, b) many of these links are set via {{commonscat}} tags on wp pages. These links are not connected to Wikidata. I've been told (I do not own a smartphone) that that's necessary because the links bar at the left is not shown in mobile view. Maybe some day these problems will be solved (or perhaps I'm missing something now), until then I'm going to keep up this request. Regards, --Achim (talk) 13:18, 10 November 2018 (UTC)[reply]
Edit, forgot to mention: c) It's not always a 1:1 relation, for example does en:Altstadt (Zürich) contain 4 different links pointing to different categories on Commons. --Achim (talk) 14:23, 10 November 2018 (UTC)[reply]
@Achim55: As background info, I posted Community Wishlist Survey 2017/Multimedia and Commons/Improve support of interwiki links on Commons using Wikidata, and when it didn't get enough votes and nothing happened, I ended up doing most of the work for it myself, based around the creation and deployment of commons:Template:Wikidata Infobox. On (a), I've bot-added around a million commons sitelinks to Wikidata over the last year via Pi bot (talk · contribs) - and I'm always open to new suggestions of how to accurately add more sitelinks. On (b), I've just pinged you about a new sandbox version of the template on enwp that tries to solve that issue, and works for your first example. There isn't a commons category to link to for your second example, so the template should be removed from that article. On (c), that probably needs a new category creating on Commons that includes the four subcategories. The issue that the links bar isn't shown on mobile is not something that can be fixed on-wiki, so I'd suggest that the best way forward here is to submit a new wishlist request that focuses on solving that issue. Thanks. Mike Peel (talk) 22:34, 10 November 2018 (UTC)[reply]

Voting

Using HotCat for many uncategorized articles in one page

  • Problem: As kowiki users, I and many editors in Korean wikipedia have a trouble with too many uncategorized articles. Considering low userparticipation of the community, a number of those articles are burdensome to us. Although HotCat is very useful tool for us, editing loads of the articles in one time contains unnecessarily repetitive tasks, because we have to go back to the page that has the list of uncategorized articles and choose the next page to change. Therefore I think it would be efficient to make a page that we can add categories with HotCat.
  • Who would benefit: Any users who are handling with uncategorized articles
  • Proposed solution: making a page that can manage all of the uncategorized articles, and makes it possible to add Categories with HotCat. And, the inteface I want is the list with header "name of article | first line of the article | HotCat tool". With first few words of article, anyone can easily figure out what category might fit to the article, because first line usually contains the definition of the ariticle.
  • More comments:
  • Phabricator tickets:
  • Proposer: Priviet (talk) 13:54, 4 November 2018 (UTC)[reply]

Discussion

  • This is a cool idea I think, but I'm not sure HotCat is the best way to fix it. --Izno (talk) 04:28, 7 November 2018 (UTC)[reply]
  • There's Gadget-Cat-a-lot, is that useful for you? --NaBUru38 (talk) 18:22, 7 November 2018 (UTC)[reply]
    • @NaBUru38: Isn't it just for files? Does the gadget work for general articles? -Priviet (talk) 13:18, 9 November 2018 (UTC)[reply]
    • Well, I just used Cat-a-lot now, but it is not what I wanted. What I suggested was for "Uncategorized Artices", and Cat-a-lot is for changing categories that already exist. :( -Priviet (talk) 14:27, 9 November 2018 (UTC)[reply]
      • I once thought along the same line as Priviet, but users on my wiki yuewp are quick to patrol new pages and add categories or {{uncat}}. With the latter you can find them in Cat:Uncategorised pages. There you can use Cat-a-lot. So a tentative solution to kowp would be to make a bot check for such pages and add the template.--Roy17 (talk) 00:16, 17 November 2018 (UTC)[reply]
        • Thanks for your opinion. We' ve already had {{uncat}} in the kowiki, which means I can see all the uncategorized aricles. However, the problem is we have to decide which category each article belongs to. This process can only be done by HUMANS, not a bot. So, the point of this suggestion is to facilitate the categorizing process by users, and I think making a page for managing these articles would be helpful. -Priviet (talk) 15:13, 17 November 2018 (UTC)[reply]
  • I wonder if the real problem is lack of reuse of categories between projects. A description of an entity can be different, thus content specific categories will be different, but the entity itself is the same across languages, thus the entity specific categories will be the same. It is really a Wikidata problem; how to propagate entity specific categorization to the articles in question, and hoisting of articles within a partially defined category tree. — Jeblad 08:26, 18 November 2018 (UTC)[reply]
    • True. But there are also the articles pertaining to domestic issues, persons, and organizations. It is not possible to use categories from wikidata when if there are no corresponding categories. Reusing the categories between wikiprojects is good idea, but still can't be a solution for all of uncategorized articles. -Priviet (talk) 15:30, 18 November 2018 (UTC)[reply]
      • Note that the anser to "It is not possible to use categories from wikidata when if there are no corresponding categories." is already given "hoisting of articles within a partially defined category tree." Articles are placed in the first found category moving upwards in the category tree. — Jeblad 20:50, 18 November 2018 (UTC)[reply]
  • May I try rephrasing this request as follows? A Cat-a-lot gadget that can be used on Special:UncategorizedPages. (There're only 128 pages on ko:Special:UncategorizedPages.)
  • As I said, the current effective solution is to add {{uncat}} to uncategorised pages. From there you can simply use Cat-a-lot in the Category:Uncategorised Pages.
  • It seems that ko:틀:Uncategorized does not add files to the tracking category.
  • See ko:케베체트 for example. A bot is already in place to add uncat, but the page is not included in any tracking cat.--Roy17 (talk) 19:23, 21 November 2018 (UTC)[reply]

Voting

Automatic category suggestion for Commons images

  • Problem: Hell lot of uncategorised / ill-categorised pages
  • Who would benefit: Whole Wikimedia community
  • Proposed solution: Implement AI to facilitate face recognition, auto-categorisation in commons.
  • More comments: This will benefit both wikiproject and decentralisation of AI. Wikipedia is one of the largest repositories of training data right now. If wikipedia open-source the trained JSON (i.e. features-label pair), this will help fast deployment of face-recognition, landmark-recognition, animal-recognition, plant-recognition and object-oriented besides other. This will help Wikipedia strengthen the goal of open-data.
  • Phabricator tickets: T192444 T155538 T155848
  • Proposer: Capankajsmilyo (talk) 09:55, 31 October 2018 (UTC)[reply]

Discussion

phab:T192444 is about identifying faces in images on commons. --AKlapper (WMF) (talk) 15:06, 31 October 2018 (UTC)[reply]

I'm okay with both. Capankajsmilyo (talk) 18:50, 31 October 2018 (UTC)[reply]

I like the idea. But before starting with heavy image recognition one could already use meta data like title, description, location for suggesting appropriate categories. Technically, i also wonder if it would make sense to build a general service for it so that other programms like different upload tools or Commons Android app could use it. --Arnd (talk) 12:02, 1 November 2018 (UTC)[reply]

As a very active Commons categorizer, I would like something like this as it would make our jobs that much easier, at least in sorting by locations. I would add two things that could really grease the skids here, and, I think, wouldn't be difficult to code and implement:
  • Use geotagging, where available, to determine where the picture is (putatively, anyway) and make location suggestions based on that (assuming the appropriate subcategory exists).
  • If the uploader has assigned the image to a location subcategory, and one exists for another category the uploader has chosen, suggest it.

Daniel Case (talk) 03:45, 4 November 2018 (UTC)[reply]

Structured data should make this significantly easier to implement. Wait a year or two more. --Izno (talk) 13:42, 5 November 2018 (UTC)[reply]


This work is really good and fun if this is possible. (Mostafameraji (talk) 13:57, 7 November 2018 (UTC))[reply]

Voting

Structure of Categories

  • Who would benefit: All people that use Commons. Categorizer, people who look for images and so on.
  • Proposed solution:
    • first: a flexible number of files per category site. two possibilities: Buttons with different possible sizes; e.g. 50, 100, 200, 500, 1000. Or, what I would like more, a field with a free definition for every user (and category site). So I could - if I would, choose 222 files per size for example.
    • second: sortable categories. Not only per alphabet, also for time. So that you can see in bigger categories, which imges are new, which one older. Or by size. Or by media.
  • More comments: I think, it's the fourth try for this. But it will be once more too usefull for Wikimedians so it once more will be ignored at the end.

Discussion

  • The current sorting of photos into categories using HotCat still require around 2-3 seconds of delay. If I were to do categorizations of hundreds of uncategorized photos, it will add up to hours of extra waiting time :( Categorizations with HotCat should be executed/processed instantaneously (a split of a second) Chongkian (talk) 10:34, 5 November 2018 (UTC)[reply]
  • Yes. Being able to sort by creator / date of media / date depicted from the information template would also be nice. It would be nice to think that functionality for sorting categories by this kind of information could be added quite quickly once these become available as structured data statements (together with filtering on the values of other structured data statements, eg license-type). However, there seems to be a party view amongst at least some of the structured data team that the structured data service is going to bury the category system (and perhaps even that the extent to which it does so should be a metric for the success of structured data, see eg last line of summary of phab:T177357). I personally don't think that will happen, in fact I think the structured data is likely to strengthen the category system, by making it possible to make categories more systematically comprehensive, and more possible to add richer functionality to category views (eg the sorts of sorts I've mentioned above). But it may take the dev team some time to realise this, and until that time I fear resources be directed away from it. Nevertheless I strongly support this proposal, and it very much has my +1. Jheald (talk) 20:29, 5 November 2018 (UTC)[reply]
  • Regarding sorting of categories, please see this proposal. --NaBUru38 (talk) 18:40, 7 November 2018 (UTC)[reply]
  • Thanks for proposing it – I had it on my list of wishes too. :) I think this could be a bit similar to filemanger like Windows Explorer, Nautilus, Dolphin, etc than users would be comfortable in using it. -- MichaelSchoenitzer (talk) 23:46, 7 November 2018 (UTC)[reply]
  • That is a great idea. Apart from mentioned above I would like to have possibility, esp. in categories with plants and landscapes, to sort pics according to calendar (from January to December). There is user who sort pics in this way in plant categories manually... Kenraiz (talk) 11:07, 10 November 2018 (UTC)[reply]
  • @Marcus Cyron: Just to set realistic expectations, part #1 of your request should be doable, but sorting is a bit more challenging. The categorylinks tables are HUGE, so it's only realistically possible to sort on data that is directly stored in that table and indexed. In other words, it's not impossible, but will be difficult (as it might require some database changes). Ryan Kaldari (WMF) (talk) 19:21, 14 November 2018 (UTC)[reply]
  • The DB limitations on sorting are mostly due to using a relational database; if categorylinks would be stored in something like ElasticSearch the problem would go away. I realize that's a bit beyond the scope of what Community Tech can handle; OTOH at some point it will have to be tackled anyway, beacuse we want to replace link tables with a more scalable and flexible dependency engine, and at that point list generation would probably have to be decoupled from dependency tracking. --Tgr (talk) 06:02, 25 November 2018 (UTC)[reply]

Voting

Improvements of Categories in Chinese Wikipedia

  • Problem: Categories are sorted by unicode encoding. It became difficult for readers to locate a page in a large category because there are tens of thousands of characters(in Chinese) rather than 26 to sort from. People use pinyin (romanized Chinese) (or zhuyin), radicals or strokes of Chinese characters when they want to find a word.
  • Who would benefit: Users at Chinese Wikipedias(zhwp, wuuwp, etc.) or in logographic language.
  • Proposed solution: I wish that there will be some options (default, pinyin, zhuyin, radicals, strokes, etc.) for users to select in categories.
  • More comments: Japanese Wikipedia users may also benefit from this proposal since kanji (characters) can be sorted by their pronunciation.

Discussion

 

Voting

Support category redirects

Discussion

@Wheeke: Is this phab:T5311, or do I misunderstand? --AKlapper (WMF) (talk) 02:53, 8 November 2018 (UTC)[reply]

Yes, I mean some like phab:T5311, You unterstand--Wheeke (talk) 07:18, 8 November 2018 (UTC)[reply]
Is this commons:Template:Category redirect? by the way, we decided at de:WP not to use that. W!B: (talk) 10:52, 18 November 2018 (UTC)[reply]

@Wheeke: Can you please elaborate on what you mean by the ”result changes automatically”? Should the wikitext be changed automagically, should the ”wrong” category name remain in the wikitext but the correct category name be shown in the bottom of the article, or something else? Thanks! /NH 11:07, 23 November 2018 (UTC)[reply]

Yes I mean the help- and useful thing like commons:Template:Category redirect how W!B: noted. I'm here, because de:WP decided not to use that. This is WP and not de:WP. Sorry for my bad English. --Wheeke (talk) 18:54, 24 November 2018 (UTC)[reply]
Thanks! /NH 10:12, 25 November 2018 (UTC)[reply]

Voting

Button to show subcategories

  • Problem: Sometimes, a category is too well tidy and a lot a sub-categories exists (that also have sub-categories). A user wanting to obtain a better vision of a whole category have visibility on the sub-categories (on top of the category page), but not on the sub-sub-categories (hidden by default). He needs to expand one by one the "blue" arrows of a sub-category.
  • Who would benefit: I mostly thinks about Commons, to help search files in a designated category, like a city category.
  • Proposed solution: I think a button/trigger/option that auto-expand the sub-categories of the current category. A limitation of one, two or three levels might be technically a need. A template can maybe be used to to force this parameter.
  • More comments:
  • Phabricator tickets:

Discussion

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Categories&oldid=18684600"