Hidden categories should appear in the category namespace, but not
elsewhere.
As for being "Hidden" or "Admin", I can envision uses for both.
Admin categories could have a separate collapsible listing, while hidden
categories might have some other uses. Since we've also been discussing
the problems of implementing "Category Intersection", an interim
solution could be repopulating parent categories and "hiding"
intersection categories. Fully populated parent categories are the norm
in some projects like German Wikipedia and they also appear sometimes in
English Wikipedia (eg. Category:Operas). I have a proposal posted
currently about fully populating "Index" categories at en:Wikipedia
talk:Categorization, and it would be much improved if the intersection
categories could be hidden. The primary reason we have been deleting
intersection categories is because they clutter articles. If they
didn't clutter articles, they wouldn't be a problem.
Perhaps the non-hidden categories could be expanded with a [+] the same
way subcategories are expanded. For example, if someone is listed under
"Methodist", clicking on the plus might add the hidden categories
"American methodist" or "Methodist presidents". This would require
searching to see if any of the hidden categories are descendants of the
clicked on category. This pseudo categorization intersection system
would also be an incentive to get ready for a real implementation. For
Category Intersection to work, hundreds of categories will need to be
repopulated.
Along those lines, I'm wondering about yet another interim step toward
full category intersection. A while back, several of us editors on
English Wikipedia worked on a design for an interface for implementing
Category Intersection (it is at en:WP:CI). We envision check boxes
next to each category listing in an article, and then a button that
queries the intersection. If making the query were to create a hidden
category and automatically categorize all the articles that result from
the query, the next time the request is made it could just display the
results, just like any other category. There might be a timer that
resets (every week?) that would force another query to update the
category. This way each intersection query would happen fairly
infrequently -- as infrequently as need be to keep from overloading the
servers.
There would need to be a naming convention for the automatically
generated categories, perhaps using a double colon -- so the
intersection of Category:Mozart and Category:Operas would generate
Category:Mozart::Operas. I don't think we'd want these auto-generated
categories to be orphan categories. The category could be
automatically put in a maintenance category, or better yet, a child
category of each parent could be created to hold all automatically
created categories. If the category is called "Operas" this holding
category could be called "Intersections with Operas" or "Operas
and..."
If the query is worth keeping it could be recategorized by an editor
(eg. Category:Operas by composer). It would probably be useful to be
able to see how often the query was requested. If intersection
categories get renamed, a category redirect should be able to get the
user (and future queries) to the correct place.
If any of these intersection queries cause problems, an administrator
could protect the category page. The next time the query is requested,
the blocked page would keep the query from being run. The user would
see the reason for the blocked query posted on the category page. This
would prevent two or more huge categories from being intersected (eg.
Category:Living People intersected with Category:Films). If the CPU
time was analyzed for each query automatically, the blocks might be able
to happen automatically.
-- Samuel Wantman
en:User:Sam