Commons:Village pump/Proposals/Archive/2012/05

Clear author indication

Hi all,

Following up on my proposal of last month (cf. Commons:Village pump/Proposals/Archive/2012/03), I see two possibilites:

• We enforce having clean Author fields. Fancy templates are moved to, say, the permission field ; precisions (date, source, etc) go to the relevant fields.
• We devise a way to clearly label the author name in the fancy templates (through some special template which would set some special HTML classes).

I think 1° is always nice to have anyway. 2° might be a better choice, as I recall the {{Artwork}} have author and source lumped together.

Thoughts?

Jean-Fred (talk) 16:33, 8 April 2012 (UTC)

I've recently been working with images of aquatint engravings from the early 1800s.

In that context: who is the author that you are interested in? Is it the artist of the adapted watercolour or drawing? The engraver, who made the adaptation? The person who made a scan of the print, and uploaded it to their company website? Or myself for removing their watermark, or cleaning up and editing a scanned book page from the Internet Archive?

I have been trying to follow what I understand as current recommended practice, namely: a {{Creator}} template and {{After}}{{Creator}} templates in the Author field for the engraver and the original artist, respectively (or in the Artist field if using {{Artwork}}); and a note of the website in the Source field, with links to the most relevant page on the website and the image url.

I would suggest that a {{Creator}} template is in fact more machine-readable than plain text -- particularly if it links to a VIAF or LCCN identifier for the individual. So in my view that template should actually be encouraged wherever appropriate, not discouraged. Jheald (talk) 15:30, 27 April 2012 (UTC)

•  Support discouraging fancy templates in the author-field. But I don't want to dig through 12000000 files. Uploader should be notified (or even scared/alerted: Re-users may have problems to properly attribute your files) if they attempt to do so with an autotranslated message. This could be even done by a bot, that is watching the new files- one by each user, looking at the author-field (wikitext); if it contains lots of HTML, notify the uploader, if it contains a template and the HTML-rendering-author-field contains a lot of stuff, also notify the uploader. -- RE rillke questions? 22:27, 2 May 2012 (UTC)

Make search default to searching category namespace

A very simple stopgap before Bugzilla:35701 is addressed one day: make search default to searching category namespace instead of file namespace. (It's a "stopgap" because each category result can be considered a simple cluster, but this isn't as good as proper clustered search would be.) This means, for instance:

• towel: this instead of this
• toothbrush: this instead of this

Reasoning: search as a way to find useful categories is a better way of meeting users' needs than trying to find files directly, since this depends on filenames and descriptions which are often flawed, and the search engine not very good. Category names get more attention. Currently we have "search in categories" a clickable option; this should be reversed, so that "search in categories" is the default, and "search in files" is the "powersearch" if you like. A default gadget should be able to do this, and this would allow users to revert back to the current situation, by turning off the gadget. Rd232 (talk) 11:29, 22 April 2012 (UTC)

•  Support - this makes perfect sense to me as a stopgap measure until Bugzilla:35701 is addressed. There's far too much weight put on textual searches of filenames here, with unwanted consequences which can make the search function less useful - Alison ^❤ 11:53, 22 April 2012 (UTC)

•  Support Good idea!--Funfood ␌ 11:59, 22 April 2012 (UTC)

•  Support Awesome idea! That's been annoying me for a while. --Terfili (talk) 12:41, 22 April 2012 (UTC)

•  Oppose An image search should at least offer some images as results.
  It might be better to find a way to stop search redirecting to galleries. --  Docu  at 12:57, 22 April 2012 (UTC)

• • Nowhere is the default search defined as "image search": it's simply "search". The question is really, what is most useful to the average user, and should therefore be the default option, as opposed to an option that takes an extra click. I think to the average user, category search will give 20 fairly useful categories to browse, whilst file search gives 20 fairly random images without even giving the categories they're in (to allow quick browsing of related images). NB I say "20" because we know that for most searches the user only looks at the first page of results. Rd232 (talk) 13:14, 22 April 2012 (UTC)
    • You might not have noticed, but Commons is a media repository consisting primarily of images, not some soapbox. --  Docu  at 13:16, 22 April 2012 (UTC)
      • You might not have noticed, but my comment does actually explain that the aim of helping users find useful images is not necessarily best served by giving them "file" search as the default. Rd232 (talk) 13:19, 22 April 2012 (UTC)
        • Because default namespace for Commons search results is file namespace? --  Docu  at 13:39, 22 April 2012 (UTC)
•  Oppose per Docu - results with only categories make the image search quite useless. /Pieter Kuiper (talk) 14:33, 22 April 2012 (UTC)
  • I'm not suggesting that when you tick the "file" box in the search, you only get categories. I'm suggesting by default when you go to "search", the "category" box is ticked instead of the "file" box, because 20 relevant categories to browse is better than 20 fairly random images. Do you understand this? Rd232 (talk) 15:04, 22 April 2012 (UTC)
    • Your examples only gave categories, the last hit on "toothbrush" was category:Adolf Hitler. Categories are already reasonably prominent in search results as it is now. /Pieter Kuiper (talk) 16:57, 22 April 2012 (UTC)
      • Your example only gave categories - yes, that was the point! Send the user to browse useful categories, instead of picking fairly randomly a selection of 20 vaguely related images. the last hit on "toothbrush" was category:Adolf Hitler - because it's in Category:Toothbrush moustaches. There are loads more toothbrush moustache images in the File search. Rd232 (talk) 20:40, 22 April 2012 (UTC)

