Commons:Village pump/Proposals

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓

This project page in other languages: English | +/− Shortcuts: COM:VPP COM:VPPROP COM:VPR Welcome to the Village pump proposals section This Wikimedia Commons page is used for making proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Commons:Village pump, which handles community-wide discussion of all kinds. Discussions here should be of wide interest; those which are more specific may be moved to the main Village Pump, with a note left here. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. For old discussions, see the Archive. Recent sections with no replies for 14 days may be archived.   Start a new discussion

Centralized discussion
Proposals	Discussions	Recurring proposals
Request for comments on handling offsite discussions (19 April 2012(2012-04-19)) Commons:WikiProject Public Domain has been created to organise and review PD files (10 March 2012(2012-03-10)) Request for comments on making Commons:Grandfathered old files an official Wikimedia Commons guideline. (4 March 2012(2012-03-04)) Request for comments about how to reduce the need for Commons and other Wikimedia projects to comply with US copyright laws. (1 March 2012(2012-03-01)) Request for comments about how to improve Commons' Search. (28 February 2012(2012-02-28)) Request for Comments on the OTRS system. (9 January 2012(2012-01-09)) Please help by translating these messages into other languages. Note: inactive discussions, closed or not, should be archived.
Archive  • Discussion • Edit • Page history • Watch

Open search results and suggestions in new tabs

User:Rd232 has developed some JavaScript that opens search results and suggestions in new tabs. It works on both the Commons and Wikipedia. See:

• MediaWiki talk:Search-results-new-tab.js

Could a gadget for this be put in preferences? --Timeshifter (talk) 03:15, 6 April 2012 (UTC)

 Support I wouldn't have thought of this idea, but based on Timeshifter's suggestion I managed to adapt this script from Wikia. And I've got used to this now - it's quite handy. Rd232 (talk) 08:14, 6 April 2012 (UTC)

Comment. I have proposed this in other places such as Bugzilla also. See MediaWiki talk:Search-results-new-tab.js and the links to other discussions. --Timeshifter (talk) 18:46, 15 April 2012 (UTC)

It sounds OK to me to have this in preferences. Teofilo (talk) 15:33, 16 April 2012 (UTC)

Advanced search link in sidebar

Putting an "advanced search" (Special:search) link in the sidebar would fix the problem too. People could right-click it to open it in a new tab. Most readers do not know much about how to find stuff on the Commons. They try the search form at the top, but soon see that it covers up the page they are looking at. Many people stop using the search form after that, and use Google Toolbar instead for site searches.

But Google Toolbar does not allow one to pick and choose namespaces to search. Special:search does do this. Also, Google no longer makes Google Toolbar for Firefox. So, putting an "advanced search" link in the sidebar would solve many problems. --Timeshifter (talk) 14:53, 29 April 2012 (UTC)

Search link to drop-down menu at top

The search link could go in the drop-down menu at the top. That may be the simplest way to get searches done in a new tab. Also, that way it would not take any valuable real estate in the sidebar or at the top. --Timeshifter (talk) 14:53, 29 April 2012 (UTC)

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)

Commons:Village_pump#New_User_Right_Proposal:_Large_Uploads

I've added a proposal for a new user right. Thoughts and comments would be appreciated! -FASTILY ^(TALK) 06:21, 15 April 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)

Improved category browsing

Improve category browsing by enabling as default gadgets

1. User:Rillke/galleryZoomHover.js - gives a popup preview of the image when you hover over it (try it with mw.loader.using(['mediawiki.util', 'mediawiki.api'], function() { importScript('User:Rillke/galleryZoomHover.js'); }); in your Special:Mypage/commons.js)
2. Long Image Names in Categories - on category pages, gives the full filename of images instead of chopping off the name after 20 letters (Special:Preferences#mw-prefsection-gadgets, "interface: files and categories")

Rd232 (talk) 13:09, 22 April 2012 (UTC)

How about adding a gadget that loads the next files on-demand when scrolling down, if the category consists of more than 200 files? (Like done in VisualFileChange) (Personally, I think MediaWiki should not send out 200 files initially but use some LOD-technique, proposed this on bugzilla:35618) -- RE rillke questions? 17:50, 22 April 2012 (UTC)