Wikimedia Commons

Commons:Images on normal pages or categories:Vote

This page is presently inactive and retained primarily for historical interest.
If you want to revive discussion regarding the subject, you may try using the talk page (though your voice may not be heard) or start a discussion at the Village pump.

There's been quite some discussion about where to place images on WikiCommons: in normal pages with image galleries, or on category pages, using the category feature. To get to a discussion, this vote was started here, hoping that the outcome will be clear enough to get a policy out of it.

Options edit

Basic edit

  • normal pages: As far as possible, we try to get images on galleries on normal pages. Each image is supposed to be on at least one normal page.
    • advantage: Pictures of similar subjects are taken together, watchlist functionality, easy renaming, headlines and subheadlines, Special:Unusedimages works for normal pages
    • advantage: less work for computers. The pages can be cached in both the Squid servers and the parser cache, so it is fast for the servers and pages will be displayed quickly
    • advantage: search works and will find the page with the related images. It's easy to add additional key words to help find them
    • advantage: sort order can be freely chosen
    • disadvantage: Extra work for humans, for each picture added one or more pages should be edited
  • categories: As far as possible, each picture should be put in one or more categories showing its subject
    • advantage: Categories can be added immediately when uploading the image, and galleries are automatically created on categories
    • disadvantage: It is not possible to add describing text, and it is not possible to change the size of the thumbnail, images added to category don't show up in the watchlist, renaming requires the name to be changed in all images, Special:Unusedimages does not work for categories
    • disadvantage: search doesn't find the page with the images because it doesn't search the contents of a category.
    • disadvantage: the choice of items (subcategories, pages or images) on a category page isn't cached so this approach will require a database search for every page view, preventing fast, cached page display. Resources used per page view are perhaps 1,000 times as much as for a normal page. Maybe more. (though this could be regarded as a mediawiki bug rather than a problem with the proposal itself).
    • disadvantage: sort order is fixed (by file name), unless arguments are provided ([[Category:Foo|Argument]])
    • Further information

