Wikimedia Meta-Wiki

Community Wishlist Survey 2021/Categories

< Community Wishlist Survey 2021
Community Wishlist Survey 2021
Categories
12 proposals, 293 contributors, 469 support votes
The survey has closed. Thanks for your participation :)



Display flexible number of images in categories

Deutsch: Flexible Anzahl von Bildern in Kategorien anzeigen lassen.

  • Problem: The same problem as submitted several times. Currently, categories are limited to a maximum of 200 images displayed per page. On the one hand, this is no longer up-to-date because the devices can process more data. On the other hand, it is simply a hindrance when processing larger amounts of data if you only have 200 thumbnails per category page. It should also be easier to reach images that are further back. Anyone who currently wants to see image 1800 in larger categories with around 2000 images must first click through in a complicated manner in steps of 200.
Deutsche: Dasselbe Problem wie schon mehrfach eingereicht. Derzeit sind Kategorien pro Seite auf maximal 200 angezeigte Bilder beschränkt. Das ist mittlerweile zum einen nicht mehr zeitgemäß, da die Geräte mehr Datenmasse verarbeiten können. Zum anderen ist es für die Bearbeitung größerer Datenmengen einfach hinderlich, wenn man nur 200 Thumbnails pro Kategorie-Seite hat. Zudem sollte es einfacher sein weiter hinten liegende Bilder zu erreichen. Wer derzeit in größeren Kategorien mit etwa 2000 Bildern zu Bild 1800 will, muss sich erst kompliziert durch in 200er-Schritten durchklicken.
  • Who would benefit: People who do bulk edits on Commons and people who search for images and have to work with larger categories.
Deutsche: Personen, die Massenbearbeitungen auf Commons machen und auch Personen, die Bilder suchen und dabei mit größeren Kategorien arbeiten müssen.
  • Proposed solution: In addition to the standard setting of 200 images, there should also be a variable setting option. Either as a box on the page, as predefined sizes (about 50, 100, 250, 500, 1000, 2000, 5000 images per category page) or in the personal settings. Even better all three options in combination. Jump marks are also required so that you don't have to click through in steps of 200.
Deutsche: Es sollte neben der Standardeinstellung von 200 Bildern auch eine Variable Einstellungsmöglichkeit geben. Entweder als Box auf der Seite, als vorgegebene Größen (etwa 50, 100, 250, 500, 1000, 2000, 5000 Bilder per Kategorie-Seite) oder aber in den persönlichen Einstellungen. Noch besser alle drei Möglichkeiten in Kombination. Zudem braucht es Springmarken, um sich nicht in 200er-Schritten durch klicken zu müssen.

Discussion

  • There is a performance aspect to this. Hitting the thumbnail server with potentially hundreds of requests (some which might be rendered already, others needing to be generated) is simply a very expensive operation, compared to text. As such with the current structure, it is unlikely that over 250 images on a page is desirable. Perhaps if some sort of dynamic loading of images took place over a longer time after the page loaded (using javascript), or if you had to 'click to load' an image then more than 250 would be possible, but i'm not sure if that would be desirable for you ? —TheDJ (talk • contribs) 11:26, 17 November 2020 (UTC)[reply]
  • For me it would already help if there were jump marks in steps of five pages (forward and backward) and the possibility to go straight to the last page. I guess this would have less impact on the performance as the suggested solution. JopkeB (talk) 15:29, 17 November 2020 (UTC)[reply]
    This I definetly could get behind. Would support a proposal like that. —TheDJ (talk • contribs) 12:36, 21 November 2020 (UTC)[reply]
  • You might also use w:en:Wikipedia:AutoWikiBrowser. Geert Van Pamel (WMBE) (talk) 18:30, 23 November 2020 (UTC)[reply]

Voting

Automatically suggest categories when creating a new article

  • Problem: It is often difficult to think of what categories a new article should be part of, leading to many categories being incomprehensive and many articles harder to find.
  • Who would benefit: Editors and readers who value categories.
  • Proposed solution: Add a function to the process of creating a new article which automatically suggests categories for it to be included in.
  • More comments: The way the suggested categories would be chosen could be for example by searching the article title in category titles, or by taking a sentence in the article that fits a generic categorizing pattern ("[article title] is/was X"), and then searching for X. Or perhaps there could be some kind of an algorithm that can look for similar articles (something like the one used for 'suggested articles' on mobile), and then showing the categories those are in.
  • Phabricator tickets: task T360189
  • Proposer: HappyMihilist (talk) 03:16, 30 November 2020 (UTC)[reply]

Discussion

Voting

