Wikimedia Meta-Wiki

Community Wishlist Survey 2022/Categories

< Community Wishlist Survey 2022
Community Wishlist Survey 2022
Categories
13 proposals, 168 contributors, 289 support votes
The survey has closed. Thanks for your participation :)



Improve tracking of categorization 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, there are some annoying display issues which could be fixed as part of this wish.
  • Proposed solution:
  • Who would benefit: Wiki gnomes checking for mistakes, patrollers checking for vandalism, wikis with complex categorizations
  • More comments: All of these could also have a filter for additions/removals only.
  • Phabricator tickets: phab:T89582, phab:T130134 (general problem); phab:T126851, phab:T148533, phab:T270662, phab:T270774 (display issues)
  • Proposer: Matěj Suchánek (talk) 20:13, 12 January 2022 (UTC)[reply]

Discussion

  • I have basically re-purposed this my wish from the previous survey. --Matěj Suchánek (talk) 20:13, 12 January 2022 (UTC)[reply]
  • Support on the concept, keeping track over Commons Categories is especially hard. For example, I may remember I put some picture in some category, but didn't add it to my Watchlist. Someone else then moves it to another category (mostly this improves categorization, so no complaint on that), but I'll never find that image again. And sometimes I want to know who removed 400 files from an observed category on my watchlist, and where these files went... again no way for me to track this. --Enyavar (talk) 10:15, 13 January 2022 (UTC)[reply]
  • A useful improvement I'd support. --Achim55 (talk) 19:05, 17 January 2022 (UTC)[reply]
  • I have encountered some behaviors similar to destruction, that is, remove all pages in a category, and then request to delete the category page, which is not easy to restore. And only watching the corresponding category can check the membership changes of this category, and it is limited by the limit of the number of recent changes displayed. A separate view page to show the changing history of category's members is useful. --113.99.12.198 10:41, 3 February 2022 (UTC)[reply]

Voting

Context-dependent sort key

  • Problem: In most Wiktionary projects, words of different languages share a page if their spellings are identical. Currently, the magic word DEFAULTSORT works for an entire page, which means we cannot define a default sort key for each language in the same page. That is an issue especially for Chinese, Japanese and Korean (hanja). They share characters but their sort keys are totally different (radicals or pinyin for Chinese, kana for Japanese, hangeul for Korean). If it is allowed to define a default sort key for each section, it will be much easier to correctly categorize pages.
  • Proposed solution: Introduction of a new magic word, say, SECTIONSORT, that works for all categories after it up to the next usage of the same magic word. SECTIONSORT should override DEFAULTSORT if both are defined. The use of SECTIONSORT without a sort key should clear the previous sort key (and should not define an empty sort key).
  • Who would benefit: Editors of Wiktionary, especially those who edit Chinese and Japanese entries.
  • More comments: See Community Wishlist Survey 2017/Wiktionary/Context-dependent sort key for a discussion in 2017. It is still a problem. See Community Wishlist Survey 2020/Wiktionary/Context-dependent sort key for further discussion (and support).
  • Phabricator tickets: phab:T183747
  • Proposer: Urhixidur (talk) 20:38, 14 January 2022 (UTC)[reply]

Discussion

Voting

Turn Cat-a-lot into a MediaWiki extension

  • Problem: When moving a category, the pages in the category remain in the previous category.
  • Proposed solution: Turn Cat-a-lot into a MediaWiki extension so that it will be easily available to all users on all wikis.
  • Who would benefit: Users that move a category.
  • More comments:
  • Phabricator tickets:
  • Proposer: USI2020 (talk) 17:21, 23 January 2022 (UTC)[reply]

Discussion

Voting

Limit which namespaces are allowed in a category on the category page itself

  • Problem: In order to avoid unwanted pages from polluting categories intended for other namespaces, we waste our time and effort manually removing or commenting out [[Category:...]] and coding templates so that they add categories only in certain namespaces.
  • Proposed solution: A magic word or extension tag to be used inside category wikitext that determines which namespaces are allowed (or not allowed) in the category.
  • Who would benefit: Readers and editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Nardog (talk) 08:02, 21 January 2022 (UTC)[reply]