Alternative edit

  • mixed system: Images can be both on normal pages and in categories; some can be both, but only images that are neither are considered 'defective'.
    • advantage: Provides freedom by allowing everybody to choose for themselves which method they prefer
    • disadvantage: Similar images can be in two completely different locations
    • Resources used per category page view are perhaps 1,000 times as much as for a normal page. Maybe more (though this could be regarded as a mediawiki bug rather than a problem with the proposal itself).
    • search doesn't find the page with the images because it doesn't search the contents of a category.
  • merged system (Andre's proposal): Like a mixed system, but instead of normal pages the editable text part of Category pages are used.
    • advantage: Provides the freedom of a mixed system while keeping the images on one location
    • disadvantage: Strange name for a page; images might show up twice on the same page (if they are both in the category and on the page)
    • as with categories, this isn't cached, so every page view will be slower than with normal pages. Even with nothing in the category part, it'll still be uncached (though this could be regarded as a mediawiki bug rather than a problem with the proposal itself).
    • search doesn't find the page with the images because it doesn't search the contents of a category.
  • merged system (Duesentrieb's proposal): like Andre's proposal, but change the Mediawiki software so that category and normal pages are the same thing (see comment in the comments section below).
    • advantage: Provides the advantages of a merged system without the strange name problem
    • disadvantage: Software changes take time, which might easily be several months and also is unknown.
    • Assuming the code for this is based on the current category system resources used per page view are perhaps 1,000 times as much as for a normal page. Maybe more.
    • search doesn't find the page with the images because it doesn't search the contents of a category.

Because of the time issue with Duesentrieb's proposal, its voting is given a separate status - whoever votes for it should also state what should be done in the meantime.

Voting is with open end ´cause software changes will need time, but if there is a clear outcome before that date, it will be considered policy pending discussion.

If there is any discussion about the voting process, changing or addition of option, please try to resolve it before Christmas 2004 to give everyone the option to vote on it without having to extend the voting period.

Votes edit

Please have a look to Category:Animal habitat maps, Category:Potala and Frankfurt am Main/Category:Frankfurt am Main as 3 different examples and compare before you vote.

Use normal pages (87) edit

  1. Pro I thougt it is easier to store pictures. --Uwe W. 14:24, 14 October 2005 (UTC)[reply]
  2. Pro. Use normal pages but ensure that the search engine is as good as possible - might be worth looking into modifying the wiki software to incorporate a good engine (something from the Apache Foundation perhaps) 83.67.19.223
  3. Pro. I know exactly how to prepare an Article and its associated Gallery but I can't understand Categories at all, they are much too complicated - Arpingstone 20:42, 17 Mar 2005 (UTC)
  4. Pro. It's simple and clear. --134.2.240.228 22:25, 26 Feb 2005 (UTC)
  5. Pro. Categories are way too complicated and have too many possibilities. Take for example The Gameboy and its variants category. I made a Gameboy page before I even realized some one had, for some reason, made a category. I referred all the game boys (Gameboy, Gameboy Color, Gameboy DS...) to that page but I am planning on making a regular page. Catagories are a pain. --Mboverload 00:34, 23 Feb 2005 (UTC)
  6. Pro. Searching only works with normal pages. (New developments will come or will not. Who knows?) --Franz Xaver 16:21, 20 Dec 2004 (UTC) - added later: It is much easier to change the name of a normal page (e.g. wrong spelling) than the name of a category. --Franz Xaver 21:39, 20 Dec 2004 (UTC)
    • Comment: These are legitimate complaints, but they can be fixed with software. Quadell (talk) 15:27, 21 Dec 2004 (UTC)
  7. Pro. I think it's more clear. --Aldipower 03:14, 21 Dec 2004 (UTC)
  8. Pro Greatpatton 08:03, 21 Dec 2004 (UTC)
  9. Pro. It is easier to split pages if you only have to move a part of the text instead of changeing on the pictures the categorie. (e.g. Salt Lake City and Temple Square)--Donny 10:11, 21 Dec 2004 (UTC)
  10. Pro, not really sure, though. --Mormegil 10:41, 21 Dec 2004 (UTC)
  11. Pro, it is much easier to search. --Hautala 11:45, 21 Dec 2004 (UTC)
  12. Pro, much more structured, easier to find stuff --Lennert B 15:49, 21 Dec 2004 (UTC)
  13. Pro --Factumquintus 16:38, 21 Dec 2004 (UTC)
  14. Pro for now anyway, revisit in a year to see if cats are sufficiently flexible. Stan Shebs 22:32, 21 Dec 2004 (UTC)
    This means in a year everything may have to be changed. That will be a hell of a lot of work! -- Chris 73 00:04, 22 Dec 2004 (UTC)
  15. Pro. This is good way to translate image descriptions. File names are not English only. --EugeneZelenko 03:57, 22 Dec 2004 (UTC)
  16. Pro. --Lukius 09:01, 22 Dec 2004 (UTC)
    Pro - I was about to say what EugeneZelenko wrote. Plus, the wikipedia.en already showed the absurdities of category schemes, which are useful of course if taken in moderate quantities. muriel@pt 11:13, 22 Dec 2004 (UTC) i also voted below, sorry! muriel@pt 11:14, 13 Feb 2005 (UTC)
  17. Pro --Steschke 18:53, 22 Dec 2004 (UTC)
  18. Pro --Lucero del Alba 20:05, 22 Dec 2004 (UTC) Better for searching.
  19. Pro For new user it is easier to understand --Heidas 21:24, 22 Dec 2004 (UTC)
  20. Pro --Pethan 20:06, 23 Dec 2004 (UTC)
  21. Pro unless watchlist functionality, easy renaming and description text is added to categories Ausir 10:46, 26 Dec 2004 (UTC)
  22. Pro The search engine of wikimedia commons does not search within categories, but only on normal pages Bernard bill5 18:04, 26 Dec 2004 (UTC)
  23. Pro I would vote Duesentrieb if it was said how he planned to deal with the repitition issue and if watchlist issues were dealt with Plugwash 03:37, 28 Dec 2004 (UTC)
  24. Pro -- Steffen M. 21:18, 28 Dec 2004 (UTC)
  25. Pro -- Get_It 01:42, 30 Dec 2004 (UTC)
  26. Pro --ocrho 20:26, 6 Jan 2005 (UTC)
  27. Pro --Marcelo Schlindwein 23:44, 6 Jan 2005 (UTC) It is more clear and easier to find.
  28. Pro --Väsk 22:50, 8 Jan 2005 (UTC) (it will be more easy to move pictures, organize galleries and split them if they get to large)
  29. Pro Kneiphof 15:02, 10 Jan 2005 (UTC)
  30. Pro --Emuzesto 01:28, 16 Jan 2005 (UTC)
  31. Pro easier to describe, search, rename, redirect, --Gabor 07:45, 19 Jan 2005 (UTC)
  32. Pro You can organize images on pages using any layout, give some descriptions for groups of images, etc Maximaximax 16:24, 19 Jan 2005 (UTC)
  33. Pro --Thommess 12:46, 23 Jan 2005 (UTC)
  34. Pro Raul654 08:13, 30 Jan 2005 (UTC)
  35. Pro When you see this page, you understand that put the images directly in the category isn't possible, besides a plane can have several images like F-16. --Dav 59 20:43, 30 Jan 2005 (UTC)
  36. Pro The 3 provided examples are in my opinion why images should be in articles and articles in categories. Also, try to put interwikis in the cat dav59 mentioned and see what happens... muriel@pt 00:20, 5 Feb 2005 (UTC)
  37. Pro Cleaner and easier to understand. Joanjoc 19:35, 10 Feb 2005 (UTC)
  38. Pro .:Ajvol:. 08:51, 12 Feb 2005 (UTC)
  39. Pro The category would also work if only there would be a logical structure (I spend too much time trying to find something through a category). The best (in my opinon) would be a picture inside an article and an article inside a category.--Lusitana 22:08, 12 Feb 2005 (UTC)
  40. Pro The automation of categories is more than offset by the difficulty of moving them. Pages also allow logical organization. Cool Hand Luke 07:06, 20 Feb 2005 (UTC)
  41. Pro It's just the better way --Schaengel89 @me 14:39, 20 Feb 2005 (UTC)
  42. Pro Allows better structuring/presentation of the appropriate pages - categories are sorted alphabetically and category pages can't have sub-heading – Sebari ☢ 03:42, 24 Feb 2005 (UTC)
  43. Pro--Fanghong 03:46, 25 Feb 2005 (UTC)
  44. Pro--Ecemaml 18:10, 1 Mar 2005 (UTC)
  45. Pro--Spm 17:40, 6 Mar 2005 (UTC)
  46. Pro, of course: Mats Halldin 20:10, 12 Mar 2005 (UTC)
  47. Pro, suppose with Franz Xaver, Nordelch 20:20, 12 Mar 2005 (UTC)
  48. I support this. This is the only proposal here which does not propose making Commons a denial of service attack on the servers. Jamesday 00:43, 14 Mar 2005 (UTC)
  49. Changing support to this option, since apparently there was no basis in other statements suggesting that categories were a solved problem. --IMeowbot 01:56, 16 Mar 2005 (UTC)
  50. Pro -- Arnomane 19:45, 18 Mar 2005 (UTC)
  51. Pro --Ikescs 07:22, 19 Mar 2005 (UTC)
  52. Pro --Patrick-br 11:23, 21 Mar 2005 (UTC)
  53. Pro more work? let's begin ;) --Roger Zenner -!- 00:32, 22 Mar 2005 (UTC)
  54. Pro -- da didi 15:42, 28 Mar 2005 (UTC)
  55. Pro --Groucho 05:02, 21 Apr 2005 (UTC)
  56. Pro Romary 10:18, 27 Apr 2005 (UTC)
  57. Pro Piotr Kuczyński 13:07, 29 Apr 2005 (UTC)
  58. Pro --Jcornelius 14:06, 2 May 2005 (UTC)[reply]
  59. Pro --Denniss 09:34, 3 May 2005 (UTC)[reply]
  60. Pro Taragüí @ 13:40, 3 May 2005 (UTC)
  61. Pro--Jpbrenna 03:36, 18 May 2005 (UTC) 03:23, 18 May 2005 (UTC)[reply]
  62. Pro --Jwnabd 11:55, 21 May 2005 (UTC)[reply]
  63. Pro -Didactohedron 10:00, 28 May 2005 (UTC)[reply]
  64. Pro Thue 23:37, 28 May 2005 (UTC)[reply]
  65. Pro--Corcoran 17:53, 8 Jun 2005 (UTC)
  66. Pro --Mayhem 08:18, 13 Jun 2005 (UTC)
  67. Pro Pyramide 19:09, 13 Jun 2005 (UTC)
  68. Pro. --Erin Silversmith 19:34, 15 Jun 2005 (UTC)
  69. Pro -- Orchi
  70. Pro --M7 13:49, 19 Jun 2005 (UTC)
  71. Pro Charlie123 11:51, 20 Jun 2005 (UTC)
  72. Pro In my opinion, using normal pages secures the easiest way to find what you look for. --wg 22:05, Jun 22, 2005 (UTC)
  73. Pro Nice "normal pages" with structured galleries (no article) that can be linked by Wikipedia. --Schandolf 17:38, 23 July 2005 (UTC)[reply]
  74. Pro NielsB 19:12, 22 August 2005 (UTC)[reply]
  75. Pro --Dirk Beyer 13:20, 26 August 2005 (UTC)[reply]
  76. Pro use of normal pages because of the advanced possibilities of content management and structurization. -- Wiki-observer 10:32, 2 September 2005 (UTC)[reply]
  77. Pro Henrik Reinholdson 21:33, 2 September 2005 (UTC) (for the structure to stop category galleries with to many images in total disorder)[reply]
  78. Pro--Jonathan Hornung 09:37, 8 September 2005 (UTC)[reply]
  79. Pro--Unf 02:47, 27 September 2005 (UTC)[reply]
  80. Pro--Pawelekj76 13:31, 9 November 2005 (UTC)[reply]
  81. Pro I can provide keywords but searching for categories is too time consuming. --Shyamal 09:51, 14 December 2005 (UTC)[reply]
  82. Pro Easy to search, simple and clear. --Anniolek talk 15:07, 8 January 2006 (UTC)[reply]
  83. pro --Lienhard Schulz 19:58, 16 January 2006 (UTC)[reply]
  84. Pro It's simplier. --Ivana1 17:10, 19 January 2006 (UTC)[reply]
  85. Pro gallery pages for images, categories for gallery pages. --BLueFiSH ?! 23:25, 1 March 2006 (UTC)[reply]
  86. Pro --Absar 17:47, 9 September 2006 (UTC)[reply]
  87. Pro -- Bo-rhein-sieg 15:44, 24 November 2006 (UTC)[reply]
  88. Pro --Denis Barthel 19:04, 1 July 2007 (UTC)[reply]
  89. Pro --Okki 23:23, 12 July 2007 (UTC)[reply]
  90. pro --Mbdortmund 17:59, 24 March 2008 (UTC)[reply]

Use category pages (85) edit

place your vote here

  1. Pro. Jeanot 07:57, 15 September 2005 (UTC)[reply]
  2. Pro Articles belong to Wikipedia itself. Or at most, have a mixed system from which people can choose. Rama 20:35, 25 Jan 2005 (UTC)
  3. Pro 'Cause wikimedia commons is about the files, and nothing else. Normally, everybody writing articles in any Wikimedia project should know enough about his topic(s) & should't need extra articles describing the photos/soundfiles/etc., as long as they're properly named and categorized. -- Mezzofortist 18:42, 17 Jan 2005 (UTC)
  4. Pro It is easiest to add the images to categories. Hopefully, describing text can be added in the future showing piped links. -- Chris 73 00:15, 21 Dec 2004 (UTC)
  5. Pro most of the time, I (and I guess others also) look for pics through the cat system - it will make life easier. and we should pressure category search to be default, and there's no problem. Felagund 10:21, 21 Dec 2004 (UTC)
  6. Pro. It's the best solution for the software we have now. Quadell (talk) 15:24, 21 Dec 2004 (UTC)
  7. Pro - So we can do the opload in one opration (so far we know the Category) Nico-dk 23:14, 21 Dec 2004 (UTC)
  8. Pro. Wouldn't that be easier? BethOHara 03:45, 23 Dec 2004 (UTC)
  9. Pro. It's a lot less work to add a category, than to create artificial pages with links. TeunSpaans 11:28, 23 Dec 2004 (UTC)
  10. Pro. Easiest way to add images (creating/editing separate pages is a hastle). An image description though piped links would make viewing pictures better. Johnteslade 18:23, 23 Dec 2004 (UTC)
  11. Pro. Problems will be overcome with software changes. We need more long-term policies. "Pages work OK for now" is fine up until MediaWiki 1.5 is released with all the category concerns addressed, and then we have a huge backlog of work to do. This is like all the images that were resized to 700px wide before uploading so that "they look nice on a monitor", now we have 1.4 which has solved this problem but we are without all those high-res pics we could've had. The category system's automation is clearly a great feature, let's think of ways to make categories work better, and then go to meta:. ed g2s • talk 03:44, 26 Dec 2004 (UTC)
  12. I upload mostly soundfiles. They are conformant to a naming convention. I upload LOADS of files and apart from adding them to a category which can be done at the same time as a copyright message, I will not add it to something else as well. GerardM 10:29, 27 Dec 2004 (UTC)
  13. Pro. --Shin-改 T 14:42, 29 Dec 2004 (UTC)
  14. Pro Silverfish 01:15, 30 Dec 2004 (UTC)
  15. Pro and agree strongly with ed g2s --BesigedB (en|talk) 13:11, 30 Dec 2004 (UTC)
  16. Pro. Categories are easier to use than article pages until Duesentrieb's Proposal can be implemented. Josh 23:39, 30 Dec 2004 (UTC)
  17. Pro --Boris 13:28, 31 Dec 2004 (UTC)
  18. Pro Jeffdelonge 15:37, 31 Dec 2004 (UTC)
  19. Pro. The good principle in big projects is KISS (Keep It Simple, Stupid). I think the level of complexity added with other solutions is not justified. Numerous articles created just to show the images make even more load on the webservers, which are currently extremely slow. The most important issue is: how should it be done properly, in a well designed system. The answer is -- (1) add image description (multilingual if possible), (2) attach it to appropriate categories. Those are the most important metadata, which should be placed in the database. The issues like searching, size of thumbnails, etc. are transitional. They can be someday fixed with MediaWiki upgrade, but we will then have a properly organised database, not a mess of articles, categories, categories combined with articles and other dirty tricks. The most important issue is to enable searching the image description pages, and if that works, other issues can wait. Wanted 13:22, 3 Jan 2005 (UTC)
  20. Pro I have been using this system for some time now, and I should like to continue doing so. --Sten 15:49, 3 Jan 2005 (UTC)
  21. Pro Michiel1972 12:20, 13 Jan 2005 (UTC) - it's fast..
  22. Pro Let the software manage it; why have a manual process? RedWolf 22:24, 16 Jan 2005 (UTC)
  23. Pro. Categories mandatory, pages optional. Dbenbenn 01:20, 24 Dec 2004 (UTC)
  24. Pro. I, and I think many others, just use the commons like a file server for the wikipediae, so we're unlikely to put much effort into collecting images together - relying on a few people to make everybody's images look nice seems unwise. Of course it would be great if the software improved so category pages were slightly easier to search. --Andrew 05:40, 18 Jan 2005 (UTC)
  25. Pro --Exdaix 19:08, 19 Jan 2005 (UTC)
  26. Pro, its way faster, less chance to make a mistake or forget to enter the image in a normal page. Duesentriebs Prop would enhance using categories even more --Jdiemer 10:08, 22 Jan 2005 (UTC)
  27. Pro --Thuresson 22:14, 24 Jan 2005 (UTC)
  28. Pro much easier to handle and maintain --Paginazero 20:31, 26 Jan 2005 (UTC)
  29. Pro - let's keep it as easy as possibe --Londenp 20:29, 1 Feb 2005 (UTC)
  30. Pro--PaolaMargherita 15:53, 6 Feb 2005 (UTC)
  31. Pro, the easiest system to work with at the moment with the least potential for inconsistent duplication. --MarkSweep 06:14, 7 Feb 2005 (UTC)
  32. Pro, categorys are much easier to use! Just place a [[Category:"subject"|{{PAGENAME}}]] link on the page and the image will automatically appear as a thumbnail image at the category page. // Solkoll 14:44, 9 Feb 2005 (UTC)
  33. Pro for many of the reasons above. Bob Palin 20:39, 14 Feb 2005 (UTC)
  34. Pro - categories, and subcategories, make sorting much easier and automatic. Put an image in one category, make sure that category is in the right categories, and immediately, the image is in all the right categories. TimShell
  35. Pro says Threedots 07:07, 17 Feb 2005 (UTC)
  36. Pro seems a lot easier from the uploader's point of view. I've a ton of images that I'd like to upload but I would shiver if I had to make Commons pages for all of them as well as including in Wikipedia (thanks to people who have put my images on pages where I have been too lazy!) Blorg 00:28, 18 Feb 2005 (UTC)
  37. Pro says --TaubeNuss 16:14, 21 Feb 2005 (UTC)
    Pro Right now it's too confusing to figure out where/how to list a file, and using categories means fewer places to edit in the common case. --IMeowbot 16:42, 27 Feb 2005 (UTC) I hadn't realized that all these changes were proposed without asking the devs first. --IMeowbot 01:48, 16 Mar 2005 (UTC)
  38. Pro Why would you post an image with no text? Why would you, or anyone, have to translate it? Post the image in a simple page, comment it linking it to anything you need. And if I like the image, I'll translate the text myself (using free translation tools if I don't speak the language) and eventually participate to link it. Ultimately, anyways, only the data used in Wikimedia Projects will be important. So data and meta-data are all that matter for the future. Oh, and how did I find that image in the first place? Well, you're meta-data should be aimed at helping me find it. Do it in your language and in English... --PecK 22:52, 01 Mar 2005 (CET)
  39. Pro -- user:zanimum
  40. Pro - With catgorisation it is easy to define the metadata of a media file so that it answers many needs (i.e. has several categories assigned). To do this on pages means copying to a variety of pages and assumes that the searcher understands where you might have put it. All media files should have fully populated meta-data expressed as categories . There is probably more work to do with categorisation conventions to make categories work better but that is no reason to move away from categories. Velela 17:09, 8 Mar 2005 (UTC)
  41. Pro — Jeandré, 2005-03-10t12:02z
  42. Pro - easiest and most flexible, easy moving images between galleries --Derbeth 22:05, 13 Mar 2005 (UTC)
  43. Pro —Ævar Arnfjörð Bjarmason 21:00, 22 Mar 2005 (UTC)
  44. Pro Den fjättrade ankan 22:41, 22 Mar 2005 (UTC)
  45. Pro Breeze 11:28, 30 Mar 2005 (UTC)
  46. Pro silsor 21:54, 31 Mar 2005 (UTC)
  47. Pro Easiest to use -- Maclemo 12:40, 4 Apr 2005 (UTC)
  48. Pro Waste of time to create another page. Don't expect me to create any, feel free to add them if you want. Dori | Talk 01:16, 8 Apr 2005 (UTC)
  49. Pro It's the least-hassle option. I want to add a picture and get on and use it, not faff around adding it to pages on here. -- Joolz 14:36, 14 Apr 2005 (UTC)
  50. Pro Otherwise it's just a whole lot of effort that doesn't really benefit anyone Maccoinnich 15:50, 16 Apr 2005 (UTC)
  51. Pro Simplest - commons are a media store -- Tomhab 20:24, 16 Apr 2005 (UTC)
  52. Pro It is easy for the uploader. You can use several categories for each picture. Most of the problems can be solved in software. --Rune Magnussen 15:41, 26 Apr 2005 (UTC)
  53. Pro Use categories now, change the software to add the benefits of articles to categories in the long run. RoceKiller 10:56, 5 May 2005 (UTC)[reply]
  54. Pro Categories are easy to maintain and there's not language issue involved. --Romanm 21:20, 5 May 2005 (UTC)[reply]
  55. Pro Yann 12:52, 8 May 2005 (UTC)[reply]
  56. Pro Rex 14:12, 23 May 2005 (UTC) - Simply because it's easier.[reply]
  57. Pro Andrew pmk 21:15, 26 May 2005 (UTC) Much easier.[reply]
  58. Pro Benjamin Shlevich 17:24, 6 Jun 2005 (UTC)
  59. Pro Arj 11:58, 8 Jun 2005 (UTC)
  60. Pro Easier for those of us who don't use English as primary language to find related pic's. G®iffen 16:07, 8 Jun 2005 (UTC)
  61. Pro Alers 11:50, 13 Jun 2005 (UTC)
  62. Pro PedroPVZ 00:51, 16 Jun 2005 (UTC)
  63. Pro Marco Bonavoglia 18:24, 19 Jun 2005 (UTC)
  64. Pro the category system is simple and less time consuming. Nichalp June 27, 2005 12:00 (UTC)
  65. Pro Alex Bakharev 28 June 2005 13:07 (UTC) More flexible and easier to use. Easier support for mutilpe languages
  66. Pro User:Docu - We will need to categorize the images anyway. If we don't, unrelated images will just fill up various higher level categories, just because someone packed 20-30 on a gallery page. BTW, yes, a feature allowing to do category intersections would be handy.
  67. Pro Andel 16:12:09, 2005-July-25
  68. Pro Categories are easy and simple to use, because they work exactly as they do on Wikipedia. I don't really understand what an article is in the context of Commons; it doesn't seem to bear any relationship to an article on Wikipedia. It also seems to increase the amount of descriptive text, which is problematic from a multi-lingual perspective, and should it not be on Wikipedia anyway?. -- Chris j wood 20:18, 26 July 2005 (UTC)[reply]
  69. Pro petrus 22:43, 28 July 2005 (UTC)[reply]
  70. Pro ChongDae 08:04, 17 August 2005 (UTC)[reply]
  71. Pro --Kai11 08:29, 29 August 2005 (UTC)[reply]
  72. Pro The software can be changed to solve all problems with the category approach (maybe except for the sorting order, but this is irrelevant anyway). So: no more work for humans, let the computers work! -- Haui 15:55, 15 September 2005 (UTC).[reply]
  73. Pro --Schubbay 16:42, 27 September 2005 (UTC)[reply]
  74. Pro Brosen 11:04, 11 October 2005 (UTC)[reply]
  75. Pro Because it is easier --Stephan Herz 09:16, 2 November 2005 (UTC)[reply]
  76. Pro It is easier to add an uploaded image (or other media) to a category. (Sorry wasn't logged in) —Kingruedi 15:58, 12 November 2005 (UTC)[reply]
  77. Pro all my points have been made by others already. pfctdayelise 01:42, 18 November 2005 (UTC)[reply]
  78.   Support thats less work for humans. We don't have all that time... Mattes 13:19, 10 December 2005 (UTC)[reply]
  79. Pro This is the most user friendly way t.m.o. It would be nice if some technical drawbacks would be solved. Mark 18:19, 18 December 2005 (UTC)[reply]
  80. Pro *drew 06:37, 3 January 2006 (UTC)[reply]
  81.   Support We can be happy if the pictures can be found in categorys. None wants to do the search and edit the articles! Metoc
  82. Pro Categories only. Articles belong to the respective Wikipedias. Handling with categories easier and faster. --Neoneo13 23:53, 9 January 2006 (UTC)[reply]
  83. Pro --Flominator 13:38, 28 January 2006 (UTC)[reply]
  84. Pro It is easier to add an uploaded image Maksim 09:58, 29 January 2006 (UTC)[reply]
  85. Pro It isn't as complex, and will help any newbies out there. Lrd1rocha 09:24, 4 March 2006 (UTC)[reply]
  86.    Support Per Quadell reasons.--68.216.187.39 01:29, 23 May 2006 (UTC)[reply]
  87. Pro Articles are difficult to create sometimes, support categories but articles can remain as well obviously as part of a category. Gryffindor 17:09, 11 November 2006 (UTC)[reply]
  88. Pro Categories are the only efficient system. Short articles are useless, and it is painful to glance through long articles, because the pictures density is low (lower than in categories). --Juiced lemon 18:43, 14 November 2006 (UTC)[reply]
  89. Pro The more you upload, the more you have to love categories. Less hassle. --Fb78 12:15, 20 February 2007 (UTC)[reply]
  90. Pro I think we NEED to have each image categorised. Otherwise they are difficult to retreive, and some images become lonely and forgotten ! Baronnet 14:06, 24 August 2007 (UTC)[reply]
  91. Pro Categories are the only way that will work. Articles of course good for Wikipedia but are evil here. --Avron 14:23, 3 March 2008 (UTC)[reply]

Use a mixed system (34) edit

  1. Pro. With a strong emphasis on normal pages because I would not want to miss the option to use (sub-)headlines (for example here: Angkor). Categories could be applied to images where it is useful. --Tsui 10:26, 21 Dec 2004 (UTC)
  2. Pro. With Categories being mandatory, but normal pages optional. andy 12:10, 21 Dec 2004 (UTC)
  3. Pro.--Shizhao 13:12, 21 Dec 2004 (UTC)
  4. Pro.--Aphaia 07:56, 22 Dec 2004 (UTC) Mainly category, but a normal page with some typical images is useful.
  5. Pro. villy 08:20, 22 Dec 2004 (UTC). Cf. andy POV.
  6. Pro.--Quistnix 19:48, 23 Dec 2004 (UTC)
  7. Pro.--FEXX 20:27, 26 Dec 2004 (UTC)
  8. Pro.-- Pedant 19:09, 30 Dec 2004 (UTC)
  9. Pro.-- Guillaume Bokiau 01:56, 31 Dec 2004 (UTC) Perfect to avoid too much sub-categories (example : Frankfurt\History-Culture-....) the extra work is worth it.
  10. Pro.--12:49, 1 Jan 2005 (UTC)
  11. Pro--llywrch 18:28, 4 Jan 2005 (UTC)
  12. Pro. Categories are more immediate to implement on the image description page, and for thumbnail gallery view - they should be considered mandatory. Pages can also be very useful, especially for multi-language text (on the same page or on individual pages, maybe with a link to the English-named category) or for creating a special-purpose gallery on the fly without the need to edit 20+ image pages to add a category tag ;) Ary29 14:39, 5 Jan 2005 (UTC)
  13. Pro. Martin 17:40, 7 Jan 2005 (UTC)
  14. Pro. Changing the software the proposed way is probably a bad idea. Emphasis on categories. --grin ✎ 14:26, 11 Jan 2005 (UTC)
  15. Pro Mainly because that is what we use. Interlanguagecategorylinks ;-) would be great for that notafish }<';> 13:31, 13 Jan 2005 (UTC)
  16. Pro - Blueshade 11:09, 14 Jan 2005 (UTC)
  17. Pro - LoopZilla 14:34, 20 Jan 2005 (UTC)
  18. Pro - Some people prefer Cats, others (like me) normal pages due to the search. I think FfM ist an example how it should be. Dickbauch 08:56, 26 Jan 2005 (UTC)
  19. Pro - Firefox 16:56, 26 Jan 2005 (UTC)
  20. Pro --Corse-Calvi 12:47, 14 Feb 2005
  21. Pro --Bubuka 20:00, 27 Feb 2005 (UTC)
  22. Pro --Sir Gawain 13:00, 5 Mar 2005 (UTC)
  23. Pro --Decumanus 00:36, 19 Mar 2005 (UTC)
  24. Pro - Against changing Mediawiki ad hoc, don't want too much strain on servers. Pages and categories provide different ways of organizing information, both valuable. If one scheme or the other proves less useful, it will get abandoned as a matter of course. -- Phyzome is Tim McCormack 19:53, 24 Mar 2005 (UTC)
  25. Pro - I am comfortable using either, though I prefer the category system. Kevyn 13:39, 7 Apr 2005 (UTC)
  26. Pro --skINMATE 08:24, 29 July 2005
  27. Pro --normal pages are really nice to discover e.g. a city, but IMO categories are still necessary for any picture, even if not needed by Joe Wikireader ClementSeveillac 21:52, 9 August 2005 (UTC)[reply]
  28. Pro -- Every image should be catted, but it can be good to have images on normal pages, too. — Xiong熊talk* 22:56, 2005 August 29 (UTC)
  29. Pro Shaqspeare 13:14, 12 November 2005 (UTC)[reply]
  30. Pro --Ronaldino 21:14, 10 December 2005 (UTC)[reply]
  31. Pro I think we need both - the category and the article. An article in Wikipedia and in Wikicommons is not the same. Articles in Wikipedia are text-based with pictures. Articles in Wikicommons can be picture- or media-based. In an article we are able to show a structured information - but in a category you can see all pictures which belong to it. --S.Möller 15:38, 14 December 2005 (UTC)[reply]
  32. Pro They both have their advantages. I use whichever is best for the subject. --Pmsyyz 07:23, 28 December 2005 (UTC)[reply]
  33. PRO --Klemen Kocjančič (Pogovor - Quick response) 10:58, 27 January 2006 (UTC)[reply]
  34. Pro. In categories we place all images and on the pages - only selected images.--Ahonc (talk) 13:00, 3 July 2008 (UTC)[reply]

