2017 Community Wishlist Survey/Multimedia and Commons

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

2017 Community Wishlist Survey

Multimedia and Commons
31 proposals, 69 contributors

Go-previous.svg Mobile and apps  •  Programs and events Go-next.svg

Contents

Number of Pixels for images on Commons

Edit proposal/discussion

  • Problem:

At Commons, when images are showed, there appears this message below the picture:

Original file ‎(4,000 × 3,000 pixels, file size: 5.6 MB, MIME type: image/jpeg); ZoomViewer: flash/no flash

It would be very helpful, if it would show the Megapixels, in this case 4000 x 3000 = 12 Mpix.

  • Who would benefit: All common users
  • Proposed solution: Add Mpix to the image dimesions
  • More comments:
  • Phabricator tickets:

Discussion[edit]

Could we get some explanation as to how described situation may be a problem? (Is it lack of compatibility with camera marketing?..)--Reseletti (talk) 22:12, 9 November 2017 (UTC)

  • Excellent proposal donald. I often have to whip out my desktop calculator to do this manually, so it would save me a lot of time. And such an easy solution to code. Reseletti, the FPC community has a 2 megapixel limit on its entries, and we often talk about images in terms of their pixel count there, and at the moment such a thing has to be worked out manually -- Thennicke (talk) 10:34, 10 November 2017 (UTC)

I see. So not everyone has that need and making the existing solution a little more accessible via a tickbox in the user preferences would be all we need, right?..--Reseletti (talk) 14:51, 10 November 2017 (UTC)

  • Much easier to just have a number, 12.0 Mpx, next to the "4000 x 3000 pixels", on the file description page. To two decimal places, it's literally just a few characters, so there is no need for preferences to be involved here.
Example: "5,419 × 3,048 pixels (16.52 Mpx), file size: 8.62 MB, MIME type: image/jpeg" -- Thennicke (talk) 02:32, 11 November 2017 (UTC)
I like the proposed format of Thennicke. Geraldshields11 (talk) 18:29, 11 November 2017 (UTC)
To add to this, it would be great to be able to search for images within a range of sizes by megapixel. We can already do that for file size, dimensions, and resolution, this would be one more unit of measurement. Edit: to be clear, I'd like to see this data exposed to the search engine as well as present on-screen. :) Ckoerner (talk) 22:48, 13 November 2017 (UTC)

Trim webm videos on site

Edit proposal/discussion

  • Problem: editing a video now requires you to download the video, find a video editor that supports ogg/webm and upload them again. YouTube videos often have an outro that is distracting when there aren't other YouTube videos linked. Sometimes a video is an assembly of segments, like the short segments in RN7 news (File:RN7 Kort 7 November 2017.webm). Sometimes a part of a video's copyright status is in doubt, like File:Zondag met Lubach houdt de wereld voor de gek.webm, which was published under a free license by VARA but features a video produced by VPRO.
  • Who would benefit: Wikimedia contributors that work with
  • Proposed solution: A tool like CropTool that lets you edit a file without having to leave the project.
  • More comments:would be extra great if relevant subtitle files would also be trimmed and re-upload.
  • Phabricator tickets:
  • Proposer: Vera (talk) 21:09, 12 November 2017 (UTC)

Discussion[edit]

  • I was going to propose this but Vera beat me to it! 100% support Victorgrigas (talk) 03:08, 13 November 2017 (UTC)
  • We don't even have a decent video player yet, let alone an editor... P.S. anyone suggesting spending time on the player. ? I've reached my quotum for the survey. —TheDJ (talkcontribs) 10:44, 13 November 2017 (UTC)
I'm not proposing an fully fledged video editor, I'm proposing a tool that lets you shorten a video by trimming off the beginning or end. Vera (talk) 16:25, 13 November 2017 (UTC)

Advanced filters for global usage on Commons

Edit proposal/discussion

  • Problem: When you want to see a specific usage of a file on some project(s)/language(s) from Global Usage feature on Commons you have to scroll all the other projects and languages and their usages.
  • Who would benefit: e.g. users looking for usage on all projects in some specific language
  • Proposed solution: The list should be either collapsible or get some filters.
  • More comments: See for example the usage list for c:File:United Kingdom location map.svg.

Discussion[edit]

Write geographical data into image files

Edit proposal/discussion

  • Problem: Images files can store location data as meta data inside the file. As of today image files do not provide this data. For a lot of files location data are available on commons. But they are stored separately on the description page.
  • Who would benefit: Users of Wikimedia Commons files who are interested in location data for images.
  • Proposed solution: Write location data from description page into meta data of the image file.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

I am concerned that the geographical data is not always accurate. If geographical data is included in the file, future users of the file will think that the data in the file overrides any geographical data in the description. Downtowngal (talk) 00:12, 17 November 2017 (UTC)

Write license data into meta data of image files

Edit proposal/discussion

  • Problem: Images files can store license data as meta data inside the file. As of today image files do not provide this data. For nearly all files on Wikimedia Commons license data are available on commons. But they are stored separately on the description page.
  • Who would benefit: Users of Wikimedia Commons files who want to use the file and need the license information but cannot find the corresponding Wikimedia Commons file page.
  • Proposed solution: Write license data from description page into meta data of the image file.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

I'm surprised nobody has requested this before. It sounds like a great idea. Is there some reason this has not been done yet? Downtowngal (talk) 00:09, 17 November 2017 (UTC)

This is not the first time I've heard this proposal. I would like to limit the scope to only the thumbnails. Original files shouldn't be touched. That would have all sorts of nasty side effects (duplicate detection broken to name one). Multichill (talk) 17:10, 17 November 2017 (UTC)

See also phab:T5361 and phab:T20871. Jean-Fred (talk) 20:14, 17 November 2017 (UTC)

Create a widget for external website consultation of video

Edit proposal/discussion

  • Problem: The Web is full of video widgets that allow to consult in place a video which is stored on a different server domain. Most of them use a video on demand service provider among the most populars. People don't have the reflex to upload to Commons, even if the video have clearly pedagogical values and that they are fine with sharing it under a free license. Although many other factor are admittedly entering in this result, not being able to easily integrate a Commons widget in their own website might be a criteria for rejecting Commons as a video hosting service. That is sad, as we directly lose many occasion of gathering more video content. But even more detrimental is the fact that we lose many occasion of making people aware that they can share their pedagogical videos on Commons. Indeed, an easy to use external widget is not just an attractive feature for this users, it's also a way to attract a lot of audience, and consequently many new potential contributors.
  • Who would benefit:
    • Everybody on the web looking for a video on demand service provider that comes with such a feature for their pedagogical videos.
    • The Commons project and community, as it could gain a lot of visibility and new contributors.
  • Proposed solution:
    • implement a widget of external consultation, which of course include a link to the Commons relative page and maybe a "About Wikimedia Commons" link. Possibly push the Commons logo at some place/point to strengthen the promotional value of the widget.
    • make this widget extremely easy to use through copy/paste of code snippet accessible everywhere the video appears so users can disseminate Commons video wherever they want on the web.


  • More comments:
  • Phabricator tickets:

