Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Commons

< Community Wishlist Survey 2016
(Redirected from 2016 Community Wishlist Survey/Categories/Commons)
Commons
21 proposals, 179 contributors, 344 support votes


Citations  •  Editing


Backup of Commons files

  • Problem: Because of various software bugs, misconfiguration or software interactions sometimes various files are lost from Wikimedia Commons. Sometimes they are restored later, but generally after a long, unpredictable period of time. In many cases they are never restored. Sometimes the files seem to be permanently lost or just nobody knows how they can be restored. In many cases it is not easy to reupload them from other sources as the files were modified/created just for use in other Wikimedia wikis and are not stored elsewhere.
  • Who would benefit: Wikimedia Commons (and other wikis) users who use the files. They will find Wikimedia Commons as more reliable file storage.
  • Proposed solution: Create a continuous backup of all uploaded files that would allow file restoring by devs in a predictable period of time (few days? a week?) on community requests.

Community discussion

Makes sense to do, but is it feasible to create (bi-monthly?) dumps of all uploaded files on Commons wiki? -FASTILY 00:56, 27 November 2016 (UTC)[reply]

There's no backup process already? I would like to see an official from Commons confirm this. Or, are there no mechanisms to retrieve files from existing backups? Stevie is the man! Talk • Work 19:01, 29 November 2016 (UTC)[reply]

There is https://archive.org/details/wikimediacommons , it's easy to help. If you have bytes to contribute, but no time: w:User:Emijrp/Wikipedia_Archive#Help_seed_the_garden_of_knowledge. Nemo 09:28, 5 December 2016 (UTC)[reply]

Voting – Backup of Commons files

  1.   Support. Scary thing, the current state of affairs, actually. --Base (talk) 18:16, 28 November 2016 (UTC)[reply]
  2.   Support, isn't this getting done already? If not it's irresponsible to do anything (including even hosting a wishlist survey) before something as fundamental as frequent backups are getting done. --Fixuture (talk) 21:26, 29 November 2016 (UTC)[reply]
  3.   Support per Fixuture --Hasenläufer (talk) 16:38, 6 December 2016 (UTC)[reply]
  4.   Support Strong support, a backup copy is necessary --β16 - (talk) 15:26, 1 December 2016 (UTC)[reply]
  5.   Support --Gestumblindi (talk) 21:26, 1 December 2016 (UTC)[reply]
  6.   Support Ankry (talk) 23:24, 1 December 2016 (UTC)[reply]
  7.   Support Libcub (talk) 02:23, 2 December 2016 (UTC)[reply]
  8.   Neutral Given the feasibility of generating and hosting/distributing this sort of database dump. For the record, there is roughly 100TB of media hosted on Commons. -FASTILY 07:08, 2 December 2016 (UTC)[reply]
    @Fastily: Really? Just 100TB? That's nothing. The cost of required storage capacity would be very low and distributing it isn't necessary - I'd totally support it though - but could be done via torrents. --Fixuture (talk) 16:59, 6 December 2016 (UTC)[reply]
  9.   Support Data is the treasure, we can't lose them.--Nachosan (talk) 00:28, 4 December 2016 (UTC)[reply]
  10.   Support --Ranjithsiji (talk) 05:47, 4 December 2016 (UTC)[reply]
  11.   Support--Molgreen (talk) 06:05, 4 December 2016 (UTC)[reply]
  12.   Support: Useful. Best regards, Kertraon (talk) 11:27, 4 December 2016 (UTC)[reply]
  13.   Support--Praveen:talk 12:59, 5 December 2016 (UTC)[reply]
  14.   Support but I see this as something not restricted to Commons. I think that every project should have protections against data loss. --Tryptofish (talk) 22:23, 5 December 2016 (UTC)[reply]
  15.   Support Lbertolotti (talk) 00:44, 6 December 2016 (UTC)[reply]
  16.   Strong support Highest priority of all proposals. Yikes! --Hedwig in Washington (talk) 03:41, 6 December 2016 (UTC)[reply]
  17.   Support any necessary improvements here. If backups aren't being currently done, that's awful. Stevie is the man! Talk • Work 13:45, 6 December 2016 (UTC)[reply]
  18.   Support --Kiril Simeonovski (talk) 09:35, 7 December 2016 (UTC)[reply]
  19.   Support - DPdH (talk) 19:42, 7 December 2016 (UTC)[reply]
  20.   Support, to keep images from being deleted by glitches. ----DanTD (talk) 20:55, 7 December 2016 (UTC)[reply]
  21.   Strong support If we're losing files on a semi-regular basis and aren't backing them up to account for this, something terribly wrong is going on. TheCatalyst31 (talk) 03:19, 8 December 2016 (UTC)[reply]
  22.   Strong support like some others, I was not aware of these issues, which seems like an obvious one to make high priority — Rhododendrites talk \\ 06:30, 8 December 2016 (UTC)[reply]
  23.   Strong support Please! These files which are permanently lost is true. When an admin merges a file with another one, sometimes one of the file revisions are permanently lost. Very scary. --Pokéfan95 (talk) 11:44, 8 December 2016 (UTC)[reply]
  24.   Strong support I though that after so many years we had reliable backups for the Commons media. If not, it is a must. Barcex (talk) 19:38, 8 December 2016 (UTC)[reply]
  25.   Support Miniapolis 21:27, 8 December 2016 (UTC)[reply]
  26.   Support --OrsolyaVirág (talk) 12:47, 10 December 2016 (UTC)[reply]
  27.   Support --Cavarrone (talk) 10:07, 11 December 2016 (UTC)[reply]
  28.   Support --Plagiat (talk) 17:17, 11 December 2016 (UTC)[reply]
  29.   Support --Soluvo (talk) 00:28, 12 December 2016 (UTC)[reply]

Category browsing without multimedia viewer

  • Problem: Editing all the images in a category is cumbersome. One has either to open each image in a new tab (which does not work on low-end computers) or to go back to the category each and every time and open a new image.
  • Who would benefit: Commons editors
  • Proposed solution: Have a browsing interface much like the MultimediaViewer, but in the description page. For instance, if you visit File:A from Category:B, the url might look like: /wiki/File:A?cat=B and you would have arrows near the image thumb allowing to move forward/backward in the category. Similar concept: albums in Flickr.--Strainu (talk) 06:37, 16 November 2016 (UTC)[reply]
  • More comments: The idea can be generalized to any image source, such as wikitext page or special page, but that raises all kind of complicated issues (you might not want images in navigation templates for instance).
  • Phabricator tickets: none yet, just gauging support

Community discussion

Voting – Category browsing without multimedia viewer

  1.   Support Léna (talk) 11:10, 28 November 2016 (UTC)[reply]
  2.   Neutral GallerySlideshow already seems to do much of this. Perhaps the development team behind that should look at any needed improvements rather than the WMF team. Given all the current features in this tool, I would say this proposal is too low of a priority for WMF. Stevie is the man! Talk • Work 19:17, 29 November 2016 (UTC)[reply]
  3.   Oppose, already possible with the media viewer?! Clicking "category slideshow" shows the images of a category in a slideshow with the shown image being linked on the left. --Fixuture (talk) 21:31, 29 November 2016 (UTC)[reply]
  4.   Support as proposer--Strainu (talk) 09:25, 30 November 2016 (UTC)[reply]
  5.   Support --Mess (talk) 19:09, 30 November 2016 (UTC)[reply]
  6.   Support--Ranjithsiji (talk) 05:47, 4 December 2016 (UTC)[reply]
  7.   Oppose We already have tools for that. No need to reinvent the wheel. --Hedwig in Washington (talk) 03:42, 6 December 2016 (UTC)[reply]
  8.   Support --Kiril Simeonovski (talk) 09:37, 7 December 2016 (UTC)[reply]
  9.   Support for forward/backward arrows at the file description page (like in albums in Flickr). Only show up if someone navigated into a file page from a category. I like current "category slideshow" tools but you can not edit from those. --Jarekt (talk) 13:50, 9 December 2016 (UTC)[reply]

DerivativeFX alternative

  • Problem: DerivativeFX was a tool that allowed for easy derivative work uploading. It added links on both the derivative and the derived work, and took care of licensing.
  • Who would benefit: Commons uploaders, image translators, illustrators.
  • Proposed solution: Create a similar tool, or integrate a similar function on actual Upload Wizard

Community discussion

Voting – DerivativeFX alternative

  1.   Support--Shizhao (talk) 02:36, 28 November 2016 (UTC)[reply]
  2.   Support as proposer Ninovolador (talk) 11:30, 28 November 2016 (UTC)[reply]
  3.   Support --Steinsplitter (talk) 15:06, 28 November 2016 (UTC)[reply]
  4.   Support · · · Peter (Southwood) (talk): 08:09, 29 November 2016 (UTC)[reply]
  5.   Support exploring various alternatives to fulfill this need. Stevie is the man! Talk • Work 19:20, 29 November 2016 (UTC)[reply]
  6.   Support but still skeptical if the task is possible without Structured data. --Jarekt (talk) 19:30, 29 November 2016 (UTC)[reply]
  7.   Support --Alexmar983 (talk) 04:18, 30 November 2016 (UTC)[reply]
  8.   Support Syced (talk) 07:12, 30 November 2016 (UTC)[reply]
  9.   Support I use the crop tool now, but this is complicated because sometimes I want to upload a detail image that can't be cropped from the already uploaded "image of the whole thing". Recently I solved this by using the crop tool and then uploading my detail image over it, but this is a kludge. Jane023 (talk) 12:55, 30 November 2016 (UTC)[reply]
  10.   Support Ainali (talk) 07:26, 1 December 2016 (UTC)[reply]
  11.   Support --Gestumblindi (talk) 21:27, 1 December 2016 (UTC)[reply]
  12.   Support —Justin (koavf)❤T☮C☺M☯ 03:51, 2 December 2016 (UTC)[reply]
  13.   Support -Geraki TL 09:11, 2 December 2016 (UTC)[reply]
  14.   Support // Martin Kraft (talk) 23:38, 2 December 2016 (UTC)[reply]
  15.   Strong support --Pokéfan95 (talk) 07:00, 3 December 2016 (UTC)[reply]
  16.   Strong support --jdx Re: 08:55, 3 December 2016 (UTC)[reply]
  17.   Support --User:Downspec
  18.   Support Jianhui67 talk★contribs 09:57, 3 December 2016 (UTC)[reply]
  19.   Support --Nevit (talk) 21:07, 3 December 2016 (UTC)[reply]
  20.   Support--Ranjithsiji (talk) 05:48, 4 December 2016 (UTC)[reply]
  21.   Support--Fulvio314 (talk) 08:19, 4 December 2016 (UTC)[reply]
  22.   Support--Praveen:talk 12:47, 5 December 2016 (UTC)[reply]
  23.   Support — Hmxhmx 18:21, 5 December 2016 (UTC)[reply]
  24.   Support Dearly missed, even the blunders it created. --Hedwig in Washington (talk) 03:44, 6 December 2016 (UTC)[reply]
  25.   Support --Assianir (talk) 07:40, 7 December 2016 (UTC)[reply]
  26.   Support --Kiril Simeonovski (talk) 09:37, 7 December 2016 (UTC)[reply]
  27.   Support, I also liked DerivateFX and miss it — NickK (talk) 18:37, 7 December 2016 (UTC)[reply]
  28.   Support --Harlock81 (talk) 18:54, 7 December 2016 (UTC)[reply]
  29.   Support Me too! Daniel Case (talk) 05:45, 8 December 2016 (UTC)[reply]
  30.   Support — Rhododendrites talk \\ 06:30, 8 December 2016 (UTC)[reply]
  31.   Support --Carnildo (talk) 03:34, 9 December 2016 (UTC)[reply]
  32.   Support --OrsolyaVirág (talk) 12:48, 10 December 2016 (UTC)[reply]
  33.   Support --Dvdgmz (talk) 21:01, 10 December 2016 (UTC) Commons needs tools to facilitate reuse, derivative tracking and multiauthorship attribution[reply]
  34.   Support Most of my contributions to commons are DWs.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:54, 11 December 2016 (UTC)[reply]

Easier file description

  • Problem: The problem is, that file description takes usually 3 or 4 times more time, than images creation and preparation. One day photographic gurney, where you create about 200 images for 25 objects, could be post-processed and uploaded within 4 hours, but it is ussually not, because you spend day on proper file naming, identification of objects displayed, local language description, Englis description, GEO COORDs adding, category setting days!
  • Who would benefit: Wikimedia Commons contributors, secondly everybody, who reads Wikipedia (because, removing such problem, we may get more photographers to our community, who will enrich Wikipedia articles with their production).
  • Proposed solution: Create a bot or tool, which will retrive information from file name and geo and propose file description in English and categories. Correct file name on commons is file:main object, detail.jpg. From such standard filename bot can guess several categories: category:main objects, category: details in UK, etc. Also geocoords provide a lot of information. e.g. Jeffrey's Image Metadata Viewer guesses Photographer location from the geo and set Street, Street no, village and municipality. Such tool may help with categorisation and description creation on Wikimedia Commons.

Community discussion

Voting – Easier file description

  1.   Support--Wesalius (talk) 06:45, 28 November 2016 (UTC)[reply]
  2.   Support --Ziko (talk) 21:09, 28 November 2016 (UTC)[reply]
  3.   Support Jane023 (talk) 12:57, 30 November 2016 (UTC)[reply]
  4.   Support Draceane (talk) 09:47, 2 December 2016 (UTC)[reply]
  5.   Support--Ranjithsiji (talk) 05:48, 4 December 2016 (UTC)[reply]
  6.   Support - Best regards, Kertraon (talk) 11:31, 4 December 2016 (UTC)[reply]
  7.   Neutral Several problems, starting with language. Then typos. Then putting tons of uploads into a meta category, like Europe. Too many variables for a bot to sort out. Not sure if a bot can be trained to generate a location category out of long/lat. Surely better than none category at all. That we be a question for bot requests. --Hedwig in Washington (talk) 03:01, 6 December 2016 (UTC)[reply]
  8.   Support --Kiril Simeonovski (talk) 09:44, 7 December 2016 (UTC)[reply]
  9.   Support --Chrumps (talk) 03:37, 11 December 2016 (UTC)[reply]
  10.   Support --Soluvo (talk) 00:29, 12 December 2016 (UTC)[reply]
  11.   Support--Mikheil Talk 20:59, 12 December 2016 (UTC)[reply]