Allow multiple entries within each category

  • Problem: Sometimes, multiple entries within a category would be useful. For instance, on the French wiktionary there is a listing of French verbs that includes both the infinitive form (e.g. aimer) and a pronominal form (s’aimer). But which sort key should be given to the pronominal form? Equally valid arguments apply for a « aimer s » key and a « saimer » key. Ideally, the entry would appear twice in the category, under those two keys. There are other examples, such as proper nouns beginning with a definite article (e.g. Le Mans should be categorised under « Mans Le » and « Le Mans »).
  • Who would benefit: Wiktionaries, other wiki projects.
  • Proposed solution: Possibly add to the wiki software a magic word that can be used to specify a second (third, fourth, etc.) entry in a category’s index. Other wikicode approaches may be possible.
  • More comments: This could be merged with the proposal for Context-dependent sort keys, depending on the technical solution chosen.
  • Phabricator tickets:
  • Proposer: Urhixidur (talk) 15:46, 25 November 2020 (UTC)[reply]

Discussion

  1. Similar to « Mans Le » and « Le Mans »: Multiple entries will also benefit an international audience to find persons with foreign surnames in the English Wikipedia.
    « Eddy Van Halen » for Chinese which are used to the first part of the name being the surname.
    « Halen, Eddy van » for Dutch used to sorting on the main part of the surname.
    « Van Halen, Eddy » for English and Flemish speakers that interpret 'Van Halen' as surname.
Uwappa (talk) 12:31, 28 November 2020 (UTC)[reply]

Voting

Protection of all pages in a category

  • Problem: Sometimes vandals will systematically work their way through a category, making changes to each page. In order to address this, admins are often forced to protect each page, one at a time.
  • Who would benefit: All users who fight vandalism
  • Proposed solution: Allow protection of all pages within a category with one action (perhaps similar to the Cat-a-lot tool).
  • More comments:
  • Phabricator tickets:
  • Proposer: UDScott (talk) 16:32, 23 November 2020 (UTC)[reply]

Discussion

Voting

Add sorting options in category pages

  • Problem: Categories are a powerful tool to search pages. However, category pages only show the page's name, and there's a single sorting method, which reduces their usefulness.
  • Who would benefit: Readers and editors alike.
  • Proposed solution: Category pages should have an option to select the sorting type, for example category tag, page name, file size, first edit date, last edit date, number of editions, and page views. These values must be displayed of course.
  • More comments:
  • Phabricator tickets: T71417, T61108, T42870
  • Proposer: NaBUru38 (talk) 17:47, 21 November 2020 (UTC)[reply]

Discussion

  • Problem: Content of Commons categories is displayed now in alphabetical order. Only. I wish we could sort content according to: size of file; date of file (chronological and on an annual basis - useful for landscapes and nature); type of file (extensions), number of uses of files.
  • Who would benefit: All users who need to find specific file in large categories.
  • Proposed solution: ?
  • More comments:
  • Phabricator tickets:
  • Proposer: Kenraiz (talk) 01:07, 26 November 2020 (UTC)
Best, MusikAnimal (WMF) (talk) 16:32, 7 December 2020 (UTC)[reply]
  • Categories are a weird realm in that they're ostensibly for readers, but de facto used mostly by editors. As a reader, the thing I'd really like to see long-term is a merging of categories and lists, such that it'd be possible to sort by things like date of birth for a people list. The more page metadata-related sorting functions proposed here would be useful for me as an editor, but if this gains support, I'd want to see it implemented in a way that doesn't add clutter for readers, who aren't very likely to want to sort by last edit date. {{u|Sdkb}} talk 04:51, 9 December 2020 (UTC)[reply]
  • I'm increasingly of the mind that the best way to handle "categories" on Wikipedia is with Wikidata. Rather than create some fixed methods of sorting our cumbersome and strange tagging system, allow for easier (and limited, for the purpose of usability) querying of Wikidata to do everything. If you build a system on Wikidata queries, supply it with a set of properties it can use, then it would take less effort to just change those properties down the road than to modify the way mediawiki runs category pages. Categories on Commons, however, serve a rather more fundamental purpose at the moment, so it may be worth it for there, but I'm still kind of skeptical. — Rhododendrites talk \\ 13:46, 9 December 2020 (UTC)[reply]
  • Can't we already do this with Petscan ? T. Le Berre, the french serpent à plumesTry and talk to me buddy 01:12, 21 December 2020 (UTC)[reply]

Voting