•  Neutral: this inspires me the following idea : how about requesting the devs to add the thumbnail of the first picture in each category next to each category name in the search result page ? Teofilo (talk) 15:01, 22 April 2012 (UTC)
  • Sure, good idea. But anything that involves the devs may take a long or very long time; the advantage of this proposal is that we can do it (I think). Rd232 (talk) 15:04, 22 April 2012 (UTC)
    • Case in point: a very similar idea to my proposal, Bugzilla:31028 (Proposal that basic search should include category search) exists since October 2011, even though it must be very, very easy to do. Rd232 (talk) 15:07, 22 April 2012 (UTC)
    • Bugzilla:36159 - For category search results, provide an image preview. Rd232 (talk) 15:12, 22 April 2012 (UTC)
      • Bugzilla:31028 can be done here with a {{#ifexist or something, can it not ? Instead of the first picture in the category, perhaps the most used picture (the number of uses on wikimedia projects) in the category would be better. Regardless what we do concerning categories, I think a search sort option with "most used picture top" would be good. This would be a feature which would be somewhat unique to Commons (as compared to Getty Images or Flickr), and provide something closer to the "relevance" algorithms used by Google image search. I don't know if it is really useful, but "newest top" would also provide a sense that Commons is enriched every day with newer pictures (Flickr has this). "largest size top" etc... Teofilo (talk) 15:30, 22 April 2012 (UTC)
•  Neutral The default search already looks for both categories and files, like this. I think that is preferable. I'm sure you'd be able to come up with searches where file results are far more preferable to category searches; I don't think we should search for only one or the other by default. Lots of images have more specific descriptions than there are categories. Also, searching on an exact filename won't work if it is a category-only search, which seems like a silly result. Carl Lindberg (talk) 16:16, 22 April 2012 (UTC)
  • I'm sure you'd be able to come up with searches where file results are far more preferable to category searches - and for those searches, file namespace search would be just a click away (as category namespace search is now). In the default search settings (which are actually gallery+file+category+help+creator+institution) categories are not given enough priority to be an effective stopgap for clustered search, which is the starting point of this proposal. Rd232 (talk) 20:36, 22 April 2012 (UTC)
  • searching on an exact filename won't work if it is a category-only search - not true. Put File:Example.jpg in the search box and it will take you straight there; put it in Special:Search with only the "category" box ticked, and it will give the same results as if "file" were ticked. Rd232 (talk) 20:36, 22 April 2012 (UTC)
•  Oppose until most categories have multilingual descriptions. I see the primary objection is that the category names are in English, and most categories do not have multilingual descriptions (or any description for that matter). This is meant to be a multi-lingual project, this suggestion sounds as though it will produce less useful results when searching in a language other than English, thereby making the project less friendly to non English speakers (and it is quite bad enough as is :-). At the moment searching in other languages has a good chance of finding a relevant file on the first results page, clicking on the file will reveal the categories it is stored in. You can look at the results returned by search as a graphical index into the category system. --Tony Wills (talk) 21:12, 22 April 2012 (UTC)
  • I considered that. I thought (i) doing this would encourage use of the sum-it-up gadget (maybe even provoke the creation of a bot to do the same) and (ii) most files only have English descriptions anyway (plus 1 language if you're lucky), and sum-it-up will cover lots more cases and languages than realistic for file-by-file translation and (iii) if that doesn't convince, the gadget could just be limited to users with English interface language. Rd232 (talk) 07:08, 23 April 2012 (UTC)
  • clicking on the file will reveal the categories it is stored in. - what proportion of end users do you think know to do that? Clicking on a file you don't really want in order to find categories at the bottom of the page which present files you might want is not an intuitive process. (It's easy enough when you know, but it's absolutely not intuitive.) By contrast, clicking on category results to find files you might want is totally obvious and intuitive. Rd232 (talk) 07:53, 23 April 2012 (UTC)

The user can set that in his search preferences. — Preceding unsigned comment added by Foroa (talk • contribs) 2012-04-23T09:12:55 (UTC)

•  Comment: I find the search links presented in the nomination misleading. "Towel: this instead of this"? The second link is not what you currently get when you type "towel" in the search box. The actual search results include Category:Towels as the first result. Jafeluv (talk) 12:41, 2 May 2012 (UTC)

Commons:Worst images gallery

The Commons' unofficial worst image contest, with several nominations. I propose to display one or two images of vomiting quality for each nomination. Also, feel free to add new nominations to this hall of shame. But do not upload bad images, please, look for images already uploaded. Incnis Mrsi (talk) 14:59, 23 May 2012 (UTC)

There are many reasons why such a "contest" is not a good idea. -- RE rillke questions? 15:15, 23 May 2012 (UTC)

So which reasons? Why not to show the bottom of vice on one page? Incnis Mrsi (talk) 15:51, 23 May 2012 (UTC)

If you manage to show how to do it better, maybe go but otherwise it's en:Pillory, if you understand German, I recommend de:Pranger which is more illustrative. -- RE rillke questions? 16:37, 23 May 2012 (UTC)

Really, why create this? For the record though, I propose adding File:Anal2.jpg and the other similar ones. -mattbuck (Talk) 15:19, 23 May 2012 (UTC)

May be you misunderstood my intention. Not hideous content (which might cause a lot of flame due to cultural incompatibilities), but appalling quality. Idiotic photos, moronic graphic tools, imbecile's image formats and conversions, and exceptionally low skills. Incnis Mrsi (talk) 15:51, 23 May 2012 (UTC)

You can’t make a category of deleted images uploaded by mostly blocked users. --AVRS (talk) 12:29, 24 May 2012 (UTC)

Sounds to me like stalking of the authors.--Ymblanter (talk) 16:36, 23 May 2012 (UTC)

Commons:Deletion requests/Commons:Worst images. Rd232 (talk) 12:59, 24 May 2012 (UTC)