Implement Internet Archive BookReader in Commons & Wikisource

  • Problem: When we view a scanned book in PDF or DjVu format in Commons or Wikisource, its always single-page view with no option to go for previous or next page in that preview. Every-time we go to the next page, we need to click on the drop down menu of pages. See this book in Commons for example. For book readers, its more like viewing images than reading books. This not only creates difficulty in reading, but also in identifying missing, duplicated pages etc. if the file needs to be corrected.
  • Who would benefit: Commons & Wikisource editors and readers
  • Phabricator tickets:

Community discussion

@Samwilson:, I was also confused where to put the proposal. Please move it accordingly. -- Bodhisattwa (talk) 06:00, 16 November 2016 (UTC)[reply]

Voting – Internet Archive BookReader in Commons & Wikisource

  1.   Support--Wesalius (talk) 06:45, 28 November 2016 (UTC)[reply]
  2.   Support, great idea IMO, would recommend looking at usability of the IA BookReader if possible though, and possibly improving upon it Spinster (talk) 15:01, 29 November 2016 (UTC)[reply]
  3.   Oppose, there are buttons for the next and previous pages of the book. --Fixuture (talk) 20:41, 29 November 2016 (UTC)[reply]
  4.   Support--Micru (talk) 12:24, 30 November 2016 (UTC)[reply]
  5.   Support Nevertheless consider the IA book reader IMHO uses high resolution jpg instead of compressed (often too much) IA pdf/djvu images. Final result, using compressed images, would be of lower quality. --Alex brollo (talk) 12:32, 30 November 2016 (UTC)[reply]
  6.   Support Great to build upon existing open source. Ainali (talk) 07:28, 1 December 2016 (UTC)[reply]
  7.   Support I love archive.org's online book experience. I much prefer it. Rachel Helps (BYU) (talk) 18:50, 1 December 2016 (UTC)[reply]
  8.   Support NMaia (talk) 02:08, 2 December 2016 (UTC)[reply]
  9.   Support Anything that brings together our communities. —Justin (koavf)❤T☮C☺M☯ 03:58, 2 December 2016 (UTC)[reply]
  10.   Support --Continua Evoluzione (talk) 13:57, 2 December 2016 (UTC)[reply]
  11.   Support Sannita - not just another it.wiki sysop 14:08, 2 December 2016 (UTC)[reply]
  12.   Support --Ranjithsiji (talk) 05:49, 4 December 2016 (UTC)[reply]
  13.   Support --HHill (talk) 10:33, 5 December 2016 (UTC)[reply]
  14.   Support --Andropov (talk) 17:47, 5 December 2016 (UTC)[reply]
  15.   Support Not high priority but should be considered soonish. --Hedwig in Washington (talk) 03:02, 6 December 2016 (UTC)[reply]
  16.   Support --Kiril Simeonovski (talk) 09:44, 7 December 2016 (UTC)[reply]
  17.   Support Low priority but potentially useful — NickK (talk) 18:38, 7 December 2016 (UTC)[reply]
  18.   Support - DPdH (talk) 20:01, 7 December 2016 (UTC)[reply]
  19.   Support --Psychoslave (talk) 09:57, 9 December 2016 (UTC)[reply]
  20.   Support Ayack (talk) 11:53, 9 December 2016 (UTC)[reply]
  21.   Support --Jarekt (talk) 13:57, 9 December 2016 (UTC)[reply]
  22.   Support Even though the ability to paginate exists already, it's quite cumbersome. This would be a much better interface. Waldir (talk) 11:00, 10 December 2016 (UTC)[reply]
  23.   Support --OrsolyaVirág (talk) 12:49, 10 December 2016 (UTC)[reply]
  24.   Support --g (talk) 12:52, 10 December 2016 (UTC)[reply]
  25.   Support --Dvdgmz (talk) 21:05, 10 December 2016 (UTC) to do Commons a better place to see/read content, not only to upload and download[reply]
  26.   Support --Yann (talk) 22:42, 12 December 2016 (UTC)[reply]

Make categories sortable

  • Problem: Good ordering of files within in categories is not given. Filenames begin with numbers, dates, locations or anything else. Additionally sometimes disruptive sortkeys are added to the files, with inconsistent schemas.
  • Who would benefit: Everyone, especially readers
  • Proposed solution: Make files within categories sortable for readers, for example sorted by location, date, name, subject,...
  • Phabricator tickets:

Community discussion

I'll try to explain it. It's a problem for a lot of categories in Wikimedia Commons, for example commons:Category:2012_in_New_York_City. The subcategories are (mostly) well ordered, the files not. But the files are ordered. Some people gave sortkeys to the files like [[Category:2012 in New York City|20120118 New York City]]. Other editors gave sortkeys like 0118 or 20120118 or no sortkey. The user sees an unordered list of files or a list that looks like unordered. It's a lot of work to give sortkeys to all the files in all categories like the one seen in the example. It would be an easy task if the category has an attribute like date ordered category. And it would be much better for all user to see a drop down list with options like sort by upload date, sort by date taken, sort by filename or sorted by any other meta data. Another good option would be to see a filter, so only files like *Empire State* are displayed. --XRay (talk) 06:25, 22 November 2016 (UTC)[reply]

Voting – Make categories sortable

  1.   Support Ninovolador (talk) 11:32, 28 November 2016 (UTC)[reply]
  2.   Support the thrust of this, as the naming and individual file sorting on Commons isn't quite as orderly as in the Wikipedias. After all, the files have metadata to work with for the category sorting -- why not take advantage of this? Stevie is the man! Talk • Work 16:25, 29 November 2016 (UTC)[reply]
  3.   Support Guycn2 · ☎ 17:50, 29 November 2016 (UTC)[reply]
  4.   Support Definitelly yes, but this could be solved by lasts year proposal to move commons categories to wikidata to the form of tags Juandev (talk) 21:04, 1 December 2016 (UTC)[reply]
  5.   Support --XRay (talk) 06:01, 2 December 2016 (UTC)[reply]
  6.   Support Draceane (talk) 09:47, 2 December 2016 (UTC)[reply]
  7.   Support, not sure if this would also be useful for categories on Wikipedia (and if this suggestion is also concerned with those) [if so allowing to sort by WikiProjects' importance & quality ratings as well would be useful there]. --Fixuture (talk) 18:07, 2 December 2016 (UTC)[reply]
  8.   Support // Martin Kraft (talk) 23:39, 2 December 2016 (UTC)[reply]
  9.   Support Jianhui67 talk★contribs 10:00, 3 December 2016 (UTC)[reply]
  10.   Support - DPdH (talk) 20:04, 7 December 2016 (UTC)[reply]
  11.   Support--Ranjithsiji (talk) 05:49, 4 December 2016 (UTC)[reply]
  12.   Neutral I'd rather see an easy mass-rename feature. --Hedwig in Washington (talk) 03:05, 6 December 2016 (UTC)[reply]
  13.   Support Muhraz (talk) 15:43, 6 December 2016 (UTC)[reply]
  14.   Support--Kiril Simeonovski (talk) 09:45, 7 December 2016 (UTC)[reply]
  15.   Support —Ynhockey (talk) 12:03, 7 December 2016 (UTC)[reply]
  16.   Support, at least some criteria (e.g. by usage, by size or by type) would be useful — NickK (talk) 18:39, 7 December 2016 (UTC)[reply]
  17.   Support per NickK. Daniel Case (talk) 05:44, 8 December 2016 (UTC)[reply]
  18.   Support sorting by attributes stored in the database, like size, type, upload date, EXIF date, original uploader, etc. could be useful. Skeptical about sorting on attributes stored in wikitext. --Jarekt (talk) 14:02, 9 December 2016 (UTC)[reply]
  19.   Support Linie29 (talk) 14:17, 9 December 2016 (UTC)[reply]
  20.   Support per Jarekt --Waldir (talk) 11:05, 10 December 2016 (UTC)[reply]
  21.   Support OrsolyaVirág (talk) 12:50, 10 December 2016 (UTC)[reply]
  22.   Support --Dvdgmz (talk) 21:06, 10 December 2016 (UTC) would be good to use commons as a presentation (ppt-like) tool in education[reply]
  23.   Support --NaBUru38 (talk)
  24.   Support --Cavarrone (talk) 10:14, 11 December 2016 (UTC)[reply]
  25.   Support --Plagiat (talk) 17:19, 11 December 2016 (UTC)[reply]
  26.   Support --Yann (talk) 22:42, 12 December 2016 (UTC)[reply]

"MediaChanges" feed to track pages where images are used

  • Problem: At the moment, its almost impossible to track, for a set of images, not only which pages images are used on, but who contributed them and when. This prevents a number of community organizing activities including:
  • Figuring out which editors have a vested interest in images on Commons, but used in another wiki
  • Community organizers, seeking to create campaigns like Archives_Challenge_2016, where collections of media are encouraged for use across multiple projects. Organizers should be able to track changes in the use of media files, without having to rely heavily on self reporting.
  • Sending thank-yous to folks who use images from collections.
  • Who would benefit: GLAM community, mass Uploaders, community organizers hoping to engage more communities in using media files across projects
  • Proposed solution: Create a recent changes-like feed that reports that logs the diff for when images are first transcluded on a page on a Wikimedia wiki and then stop being transcluded on a page, recording the diff of the changes that add or remove the media file. This feed/database/changelog could be used for an "image use watchlist" so to speak.

Community discussion

Voting – "MediaChanges" feed to track pages where images are used

  1.   Support as creator, Sadads (talk) 14:45, 28 November 2016 (UTC)[reply]
  2.   Support MichaelMaggs (talk) 19:53, 28 November 2016 (UTC)[reply]
  3.   Support WereSpielChequers (talk) 12:38, 29 November 2016 (UTC)[reply]
  4.   Support There's definitely a value to having ways to watch or aggregate these transclusions/untransclusions. I share Bawolff's views but I'm sure able developers will figure out a good solution. Stevie is the man! Talk • Work 16:20, 29 November 2016 (UTC)[reply]
  5.   Support, however I do think that the proposal is a bit misleading: it's already possible to track where images are used as the pages that use an image are listed on the image's page. As of right now there's just no proper way to get notified when a page adds a specific image. I'd suggest (also) allowing people to have such image-inclusions appear in their normal watchlist. --Fixuture (talk) 20:53, 29 November 2016 (UTC)[reply]
    @Fixuture: If you read into the way in which the Phabricator item is scoped, I the problem behind all of this, is that we are not tracking the "when" of transclussions: the database doesn't record the diff in which transclusion happens, so you can't point at the information associated with a diff -- they just appear once the software recognizes the transclusion. Sadads (talk) 14:58, 30 November 2016 (UTC)[reply]
  6.   Support --Alexmar983 (talk) 04:19, 30 November 2016 (UTC)[reply]
  7.   Support Rachel Helps (BYU) (talk) 18:51, 1 December 2016 (UTC)[reply]
  8.   Support--Ranjithsiji (talk) 05:49, 4 December 2016 (UTC)[reply]
  9.   Support Gareth (talk) 10:48, 4 December 2016 (UTC)[reply]
  10.   Support Long overdue. Muhraz (talk) 15:43, 6 December 2016 (UTC)[reply]
  11.   Support - DPdH (talk) 19:53, 6 December 2016 (UTC)[reply]
  12.   Support --Assianir (talk) 07:40, 7 December 2016 (UTC)[reply]
  13.   Support --Kiril Simeonovski (talk) 09:47, 7 December 2016 (UTC)[reply]

Multi-description tool

  • Problem: As of now, there is more than 291 000 pictures on Wikimedia Commons withouth any description. If one person will be able to describe mannualy 100 per day, the entire work would take him 8 years. Even the community is failing in solving this issue, and the number is therefore going only up. Having categories is fine, but some information can't be put in the categorization table. That is why we need a tool that will allow us to work much faster. Like in Wikidata, where actual editing is not done by the edit link, but by various tools, on Commons with thousands of photos we need to use tools like Commonist or Cat-a-lot in order to actually do something. And such a tool will only help.
  • Who would benefit: Wikimedia Commons editors and administrators.
  • Proposed solution: To apply the Special:Translate extension (that is already used on Meta) and really well working on Translatewiki.net to a given category on Commons. ie: 1) the user select a category 2) a list of pictures without description in a chosen language appears 3) the user can add description "one line - one file". Edits are being saved in the same time as new ones are being written.
  • Phabricator tickets:

Community discussion

  • I am one of the users who used to add descriptions and I have to say I am bored and frustrated. We need to improve some efficient tool, I totally support the general idea here. Some sort of fast translation interface like on meta would be terrific. We spent so much energy on a translation tool for articles where there are tons of bugs and local templates and it is often far from efficient, but in reality it is on multilingual platform on short string that these ideas perform better. More in general, we agreed amongst friends, also discussing offwiki, that wikidata has opened a new type of architecture for multilingual platform, and as a crosswiki project wikimedia commons should start to embrace it.--Alexmar983 (talk) 05:25, 14 November 2016 (UTC)[reply]
  • I heard that this problem could be fixed by adding Translatewiki tag into commons file descriptions. Did someone asked someone with a bot to do so?--Juandev (talk) 16:58, 14 November 2016 (UTC)[reply]
  • @Aktron: There's another proposal below related to making descriptions more efficient: Easier file description. Could we combine them, or are there are significant differences that make this proposal unique? Same question about your other description proposal right below here. :) -- DannyH (WMF) (talk) 23:27, 18 November 2016 (UTC)[reply]
    • Well, I believe this can be easily merged with a proposal below. The point here is to make multiple edits just by one edit submission (like on Translatewiki), but the data have to be imputted manually. In the proposal below the data are extracted automatically, but with one edit per one submission. Combining these would be good, but only for uploading. For that 290 000+ files it is hard to get data from GPS if these are not there. And in many cases the file descriptions are not helpful, but random. Unfortunately. --Aktron (talk) 12:37, 19 November 2016 (UTC)[reply]
  • To a degree, commons:User:MarkTraceur/editDescriptions.js does this already, but I don't think it would be considered 'production ready'. @MarkTraceur: Thoughts? Revent (talk) 19:55, 22 December 2016 (UTC)[reply]

Voting – Multi-description tool

  1.   Support, categories could also show the number of images without description in them and a button to start description-addition-tool. Also instead of just one image being shown to the user (with a next button that quickly switches to the next image) it would probably be better to show many images (e.g. 4 on a normal resolution, with the rest showing when scrolling down) at once to speed up the process. --Fixuture (talk) 21:02, 29 November 2016 (UTC)[reply]
  2.   Support --Alexmar983 (talk) 04:19, 30 November 2016 (UTC)[reply]
  3.   Support --Mess (talk) 19:10, 30 November 2016 (UTC)[reply]
  4.   Support In this case I would not mix it with other proposal as proposed. This is an easier way how to help people translate description and I dont see only one block which is a community consensus. Juandev (talk) 21:06, 1 December 2016 (UTC)[reply]
  5.   Support Draceane (talk) 09:48, 2 December 2016 (UTC)[reply]
  6.   Support - it would be useful to make these files easier to find, and to add the descriptions. Hopefully this would be a short-term tool, though, until the existing missing descriptions are fixed (assuming no new files are uploaded with missing descriptions!). Mike Peel (talk) 23:47, 2 December 2016 (UTC)[reply]
  7.   Support --Ranjithsiji (talk) 05:50, 4 December 2016 (UTC)[reply]
  8.   Support First line of defense should be that one can't upload anything w/o description (remove ignore feature). --Hedwig in Washington (talk) 03:09, 6 December 2016 (UTC)[reply]
  9.   Support Muhraz (talk) 15:45, 6 December 2016 (UTC)[reply]
  10.   Support - DPdH (talk) 20:08, 6 December 2016 (UTC)[reply]
  11.   Support --Assianir (talk) 07:35, 7 December 2016 (UTC)[reply]
  12.   Support --Kiril Simeonovski (talk) 07:41, 7 December 2016 (UTC)[reply]
  13.   Support —Ynhockey (talk) 11:53, 7 December 2016 (UTC)[reply]
  14.   Strong support, per Fixuture. Anything that helps add descriptions and categories to these images is well worth it, especially with the recent crop of images without descriptions being uploaded from panoramio. ----DanTD (talk) 21:06, 7 December 2016 (UTC)[reply]
  15.   Support per Fixuture --g (talk) 12:54, 10 December 2016 (UTC)[reply]
  16.   Support --Dvdgmz (talk) 21:08, 10 December 2016 (UTC)[reply]
  17.   Support --Cavarrone (talk) 10:15, 11 December 2016 (UTC)[reply]
  18.   Support --Plagiat (talk) 17:20, 11 December 2016 (UTC)[reply]
  19.   Support --Soluvo (talk) 00:31, 12 December 2016 (UTC)[reply]

UploadWizard: Allow providing image categories and description while still uploading

(was: New upload wizard; corrected by User:Gryllida on 23:43, 1 December 2016 (UTC))[reply]

  • Problem: Upload wizard is slow, boring and old
  • Who would benefit: Anyone who uploads several files together on commons
  • Proposed solution: Ses how album upload works on Facebook: while the files are uploading you can start to put tags and descriptions oin those already done, you don't have to wait until it all ends. There is not loss of time there, the user can take advantage of the upload time and fix your work immediately. It is more fun and easy.

Community discussion

  • Whatever is the improvement, we need a better upload management. It's a disaster. Of course someone may think this protects commons form tons of files to be uploaded by users that uses it as social media platform. I do, for example. But we can always test it with autopatrolled users... or with users with a certain number of upload. Many platform allow faster and better upload of metadata and information to more "expert" users, it is no more a discrimination than waiting before being an autoconfirmed.--Alexmar983 (talk) 05:05, 11 November 2016 (UTC)[reply]
    • That is what I hear everywhere. We cannot easy upload, because than we are flooded by useless images, we cannot start uplad app, because that we are flooded by useless images. But, who would love to use such primitive software to imitate social media like Facebook or Instagram? Are there any links to those examples, when somone were placing unproper files? How many people missused that upload app, and what was the percantege of these users regarding other users?--Juandev (talk) 16:56, 14 November 2016 (UTC)[reply]
Juandev I never found any specific data, I was just drafting an answer for a very common doubt, that as you also noticed always emerged with this type of request. What if users consider commons like one of those "narcissistic" social media, and they upload tons of photos of their breakfasts and cats? I don't know if this is likely, I just assume it could be. And my answer is: don't give advanced upload tools to everybody, that's the safer way to start. If after 12-18 month of restricted use the world has not ended, than we can test it for everyone I guess. That being said, there are some types of images that would be nice to have on commons and that we don't have because our upload is even too "serious", I found many classes proposing commons photo challenges. For examples for baby equipments or gardening, our quality was quite low. But I guess we can always pick them once needed from other platforms where they are more common than on commons. We already do that for some place or building images, scanning flickr for example. So it does not really affect our overall quality in a strict way, I guess. Maybe we do need much faster way to export to commons, I agree on that but personally I doubt that whoever uploaded them on another website will do it on commons simply because we improve our interface. Sometimes you get the picture of a park or a village just cutting an happy family vacation photo that would have never been uploaded on commons in any case, for example. But that's just a feeling. What is more objective is that there is too much back log and we don't want to increase that. Of course improving efficiency in file management would be better than just putting an upload funnel, as we are de facto doing now and that's no real solution, I agree, and that's what we ask for in these wishlist surveys every year. But helping expert users to upload faster does not increase the back log, it reduces it. So I think that should be, based on good sense, the best strategy so far and a compromise we can all agree on to move on. But again if there are data, and someone has time to show us, I am more to happy to read them.--Alexmar983 (talk) 03:59, 15 November 2016 (UTC)[reply]
  • Agree with the proposer. I do note that 'ease' is somewhat incompatible with our projects stated goals of quality, educational value and reuse freedom. Comparison with other websites won't hold up completely for that reason, but workflow wise there are still huge improvement steps that we could make, like indeed doing metadata annotation while we upload. I do however think that any contribution improvements to Commons requires equal improvement to the curator workflows to review those contributions. —TheDJ (talk • contribs) 10:39, 11 November 2016 (UTC)[reply]
I agree that revising the workflow is very important, but again it is not because of this aspect that the we don't have to ask for an improved uploading system. As I said, there is a simple maybe just temporary solution, we can restrict advanced functionalities to a class of users (whatever it is) that we statistically trust. This way we have all the time to see the impact and check how the overall workflow is affected. i think that the strategy "if you're a good users, you get a nicer tool" should pay in the end. The funnel of the upload is not critical for sporadic users, it is not so annoying when you upload a picture once in a while. I don't care to fix the files of these users while revising them. I believe that the main target should be at least to allow people who know what they are doing, to do it faster, that's in the interest of everyone.--Alexmar983 (talk) 04:20, 12 November 2016 (UTC)[reply]
I use commonist for upoading, but I am always afraid that with new Java versions, needed for this use, it does not work any more. So I don't download the updates. Dangerous. --Stunteltje (talk) 11:34, 14 November 2016 (UTC)[reply]
There is a plethora of other upload tools, which are just as good, if not better than Commonist -FASTILY 21:15, 17 November 2016 (UTC)[reply]
First time I see this page, I should translate it in Italian and spread the news.--Alexmar983 (talk) 07:24, 18 November 2016 (UTC)[reply]

My request would be a button that clears the upload form when you go back to it if, like me, you prefer to upload images one at a time. Currently when you go back to it you have to do this yourself, unless you go all the way back to the wizard page and reclick the link. Daniel Case (talk) 05:05, 16 November 2016 (UTC)[reply]

