Page MenuHomePhabricator

Feature request: Module "List all (sub-)category-members"
Closed, DeclinedPublic

Description

Allow listing of files in a category + all sub-categories. This request is for an API module.

It is a highly requested feature on Commons and would solve the problem of too deep categorization vs. categories with too many category members.

This is nothing expected to be done in 1/2 year and of course you must create the technical infrastructure before.

The current system is neither efficient nor sufficient for the editors and viewers.

There might be better ideas on [[:commons:User:Multichill/Next generation categories]]


Version: unspecified
Severity: enhancement

Details

Reference
bz35614

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:14 AM
bzimport set Reference to bz35614.
bzimport added a subscriber: Unknown Object (MLST).

Nothing except it does not list the subcategory *members* and one has to do recursive calls. And when all of these calls are ready, one can start with sorting. This must be more efficient. Do you need samples for use cases?

That makes sense, though, I'm not sure why it needs to be done on the server side.

If you pull a list of all category members, and recursively go through and pull the members lists (using continue where necessary). Track which categories you've been to (so you don't visit them multiple times pointlessly).

I'm not sure having the server do this automagically is sensible, or even more efficient, as for some category trees, the number of members will explode by many magnitudes

I'm inclined to WONTFIX this

It would be also useful for the interface:

  • According to our current system, it would be ideal if [[Category:Churches]] only contains subcategories.
  • You have no possibility to view all churches without going along the whole category tree
  • Instead of getting an overview, you get lost in the tree. Often seeing only one file in one category.

Sorting would not be that important in this case.

If you decline this request, I assume you will decline an interface request as well.

And yes, there is http://toolserver.org/~magnus/catscan_rewrite.php

But how long should we send people to toolserver for tasks that should be done by the software itself?

(In reply to comment #5)

But how long should we send people to toolserver for tasks that should be done
by the software itself?

I'm not sure what dictates when a piece of software should or shouldn't have an arbitrary feature

You don't have a working feedback system for MediaWiki. That's one of the biggest weaknesses in my eyes so one has to use bugzilla. (http://input.mozilla.com/en/feedback)

rd232 wrote:

(In reply to comment #7)

You don't have a working feedback system for MediaWiki. That's one of the
biggest weaknesses in my eyes so one has to use bugzilla.
(http://input.mozilla.com/en/feedback)

+1. Bugzilla is fine for simple *bugs*, but for complex feature requests, it sucks, IMO. I've never understood why there isn't some kind of a wiki-based discussion system attached.

Anomie set Security to None.
Anomie subscribed.

Dealing with the potentially-recursive nature of subcategories is best done on the client side, as well as issues of maximum depth, traversal order, and maintaining state across continuation.