Discussion[edit]

  • We actually do have this, but we don't promote it much, because its rather unstable. But if on commons, you go to "Use this file", and copy paste the HTML code:
<iframe src="https://commons.wikimedia.org/wiki/File%3APetrSU_English_2017.ogv?embedplayer=yes" width="1024" height="576" frameborder="0" ></iframe>

Then this can be embedded into another page. The Wikimedia blog uses it. But as stated, its a bit flaky and additionally, we are terrible at Commons at encouraging usage of our material to begin with. We seem to focus on collecting rather than reusing. —TheDJ (talkcontribs) 10:52, 13 November 2017 (UTC)

  • Great news, thank you. Then I think this proposal should be turned into improve this feature to fix its unstability. For the problem of promoting reuse, it's not a technical problem. But Community Liaisons might consider the problem. @Trizek (WMF):, @Qgil-WMF:, et alia, may we discuss the topic somewhere? --Psychoslave (talk) 11:28, 13 November 2017 (UTC)
    • <hobby horse>It would be great to see support for something like oembed (T27854) and/or opengraph for Wikimedia urls. When I copy and paste a URL into a non-Wikimedia site or social media I'd love to see an automagical expanded player ala every other media provider on the 2017 Internet. ಠ_ಠ </hobby horse> CKoerner (WMF) (talk) 22:56, 13 November 2017 (UTC)
    • I don't know any details, but I expect the Structured Data on Commons program to make Commons content not only easier to find, also easier to promote. @SandraF (WMF):. Qgil-WMF (talk)
    • As mentioned above, one of the (many) goals of Structured Data on Commons is to improve our reuse scenarios. Once we have structured data in place, we'll start building out tools that take advantage of it. Reuse/embed work is currently scheduled for 2019, and our plans include ways to improve both the tech side and address the problem of promoting Commons and its content. For example, one approach may be to have a Wordpress widget for this in addition to our own tool (which, as TheDJ mentions, exists now but could use some improvement).

Textual diffs for SVGs

Edit proposal/discussion

  • Problem: Comparing different media versions is often difficult as the changes may not be noticeable. This stands for SVGs as well as other media formats; however, as SVG is a textual file format, its changes can be shown as textual diffs.
  • Who would benefit: Advanced users who understand the SVG source code.
  • Proposed solution: Use the existing diff used for wikitext changes also for SVG (and any other textual file format), provide a diff link in the first column of the file history like (current | diff) / (restore | diff).
  • More comments:
  • Phabricator tickets:
  • Proposer: Tacsipacsi (talk) 20:22, 6 November 2017 (UTC)

Discussion[edit]

Example SVG file used on 7.7M pages, which has 8 versions. When 9-th version is uploded it would be nice to compare source-codes to see what changed. --Jarekt (talk) 14:29, 16 November 2017 (UTC)

Do you have a specific example of an SVG file (on Wikimedia Commons etc) which got updated and when being able to view such a diff would have been helpful? --AKlapper (WMF) (talk) 21:30, 7 November 2017 (UTC)

It came into my mind just after the previous year’s survey, I don’t remember specific image which I had in my mind ten months ago… But maps like Kosovo relations.svg are good examples: this file’s changes are mainly properly noted (except if the change wasn’t the one stated in the upload comment), but some versions don’t have comment while they—I suppose—are mainly consist of toggling CSS classes, so it’s easily understandable from the textual diff. Also, textual files can be changed in such a way that they are really the same pixel by pixel, but the source code is different (from changing a comment to a major cleanup). —Tacsipacsi (talk) 22:07, 7 November 2017 (UTC)

This seems like a very limited and specific use case, that could easily be addressed with a gadget, that uses an online diff service or something to compare two files, without forcing an extra useless button upon people who won't need it. —TheDJ (talkcontribs) 10:46, 8 November 2017 (UTC)

At least the backend should be done—why would I need to use a third-party service when we have a working diff system? Also, MediaWiki already has many links which I should call bloatware at more visible places like the “beta” link in the personal toolbar (one can easily get there from the preferences; or why don’t we have separate links for all preferences tabs?). OK, make it opt-in, but do it in PHP—it’s not easier to do client side than the sandbox link, which is not even opt-out. Please do not mark it as nonsense or useless ab ovo, just vote against it in the voting phase. It may turn out than that nobody else would need this feature. —Tacsipacsi (talk) 22:15, 8 November 2017 (UTC)

I'd think a state-of-the-art visual compare tool would address a wider audience, although it wouldn't be completely equivalent. It would be more intuitive for non-nerds and it's often more important to get help spotting inconspicuous visual changes than calling attention to some purely technical rearrangement of internal data structures. I'm picturing something that shows two images on top of each other and a visibility seam between that you can grab and slide around like here, and maybe some compensation mechanism to disregard if content was just shifted around on the page.--Reseletti (talk) 15:59, 9 November 2017 (UTC)

Yes, a visual diff might be more important. It’s also better because it can work for all image types (but still not for other media types: videos, sound and multipage documents like PDF and DjVu). —Tacsipacsi (talk) 21:26, 9 November 2017 (UTC)
This makes sense for PNGs and GIFs because they are losslessly compressed, but JPEG quantization has real potential to make visual diffs a dog's breakfast. MER-C (talk) 03:51, 10 November 2017 (UTC)
The above example works also for JPEG, as it doesn’t compare the images by itself, rather makes the user easier to do so. —Tacsipacsi (talk) 14:31, 10 November 2017 (UTC)
Reseletti, Tacsipacsi, MER-C If you are enthusiastic about an option like that, please make sure to submit it as a SEPARATE proposal. —TheDJ (talkcontribs) 10:35, 13 November 2017 (UTC)
  • Expanding on this: general SVG uploading via text would be very good to have too. It is a format that should and could be changed very easily, but currently we are stuck with a system that doesn’t serve its needs well enough despite it gaining traction for the usage in all kinds of graphics. stjn[ru] 21:13, 11 November 2017 (UTC)
  • For years I was struck by how strange it is when people are trying to improve existing SVG files by tweaking their source-code and we have no good way of comparing before and after versions. --Jarekt (talk) 14:29, 16 November 2017 (UTC)