That doesn't mean it can't be improved. Daniel Case (talk) 07:51, 18 November 2016 (UTC)[reply]
  • I didn't know about the other upload tools. What if we make some analysis about features that people need, check which tool has them and maybe start to insert in the current basic interface a link like "if you need a tool that does this >> click here". It looks to me that there were many tests and attempt to improve so far, but we kinda failed to actually integrate the expertise in a more plug-and-play infrastructure. If it is not a problem of coding, I suspect there is some problem of management, of long-term coordination. Are we ok with this status quo, namely an "old" upload interface and a plethora of more advanced but secondary tools, or can we start to integrate something here?--Alexmar983 (talk) 07:24, 18 November 2016 (UTC)[reply]
    • I can but agree on this proposal. There at least ought to be a form for experienced users who have to upload several images at once (for instance, from the same museum) and need to write detailed captions, perhaps in more than one language as I do. Currently I have to write zzzzzzzzzzzzzzzz in the compulsory fields, otherwise I am not allowed to upload, and then open the uploads one by one and correct the gibberish one by one. There is no space enough to write the full text in the case. "Commonist" was much better at this. Sometimes, I prefer uploading some photos on Facebook when I think of how much more complicate and time-consuming it would be uploading them on Commons :-( --G.dallorto (talk) 11:26, 20 November 2016 (UTC)[reply]
      • @G.dallorto: What tool are you using to upload the files? I think https://commons.wikimedia.org/wiki/Special:UploadWizard (the default one when you click "Upload file" in Commons' sidebar) allows you to do all this… Matma Rex (talk) 18:07, 25 November 2016 (UTC)[reply]
        • Have you ever tried and upload twenty images at once? I doubt. It works for one, or two images at once, non for bulk uploads, such as those you upload after you visit a museum, with diverse captions and texts. have a try, and then let me know. --G.dallorto (talk) 22:50, 25 November 2016 (UTC)[reply]
          • @G.dallorto: I'm not a photographer, and I think the most files I ever uploaded at once was five, but I've tested with 50 several times when working on UploadWizard's performance and everything seemed fine (I'm part of WMF's Multimedia team). I really would appreciate if you could explain the exact problems you're facing, so that we can fix them. For example, why do you need to fill fields with gibberish to upload files, and which fields? Why is the current interface for multilingual descriptions insufficient? Matma Rex (talk) 14:45, 26 November 2016 (UTC)[reply]
      • we should have a better way of interacting with the wizard team to incorporate UX. the response "works fine for me" is inadequate. there needs to be clear off ramp for other than own photos, since this is not designed for, and create bad metadata for others to cleanup. Slowking4 (talk) 15:22, 21 November 2016 (UTC)[reply]

@Sailko: Could you provide some clarification on how you would want a new UploadWizard to be different than the existing one. What specific features or changes would you like to see? Ryan Kaldari (WMF) (talk) 19:21, 21 November 2016 (UTC)[reply]

I was thinking of the fields where you put description, categories etc., to appear as soon as the image is uploaded, next to the preview. You could start working on them while the other images upload. Now instead you have to wait untill all the images are uploaded. --Sailko (talk) 20:58, 21 November 2016 (UTC)[reply]
  • I don't see why this would require a "new" upload wizard. It's entirely possible to add this feature to the existing one, and it's a long-standing request (phab:T39462)). UploadWizard has received some attention from the Multimedia team at the WMF this year, but we've been mostly focusing on stability improvements. Matma Rex (talk) 18:01, 25 November 2016 (UTC)[reply]

Voting – New upload wizard

  1.   Support--Shizhao (talk) 02:39, 28 November 2016 (UTC)[reply]
  2.   Oppose Not a good use of developer time. UploadWizard is a basic tool used for handling simple cases; advanced/special needs can easily be met by these upload tools. Adding advanced features to UploadWizard at this point would be a bad case of reinventing the wheel. -FASTILY 09:22, 29 November 2016 (UTC)[reply]
  3.   Oppose Yes, we need a better UploadWizard but it's wiser to start working on this when Structured Data on Commons is rolled out, so that we have an UploadWizard that immediately works with that. Spinster (talk) 14:52, 29 November 2016 (UTC)[reply]
  4.   Oppose a new upload wizard, but I'm neutral on phab:T39462 as a change to the existing one. That seems reasonable enough to work on eventually, but I don't feel it's important enough for the WMF to work on in the next year. Otherwise, I don't think this should ever be about "fun and easy". But ideas to get rid of unnecessary impediments are certainly welcome. Stevie is the man! Talk • Work 17:12, 29 November 2016 (UTC)[reply]
  5.   Oppose I do not think we need a new upload wizard. I think current upload wizard needs to be improved and expanded (special cases for supporting other commons infoboxes like "Artwork" or "Book", better support of "not own work" cases, etc), and I do not oppose specific improvement mentioned in phab:T39462 but it is a low priority in my book and should be done to current upload wizard. --Jarekt (talk) 18:00, 29 November 2016 (UTC)[reply]
  6.   Support We need a simple tool, not a limited tool. Simple for example means that in a plug and play way, advanced functionality can be added in an elegant way, not that they are not present. I talk a lot with newbies and they don't really like to be treated like that. The commons community should really address this perception problem... we have backlog also because we don't allow people to do more in an easy way. And again the problem of being flooded disappears if you propose the right filter to access the new functionalities.--Alexmar983 (talk) 04:28, 30 November 2016 (UTC)[reply]
  7.   Support --Mess (talk) 18:59, 30 November 2016 (UTC)[reply]
  8.   Support Upload Wizard should let users add description and categories while the upload is progressing (not only after it ends), and should be faster and less buggy when dealing with many files (upload often gets stuck when I select many pictures at once). --Una giornata uggiosa '94 · So, what do you want to talk about? 02:42, 1 December 2016 (UTC)[reply]
  9.   Support I don't want wait 2 hours before to sleep anymore PLEASE!!! to add the description, category and name of all my images (arround 90 Mpx). I want add this information and let the upload join this information.--The Photographer (talk) 17:52, 1 December 2016 (UTC)[reply]
  10.   Oppose I do not think we need a new upload wizard. --Steinsplitter (talk) 18:52, 1 December 2016 (UTC)[reply]
  11.   Support Even I dont use browser upload, I think this is a good idea Juandev (talk) 21:07, 1 December 2016 (UTC)[reply]
  12.   Support "while the files are uploading you can start to put tags and descriptions oin those already done, you don't have to wait until it all ends." or "Allow providing image information (categories/description) while still uploading" from the phab task title it is a very clear request, I don't see where the confusion comes from. The title is bad, I corrected it. --Gryllida 23:43, 1 December 2016 (UTC)[reply]
  13.   Support CFynn (talk) 05:49, 2 December 2016 (UTC)[reply]
  14.   Support Draceane (talk) 09:48, 2 December 2016 (UTC)[reply]
  15.   Support --Sailko (talk) 11:51, 2 December 2016 (UTC)[reply]
  16.   Neutral I'm not really convinced that there is a sufficient need for this. --Tryptofish (talk) 22:15, 5 December 2016 (UTC)[reply]
  17.   Oppose per above, nuttin' to add. --Hedwig in Washington (talk) 03:12, 6 December 2016 (UTC)[reply]
  18.   Oppose--I do not think we need a new upload wizard.--alm (talk) 03:52, 6 December 2016 (UTC)[reply]
  19.   Support Muhraz (talk) 15:47, 6 December 2016 (UTC)[reply]
  20.   Support - Improve existing tool if possible, new if not. DPdH (talk) 20:05, 6 December 2016 (UTC)[reply]
  21.   Support --Assianir (talk) 07:35, 7 December 2016 (UTC)[reply]
  22.   Support The suggestion is sensible and may solve a problem that many users regularly face during mass uploads.--Kiril Simeonovski (talk) 07:54, 7 December 2016 (UTC)[reply]
  23.   Support for changes in the existing wizard, not necessarily a new wizard. The reliance on outside tools known only to veteran editors is one of the major problems in our projects (IMO), and this should be curbed as much as possible, especially when the problem is with the UX; even if the cost is investing developer time on re-creating functionality that already exists in external tools. —Ynhockey (talk) 11:57, 7 December 2016 (UTC)[reply]
  24.   Comment The current UW is hardly a wizard. It lacks reliability and many useful features. It needs a grand-uplifting, and a lot of bug correction. --Yann (talk) 22:46, 12 December 2016 (UTC)[reply]

Rapid category creation

  • Problem: Commons category tree is chaotic, and one aspect is the lack of category when necessary. This is frustrating for less expert users that don't understand for example why "X in country A" exists but not "X in country B" or "Y in country A". Now, we can't put a powerful tool in the end of newbies but at least for autopatrolled users some easy interface to create new categories would be useful.
  • Who would benefit: Every users of commons. The faster new specific category can be created, the easier they can be used by less expert users during upload.
  • Proposed solution: I would like a tool that based on the generic categories that are already inserted in a file, and on similar subcategories at their same level, is able to suggest the creation of a new category with a click. Such proposed code could be revised by the user before saving it, and maybe it could be later integrated in an advanced upload interface directly if it proves successful. So, if you have the categories "dumpsters" and "Italy" the tool could offer you to save a new "category:dumpsters in Italy" informing that we already have "dumpsters in Canada" and "dumpsters in Russia", just to be sure that's not really an "uncharted territory", but quite a standard ramification (this example occurred to me yesterday). The use of the tool should be reported in the edit summary "category created by..." similarly to the gadgets on wikidata, for example. To avoid proliferation of new specific categories, we can limit its use to no more than X new categories per month. Still, it would be an improvement for the workflow of a lot of us.
  • More comments: Of course if there is something similar to do that, I am more than happy to learn it. I simply never discovered it yet.
  • Phabricator tickets:

Community discussion

Do we want every such intersection to be created automatically for a single item? Quite likely on the country level, but not necessarily for cities (e.g we have commons:Category:Neighborhoods in Chicago, but certainly wouldn't want "dumpsters in Chicago" fir a single image). We would require some reasonable means of identifying country categories as opposed to city categories. עוד מישהו Od Mishehu 07:15, 15 November 2016 (UTC)[reply]

I don't want that. The country was just an example, there are more combinations, In fact, as I clearly stated it is just a way to improve a manual task that would be done in any case (and the word automatically.... automatically appears in the wikimedian mind even if it is not automatic). The depth of our categories tree is a practical thing, it goes as it needs to go, most of the time, based on existing files. People like me work on what's there, we don't have time to work on what could be... I therefore clearly stated that the proposal should be based on existing subcategories, and manually revised. I am not saying we can do it efficiently even now, but hopefully with a more wikidata-like management we could in some years and it would be nice to start to think about it. I guess even now we can arrange something, even if less precise but good in many cases (if the suggestion is rubbish, I simply don't save it). And I am also even suggesting a limit per user of this type of creation. I mean, does it really risk to be like of those situations where we have to "suffer" just because people see critical scenarios that can be easily prevented by some sort of filter? Can we have some trust at least in the autopatrolled users on commons, at least that group... At the moment it takes 5 minutes to search in the cat tree to check to level of depth, copy the text from a previous cat, adjust it (or write it directly), insert the category... something that for well-established category pathway (that a program can detect) could be done in few second with a click and a manual revision. If we still have to work like that, no wonder it was not done enough, as it needed. I mean: the problem is not that we have too much overcategorization... we might have it somewhere probably done by some bot, but in a general perspective the issue is that we have a lot of partial categorization. And maybe a manually revised tool is not a bad idea. If we are not entrusted and find to some way to speed it up, we will do this type of job less frequently, and the image will remain in overcrowded categories for a long time. Fine with me...--Alexmar983 (talk) 11:32, 15 November 2016 (UTC)[reply]
  • I'm not sure if this is exactly the same idea, but it well could be. I've taking all pictures in Category:Burjassot which are also in Category:Town halls in the Land of Valencia to form the Category:Town hall, Burjassot. Which is included in both Burjassot and Town halls in the Land of Valencia. I understand that we need a tool that allowed all that process to be done in a few simple steps (not having to create-include files in category-include category as subcategory-exclude files from previous categories). B25es (talk) 19:38, 19 November 2016 (UTC)[reply]
  • I am leery of any idea/proposal that tends to automate the creation of categories. There's just too much that can go wrong, too easily. I'm more comfortable with this being a manual, human-judgment-based effort. Stevie is the man! Talk • Work 17:24, 29 November 2016 (UTC)[reply]
  • @Alexmar983: Afaik there are tools for that, aren't there? Couldn't find any though. I don't think that this should be built into Wikipedia - there are just very few people that would need it. I'd look up some "X in country" or "year in x" categories and ask their creators how they created them - I doubt they did that manually (and if so an appropriate tool would be needed indeed). --Fixuture (talk) 21:06, 29 November 2016 (UTC)[reply]
Fixuture there are tons of images needing all sorts of category, not just "X in country", people don't do because it a boring process. I talked to them, over the years. But in the end it is not my problem, it's a problem of commons, its management and the messages you're giving to users. If some users prefer to spend energy to find reason not to do something instead of helping to do it, as a wiki environment should suggest, it's their responsibility. I did my part :)--Alexmar983 (talk) 03:49, 30 November 2016 (UTC)[reply]
About about certain massive "X in country" or "year in x" categories I'm sure they did in a special way, but that's not what I am suggesting. I want a low-intensity process, and the fact the people scale up to a "automatic scenario" it's indicative IMHO of a partially ideological interpretation. I don't want to prepare 195 categories "X in country Y", I want to create "X in the specific country Y" when needed in an easier way, and so want other people I discussed in the past. you're not helping us, it is a fact. But this should not be done, it's apparently "dangerous". So dangerous that people even ignore the proposals to reduce its impact, provided since the beginning (restricted number of creations, restricted to specific users). Instead, stuffing files in overcrowded categories, inducing asymmetric and random categorization and maybe than once in a while performing some automatic massive categorization that requires in any case fixing and standardization, and concentrate the expertise in few hands... that's better on the long term? It seems to me that the only effect is to actually discourage a diffuse expertise, and probably one of the main cause of the backlog itself. But let's not loose the hope that more expert users will fix this issue, in the following 10 years. It's going to be difficult, apparently our autopatrolled users are so incompetent they cannot even manually revise a suggestion, with such a low starting level... :)--Alexmar983 (talk) 04:50, 30 November 2016 (UTC)[reply]
  • Since Alexmar983 brought up the issue of categories such as "Town halls in the Land of Valencia," I have something I need to say about this; Recently there was a decision made by a normally trustworthy administrators to delete "City Halls," "Village Halls," and other local government buildings in the United States and place them under "Town Halls" in (foo state). This is wrong, because these other types of halls are not Town Halls, and when the categories were revived he became quite adamant about deleting them, salted some of the redlinks, and even threatened other editors for bringing them back. This task must be undone. ----DanTD (talk) 19:25, 1 December 2016 (UTC)[reply]
I didn't cite that example but in any case I am not sure how this fits in the discussion. If you are saying there is a general push for some users to have less categories it is possible. But rationalization of categories is not totally related to the creation of them. If rules are clear, more correct categories are created making the rules stronger, if rules are not clear, creation of subgroups of categories with similar styles actually point out the possible scenario that has to be standardized and shows the most common alternatives. IMHO speeding up day-by-day tasks for a bigger group of users actually supports long-term balanced discussions about the style or strategy to adopt.--Alexmar983 (talk) 07:52, 2 December 2016 (UTC)[reply]