Discussion

  • One application of this would be disabling article categories in the draft namespace (relevant wish). {{u|Sdkb}} talk 22:44, 23 January 2022 (UTC)[reply]
  • @Nardog: Is your use case solely about categories in English Wikipedia's draftspace (and userspace drafts, I guess), and if so, are you okay with us archiving this in favor of Prevent draftspace pages from being placed in article categories? I would select that one because the focus is more clear to voters. If there is a need for this functionality beyond English Wikipedia drafts, this proposal can of course stay, however I'm a little concerned about the request to filter by namespace when browsing a category. In most cases this will be just fine, but for very large categories it could cause performance problems (maybe), so I think the focus of this proposal should be aboutstorage of categories, not the display of it's members. So instead of filtering by namespace when viewing a category, we make sure it's never categorized there in the first place (based on the namespace). Does that makes sense? Please let us know how'd you like to proceed. Thanks! MusikAnimal (WMF) (talk) 02:19, 25 January 2022 (UTC)[reply]
    @MusikAnimal (WMF): No, focusing on articles vs drafts is far too specific IMO. If anything this wish should subsume that one, not the other way around. Reliable filtering would likely involve changes to how categories are stored in the first place, indeed, and if that's too long a shot then I wouldn't mind changing this to one about preventing certain namespaces from creeping in category by category (which I really think should be possible via a magic word or extension tag to be used in category wikitext), which would make this and Sdkb's meet in the middle. Nardog (talk) 07:51, 25 January 2022 (UTC)[reply]
    Okay, thanks for clarifying. Again it's just the A multiselect interface like Special:Search on each category page that filters which namespaces to show that worries me (ideally we'd remove that proposed solution to not mislead voters), but we focus on the problem, not the solution anyway. The draftspace proposal is more focused and hence could have a different, more focused solution, but I'm thinking we'll just let both proposals go to voting and if we pick one up one we'll effectively work on both. Thanks, MusikAnimal (WMF) (talk) 19:11, 25 January 2022 (UTC)[reply]
    I was bold and went ahead and removed the "multiselect interface…" bit. Let me know if that's a problem! When we first read this proposal, we were thinking it could be external tool (since that is allowed to have slower queries), but that wouldn't solve the use case of drafts being categorized. MusikAnimal (WMF) (talk) 19:14, 25 January 2022 (UTC)[reply]
    @MusikAnimal (WMF): Then can you move this to "Preemptively exclude certain namespaces from a category on the category page itself" or something? My main idea was the post-hoc filtering, which you've abandoned, so the title doesn't fit anymore.
    Focusing on drafts strikes me as a bad idea. Some categories are meant to include articles and drafts, but not talk pages, and so on. Jettisoning flexibility when the same principle can have wider applicability makes little sense to me. Nardog (talk) 05:19, 26 January 2022 (UTC)[reply]
    @Nardog Good call! How about "Ignore categories from being saved when placed in certain namespaces"? If it wasn't clear, we're trying to avoid any kind of "filtering" by namespace when viewing categories. Instead, we will use a parser function / magic words to distinguish where they are allowed to be saved. So en:Category:Living People for instance would have something like (a crude markup) {{#catnamespace:0}} so it only gets stored on the main namespace. We'd find more ways to do this en-masse, or have inverse functions like {{#catnonamespace:0}} (Living People shown everywhere but the mainspace). Going the route of storage, we don't have to worry about query times when browsing categories since we won't need namespace filters. Does that sound right? This removes any focus on Drafts, specifically (I just used it as an example). It could be used for any purpose. MusikAnimal (WMF) (talk) 05:55, 26 January 2022 (UTC)[reply]
    @MusikAnimal (WMF): "Ignore categories from being saved when placed in certain namespaces" doesn't quite capture what this is about IMO. The crux of the proposal is that it's done on a category-by-category basis, on the category page itself (as opposed to where [[Category:...]] is placed). I fail to see what you thought was lacking in my suggestion ("Preemptively..."). (ETA: How about "Limit which namespaces are allowed in a category on the category page itself"?) Nardog (talk) 06:41, 26 January 2022 (UTC)[reply]
    We're on the same page, I think (putting the markup on the category page itself), just struggling with a clear title. "Limit which namespaces are allowed in a category on the category page itself" sounds fine, I've moved the it there :) Thanks, MusikAnimal (WMF) (talk) 15:44, 26 January 2022 (UTC)[reply]
    @MusikAnimal (WMF): Thanks, but now the solution needs updating. "which namespaces to be shown by default" should be "which namespaces can be included in the category" or something. Nardog (talk) 06:06, 27 January 2022 (UTC)[reply]
  • Just to clarify, this would automatically also apply to all subcategories, right? Jochem van Hees (talk) 17:28, 31 January 2022 (UTC)[reply]

Voting

Commons-specific: Display media/content of subcategories

  • Problem: In Commons, I often encounter very deep sub-categories, which are valid and should exist, but still only contain very few files. Browsing the content in these categories is difficult because you have to open each specific subcategory to get the preview of just one or two files.
  • Examples: 17th c. maps of Hesse which has in total 35 files over 14 sub-categories. Or Lviv in 19th c., with about 200(?) files in about 50(?) sub-sub-sub-categories (can't count exact numbers here, some categories and files show up in different branches). Problem has come up in this talk recently, between me and User Nosferattus.
  • Proposed solution: A clickable button "show all content over all sub-categories" that allows the user to open a new window/tab which then shows all files within such sparsely populated categories and their sub-categories.
    • technical suggestions I can already think of myself:
      • Exclude recursions and duplicates from showing up several times, of course.
      • Possibly with a marker from which category the files come from. Possibly duplicate files as per the above point, could receive several markers.
      • The proposed tool is NOT helpful in the case of heavily populated categories. It should not show up if the parent-category has more than X files, and exclude all childnode-categories that go over that same threshold. If too many files would need to be displayed, a warning should come up, or the button should be greyed out, or not be displayed at all. X could be a comparatively low number like 100, or 200.
      • I figure that fetching all sub-cat content and displaying it "temporarily" in the parent-category window for the user, would mess with tools like Cat-a-lot, which is why I propose a new display window. This one should only display the files, possibly the corresponding markers mentioned above, and a backlink to the actual category.
  • Who would benefit: Users browsing Commons content via categories, including the Categorizers.
  • More comments:
  • Phabricator tickets:
  • Proposer: Enyavar (talk) 11:44, 11 January 2022 (UTC)[reply]

Discussion

  • I think it would be very useful for the tool to list big subcategories. There are many categories with subcategories, which each have few files and a few subcategories. Most trees may be near empty, while most files of the parent category is in one or a few categories down the tree. Often the files you are looking for would be found in those. If the categories are big enough, above the threshold, ordinary links to go directly to the most promising ones (and perhaps expand subtrees when there) would be very useful. –LPfi (talk) 12:42, 13 January 2022 (UTC)[reply]
    その意見に同意します。大きなサブカテゴリーの一覧が予め表示されているととても便利です。 Mishika (talk) 00:29, 23 January 2022 (UTC)[reply]
  • I feel like improving the data for MediaSearch to consume is probably the way forward here rather than adding yet more support for the antiquated category system. Which is also something that can be done yourself. :D --Izno (talk) 02:14, 17 January 2022 (UTC)[reply]
What do you mean with that? If this is about structured data, there is no helper functionality I am aware of. I need to click on an image, click on the structured data tab, then navigate through an arcane menu to add statements, which I need to do one at a time. "This depicts a map". "The map is from year 1898". "The map is a topographical map". "The map depicts Illinois". "The map was drawn by John Smith". Doing so for more than a few dozen files in a row is EXHAUSTING. The categories are at least immediately accessible via HotCat and Cat-a-lot. --Enyavar (talk) 09:48, 18 January 2022 (UTC)[reply]
So, that's an editing problem then (which this team could also help with).
And you're talking to one of the first editors for Wikidata phase 2 and 30k edits when I stopped editing on the project. I know how much work it is. There are tools on Wikidata today that could also be adapted for Commons to help with making structured data better. Izno (talk) 04:48, 19 January 2022 (UTC)[reply]
antiquated or not, the category system is currently an important pillar of Commons. I believe the idea above is a pretty simple and straightforward, while I have no idea what all needs to be done to help with structured data input. --Enyavar (talk) 10:54, 19 January 2022 (UTC)[reply]

Voting

  • Problem: It is boring to keep on going to the edit page when you want to add a category.
  • Proposed solution: Make HotCat a native feature.
  • Who would benefit: Ordinary Wikipedians.
  • More comments:
  • Phabricator tickets:
  • Proposer: Bli231957 (talk) 20:45, 10 January 2022 (UTC)[reply]

Discussion

Voting

Showing sort keys on category page

  • Problem: Because category trees aren't made by one person, things like sort keys may be inconsistent. From the category pages themselves it is often not obvious when the sort keys deviate.
  • Proposed solution: Show the sort key of every page in the category, maybe in brackets after the link to the page. Because most regular readers probably don't care about sort keys, this should be an opt-in (maybe through a gadget).
  • Who would benefit: Wikimedians who categorise.
  • More comments:
  • Phabricator tickets:
  • Proposer: Jochem van Hees (talk) 21:47, 19 January 2022 (UTC)[reply]

Discussion

Voting

A tool for creating year and month categories on Commons

  • Problem: Many photographs are uploaded to Wikimedia commons which can be assigned a date and a place by being sorted into a category such as "$month $year in $place". With the increasing number of such uploads of pictures from more recent years and from more places, it becomes necessary to create new categories accordingly. Doing this by hand is somewhat tedious work and prone to errors, so that some tool to simplify this task appears desirable. Also, some of these category names are rather long, so that an editor could benefit from appropriate category redirects. For instance, the category "$month $year in $borough" would redirect to "$month $year in the Metropolitan Borough of $borough" where applicable (uniqueness needs to be observed), and an editor should be able to set up such redirects just as easily as the correct categories.
  • Proposed solution: A tool be created in which an editor only needs to enter the place name and the year, and which then creates the category tree as needed in accordance with the existing structure.
  • Who would benefit: Editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Schlosser67 (talk) 07:06, 18 January 2022 (UTC)[reply]

Discussion

Voting

Help to know if an article exists in a certain language from the categories.

  • Problem: It is not possible to see from a category if the articles that are there are also in Wikipedia in other languages.
  • Proposed solution: Example: I am in a category on Wikipedia in English, for example on American poets, and I want to see which of those articles are on Wikipedia in Spanish. What I can do? I have to click the articles one by one and check if the articles are found in the other Wikipedia. It is possible to find some way that articles that are in other Wikipedia are underlined or highlighted.
  • Who would benefit: to all of us who categorize and who use Wikipedia in more than one language.
  • More comments:
  • Phabricator tickets:
  • Proposer: Igallards7 (talk) 22:51, 10 January 2022 (UTC)[reply]

Discussion

Voting

Prevent draftspace pages from being placed in article categories

  • Problem: Per w:WP:DRAFTNOCAT (and equivalent policies and guidelines at other wikis/language editions), draft pages are not supposed to be placed in article categories. However, many newcomers are unaware of this. Further, many experienced editors choose to ignore it. As a result, volunteers have to go around regularly manually disabling categories on drafts.
  • Proposed solution: This task could be integrated into the software. In an ideal application, all categories in a draft would be automatically wrapped in the draft categories template by the software, without the need to do anything to the wikitext. Exceptions should be made for Category:Wikipedia drafts and its subcategories.
  • Who would benefit: This would eliminate a task for patrollers, reduce confusion for newcomers, eliminate the chance readers come across a miscategorized draft while browsing categories, and allow for easier category work on drafts for all editors.
  • More comments:
  • Phabricator tickets: phab:T299286
  • Proposer: {{u|Sdkb}} talk 20:33, 22 January 2022 (UTC)[reply]

Discussion

Voting

Allow custom display of entries in a category's page list

  • Problem:
    • Categories are very important for Wiktionary. We use them to group words by language, part of speech, register, topics, rhymes and many other groupings, as well as for maintenance purposes.
    • However, the category listings are very bare-bones. In particular, in language-specific categories, we would like the entries to be formatted correctly according to our rules for that language.
    • For instance, when you visit a category of Greek words (such as - an example at English Wiktionary - wikt:Category:Greek nouns), the user should see Latin-script transliterations next to the Greek script, just as they do anywhere a Greek word is mentioned in an entry, thanks to our use of templates. We already have Lua modules to do this work within the entries themselves - we just need a way to allow these modules to be run against the page list on a category page.
  • Proposed solution: Develop some kind of magic word that is placed in the category wikitext. This magic word tells MediaWiki that, every time a user views the category, each page title to be displayed should be passed into a Lua module, which then transforms the title for display.
  • Who would benefit: Wiktionary readers and editors
  • More comments:
  • Phabricator tickets:
  • Proposer: This, that and the other (talk) 12:47, 18 January 2022 (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 »).
  • 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.
  • Who would benefit: Wiktionaries, other wiki projects.
  • 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) 20:36, 14 January 2022 (UTC)[reply]

Discussion

Voting

Provide a quick-way to remove page from all parent categories

  • Problem: Ideally, pages are pushed down the category tree as far as possible. Once this is done, haviing a tool that "walks the category tree" to the root and removes the page from all parents would be useful.
  • Proposed solution: Add a tool that allows removing the current page from all parent categories.
  • Who would benefit: Users pushing pages down the category tree
  • More comments:
  • Phabricator tickets:
  • Proposer: Eptalon (talk) 23:43, 18 January 2022 (UTC)[reply]

Discussion

Voting

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