Community Wishlist Survey 2016/Categories/Commons

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Community Wishlist Survey 2016

Commons
21 proposals, 179 contributors, 344 support votes


Go-previous.svg Citations  •  Editing Go-next.svg


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[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! TalkWork 19:01, 29 November 2016 (UTC)Reply[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[reply]

Voting – Backup of Commons files

  1. Support Support. Scary thing, the current state of affairs, actually. --Base (talk) 18:16, 28 November 2016 (UTC)Reply[reply]
  2. Support 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[reply]
  3. Support Support per Fixuture --Hasenläufer (talk) 16:38, 6 December 2016 (UTC)Reply[reply]
  4. Support Support Strong support, a backup copy is necessary --β16 - (talk) 15:26, 1 December 2016 (UTC)Reply[reply]
  5. Support Support --Gestumblindi (talk) 21:26, 1 December 2016 (UTC)Reply[reply]
  6. Support Support Ankry (talk) 23:24, 1 December 2016 (UTC)Reply[reply]
  7. Support Support Libcub (talk) 02:23, 2 December 2016 (UTC)Reply[reply]
  8. Neutral 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[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[reply]
  9. Support Support Data is the treasure, we can't lose them.--Nachosan (talk) 00:28, 4 December 2016 (UTC)Reply[reply]
  10. Support Support --Ranjithsiji (talk) 05:47, 4 December 2016 (UTC)Reply[reply]
  11. Support Support--Molgreen (talk) 06:05, 4 December 2016 (UTC)Reply[reply]
  12. Support Support: Useful. Best regards, Kertraon (talk) 11:27, 4 December 2016 (UTC)Reply[reply]
  13. Support Support--Praveen:talk 12:59, 5 December 2016 (UTC)Reply[reply]
  14. Support 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[reply]
  15. Support Support Lbertolotti (talk) 00:44, 6 December 2016 (UTC)Reply[reply]
  16. Strong support Strong support Highest priority of all proposals. Yikes! --Hedwig in Washington (talk) 03:41, 6 December 2016 (UTC)Reply[reply]
  17. Support Support any necessary improvements here. If backups aren't being currently done, that's awful. Stevie is the man! TalkWork 13:45, 6 December 2016 (UTC)Reply[reply]
  18. Support Support --Kiril Simeonovski (talk) 09:35, 7 December 2016 (UTC)Reply[reply]
  19. Support Support - DPdH (talk) 19:42, 7 December 2016 (UTC)Reply[reply]
  20. Support Support, to keep images from being deleted by glitches. ----DanTD (talk) 20:55, 7 December 2016 (UTC)Reply[reply]
  21. Strong support 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[reply]
  22. Strong support 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[reply]
  23. Strong support 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[reply]
  24. Strong support 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[reply]
  25. Support Support Miniapolis 21:27, 8 December 2016 (UTC)Reply[reply]
  26. Support Support --OrsolyaVirág (talk) 12:47, 10 December 2016 (UTC)Reply[reply]
  27. Support Support --Cavarrone (talk) 10:07, 11 December 2016 (UTC)Reply[reply]
  28. Support Support --Plagiat (talk) 17:17, 11 December 2016 (UTC)Reply[reply]
  29. Support Support --Soluvo (talk) 00:28, 12 December 2016 (UTC)Reply[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[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

  • Interesting idea, might be worth exploring. —TheDJ (talkcontribs) 12:29, 16 November 2016 (UTC)Reply[reply]
  • Let's explore it, it could be of great utility.--Alexmar983 (talk) 13:17, 16 November 2016 (UTC)Reply[reply]
  • Global find and replace done on multiple images in a category can be easily done with VisualFileChange tool. AutoWikiBrouwser is an excellent tool for quickly editing a page and moving to the next one. There is a proposal here to do browser based AutoWikiBrouwser that sounds very much like this proposal. --Jarekt (talk) 04:00, 17 November 2016 (UTC)Reply[reply]
    • Jarekt, thanks for the feedback. Editing files is not the only reason one might want to navigate through files from a category. It might be just another "Category Slideshow" with full page descriptions instead of the low-quality information now present or identifying pages from a category lacking some information (yes, I know PetScan can do a lot, but it can't do everything).--Strainu (talk) 21:49, 17 November 2016 (UTC)Reply[reply]

Voting – Category browsing without multimedia viewer

  1. Support Support Léna (talk) 11:10, 28 November 2016 (UTC)Reply[reply]
  2. Neutral 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! TalkWork 19:17, 29 November 2016 (UTC)Reply[reply]
  3. Oppose 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[reply]
  4. Support Support as proposer--Strainu (talk) 09:25, 30 November 2016 (UTC)Reply[reply]
  5. Support Support --Mess (talk) 19:09, 30 November 2016 (UTC)Reply[reply]
  6. Support Support--Ranjithsiji (talk) 05:47, 4 December 2016 (UTC)Reply[reply]
  7. Oppose Oppose We already have tools for that. No need to reinvent the wheel. --Hedwig in Washington (talk) 03:42, 6 December 2016 (UTC)Reply[reply]
  8. Support Support --Kiril Simeonovski (talk) 09:37, 7 December 2016 (UTC)Reply[reply]
  9. Support 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[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

  • Good idea --Steinsplitter (talk) 15:13, 10 November 2016 (UTC)Reply[reply]
  • I've wanted this ever since Tooserver killed this original tool. It was easy as a newbie to find out if two fils were (license) compatible with eachother, and which license the deriviative had to use etc. Josve05a (talk) 21:17, 10 November 2016 (UTC)Reply[reply]
  • I would also like to see this again. "Fork this image" :) —TheDJ (talkcontribs) 10:41, 11 November 2016 (UTC)Reply[reply]
  • https://tools.wmflabs.org/croptool solves 90% of the tasks I used to perform with DerivativeFX. Syced (talk) 14:19, 14 November 2016 (UTC)Reply[reply]
  • DerivativeFX was often a disaster, creating image description pages that missed much of vital metadata from the original files. I like the "Fork this image" link idea and some DerivativeFX alternative that actually works. Unfortunately I am pessimistic if one can write a tool to analyze current file description, which might be using variety of templates and description styles (or none), and create new correct description. Maybe we need Structured data first, or a tool that can at least recognize cases it can not handle and concentrate on those that can be handled with high success ratio. --Jarekt (talk) 13:43, 16 November 2016 (UTC)Reply[reply]
  • @Ninovolador: Images being open means making it easy for people to create derivatives of them - however I don't think that this would be used much on Wikipedia. For altered versions of images there's already the "Upload a new version of this file". Actually I'm not entirely sure how this would differ from that? --Fixuture (talk) 21:36, 29 November 2016 (UTC)Reply[reply]
    @Fixuture: I used it, for example, for uploading image translations (schemes, diagrams), map modifications (coloring, marking), uploading images from books for Wikisource. And i am sure other people used it for other reasons. --Ninovolador (talk) 22:32, 29 November 2016 (UTC)Reply[reply]

Voting – DerivativeFX alternative

  1. Support Support--Shizhao (talk) 02:36, 28 November 2016 (UTC)Reply[reply]
  2. Support Support as proposer Ninovolador (talk) 11:30, 28 November 2016 (UTC)Reply[reply]
  3. Support Support --Steinsplitter (talk) 15:06, 28 November 2016 (UTC)Reply[reply]
  4. Support Support · · · Peter (Southwood) (talk): 08:09, 29 November 2016 (UTC)Reply[reply]
  5. Support Support exploring various alternatives to fulfill this need. Stevie is the man! TalkWork 19:20, 29 November 2016 (UTC)Reply[reply]
  6. Support Support but still skeptical if the task is possible without Structured data. --Jarekt (talk) 19:30, 29 November 2016 (UTC)Reply[reply]
  7. Support Support --Alexmar983 (talk) 04:18, 30 November 2016 (UTC)Reply[reply]
  8. Support Support Syced (talk) 07:12, 30 November 2016 (UTC)Reply[reply]
  9. Support 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[reply]
  10. Support Support Ainali (talk) 07:26, 1 December 2016 (UTC)Reply[reply]
  11. Support Support --Gestumblindi (talk) 21:27, 1 December 2016 (UTC)Reply[reply]
  12. Support SupportJustin (koavf)TCM 03:51, 2 December 2016 (UTC)Reply[reply]
  13. Support Support -Geraki TL 09:11, 2 December 2016 (UTC)Reply[reply]
  14. Support Support // Martin Kraft (talk) 23:38, 2 December 2016 (UTC)Reply[reply]
  15. Strong support Strong support --Pokéfan95 (talk) 07:00, 3 December 2016 (UTC)Reply[reply]
  16. Strong support Strong support --jdx Re: 08:55, 3 December 2016 (UTC)Reply[reply]
  17. Support Support --User:Downspec
  18. Support Support Jianhui67 talkcontribs 09:57, 3 December 2016 (UTC)Reply[reply]
  19. Support Support --Nevit (talk) 21:07, 3 December 2016 (UTC)Reply[reply]
  20. Support Support--Ranjithsiji (talk) 05:48, 4 December 2016 (UTC)Reply[reply]
  21. Support Support--Fulvio314 (talk) 08:19, 4 December 2016 (UTC)Reply[reply]
  22. Support Support--Praveen:talk 12:47, 5 December 2016 (UTC)Reply[reply]
  23. Support SupportHmxhmx 18:21, 5 December 2016 (UTC)Reply[reply]
  24. Support Support Dearly missed, even the blunders it created. --Hedwig in Washington (talk) 03:44, 6 December 2016 (UTC)Reply[reply]
  25. Support Support --Assianir (talk) 07:40, 7 December 2016 (UTC)Reply[reply]
  26. Support Support --Kiril Simeonovski (talk) 09:37, 7 December 2016 (UTC)Reply[reply]
  27. Support Support, I also liked DerivateFX and miss it — NickK (talk) 18:37, 7 December 2016 (UTC)Reply[reply]
  28. Support Support --Harlock81 (talk) 18:54, 7 December 2016 (UTC)Reply[reply]
  29. Support Support Me too! Daniel Case (talk) 05:45, 8 December 2016 (UTC)Reply[reply]
  30. Support SupportRhododendrites talk \\ 06:30, 8 December 2016 (UTC)Reply[reply]
  31. Support Support --Carnildo (talk) 03:34, 9 December 2016 (UTC)Reply[reply]
  32. Support Support --OrsolyaVirág (talk) 12:48, 10 December 2016 (UTC)Reply[reply]
  33. Support Support --Dvdgmz (talk) 21:01, 10 December 2016 (UTC) Commons needs tools to facilitate reuse, derivative tracking and multiauthorship attributionReply[reply]
  34. Support Support Most of my contributions to commons are DWs.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:54, 11 December 2016 (UTC)Reply[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

  • While this goes under discussion, you may want to consider uploading to flickr first, where mass upload tools exist, and then pulling images across automatically with one of the several tools that exist for this purpose. I suspect that whether this can be time saving depends on the exact number of images. Regards, Samsara (talk) 18:47, 15 November 2016 (UTC)Reply[reply]
  • this would be useful for category missing description. we should be able to have tools as good as flickr uploader, but why start now? Slowking4 (talk) 15:17, 16 November 2016 (UTC)Reply[reply]
  • (note for Juandev: I moved your proposal to this page, I think it'll get more attention from Commons contributors.)
  • @Juandev: Would "Based on file name and geo data, propose English file description and categories when uploading to Commons" be a proper summary of this request? I'm asking as "Easier file description" did not allow me to quickly get an idea what's proposed here, so I wonder if you could edit and clarify the proposal's summary? --AKlapper (WMF) (talk) 11:08, 17 November 2016 (UTC)Reply[reply]
  • @Juandev: There are two other proposals above related to making descriptions more efficient: Multi-description tool and Semi-automatic photo description and categorization tool. Could we combine them, or are there significant differences that make this proposal unique? -- DannyH (WMF) (talk) 23:24, 18 November 2016 (UTC)Reply[reply]
  • @Juandev: Can we merge this proposal with the one above (#Semi-automatic photo description and categorization tool)? Ryan Kaldari (WMF) (talk) 19:39, 21 November 2016 (UTC)Reply[reply]
  • I think that improving the upload steps to allow you to do the metadata annotations during the upload or after having completed it, solves more 'wasted' hours, then auto generated descriptions would really. See also the discussion under #A_new_upload_wizard. —TheDJ (talkcontribs) 11:30, 23 November 2016 (UTC)Reply[reply]
  • If I'm understanding these proposals correctly, the Semi-automatic photo description and categorization tool proposal would help with getting good information (and geo-coords) to begin with. Then this proposal could get a proper Commons file name and better category suggestions. I had no idea of the correct way to name a file in Commons and I would guess that most casual users would not either. Thanks!--Tbennert (talk) 07:36, 26 November 2016 (UTC)Reply[reply]
  • See my discussion in Semi-automatic photo description and categorization tool that starts: "I'm leery of any idea/proposal where category suggestion is involved...". I haven't considered other aspects of this proposal yet. Stevie is the man! TalkWork 21:57, 29 November 2016 (UTC)Reply[reply]

Voting – Easier file description

  1. Support Support--Wesalius (talk) 06:45, 28 November 2016 (UTC)Reply[reply]
  2. Support Support --Ziko (talk) 21:09, 28 November 2016 (UTC)Reply[reply]
  3. Support Support Jane023 (talk) 12:57, 30 November 2016 (UTC)Reply[reply]
  4. Support Support Draceane (talk) 09:47, 2 December 2016 (UTC)Reply[reply]
  5. Support Support--Ranjithsiji (talk) 05:48, 4 December 2016 (UTC)Reply[reply]
  6. Support Support - Best regards, Kertraon (talk) 11:31, 4 December 2016 (UTC)Reply[reply]
  7. Neutral 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[reply]
  8. Support Support --Kiril Simeonovski (talk) 09:44, 7 December 2016 (UTC)Reply[reply]
  9. Support Support --Chrumps (talk) 03:37, 11 December 2016 (UTC)Reply[reply]
  10. Support Support --Soluvo (talk) 00:29, 12 December 2016 (UTC)Reply[reply]
  11. Support Support--Mikheil Talk 20:59, 12 December 2016 (UTC)Reply[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[reply]
    • @Bodhisattwa: Okay, I've moved it here to Commons because I think that's where these files are mostly viewed (outside ofthe proofreadpage interface). Sam Wilson 06:17, 16 November 2016 (UTC)Reply[reply]
  • @Bodhisattwa: Trying to improve the proposal summary (as "Improve scanned book reading experience in Commons & Wikisource" did not allow me to quickly understand what is being proposed), could this be described as "Offer more view options for reading scanned books on Commons & Wikisource" instead? If yes, please feel free to edit the proposal summary. Thanks! --AKlapper (WMF) (talk) 11:29, 17 November 2016 (UTC)Reply[reply]
    • @AKlapper (WMF):, I have changed the title to "Implement Internet Archive BookReader in Commons & Wikisource", please opine if it is ok. Thanks. -- Bodhisattwa (talk) 12:36, 17 November 2016 (UTC)Reply[reply]
  • While this looks interesting, and is indeed far better than our viewer, I feel obliged to mention that there are prominent links to view "next page" and "previous page". Matma Rex (talk) 17:45, 25 November 2016 (UTC)Reply[reply]
    • And the next page can also be viewed by clicking the current preview. Nemo 09:31, 5 December 2016 (UTC)Reply[reply]

Voting – Internet Archive BookReader in Commons & Wikisource

  1. Support Support--Wesalius (talk) 06:45, 28 November 2016 (UTC)Reply[reply]
  2. Support 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[reply]
  3. Oppose Oppose, there are buttons for the next and previous pages of the book. --Fixuture (talk) 20:41, 29 November 2016 (UTC)Reply[reply]
  4. Support Support--Micru (talk) 12:24, 30 November 2016 (UTC)Reply[reply]
  5. Support 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[reply]
  6. Support Support Great to build upon existing open source. Ainali (talk) 07:28, 1 December 2016 (UTC)Reply[reply]
  7. Support Support I love archive.org's online book experience. I much prefer it. Rachel Helps (BYU) (talk) 18:50, 1 December 2016 (UTC)Reply[reply]
  8. Support Support NMaia (talk) 02:08, 2 December 2016 (UTC)Reply[reply]
  9. Support Support Anything that brings together our communities. —Justin (koavf)TCM 03:58, 2 December 2016 (UTC)Reply[reply]
  10. Support Support --Continua Evoluzione (talk) 13:57, 2 December 2016 (UTC)Reply[reply]
  11. Support Support Sannita - not just another it.wiki sysop 14:08, 2 December 2016 (UTC)Reply[reply]
  12. Support Support --Ranjithsiji (talk) 05:49, 4 December 2016 (UTC)Reply[reply]
  13. Support Support --HHill (talk) 10:33, 5 December 2016 (UTC)Reply[reply]
  14. Support Support --Andropov (talk) 17:47, 5 December 2016 (UTC)Reply[reply]
  15. Support Support Not high priority but should be considered soonish. --Hedwig in Washington (talk) 03:02, 6 December 2016 (UTC)Reply[reply]
  16. Support Support --Kiril Simeonovski (talk) 09:44, 7 December 2016 (UTC)Reply[reply]
  17. Support Support Low priority but potentially useful — NickK (talk) 18:38, 7 December 2016 (UTC)Reply[reply]
  18. Support Support - DPdH (talk) 20:01, 7 December 2016 (UTC)Reply[reply]
  19. Support Support --Psychoslave (talk) 09:57, 9 December 2016 (UTC)Reply[reply]
  20. Support Support Ayack (talk) 11:53, 9 December 2016 (UTC)Reply[reply]
  21. Support Support --Jarekt (talk) 13:57, 9 December 2016 (UTC)Reply[reply]
  22. Support 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[reply]
  23. Support Support --OrsolyaVirág (talk) 12:49, 10 December 2016 (UTC)Reply[reply]
  24. Support Support --g (talk) 12:52, 10 December 2016 (UTC)Reply[reply]
  25. Support Support --Dvdgmz (talk) 21:05, 10 December 2016 (UTC) to do Commons a better place to see/read content, not only to upload and downloadReply[reply]
  26. Support Support --Yann (talk) 22:42, 12 December 2016 (UTC)Reply[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

  • Isn't that what sortkeys are for ? —TheDJ (talkcontribs) 00:02, 16 November 2016 (UTC)Reply[reply]
    Sortkeys are static and file defined. As I understand this wish, what is asked is a dynamic sort at a category level. Léna (talk) 16:08, 16 November 2016 (UTC)Reply[reply]
    That is right. The user should sort the categories, dynamicaly. --XRay (talk) 12:05, 17 November 2016 (UTC)Reply[reply]
  • @XRay: I am aware of requests to sort categories by usage (most/least used pages) or creation date (newest/oldest date of original image/video), by date reversed, by size for files in that category. What would "by subject" mean? How exactly would results look like if you sorted "by location"? Is that a list of location names, or sorting by what's closest to some place? This proposal welcomes elaborations, and it seems to mix up several different feature requests ("location, date, name, subject,...") in one proposal which is not recommended by the Community Wishlist guidelines and might make this proposal invalid. Hence clarifications and improvements are welcome. --AKlapper (WMF) (talk) 11:51, 17 November 2016 (UTC)Reply[reply]
    A location is given in meta data, the origin is the geo location. Sort by location may be for example in a category like "... in Germany" Aachen, Bonn, Chemnitz, ... --XRay (talk) 12:05, 17 November 2016 (UTC)Reply[reply]
    @XRay: Can you clarify this proposal further? Would this be a separate interface for viewing categories or would it replace the existing category page interface? Ryan Kaldari (WMF) (talk) 19:48, 21 November 2016 (UTC)Reply[reply]

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[reply]

Voting – Make categories sortable

  1. Support Support Ninovolador (talk) 11:32, 28 November 2016 (UTC)Reply[reply]
  2. Support 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! TalkWork 16:25, 29 November 2016 (UTC)Reply[reply]
  3. Support Support Guycn2 · 17:50, 29 November 2016 (UTC)Reply[reply]
  4. Support 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[reply]
  5. Support Support --XRay (talk) 06:01, 2 December 2016 (UTC)Reply[reply]
  6. Support Support Draceane (talk) 09:47, 2 December 2016 (UTC)Reply[reply]
  7. Support 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[reply]
  8. Support Support // Martin Kraft (talk) 23:39, 2 December 2016 (UTC)Reply[reply]
  9. Support Support Jianhui67 talkcontribs 10:00, 3 December 2016 (UTC)Reply[reply]
  10. Support Support - DPdH (talk) 20:04, 7 December 2016 (UTC)Reply[reply]
  11. Support Support--Ranjithsiji (talk) 05:49, 4 December 2016 (UTC)Reply[reply]
  12. Neutral Neutral I'd rather see an easy mass-rename feature. --Hedwig in Washington (talk) 03:05, 6 December 2016 (UTC)Reply[reply]
  13. Support Support Muhraz (talk) 15:43, 6 December 2016 (UTC)Reply[reply]
  14. Support Support--Kiril Simeonovski (talk) 09:45, 7 December 2016 (UTC)Reply[reply]
  15. Support SupportYnhockey (talk) 12:03, 7 December 2016 (UTC)Reply[reply]
  16. Support 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[reply]
  17. Support Support per NickK. Daniel Case (talk) 05:44, 8 December 2016 (UTC)Reply[reply]
  18. Support 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[reply]
  19. Support Support Linie29 (talk) 14:17, 9 December 2016 (UTC)Reply[reply]
  20. Support Support per Jarekt --Waldir (talk) 11:05, 10 December 2016 (UTC)Reply[reply]
  21. Support Support OrsolyaVirág (talk) 12:50, 10 December 2016 (UTC)Reply[reply]
  22. Support Support --Dvdgmz (talk) 21:06, 10 December 2016 (UTC) would be good to use commons as a presentation (ppt-like) tool in educationReply[reply]
  23. Support Support --NaBUru38 (talk)
  24. Support Support --Cavarrone (talk) 10:14, 11 December 2016 (UTC)Reply[reply]
  25. Support Support --Plagiat (talk) 17:19, 11 December 2016 (UTC)Reply[reply]
  26. Support Support --Yann (talk) 22:42, 12 December 2016 (UTC)Reply[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 Support as creator, Sadads (talk) 14:45, 28 November 2016 (UTC)Reply[reply]
  2. Support Support MichaelMaggs (talk) 19:53, 28 November 2016 (UTC)Reply[reply]
  3. Support Support WereSpielChequers (talk) 12:38, 29 November 2016 (UTC)Reply[reply]
  4. Support 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! TalkWork 16:20, 29 November 2016 (UTC)Reply[reply]
  5. Support 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[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[reply]
  6. Support Support --Alexmar983 (talk) 04:19, 30 November 2016 (UTC)Reply[reply]
  7. Support Support Rachel Helps (BYU) (talk) 18:51, 1 December 2016 (UTC)Reply[reply]
  8. Support Support--Ranjithsiji (talk) 05:49, 4 December 2016 (UTC)Reply[reply]
  9. Support Support Gareth (talk) 10:48, 4 December 2016 (UTC)Reply[reply]
  10. Support Support Long overdue. Muhraz (talk) 15:43, 6 December 2016 (UTC)Reply[reply]
  11. Support Support - DPdH (talk) 19:53, 6 December 2016 (UTC)Reply[reply]
  12. Support Support --Assianir (talk) 07:40, 7 December 2016 (UTC)Reply[reply]
  13. Support Support --Kiril Simeonovski (talk) 09:47, 7 December 2016 (UTC)Reply[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[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[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[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[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[reply]

Voting – Multi-description tool

  1. Support 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[reply]
  2. Support Support --Alexmar983 (talk) 04:19, 30 November 2016 (UTC)Reply[reply]
  3. Support Support --Mess (talk) 19:10, 30 November 2016 (UTC)Reply[reply]
  4. Support 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[reply]
  5. Support Support Draceane (talk) 09:48, 2 December 2016 (UTC)Reply[reply]
  6. Support 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[reply]
  7. Support Support --Ranjithsiji (talk) 05:50, 4 December 2016 (UTC)Reply[reply]
  8. Support 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[reply]
  9. Support Support Muhraz (talk) 15:45, 6 December 2016 (UTC)Reply[reply]
  10. Support Support - DPdH (talk) 20:08, 6 December 2016 (UTC)Reply[reply]
  11. Support Support --Assianir (talk) 07:35, 7 December 2016 (UTC)Reply[reply]
  12. Support Support --Kiril Simeonovski (talk) 07:41, 7 December 2016 (UTC)Reply[reply]
  13. Support SupportYnhockey (talk) 11:53, 7 December 2016 (UTC)Reply[reply]
  14. Strong support 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[reply]
  15. Support Support per Fixuture --g (talk) 12:54, 10 December 2016 (UTC)Reply[reply]
  16. Support Support --Dvdgmz (talk) 21:08, 10 December 2016 (UTC)Reply[reply]
  17. Support Support --Cavarrone (talk) 10:15, 11 December 2016 (UTC)Reply[reply]
  18. Support Support --Plagiat (talk) 17:20, 11 December 2016 (UTC)Reply[reply]
  19. Support Support --Soluvo (talk) 00:31, 12 December 2016 (UTC)Reply[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[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[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[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[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 (talkcontribs) 10:39, 11 November 2016 (UTC)Reply[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[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[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[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[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[reply]

  • I find current upload wizard to be a good tool with few problems. --Jarekt (talk) 13:45, 16 November 2016 (UTC)Reply[reply]
That doesn't mean it can't be improved. Daniel Case (talk) 07:51, 18 November 2016 (UTC)Reply[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[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[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[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[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[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[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[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[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[reply]

Voting – New upload wizard

  1. Support Support--Shizhao (talk) 02:39, 28 November 2016 (UTC)Reply[reply]
  2. Oppose 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[reply]
  3. Oppose 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[reply]
  4. Oppose 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! TalkWork 17:12, 29 November 2016 (UTC)Reply[reply]
  5. Oppose 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[reply]
  6. Support 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[reply]
  7. Support Support --Mess (talk) 18:59, 30 November 2016 (UTC)Reply[reply]
  8. Support 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[reply]
  9. Support 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[reply]
  10. Oppose Oppose I do not think we need a new upload wizard. --Steinsplitter (talk) 18:52, 1 December 2016 (UTC)Reply[reply]
  11. Support Support Even I dont use browser upload, I think this is a good idea Juandev (talk) 21:07, 1 December 2016 (UTC)Reply[reply]
  12. Support 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[reply]
  13. Support Support CFynn (talk) 05:49, 2 December 2016 (UTC)Reply[reply]
  14. Support Support Draceane (talk) 09:48, 2 December 2016 (UTC)Reply[reply]
  15. Support Support --Sailko (talk) 11:51, 2 December 2016 (UTC)Reply[reply]
  16. Neutral Neutral I'm not really convinced that there is a sufficient need for this. --Tryptofish (talk) 22:15, 5 December 2016 (UTC)Reply[reply]
  17. Oppose Oppose per above, nuttin' to add. --Hedwig in Washington (talk) 03:12, 6 December 2016 (UTC)Reply[reply]
  18. Oppose Oppose--I do not think we need a new upload wizard.--alm (talk) 03:52, 6 December 2016 (UTC)Reply[reply]
  19. Support Support Muhraz (talk) 15:47, 6 December 2016 (UTC)Reply[reply]
  20. Support Support - Improve existing tool if possible, new if not. DPdH (talk) 20:05, 6 December 2016 (UTC)Reply[reply]
  21. Support Support --Assianir (talk) 07:35, 7 December 2016 (UTC)Reply[reply]
  22. Support 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[reply]
  23. Support 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[reply]
  24. Comment 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[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[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[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[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! TalkWork 17:24, 29 November 2016 (UTC)Reply[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[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[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[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[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[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[reply]

Voting – Rapid category creation

  1. Oppose Oppose Sorry, but I strongly think this work should be manually done, with human judgment. Stevie is the man! TalkWork 17:27, 29 November 2016 (UTC)Reply[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[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! TalkWork 18:32, 30 November 2016 (UTC)Reply[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[reply]
  2. Support Support --Mess (talk) 19:00, 30 November 2016 (UTC)Reply[reply]
  3. Support Support --Una giornata uggiosa '94 · So, what do you want to talk about? 02:45, 1 December 2016 (UTC)Reply[reply]
  4. Support Support Emir of Wikipedia (talk) 15:15, 2 December 2016 (UTC)Reply[reply]
  5. Oppose 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[reply]
  6. Oppose Oppose Too risky. Muhraz (talk) 15:47, 6 December 2016 (UTC)Reply[reply]
  7. Support Support --Assianir (talk) 07:35, 7 December 2016 (UTC)Reply[reply]
  8. Oppose 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[reply]
  9. Oppose 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[reply]
  10. Neutral Neutral Adding a "red category" is sometimes better than no category. Matěj Suchánek (talk) 15:34, 7 December 2016 (UTC)Reply[reply]
  11. Oppose 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[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[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: Do you have a link to the 'recent uploads patrol' tool? Could the newbie-uploads tool be a basis for this (if it were modified to be able to mark things as patrolled, or nominate for deletion etc.)? Sam Wilson 06:04, 15 November 2016 (UTC)Reply[reply]
  • I was thinking about this Recent uploads patrol webapp. Thanks for the link! The newbie-uploads is definitely a great project to start with, I update my proposal including your input. Syced (talk) 07:05, 15 November 2016 (UTC)Reply[reply]
  • Sam, I honestly have no idea how to mark an image as patrolled with that tool. Visiting the page of an image does not make it disappear from the list, even after a refresh. Syced (talk) 08:22, 15 November 2016 (UTC)Reply[reply]
  • @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[reply]
  • Support. Desperately needed. —TheDJ (talkcontribs) 00:04, 16 November 2016 (UTC)Reply[reply]
  • I am unable to parse exactly what is the proposed solution here. What exactly is proposed to make it "10 times more time-efficient"? Stevie is the man! TalkWork 18:03, 29 November 2016 (UTC)Reply[reply]
    The "10 times more time-efficient" link leads to the list of proposed enhancements, on the project's issue tracker. They are numerous small changes, so I did not judge useful to list them all here, but feel free to edit to add them, cheers! Syced (talk) 06:52, 30 November 2016 (UTC)Reply[reply]
    There's no clear way for me to parse these list items to get to the conclusion of "10 times more time-efficient". I would like to see this claim backed up in some way within this proposal, using particular examples from the list. Stevie is the man! TalkWork 18:36, 30 November 2016 (UTC)Reply[reply]

Voting – Recent uploads patrol webapp

  1. Support Support Syced (talk) 06:53, 30 November 2016 (UTC)Reply[reply]
  2. Support Support--Ranjithsiji (talk) 05:51, 4 December 2016 (UTC)Reply[reply]
  3. Support Support 15:48, 6 December 2016 (UTC)
  4. Support Support - DPdH (talk) 20:12, 6 December 2016 (UTC)Reply[reply]
  5. Oppose 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[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[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[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[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[reply]
    • That was introduced by CirrusSearch, there should be a report or something about it. (But of course searching Phabricator is a nightmare.) Nemo 09:29, 25 November 2016 (UTC)Reply[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 Support--Wesalius (talk) 06:35, 28 November 2016 (UTC)Reply[reply]
  2. Support Support A really interesting suggestion that can do a load of good if implemented well. Soni (talk) 15:04, 29 November 2016 (UTC)Reply[reply]
  3. Oppose 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[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! TalkWork 18:15, 29 November 2016 (UTC)Reply[reply]
    Soften my stance to Neutral Neutral because this really is about timing, not potential value. Stevie is the man! TalkWork 12:14, 10 December 2016 (UTC)Reply[reply]
  5. Oppose 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[reply]
  6. Support 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[reply]
  7. Support 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[reply]
  8. Support Support --Mess (talk) 19:01, 30 November 2016 (UTC)Reply[reply]
  9. Support Support --β16 - (talk) 15:12, 1 December 2016 (UTC)Reply[reply]
  10. Support Support Ahm masum (talk) 17:07, 1 December 2016 (UTC)Reply[reply]
  11. Support Support Why not, than the bot can also write the red text to the description Juandev (talk) 21:08, 1 December 2016 (UTC)Reply[reply]
  12. Support 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[reply]
  13. Support Support NMaia (talk) 02:09, 2 December 2016 (UTC)Reply[reply]
  14. Support Support Libcub (talk) 02:26, 2 December 2016 (UTC)Reply[reply]
  15. Oppose Oppose per Jarekt -FASTILY 07:08, 2 December 2016 (UTC)Reply[reply]
  16. Oppose Oppose per Fixuture. --Steinsplitter (talk) 12:51, 2 December 2016 (UTC)Reply[reply]
  17. Oppose Oppose, per Jarekt. Muhraz (talk) 15:49, 6 December 2016 (UTC)Reply[reply]
  18. Support Support - DPdH (talk) 20:14, 6 December 2016 (UTC)Reply[reply]
  19. Support Support -- Movses (talk) 21:49, 6 December 2016 (UTC)Reply[reply]
  20. Support Support --Assianir (talk) 07:35, 7 December 2016 (UTC)Reply[reply]
  21. Support 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[reply]
  22. Support Support Miniapolis 21:04, 8 December 2016 (UTC)Reply[reply]
  23. Support Support --Arnd (talk) 13:39, 9 December 2016 (UTC)Reply[reply]
  24. Support Support Linie29 (talk) 14:18, 9 December 2016 (UTC)Reply[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

  • I support some sort of category-filtered display (and search, but we can do it that at least with ctrl+F) within a selected depth. It's something that it is needed sometimes.--Alexmar983 (talk) 16:45, 18 November 2016 (UTC)Reply[reply]

Voting – Searching for images in nested categories

  1. Support Support --Ziko (talk) 21:10, 28 November 2016 (UTC)Reply[reply]
  2. Support Support Guycn2 · 17:52, 29 November 2016 (UTC)Reply[reply]
  3. Support Support --Alexmar983 (talk) 04:01, 30 November 2016 (UTC)Reply[reply]
  4. Support Support --Mess (talk) 19:02, 30 November 2016 (UTC)Reply[reply]
  5. Support Support as proposer, Jane023 (talk) 00:49, 1 December 2016 (UTC)Reply[reply]
  6. Support Support --Bramfab (talk) 13:27, 1 December 2016 (UTC)Reply[reply]
  7. Support Support Ahm masum (talk) 17:07, 1 December 2016 (UTC)Reply[reply]
  8. Support Support --Kusurija (talk) 18:00, 1 December 2016 (UTC)Reply[reply]
  9. Support Support --Gestumblindi (talk) 21:23, 1 December 2016 (UTC)Reply[reply]
  10. Support Support Libcub (talk) 02:21, 2 December 2016 (UTC)Reply[reply]
  11. Support Support --Morio (talk) 11:43, 2 December 2016 (UTC)Reply[reply]
  12. Support Support --Nevit (talk) 21:10, 3 December 2016 (UTC)Reply[reply]
  13. Support Support--Molgreen (talk) 06:03, 4 December 2016 (UTC)Reply[reply]
  14. Support Support - Best regards, Kertraon (talk) 11:38, 4 December 2016 (UTC)Reply[reply]
  15. Support Support Muhraz (talk) 15:49, 6 December 2016 (UTC)Reply[reply]
  16. Support Support --Assianir (talk) 07:35, 7 December 2016 (UTC)Reply[reply]
  17. Support Support --Geolina163 (talk) 08:33, 7 December 2016 (UTC)Reply[reply]
  18. Support Support--Kiril Simeonovski (talk) 08:39, 7 December 2016 (UTC)Reply[reply]
  19. Support Support --M11rtinb (talk) 16:29, 7 December 2016 (UTC)Reply[reply]
  20. Support SupportNickK (talk) 18:30, 7 December 2016 (UTC)Reply[reply]
  21. Support Support --Carnildo (talk) 01:54, 8 December 2016 (UTC)Reply[reply]
  22. Support SupportRhododendrites talk \\ 06:25, 8 December 2016 (UTC)Reply[reply]
  23. Support Support Miniapolis 21:06, 8 December 2016 (UTC)Reply[reply]
  24. Support Support OrsolyaVirág (talk) 12:51, 10 December 2016 (UTC)Reply[reply]
  25. Support Support, with a customizable depth level. --NaBUru38 (talk)
  26. Support Support Lack of this is very frustrating.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:56, 11 December 2016 (UTC)Reply[reply]
  27. Support Support --Alaspada (Talk) 20:05, 11 December 2016 (UTC)Reply[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[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[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[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[reply]
    • Moreover, once you read the information somewhere, you can distrubute it elswhere - e.g. to the description.--Juandev (talk) 20:24, 13 November 2016 (UTC)Reply[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[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[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[reply]
  • A good idea. We could also parse the description for related categories, ex. word painting should trigger suggestion of commons:Category:Paintings, etc. --Piotrus (talk) 08:21, 15 November 2016 (UTC)Reply[reply]
  • @Aktron: Can we merge this proposal with the one below (#Easier file description)? Ryan Kaldari (WMF) (talk) 19:38, 21 November 2016 (UTC)Reply[reply]
    • These two seems to be basically identical, so why not ;-) --Aktron (talk) 22:56, 21 November 2016 (UTC)Reply[reply]
  • I proposed something similar in phabricator:T118875. Two years ago I created Category:Media with geo-coordinates needing categories which now has 316k files to make it easier to develop tools to categorize images based on location. --Jarekt (talk) 13:14, 26 November 2016 (UTC)Reply[reply]
  • I'm leery of any idea/proposal where category suggestion is involved, as whether the suggestion is correct or not, the newbie will likely accept it. I'd rather see the development of features that help users understand the category hierarchies, although I recognize this as a difficult proposition. If there's going to be any suggesting, they should only be unmistakable ones. That is, only suggest where there is near-absolute certainty. Otherwise, the frustrated newbie is just going to have to learn the categories. I'd rather they not categorize than mis-categorize. Stevie is the man! TalkWork 16:46, 29 November 2016 (UTC)Reply[reply]

Voting – Semi-automatic photo description and categorization

  1. Support Support--Wesalius (talk) 06:32, 28 November 2016 (UTC)Reply[reply]
  2. Support 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[reply]
  3. Support Support --Alexmar983 (talk) 04:01, 30 November 2016 (UTC)Reply[reply]
  4. Support Support Syced (talk) 06:57, 30 November 2016 (UTC)Reply[reply]
  5. Support Support --Mess (talk) 19:03, 30 November 2016 (UTC)Reply[reply]
  6. Support Support Ahm masum (talk) 17:07, 1 December 2016 (UTC)Reply[reply]
  7. Support Support Juandev (talk) 20:52, 1 December 2016 (UTC)Reply[reply]
  8. Support Support --Gestumblindi (talk) 21:24, 1 December 2016 (UTC)Reply[reply]
  9. Support Support Orgio89 (talk) 02:27, 2 December 2016 (UTC)Reply[reply]
  10. Support Support --Marianne Casamance (talk) 05:56, 2 December 2016 (UTC)Reply[reply]
  11. Support Support Draceane (talk) 09:49, 2 December 2016 (UTC)Reply[reply]
  12. Support Support MartinThoma (talk) 15:46, 2 December 2016 (UTC)Reply[reply]
  13. Support Support // Martin Kraft (talk) 23:40, 2 December 2016 (UTC)Reply[reply]
  14. Support Support --Tbennert (talk) 06:51, 5 December 2016 (UTC)Reply[reply]
  15. Support Support Muhraz (talk) 15:50, 6 December 2016 (UTC)Reply[reply]
  16. Support Support - If possible would be great. DPdH (talk) 20:51, 6 December 2016 (UTC)Reply[reply]
  17. Support Support -- Movses (talk) 21:53, 6 December 2016 (UTC)Reply[reply]
  18. Support Support --Assianir (talk) 07:35, 7 December 2016 (UTC)Reply[reply]
  19. Support Support --Geolina163 (talk) 08:36, 7 December 2016 (UTC)Reply[reply]
  20. Support Support--Kiril Simeonovski (talk) 08:40, 7 December 2016 (UTC)Reply[reply]
  21. Support Support nice idea — Rhododendrites talk \\ 06:26, 8 December 2016 (UTC)Reply[reply]
  22. Support Support Miniapolis 21:08, 8 December 2016 (UTC)Reply[reply]
  23. Support Support Useful function. Akela (talk) 21:40, 8 December 2016 (UTC)Reply[reply]
  24. Support Support --Arnd (talk) 13:35, 9 December 2016 (UTC)Reply[reply]
  25. Support Support Linie29 (talk) 14:15, 9 December 2016 (UTC)Reply[reply]
  26. Support Support --OrsolyaVirág (talk) 12:52, 10 December 2016 (UTC)Reply[reply]