Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Commons

< Community Wishlist Survey 2016
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]