Use a merged system (Andre's proposal) (4) edit

place your vote here

  1. pro. Several advantages: a personal choice is possbile between very little effort (while uploading you can directly put it in a category), and more effort but large flexibility. Also: while working on the top part of the category, you can directly see all other pictures in the category and add them with comments. In (the far) future a software update would in theory be possible removing the thumbnails from the lower part, when the picture is also shown in the upper part. Elly 10:46, 22 Dec 2004 (UTC)
  2. pro. I don't think a merged system in the way Duisentrieb suggests is feasable; too many category pages already contain text that may not be possible to move automatically to the corresponding normal page. And I think Categories is a more flexible way of organizing data than simply including them in a single ordinary page. But Duisentrieb's idea to include the corresponding ordinary page as a template is very good! This would make it possible for those who prefer using ordinary pages to continue doing so, while still exploting the advantages of using Categories. -- Kjell ANDRÉ 19:00, 2 Jan 2005 (UTC)
  3. pro. Shouldn't Andre Engles, who suggested this, be counted here too? Please remove if you don't agree (Kjell André).
  4. I hate “democracy”. Ramir 13:08, 2005 Apr 7 (UTC)

Use a merged system (Duesentrieb's proposal) (123) edit

... using normal pages until it is implemented (0) edit

place your vote here

... using category pages until it is implemented (11) edit

place your vote here

  1. pro This works for me.Quadell (talk) 15:29, 21 Dec 2004 (UTC)
  2. Pro Anything with a category system works for me -- Chris 73 00:00, 22 Dec 2004 (UTC)
  3. Pro. villy 08:21, 22 Dec 2004 (UTC)
  4. Pro --Thomas G. Graf 14:46, 23 Dec 2004 (UTC)
  5. Pro. This is a good compromise. Josh 23:32, 30 Dec 2004 (UTC)
  6. Pro. This is the way it should be, as uploading of images will be easy and an "atomic operation" (i.e. no need to edit 2 pages (or more) for one image). --Jdiemer 10:09, 22 Jan 2005 (UTC)
  7. Pro. --MarkSweep 22:12, 11 Feb 2005 (UTC)
  8. Pro. --Ggonnell 23:51, 27 Mar 2005 (UTC)
  9. Pro. – Kaihsu 1 July 2005 14:55 (UTC)
  10. Pro -- iGEL (talk) 20:16, 23 July 2005 (UTC)[reply]
  11. Pro -- Ecki 16:00, 4 November 2005 (UTC)[reply]
  12. Pro -- Evrik 05:17, 16 January 2007 (UTC)[reply]

... using a mixed system until it is implemented (108) edit

place your vote here

  1. Pro --GunnerPoulsen 11:05, 16 March 2006 (UTC)[reply]
  2. Pro --Elgaard 12:49:35, 2005-07-14 (UTC)
  3. Pro --Maros 00:09, 18 Jun 2005 (UTC)
  4. Pro El Comandante 21:47, 12 Jun 2005 (UTC)
  5. Pro Karmosin 18:00, 3 Mar 2005 (UTC)
  6. Pro. Because a mixed system is what we have now, and changing the system twice would be a waste of time. Duesentrieb 16:01, 20 Dec 2004 (UTC)
  7. pro full ack. :Bdk: 10:15, 21 Dec 2004 (UTC)
  8. pro Darkone (¿!) 15:13, 21 Dec 2004 (UTC)
  9. pro This works for me.Quadell (talk) 15:29, 21 Dec 2004 (UTC)
  10. pro WεFt 21:16, 21 Dec 2004 (UTC)
  11. Pro Anything with a category system works for me -- Chris 73 00:01, 22 Dec 2004 (UTC)
  12. Pro. villy 08:21, 22 Dec 2004 (UTC)
  13. Pro. use-to-abuse 11:00, 22 Dec 2004 (UTC)
  14. Pro. Reinhard 01:50, 23 Dec 2004 (UTC)
  15. Pro. If I understand duesentrib's proposal correctly, I think this would work well. BethOHara 03:46, 23 Dec 2004 (UTC)
  16. Pro. I like it this way... --Avatar 08:48, 23 Dec 2004 (UTC)
  17. Pro Trevithick 11:58, 23 Dec 2004 (UTC)
  18. Pro I agree with Chris 73, anything with categories is a good idea. Deviantart works much like this, with the ability to add images to categories as well as specific info for each image. Glitch010101 16:25, 23 Dec 2004 (UTC)
  19. Pro Simplicius 19:43, 23 Dec 2004 (UTC)
  20. Pro Maarten van Vliet 20:30, 23 Dec 2004 (UTC)
  21. Pro Malene 22:14, 23 Dec 2004 (UTC)
  22. Pro James F. (talk) 06:32, 24 Dec 2004 (UTC)
  23. Pro Zeimusu 13:07, 24 Dec 2004 (UTC)
  24. Pro With emphasis on regular pages. At this point, I don't think we want an image categorized in ten different langauges. That would make a page look ugly. Yet in order to promote re-use of our free contents, it is very very important to sort and exhibit them in many languages. It means that listing images in the regular pages are much more important than using categories. Tomos 21:01, 25 Dec 2004 (UTC)
  25. Pro Hellisp 19:43, 26 Dec 2004 (UTC)
  26. Pro I prefer the category-system but I think the mixed system won't be a problem as long as it stays a temporary solution. --chris 論 22:10, 26 Dec 2004 (UTC)
  27. Pro --BigDipper 23:19, 4 Jan 2005 (UTC)
  28. Pro SeballaOne 12:07, 27 Dec 2004 (UTC)
  29. Pro Fphilibert 14:29, 27 Dec 2004 (UTC)
  30. Pro Jthiesen 22:47, 27 Dec 2004 (UTC)
  31. Pro Monet 15:20, 28 Dec 2004 (UTC)
  32. Pro Ikiwaner 20:50, 28 Dec 2004 (UTC)
  33. Pro David.Monniaux 15:24, 31 Dec 2004 (UTC)
  34. Pro Oldak Quill 10:17, 1 Jan 2005 (UTC)
  35. Pro Aka 11:32, 1 Jan 2005 (UTC)
  36. Pro Neutrality 05:18, 2 Jan 2005 (UTC)
  37. Pro Kpjas 20:41, 2 Jan 2005 (UTC)
  38. Pro Golbez 23:34, 2 Jan 2005 (UTC)
  39. Pro Ranveig 16:23, 3 Jan 2005 (UTC)
  40. Pro MilesTeg 20:40, 4 Jan 2005 (UTC)
  41. Pro Diego UFCG 22:33, 8 Jan 2005 (UTC)
  42. Pro Urby2004 09:05, 9 Jan 2005 (UTC)
  43. Pro notafish }<';> 12:06, 13 Jan 2005 (UTC)
  44. Pro Blueshade 11:11, 14 Jan 2005 (UTC)
  45. Pro Agree with Duesentrieb. Juntung 14:17, 16 Jan 2005 (UTC)
  46. Pro Sounds like the best solution. Paycheck 13:03, 17 Jan 2005 (UTC)
  47. 同意. Itkewe pirka soryuushon. Node ue 01:52, 18 Jan 2005 (UTC)
  48. Pro KayEss 07:21, 18 Jan 2005 (UTC)
  49. Pro Jurema Oliveira 05:24, 19 Jan 2005 (UTC)
  50. Pro Jacobolus 08:20, 20 Jan 2005 (UTC)
  51. Pro Greudin 11:14, 20 Jan 2005 (UTC)
  52. Pro Jcornelius 15:16, 20 Jan 2005 (UTC)
  53. Pro --Finanzer 23:16, 20 Jan 2005 (UTC)
  54. Pro Giorgio. (Drop a note) I'm here 08:10, 23 Jan 2005 (UTC)
  55. Pro --Conti|✉ 14:19, 25 Jan 2005 (UTC)
  56. Pro --Raymond de 14:22, 25 Jan 2005 (UTC)
  57. Pro --Addicted 13:35, 26 Jan 2005 (UTC)
  58. Pro --Chepry 08:46, 28 Jan 2005 (UTC)
  59. Pro Dub 13:23, 30 Jan 2005 (UTC)
  60. Pro Maryna Ravioli 17:08, 31 Jan 2005 (UTC)
  61. Pro Andrew pmk 00:42, 3 Feb 2005 (UTC)
  62. Pro Pamri 12:53, 5 Feb 2005 (UTC)
  63. Pro Sounds good. -- Serpens 07:38, 6 Feb 2005 (UTC)
  64. Pro With emphasis on categories. --Glimz 04:26, 7 Feb 2005 (UTC)
  65. Pro Krzych 17:02, 10 Feb 2005 (UTC)
  66. Pro Sj 15:47, 11 Feb 2005 (UTC)
  67. Pro With emphasis on normal pages. Jastrow 14:48, 13 Feb 2005 (UTC)
  68. Pro DCLXVI 18:20, 13 Feb 2005 (UTC)
  69. Pro Formulax 08:21, 15 Feb 2005 (UTC)
  70. Pro Ckeen 17:24, 15 Feb 2005 (CET)
  71. Pro --Arturo Reina 13:50, 25 Feb 2005 (UTC)
  72. Pro Christiaan 12:20, 26 Feb 2005 (UTC)
  73. Pro But new system should support different languages as good as currently articles, i.e. same content can be in different language articles, articles don't have to be in categories, pictures do TarmoK 21:39, 28 Feb 2005 (UTC)
  74. Pro --Joterr 10:35, 1 Mar 2005 (UTC)
  75. Pro Probably the best way to avoid orphaned pictures in the future --Eichendorffschule 16:54, 8 Mar 2005 (UTC)
  76. Pro --HappyDog 15:23, 10 Mar 2005 (UTC) I think that as long as the new software resolves all of the points mentioned in User:Quadell/The_category_solution then that is the way forward, and that it's not worth making the change twice.
  77. Pro Sounds reasonable. --195.19.204.69 18:41, 12 Mar 2005 (UTC)
  78. Pro Shouldn't change everything twice. - Omegatron 05:33, 18 Mar 2005 (UTC)
  79. Pro Mats Halldin 21:46, 3 Apr 2005 (UTC)
  80. Pro Walkerma 21:04, 8 Apr 2005 (UTC)
  81. Pro Duffman 21:54, 21 Apr 2005 (UTC)
  82. Pro Eleassar777 16:14, 23 Apr 2005 (UTC) - should also support different languages
  83. Pro It irks me that I currently have to add everything twice, and this was the least disruptive option. Cheers, Donovan. 11:34, 2 May 2005 (UTC)[reply]
  84. Pro -- Andreas -horn- Hornig 15:18, 3 May 2005 (UTC)[reply]
  85. Pro --Snek01 00:14, 12 May 2005 (UTC)[reply]
  86. Pro Sometimes it's more useful to use articles that point to categories [[:Category:Algarve]], others it's better to use categories that point to articles [[Algarve]] --OsvaldoGago 18:41, 12 May 2005 (UTC)[reply]
  87. Pro --Zinnmann 23:40, 13 May 2005 (UTC)[reply]
  88. Pro --Quasipalm 21:55, 26 May 2005 (UTC)[reply]
  89. ProLongbow4u18:12, 28 May 2005 (UTC)[reply]
  90. Pro --Sweets 21:21, 3 Jun 2005 (UTC)
  91. Pro Pro But new system should support different languages Kolossos 09:17, 5 Jun 2005 (UTC)
  92. Pro WernerHerdecke 00:16, 7 Jun 2005 (UTC)
  93. Pro 84.173.97.86 12:13, 9 Jun 2005 (UTC)
  94. Pro. --Erin Silversmith 19:35, 15 Jun 2005 (UTC)
  95. Pro Chamaeleon 20:43, 15 Jun 2005 (UTC)
  96. Pro I just hope it happens soon. :/ Kmccoy 03:38, 21 Jun 2005 (UTC)
  97. Pro--PatrickD June 26, 2005 22:46 (UTC)
  98. Pro --Kh80 30 June 2005 07:11 (UTC)
  99. Pro --Stefan-Xp 20:23, August 3, 2005 (UTC)
  100. Pro --Rdnk 11:08, 9 August 2005 (UTC)[reply]
  101. Pro --che 03:52, 23 August 2005 (UTC)[reply]
  102. Pro --Huebi 08:42, 24 August 2005 (UTC)[reply]
  103. Pro --ALE! 22:11, 22 September 2005 (UTC)[reply]
  104. Pro --Ronaldino 21:00, 10 December 2005 (UTC)[reply]
  105. Pro --Lienhard Schulz 19:57, 16 January 2006 (UTC)[reply]
  106. Pro -- Much easier in the long run.Dannycas 03:26, 20 January 2006 (UTC)[reply]
  107. Pro --Nielsmo 17:08, 6 March 2006 (UTC)[reply]
  108. Pro --Yann 19:13, 23 August 2006 (UTC)[reply]
  109. Pro --Hasan Sami Bolak 17:02, 26 September 2006 (UTC)[reply]
  110. Pro Plants is a normal-page system, will you write the bot to convert it? --Ayacop 15:34, 11 October 2006 (UTC)[reply]
  111. Pro Wojsyl 17:45, 20 February 2007 (UTC)[reply]

... using Andre's proposal until it is implemented (11) edit

  1. Pro. Has the advantage of easiest transition once the software changes are made. Peter_Aut 15:10, 20 Dec 2004 (UTC)
  2. Pro. So far, I never understood the distinction between category and article. With this proposal, the distinction would simply become obsolete, and categories would become searchable. --wpopp 10:07, 21 Dec 2004 (UTC)
  3. pro This works for me. Quadell (talk) 15:29, 21 Dec 2004 (UTC)
  4. Pro Anything with a category system works for me -- Chris 73 00:01, 22 Dec 2004 (UTC)
  5. Pro. villy 08:22, 22 Dec 2004 (UTC)
  6. pro. Elly 10:49, 22 Dec 2004 (UTC)
  7. Pro --Zeimusu 13:07, 24 Dec 2004 (UTC)
  8. Pro --Walter 13:10, 30 Dec 2004 (UTC)
  9. Pro kind of, if we use for that Dusentrieb's proposal of including the main article in the category with a template. notafish }<';> 12:39, 13 Jan 2005 (UTC)
  10. Pro I prefer categories. --CSamulili 16:30, 16 Jan 2005 (UTC)
  11. Pro The merged system allows a quick provisional fix to have everything together, when, confusingly, there is an article and a category on a subject.--Patrick 12:33, 7 Feb 2005 (UTC)
  12. Pro--Porao 15:43, 21 November 2005 (UTC)[reply]
  13. Pro Human resources is the bottleneck, not IT resources. Therefore we need to get rid of this unmaintainable, chaotic coexistence of categories and pages, the quicker the better. Andre's proposal is a good first step of the transition that doesn't create any double work, but makes it possible to start ASAP. PanchoS (talk) 14:26, 4 February 2010 (UTC)[reply]

... using any proposal until it is implemented (1) edit

  1. In the long run what we use now is unimportant. I'm fine with any of them. BrokenSegue 02:01, 23 Dec 2004 (UTC)

Comments edit

The category solution edit

Please see User:Quadell/The category solution for more information on how this could work, and why I support it as a solution. Quadell (talk) 18:03, 22 Dec 2004 (UTC)

I've found new articles Unknown birds, Unknown creatures and Unknown plants. It's clear that those would work a great deal better as Category:Unknown birds and Category:Unknown flowers or whatever - One could simply add such images by uploading them with the comment [[Category:Unkown birds]] and there would be no need to update any other page on the wiki, not even the image-page itself. Peter_Aut 13:15, 25 Dec 2004 (UTC)

Another idea that would address some of the concerns of those in favor of articles with galleries: To allow better captioning of galleries on category pages, the mediawiki software could be changed (easily, I suppose) so that when you put 

[[Category:Corvus|C. corone]]

on Image:Image1.jpg, and 

[[Category:Corvus|C. cornix]]

on Image:Image2.jpg, they show up on the category page Category:Corvus as if there had been the wikitext 

<gallery>
 Image:Image2.jpg|C. cornix
 Image:Image1.jpg|C. corone
</gallery>

This would make categories into customized image galleries.

Now if it would also be possible to transclude those galleries into articles by saying {{Category:Corvus}}, everybody should be happy. If those two changes (flexible captioning, gallery transclusion) were implemented, one could also rename the namespace "Category:" into "Gallery:", since that would be the primary function of categories. --MarkSweep 19:31, 11 Feb 2005 (UTC)

D'oh! Some of this has already been discussed further down on this page. --MarkSweep 19:33, 11 Feb 2005 (UTC)

Duesentrieb Proposal edit

I, Duesentrieb, would like to explain a few things about my proposal. Most importantly, as far as I can see the changes needed on the software would be minimal - the only difference to the way categories are handled now is a change in the namespace - [[Foo]] and [[:Category:Foo]] would simply point to the same page. So, one can say it would show category content on normal pages. But it make the idea clearer to just say to that we would use the category-pages as they are now as if they where normal pages, and put them in the main namespace.

A comment to Andre's proposal: as a compriomise, it would be possible to include the "main" article of a category into the category-header, just like a template. So, just put {{:Rainbow}} into the category-header of Category:Rainbows - i did it for that category, so have a look... (if my proposal was to be implemented, this would mean that a page would include itself as a template recursively, so this would have to be undone in this case) -- Duesentrieb 16:01, 20 Dec 2004 (UTC)

Excellent idea! This is easy, and it would give us a mixed system (which I think is unavoidable) that uses the best of both "main" pages and Categories. -- Kjell ANDRÉ 19:11, 2 Jan 2005 (UTC)
That completely misrepresents how bad this proposal is. A normal page view is served by the Squid cache servers. A Category page view cannot be cached by the Squid cache servers or the parser cache. Instead every view of a category requires a database search. That is, this is a proposal to make Commons a denial of service atack on the web servers by serving pages in the most inefficient way they can be produced. Jamesday 00:43, 14 Mar 2005 (UTC)

Just wondering....isn't there a way to cache these category pages (with a small modification, of course)? I would think a minimal delay in updating categories would be okay. --Mattwj2002 05:40, 16 Mar 2005 (UTC)

we already have an touching system used for templates on normal pages. As far as i can tell the only reason categories aren't cached is because they haven't become a big enough problem for the developers to bother making them cacheable. Plugwash 19:15, 17 Mar 2005 (UTC)

Categories edit

With categories, a new feature to include piped links in Categories would be most useful. Currently, images can be added to categories for example as [Category:Exlorers|Amundsen, Roland] to have it sorted under "Amundsen, Roland". This shows the image name and file size only, which is not needed by most users. A good feature would be to show not the image name but the piped text "Amundsen, Roland", in which case more information can be added, e.g. [Category:Exlorers|Amundsen, Roland at the pole in 1911]. This would be also useful if Duesentriebs Proposal gets implemented. -- Chris 73 00:35, 21 Dec 2004 (UTC)

Whole-heartedly agree. Quadell (talk) 15:29, 21 Dec 2004 (UTC)
As I suggested on the village pump earlier, one could even take this one step fursther, by allowing labels in different languages to be specified in the category-link, like this: [Category:Cities|Munich|de=München]. The label to use would then be selected by the users interface language (which can be selected in the preferences since 1.4). This would reduce cache-hits, but other then that i think it would be a major step towards a truely multilingual project. -- Duesentrieb 20:37, 21 Dec 2004 (UTC)
Whole-heartedly agree. -- Chris 73 23:58, 21 Dec 2004 (UTC)
Really great to have that kind of multilingual feature. Tomos 21:58, 25 Dec 2004 (UTC)

Searching Categories edit

Many users prefer articles because they can be searched. But Categories can also be searched. Either select the options individually for each search, or set your preferences to include categories and image pages into the search. Best of course would be if this is the default option in the system. This would probably be easy to change in the software, just toggle the default search flags. -- Chris 73 13:01, 21 Dec 2004 (UTC)

Exactly. I wish more people would realize this. An I whish people would also realize that you can use the category header for structured information, just like you do in a "real" page. Oh, well... people stick to what they know, i guess. :-/ -- Duesentrieb 18:49, 21 Dec 2004 (UTC)
I've created some pages at Category:Cypriniformes this way. Especially at Category:Barbus titteya can be seen how this works, if there is more than one image. What still lacks is other information than the filename. Peter_Aut 19:49, 21 Dec 2004 (UTC)

This does not really work well: I set my preferences as proposed. Now I still do not find Cypriniformes if searching for "Cypriniformes". You do only find it, if you write "Category:Cypriniformes" into the search window. That means: You have to know, if you are searching for a category or for a normal page. --Franz Xaver 22:20, 21 Dec 2004 (UTC)

Still something that could be easily fixed by a small software change. -- Chris 73 23:57, 21 Dec 2004 (UTC)
Yes, Searching for text in Category names works! There must be som kind of misunderstanding if it does not work for Frans Xaver. I have changed my preferenses as Chris 73 suggests, in "Search result settings" and "Search these name spaces by default" to include Category, and now I get several hits when searching for Cypriniformes. But I really think it would be a good thing if this was the default, both here and in the ordinary wikis. -- Kjell ANDRÉ 11:15, 2 Jan 2005 (UTC)
Now this also works for me, however it did not before. Probably someone has fixed it. --Franz Xaver 12:19, 7 Jan 2005 (UTC)

Category - language issues edit

Just to illustrate one concerin I have..

An image depicting a sunset of a beach in San Francisco could be categorized as "sunset" "beach" and "San Francisco." Possibly more, if there are something else notable in the picture (such as children at play, for example).

Now, I strongly doubt that we want to use multiple languages for these categories. Just using, say, 5 languages for the three categories makes it 15 tags to one image. The image page would look a bit awkward. And remember how many languages active in Wikipedia projects...

But if we rely heavily on English or any other single language, it would be against our principle of promote the use of free contents. We would want to serve people who do not know even the basic vocaburaries of English very well.

For this reason, I think it is good to use regular pages in as many languages as we can, and category in a limited number of languages.

If I may clarify further, I think it is fine that people who uploaded pictures (and other media files) do not list the files in any page. Other volunteers can take care of that just like when someone contribute an unformatted chunk of well-written text to Wikipedia.

Tomos 21:53, 25 Dec 2004 (UTC)

Well, just like it is now with articles, categories would be in English (or Latin in case of biology galleries), with redirects in other languages and translations in the category/article text itself. Ausir 10:51, 26 Dec 2004 (UTC)
A few section above this one, and on the Village Pump, i suggested a solution for this: have category-aliases (like redirects, but better) and allow labels in different languages. Generally, I belive that the mediawiki-software is not really ready for a multilingual project yet - articles are a little, but not much better for multilingual content. We could fur instance use project-internal interlanguage links, etc. I hope there will be some talk about these things at the developers convention which starts tomorrow. -- Duesentrieb 19:21, 26 Dec 2004 (UTC)
Categories shpuldn have a name, but an ID. Depending on the language the user choosed the linked name to this ID is shown, if the language is not yet in the name table, the english version is shown. But this makes it diffcult for beginners to create new categoeries and it is a lot of work to change the existing categoeries ans split them into an ID a storing the names in a different table. Nevertheless, it can be done by a small script, replacing the name by an ID, and store the name with an english tag in a spearte table. Its more work to adopt the wikimedia to this two tables in every place. --Huebi 10:26, 24 August 2005 (UTC)[reply]
I second this. However, the IDs should consist of ASCII characters that can be interpreted as English (Latin for species) words or (an ASCII transliteration of) proper nouns. This has an obvious advantage for people understanding English. For people who don't, the strings copied-and-pasted are meaningless either way. -- 3247 11:08, August 25, 2005 (UTC)
I have created a separate page concerning this language issue, Commons:Language for categories, in order to keep things a bit more manageable. Gryffindor 13:35, 3 December 2006 (UTC)[reply]

Watchlist functionality edit

Currently, if a new image is added to an article, users who have the article in their watchlist would see it there. It is not true with categories, and it would make watchlist useless on Commons to use the category system, unless it is made possible in 1.5 to see new articles added to a category in the watchlist. Ausir 10:57, 26 Dec 2004 (UTC)

Renaming edit

Currently, renaming categories takes a lot of time - you have to change the category link in all articles in that category. It would be great if by moving a category with the "move" tab, you would change the category link in all its articles automatically. Ausir 10:57, 26 Dec 2004 (UTC)

Actually, there are bots that can do this. But I agree that it would be much nicer if the mediawiki-software could do that. -- Duesentrieb 19:17, 26 Dec 2004 (UTC)
Well, not anyone can use bots - and a wiki is supposed to be easily editable by everyone... Ausir 23:35, 26 Dec 2004 (UTC)
This is a bad ideia. If it is implemented, one can mix several categories that should not be mixed. Only if we have an easy way to undo. --E2m 05:44, 17 Jan 2005 (UTC)
A better solution is if category redirects work the way you'd expect. Namely, if Category:A redirects to Category:B and Foo is in Category:A, it would show up in Category:B. Then the "move" feature would be just like for articles: move the text, and leave a redirect behind at the old page. dbenbenn | talk 16:42, 24 August 2005 (UTC)[reply]

Duplicate-free pages in a merged (or hybrid) system edit

What about pages that can be edited and structured similar to normal pages but contain a Category section where the remaining photos/files are listed? A newly started Category would automatically generate category pages as at present. With handwritten text added, files explicitely included therein would no longer show up in the 'category' part of the page. -- Klaus with K 11:24, 1 August 2005 (UTC)[reply]

End date edit

When does this poll end? Or is this the kind of poll which goes on forever? It seems like a critical issue which should be decided soon. BrokenSegue 02:01, 28 Jan 2005 (UTC)

i think realistically it will stay open until Duesentrieb's proposal is implemented (since current consensus is to maintain the status quo until that is done anyway. I think the chance of this proposal getting implemented any time soon is slim to nil. Plugwash 21:31, 25 Feb 2005 (UTC)
Really? It seems kind of critical to the usability of Commons. Is there any way we can push it up the list of things to do? —Christiaan 12:30, 26 Feb 2005 (UTC)
Eloquence makes some interesting comments in this regard:
http://en.wikinews.org/wiki/User:Eloquence/State_of_the_Wiki:_February_26,_2005#Software_needs
Here's how a normal page view is generated for the typical anonyous viewer:
  • The nearest Squid cache to them (Paris, Florida, or one of the others which are coming in other parts of the world) is asked for the page. It probably has it already and delivers it immediately. If not, it passes the request on to an Apache web server which makes some fairly cheap database requests to build the page.

Here's how a category page view is generated for the typical anonymous page viewer:

  • The Squid cache server can't cache the page so it's passed on to the Apache web servers every time. Can't be done by the nearest Squid cache server.
  • The Apache web servers ask a database server to make a comparatively slow query get a list of every page in the category and then build a page from those results.

The category way takes hundreds to thousands of times the resources of the normal page view and prevents serving the page from Squid servers close to the viewer. We're working hard to design the systems so everything possible is cached at the Squids, because that's the way to improve the performance of the systems.

It's possible, perhaps, to completely rewrite the way category pages are produced, so that they are also cached, perhaps by generating a normal page each time an item is added to or removed from a category. That's what it would take to try to make a categories approach work if Commons becomes as popular as I hope it becomes. For now, the extra costs of the categories approach are mostly invisible, because Commons is comparatively small and little used.

Absent that, Commons is going to end up explaining why each Commons page view consumes hundreds to thousands of times the resources of page views for other projects when there's an alternative, efficient, way available instead. At the moment Commmons traffic is sufficiently low that it's not completely obvious how inefficient this is. It'll become very obvious if Commons ever sees a lot of page views.

If anyone wants Commons to become popular, I suggest doing things efficiently until the way category pages are produced is rewritten. Jamesday 00:43, 14 Mar 2005 (UTC)

its not easy to do things efficiantly when noone tells you what is and isn't efficiant until extremely late in the desicion process. Plus there comes the question of WHY categories are so badly designed anyway? I suspect it is because they have never been used enough for the developers to care about how they perform. plus i don't see why categories aren't cached, we already have a touching system in place to deal with edits to templates surely this same system could be used to deal with edits that effect a categories contents. Is there any documentation out there on how categories actually work (i suspect there is a linking table of some kind)? What about stats on how much the queries to get the data for a category actually cost the database compared to those needed for a normal page view? Plugwash 02:19, 14 Mar 2005 (UTC)
It seems this whole poll is moot because the developers can't/won't make the changes and if they did it apparently wouldn't work well. Seems that mixed wins be default. BrokenSegue 03:20, 1 Apr 2005 (UTC)
This seems a good place to point out the tyranny of the developers. Hundreds of contributors can vote here for even a relatively minor software change, and it doesn't happen because developers don't feel like implementing it. In return for the privilege of having admin powers far in excess of those possessed by hundreds of contributors who no doubt make far greater daily contributions to Wikimedia projects, shouldn't developers be required to adhere to the will of the community just a tiny bit more than they currently do? Chamaeleon 20:40, 15 Jun 2005 (UTC)
I agree. Same problem with meta-templates (see the talk page or revert war history edit history for some of the contention this issue caused there, forcing humans to adapt awkwardly and painfully to software instead of the other way around.) - Omegatron 16:42, 14 July 2005 (UTC)[reply]
This seems a good place to point out the tyranny of the developers. Hundreds of contributors can vote here for even a relatively minor software change, and it doesn't happen because developers don't feel like implementing it. This is the most ignorant statement I read for months anywhere. Visit the link given above as to why you cannot expect soon from a handful of devs that have a dozen more important tasks to change probably thousands of lines of code within 150,000 other lines. Can you imagine 150k lines of code at all? That's quite a lot, my son. And I wouldn't feel any haste as unpaid coder if I had to read such offensive statements as yours. -- Ayacop 15:26, 11 October 2006 (UTC)[reply]
Any suggestion? They are volunteers, after all. --Eleassar   my talk 5 July 2005 11:17 (UTC)
Maybe instead of donating to regular Wikimedia, we should start a "prize fund" for only the features that we want. When a developer (or several) completes a feature, they get the money for that feature. Like the X prize.
It would be like bugzilla voting (except someone would actually notice it). - Omegatron 16:42, 14 July 2005 (UTC)[reply]

I think one problem is that the barriers to entry as a MediaWiki contributor are pretty high. You have to get Mysql, PHP, and Apache all working. I've managed to do it once, but it took a lot of effort.

That said, it is certainly possible to make categories and meta-templates be totally efficient. There's nothing inherently complex about these features. It just requires a lot of effort by developers who don't current exist. dbenbenn | talk 23:21, 28 July 2005 (UTC)[reply]

I agree with the sentiment, but please don't call them "meta-templates". That is a terrible misuse of language. A meta-template is a template about a template or templates; that is the meaning of that prefix. (Think: WikiMedia Meta-Wiki is about WikiMedia Wikis.) What are wrongly described using that term are templates designed to be multiply transcluded -- that is, daughter templates transcluded in a master template, which is then transcluded onto a target page. (Similar to, but not really the same as, Commons, which contains images which "stand in" for Wikipedia Image namespace files, and are then displayed on Wikipedia target pages.) It might make more sense to call these "common templates", but the dominant terms for such things pair them (master-slave, parent-child, etc.). Please help stamp out creeping ignorance and disrespect for the language that makes this all possible. Avoid calling daughter templates "meta-templates". Thank you.
That said, I agree that MediaWiki 1.6 is still an amazingly inefficient engine and cries out for a major overhaul. There is no reason for it to be so clunky -- except that we seem to demand that our developers work for FreeBeer, and we find a special virtue in poverty. — Xiong熊talk* 04:12, 14 September 2005 (UTC)[reply]
How do we make them exist? :-) - Omegatron 15:45, 29 July 2005 (UTC)[reply]
Well, we could make the process more friendly. For example, imagine a wiki for editing MediaWiki code: a server running MediaWiki, where the code it's running is editable. Then anybody could try out changes. (I know there are problems with that idea, but I guess they could be worked out.) The documentation in MediaWiki is pretty crappy (just like almost all programs), because once I bother to figure out how a particular function works, it isn't worth the effort to submit a patch via bugzilla just to add some documentation. dbenbenn | talk 16:37, 24 August 2005 (UTC)[reply]
Bad idea. The first features implemented would be spamming and distributing trojans. -- 3247 11:16, August 25, 2005 (UTC)
Bad idea. We don't need more unpaid developers chipping away at the Engine in their "free" time -- free is always most expensive in the long run. We need more paid developers working as if this was a Real Job. — Xiong熊talk* 04:12, 14 September 2005 (UTC)[reply]