Better tracking of category changes

  • Problem: For a few years, category changes have had dedicated entries in recent changes and watchlist. This is useful for watchlist – when you watch a category and have category changes enabled, you can see recent additions and removals to the category. For recent changes, this isn't much useful as it lists changes to any category. For Special:RecentChangesLinked ("related changes"), it only shows additions to the category. It's because when you remove a page from the category, it is no longer "linked" and thus it isn't listed in the related changes anymore. I believe this isn't logical as this change is pretty much related. Additionally, the diff links of category changes are quite buggy and could be fixed as part of this wish.
  • Who would benefit: Wiki gnomes checking for mistakes, patrollers checking for vandalism, wikis with complex categorizations
  • Proposed solutions (one of these):
    1. Improve Special:RecentChangesLinked to implicitly show additions and removals of the category
    2. Create a dedicated "mode" for categories in Special:RecentChangesLinked (i.e., make #1 explicit)
    3. Create a new special page dedicated to category changes (similarly, there is Special:NewPages for pages creations)
  • More comments: All of these could also add a filter for additions/removals only. Option #3 a stand alone tool to see whats been added or removed from a category in the last 30, 60, 90 days.
  • Phabricator tickets: phab:T89582, phab:T130134 (general problem); phab:T140602, phab:T147770, phab:T148533, phab:T243965, phab:T264491 (diff links, could be duplicates)
  • Proposer: --Matěj Suchánek (talk) 10:25, 30 November 2020 (UTC)[reply]

Discussion

Voting

Display categories before pages

  • Problem: (COMMONS only)
    • At present, where there is a Commons page with the same name as a category, a reader searching on Commons for the term is taken to the page, not the category. Most readers will not realize that there is a category at all. The average Commons page is terrible; most have not been edited for several years. Hardly any relect the choice of images in a category adequately. Johnbod (talk) 19:14, 20 November 2020 (UTC)[reply]
    • When typing to search field in comons, suggester suggest names of files and galleries, but not categories. ALso after search there are in results on the first place galeeries and then files. Categories are on the n-th page, when there are more than 20 results
  • Who would benefit: All Commons readers/users, especially those less used to Commons
  • Proposed solution: Just display the category screen from a search. No idea of the technicalities, but it shouldn't be too difficult.
  • More comments: I think the current situation must be giving inexperienced users of Commons a very misleading impression of our contents.
  • Phabricator tickets:
  • Proposer: Johnbod (talk) 19:13, 20 November 2020 (UTC)[reply]

Discussion

  • @Tuvalkin: But this wish is about searching results. Searching "foo" should display at first places gallery Foo, image foo.jpg and category:Foo. And then all things containing foo in name and then things containing foo in descriptionn. But now category:Foo is displayed after all files and galleries containig foo in name or description. JAn Dudík (talk) 08:49, 18 December 2020 (UTC)[reply]
  • @JAn Dudík: Okay, so the o.p. is indeed about search results, or at least we both think so. What to say? Raw text search is always a rough tool to locate things and having categories prioritized or not in search hit rankings is eitherway a non-ideal option. As someone who started using computers in the mid-1980s, I always found “fascinating” how subsequent latecomers used search engines, just like in the old 1970s movies about computers — with wholly unrealistic expectations etched even in the way search queries are worded, which would develop in “human interface” monstrosities like modern day’s Alexa. I am no less “fascinated” today by the fact that the very same people who are riding the “structured data” horse — which in itself harks back to Middle Ages’ flawed philosophies about discovering (not creating) a fanciful universal classification of platonic ideals — are also invested in raw text search “optimization” and keep sneering at Commons’ categories — which are human-generated, organically developed, non-teleologic, and ever-improving — in a word, Commons’ categories are wiki, while Wikidata (and its outgrowths in other projects) essentially and fundamentally is not. Tuvalkin (talk) 14:58, 18 December 2020 (UTC)[reply]

Voting

Support multilingual category names

  • Problem: Commons imposes English-named categories, which discourages non-English speakers from adding and creating categories and sometime leads to weird category names.--Strainu (talk) 11:57, 17 November 2020 (UTC)[reply]
  • Who would benefit: At least Commons editors, likely all multilingual wikis.
  • Proposed solution: Use Wikidata labels from the item associated with the category to provide multilingual aliases for the category names. The wikitext should always contain the English name, just the display and input should be i18n.
  • More comments: Input should work everywhere categories are used: search, wikitext editor, visual editor, upload wizard, classic uploader, API etc. The same, display should work in desktop, mobile and apps,
  • Phabricator tickets: could benefit: phab:T89973
  • Proposer: Strainu (talk) 11:57, 17 November 2020 (UTC)[reply]

Discussion

  • I think this proposal has low priority. English is the language of international communication. Plus, there is not always an exact correspondence between categories from different languages.Carn (talk) 13:18, 18 November 2020 (UTC)[reply]
  • What a horrid and Imperialistic comment to make. Yes I can speak English fairly well. English isn't my normal language of comunication, Welsh is. Welsh is the language I speak to my friends and family. Your suggestion, that my language is low priority, is arogant and crude and insulting to my loved ones who I use my first language with on a daily basis! Saying that my language is low priority is the same as saying that my parents and children and other loved ones, who I speak that language with, are low priority. AlwynapHuw (talk) 05:29, 17 December 2020 (UTC)[reply]
  • It is low-priority for English-speakers, yes :) Not so for people who don't speak English at a decent level. As to the correspondence, it should (and usually is) handled in Wikidata. The guidance there is to have 1 item for each clearly identifiable concept or object, it this isn't the case, then more items should be created.--Strainu (talk) 16:33, 18 November 2020 (UTC)[reply]
    So it is low priority for ~20% of people and high priority for ~80% of people of the Earth. Infovarius (talk) 23:15, 21 November 2020 (UTC)[reply]
  • I do see it as high priority. Right now there are too many duplicities between commons and local wikis. Some, like es: has move to use only Commons to avoid that. However, we lose some of the content from that communities if the lack of localization discourage a fraction of users from collaborating in Commons. A more multilingual commons that allow all wikis (specially small ones which may lack skilled manpower for an effective (C) review of images) will avoid the need for local repositories. It may be specially relevant for small communities which sometimes are themselves finding hard to create a core user group for edit on their language online and may find it more challenging to use something more internationally oriented. For many of them online skills and language proficency are hard already to find together--FAR (talk) 11:08, 29 November 2020 (UTC)[reply]
  • Start using structured data and Wikidata instead of Categories :-) --Sabas88 (talk) 12:49, 20 November 2020 (UTC)[reply]
    Wikidata doesn't contain media, for example, as Commons do. Infovarius (talk) 23:15, 21 November 2020 (UTC)[reply]
    What Sabas is suggesting here is to move away from Categories to more modern ways of grouping media. I don't think we're there yet. While bots are actively adding information, there is a shortage of simple tools to find images based on those informations. Plus, my proposal goes in the same direction, by using Wikidata as source for the names.--Strainu (talk) 23:42, 21 November 2020 (UTC)[reply]
    Yeah, my comment was to use the Structured Data deployed in Commons to replace the Category system --Sabas88 (talk) 12:38, 25 November 2020 (UTC)[reply]
  • @Strainu and Mike Peel: Is this close to being the same as Make subcategory browsing multilingual using Wikidata, and should they be merged? —SWilson (WMF) (talk) 07:17, 4 December 2020 (UTC)[reply]
    @SWilson (WMF): Yes, they're pretty close. Mike's proposal treats the display part (the easy one, I would say), while mine also includes the possibility for the user to input category names in any language (which is somewhat harder due to all the different ways this can be done).--Strainu (talk) 08:54, 4 December 2020 (UTC)[reply]
    Agreed they are close. I didn't want to include editing in mine as that's a whole different ballpark from just displaying the content, but I really like Strainu's point about using multilingual category names everywhere else, not just when browsing categories. I'm happy for them to be merged if you want. Thanks. Mike Peel (talk) 10:59, 4 December 2020 (UTC)[reply]
  • @Strainu and Mike Peel: Okay, thanks, makes sense. I'm not sure any more: let's just leave them as separate, and we can see which gets the most votes. Certainly the displaying feels easier, but it'd be super great to have more editing places support Wikidata lookups. :-) —SWilson (WMF) (talk) 06:58, 7 December 2020 (UTC)[reply]
  • Very interresting proposal, there is a lot of categories when another language would be more appropriate. For exemple, categorizing Louvre rooms and paintings in english is rather inefficient: we do not always have an english translation for all terms, so it leads to a strange frenglish mix.--Green fr (talk) 18:32, 11 December 2020 (UTC)[reply]

Voting

  • Problem: When adding or editing content categories for an article using Visual Editor, the search is case sensitive. It is also sensitive to spellings from different dialects, e.g. Non-profit organizations vs. Non-profit organisations. This makes it hard to find and discover existing categories, especially when it comes to improving categorisation and adding categories to pages without any.
  • Who would benefit: All editors.
  • Proposed solution: Make the category selection search query case and dialect insensitive.
  • More comments:
  • Phabricator tickets:
  • Proposer: WikiVillager (talk) 11:24, 17 November 2020 (UTC)[reply]

Discussion

Voting