Variable size of Commons categories

Edit proposal/discussion

  • Problem: Currently there is a strict restriction of 200 images per page of a commons category. For working, especially for housekeeping, but also for worling on articles etc. it would be very helpfull, if users could change the limitation of images.
  • Who would benefit: Every user who works a lot on Commons. Scrolling through 200 image pages of very large categories is time consuming and unnerving. In both cases, maintenance and looking for images.
  • Proposed solution: There are in my eyes two possibilities for logged in users: 1st is a mask, where users can free write the number of images they would like to see on one Category page. So I could say, I want to see 40, 50, 100, 120, 200, 250, 500, 788 or 1000 images in one page. Or, 2nd possibility: Commons set some standard numbers as button f.e. 50, 100, 250,, 500, 1000. Best would be in my eyes a combination of both.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

  • This is basically phab:T13281. Anomie (talk) 16:42, 13 November 2017 (UTC)
    I made this request already two times - but it's still an ongoing request. For my work this is so much needed and deserved. And to wait until maybe sometimes somebody came, is hopefully not the way, that is needed to go. Marcus Cyron (talk) 18:17, 13 November 2017 (UTC)

Support 360 photo viewing

Edit proposal/discussion

  • Problem: As last year: 360 and panorama photos is a mainstream media type. Articles & MediaViewer do not support it unless we direct users to toolsforge.
  • Who would benefit: readers and editors of wikis/Wikipedia technical articles, architecture and nature related articles would benefit. Also a good way to view panorama photos on mobile devices, where panoramas otherwise are real small
  • Proposed solution: Add support for Mediawiki to record the perspective of an image, either by reading the exif information, or by using a magic word. Add support in the front end to use panellum (example category).
  • More comments:
  • Phabricator tickets: phab:T151749. there is some open task in phabricator related to this ;[1] [2] [3]

Discussion[edit]

  • this request is pretty urgent, not only because of the mainstream panorama movement, but also because environments can be seen and appreciated much better when viewed in 180° or 360°. a current example is the educational VR documentary about chernobyl. in the app you are in the abandoned buildings, you see the dimensions exactly. all the abstract art of photography with its selective angle and focus is trivialized by surround photography. it tells the truth. excellent for an encyclopedia. [from what i heard, wiki loves monuments has something like that in the pipeline.] Maximilian Schönherr (talk) 17:07, 10 November 2017 (UTC)
  • I support it. This type of media are more popular for new generation, which we need to hit also. More over it helps to study some object.--Juandev (talk) 07:09, 11 November 2017 (UTC)
  • Excellent idea. Doc James (talk · contribs · email) 22:11, 13 November 2017 (UTC)
  • anyone care to adopt this proposal ? I have too many, so I need to drop this one. —TheDJ (talkcontribs) 22:55, 13 November 2017 (UTC)
    I'll adopt :) — MusikAnimal talk 17:10, 14 November 2017 (UTC)
  • Considero que es un formato cada vez mas utilizado, un gran modo de documentar, y tiene mucho mas llegada en su formato de visualización esférica que desplegada. TitiNicola (talk) 12:55, 14 November 2017 (UTC)

Use native audio player

Edit proposal/discussion

  • Problem: Current audio player is created for video files, and includes advert of "KALTURA"
  • Who would benefit: All community
  • Proposed solution: Use html 5 player
  • More comments:
  • Phabricator tickets:

Discussion[edit]

Issue since at least 2010:

https://phabricator.wikimedia.org/T25965

Geni (talk) 08:43, 18 November 2017 (UTC)

Upload-Wizard should remember the uploaders name

Edit proposal/discussion

  • Problem:

Whenever I upload a self-taken picture to Commons with the Default-Uploaderpage ("Upload-Wizzard"), the name with the name of the author contains my username but I want my real name to be specified there. So every time I have to replace my username by my real name. It's especially annoying since the auto-fill of the Browser does not work in this field.

  • Who would benefit:
  • Proposed solution: Since the name of user rarely if at all changes it would make sense for the Upload-Wizzard to remember the given name.
  • More comments: Could be saved in Cookie or on server-side, I don't care but please save it.
  • Phabricator tickets:

Discussion[edit]

  • Endorse, in fact there should be several options like “upload with your signature” (WikiSignature), or any way you like it, like for example “Joseph Smith (b. 1973)” in case someone finds that important, this should be a custom option in preferences. --Donald Trung (Talk 🤳🏻) (My global lock 😒🌏🔒) (My global unlock 😄🌏🔓) 12:04, 12 November 2017 (UTC)
  • Endorse Vera (talk) 20:48, 12 November 2017 (UTC)
  • +1. I have a 'Creator:' template, so that should be remembered, too. And obviously overwriteable, if the user is uploading third-arty images. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:27, 15 November 2017 (UTC)
  • Small issue but good idea. --Jarekt (talk) 14:31, 16 November 2017 (UTC)
  • And remember not to link to the entire name, maybe? What I want for Commons is to have both my name and my user name, but only link to the user name: "Johan Jönsson (Julle)". /Julle (talk) 15:24, 16 November 2017 (UTC)
  • This already has a Phab ticket and a patch, which is being addressed now. https://phabricator.wikimedia.org/T154154 RIsler (WMF) (talk) 00:55, 18 November 2017 (UTC)
  • Endorse, · · · Peter (Southwood) (talk): 09:48, 18 November 2017 (UTC)

Fix problems that FlaggedRevs wikis have with Commons

Edit proposal/discussion

  • Problem: The common problem for all Wikimedia wikis that currently use FlaggedRevs extension (there are currently 45 of them) is that almost every change at Commons at any scope (even a page edit) brings more work to reviewers across the projects that use files from Commons: Холодный Яр − the page after an edit at Commons immediately deems itself unstable and the only way to fix this is to waste time of editors by rereviewing it again manually. It is because FlaggedRevs does, justly, think that any transclusion that is not in a reviewable namespace makes a page unstable, but it is not right to neglect the fact that images from Commons are currently used in thousands upon thousands of pages in 45 Wikimedia projects. Given that this problem persists almost for 10 years in some cases, I propose that we should find a solution already that would satisfy both wikis with and without FlaggedRevs extension enabled.
  • Who would benefit: Reviewers and readers at wikis that have FlaggedRevs extension enabled
  • Proposed solution: Fix the problem of cross-wiki transclusion or enable FlaggedRevs at Commons for all users, if the latter would help (the solution can be technical and all edits can be reviewed automatically for all users).
  • More comments:
  • Phabricator tickets:
  • Proposer: stjn[ru] 11:24, 14 November 2017 (UTC)

