Commons:Village pump/Archive/30

From Wikimedia Commons, the free media repository

Jump to: navigation, search
Village pump (Archives)

2004: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 2005: 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 2006: 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 2007: 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 2008: 52 | 53 | 54 |

This is an archive. Do NOT post here.
If you want to restart an old topic, copy the entire topic to the Village pump and add your post like you would normally.

Contents


May 14, 2006

Category:Candidates for speedy deletion restructuring

Given the recent discussion about {{redundant}} and {{duplicate}}, I was thinking that perhaps Category:Candidates for speedy deletion should be separated into more categories. Specifically:

  • Category:Copyvio for clear-cut copyright violations and fair use images that were uploaded against Commons policy. These images could be deleted after a simple check of the nomination's validity; no CheckUsage would need to be done, as the responsibility would fall on the offending uploader. Suggested nominating template: {{copyvio}}.
  • Category:Superseded for what we now use Category:Redundant for, but named more clearly. Should include files that were made obsolete (ie. superseded) by clearly different, but (subjectively) "better" files (e.g. PNG → SVG, so PNG is tagged, JPG → PNG, so JPG is tagged, thumbnail to hi-res, so thumbnail is tagged). The procedure to delete these files would be the "cross" method: to replace it with a cross, and once usages have been replaced, delete the file (see {{Deleted duplicate}}). Suggested nominating template: {{superseded}}.
  • Category:Duplicate for images that seem to be or are in fact exactly the same. Only one should be tagged at the evaluator's discretion. The deletion procedure for these would be the same as for superseded. Suggested nominating template: {{duplicate}}.

Please keep in mind that the goal of this proposal is not to extend the bureaucracy, but to make Commons easier to manage. With this three-way speedy deletion sorting, obvious copyvios could be deleted faster, while those files that need more attention to check and replace usage would be separated to avoid having to fish trough CAT:CSD. —UED77 03:22, 14 May 2006 (UTC)

I agree that we should split up the speedy-category - but i'm not sure a three-way system is needed. In my mind, we need one cat for things that should be deleted fast, even if they leave "holes" in wikis (i.e. copyvios/non-free stuff), and things that should only be deleted if that does not disturb anyone (i.e.e duplicates).
After all the trouble we have had with "inferior" images being deleted prematurely, I would actually suggest not to treat "superceded" or "redundant" as speedy deletions at all - that should simply be an advisory, like {{vector version available}}, that may or may not be followed by a regular deletion request.
Another note about duplicates and redundant images: we must take care not to deleted images that are the basis of other images. I.e. when deleting (true) duplicates, the one with the full version history should be kept. Also, if someone made an SVG from a PNG, we should probably keep the PNG as being the original - we should also have a tag for this, something like superceded, keep because; OTOH, if someone simply uploads a rendered version in addition to the original SVG, we do not have keept that, IMHO.
Regards -- Duesentrieb(?!) 10:13, 14 May 2006 (UTC)
Indeed; it is a good idea to turn superseded and duplicate into marker templatates rather than speedy deletion templates. Then, regular (slow) deletion could be requested on a per-file basis. I recommend adding a {{badname}}, or something of the like, intended to be used if the uploader misnames an image, and reuploads it with the correct name; all inappropriately-named "duplicates" should be tagged as such, and the file will be placed in CAT:CSD (along with the clear copyvios; there is no need to separate these two). —UED77 02:10, 15 May 2006 (UTC)
Hm I had merged a lot of categories into speedy deletion, like categoy non-derivative category non-commercial and so forth... I think for clear copyvios category speedy deletion is the perfect place as they are indeed speedy deletion. But I agree with you that separating duplicates and superseeded files into other categories makes perfect sense. Arnomane 11:01, 14 May 2006 (UTC)
I agree fully; I don't see any need for CC-NC, CC-ND, or fair use categories, all that matters is that they are against our policy, and belong in CAT:CSD. Sorry if my original post wasn't clear on that. —UED77 02:10, 15 May 2006 (UTC)
All right. The new Category:Candidates for speedy deletion is done. It now has three subcategories: Category:Against policy for copyvios, Category:Incorrectly named for misnamed files, and Category:Duplicate for exact duplicates. The current nominating templates are {{copyvio}} and {{fair use}} for Category:Against policy, {{badname}} for Category:Incorrectly named, and {{duplicate}} for Category:Duplicate. All of these four templates still put files in Category:Candidates for speedy deletion as well.
In addition, {{redundant}} has been deprecated along with its category, Category:Redundant, and such files should no longer be considered to be speedies. Instead, slow deletion could be requested on a per-file basis.
Furthermore, {{superseded}} is now in effect, which places files into Category:Superseded for reference. {{vector version available}} was redesigned so that it calls {{superseded}}.
I might have made a mess of lang templates, but I was focused single-mindedly on getting the English done. Sorry if I broke anything. Now, if you'll excuse me, I need to crash (UTC-04) —UED77 07:29, 16 May 2006 (UTC)
I hope this is the last major reshuffle of the deletion categories :/ and please indicate VERY clearly for users who just want to delete their own mistakes, how to do it and NOT to list on COM:DEL. What on earth is the difference between {{superseded}} and {{redundant}}? pfctdayelise (translate?) 11:22, 16 May 2006 (UTC)
in theory, "redundant" is the same as "superceeded" - but it was and still is often used to mean "duplicate". So, to avoid confusion, it has been deprecated. Hm, Commons:Deletion guidelines needs to be changed to reflect the new types of deletion requests. -- Duesentrieb(?!) 12:06, 16 May 2006 (UTC)
Commons:Deletion guidelines still lists {{Redundant}} for dealing with duplicate images, and says nothing about {{duplicate}} which is preferred now i think ({{Redundant}} says use {{duplicate}} at least). --Tomia 18:11, 21 May 2006 (UTC)

Tags for images missing info

While we are at it: we have far too many "missing info" tags. here are a few:

So, what we need is to define a) what is crucial info b) what happens if it's missing c) what tags do we need. My personal take:

  • Crucial info: Author, License (verifiable), Source (if not original work); Date of creation is required for works claimed to be PD because of age (but is always nice to have).
  • If such info is missing, the image should be tagged and the uploader informed on his/her talk page. If there's no activity or hope of getting the required info for 7 days, the image should be deleted without further ado. Unlinking the image is not required for the deleting admin, but is appreciated.
  • We need one tag for each info that may be missing - could all be mapped to one generic template.

So, what do you think? What would be the best way to clean up this mess? -- Duesentrieb(?!) 22:13, 17 May 2006 (UTC)

It should be one tag! And it should work fast. And it is necessary to inform the uploader. and it must easy work for the admin to delete. I prefer Template:No source and Template:No license too. -- Rüdiger Wölk 22:41, 17 May 2006 (UTC)
For Untagged utility, read User_talk:Orgullomoore#No_tag_bot Sanbec ✉ 00:14, 18 May 2006 (UTC)
I think "unknown" must be redirected to "no license" and "incomplete license" to "no source" Sanbec ✉ 00:17, 18 May 2006 (UTC)
I agree. Less is more. pfctdayelise (translate?) 04:55, 18 May 2006 (UTC)


See changes in templates and at Commons:Copyright_tags#Tags_for_incomplete_or_missing_license_info Sanbec ✉ 09:39, 24 May 2006 (UTC)