Another thing I am worried is that many proposal here goes in the direction of increasing categorization of file. That's good but please just consider that we shouldn't have an easy way to put things in existing (yet still quite generic, I don't expect the system to be super detailed) categories without supporting the creation of further necessary subcategories. We risk to create a funnel here. Both task should rely on diffuse expertise. And of course the second one is more delicate and it cannot be for the same number of people, but still it shouldn't be as slow as it is now. We needed some little help and we're gonna need it more. --Alexmar983 (talk) 07:52, 2 December 2016 (UTC)[reply]

Voting – Rapid category creation

  1.   Oppose Sorry, but I strongly think this work should be manually done, with human judgment. Stevie is the man! Talk • Work 17:27, 29 November 2016 (UTC)[reply]
    the judgement that you use when you verify a suggestion for example? You are basically saying that autopatrolled users don't have enough judgment to verify that. It's not a nice message. If I'll link this discussion to people in the following months, they won't fell very appreciated.--Alexmar983 (talk) 03:44, 30 November 2016 (UTC)[reply]
    I say they have enough judgment to do the work manually. Not everything should be automated or semi-automated. This proposal seems more than about mere suggestions as it is worded. Stevie is the man! Talk • Work 18:32, 30 November 2016 (UTC)[reply]
    if I have the judgment to look inside the category tree, check how similar category are structured, copy their code and save my proposal, I have the same judgment to take a code proposal from a tool and save it if it is ok. It's a suggestion and I save it. If you prefer, we can be sure than the suggestion can be also edited before saving and not after saving to add some other father category for example, but that's it. There is a total human judgment, the tool is only giving a shortcut for a boring task as many other tools. It is similar to the completion of a category name with AWB and It is much less ambiguous than the content translator, which provides many code lines to revise.--Alexmar983 (talk) 07:37, 2 December 2016 (UTC)[reply]
  2.   Support --Mess (talk) 19:00, 30 November 2016 (UTC)[reply]
  3.   Support --Una giornata uggiosa '94 · So, what do you want to talk about? 02:45, 1 December 2016 (UTC)[reply]
  4.   Support Emir of Wikipedia (talk) 15:15, 2 December 2016 (UTC)[reply]
  5.   Oppose Needs to be done manually. Just a good ol' copy and paste does the trick. Better invest developer time into really pressing matters. --Hedwig in Washington (talk) 03:15, 6 December 2016 (UTC)[reply]
  6.   Oppose Too risky. Muhraz (talk) 15:47, 6 December 2016 (UTC)[reply]
  7.   Support --Assianir (talk) 07:35, 7 December 2016 (UTC)[reply]
  8.   Oppose Indeed too risky. The small saving of time is not worth the time required for manually correcting the erors.Wouterhagens (talk) 08:09, 7 December 2016 (UTC)[reply]
  9.   Oppose This is an interesting idea but it may not work the way we expect. I think it is still better to do it manually.--Kiril Simeonovski (talk) 08:16, 7 December 2016 (UTC)[reply]
  10.   Neutral Adding a "red category" is sometimes better than no category. Matěj Suchánek (talk) 15:34, 7 December 2016 (UTC)[reply]
  11.   Oppose If I am correct, AWB with the right plugin can do this. And not worth of a developer's time. --Pokéfan95 (talk) 11:48, 8 December 2016 (UTC)[reply]
    waiting to learn that. Certainly making manually dozens of new categories is not worth my time :D. But if someone teaches me I'm more than happy to spread the information,--Alexmar983 (talk) 05:56, 10 December 2016 (UTC)[reply]

Recent uploads patrol webapp

  • Problem: We need much more diverse images from contributors with very diverse backgrounds, documenting their lives all over the world from Ethiopia to Vietnam. That means thousands of newbies, and that means a portion of uploaded files will be junk (learning often means making a few mistakes). Currently, only pictures uploaded via the Android app get a proper review. Other uploads often slip through and stay on Commons for years.
  • Who would benefit: People who want to delete junk (copyrighted/selfie/etc) images

Being a software developer, I estimate that implementing this would take between 2 and 4 weeks in total. So it is a low-hanging fruit with huge benefits.

  • Phabricator tickets:

Community discussion

  • @Syced: I don't think it's possible at the moment to part files as patrolled directly (it marks them with a '!' though). And good to get clarity that newbie-uploads is the replacement for CommonsUploadPatrol. @Steinsplitter: are you the maintainer? Do you have plans for this tool? Is the above proposal in keeping with your goals? —Sam Wilson 08:07, 15 November 2016 (UTC)[reply]

Voting – Recent uploads patrol webapp

  1.   Support Syced (talk) 06:53, 30 November 2016 (UTC)[reply]
  2.   Support--Ranjithsiji (talk) 05:51, 4 December 2016 (UTC)[reply]
  3.   Support 15:48, 6 December 2016 (UTC)
  4.   Support - DPdH (talk) 20:12, 6 December 2016 (UTC)[reply]
  5.   Oppose Such tool may seem definitely needed but, considering the number of files uploaded and the amount of work it requires, it is hard to believe that its introduction will lead to significant improvements. It is also a bit dubious what can be considered a 'junk' file. I think the problem should be mitigated by improvements made to the upload wizard as a preventive measure rather than by introducing some tools as a corrective measure.--Kiril Simeonovski (talk) 08:35, 7 December 2016 (UTC)[reply]

Search images by OCR

  • Problem: Many images contain at least some text. But searching for that text does not make these images appear in the results.
  • Who would benefit: People who use the search box.
  • Proposed solution: Perform an OCR (Optical Character Recognition) on the images, and index this information so that search can find it.

Community discussion

  • This is a very interesting proposal, I hope it catches on. NMaia (talk) 12:55, 19 November 2016 (UTC)[reply]
  • I agree this is interesting, but a first step might be to think through how automated tools can safely add metadata to Commons files. I think there are many computer vision researchers who might be interested in annotating our collection, but we need a way to do this so bad data does not overwhelm our good data. Maybe require an account and develop a naming convention for tentative automated contributions so they could be hidden or removed if their quality proved poor. Another useful thing would be to develop a corpus of images with text in them that has been included in the description. This would provide a training and test set for OCR developers. Another class of test sets might be images that contain X; we already have many. A master category of machine generated categories would also be helpful. there may well be a wave of efforts to use machine learning to categorize Commons images. Some preparation could avoid a lot of trouble.--ArnoldReinhold (talk) 21:46, 20 November 2016 (UTC)[reply]
  • This is something that should be addressed. Maybe not this year, but it should be addressed.--Alexmar983 (talk) 02:48, 22 November 2016 (UTC)[reply]
  • I was under the impression that if the file contained a text layer (Somewhat common for PDF/DjVu) the text layer information is included in searches. But now I can't find documentation for that. Bawolff (talk) 18:03, 23 November 2016 (UTC)[reply]

Voting – Search images by OCR

  1. See categorisation_of_Commons_media_using_computer_vision for computer vision work alreadz happening with GSoC in the past.   Support--Wesalius (talk) 06:35, 28 November 2016 (UTC)[reply]
  2.   Support A really interesting suggestion that can do a load of good if implemented well. Soni (talk) 15:04, 29 November 2016 (UTC)[reply]
  3.   Oppose for time being. Once we have structured data on Commons (similar to Wikidata) with ability to store various properties of each image, we can add OCR property. Then we can propose to make it searchable. Proposal ahead of its time. --Jarekt (talk) 18:10, 29 November 2016 (UTC)[reply]
  4. {{oppose}} per Jarekt. There's also a complication in that we would probably need a review process to human-verify the OCR results. This is too much to take on in the next year, IMHO. Stevie is the man! Talk • Work 18:15, 29 November 2016 (UTC)[reply]
    Soften my stance to   Neutral because this really is about timing, not potential value. Stevie is the man! Talk • Work 12:14, 10 December 2016 (UTC)[reply]
  5.   Oppose per Stevietheman and because this is simply too much effort for nothing as it'll probably won't get good enough results for most images that include text so that the people checking and fixing the results could have transcribed them manually in the time. But generally it's a good idea and might be worthy at another point in time... --Fixuture (talk) 21:09, 29 November 2016 (UTC)[reply]
  6.   Support if you do it later, fine with me. I think the idea should be supported, the timing of the process will change as it usually does for almost all of the proposals, but we need this soon or later. If it 's not the moment, we will accept the explanation of the delay but in my opinion there is no need to deny support per se.--Alexmar983 (talk) 04:00, 30 November 2016 (UTC)[reply]
  7.   Support Even if OCR is not 100% foolproof, it would make Commons files more discoverable, at a cost much lower than manually entering the pictured text in the descriptions (which is how it is done currently, very time consuming). Syced (talk) 06:57, 30 November 2016 (UTC)[reply]
  8.   Support --Mess (talk) 19:01, 30 November 2016 (UTC)[reply]
  9.   Support --β16 - (talk) 15:12, 1 December 2016 (UTC)[reply]
  10.   Support Ahm masum (talk) 17:07, 1 December 2016 (UTC)[reply]
  11.   Support Why not, than the bot can also write the red text to the description Juandev (talk) 21:08, 1 December 2016 (UTC)[reply]
  12.   Support I hear the opposes above, but I can't even begin to count how many times a shoddy, plain text OCR of an Internet Archive document has introduced me to entire bodies of literature. Having even barebones OCR'd text searchable on Google will greatly open our Commons resources to the Internet. I'm less concerned how it fits into Commons' overall data than how it fits Commons into common search engines. czar 01:05, 2 December 2016 (UTC)[reply]
  13.   Support NMaia (talk) 02:09, 2 December 2016 (UTC)[reply]
  14.   Support Libcub (talk) 02:26, 2 December 2016 (UTC)[reply]
  15.   Oppose per Jarekt -FASTILY 07:08, 2 December 2016 (UTC)[reply]
  16.   Oppose per Fixuture. --Steinsplitter (talk) 12:51, 2 December 2016 (UTC)[reply]
  17.   Oppose, per Jarekt. Muhraz (talk) 15:49, 6 December 2016 (UTC)[reply]
  18.   Support - DPdH (talk) 20:14, 6 December 2016 (UTC)[reply]
  19.   Support -- Movses (talk) 21:49, 6 December 2016 (UTC)[reply]
  20.   Support --Assianir (talk) 07:35, 7 December 2016 (UTC)[reply]
  21.   Support I like to see this especially work when searching text in scanned books and documents.--Kiril Simeonovski (talk) 08:39, 7 December 2016 (UTC)[reply]
  22.   Support Miniapolis 21:04, 8 December 2016 (UTC)[reply]
  23.   Support --Arnd (talk) 13:39, 9 December 2016 (UTC)[reply]
  24.   Support Linie29 (talk) 14:18, 9 December 2016 (UTC)[reply]

Searching for images in nested categories

  • Problem: While searching for images in nested categories, you never see all files in all sub-categories
  • Who would benefit: Anyone searching for images
  • Proposed solution: "View flat" option with standard maximum of 50/100/200 files while keeping original search string (e.g. "horse"): while searching for files, allow viewing all files in a category that has sub-categories, even though some files may be in multiple sub-categories.
  • Phabricator tickets:

Community discussion

Voting – Searching for images in nested categories

  1.   Support --Ziko (talk) 21:10, 28 November 2016 (UTC)[reply]
  2.   Support Guycn2 · ☎ 17:52, 29 November 2016 (UTC)[reply]
  3.   Support --Alexmar983 (talk) 04:01, 30 November 2016 (UTC)[reply]
  4.   Support --Mess (talk) 19:02, 30 November 2016 (UTC)[reply]
  5.   Support as proposer, Jane023 (talk) 00:49, 1 December 2016 (UTC)[reply]
  6.   Support --Bramfab (talk) 13:27, 1 December 2016 (UTC)[reply]
  7.   Support Ahm masum (talk) 17:07, 1 December 2016 (UTC)[reply]
  8.   Support --Kusurija (talk) 18:00, 1 December 2016 (UTC)[reply]
  9.   Support --Gestumblindi (talk) 21:23, 1 December 2016 (UTC)[reply]
  10.   Support Libcub (talk) 02:21, 2 December 2016 (UTC)[reply]
  11.   Support --Morio (talk) 11:43, 2 December 2016 (UTC)[reply]
  12.   Support --Nevit (talk) 21:10, 3 December 2016 (UTC)[reply]
  13.   Support--Molgreen (talk) 06:03, 4 December 2016 (UTC)[reply]
  14.   Support - Best regards, Kertraon (talk) 11:38, 4 December 2016 (UTC)[reply]
  15.   Support Muhraz (talk) 15:49, 6 December 2016 (UTC)[reply]
  16.   Support --Assianir (talk) 07:35, 7 December 2016 (UTC)[reply]
  17.   Support --Geolina163 (talk) 08:33, 7 December 2016 (UTC)[reply]
  18.   Support--Kiril Simeonovski (talk) 08:39, 7 December 2016 (UTC)[reply]
  19.   Support --M11rtinb (talk) 16:29, 7 December 2016 (UTC)[reply]
  20.   Support — NickK (talk) 18:30, 7 December 2016 (UTC)[reply]
  21.   Support --Carnildo (talk) 01:54, 8 December 2016 (UTC)[reply]
  22.   Support — Rhododendrites talk \\ 06:25, 8 December 2016 (UTC)[reply]
  23.   Support Miniapolis 21:06, 8 December 2016 (UTC)[reply]
  24.   Support OrsolyaVirág (talk) 12:51, 10 December 2016 (UTC)[reply]
  25.   Support, with a customizable depth level. --NaBUru38 (talk)
  26.   Support Lack of this is very frustrating.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:56, 11 December 2016 (UTC)[reply]
  27.   Support --Alaspada (Talk) 20:05, 11 December 2016 (UTC)[reply]

Semi-automatic photo description and categorization tool

  • Problem: Every user has to add categories and descriptions (mostly) manually when uploading a file. This is ok for the experienced users, but annoying for newbies. Looking for a suitable category from hunderds of available ones is usually time-consuming. Describing pictures with information kinda similar to available categories is also rather annoying, given the fact that sometimes one information needs to be written twice ({{en|A tree in the Paris garden}} [[Category:Paris Garden]][[Category:Trees]]
  • Who would benefit: Commons uploaders
  • Proposed solution: The information we need is already there in some parts. We do have now pictures that are uploaded with the geographical coordinates. It is a small part of all uploads, but it is growing over time. What we do need is a tool that will take the coordinates (data) and looks for the nearest Wikipedia article. Then the tool will suggest the name of the article as a suggestion for the user for the picture. The user can either confirm or reject it - it can be a popup window or it can have some other form. Since most articles now have their own coordinates and relevant categories on Wikidata, it can be doable.

Community discussion

  • I agree with this idea. It's frustrating for me to have to manually place images into "category:Taken with Canon EOS 6D" when that information is already in the EXIF metadata, or "category:Photographs by Thennicke" when that's almost always true. Automating categorisation as much as possible reduces the workload and improves the completeness of categorisation for everybody. -- Thennicke (talk) 00:01, 14 November 2016 (UTC)[reply]
  • Thank you Aktron . I don't suggest anything unless I feel it can be enough specific, and it's because of that that I don't write this type of proposal myself, but we did target some specific issues here in the general framework of the need of a much more newbiee and user-friendly categorization interface. And there is so much to improve there... I don't know if "semantic" suggestion such as "tree in the description >> suggest category:trees" would work even for the most commons languages but some sort of suggestion based on geolocalization I'm sure can be successful. Most of the time with newbies even a slight improvement can catalyze a much better management later. I mean, the category they use are too generic in 99% of the cases, but still if they are less generic, our work of maintenance is much easier. --Alexmar983 (talk) 05:38, 14 November 2016 (UTC)[reply]
  • Note there is Jeffrey's Image Metadata Viewer, which guess photographer location, including street, street number, area and municipality. If we integrate this tool to Commons or Toolserver or Program something simmillar it can help us a lot. There might be also pair geo data with object groups and names in OpenStreetMap.--Juandev (talk) 20:24, 13 November 2016 (UTC)[reply]
  • The other possibilities how to automate this, would be to run a bot, who will read data in file name (some, in fact correctly set file names are File:main object, focus - i.e. Village name, church; or Plant name, part. From this you may propose to the user at least to cats: main and special - eg. cat:village name, cat:churhecs in Country/district; cat:plantname, cat: parts of this plant.--Juandev (talk) 20:24, 13 November 2016 (UTC)[reply]
  • The Commons Android app has some of this functionality. Categories are automatically suggested based on the image's title and coordinates, and the user can choose to select them or to manually search for categories instead. There are some issues that need to be smoothed out with our implementation, though (e.g. our 'nearby categories' suggestions don't work for some phones). Misaochan (talk) 06:22, 15 November 2016 (UTC)[reply]
  • Yes, the Commons Android app takes the coodinates from EXIF, retrieves the categories of nearby pictures, and suggests them to the uploader. This could be improved further if most geographical Commons categories had coordinates, but unfortunately very few categories have coordinates at the moment. Syced (talk) 02:59, 17 November 2016 (UTC)[reply]
That's the problem with commons, it's much less "smart" than it should be, basically wikidata-like smart. I see many proposal targeting in this direction, namely that could be solved if this architecture were already reality. But it's so hard to make commons users (and therefore the overall platform) to interact with wikidata or to embrace a "metadata mentality". Commons need some metadata literacy, IMHO. --Alexmar983 (talk) 07:05, 18 November 2016 (UTC)[reply]

Voting – Semi-automatic photo description and categorization

  1.   Support--Wesalius (talk) 06:32, 28 November 2016 (UTC)[reply]
  2.   Support, it should also the category of the location (e.g. city). And what should happen once the user confirms the nearest article? An article is not same as a category besides if there is an eponymous one for the article? Also please see my highly related suggestion: "Automated edit suggestions for articles' categories & WikiProjects" as these could be such "edit suggestions" (just for images on commons). --Fixuture (talk) 21:17, 29 November 2016 (UTC)[reply]
  3.   Support --Alexmar983 (talk) 04:01, 30 November 2016 (UTC)[reply]
  4.   Support Syced (talk) 06:57, 30 November 2016 (UTC)[reply]
  5.   Support --Mess (talk) 19:03, 30 November 2016 (UTC)[reply]
  6.   Support Ahm masum (talk) 17:07, 1 December 2016 (UTC)[reply]
  7.   Support Juandev (talk) 20:52, 1 December 2016 (UTC)[reply]
  8.   Support --Gestumblindi (talk) 21:24, 1 December 2016 (UTC)[reply]
  9.   Support Orgio89 (talk) 02:27, 2 December 2016 (UTC)[reply]
  10.   Support --Marianne Casamance (talk) 05:56, 2 December 2016 (UTC)[reply]
  11.   Support Draceane (talk) 09:49, 2 December 2016 (UTC)[reply]
  12.   Support MartinThoma (talk) 15:46, 2 December 2016 (UTC)[reply]
  13.   Support // Martin Kraft (talk) 23:40, 2 December 2016 (UTC)[reply]
  14.   Support --Tbennert (talk) 06:51, 5 December 2016 (UTC)[reply]
  15.   Support Muhraz (talk) 15:50, 6 December 2016 (UTC)[reply]
  16.   Support - If possible would be great. DPdH (talk) 20:51, 6 December 2016 (UTC)[reply]
  17.   Support -- Movses (talk) 21:53, 6 December 2016 (UTC)[reply]
  18.   Support --Assianir (talk) 07:35, 7 December 2016 (UTC)[reply]
  19.   Support --Geolina163 (talk) 08:36, 7 December 2016 (UTC)[reply]
  20.   Support--Kiril Simeonovski (talk) 08:40, 7 December 2016 (UTC)[reply]
  21.   Support nice idea — Rhododendrites talk \\ 06:26, 8 December 2016 (UTC)[reply]
  22.   Support Miniapolis 21:08, 8 December 2016 (UTC)[reply]
  23.   Support Useful function. Akela (talk) 21:40, 8 December 2016 (UTC)[reply]
  24.   Support --Arnd (talk) 13:35, 9 December 2016 (UTC)[reply]
  25.   Support Linie29 (talk) 14:15, 9 December 2016 (UTC)[reply]
  26.   Support --OrsolyaVirág (talk) 12:52, 10 December 2016 (UTC)[reply]
  27.   Support --Chrumps (talk) 03:38, 11 December 2016 (UTC)[reply]

  • Problem: There are the following buttons on each image on Commons: View | Edit | History | ☆ | More - Move

The five pointed star is for adding/removing to/from watchlist.

The Move button is from the RenameLink gadget. This gadget is default. It is accessible at Commons / Prefernces / Gadgets / RenameLink - commons:Special:Preferences#mw-prefsection-gadgets.

The whole page will load first and with about one or two secondz delay will load the button "More". I edit Commons quickly. I click on the page, then to the Edit, but meantime the buttons will move and instead of editing the page it will show the History of the page. (This behavior is on the Firefox 50.0 browser and on the Chromium 53. browser, but I think, it is not browser related.)

  • Who would benefit: Editors.
  • Proposed solution: Ideally it would be good to load the "More" button exactly at the same time as all other buttons.
  • More comments: It is possible to turn off the gadget in Preferences, but when it is default one, then it should behave normally.

Community discussion

Guessing the MediaWiki purposely lazy loads third party scripts/gadgets, in the event that some script performs an expensive initialization operation which would otherwise cause the browser to hang. Not ideal, no, but but probably the safer option. -FASTILY 00:47, 27 November 2016 (UTC)[reply]

@Fastily and Snek01: MediaWiki "lazy-loads" all scripts, in fact (no preference is given to core/extensions/gadgets). Page contents and styles are loaded first. But core/extensions have the ability to render things in PHP code, to avoid this effect of things moving around – that's why you don't see this issue e.g. with the Echo alerts/notices icons in the personal bar. The RenameLink gadget would need some support from MediaWiki – e.g. a configuration option to display a "Request move" menu option when the user is not allowed to "Move" a page, which the RenameLink gadget could take over (rather than displaying its own after the page loads, thus avoiding other menu items moving around). Matma Rex (talk) 15:52, 27 November 2016 (UTC)[reply]

See also "Improve the stability of the page while loading". Stevie is the man! Talk • Work 18:27, 29 November 2016 (UTC)[reply]

  1.   Oppose I'm not convinced this is a real problem that needs fixing. -FASTILY 07:01, 2 December 2016 (UTC)[reply]
  2.   Support --Kiril Simeonovski (talk) 08:41, 7 December 2016 (UTC)[reply]
  3.   Support Miniapolis 21:13, 8 December 2016 (UTC)[reply]

Tool for mass downloading files

  • Problem: Currently there is no easy way to download all pictures from a given category, which makes re-use of the files (and promotion of Wikimedia projects) much harder. A typical example are our picture competitions (POTY, WLE, WLM, ESPC, you name it): once the winning photos are placed in a separate category, it would be natural for the community or the media to just drop by and download them all with one click, preferably together with the automatically-generated attribution line ("Use this file" button) and perhaps also the description in a selected language. Yet, the only way to re-use the files in bulk is to download them by hand, resize them by hand and then copy the attribution and description by hand. I know of no automatic downloading plugin for web browsers that would work with Commons (think DownThemAll! and similar: they work great with most pages out there - except for Wikimedia Commons).
  • Who would benefit: Every Wikimedia Commons user who wants to re-use the files outside of the Wikimedia projects themselves: the media, people wanting to share the pictures through social media etc.
  • Proposed solution: Create a tool (app/applet/extension/external tool) that could download all pictures from a given category, and also download selected metadata: description in a given language and automatically-created attribution.

Community discussion

I'd have a few en:WP:BEANS concerns about such a tool being used in a way to crash the server? Courcelles 21:48, 9 November 2016 (UTC)[reply]
That seems unlikely. In any case, someone could already use something like wget to do mass-downloading. Legoktm (talk) 04:04, 10 November 2016 (UTC)[reply]

I think you're proposing something like the Collection extension, but for files? Legoktm (talk) 04:04, 10 November 2016 (UTC)[reply]

Something like Imker, but as an extention for MediaWiki? -- Freddy2001 talk 09:14, 10 November 2016 (UTC)[reply]
@Freddy2001 and Legoktm:, yeah, something like Collection extension or Imker (thanks, I didn't know it existed), but with the ability to download metadata together with the picture. It doesn't have to be an extension, and external tool or a script would work just as well. Though making it part of MediaWiki would probably be a cleaner solution. Halibutt (talk) 14:34, 10 November 2016 (UTC)[reply]
Just downloading metadata should not be too hard, but storing it in a machine readable way requires the metadata to be machine readable on commons in the first place... I am assuming you are referring to metadata such as author, license, categories? --McZusatz (talk) 14:59, 20 November 2016 (UTC)[reply]

I generally like the concept. Whatever is technical development might be, I think we should go that way. --Alexmar983 (talk) 05:06, 11 November 2016 (UTC)[reply]

I've written a standalone Java CLI tool that does this. If there's enough interest for something like this, then ping me and I'll release it and roll a GUI into it. -FASTILY 20:42, 13 November 2016 (UTC)[reply]
@Fastily:, please do! Halibutt (talk) 22:25, 16 November 2016 (UTC)[reply]
I just noticed that McZusatz has already written and released a tool, Imker, which makes it easy to perform batch downloads. Holding off on getting started for now, since I'll be duplicating my efforts 😛-FASTILY 21:12, 17 November 2016 (UTC)[reply]

Havent seen this problem. Thank you to take it on light. Yes I agree - we collect open files on our repository, but we create barriers for reuse. This problem should be definitelly removed.--Juandev (talk) 16:52, 14 November 2016 (UTC)[reply]

BTW Platonides had developed the "catdown" tool which made this a matter of a couple clicks (by producing a list of URLs and providing the poor Windows users with a copy of wget). Nemo 08:17, 15 November 2016 (UTC)[reply]

@Nemo bis:, do you mean this catdown? It seems to be... errr... down. Halibutt (talk) 22:25, 16 November 2016 (UTC)[reply]

I've recently written a quick shell script to do this. You can find it here: https://github.com/aucuparia/commons-category-downloader/. It queries the API for URLs of files in a given category and then fetches them using wget. Very easy to use, just run it like this: ./commons_category_downloader.sh "Name of category". It doesn't fetch meta- and attribution data though. Feel free submit pull requests to fix that. Ceteron (talk) 14:27, 19 November 2016 (UTC)m[reply]

There seems to be a plethora of such tools :-D I’m also aware of
Jean-Fred (talk) 15:30, 28 November 2016 (UTC)[reply]
I quickly wrote down current options at Commons:Download_tools. Jean-Fred (talk) 16:19, 28 November 2016 (UTC)[reply]

Voting – Tool for mass downloading files

  1.   Support--Wesalius (talk) 06:45, 28 November 2016 (UTC)[reply]
  2.   Support Sadads (talk) 14:48, 28 November 2016 (UTC)[reply]
  3.   Oppose Not a good use of developer time; existing solutions work great -FASTILY 09:22, 29 November 2016 (UTC)[reply]
  4.   Oppose Use an existing tool, or make a tool to do it, but let's not use the WMF team for this. We have much more important improvements to pursue. Stevie is the man! Talk • Work 18:35, 29 November 2016 (UTC)[reply]
  5.   Oppose There are already tools for this. --Fixuture (talk) 21:18, 29 November 2016 (UTC)[reply]
  6.   Support--Strainu (talk) 09:29, 30 November 2016 (UTC)[reply]
  7.   Support--Harvinder Chandigarh (talk) 07:03, 2 December 2016 (UTC)[reply]
  8.   Support Existing tools are not well known, so this may be as simple as improving links to them (and/or bringing them in-house). But mass download might be quite useful for reusers. Thanks. Mike Peel (talk) 23:42, 2 December 2016 (UTC)[reply]
  9.   Support Henryk Borawski (talk) 03:41, 3 December 2016 (UTC)[reply]
  10.   Oppose There are already tools for this. --Steinsplitter (talk) 10:02, 3 December 2016 (UTC)[reply]
  11.   Support--Ranjithsiji (talk) 05:52, 4 December 2016 (UTC)[reply]
  12.   Support — Hmxhmx 18:21, 5 December 2016 (UTC)[reply]
  13. Weak   Support Muhraz (talk) 15:51, 6 December 2016 (UTC)[reply]
  14.   Support - Maybe as simple as improving and promoting existing tools. DPdH (talk) 20:54, 6 December 2016 (UTC)[reply]
  15.   Support --Kiril Simeonovski (talk) 08:42, 7 December 2016 (UTC)[reply]
  16.   Oppose already exists per above — Rhododendrites talk \\ 06:26, 8 December 2016 (UTC)[reply]
  17.   Support Miniapolis 21:15, 8 December 2016 (UTC)[reply]
  18.   Support Swiss GLAMs have required such a function; presently they upload pictures to Commons, and they make the metadata and thumbnail pictures available for download in a Zip file on the Swiss Open Government Data Platform. The metadata contains links to high-resolution pictures on Commons. If Commons provided such a batch download function for the metadata and thumbnail pictures, the GLAMs could save a step in their data publication workflow. Obviously, this should be an easy-to-use function built into the Wiki interface that can easily be linked to and not some obscure script only insiders know about. The only doubt I have is with regard to the future transfer of the Commons metadata to Wikibase: Maybe we shouldn't put too much effort into supporting this functionality on the present Commons templates, but wait for the data transfer to Wikibase. --Beat Estermann (talk) 20:22, 9 December 2016 (UTC)[reply]
  19.   Support --OrsolyaVirág (talk) 12:53, 10 December 2016 (UTC)[reply]
  20.   Oppose There are already apps and browser add-ons for grabbing images or all content from directory trees or even whole sites. WMF should not waste time reinventing this wheel.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:57, 11 December 2016 (UTC)[reply]

Upload wizard for uploading artwork

  • Problem: new GLAMs want to upload but are confused by upload wizard
  • Who would benefit: GLAMs, and users trying to find metadata, and metadata cleanup
  • Proposed solution: make uploads of artwork or information template possible in upload wizard, or direct GLAMs to those tools that allow these templates

Community discussion

@Slowking4: Can you please elaborate how and why people "are confused by upload wizard"? Understanding the underlying problems in Upload Wizard better will also allow to find and discuss better solutions. Thanks! --AKlapper (WMF) (talk) 09:40, 8 November 2016 (UTC)[reply]
Could you clarify how the Campaign namespace and/or GLAM Wiki Toolset is not a sufficient answer to this issue ? Léna (talk) 11:46, 8 November 2016 (UTC)[reply]
this is a perennial issue [1], [2] GLAMs are constantly wondering how to upload and the help is tl;dr. GLAM wiki toolset is for experts, not ready for newbies. to the extent they do not know about pattypan, (and how would they) they upload with wizard and the metadata is wrong, i.e. [3]; [4]; [5].
we need a better UX for uploaders, there is little help for small or medium size mass uploads. the assumption is everyone is uploading own work, or they are aware of the constantly changing tools. GLAM wikitoolset is designed for remote upload, and many GLAMs have metadata in spreadsheet, and images on harddrive. Slowking4 (talk) 20:09, 8 November 2016 (UTC)[reply]

@Slowking4:, are you aware of Commons:Pattypan? It's a tool designed specifically for small GLAM institutions, it's easy to use and works great with the Artwork template. Halibutt (talk) 11:31, 9 November 2016 (UTC)[reply]

  • just a little. apparently no one else is. how would you suggest incorporating this tool into the upload "guidance"? there is an ocean of existing information template that needs to get edited into artwork. could you please stop the tide rising? Slowking4 (talk) 12:09, 9 November 2016 (UTC)[reply]
I definitely agree of this proposal. I am one of the main photographers of Old masters artpieces on Commons (I am also in the examples listed), and more frequently my images, as they come out from upload wizard, are tagged as inappropriate, as some users confuse the author field that comes out (myself, as the author of the shot) as the author of the artpiece (someone was arguing how I could have painted as Seurat...). I always use a correct filename and categories, but sometimes it sounds not enough. Uploading is already a big pain and loss of hours and hours, we need something easy and incorporated in the main upload tools. As a start, it would helpful if the "author" field could be renamed or qualified as the "photographer" name. --Sailko (talk) 23:19, 10 November 2016 (UTC)[reply]
  • I did not have chance to use Commons:Pattypan tool yet and I hope that it might answer many issues, but our default upload interface is Upload Wizard and it should handle infobox templates other than {{Information}}. Commons uses several standard infobox template, see c:Commons:Infobox templates, but Upload Wizard supports only one. I think it should definitely start supporting Artwork and Book infoboxes. --Jarekt (talk) 14:02, 16 November 2016 (UTC)[reply]
  • "GLAMs are constantly wondering how to upload and the help is tl;dr.". I don't personally dispute the complexity of the upload tools, but at the same time I do have some concern with the wording of this proposal.. If you are a GLAM, documentation should never be short, and you should always be willing to read it, no matter what. These should not be some sort of PR-folks driven uploads, but require expertise and effort. As multichill often denotes, he spends 90% of his time analyzing and preparing both the new data and the data already in the wikis. If you TL;DR the tools, then I'm not too confident by your mass contribution honestly. Anyway, these are highly specific workflows, and I suggest further strengthening the Pattypan tool and project for that purpose. Not sure if doing that from the community tech team is a good idea. Instead i'm looking at this GLAM and GLAMwiki.org pages and my mind goes... no wonder people are not finding what they need. —TheDJ (talk • contribs) 11:23, 23 November 2016 (UTC)[reply]
  • Can you elaborate on what exactly would be required to support this proposal? Is this just about supporting the {{Artwork}} template (which is phab:T51443)? Matma Rex (talk) 18:26, 25 November 2016 (UTC)[reply]
  • I think the "GLAM" should be read here as "Wikimedian acting in good faith on behalf of or despite a GLAM" (WAINGFOBOODAG for short), as there are in fact very few GLAMs who ever dabble in Wikimedia projects except for the large institutions. Most of the world's art is not in those institutions, however, but spread all over the globe, including private and semi-public collections who think we are going to steal their stuff away. Asking people to wait for structured data to save the day is silly, because these types of sources will never have structured data and it is up the WAINGFOBOODAG to do this on upload. Jane023 (talk) 15:38, 30 November 2016 (UTC)[reply]
    • (killing me softly with acronyms) yes, as we migrate practice to smaller GLAMs, we need friendlier tools, so they can be a part of ordinary practice. you should not have to know java or python to do uploads, or have to know the secret pathways. the big GLAMs made all the mistakes so the smaller volunteers do not have to. Slowking4 (talk) 19:45, 1 December 2016 (UTC)[reply]
  • Hi, I'm one of the users whose discussion you linked to. For me, the guidelines weren't "TL;DR"; I actually spent a lot of time reading about ways to upload (on and off Wikipedia), and I wasn't sure what the best way to structure the data was (especially since I had only uploaded through the upload wizard before). There are some contradictory expectations; Commons:GLAM/Getting_Started suggests that GLAM people will want to get help from another Commons user, as does the Commons:Batch_uploading page. But Commons:Guide_to_batch_uploading gives specific instructions on how to do it, and a user who has access to the files and the metadata can manage it, if their excel skills are up to the task. I would love to see examples on the Guide to Batch Uploading page of batches that were uploading with really nice metadata; I've seen some institutions that provide their own copyright template and some that even link within the template to the item's URL on the institution's site (like some of the NYPL uploads, those are cool).Metawiki seems to recommend institution templates, but the community consensus when I asked about it was that I should just use the pre-existing artwork and photograph templates. I would love to see a better uploading UI/UX, and more consistent advice to GLAMs. Rachel Helps (BYU) (talk) 18:42, 1 December 2016 (UTC)[reply]
    • thanks for the feedback, i really did not mean that the people in the examples did not "read" the documentation, merely that it is so prolix and detached from ordinary UX as to be confusing and unhelpful. i would encourage you to give more feedback to the design teams, as they often get stuck at "things work for me". Slowking4 (talk) 19:40, 1 December 2016 (UTC)[reply]

Voting – Upload wizard for uploading artwork

  1.   Support--Shizhao (talk) 02:37, 28 November 2016 (UTC)[reply]
  2.   Oppose Wait till structured data on Commons is rolled out, we will treat all files differently then, including artworks. That will require a very different UploadWizard that will need full attention from developers. I have worked with Pattypan and it's pretty good for the current situation IMHO. Agree with the argumentation by TheDJ above. Spinster (talk) 14:58, 29 November 2016 (UTC)[reply]
  3.   Support We do not have to wait for structured data on Commons or make anything complicated here, just an option in upload wizard to use c:Template:Artwork instead of c:Template:Information as the basic infobox. I would also expand it to allow c:template:Book for books and maybe c:template:Art photo for sculptures (they require information about author+copyrights of the sculpture and photograph). One implementation would be ask users about what type of the work it is: photograph, painting (or other 2D work), photograph of a sculpture, scan of a book, scan of a map, recording, etc. Than provide most appropriate infobox template. --Jarekt (talk) 18:39, 29 November 2016 (UTC)[reply]
  4.   Support I totally support structured data, but I see also improvement on this issue that can be done now. We're talking about important files form the cultural point of view, they deserve some attention.--Alexmar983 (talk) 04:08, 30 November 2016 (UTC)[reply]
  5.   Support Yes, anything to help User:Sailko input better metadata. I have a kludge built by User:1Veertje that helps but this lack of functionality in the default upload wizard has been a serious blocking reason for me to undertake more than one artwork upload at a time. Pattypan is sweet, but not the answer. I also hate that I can't make artwork uploads from my phone when I am in a museum. Jane023 (talk) 12:41, 30 November 2016 (UTC)[reply]
  6.   Support --β16 - (talk) 15:23, 1 December 2016 (UTC)[reply]
  7.   Support especially if it helps GLAMs upload their metadata more consistently. See my comment above. Rachel Helps (BYU) (talk) 18:42, 1 December 2016 (UTC)[reply]
  8.   Support -- CFynn (talk) 05:32, 2 December 2016 (UTC)[reply]
  9.   Support --jdx Re: 08:51, 3 December 2016 (UTC)[reply]
  10.   Support --Yiyi (talk) 16:12, 3 December 2016 (UTC)[reply]
  11.   Support --Ranjithsiji (talk) 05:53, 4 December 2016 (UTC)[reply]
  12.   Support -- Marcus Cyron (talk) 12:10, 4 December 2016 (UTC)[reply]
  13.   Support Blue Rasberry (talk) 19:10, 6 December 2016 (UTC)[reply]
  14.   Support --Assianir (talk) 07:35, 7 December 2016 (UTC)[reply]
  15.   Support --Geolina163 (talk) 08:37, 7 December 2016 (UTC)[reply]
  16.   Support --Kiril Simeonovski (talk) 08:42, 7 December 2016 (UTC)[reply]
  17.   Support - DPdH (talk) 14:35, 7 December 2016 (UTC)[reply]
  18.   Support Miniapolis 21:17, 8 December 2016 (UTC)[reply]

Use computer vision to propose categories

  • See also: w:Computer_vision#Applications
  • Problem: There are many uncategorized images
  • Who would benefit: People who benefit from categories
  • Proposed solution: Use computer vision (like Google Goggles or an open source equivalent) to guess what each uncategorized picture shows (monkey? car? bridge? etc). Then have a game (similar to the Wikidata game which has 23 million improvements to its record) that asks people to verify whether the picture is what the computer thinks. If confirmed, add the category to that picture. Once it is in the right high-level category, chances are much higher that a someone with an interest in the field will further classify it (for instance from Monkey to the exact species).
  • Phabricator tickets:

Community discussion

  • I'm skeptical about the cost/benefit ratio of such an undertaking; this will clearly require a *massive* amount of developer resources and an enormous training set, and may only amount to many vague and incorrect categorizations. -FASTILY 01:54, 22 November 2016 (UTC)[reply]
Yes, developing computer vision would require massive development. But embedding an existing computer vision library requires like one day of work. Syced (talk) 05:57, 24 November 2016 (UTC)[reply]
I think you are vastly overestimating the abilities of existing freely available computer vision libraries; these aren't the sort of magic bullet you're claiming them to be. -FASTILY 01:30, 25 November 2016 (UTC)[reply]
  • One of previous proposal suggests to use description and geolocalization to propose categories. At the moment that would be enough for me. But I welcome every analysis of pros and cons for the best strategy. Also, before some wikidata game, I would also like to see a real metadata architecture, as emerged in previous discussions. That's why I guess this may not be priority.--Alexmar983 (talk) 02:46, 22 November 2016 (UTC)[reply]
My proposed solution does not require any new metadata architecture. Commons' existing categories system is already enough. Syced (talk) 05:59, 24 November 2016 (UTC)[reply]
  • There is a similar proposal "Search images by OCR" at Commons [6]. I commented there that the AI/machine vision community might be interested in this challenge and that rather than expending developer effort we may just need to develop some infrastructure and invite them in. We would need guidelines and a branch of our category tree for experimental category creation and additions so that massive AI-generated updates can be evaluated before we integrate them into our working categories. I think an online discussion or even a conference is the next step here.--ArnoldReinhold (talk) 16:12, 23 November 2016 (UTC)[reply]
Well spot, actually I wrote the OCR one too. Your comment there tipped me to write this new one abour computer vision, because the goal (and underlying technology) is different. We are not talking about automated mass dumping here, but rather assisted category addition. Does this picture really contain a dog? -> Yes -> Tag as "Dog". In that scenario, tagging as "Dog" is not a controversial edit, right? Cheers! Syced (talk) 05:54, 24 November 2016 (UTC)[reply]

Some of the Deep learning algorithms are quite successful at tagging image content. Google hired come of the top scientists in this field and is providing services in this field, like https://cloud.google.com/vision/ . But Open source alternatives exist see for example http://blog.algorithmia.com/open-source-deep-learning-algorithm-roundup/ . Computer vision classifier algorithm work in 2 stages: training stage takes massive amount of tagged images and some powerful hardware and software. Once you build your classifiers (rules for telling things apart) you can use them to classify and tag images with little effort. I think we should build a tool to run some of the algorithms mentioned here on unclassified commons images. We can automatically add categories like c:Category:Media needing categories: possibly depicting automobiles which would then be moved (using cat-a-lot) by volunteers to c:Category:Media needing categories: depicting automobiles which would be a subcategory or c:category:Automobiles. Similarly we could add categories like: people, animals, churches, airplanes, etc. --Jarekt (talk) 04:15, 26 November 2016 (UTC)[reply]

  • I've been doing some small tests with this. I downloaded a few thousand uncategorised images and a few thousand portraits and try to predict portraits in the uncat files. I Have some issues with mass testing (and mass downloading and soon some hardware issues), and should continue my work, but the first results on such a small set seem to indicate that for simple questions such as: "is this a portrait" we can get good results (in this set ca. 95% correct, with more images that likely improves). Validating images on such simple queries is easy to do by hand. My main question now is: What are the use cases really? Do we want to split images based on simple information such as portrait to later use this to validate whose portrait it may be? The use case as explained by Jarek is quite easy and can be done by retraining the final layers of existing imageNet classifiers (see this tensorflow page). If anybody is interested in thinking about a few (easy) use cases to prove the value of image recognition I'm happy to discuss those. Basvb (talk) 15:43, 26 November 2016 (UTC)[reply]
    • I've got some results now. I was able to classify roughly 2000 unseen images from the uncategorised images. The results can be seen at this page, it is a little buggy with the high amount of thumbnails, but when you sort on the probability you can see that there is definitely some learning in there. This example was based on only 2000 training examples, ca. 1000 for each class, where the potraits were taken from the Category:portraits and the non-portraits are 1000 images from the uncategorised images where I removed portraits and portrait-like images (a little issue with portraits is that the definition is a bit fuzzy, e.g. is a picture of somebody in a room of others also a portrait?). From here it should be easy to expand this to some better example cases and improve upon the structure (decide which classes interest us, improve downloading, etc.). Feedback very welcome. Basvb (talk) 14:34, 29 November 2016 (UTC)[reply]
  • Generally, I am leery of any idea/proposal that tends to automate the setting or creation of categories. There's just too much that can go wrong, too easily. However, if this is to be a separate process that fills review lists with files according to particular tags set by the computer vision tool, and human editor judgment is involved with the actual categorizing of the files, I can see the value. But... getting the computer vision part right seems very long-termish and thus maybe not well-suited for the WMF team to pursue in the next year. Stevie is the man! Talk • Work 17:47, 29 November 2016 (UTC)[reply]
    The computer vision part doesn't have to take a year. See the example in my command which was roughly 1 day's work and is pretty good already in classifying portraits/pictures of humans. Basvb (talk) 19:25, 29 November 2016 (UTC)[reply]
    OK, given this is true, it only takes care of part of my concerns. But then, integrating the computer vision in will take much longer than the 1 day's work. There's proof of concept, and then there's software development. At the end of the day, this process should fill review lists like I say above, not do any actual categorization. Stevie is the man! Talk • Work 23:03, 29 November 2016 (UTC)[reply]

Voting – Use computer vision to propose categories

  1. People have been working on this in the past already - see categorisation_of_Commons_media_using_computer_vision. I   Support --Wesalius (talk) 06:43, 28 November 2016 (UTC)[reply]
  2.   Support I've tried CV on commons myself (although only for pattern recognition) and it proved quite useful. Having a tool that any user can run could significantly improve the categorization on commons.--Strainu (talk) 10:19, 28 November 2016 (UTC)[reply]
  3.   Support. I think something about it was on the AI session on Wikimania in Mexico, ping とある白い猫, user:Ladsgroup (I haven't attended that one though, only heard about it from Ата). Flickr has this feature for tags AFAIK and that is definitely a good thing to copy. --Base (talk) 17:57, 28 November 2016 (UTC)[reply]
  4.   Support but note that this is a hard problem. — Jeblad 01:36, 29 November 2016 (UTC)[reply]
  5.   Support Vadimzer (talk) 08:26, 29 November 2016 (UTC)[reply]
  6.   Support - But note that we should also have ideas on how to use this. If we have some machine learning bot propose basic categories without anybody looking after those categories afterwards it would not make sense to invest in this. Basvb (talk) 12:48, 29 November 2016 (UTC)[reply]
  7.   Support I've seen software demoed that was trialled on millions of images from the British Library. Aside from being able to find ships etc I suspect we could use this to find near dupes. I've jut been manually going through the commons category churches and if you search we often have a similar image of the same church. An AI should be able to do this much more efficiently. WereSpielChequers (talk) 17:03, 29 November 2016 (UTC)[reply]
  8.   Neutral per my comments above. There's value if developed in a responsible manner, but it seems too long-termish for this survey (projects to be mostly completed in the next year). Stevie is the man! Talk • Work 17:47, 29 November 2016 (UTC)[reply]
  9.   Oppose, takes too much precious development time which should be used for more pressing issues. Also please see my highly related suggestion: "Automated edit suggestions for articles' categories & WikiProjects" as these could be such "edit suggestions" (just for images on commons). --Fixuture (talk) 21:21, 29 November 2016 (UTC)[reply]
  10.   Support the improving in the categorization is clearly a Zeitgeist here. I support all proposals, I let the team decide which are the simplest ones to support. At the moment, I'm happy with whatever we can obtain. Whatever are the issues or funnels that can be created by an unbalanced schedule, I think they are not worse than not progressing on the issue at all.--Alexmar983 (talk) 04:15, 30 November 2016 (UTC)[reply]
  11.   Support for portraits as a first step. We have a working proof-of-concept already, and classifying all portraits will already slash a good portion of the uncategorized pictures. Tasks remaining: Scale the POC into a daily(monthly?) batch on all uncategorized images, and create a gamification UI à la Wikidatagame. Syced (talk) 07:10, 30 November 2016 (UTC)[reply]
  12.   Support --Micru (talk) 12:26, 30 November 2016 (UTC)[reply]
  13.   Support --Mess (talk) 19:04, 30 November 2016 (UTC)[reply]
  14.   Support Ainali (talk) 07:24, 1 December 2016 (UTC)[reply]
  15.   Support Categorization is sometime tough and not good experience in commons so computor robotic help will boost things a lot. Orgio89 (talk) 02:30, 2 December 2016 (UTC)[reply]
  16.   Support --Marianne Casamance (talk) 05:58, 2 December 2016 (UTC)[reply]
  17.   Support Draceane (talk) 09:49, 2 December 2016 (UTC)[reply]
  18.   Support I wanted to make a bot for that as I am a Computer Vision / Machine Learning researcher. However, it was too much work due to the strange category system. 2016_Community_Wishlist_Survey/Categories/Search#Built-in_CatScan would be a first step to fix the category system. MartinThoma (talk) 14:55, 2 December 2016 (UTC)[reply]
  19.   Support as a web-app, with let real user to save page. Idea: let show it by block of pictures of the same detected categories (like a wall) at the same time and not one by one --Framawiki (talk) 20:17, 2 December 2016 (UTC)[reply]
  20.   Support - Best regards, Kertraon (talk) 11:41, 4 December 2016 (UTC)[reply]
  21.   Support -- T.seppelt (talk) 16:26, 4 December 2016 (UTC)[reply]
  22.   Neutral per Stevie is the man. --Tryptofish (talk) 22:20, 5 December 2016 (UTC)[reply]
  23.   Neutral I fail to see how adding a file to a meta category like Portrait is much different from uncategorized? Nobody ever searches through there, hoping to find Portrait of XYZ.JPG Finding duplicates isn't that much of a biggy either, currently we have space to spare. --Hedwig in Washington (talk) 03:32, 6 December 2016 (UTC)[reply]
  24.   Support -- Movses (talk) 21:46, 6 December 2016 (UTC)[reply]
  25.   Support --Assianir (talk) 07:35, 7 December 2016 (UTC)[reply]
  26.   Support --Kiril Simeonovski (talk) 08:44, 7 December 2016 (UTC)[reply]
  27.   Support --Geolina163 (talk) 08:48, 7 December 2016 (UTC)[reply]
  28.   Support just because it sounds interesting. Matěj Suchánek (talk) 15:40, 7 December 2016 (UTC)[reply]
  29.   Support if feasible, although I can imagine both serious privacy issues (were should it look for photos of identifiable people?) and potential problems with (remember how Google identified two African Americans as gorillas), thus we need to be extra careful with this — NickK (talk) 18:35, 7 December 2016 (UTC)[reply]
  30.   Support — Rhododendrites talk \\ 06:27, 8 December 2016 (UTC)[reply]
  31.   Support Miniapolis 21:19, 8 December 2016 (UTC)[reply]
  32.   Support --Psychoslave (talk) 09:51, 9 December 2016 (UTC)[reply]
  33.   Support if applying existing solutions, developing brand new solutions might be too time consuming here --Jarekt (talk) 13:21, 9 December 2016 (UTC)[reply]
  34.   Support --Arnd (talk) 13:36, 9 December 2016 (UTC)[reply]
  35.   Support OrsolyaVirág (talk) 12:46, 10 December 2016 (UTC)[reply]
  36.   Neutral I think this sounds good in principle and I would fully support this if it's proven that the categories can be added with relative reliability, but I don't think the tools are capable of that yet. Reguyla (talk) 18:26, 10 December 2016 (UTC)[reply]
  37.   Support -- Tinss (talk) 17:44, 11 December 2016 (UTC)[reply]

View slider to compare two images

  • Who would benefit: Anyone wishing to illustrate certain differences in similar images
  • Proposed solution: no idea
  • Phabricator tickets:

Community discussion

Nifty, but I can't see this being so widely used as to warrant inclusion in core MediWiki -FASTILY 00:41, 27 November 2016 (UTC)[reply]

Sad that you have so little imagination that you can't think of any other examples, because I can think of so many, such as before and after "nose jobs" and other facial work, before and after photos of burned forests, comparison of bird plumage in various seasons, etc. Jane023 (talk) 12:46, 30 November 2016 (UTC)[reply]

Since there is no proposed solution, perhaps this should be archived. Stevie is the man! Talk • Work 17:31, 29 November 2016 (UTC)[reply]

The solution is for the developer, not the voter to decide. Jane023 (talk) 12:46, 30 November 2016 (UTC)[reply]
That seems to go against the spirit of this process, at the very least. Proposers are required to at least attempt to explain a solution. Stevie is the man! Talk • Work 18:42, 30 November 2016 (UTC)[reply]

Voting – View slider to compare two images

  1.   Oppose, I agree with User:Fastily. --Fixuture (talk) 21:23, 29 November 2016 (UTC)[reply]
  2.   Support as proposer, Jane023 (talk) 12:47, 30 November 2016 (UTC)[reply]
  3.   Oppose -- there's no proposed solution. Stevie is the man! Talk • Work 18:42, 30 November 2016 (UTC)[reply]
  4.   Neutral Photo comparison software would be interesting, but I'm not sure how useful this could be. There is http://pdiff.sourceforge.net/ though, which is FOSS (Free, Open-Source Software) and released under the GNU GPL. SamanthaNguyen (talk) 01:11, 1 December 2016 (UTC)[reply]
  5.   Oppose per my reasoning above -FASTILY 07:08, 2 December 2016 (UTC)[reply]
  6.   Neutral--Ranjithsiji (talk) 03:30, 4 December 2016 (UTC)[reply]
  7.   Oppose per Fastily. Love the idea, tho. --Hedwig in Washington (talk) 03:33, 6 December 2016 (UTC)[reply]
  8.   Oppose The explanation of the problem indicates to something reasonable but there is no proposed solution. It is also a big question why do we really need to use such comparison.--Kiril Simeonovski (talk) 08:47, 7 December 2016 (UTC)[reply]
  9.   Oppose, until a feasible solution is proposed. Miniapolis 21:22, 8 December 2016 (UTC)[reply]
  10.   Support nice idea and useful feature --Dvdgmz (talk) 20:49, 10 December 2016 (UTC)[reply]

VisualFileChange category processing improvement

  • Problem: VisualFileChange can load files from a specified category, but don't have any category-related functions. To add/change/delete categories for the loaded files, you need to use "append any text" & "custom replace" functions and play with text patterns.
  • Who would benefit: Commons users trying to sort out overcrowded categories.
  • Proposed solution: add some new "action" functions to the gadget ("Add/change/delete category").
  • Phabricator tickets:

Community discussion

Hi Djadjko, just a heads-up that I've moved your proposal to the Commons category. -- DannyH (WMF) (talk) 16:15, 22 November 2016 (UTC)[reply]

Voting – VisualFileChange category processing

  1.   Support --Jarekt (talk) 18:40, 29 November 2016 (UTC)[reply]
  2.   Support --Alexmar983 (talk) 04:17, 30 November 2016 (UTC)[reply]
  3.   Support --Hedwig in Washington (talk) 03:35, 6 December 2016 (UTC)[reply]
  4.   Support--Assianir (talk) 07:37, 7 December 2016 (UTC)[reply]
  5.   Support --Kiril Simeonovski (talk) 09:33, 7 December 2016 (UTC)[reply]
  6.   Support Miniapolis 21:23, 8 December 2016 (UTC)[reply]
  7.   Support --Jarekt (talk) 13:23, 9 December 2016 (UTC)[reply]
  8.   Support --Arnd (talk) 13:36, 9 December 2016 (UTC)[reply]
  9.   Support VFC is an awesome tool but this would be a very welcome improvement. Reguyla (talk) 18:36, 10 December 2016 (UTC)[reply]

Allow hiding chosen versions of images on File page

  • Problem: Lists of versions are very frequently too long, current version usually is better than previous ones, some of previous versions may be inadequate.
  • Who would benefit: Anyone.
  • Proposed solution: Option allowing hiding thumbnails of chosen versions of images or except first one and last one. Available for logged in uploaders of the first version. Date/Time, Dimensions, User and Comment could remain or be lumped into one field, separated by semicolons or other characters. Or removed.

Community discussion

Earlier community discussion and endorsements

@Darekk2: Hi, please could you link to 2 or 3 example files, so that everyone can better understand the problem you're describing? Thanks. Quiddity (WMF) (talk) 20:08, 13 November 2016 (UTC)[reply]

Kępa Wieloryb.jpg, Kępa Wieloryb - mapa.png Darekk2 (talk) 23:27, 13 November 2016 (UTC)[reply]
Perhaps hiding all but the last six versions by default, with a "show all" link. This would keep pages shorter and quicker loading without making the info unavailable. Bcharles (talk) 17:06, 15 November 2016 (UTC)[reply]
  • It is a minor and cosmetic annoyance, but yes showing all images in version history can make file page unappealing. We really only care for the last version. Maybe an official gadget that allow people to hide all but chosen number of older file versions. --Jarekt (talk) 14:09, 16 November 2016 (UTC)[reply]
  • Personally I like to see previous versions, to understand the history of the file. For instance if a label has been cropped out, that label might provide some information. But when there are more than 10 revisions a scrollable or paged UI might be an improvement indeed. Cheers! Syced (talk) 02:56, 17 November 2016 (UTC)[reply]

I don't think this should be implemented. Administrator can already hide revisions, and this ability should remain limited to them. Instead, like Bawolff says, we should paginate the lists better. On files like c:File:07L 2010 5day.gif (with 84 revisions) you can see we paginate at 50, but that is still overwhelming. I submitted a patch to do this: https://gerrit.wikimedia.org/r/323547 Matma Rex (talk) 17:08, 25 November 2016 (UTC)[reply]

Voting – Hiding chosen versions of images on File page

  1.   Oppose solution already implemented by Matma Rex seems sufficient.--Jarekt (talk) 18:43, 29 November 2016 (UTC)[reply]
  2.   Oppose per Jarekt. Also, this is seemingly too cosmetic to submit to the WMF team. Stevie is the man! Talk • Work 18:52, 29 November 2016 (UTC)[reply]
  3.   Oppose per Jarekt -FASTILY 07:08, 2 December 2016 (UTC)[reply]
  4.   Oppose Not needed, the thumbs don't bite. --Hedwig in Washington (talk) 03:37, 6 December 2016 (UTC)[reply]
  5.   Oppose As pointed out above, the problem seems sufficiently resolved.--Kiril Simeonovski (talk) 09:35, 7 December 2016 (UTC)[reply]
  6.   Oppose Not needed. Miniapolis 21:25, 8 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Commons&oldid=24927786"