Last modified: 2008-04-11 10:30:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13590 - ability to have member categories as well as subcategories
ability to have member categories as well as subcategories
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2008-04-02 10:53 UTC by Le Chat
Modified: 2008-04-11 10:30 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Le Chat 2008-04-02 10:53:58 UTC
Some higher-level categories logically have categories as members. It should be possible, when adding one category to another, to specify that it is being added as a member and not as a subcategory. These member categories should then be listed among the member articles, or at least separately from the true subcategories.
Comment 1 Brion Vibber 2008-04-02 19:36:53 UTC
That doesn't really fit our category model, in which there is no distinction between subcategory and member category.
Comment 2 Le Chat 2008-04-03 13:48:49 UTC
Sorry if I didn't make myself clear - this is a request to extend the category model, which would in fact enable such a distinction. (It's a feature request rather than a bug report.) The point is that, logically, there should be a distinction between member cats and subcats (but as you imply, the software doesn't currently support this).
Comment 3 Brion Vibber 2008-04-03 22:51:51 UTC
I wouldn't consider this a desirable change at this time.
Comment 4 Le Chat 2008-04-05 10:26:25 UTC
Reopening again in the hope of extracting a fuller explanation as to why it isn't desirable.
Comment 5 Brion Vibber 2008-04-07 21:15:58 UTC
Categories are not primary content pages; they're collections based on tagging.

When category pages are themselves categorized (tagged), they too appear in a category collection. But, because categories are something special, we separate these out from the regular pages, and make it easier to navigate down a virtual "tree". These are then called subcategories.

Since categories are special collections, not regular pages, they are treated specially. This is by design.

Offhand there is little or no benefit to complicating the system to treat them sometimes specially and sometimes not, when in fact they are *always* something special.
Comment 6 Le Chat 2008-04-08 08:58:34 UTC
I understand, but my point is that they can be "something special" in different ways. For example, "Category:Jesus" and "Category:Politician categories" might both be assigned to "Category:People categories". At present they would both be listed on that page as subcategories. However, logically, only the second one is a subcategory, while the first has a totally different relationship with the parent category - it is *not* a subcategory (in the sense of subset), but a member of the category.
Comment 7 Brion Vibber 2008-04-08 23:29:38 UTC
Well, that's just not the way we do categories.
Comment 8 Le Chat 2008-04-09 06:57:57 UTC
Er... obviously it isn't, otherwise I wouldn't need to be proposing this improvement. You could dismiss any feature request by saying "it's not the way we do it". My point is that it should be the way we do categories, otherwise you get a mess. Admittedly here the mess is only at the top of the category tree, where perhaps few users ever venture, so it isn't a vastly important issue, and I don't mind letting it drop. However I will probably be making a more extensive category proposal soon, which might be of great assistance to tidying up the category system e.g. in Wikipedia, and I hope it will meet with a more open-minded attitude.  
Comment 9 Brion Vibber 2008-04-09 20:07:18 UTC
In the lack of a strong reason to change the system, the default logical position is *always* to not make the change. The burden of proof lies on the change.

There's relatively little justification given for the requested change, and it doesn't seem an appropriate change to me.

The reason I see given is based on a reinterpretation of how MediaWiki categories work, from 'practical navigational tagging tool' to 'strict logical semantic hierarchy'.

Given that strict logical semantic hierarchies are pretty much impossible to maintain in a world full of non-hierarchical, overlapping, sloppy concepts, and that MediaWiki is designed to run an online encyclopedia under constant construction by multiple authors, and that it is therefore a requirement to handle non-hierarchical, overlapping, sloppy concepts, and that it is *not* a requirement to handle strict logical semantic hierarchies (which do not exist in the real world and cannot be maintained given our environment), I see little benefit to adding complexity to the system to support something which is antithetical to the design and purpose of the system.
Comment 10 Le Chat 2008-04-11 10:30:13 UTC
Thanks for the fuller explanation. I still think the categorization software needs some additions though. My wish is not for an absolutely strict semantic hierarchy, since this would be unrealistic as you say, but it does seem realistic to strive for a fairly consistent treatment of categories within a given project. And the present state of the software seems not to be conducive to this - it doesn't provide appropriate features for handling all the situations in which people want to use categories. And making categories work sensibly is important, if only because they are part of the content on each and every Wikipedia article page. Anyway, this particular proposal wouldn't make a major difference, so no need to discuss it further, but as promised above, I hope to be making a more useful proposal sometime later.  

Note You need to log in before you can comment on or make changes to this bug.