New version of an image

Not sure if anyone else knows about this, but today I discovered that if I upload a new version of Image:Example.xyz, and type a summary of {{subst:Image:Example.xyz}}, the old summary will remain. This is certainly handy for preserving detailed info and copyright tags. Maybe {{subst:{{FULLPAGENAME}}}} should be pre-loaded into the "Upload a new version of this file" form? Seahen 17:22, 14 May 2006 (UTC)

Whatever you set on the upload summary, it doesn't show on the image page. The image page only copies that when it's void (when it's uuploaded first time). The summary is only to show in the upload entry. Platonides 19:18, 14 May 2006 (UTC)
You're talking specifically about Image:Parabel.png. When you're uploading a new version of an image, please use the summary to indicate how you changed the image. The only place your summary goes (for a new revision) is in the "File history" section at the bottom of the image page. Writing {{subst:Image:Parabel.png}} doesn't communicate anything, and the wiki code doesn't have any effect. User:dbenbenn 19:40, 14 May 2006 (UTC)

Template:ADRM2

Proponent of this license reverts changes that ask people to re-license files. This license is listed in Commons:Copyright tags#Unfree copyrights, so I protected this template.

However I ask help of anybody who knows legal issues better then me to participate in this dispute.

EugeneZelenko 18:44, 14 May 2006 (UTC)

The Gallery should have alt-text

The Gallery "element" (<gallery>) should have alt-text or link text.AirBa 22:21, 14 May 2006 (UTC)

Images in a <gallery> element can have alt text. See President of the United States for 43 examples :) —UED77 22:27, 14 May 2006 (UTC)

Interface links I18n now solved :-)

Hi folks I just got this bug fixed: http://bugzilla.wikimedia.org/show_bug.cgi?id=5925. I suppose this did annoy many of you for ages.... Please join Commons:Help page maintenance now and look at its sub pages for contributing translations and which conditions a translation of these important legal pages must meet in order to get directly linked from the interface. Have fun, Arnomane 23:08, 14 May 2006 (UTC)

Nice work with bugging the devs about the bug! I'll get to work soon. By the way, can this "/ISOCODE" not be extended for all pages? (i.e. if your interface is set to German and you click on a wikilink, you get directed to target/de instead of target if target/de exists, or if it doesn't, then to target?) —UED77 01:14, 15 May 2006 (UTC)
No this is not possible as you have no easy possibility determining the language as user did set. We would need a USERLANGUAGE variable or an automated jump into /-subpages in MediaWiki in order to make this work. Arnomane 06:13, 15 May 2006 (UTC)
There are some other pages not fixed yet. I put two of them at http://bugzilla.wikimedia.org/show_bug.cgi?id=5925 Sanbec ✉ 07:52, 16 May 2006 (UTC)

May 15, 2006

questions

can you check my images and add info? = Owe 15:03, 15 May 2006 (UTC)

Honestly it is your duty to check your files and giving them proper info. We have written many help pages in order to assist you as much as possible to do everything right on your own. We simpy don't have the time cleaning up after lazy people. So please see Commons:First steps and Commons:Licensing in order to see how to improve your image descriptions. And please read warnings like overwrite warnings (do not click the "ignore all warnings" checkbox). For exapmple you did overwrite Image:Images.jpg with an image that surely should have another name and it also lacks important information on author and source (a scan does not generate own copyright). Arnomane 15:18, 15 May 2006 (UTC)

May 16, 2006

Goldfish2.cropped.jpg

Goldfish2.cropped.jpg

this photo is in the marine sections of photos. There are KOI and goldfish in the pic, neither are marine fish. I'm pretty sure this is the wrong place to bring this to the attention of anyone that can and wants to change it but there it is. —Preceding unsigned comment added by 152.163.101.6 (talk • contribs) 02:28, 16 May 2006 (UTC)

WHY

Vipuser removed the Pin Yin and Zhu Yin versions f Main Page from MP LAng template. Why? And now it is PROTECT so cannot edit! HELP

You can still edit the Talk page. I would have to support his decision though. Here are the pages: Shǒu yè (pinyin) and ㄕㄡˇ ㄧㄝˋ (bopomofo or zhuyin). The pinyin one actually makes my skin crawl! Yuck.
Is there anyone who could read these that could not read the 简体中文 (simplified chinese) or 正體中文 (traditional chinese) versions? If you can honestly say yes to this, then there might be an argument for keeping these pages. And Chinese learners reading pinyin is not a good argument: we would expect them to read in their native languages. Also is there support on any other Wikimedia project for either of these 'languages'? If you can say yes to that as well, then we might be getting somewhere. --pfctdayelise (translate?) 04:13, 10 April 2006 (UTC)
The pages in both Hanyu Pinyin and Zhuyin Fuhao version is already exists since in May 2005, I've only updated the page layout for these two pages and not letting them to be abandoned. :) --Shinjiman 12:09, 18 May 2006 (UTC)
Resurrected from Commons:Village pump archive-27 by User:24.251.68.75
I don't know about BPMF -- I do know that little kids use it, and I'm *guessing* that it's also used for the mentally-disabled. I do know, though, that Pinyin is used in a practical way -- some things have been published in Pinyin, it is intended for people who know how to speak Mandarin (mostly national minorities who learned it as a second language), but didn't learn the characters. This would presumably include an audience of many millions of people. I don't know how many of them have internet access. And whether or not it makes your skin crawl is entirely irrelevant. --24.251.68.75 03:21, 16 May 2006 (UTC)
I am not aware at all of ethnic minorities using pinyin as anything other than an aid to learning full Chinese characters. In fact, your assertion is not mentioned on w:Pinyin so I encourage you to add it to that article ...with a credible source cited of course. Your last point is correct. But I don't see the point of keeping pinyin transliterations that are bound to go out of date when there exist several automatic converter tools (linked at the end of the WP article, e.g. http://www.rikai.com/ ). We should just provide a link to that, since that will always be up-to-date. Unlike automatic translators, an automatic pinyin converter will be extremely accurate, since for the vast majority of characters there is a 1-1 correspondence between character and pinyin.
We could provide an IPA transliteration of the English main page too, but we don't. I consider it very similar. pfctdayelise (translate?) 04:32, 16 May 2006 (UTC)
Wouldn't it be rather costly to put all minority adults into hanzi literacy education? So what do they do when they want to reach people who speak Mandarin but never knew how to read it?? You're probably the same kind of person as thinks we shouldn't have a Cantonese Mainpage. And you speak with such an air of importance, tell me, why does your opinion any more important than mine? ——Preceding unsigned comment added by 24.251.68.75 (talk • contribs) 05:49, 18 May 2006 (UTC)
OK, people who are completely illiterate will not be using the internet, let alone the Commons. It is ridiculous to provide pinyin on that basis. People who can speak Mandarin (but can't read characters) can't automatically read pinyin anyway! Why don't provide a strong argument to include such pages instead of resorting to snide personal comments? In this topic my opinion is only marginally more important than yours because I am willing to identify myself and stand behind it. Why don't you get an account? pfctdayelise (translate?) 03:12, 19 May 2006 (UTC)

Upload Size Limit

Sorry if this question has been answered, I couldn't find this exact answer, only similar). In a fresh MediaWiki installation on my computer, what is the upload file size limit? How can I change it / remove it?

Thanks, 84.109.54.93 13:44, 16 May 2006 (UTC)

First of all, you are in the wrong place, since your question is about en:MediaWiki, not en:Wikimedia Commons. Secondly, the upload size limit is a PHP setting, MediaWiki does not care. Look into the PHP documentation: http://www.php.net/manual/en/ini.php -- Duesentrieb(?!) 13:47, 16 May 2006 (UTC)
Thanks and sorry for the confusion. Ripper234 14:46, 16 May 2006 (UTC)

600,000 files

Commons reached 600,000 files yesterday while nobody was paying attention. I attempted a backcount of images based on current numbers, and the image I came up with is this one: Peperomia graveolens - Botanischer Garten Bonn.jpg, and I've created a page at Commons:Media File 600000, an image of Peperomia graveolens by Raymond de, that he took while he was waiting to get this image: Amorphophallus titanum with 3 flowers - Botanischer Garten Bonn.jpg. Cary "Bastique" Bass parler voir 18:01, 16 May 2006 (UTC)

These milestones are passing rather quickly. Which begs the question: what should we do when the time comes for 1 million files?
We should probably start translating a press release now ;)
How do we even count a million files? How do we discount the several hundred waiting to be deleted? And what if the millionth file is a copyvio? :) --pfctdayelise (translate?) 02:44, 17 May 2006 (UTC)
Easy. You count as the 1 million file the one that would make the {{NUMBEROFFILES}} show 600,000. You would only need to not start deleting a hundred files when you're between 999,989 and 1,000,020 ;)
Commons growing should avoid get under the million again. And i don't think that would be a problem. I'm sure there'll be several people ready to add dozens of files to beat the number. So we'll get good images plus images enough to not go down under the number.
In the case that this would be a copyvio, well, i'd sugger replacing it for a free version of the same content and give the new version the '1 million' name.
Platonides 09:52, 17 May 2006 (UTC)
Why don't we prepare the "1-million image", have it ready on another wiki, and plug it just in time to be the 1000000 image, No one would like to see a penis being the 1000000. Have the image researched, prepare good background, and so on. --Tarawneh 01:32, 18 May 2006 (UTC)