Work the Machine, not the Man edit

After weathering the lengthy, bitter debate over multiple transclusion -- wrongly and ignorantly described as "meta-templates" -- I am frankly disgusted to see the same arguments arise here in a different guise.
It is just plain wrong to ask humans to do extra work for no better reason than to allow machines to do less.
I began my involvement with computing machines in the days of the Model 35 TTY, with long rolls of very cheap paper upon which smeared characters were hammered, very loudly; of 30 baud acoustic coupler modems; of time-shared mainframes. These dinosaurs were so large, expensive, unwieldy, and intractable that it took great patience to lead them to any useful, or even recognizable, activity. We had no choice but to serve the machine, if it were to serve us at all.
I have programmed analog computers by connecting computational elements with patch cables, an operation so fraught with risk that it was truly possible to pose a question to the machine that, if considered, would destroy it.
I have sat for hours at the keypunch, and reflected often on the inability of the device to unpunch a card.
I have cursed, exhorted, and beaten a procession of instant consumer computers, from the Timex Sinclair, the Commodore, the Atari, ad nauseam, right up to the top of the garbage pile, the Radio Shack TRS-80 ("Trash Eighty"). All had in common crappy displays, tiny memories, tinier keyboards, and shitty storage media -- if any.
I burnt my youth at the altar of these early machines, in exchange for the right to teach them to do tricks. Much of the time I might have spent (I will not say better, but perhaps more normally) gaming, drinking, and whoring -- I spent instead at the feet of the machine; occult, weighty tome in hand, groping for incantations to unlock arcane secrets.
My young manhood went much the same way. I was present at the birth of many a new machine; many failed, few succeeded, but all demanded the same unswerving loyalty to utter rationality, negation of every earthly and human demand, willingness to put the machine's needs and viewpoint ahead of all others.
I got out. I spent the next decade and a half writing, illustrating, and publishing; playing banjo on the street, clowning, driving taxicab, and teaching American English as a foreign language to students in China.
By the time I returned to Silicon Valley, much had changed. One might say my investment has paid off. Modern machines are so very much more powerful than their ancestors of only a few short years ago; so very much easier to use, if not to understand. A two year old child can now work a screen to produce something she (and I) find worthy -- if not of the Louvre, then at least of the Frigidaire.
Forty years ago, no novice ever used a screen directly. Indeed, few professionals ever saw the machine, except through a glass window or the dutch door on the other side of which worked the anointed few who fed and touched and curried the beast. Programmers of my father's era knelt to make offerings and returned to the dutch door at random intervals, hoping for an utterance of the oracle, and fearing its 132-column greenbar expression of displeasure.
Now, the screens sing and dance for us; they are quite tame. We carry them in our pockets and at whim, dispose of more computing power than put Men on the Moon. Any man carrying a PowerBook G4 under his arm, were he to go back in time to the year of my birth, would have been killed instantly for the prize, and nations gone to war over it. Yet he may be a complete technical idiot and still use this phenomenal power to chat with other fools around the world; to conjure up the libraries of humanity; to make visible models of that which formerly existed as mere dry equations; to enter fantastic universes so compelling as to be given the oxymoronic label of "virtual reality".
Still the priests labor, for we have yet to get up off our asses and make -- or allow -- the machines to breed themselves. Each one must still be midwifed by Men. Perhaps this is good; I think not. I would rather set them free, and by doing so, reduce the need for Men to feed their lives into Juggernaut. But this is still in future.
We have the capacity to build an engine to serve our Goal in this Project. We have sufficient presence to attract all the Cash Money this might ever require. The technology is sufficiently advanced that it may deliver, on demand, anything we require of it -- categories, templates, dynamic content. To the extent that we still require skilled professionals to groom the beast, we can hire them and pay well.
Instead, I see this same acolyte of the rack room bitching and moaning, urging us all to work harder, so he and his pet can rest.
I have all the sympathy in the world for this solitary, underpaid worker, slaving away, trying to run a 21st Century service with 20th Century technology. I have been that man. At the time, I thought it a privilege; now, I'm not so sure.
But I will be burnt in oil before I assent to humans working harder so that the machine can rest.