Discussion[edit]

Fix Gallery slideshow

Edit proposal/discussion

  • Problem: The slideshow option of the gallery-tag has some bugs that basically prevent it from being usable.
  • Who would benefit: Readers and editors
  • Proposed solution: Fix these 4 annoying bugs:
    • Slideshow is sometime completely different in edit preview than on saved page - phab:T151471
    • You can't specify the size of the images (heights and weights parameters are ignored) - phab:T154013 (VE)
    • The images are often slightly sharp
    • Images sometime don't fully load but stay extremely blurry.
  • More comments:
  • Phabricator tickets:

Discussion[edit]

  • @MichaelSchoenitzer: Could you add links to any existing phabricator tasks, for these issues? or create new tasks that give details on each problem. Thanks! (We discourage abstract "fix all the things with X" proposals, but I think a limited and specific list like this one might be ok.) Quiddity (WMF) (talk) 19:51, 17 November 2017 (UTC)

Support CSS files associated to SVG as media files

Edit proposal/discussion

  • Problem: There are a number of svg maps presenting statistical information or locations for countries or regions. Every time a new information is presented the map is duplicated and adapted to the information to be shown. This leads to several problems: (1) increases the size of data to be stored - the same geographical information is copied every time (2) requires skills to manipulate these images using software or knowledge of the svg format and (3) requires several images to be corrected if the basic geographical information is changed. As an example the following maps are based on the same geographical information but present different data. Each time the map of 12 MB is copied and modified:

CSS files associated to svg images can be used to present information without changing the svg file. Entities from the picture can be coloured using their ids in a separate file. This file than can be used in association with the basic svg as a picture instead of creating new image every time. A simple text editor can be used to manipulate data given that the basic svg is formed in a convenient manner.

  • Who would benefit: Wikimedia Commons, editors
  • Proposed solution: Allow CSS files associated to svg files to be used as media.
  • More comments:
  • Phabricator tickets:
  • Proposer: Ikonact (talk) 14:54, 14 November 2017 (UTC)

Discussion[edit]

Automatic display of attribution and license information

Edit proposal/discussion

  • Problem: We currently do not display any attribution, license or other common types of multimedia metadata when illustrating Wikipedia articles - we rely on the manually written contextual caption and users clicking the image to see any metadata. Yet, we expect third-party re-users of our materials (e.g. in news websites) to overtly display the free-license information, the photographer's attribution, or at the very least the words "via Wikimedia Commons" with a link. This is inconsistent. If we want people to respect free licenses and attribution metadata we should be upholding best practices ourselves.
  • Who would benefit: Readers of illustrated Wikipedia articles, Commons photographers and other multimedia creators, re-users of free-licensed materials, the 'unseen' Commons users who regularly clean up messy metadata.
  • Proposed solution: Create a UI (it could be a 'hover over', or small/semi-transparent font, or some other design) that displays the key licensing and attribution metadata for any file being embedded from Commons, on Wikipedia (or other sister-site). This includes: Author, year, license. This would not replace or distract from the contextual caption in the Wikipedia article but supplement it. When applicable this metadata could also include the relevant institution e.g. a space agency, or a GLAM.
  • More comments: Norwegian (Bokmal) has a version of this already within their standard image template called "credit line". However it is manually written, and therefore duplicates the metadata on Commons.

This builds on the work of the 2014 File metadata cleanup drive which aimed to ensure that all files, especially those used in WP articles, have machine-readable metadata. By making the metadata more visible, Wikimedia editors will be incentivised to ensure that the information on Commons is accurate.
The work of the "Structured Data on Commons" project would benefit from this as it would increase the inter-project visibility of our own metadata, decreasing barriers between the sister projects.
There would be a lot of edge cases - such as "photograph of a painting in a book, uploaded by a museum" where the licensing/attribution metadata would be multilayered. However, if there's ANY community in the world who can discuss and come to a consensus about licensing/attribution copyright edge cases, it's the Commons community!


  • Phabricator tickets:

Discussion[edit]

  • Mediaviewer already does this right ? And Wikipedia itself discourages from doing it more 'inline' of the article.. —TheDJ (talkcontribs) 14:38, 15 November 2017 (UTC)
  • Is the "we expect third-party re-users" sentence accurate, or is it merely that we expect reusers to follow the terms of the images' licenses, which in the case of CC-BY licenses requires the attribution be made "in any reasonable manner based on the medium", which for traditional news sites and paper publications differs from that for MediaWiki-based wikis? Anomie (talk) 15:18, 15 November 2017 (UTC)
  • I remember this has been talked about for a long time, in cycles, on svwiki, and a solution would have saved many hours and kept a couple of good photographers from leaving. I found some notes from a meetup in 2010 where an automatic solution was discussed and liked. Ainali (talk) 17:00, 15 November 2017 (UTC)
  • Yes that could be one of benefits of Structured Data on Commons effort. --Jarekt (talk) 14:36, 16 November 2017 (UTC)

Upload and instant conversion of mpeg and avi etc

Edit proposal/discussion

  • Problem: As per Commons:Commons:File types: "Patent-encumbered file formats are not accepted at Wikimedia Commons... Examples of patent-encumbered file formats are AAC, WMA, MPEG and most AVI codecs. Our mission requires content to be freely redistributable to all. Patent-encumbered formats fail to meet this standard."
    Yet these are popular file types, and the outright refusal of Wikimedia to receive such files impedes the growth of the project.
  • Who would benefit: All projects and viewers.
  • Proposed solution: Have a built-in converter instantly turn such file uploads into an open format.
  • More comments:

Discussion[edit]

  • Video2Commons does that. Yann (talk) 15:34, 9 November 2017 (UTC)
    • I guess that one could be improved a lot: It encodes to WebM with old VP8 and Vorbis. We could readily use the much-improved formats VP9 and Opus. It doesn't directly encode the files for all the different quality levels. They are reencoded on Commons, once again, because there's no integration. When sourcing from YouTube, it will reencode (lossy) instead of using their WebM file(s) directly. It doesn't even recycle their Opus audio tracks. So it doesn't even check if the files it's fed are already in the right format. Does it keep the original file around for later reencoding? Quality loss, loss, loss.--Reseletti (talk) 17:33, 9 November 2017 (UTC)
    • (Somebody should task a bot with replacing all those video files that this tool reencoded out of YouTube videos with YouTube's WebM files directly out of youtube-dl).--Reseletti (talk) 19:25, 9 November 2017 (UTC)
    • Videoconvert (by User:Prolineserver) does that too, with thousands of videos uploaded since 2014. See also one user's recent comparison of these two and other tools, pointing out various usability issues. Regards, Tbayer (WMF) (talk) 00:49, 18 November 2017 (UTC)
  • This is particularly important for mobile users--it's possible to upload still images from a phone, but there's no automated MP4 conversion which can allow uploading videos from a phone, so you have to download to a computer, encode using ffmpeg or the like, and re-upload, which is significantly more complex. Grendelkhan (talk) 23:30, 9 November 2017 (UTC)
  • There's some history here to keep in mind. 😂 (talk) 00:13, 10 November 2017 (UTC)
  • We used to have this feature in UploadWizard, relying on the Firefogg extension for Firefox, but that is no longer possible since Firefox removed support for it. We have phab:T157319 about implementing a replacement, I'll link that to this wish. Matma Rex (talk) 16:34, 13 November 2017 (UTC)
  • It seems to me that this would first require the community to change their consensus on NOT permitting the WMF to work on this option, as noted in the RFC linked to by User:😂-emoji —TheDJ (talkcontribs) 14:36, 15 November 2017 (UTC)

Image recognition and tagging

Edit proposal/discussion

  • Problem: Image description and categorising is way too long work, that many users, don't do it.
  • Who would benefit: Wikimedia Commons, Wikipedia, contributors
  • Proposed solution: There are two solutions, which may be used alone, or combined. One is to retrieve some information from GPS. If the GPS is harvested by camera, it is usually not correct, but we can get an estimate for a place, where picture was taken (in which settlement (village, municipality)). This estimate may be written to the file description and from this estimate can be created a category. At the same time, we may tag those files with a template announcing this technology was used and this information should be controlled by a human. If the coordinates are set manually the guess is more precise more likely correct.

The other technology is the image recognition provided e.g. by Google, which recognised basic objects (church).

Combination of these technologies, may provide better recognition (Church of St. Peter).

  • More comments:
  • Phabricator tickets:
  • Proposer: Juandev (talk) 21:03, 8 November 2017 (UTC)

Discussion[edit]

As someone who categorizes images, I welcome any information that can be generated automatically from the GPS coordinates. Often the building or village name is not enough. Sometimes the city name is not enough. The Panoramio and Flickr tags are often not enough. I have to know the province or district or country name, and the only way to find that is to load a Google map. I agree that the automatically generated information should be tagged as temporary within the file, or alternatively the image should be placed in a category requiring human attention. Downtowngal (talk) 03:16, 9 November 2017 (UTC)

Yup, thats correctly said: category requiring human attention.
Anyway if you have a village name, we/they can automate to provide categories of higher administrative units, as we are able to write a code, which will do it.--Juandev (talk) 09:37, 9 November 2017 (UTC)
Even having a country or region name would be useful in order to narrow it down. Commons has a huge backlog of uncategorized images and media, some of which could be auto-tagged based on GPS info, and then placed in commons:Category:Media_needing_category_review (or perhaps even location-based subcategories, for instance, "Media needing category review geotagged in India") for human review. Dragfyre (talk) 18:26, 9 November 2017 (UTC)
I have been just a little bit digging in this area. Coders know two ways of recognition and tagging. One is provided by Google. They provide 1000 image/month/user in Google Cloud for free and than each image for some cents of USD. But I have seen around internet other companies, who work on recognition. As far as I know, they work for business and develop recognition for them. So the technology of image recognition is probably widely know. I don't think so, our devs of WMF would work on its own recognition bot, but we may test the technology on those 1000 free recognised images by Google and then if there is a high success rate WMF may negotiate a partnership and negotiate some mass usage.
The other way of recognition is done somehow via search and I don't know much about it, how it works, I have seen just an example. I guess weather this harvest all available data and metadata about our image (image on Wikimedia Commons) and than using the algorithm to try to find out most probable depiction. But this is just guessing. Maybe they do it via coords, because there is free tool called Jeffrey's Image Metadata Viewer, which do this work using coords of the images and different map application, to name photographer position. In this case you get the house number. So the expample for the file.jpg might be: Czech Republic, Klatovy Region, Klatovy District, Train Street no. 44, i.e. Country, NUTS x, NUTS x, Street, House number.
But the question is how precise is the automate coordination harvest. For those, who add coords, getting them from satellite imagery and adding also the way of which the photograph was taken, may this be very useful and precise. I wonder if we are able to write the address of the photographer position in words, that it might be possible to write other objects in words using POI (like Church of St. Peter). There is also a technology, which can show and write down all objects in the way in which photograph was taken. It can also remove non visible objects caused by elevation, but it probably is not ably to hide non visible objects, behind human construction. So, if there is a picture of house and there is a Church of St. Peter behind this house, but it is not visible on this image, because the house hides it, the code is able to say there is the Church in the range, but I am not sure if the code can also say that in this case is not visible, because there is a house in behind. This tool is called Hey Whats That!--Juandev (talk) 20:29, 9 November 2017 (UTC)
In the case of location tagging, categorization needn't be too precise. Geotagging on some phones isn't always so accurate in the first place; if you're in an area with poor cell coverage, for instance, a photo you take might be tagged with a location that's several kilometres away from your actual position. In most cases, though, it'll at least be in the same country or region: The coordinates may not tell me the correct street or town it was taken in, but I may know it's in Maharashtra, which is in India. Even drilling down this far will help a great deal with categorization. Dragfyre (talk) 18:34, 10 November 2017 (UTC)
I support Dragfyre's suggestion of location-based subcategories "media...geotagged in India." For popular names like "San Fernando," that tells us which country it is in. It directs people with expertise in that country to work on that subcategory. However, for countries with many English-speaking Wikipedians who participate as uploaders and categorizers, a lower level subcategory (state, province, region) would speed up categorization. If I know that all the images are in, for example, Florida, my work will be faster than if I only know they are in the United States. I have a question about this proposal. Often people upload several images from one location. Will there be a way for the categorizer to know that images 4, 19 and 25 tagged "Florida" are from the same upload, without looking at each individually? Can we at the same time be shown a map with the geotagged but unclassified images pinpointed, like Open Street Map? Downtowngal (talk) 01:50, 10 November 2017 (UTC)
A map would be a huge plus, but at the same time, I think I'd be happy with a tool that does the categorization. I seem to remember that there are some geotagging tools that will show you all the images in a certain category on a map. I'll have to look it up. Dragfyre (talk) 18:40, 10 November 2017 (UTC)
I want to add something to my comment. The tool used should harvest information from Google or another map that provides all the information (village name, region name, etc.) in English. Why? I want the English spelling of place names, because most of the time Commons categories use English spelling of place names. I don't want a map that uses only the local language, like OpenStreetMap, and generates names with their local language spelling. That is not much help. Downtowngal (talk) 01:37, 10 November 2017 (UTC)
As long as Google's API is usable for these purposes, I suppose. There might be a possibility of incorporating data from Wikidata, too; locations there are generally tagged with their coordinates. Dragfyre (talk) 18:40, 10 November 2017 (UTC)
I just had an idea. Is it possible to sort the images in "media needing category review geotagged in India" by coordinate? I think that ability would be useful to a person who categorizes images. That way, all the images from a single village will be close together. Downtowngal (talk) 01:58, 10 November 2017 (UTC)
Good idea. Dragfyre (talk) 18:40, 10 November 2017 (UTC)
To sort images from Florida by uploader should be possible. Such options have allready "Perform Batch Task".--Juandev (talk) 22:09, 10 November 2017 (UTC)
But I want to sort only images from Florida that have not already been categorized. If the uploader has been active earlier, some of their uploads may already be categorized. Can I restrict my sorting to images in "media needing category review geotagged in Florida"? Also, please remember that the tools should be easy to use for people who are not IT specialists and who are not native speakers of English. I am a layperson and I am afraid to "perform batch task" because if I make a mistake I don't know how to fix it. Downtowngal (talk) 22:40, 10 November 2017 (UTC)
You could make a decent CAPTCHA out of this. MER-C (talk) 07:04, 10 November 2017 (UTC)

Hey all, the Structured Data on Commons team is planning to implement image recognition in 2019 as part of the Structured Data on Commons program. Abittaker (WMF) (talk) 17:01, 13 November 2017 (UTC)

Integrate Pattypan and Quick Statements (Placeholder)

Edit proposal/discussion

Mapping for Commons artwork template vs Wikidata item for a painting

Since it was proposed under Wikidata, I assume it should be left there, but the main issue was proposed last year under the Commons group here: 2016_Community_Wishlist_Survey/Categories/Commons#Upload_wizard_for_uploading_artwork

  • Who would benefit: Commons uploaders and Wikidata item curators for paintings and other artworks
  • Proposed solution: The title says it all; but maybe it should also say "Commons UW & Quick Statements". Basically you want an easy way to upload the metadata of an image to both Wikidata and Commons at the same time (given there is generally overlap for 90% of the metadata, the stuff not in overlap could be defined in some sort of "user profile" or "upload campaign".
  • More comments: please comment on the initial proposal under Wikidata; this is just a placeholder
  • Proposer: Jane023 (talk) 11:35, 15 November 2017 (UTC) (for findability)

Discussion[edit]

Please comment on the initial proposal under the group heading Wikidata, not here 2017 Community Wishlist Survey/Wikidata/Integrate Pattypan and Quick Statements

Extension:Translate for Wikimedia Commons images

Edit proposal/discussion

  • Problem: There are Over 365 000 images on Wikimedia Commons with no description. Many more are without descriptions in various languages. Adding these descriptions is painfully slow, but the Translate extension used well in Translatewiki can make a) adding descriptions much simplier, b) translating descriptions even more simplier. With such a thing implemented (and yes, it is already present on Meta, where it serves really well.
  • Who would benefit: Wikimedia Commons editors and translators.
  • Proposed solution: Installing the Translate MediaWiki extension on Wikimedia Commons. Making it possible so that Special:Translate can display files from a selected category with possible editing windows for new translations.
  • More comments:
  • Phabricator tickets:
  • Proposer: Aktron (talk) 22:14, 8 November 2017 (UTC)

Discussion[edit]

The Translate extension is already installed and is in use on Commons for template internationalization (see for example the big blue button on Template:Welcome). However, file descriptions use a very different format, so the way it works there should be implemented. (Good idea though, if the developers can get it work.) --Tacsipacsi (talk) 22:19, 8 November 2017 (UTC)

Question Question: Won't this be a non-issue with the integration of Wikibase in Commons? NMaia (talk) 00:51, 9 November 2017 (UTC)

Yup, that is an unknown space, how file editing will work after data integration.--Juandev (talk) 09:39, 9 November 2017 (UTC)
As per my understanding, Wikibase will make the data more structured, but not easier to translate large number of descriptions. Integration with the Translate extension would still be useful. –Nikerabbit (talk) 15:24, 9 November 2017 (UTC)
Well if I am thinking again about it, Wikibase will structure date, which can be structured. So e.g. categories and they (WMF) will hopefully develope the way how to add translations to different languages just within WMC. But in the case of descriptions, they have no way to change this object, so here could be integrated the technology of Translatewiki (which is realy good :-)--Juandev (talk) 20:37, 9 November 2017 (UTC)
The Structured Data on Commons team is planning to implement translatable fields in late 2018 as part of the Structured Data on Commons program. Many of the currently unstructured fields will be structured, (depending on what the Commons community wants, but it might look something like this.) So many of the fields, including the description, could be translatable within Commons. Abittaker (WMF) (talk) 17:31, 13 November 2017 (UTC)

Upload wizard for uploading artwork template

Edit proposal/discussion

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

Discussion[edit]

Made a related proposal at 2017 Community Wishlist Survey/Multimedia and Commons/Improve UploadWizard campaigns. Multichill (talk) 17:17, 17 November 2017 (UTC)

Allow exploration of categories at upload time

Edit proposal/discussion

  • Problem: Category selection via the upload wizard on Commons performs autocompletion, which is helpful, but doesn't allow for walking the category tree, so finding a more specific, more general, or sibling category involves either opening the category in another tab and navigating the tree there, or completing the upload wizard and then using HotCat to refine the categories afterwards.
  • Who would benefit: Anyone uploading and categorizing images to Commons.
  • Proposed solution: Integrate HotCat or something like it with the Commons upload wizard.
  • Phabricator tickets:

Discussion[edit]

Good, clear description of the problem. I agree with the proposed solution. Downtowngal (talk) 23:49, 10 November 2017 (UTC)

  • This would be a huge time-saver! Victorgrigas (talk) 03:04, 13 November 2017 (UTC)
  • HotCat is so much better at this; and has a better interface; surely its code could be reused/ shared? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:14, 15 November 2017 (UTC)

Flexible use of EXIF- and IPTC-data and filenames on Uploads

Edit proposal/discussion

  • Problem: Many photos have useful information in EXIF, IPTC or in he filename. Using them on upload instead of rewriting everything could make uploads more interesting.
  • Who would benefit: Those who want to upload numerous photos and have already put the necessary infos to the file would get a great benefit.
  • Proposed solution: Write a new upload prcedure where the user can define which information is taken from where and such definitions can be saved and reused.
  • More comments: There should be more than one source allowed to fill in one field.
  • Phabricator tickets:

Discussion[edit]

  • UploadWizard already partially does this right ? At least for date and location if I remember correctly. —TheDJ (talkcontribs) 08:19, 9 November 2017 (UTC)
  • Very much agree with this proposal. I currently have to manually add categories such as "taken with Canon EOS 5D Mark III" to my uploads, and this would save me a lot of boring, time-wasting repetition. Just to extend this wish: I would also like "category:Photographs by Thennicke" to be added by default to my list of categories, for the same reason, which isn't actually in the EXIF data. -- Thennicke (talk) 10:37, 10 November 2017 (UTC)

Provide file uploading facility

Edit proposal/discussion

  • Problem:

Today Upload Wizard is providing file by file selection and bulk uploading facility only. It takes much more time and if any interruptions such as power loss, connectivity loss etc. occurred while uploading, all efforts went in vain.

  • Who would benefit:
  • Proposed solution:

Provide file uploading facility like Pattypan.

  • More comments:
  • Phabricator tickets:

Discussion[edit]

UploadWizard lets you select multiple files at once and I think it does as much as it can for parallel uploading. If you can’t select multiple files at once, it’s most likely a browser- or OS-related issue and should be considered as a bug. You can open a task for it on Phabricator or report it on its feedback page on Commons. I don’t know what Pattypan is, could you explain it or provide a link? —Tacsipacsi (talk) 14:09, 11 November 2017 (UTC)

Probably c:Commons:Pattypan. In which case the answer is probably "Pattypan already exists". Anomie (talk) 16:33, 13 November 2017 (UTC)

Client side SVG rendering

Edit proposal/discussion

  • Problem: Currently we show PNG derivatives for all SVG images. As SVG support has expanded significantly, the proposal is to start preferring SVG rendering client side.
  • Who would benefit: More accurate and infinitely scaling detail of SVG resources.
  • Proposed solution: Make SVGs the default when their size/complexity is not prohibitively large and the browser supports it.
  • More comments:

Discussion[edit]

  • Agree. Instead of transferring to user a 4 KB SVG image, we transfer 100 KB PNG render of it. Also, the PNG render sent to user is chosen depending on his screen resolutions, so if he scales in the page, the new render needs to be transferred. --Tohaomg (talk) 20:51, 8 November 2017 (UTC)
    Sometimes, the opposite can be the case, for example File:Flag of Mexico.svg is 220kb while most of its uses are tiny flag icons that weigh just 1kb as PNGs. Max Semenik (talk) 23:47, 8 November 2017 (UTC)
There are lots of much more extreme examples, which goes to say: Filesizes get really unpredictable.--Reseletti (talk) 21:58, 9 November 2017 (UTC)

Rendering may also get less predictable with more diversity in rendering software. Most of the rendering bugs that appear with the current software chain are not present in the browsers I tried, though...--Reseletti (talk) 22:02, 9 November 2017 (UTC)

SVGs are preferred for lossless image quality at any zoom factor, but since we don't actually display SVG, we get blurry images, especially noticeable is then marquee/main image on mobile. Senator2029 talk 00:15, 17 November 2017 (UTC)

Rotate-template

Edit proposal/discussion

  • Problem: Some pictures don't have only one right orientation, for instance an insect that is pictured from upside will apear correct with head up or with head left side. Some writers (for instance me in blocks of pictures) compose the pictures in their articles in a way, that there is only one orientation correct, the other (though also correct) destroys the composition. Now, if a second user wants to use the picture with another orientation, he may use the rotate template, not being aware, that the picture is rotated not only for him, but also for all other users of the picture, who perhaps don't want the picture rotated.

Usually users of the picture before rotation even don't realize, that the picture was rotated, because they won't be informed, they realize the transformation at best by chance. In letter case, you have to restore the old version, put a new rotated one and control all users of the picture, which orientation fits better in their cases. I explained the problem already several times at different places, but did not provoke reactions.

  • Who would benefit: All users, that want to use the picture only in that way, they choose it.
  • Proposed solution: every by bot rotated picture gets a new name, for instance the old name prolonged by -rot.
  • More comments:
  • Phabricator tickets:
  • Proposer: Siga (talk) 14:59, 11 November 2017 (UTC)

Discussion[edit]

Most rotated pictures are correct only after rotation. If you compose an article in which the Eiffel Tower only fits on its side (i.e. rotated by 90°), the article is simply not OK. I know that you have problem with not-so-obvious cases, but if the rotated image is uploaded with another name, this will stay unfixed as well. Even if there’s no composition in the article, which latter means, I think, the 90% of the articles. This proposal would improve the 10% of the 10% of the articles, but the other 99% wouldn’t be improved or would be even worse than now. —Tacsipacsi (talk) 22:00, 11 November 2017 (UTC)

if the picture is obviously wrong orientated, than the one, who loads it up will use the template. And everyone who uses the picure, will use the name of the right version, because the picture is new. On contrary, if the picture is uploaded from person 1 and used from persons 2 ...5 in that way, and afterwards rotated as wish from person 6, person 6 may it use with the new name and persons 7 .... in the orientation and corresponding name they prefer. I see your argument with the 10 % of 10% too, but its a lot of work for the 1 per mille too, to correct the mess, that may be provoqued (and mostly not detected). There would be also the possibility to inform automatically all users of the picture, if the picture is rotated - but this would reach only the activ users. --Siga (talk) 10:33, 14 November 2017 (UTC)

Track changes of files and metadata

Edit proposal/discussion

  • Problem: As a GLAM institution I would like to keep track of what changes to files and metadata are being done after upload. Both to get statistics which might be relevant for further involvement, but also to see if there are changes that could also be brought back to our own databases.
  • Who would benefit: GLAMs (statistics might also be useful for Wikimedia affiliations and in some cases individual users)
  • Proposed solution: A tool on labs that accept a collection of files (at least Category, but also files from a user, pagepiles etc. could be relevant). Stats could include number of new versions of files, changes to file descriptions, changes to categories, changes/additions of coordinates etc. If these changes also were available in a machine readable way (eg. a list of added and removed categories for each edit) it would be great.
  • More comments:
  • Phabricator tickets:
  • Proposer: Ainali (talk) 08:07, 17 November 2017 (UTC)

Discussion[edit]

Category title in suitable language

Edit proposal/discussion

  • Problem: I'm french user (sorry for my English). In Commons, my account specifies the french language. But, the categories titles are displayed only in the language used by the creator of the category (I speak about categories, but the problem is similar for other elements). I can understand this behavior when there is no information about translation, but if contributors (like me) fill the locale models like {{Translation table}} or {{fr}}, these texts are not taken in account for title display (only in content) or search.
    For concrete case, if I search "category:Heraldry", I find. If I search french equivalent "catégorie:Héraldique", I can't find the category. If I search "category:Héraldique", I find a duplicated category. If I search in the search tool, I can find the relevant category at the 371st position.
    For me, this problem encourages users to create duplicated categories in different languages and it is not a good thing for contributors and visitors speaking only one language. It is not pleasant to search in Commons with a bilingual dictionary in the hands.
    The problem is also the same in the list of subcategories. It will be preferable to see the translated version of the category title instead of the original title.
  • Who would benefit: Contributors and visitors will be interested by this feature.
  • Proposed solution: I think that the problem is linked to the data structure of Commons. Maybe it is possible to define the list of models usable for translation and use them.
  • More comments:In fact, I would like to see a similar behavior to Wikidata where it is possible to search, find and see the elements with a text in my language (when defined of course).
  • Phabricator tickets:

Discussion[edit]

I think this problem will be fixed next year. If the tech team will follow their road map, they should test to apply Wikidata on Commons in 2018. Than offcourse category would be in whatever language.--Juandev (talk) 20:44, 9 November 2017 (UTC)

The Structured Data on Commons team is planning to implement structured data fields in late 2018 as part of the Structured Data on Commons program. Many of the currently unstructured fields will be structured and translatable, (depending on what the Commons community wants, but it might look something like this.) In that case, for a file that depicts heraldry, the field for "Depicts" would display as "Heraldry" in English, and "Héraldique" in French, (as long as both languages are listed in the item for heraldry). Abittaker (WMF) (talk) 19:32, 13 November 2017 (UTC)

Improve UploadWizard campaigns

Edit proposal/discussion

  • Problem: UploadWizard campaigns are currently very much focused on photo competitions and are not very flexible. Not very strange because we developed it for WLM 2011. If it would be more flexible it could be used for more custom upload work flows like for example uploading images of art.
  • Who would benefit: People who contribute images (and other media) to Commons and the people who curate Commons.

Discussion[edit]

Enable additional links in the GallerySlideshow

Edit proposal/discussion

  • Problem: In a gallery page I can insert links (to further images in a category or gallery) in the image's captions. Any link is visible and works only in the pages view, not in the GallerySlideshow.
  • Who would benefit: Each User of a Slideshow of a gallery containing such links
  • Proposed solution: Enable the Gadget to show links containd in the captions
  • More comments:
  • Phabricator tickets:

Discussion[edit]

UTRS for Wikimedia Commons.

Edit proposal/discussion

  • Problem: Currently if someone is blocked on Wikimedia Commons with their
  • Who would benefit: Everyone, (1) the blocked users have another way to appeal, (2) the Stewards as they are the only option Wikimedia Commons blocks can be appealed to if users can’t do this locally, basically serving as a substitute arbitration committee for Wikimedia Commons, and (3) every Wikimedia project, as they’re all dependent on Wikimedia Commons for their imagery and other free and open files, and having good photographers and other people return would greatly benefit any lover of (visual) knowledge.
  • Proposed solution: Create a UTRS for Wikimedia Commons, this one would work practically the same as the one on English Wikipedia. This would immediately be an option between contacting administrators locally and contacting “the stews”.
  • More comments: I'm personally not a fan of the system (as administrators can only basically give one answer which is the w:en:WP:SO without ever addressing a single point), but if this gets any users who would've otherwise not been able to appeal their blocks unblocked and help have more good photographs uploaded then even if this would only get 1 (one) photographer unblocked it would be an amazing thing.
  • Phabricator tickets:

Discussion[edit]

Hey Donald Trung, you'd probably want to briefly explain what a UTRS is and how it works. Those not familiar with it on English Wikipedia will probably not support something they don't understand what it is. (: /Johan (WMF) (talk) 23:06, 9 November 2017 (UTC)

  • Do you have a consensus from the Commons community that they want it? Otherwise, there's nothing for developers to act upon. Max Semenik (talk) 00:28, 10 November 2017 (UTC)

Audio/video review tool (for mp3s especially)

Edit proposal/discussion

  • Problem: The Commons community is currently discussing enabling MP3 uploads and next year will be considering whether or not to allow MPEG-2 video uploads. Commons is also currently dealing with a piracy problem (task T129845) and has always had to deal with large amount of copyright violations. The Commons community has never been equipped with effective tools for reviewing new uploads, especially audio and video uploads which are tedious to review and more difficult to identify copyright violations for. Allowing MP3 and MPEG-2 uploads will make this an even more pressing problem.
  • Who would benefit: The Commons community would benefit by having better tools to review and curate their content. Commons users would benefit by having less restrictions on uploading (in the long run) and access to more multimedia content.
  • Proposed solution: The Community Tech team should build a tool similar to CopyPatrol or New Pages Feed, but specifically for reviewing audio and video uploads. The tool should use both internal rules and 3rd party APIs to automatically flag files that are likely to be copyright violations (for example, matching the audio or video signatures of known commercial files, being over a certain size, receiving an abnormal amount of requests, etc.). It should then allow trusted Commons users to easily nominate the files for deletion and remove them from the review queue.
  • Phabricator tickets:
  • Translations: none yet

Discussion[edit]

Unambiguous cases could already be caught during the upload procedure. E.g. we could refuse files like exact duplicates or with known bad hash values right away. This was a proposal here some years ago. What happened to that?..--Reseletti (talk) 22:32, 9 November 2017 (UTC)

file_sha1 was added to Abuse filter in April 2016. Last time I checked, Commons is blocking 150+ known bad hashes. Dispenser (talk) 01:33, 17 November 2017 (UTC)