May 17, 2006

Email Confirmation

I created an account, and clicked on the button to generate an Email confirmation. When I got the Email, I clicked on the link to verify my Email address, but it came up "Email-confirmation_invalid" or something like that. Why? —Preceding unsigned comment added by Mrgabbard (talk • contribs) {{{2}}} (UTC)

Try again, and this time give us the exact error message? pfctdayelise (translate?) 02:46, 17 May 2006 (UTC)
"confirmemail_invalid" is the error message. I've tried it several times, and I get the same error message.
I finally got it to work. I'm not sure what the glitch was, but I must have done something right. Thank you.

Naming categories of maps that are "historical" / "old" / "showing history" / etc

Hello all,
Looking within Category:Maps, there sometimes seems to be confusion over the intended meaning of "historical" in subcategories' titles. "Historical maps" appears to be intended to mean pictures of old maps, but, understandably, it has also been taken to mean contemporary maps indicating something historical. Would anyone balk at or forsee problems renaming/creating these categories:

  • Category:Historical maps of X → Category:Old maps of X
  • Category:Maps indicating history of X (or the like) ...?

I'd suggest "old" is taken to mean "over a hundred years ago" and a message to that effect included at the top of the relevant categories' pages.
Thanks in advance for your thoughts, David Kernow 12:04, 17 May 2006 (UTC)

I don't see a problem with the rename; the clarification would be beneficial. Unfortunately, though, since a category would be split, it would have to be done by hand. Nonetheless, I like the idea. —UED77 18:11, 17 May 2006 (UTC)
Thanks for your support – as regards implementing the change, yes, I realise I'd need to work through the relevant categories; but I'm making enquiries as to whether I might be able to use AutoWikiBrowser or the like to assist... Regards, David Kernow 21:26, 17 May 2006 (UTC)
I couldn´t agree more with your propposed category "Old maps of ...." . In fact, this case is a fine example of too much techncality. "Historical maps" is simply an too ambigous description, whereas "Old maps of..." is simply easier too understand, but we have to add the proper text you propposed.
As for "Category:Maps indicating history of X (or the like)" I don´t agree with it. Keep it simple I say. If there are plenty of maps of an previous period, then sort it by the proper name (for example: "Maps of the British Empire" and not "Maps indicating history of the UK", the later would be completly useless in my opinion). "Old maps of X"
We should only create a new sub when we really need it and NOT before. Only when the number of maps reaches (more or less) 10 should we create a new sub.


Lets use real examples we can follow (and should implement, if we all can agree with it), lets not be too abstract:

Here is my proposal, on how we should handle all maps of every kind: First we have to turn the article Maps into a redirect to "Category:Maps". Then we put several categories inside of "Category:Maps" (we will have to rename a few)

"Maps of Europe", "Maps of Africa", "Maps of Asia", "Maps of North America", "Maps of South America", "Maps of Australia", "Maps of Antartica", "Maps per language" (for maps of the diffent languages), "Maps per religion" (diffrent faiths), "Maps of the Moon" (instead of Lunar maps), Maps of Mars (etc for all maps and images of all the planets and moons), "Old Maps" (for old maps, more than 100 years), "Maps per country", etc. There is simply NO need to have a sub called "Maps by continent". Let´s follow the example of Europe.

Inside of "Maps of Europe" we should have all maps and images which show Europe along diffrent views (geographical, linguistical, religious, etc). "Maps of Europe" would also have subs like "Maps of the EU", "Maps of Spain", "Maps of France", etc, "Maps of the Roman Empire", "Maps of the Byzantine Empire", "Maps of Austria-Hungary" (I know that these later states don´t exist anymore, but soo what? Ppl will still look for them following these links, so lets keep it simple).

Only IF needed (if there are simply too many maps) should we create more categories like "Maps of European Languages" and "Maps of European Religions" (let me repeat that: if there aren´t many of these maps, leave them under "Maps of Europe"). Let´s follow the example of Spain.

We have the geographic "Iberian Peninsula" (where Spain is located), today with 3 countries and a British overseas territory: Portugal, Spain, Andorra, and Gibraltar. According to history the Iberian peninsula (and therefore Spain) was inhabitated by the Iberian celts (or Celtic-Iberians or something like that), colonized by the ancient Greeks, the Carthaginians, conquered by the Romans, and invaded and colonized by the muslim Arabs. We had several countries at the time of the Reconquista like Portugal, Aragon, Castilhe, Navarre, and Leon. The later four joined into Spain. At the time of the Discoveries (or shortly after) Spain had a Spanish Empire and Portugal had a Portuguese Empire (alltough the later was never referred as such).

Lets assume the worst (best?) scenario: we have plenty of maps for everything (in fact it isn´t so, but this is only an example). Needless to say that "Category:Maps of Spain" should be a sub of "Category:Spain"

We need the following categories: "Maps of Spain", "Maps of Portugal", "Maps of Andorra", and "Maps of Gilbraltar". Then we need subcategories: "Maps of Pre-Roman Hispania", "Maps of Roman Hispania", and "Maps of Muslim Iberia". All of them should be subs of "Maps of Portugal" and ALSO of "Maps of Spain", etc. We don´t need "Maps of Pre-Roman Portugal" or "Maps of Pre-Roman Spain" or "Roman Spain" these countries did not exist at that time (to make these cat´s would only be technical nonsense and add to the confusion). Maps of Roman Hispania should logicaly also be in the category of "Roman Hispania" but there is really no need to create a sub called "Maps of Roman Hispania" (unless there are too many images).