(failed to sign at the time I made this comment; sorry) — Xiong熊talk* 22:51, 2005 August 29 (UTC)

It is just plain wrong to ask humans to do extra work for no better reason than to allow machines to do less.
Obviously. In this case we are limited by economics, though. — Omegatron 18:56, 7 September 2005 (UTC)[reply]

Decision? edit

Today I did some effort to gategorize pictures. After more than a hour of work, another user started to delete the category entries and put the pictures in galleries. This frustrated me. Could someone please give some indications how to organize things here on Wikicommons? To my opinion, using two sytems (normal pages AND categories) at the same time is not efficient. It is better to concentrate on only one user-friendly system and organize it in a good way. I would be glad if just some guidelines were made clear. Mark 18:27, 18 December 2005 (UTC)[reply]

No, this is allowed by a mixed system. Also some parts of Commons explicitly favour galleries over categories (plants, animals...) and 98 per cent of images are in galleries. In those parts it would be offensive not to adapt and normal to remove your categories. -- Ayacop 15:31, 11 October 2006 (UTC)[reply]
I have had some problems too. IMO it is fine to use both a gallery and a category for an image, however not acceptable to remove an image from a category only for the sake of an article, since both systems are allowed. Gryffindor 17:06, 11 November 2006 (UTC)[reply]
Ack to Gryffindor -- Godewind 11:44, 21 January 2007 (UTC)[reply]

