Hello
I just send the following mail to the wikitech-l list. As it mainly concerns the commons, i'll repost it here:
--------------------------------------------------------------------- Hi all
As you may now, there is some discussion about wether to use page to form galleries on the commons, or to use the new thumbnails-in-categories feature of 1.4 to do that. Both have their pros and cons, and no real solution has yet been found for this question (see http://commons.wikimedia.org/wiki/COM:VP for some discussion).
I would like to propose to simply do away with the difference between pages and categories (see http://commons.wikimedia.org/wiki/COM:VP#Categories_or_.27normal.27_pages:_A...)
by treating every page as a category. That is, IMHO it would be best to drop the "Category:" namespace and list articles and images the contain a category link like [[category:Foo]] directly at the bottom of page "Foo". This way, pages can be used as a structured article or as an unstructured category, as need be. The category-ish list at the bottom could also serve as a todo-list of stuff that need to be integrated into a structured page.
This would resolve the problem that categories aren't readily found by a simple search, and that there often is a category and a page for the same topic, containin different but overlapping sets of images, which would need to be kept in sync manually. This is annoying when looking for images about a specific topic.
I would like to make all pages categories for the commons - maybe the same thing would be a good idea for the wikipedias, too, but i'm not yet sure about this.
I had a conversation about his with Jamesday on IRC the other day, i'll try to summary some of the concerns and my answers below.
Q: List-Articles would still be needed, because categories can only show articles that exist. A: We could still do that, either by simply not using the category-aspect of the respective page, or be keeping the missing things at the top and the existing ones in the category-ish listing.
Q: Replication is a good thing, so users have a choice of how to ciew a gallery. A: Keeping the different views in sync is tedious and unrealistic. We already have a lot of images on the commons that can't be found because they are on no page and in no category. In cases where both exist, they are nearly never in sync, and they often do not link to each other. The entire structure is very inconsistent, and the distinction between pages and categories only makes things worse.
Q: Galleries can not represent internal structure. A: In cases where internal structure is needed, just don't use the category-aspect of the page, or use it as a todo-list.
A feature that allows for structure in categories is a different matter: maybe we could have sections in categories, using a syntax like [[Category:Foo#section-name]] or something. Or we could have a switch the shows sub-categories "inlined". Also, it would be extremely useful to show the link-text after the "|" in the category link (now only used for sorting) as the image-label in categories. But this does not really touch my idea.
Q: Categories can be very lagre. This would hinder the loading / viewing of the respective Articles. A: In most cases, large categories (just like large pages) should be split into subcategories - that would resolve this isse in most cases.
Bot some categories are large by nature, especially ones that are used for tagging images with copyright-information, etc. Those categories do not have a meaningfull article associated with them, they are simply very long lists, and it does not matter in which namespace they show.
Keep in mind that categories are simply pages that are filled in a diferent way and have no internal structure. With regards to the commons, there is no "logical" difference: they both consitute galleries.
In a nutshell: I can see only advantages to showing things in category "Foo" at the bottom of page "Foo". The distinction between articles and categories seems artificial and unneccessary, at least for the commons.
I was thinking about submitting this as a feature request - but i'm not sure if this would be the right way to go, as this is not only a little software feature, but a request for a structural change, too. So i'd like to discuss it here first - and maybe on some of the other mailing lists? I'm not sure which one would be most appropriate.