Maps which are (more or less) over 100 years old of these areas should be organized under "Old maps of Spain", "Old maps of Portugal", etc. A old map of Roman Hispania should be under "Old maps of Portugal" and "Old maps of Spain" and certainly also be in "Old maps of the Roman Empire" and NO-WHERE else. There is no need to create another sub called "Old maps of Roman Hispania". Only if there plenty of maps of Aragon should we create "Maps of Aragon" which should be a sub of "Maps of Spain". Only if we have plenty of images of the Spanish Empire should we create such a sub ("Maps of the Spanish Empire") which should be a sub under "Maps of Spain". A image which shows a territory contested by Spain and by Portugal should appear in both of them, (there isn´t any, but there are plenty of countries which have such a thing). Maps of the city of Madrid should be in the cat "Madrid", and only if there are plenty of maps of Madrid should we create a sub called "Maps of Madrid" which should appear inside "Madrid" and also would appear as a sub in "Maps of Spain".

Articles should be organized under the correct categories. For example: a article about Spanish Maps should be found in "Category:Maps of Spain" (duh). a article about the whole Iberian peninsula should appearin "Maps of Spain" AND "Maps of Portugal", etc. An Article about old spanish maps should appear in "Maps of Spain" and "Old maps of Spain"

Keep it simple as possible, avoid overcatagorization, and create as few subs as we can. Flamarande 17:21, 18 May 2006 (UTC)

Thumb bug

Frozen Bubble.png

Hello, this image Image:Frozen_Bubble.png have a strange thumb seeing an computer hardware.

Is it possible to recompute the thumb ? ~ bayo or talk 13:25, 17 May 2006 (UTC)

Looks fine in Firefox. Cary "Bastique" Bass parler voir 18:00, 17 May 2006 (UTC)
Indeed it does. Try clearing your cache. —UED77 18:07, 17 May 2006 (UTC)
Its my cache. Thanks a lot. ~ bayo or talk 15:34, 18 May 2006 (UTC)

Inschrijving leden voor VWN

(This message is in Dutch. If you want it to be in your language, plese be bold, and translate it into your language and place it under mine.)

Beste Wikianen,

Mensen die lid willen worden van Vereniging Wikimedia Nederland, kunnen zich nu als zodanig aanmelden. Op nl.wikimedia.org kunt u meer informatie vinden over de inschrijfprocedure en de te volgen stappen. Ik hoop dat wij vele leden mogen verwelkomen.

Met vriendelijke groet, Lodewijk Gelauff aka Effeietsanders 21:06, 17 May 2006 (UTC)

Babelfish says: Dear Wikianen, People who member wants become of association Wikimedia the Netherlands, can submit an application now as such. On nl.wikimedia.org you can find further information on the inschrijfprocedure and the to next steps. I hope that we suffered a lot of can welcome. Kind regards... (--pfctdayelise (translate?) 07:22, 21 May 2006 (UTC))

Just to patch a hole in the translation, "inschrijf" is to sign up. But I guess you could figure that out :) —UED77 23:50, 21 May 2006 (UTC)

Need for further information on image pages

Moving from 500K images to 600K images is an indication of a condition that is only going to accelerate with time. Commons is exceptionally unique in that its most common pages are regarded somehow as second class citizens. This chauvinism is mostly due to historical reasons, but like other innovations, it takes a while to come to grips with qualitative changes (eg- the way television was at first treated as theater in front of a camera). The absurdity of this status should be painfully obvious- Image pages are currently an order of magnitude more common, and at this rate soon will be two orders of magnitude more common than article or category pages. Interestingly, the upper limit of pages in an encyclopedia is bounded, whereas it is virtually unbounded in the case of numbers of images on a particular subject. This has profound implications for documentation of these images.


If for no other reason that the shear weight of numbers, it should be painfully obvious that visitors coming to Commons via a link or (in the future) an internet search will in nearly all cases find themselves on an image page. Further, the high probability is that the Image page will have very little information regarding the subject of the image, and if there is any, it will be in english. Non english speakers will have no information about what they are looking at because such multilingual text about the subject of the image (if it even exists) will be an article or category page. Yet anyone unfamiliar with Commons will not be aware that further information might be available or how to find it via links to articles or understand how to use categories to navigate.


A few weeks ago, I asked about people's preferences about where navigational links to Wiki articles should be placed on an Image Page- in the sidebar or in the body of the page. Only one person gave a response, and another responded that no such information belongs on Image pages.


While it is everyone's ideal that all Commons' images have unique translated captions for all of its images, we have to question how practical it is to not provide any mechanisms for at least providing some background information on the subject of an image. To that end, I'd like to question what people's preferences are regarding inclusion of information related to the subject of an image rather than just the clerical details of the image (source, license and so on).


It is possible to translude information about a subject onto an image page. To this end, I have been working on an approach to make this simple. An example of the kind of information I am talking about may be found on Image:Uss iowa bb-61 pr.jpg. While this particular example uses an obsolete template, the information that the templates produce is the subject I am asking about. Some object to the concept of transclusion, not understanding that the concept was invented as a form of hypertext without the need for making a jump.


While it is true that custom captions are better than "generic" background information on a subject, is no information on the subject of an image better than some information? The scheme I have in mind allows background text for particular languages to be turned off when a custom caption is written for an image. It is intended as something to give assistance to visitors while fully translated captions are being produced.


If only custom captions are permissible, then how many years do folks honestly think it will be before the current 600K images have captions in all 20 major languages? And at that date how many more images will there be?

-Mak 21:30, 17 May 2006 (UTC)
I agree with half of what you say, and disagree with the rest. When I first came across the Category:Info Templates, I admit I cringed at what I considered to be too many templates, and I couldn't readily see a use for them. However, the point you have brough up is indeed a grave one, as the vast majority of our images lack necessary information. While I am not expressly opposed to the idea of using template transclusion to convey some facts about the subject of the image, I believe that if used, these templates would need to be categorized much the same way as the images themselves, in addition to being categorized as "Info templates" or something of the like.
However, I do believe that a better solution, especially in order to promote the Commons' function as an organized media repository, providing obvious links to articles and categories that relate to the image is more important. Such links should be stand-alone; not embedded in text of any language, and should take both an English form and the localized form (e.g. After the English and other language {{Information}} (or similar) templates, links to USS Iowa, Battleships of the United States, and similar links would appear). Following these links would lead users to a truly multilingual page.
I understand that it is hard to make such links multilingual, so let me reiterate, I am not expressly opposed to your template method. If indeed that does end up being used, however, they should be organized logically, in addition to being "dumped" into Category:Info Templates. I do agree with you that image description pages tend to be ignored relative to articles, and something must be done. The question is should we create templates for every single topic (basically every single article+category), or trust that users know to click on shiny blue text, even if it might not be, in all cases, fully translatable to their language. Originally, I favored the links, but for the sake of better internationalization, I would be inclined to get used to the templates. —UED77 22:40, 17 May 2006 (UTC)
The rewrite I am presently undertaking does not use the Template space. They don't need to pollute that namespace, and besides they are just containing data, so I am moving them to a pseudo namespace Info:. So former Template:Info-USS Iowa (BB-61) becomes Info:USS Iowa (BB-61).