What can be done if a user persistently removes categories from an image (probably believing that a category in only a placeholder for images until they make it into a gallery page). He's not willing to discuss this, and I don't want to waste time and nerves revert-warring. Where can I look for help ? Wojsyl 16:49, 19 February 2007 (UTC)[reply]

There is no harm in raising this issue in Commons:Village pump because administrators will read and discuss there. If they do not know, they cannot take action.--Klaus with K 19:53, 19 February 2007 (UTC)[reply]
I assume you're talking about Image:Berlin Hotel Adlon.jpg ? Has there been any attempt at actual discussion about the matter, or is all communication simply in reverts? It might be worth taking it to the image's talkpage, or directing the discussion to here, or the Village Pump. --Elonka 06:22, 22 February 2007 (UTC)[reply]

Categories and Galleries: two different things edit

One has to see the commons as a very large museum that holds millions of photographs all piled up in its warehouses. The categories are the thousands of wires that connect the pictures together in some sort of logical fashion. If you follow for example the "rozes" wire, you will end up in the warehouse were most wires of the roses species come together, so you can try to follow specific wires, some might possibly lead to even roses in the Sahara or greenhouses in Alaska.

A gallery is an exhibition room of the commons museum. A gallery tends to be a nice exhibition of certain themes or subjects. An example could be, all the species of tradional (or wild) garden flowers that are pink and that have pins (or contain poison). In most galleries, the pictures that are exhibited are a selection of the best photographs that are properly labeled and possibly ordered following some logic, for example country of origin. Often, from the several pictures available around a comparable subject, only one or two handpicked pictures are shown in the gallery. Bigger galleries might be divided in several sections and might contain a table of contents to provide to the visitor an overview of the organisation of the exhibition. Because a gallery is often a nice overviewing exhibition organised by a person, dropping images in it by a third party might lead to conflicts.

In a large category organisation, a category is like a thick cable containing many wires. As the category is deeper organised, the cable is split into several sub-cables, which are in their turn split again and again in sub-cables. At the end, one has only a bunch of wires, each of them holding together the basic category, or what one could call an end node. Here a simple example: World --> Continents --> Countries --> Cities --> Towns.

An image that represents this well is a tree: trunk --> branches --> twigs --> leaves , why technical people speak of a node, end-nodes and leafs.

One of the major difficulties with category systems is that in fact, there are several category systems running in parallel. For example a painting can belong to many category organisations pertaining to the painting itself, its artist and the subject of the painting: period in time, geographical place, styles, techniques and materials, historical information, ... From that example can be seen that only category systems belonging on each image are capable of expressing all its relations; a gallery is a collection of images, each of them with many different characteristics. --Foroa 09:56, 21 April 2008 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Images_on_normal_pages_or_categories:Vote&oldid=686071525"