As for how the format of how the data is actually presented, I don't really care that much. The current scheme separates the data from the presentation more, so for example with interwikis, they are not presented as [[en:USS Iowa (BB 61)]] but |en_article=USS Iowa (BB 61). This allows you to run a display method on the Info Page either to put it in the interwiki sidebar, or using some internationalized scheme as you were describing. To get any scheme to work, you need the data of what is the article in which language for which subject. Currently, we are not expressing that in a form so that you could write a multilingual see also as you describe.
The scheme I describe attempts to separate the data from the presentation. The former version made a lot of compromises with that, the current one is better, but I face many instances where I can make the data abstraction ideal, but the Info: Page is way way to intimidating for users. So there is a balance.
In any case, as I was saying, alternative displays can be used with the Info Pages. They are as you must have seen, just a list of parameters that can be passed to Any Template. Or you can selectively do a chinese menu approach using the templates to extract just the portion desired. This is why there are so many of them- I could certainly glom them all into one template, but then that returns us to the fragility/ opacity meta template issues. You can individually run a method like so: (old syntax example) {{Info-USS Iowa (BB-61)|Method=More-wiki articles}} displays Arnomane's sidebar wiki location, substitute More-text as the method, and you get just the text. New method scheme puts more formatting in the methods so that end users can mess with them. Template code in the display methods is typical of other templates. However the central execution template will continue to have complex logic which probably will not be of any interest to 99% of template editors anyway. I expect it will largely be treated as a black box with the two ends editable by end users- the Info: Pages data in the front end, and the Formatting methods on the back end.


The architecture is a new approach to Meta Templates- addressing the Fragility and Opacity issues that made former attempts problematic.


I continue to revise the approach and it is by no means finished. Any technical comments are welcome either here or on my talk page. -Mak 01:30, 18 May 2006 (UTC)


I still disagree that the entry point to the Commons for most people will be the image page. I believe most of our traffic is still Wikimedia-based. And most of the links to the Commons are to categories, articles or the main page.
Of course there are no available statistics about this so neither of us has any firm ground to argue from, which makes it rather pointless... pfctdayelise (translate?) 23:48, 17 May 2006 (UTC)
Even if that were true, if we believe in our destiny to be the definitive Media repository for high quality free media on the net, then we naturally would expect that the WPs will be a rapidly diminishing source of inbound traffic. It could happen the very day Google engineers read their email and figure out that urls on our site with Image: are text, regardless of the extension (.jpg) or whatever. -Mak 01:30, 18 May 2006 (UTC)
We already have a lot of extra information for many of the images on Commons, mostly related articles and sometimes even captions. That base of information is called Wikipedia. It makes no sense replicating the image use information that we have from there. There already exists the CheckUsage tool, which all Commons images link to now. Other entry points than Wikipedia pages are meaningless, since they provide no extra information, so a simple trackback link as often used in blogs wouldn't be useful. Since you would like to see static data and querying all the databases run-time isn't possible, I suggest you go to bugzilla and propose a framework for updating image links to Commons whenever a link is made from a Wikipedia page. Some people are doing this effort manually by adding interwiki links to image pages, articles and categories, but it is just a total waste of time since a one way link exists already. Now we just need to have the software make that link bidirectional. --Para 11:15, 18 May 2006 (UTC)
I am a little confused about your response. Info page used by Image:Uss iowa bb-61 pr.jpg and all other images of category USS Iowa (BB-61) do much more than simple cross linking. Info Pages also:
  • include a representative image on a category page
  • transclude text in multiple languages
  • provide a list of equivalent terms (Vernacular terms) in multiple languages (optional). See Category:Struthio camelus for an example.
  • provide See Also links to WP, Commons and External sites.
Regarding the Do/Don't use Interwiki sidebar conundrum. I really don't care where the cross links go and I suspect this may be fought over forever. Don't be thrown by the crosslinks appearing in the the sidebar as in the Iowa example. They easily can go in the body of the page, and the alternate option will resemble the Mona Lisa example described in an early thread above. I am not super happy with the format of that either, so the templates are written in such a way that very simple templates can be written to present the information in whatever format an editor desires. Interested parties may refer to the More-text example I gave to UED elsewhere in this thread.


In any case, even if cross linking to wikis was the sole function, how is it that a bidirectional cross link can be made if Wiki never makes the initial link? In many cases, there are dozens of images that could be used but aren't. Does that mean that someone browsing commons should not have the benefit of information about the wiki article on that subject? -Mak 20:04, 18 May 2006 (UTC)


This could all be done automatically, without forking yet another set of external links.
  • Representative image of a category: Take the first image of a category. Any image can be placed "first" by using a sort key.
Problems- implied not explicit semantics means that the convention will most frequently not be obeyed or understood. Commons is extremely explicit about Rights tags on the upload page. Take a look at the compliance rate. But ok, let's assume the miraculous occurs and you get decent compliance. Still, the scheme is implicit, and so will break with new image additions. -Mak
  • Text in multiple languages: Take the introductory paragraph from Wikipedia, using interwiki links to find the available languages.
Doesn't answer the already stated issue of multiple terms -Mak.
You are thinking of equivalent terms in same language. If you look at the ostrich example I gave, it is for multiple languages. However, I agree that if wiki articles exist in all languages, that this could be solved automatically. Eventually this will be the case. Currently, it is seldom the case.
  • See also: Take the "See also" or "External links" section from a Wikipedia article
Pearl Harbor Attack has 28 entries. You going to put them all in a see also box?. Sorry, a human has to be on deck to tell us which ones make the short list. Besides, See alsos also are to Wiki articles. Which of the countless links to other wiki articles will your algorithm choose? Algorithms don't have sufficient intelligence to replace subject matter experts. How does your algorithm know which ones are the best ones? -Mak
  • Images with no link from Wikipedia: Use the information from the "representative" image of the same category.
Not clear what is meant by this, but again, you are placing more weight on a scheme that will break easily. (Fragility issue due to implied, not explicit semantics) -Mak.
It would be possible to make a proof of concept of all this, as a dynamic Greasemonkey script for example. You would not be limited to sidebars. There is really no point in manually replicating existing information within the same project. --Para 11:17, 19 May 2006 (UTC)
Your proposal fails on all counts. You cannot replace human subject matter experts with algorithms. Algorithms cannot extract information reliably if semantics are not explicitly encoded, that is, unless you have come up with a breakthrough in AI software. People keep saying that the information is there. Sure it is there, it is readily apparent to humans. Info pages make these relationships explicit, and in a form that can be used by algorithms with high confidence because the rrelationships were explicitly declared by humans. -Mak 19:45, 19 May 2006 (UTC)


(edit conflict) As I have said before: more information about each image is always welcome. Copying or transcluding the same text to dozens of images is not helful to people or search engines - quite the contrary; Having the interwikis for "Foo" on all images in the "Foo" category is plain counter-productive and misleading.
I agree however that to people hitting on an image page as an "entry point" to commons, the "browse category" and "pages that use this image" stuff is obscure. Those two things could be combined into a nice "For more information see..." section - i.e. we would need a special image page specifically tailored for media-centric projects like the commons. Issues like internationalized keyword lists for search engines could be adressed in the same go. and I still dream of doing away with the distinction between galleries and categories...
So: a complex template system for transcluding the same info all over the place seems a very bad idea to me. Instead, we should think about and work on a technical solution that would put the information already available in the database to better use, for users and search engines, without any additional handy-work being required. -- Duesentrieb(?!) 11:17, 18 May 2006 (UTC)


"Copying or transcluding the same text to dozens of images is not helful to people or search engines " -Duesentrieb

Oh? Perhaps if transcluding "generic" information damages Image pages, we should ban use of Creator transclusion? Consider Image:Sommer, Giorgio (1834-1891) - Agrigento, Tempio della Concordia.jpg. If Info Pages are bad because they transclude the "same text", then is this page bad because it also transcludes? Info Pages are doing a much better job than Creator is in delivering useful information to users in this case, which is not atypical. If Creator Pages are allowable for transclusion, then why not Info Pages?


When is transcluding such so called "generic" text Transclusion was invented for this very purpose you disparage: "copying text everywhere", but with the beauty that it really is not a copy. Only one copy is kept, and when it is updated with an explanation line in another language, everyone benefits. It is a convention used in the print media- Inset boxes with factoids are commonplace.
It is secondly incorrect that the information is not useful to search engines. There are more words for the search engine to hit on. Therefore, the user doesn't have to know to search for "B-17", they can simply search for "Bomber" and "Hawaii" and get all the Hawaiian bomber photos. Consider the photo: Image:NARA 28-1277a.gif. Unlike the vast majority of Commons images, this has a decent caption. And we'd like all images to eventually have this kind of caption. But even this caption would benefit from english language background text, because for a search to be successful the user would have to know what a B-17 is. And most people don't. They use vague terms like bomber in search expressions. That term does not exist in the caption. Usually, such hyponyms occur in subject descriptions. And that is exactly what Info page Text lines are intended to do.


No one should be laboring under the misconception that we can simply put images on a category or article page with suitable multilingual descriptive text and get a hit on such typical searches that way. If pictures are worth a thousands words- they usually deal with more than one subject. And that in essense is the death of the "throw it on a categorized page" approach. Consider photos of politicians. The more interesting the picture, the more the subjects, the higher the value. This picture is just as much about the Pearl Harbor attack. When both Pearl Harbor Attack and B-17 bomber Info subjects are associated with this image, it is now possible for a user to search for hawaii bomber and get a hit on this image.
Note also that using this scheme, we can also search on pearl harbor 真珠湾 and bomber 爆撃機 and get a hit on this image. Or they could mention hawaii ハワイ instead.


Lastly, info pages, because they are very simple to use are simple for naive users to update. Already, french and chinese translations have been added to the BB Iowa Info page by users who were not prompted, not given any explanatory information how to use them. They simply clicked on the edit link- saw the familiar wiki text on languages and added their own. In that way, they saw their contribution impact several pages, not just one. It Keeps it Simple for the user, and that is what matters.


Is it true that Image pages are better off without Any of this information? If this is true, we have not heard why. -Mak 17:32, 18 May 2006 (UTC)
'Creator' tags are only used for a very small subset of images. You could not, for example, make a 'Creator' tag representing yourself. And they were intended for use specifically with the DirectMedia collaboration uploads -- not as a totally new method for image pages. Creator tags are concise, brief and not designed for Google hits -- nothing like your Info tags.
My comments on Creator were in response to the controversial statement: "transcluding the same text to dozens of images is not helful to people". I pointed out that it is regarded as being helpful to transclude some types of text but not others. I think most people feel it is helpful to provide additional subject matter information on an image, and this is reflected in the use of the Creator Tag. Info Pages are a continuation of this principle. Nothing you have said explains why transclusion is regarded as good in one case, but not in another. -Mak 19:45, 19 May 2006 (UTC)
You said No one should be laboring under the misconception that we can simply put images on a category or article page with suitable multilingual descriptive text and get a hit on such typical searches that way but I don't see why not, especially since we currently have ~0 hits anyway.
Have you actually even done the searches you claim are so impossible? bomber site:commons.wikimedia.org gives Category:Bomber aircraft as the second result. And guess what, Category:B-17 Flying Fortress is an extremely visible subcategory of that!
Doesn't it make more sense to offer a searcher a structured overview straight-up (ideally a gallery, but to a lesser extent a category) than give them dozens of unsorted unidentified images? I.E. prioritise gallery/category results over image-page results. Which is what we have been unconsciously doing to date.
(Please try and be more consise in your replies) --pfctdayelise (translate?) 08:19, 19 May 2006 (UTC)
Info pages address more than the theoretical problem of providing terms for internet search. Nonetheless, regarding your comments on that subject, you are seriously mistaken. The search was for Hawaii bomber in multiple languages using image search like Google's, Yahoo's, or MSN's. You searched for Bomber only using Commons search. Sure, hyponyms occaisionally will occur in captions, and Hawaii and Bomber terms happen to be on that particular gallery page.
  1. Do we expect everyone will search in english? Will users find the hit using non english languages? No.- Have you tried searching on commons for pearl harbor 真珠湾 and bomber 爆撃機 (That is, when commons search is not overloaded and suggests you try google search instead?)
  2. Will they find it using english? No- reason why is that both bomber and hawaii are not associated with the same image. See prior non concise explanation of that subject if interested. (search VP for "proximity").
  3. Even if there was a hit on a gallery page using Google image search, would the users find it? No- because gallery pages reference only a small image, and google search will rank that hit last. Most google users don't go beyond the first one or two pages of hits. Our page would be buried.
  4. Ok, let's assume even very narrow uses of google. Let's assume people know that commons is a great place for images and restrict their searches just to commons. Now, there is some multilingual capability- you will get a hit on Pearl harbor gallery if you type 真珠湾. You will also get a hit on 爆撃機 (bomber) for the B-17 gallery page. This case illustrates the following issues with multilingual search and problems with proposed solutions to interested parties:
    • If you search for both terms, there is no hit. If pictures are worth a thousand words, this approach supports only one word. (single subjects and term variants. Info page approach can associate multiple subjects with an image, as in the example image.)
    • These multilingual hits are generated from image titles in the interwiki links. Japanese is the only language that mentions the hyponym in the page title. For the others? if you don't use B-17, you other option is to ask for "flying fortress"
    • This cannot be relied on for multilingual support becasue it uses an extremely restricted vocabulary- it is about as useful as google would be if we could only get search hits on text that is in the title of an internet page.
I'm afraid the subject is a little more complex than you suspect. I do apologize for not being able to explain the subject in a more simplified manner, but it is very easy to misunderstand how searchers work. Your thoughts? -Mak 17:37, 19 May 2006 (UTC)
I just think you are trying to provide mind-reading capabilities for searches in every langauge
Hardly. I am just trying to provide terms that a search engine could use. By the way, these terms don't have to be visible to be used by search engines.

known to man and it's unnecessarily ambitious.

Not ambitious at all. Instead of tagging something Category:USS Iowa, a person tags it Show-Info|USS Iowa That's one more letter to type. Does that seem ambitious to you?

It is not usual that the exact thing you're after drops into your lap with any search. The search is only the first step in finding exactly what you're after - you have to use your brain to sort the wheat from the chaff. This is my experience. Therefore I would expect someone searching for 真珠湾 and 爆撃機, if that fails, to then search for just one of the terms.

I get it. People should just stop using more than one term on Google.

That would succeed. For many, many more general searches (if I'm doing an assignment on aircraft and I just want a picture of an aircraft... I don't care what it is, but I will choose one that looks flashy), then your "spammy" method will actually worsen their results. For this type of search a structure overview such as a category/gallery result is the best result.

Uh? Were you reading? Do you understand that a category/ gallery page will be ranked Last in any google image search? Hello? -24.161.144.164 03:03, 20 May 2006 (UTC)


I could probably abide the info tags if they much less intrusive.
All items can be turned off by parameter at the editor's discretion. If the community would rather have some items be default off, that is fine. I recognize some people will prefer them while others will not like some of the visual elements. It is flexible that way.


At the moment they are bulky and distracting from the specific information that is relevant to that particular image (including licensing info). It is hard to distinguish what is generic and what is specific.

Like I said, formating is customizable, and you don't have to accept the formating that one particular template writer chose. The Info Page just has information, mostly without any formating characteristics. There are hundreds of formats for distinguishing factoids and backround info from the body of print media articles. I agree that background info should be visually distict. There are many ways of doing this. I chose one, possible not the best. -24.161.144.164 03:03, 20 May 2006 (UTC)


I guess I am opposed to them because I see the image page as an endpoint in a search, not a starting point. I assume that to be searching for a picture of the Mona Lisa, the searcher must know what it is.

Because that is your style of search, should everyone else be bound by the limitations you impose on yourself? There is a very large class of users who use search to find things they only have vague understandings of. That is one of the great motivations for them to search. That is, to increase their knowlege about things they do not already know about. -Mak
Anyway more to the point I just realised something important. template:Info-Struthio camelus is actually going to make it harder to provide a multilingual interface in the future. Ideally we are likely to use the "hiding method" to hide captions (in the form {{en|caption}}) that the user doesn't understand. Since you are removing this information directly from the category and article pages, it won't work, I don't think. So this is especially a good reason not to do this... --pfctdayelise (translate?) 02:24, 20 May 2006 (UTC)
Wrong again. I use the templates en, fr, de etc and so the hiding will work properly. Perhaps the equivalent terms current implementation does not do that, I don't recall. In any case, this is all aligned with the hiding scheme.
Could you sum up why you think Transclusion is a bad thing for image pages? Please make it clear to us why Creator transclusion is good, but Info Page transclusion is bad. -24.161.144.164 03:03, 20 May 2006 (UTC)

My last point; I never said Creator transclusion was good. I am not very fond of it actually, but since it has a limited scope it has limited impact (thus I can ignore it).

It is impossible to reason with you.

It's quite simple. Just use an argument that is based in fact and logic. If your argument has been shattered in the face of facts, it is time to change your position, not assault the person who has presented you with the argument. I have been wrong countless times in the past. Maybe this is one. We help each other by showing each other where we have erred. It's not about winning or losing. We both win when we get closer to the truth. If I have erred in any of the facts I have presented you regarding proximity, behavior of image search on pages like gallery and category pages, and how that undermines your concept about how image search works, then show me where I have erred. -24.161.144.164 05:07, 20 May 2006 (UTC)

You obviously won't accept that any opinion other than your own is valid.

That's not fair. Dbenbenn presented me arguments about problems with fragility and opacity my earliest attempts at Info Templates and I very much was convinced he was correct. Other points I was not convinced of but I saw a way to accomodate his point of view. DennisS and I have strong differences of opinions on use of Categories, but I am now relying much more heavily on See alsos instead of categories to accomodate his point of view. Duesentrieb felt I should not use the Template namespace and I should use #if parser functions, and presented reasons for those items. So I am making those changes.


I have tried several times because I think your scheme will not improve the Commons - that is my only motivation in continuing your exhausting arguments - but I am giving up again because it's a frustrating and obviously pointless exercise. You have the words of a dozen people but it is only one person who is defending your stance; you. pfctdayelise (translate?) 03:38, 20 May 2006 (UTC)

I appreciate you taking the time to respond. If you think that Info pages don't improve pages you edit, then by golly, don't use them. No one is forcing you to use templates de, information, parser functions or the tag Creator either. I happen to think they are useful and so I use them. I am sorry that you have chosen not to respond to my arguments though. Really, I do think you are mistaken and should think about some of the facts I presented. -Mak 05:10, 20 May 2006 (UTC)

Mak. Stop using your template or I will make a roll back on all of these edits using that templates. I don't make fun with that. People including have talked to you in previous a lot and with a lot of patience why it just makes no sense. EOD. Arnomane 10:30, 20 May 2006 (UTC)

Really? On the contrary, very little patience has been shown on this subject. We have seen drive by pronouncements, and when I take time to show why the pronouncement is mistaken, no one wishes to defend their position. After two days of consideration of this important subject, you are ready to proclaim yourself judge and executioner.


You seem convinced that Image pages are better off without any of this information. Is that so? And yet, you yourself instructed me that I should copy transwiki information to an image page. So isn't it true that you are only opposed to part of what the templates do?


It would be simple to accomodate your request not to use templates. It would be trivial to write a bot to eradicate the info template use and instead copy the transwikis links to each image page. Presumably since that follows your guidance, you would be happy. Is that correct? -Mak 00:55, 21 May 2006 (UTC)

This wiki is a bloody mess- and I mean this in a bad way

I am new here, I certainly grant you that. But everywhere I go, I can only see caos: We have here way too much categories which many times differ from each other only in useless tecnicalities. In fact they compete with each other and only add to the confusion. Keep it simple for Chris´sake !, any subject that has more than 4 ! layers of subcategories is probably being handled in unefficient manner. Create new subcategories only when they are really needed. Link the categories to each other! Flamarande 22:29, 17 May 2006 (UTC)

Welcome to the pits of hell! Here's your showel... -- Duesentrieb(?!) 22:34, 17 May 2006 (UTC)
If Dante were alive, he would describe the Inferno of several control-freaks as "they are organizing things in Wikicommons". Flamarande 22:38, 17 May 2006 (UTC)
You need to understand our situation, Flamarande — "and I mean this in a bad way" :) Seriously, though, us "control freaks" who in your edition of the Inferno are in the lowest circles of hell, are some of our most valuable users. You see, we need more "control freaks", as it's the other twenty-or-so-thousand users who leave baskets full of pictures at the Commons' doorstep in the morning are the ones responsible for this. If everyone actually categorized pictures, and actually looked a bit around before doing so to know how they should be categorized, we wouldn't have such a chaos on our hands. Unfortunately, though, that is not the case — just look at how many copyvios get uploaded each day even though you can't possibly upload pictures without being told to read the Commons:First steps! You can't even create an account anymore without being told to read it before you do so. But people don't follow directions, so the Commons remains in a chaotic state. We are all aware that it's disorganized, so why don't you help us clean it up? I maintain the ones you are addressing this to are not in the lowest circles of hell, although the cold air might be nice to cool us off after the work we do :) —UED77 22:54, 17 May 2006 (UTC)

Frankly, I agree with Flamarande. I have never been a fan of categories, and the way commons has used them as a primary method of organization is, honestly, a disaster. Pity the poor soul who actually has to navigate around the category system here. Raul654 22:58, 17 May 2006 (UTC)

Really? What exactly is so problematic about navigating categories? Jkelly 03:49, 18 May 2006 (UTC)
The problem is that there are simply too many of them, which many times differ only in small tecnicalities and compete with each other. Many times there are simply too much "layers of subs" when they are not really needed. Flamarande 15:23, 18 May 2006 (UTC)

Thanks for all the criticism, folks. Now does anyone have a better solution? That is simple and easy enough that we can enforce it widely? We're waiting... pfctdayelise (translate?) 23:35, 17 May 2006 (UTC)

Suggestion: A recursive "see all content from this category onward" option?

Although I suppose I'm pro-categories, I recognise Flamarande and Raul654's point. Sometimes here and also on Wikipedia I wish I could just click a button and have all items/articles in a category and its subcategories (and its subcategories, etc) displayed all on one page, even if it might take a while to load. I realise the category system isn't strictly hierarchical, so I guess some coding to prevent infinite looping would be required. I think it'd then be easier to justify categorising smaller groups of similar items, as those folk frustrated by what they see as over-categorisation could then override it.

Hope that made sense. If so, what do people think – and, more importantly, could/would it ever be implemented?  Regards, David Kernow 00:32, 18 May 2006 (UTC)


I hate the yellow pages. Stereos listed under "High fidelity equipment" etc. Sheesh. Here, all you have to do to find what you want is navigate the tree structure to Audio output devices of the 1990's manufactured in Aichi prefecture. Hmmmm. I hate Commons. When do I get the direct cerebral cortex implants so I can just jack in to Commons, think of an image of what I want, and it pulls up similar images for me. Ok. Maybe I'll stick with the yellow pages approach. -Mak 01:55, 18 May 2006 (UTC)

Mmmm, I love the smell of sarcasm in the morning. Seriously, just because I cannot resist the urge to go by your example, enter "electronics" into the search box, get presented with Category:Electronics, click on Category:Electrical devices. Alternatively, navigate to Category:Audio, then to Category:Hi-Fi equipment. Or simply enter "Hi-fi" into the search box. While it is sometimes a challenge to find images of a very narrow topic in Commons, if one has a little patience browsing through categories, it's not nearly as bad. Sure, we could use a better search; we could use a lot of things. However, complaining about things we already know helps nothing. Be bold. —UED77 02:47, 18 May 2006 (UTC)


CRITICISM OF TECHNICAL LIMITATIONS THAT WE HAVE NO CONTROL OVER IS NOT HELPFUL. BUG THE DEVELOPERS OR CODE IT YOURSELF. >:|

  • bugzilla:3834 'Number of articles in subcategories known and showed on category page?'
  • bugzilla:2725 'View list of articles in subcategories all on one page' (David Kernow's idea, where articles = images/media files)
  • Only eight – well, now nine – votes for this... sigh... David Kernow 11:26, 18 May 2006 (UTC)

--pfctdayelise (translate?) 04:53, 18 May 2006 (UTC)

I've always favored just imitating the wikipedias' category and article structure as much as possible. That way you can let those folks argue it out, and not have to redo all the arguments all over again here. Plus which if somebody starts whining about how bad it is here, you can just forward them to the WP in their favored language, lets us get back to more important tasks. Stan Shebs 03:33, 19 May 2006 (UTC)

The issue with that, is that you're probably referring to the English wikipedia's category structure. I don't believe that french, german AND polish all have the same type of structure as english. And we have to accomodate everyone. Cary "Bastique" Bass parler voir 05:09, 19 May 2006 (UTC)

May 18, 2006

placement of copyright

I apologize for asking yet another stupid newbie question. (sigh). Does it matter where I place the copyright info on a page? Since the thfo box was started, I've been placing the copyright info (in this case pd-self or pd-user) in the info box, but then when I look at the gallery, I see it flagged in red as not having a license tag. When I add the {{pd-self}} template at the end of the page, the red flag goes away, but it seems somewhat redundant. Any comments? --Bachrach44 02:42, 18 May 2006 (UTC)

It's not a newbie question; early questions prevent later work :)
Customarily, the license tag (license template) is placed after the {{Information}} tag. The "Permission" field of the Information template was meant for textual quotes (or weblinks), such as "Works by John Doe are released under CC-By-2.5", or "I release my works under the GFDL". Regardless of the content of the Permission parameter, a license tag is required, and since Duesentrieb's tools apparently do not check for the tag if it's inside the Information template, you are better off with putting it outside of it. For a good example (shameless plug :P ) see my Image:Cape Cove, Oregon.jpg. —UED77 02:56, 18 May 2006 (UTC)
Try explaining that to the commonist-0.1.13 running loss on my computer ;-) --Tarawneh 03:17, 18 May 2006 (UTC)


Hi. Maybe the restriction about Duesentrieb's tools must be explained in Template_talk:Information. The first I did when I started using the template was put the cc-by-sa tag into the Permission field.
In Commons:First_steps/Quality_and_description reccomends to copy the code into Summary field without mention the template. There seems to be clear to put a text into the Permission field and the tag outside. While I wonder if there is not redundant information because template tags tells a lot of information in several languages... so maybe this field was unnecesary.
I also miss references to Commons:Multilinguality in first steps and even in referred template documentation.
Honestly when I upload my first files many time ago I've copied from others. I believe that then was an older help in Spanish (I'm not sure). I changed the info in my files as I watch different ways by others or some helpful user correct mines. But recently I try to explain it to new users and I think that we must navigate across many pages if we want to have a "perfect" content in the image (video, audio...).
Of course this is not a compliant. I know there is people working on it. It's just a little feedback. Regards, --Colegota 09:52, 19 May 2006 (UTC)

Translation of an article into many languages; prioritizing a translation

What would I want to do to get a particular article seen by other Wikipedias, if it were something that were, for example, a medical article containing information that was not widely known abroad, but was of significant importantance?

How would I suggest an article, eg::-- Sammy_Do_Not_Touch_Yourself_There to be reviewed for translation based on it being something important in Switzerland, Germany, and Israel?

Thanks! ——Preceding unsigned comment added by 71.140.139.97 (talk • contribs) 05:56, 18 May 2006 (UTC)

Is meta:Translation of the week what you are looking for? --::Slomox:: >< 10:46, 19 May 2006 (UTC)

Template:PD-user-w and Template:PD-user-wikimedia

Two tags for the same think. PD-user-w is like GFDL-user-w, PD-user-wikimedia is easier.

Which do you prefer? Sanbec ✉ 11:50, 18 May 2006 (UTC)

They are different. PD-user-wikimedia assumes the project is Wikipedia (bizarrely, given the name - it should be PD-user-wikipedia!). PD-user-w you have to fill in the project (could be wikinews, wiktionary etc). I vote depreciate PD-user-wikimedia. pfctdayelise (translate?) 03:06, 19 May 2006 (UTC)
No, PD-user-wikimedia has a parameter to fill in the project code, as well as PD-user-w. The difference is only the project name. I prefer PD-user-w too. Sanbec ✉ 14:24, 24 May 2006 (UTC)

Function : Download a Categorie

Some categories became really big, can we have a funtion "Download All" [the files of this category]. This can be usefull for webmaster who want all the pic about one subject. Yug (talk) 16:57, 18 May 2006 (UTC)

I don't think that's done so often really, so you probably won't see anyone doing scrip