Jump to content

Community Wishlist Survey 2017/Multimedia and Commons

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2017
Multimedia and Commons
29 proposals, 312 contributors



  • Problem: While interwiki links on Wikipedias are now all handled by Wikidata, Wikidata's support for Commons interwiki links is far more patchy. Wikidata does support Commons interwiki links by a link in "other sites", however it also has commons category and gallery properties and these aren't kept in sync. In addition, Commons only allows one link to Commons, and conflicts can happen about whether this is to a gallery or a category. There are also a lot of manual interwiki links scattered across Commons that have not yet been migrated to Wikidata.
  • Who would benefit: Users and editors of Commons that want to find/use interwiki links
  • Proposed solution: Make more consistent use of Commons sitelinks by bot edits that keep the Wikidata property and site links synchronised. Finish migrating interwiki links on Commons to Wikidata via a bot. Support multiple links to Commons galleries and categories.
  • More comments: There have been some discussions on Wikidata about this, e.g. see [1], however there has been no pathway to implementing this so far.
  • Phabricator tickets:

Discussion

[edit]

Seems similar/the same as Community Wishlist Survey 2017/Wikidata/Stop using string datatype for linking to pages on other projects, which I had some bitching about. (Mostly, it's a community problem IMO.) --Izno (talk) 04:09, 19 November 2017 (UTC)[reply]

Voting

[edit]

Trim webm videos on site

  • 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 c:File:Zondag met Lubach houdt de wereld voor de gek.webm, which was published under a free license by VARA but features a trailer 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:

Discussion

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

Voting

[edit]

Advanced filters for global usage on Commons

  • 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]
How is that a problem? You have to switch pages all the time. Just open another tab in your browser. --Hedwig in Washington (talk) 02:48, 29 November 2017 (UTC)[reply]

Voting

[edit]

SVG-Translate

  • Problem: You have a svg-file in a different language and want to use it, but you don't know how to edit SVG-Files (You can't handle SourceCode, Inkscape has to be installed,...).
  • Who would benefit: User who adds Images to articles, but are not familiar with SVG-editing

Discussion

[edit]

Voting

[edit]

Write geographical data into image files

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

@Sebastian Wallroth: Could you describe more specifically what problem this is intended to solve? Why only include the geographical data? Why not include all the metadata? Ryan Kaldari (WMF) (talk) 22:22, 20 November 2017 (UTC)[reply]
Hi @Ryan Kaldari (WMF): I am in the one-wish-at-a-time mode. I want to have the ability to write all metadata into the file. License, author, location data, file source, tags. This would solve the problem that files found in the wild do not contain the information for people who wish to re-use the files. --Sebastian Wallroth (talk) 17:42, 21 November 2017 (UTC)[reply]
  • There are several kinds of "location data". For photographs, there is the position (and orientation of) the camera and there is the position of (if relevant) the subject of the photo. Usually the location embedded in a photo is the former and if not present, it is often very hard for someone other than the photographer to determine accurately. I am concerned, for example, that someone sets the location description of a bunch of photos of the London Eye and this is embedded into the photos, when in fact the photos were all taken from different places, some looking at and some on the London Eye. Btw, if the JPG already contains GPS location when uploaded, the image description page is taken from that. There is other meta data that one could add from the file back to the image, not just GPS. However doing this increases the risk of damaging files when users make careless or disruptive edits to pages on Commons. So I don't think this is such a commonly needed feature that it is worth the risk that someone uses VFC to insert vandalism into JPGs or worse, to "out" a user's location into their JPGs. -- Colin (talk) 15:56, 29 November 2017 (UTC)[reply]

Voting

[edit]

Write license data into meta data of image files

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

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

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

The common concern about this is file size overhead for small thumbnails. --Tgr (WMF) (talk) 01:05, 20 November 2017 (UTC)[reply]

Voting

[edit]

Textual diffs for SVGs

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

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

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

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

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 (talk • contribs) 10:46, 8 November 2017 (UTC)[reply]

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

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

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)[reply]
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)[reply]
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)[reply]
Reseletti, Tacsipacsi, MER-C If you are enthusiastic about an option like that, please make sure to submit it as a SEPARATE proposal. —TheDJ (talk • contribs) 10:35, 13 November 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

Voting

[edit]

Flickr-like uploader

  • Problem: Although there are various uploaders available: Upload Wizzard, Commonist, Vicuna, Pattypan... what we are missing is an uploader that will have the basic functionalities of Flickr. What does that mean? A simple workflow: 1) Choose files from a folder, 2) see thumbnails in the uploading tools, add filenames, categories and descriptions (everything else can be added automatically, like usernames or licence). Put it in the browser and make it as simple as possible for people to use. The uploading is happening DURING description of the files so that time delays are minimized.
  • Who would benefit: Commons newbies, users that are not familiar with wikicode and those who can be easily distracted by complicated uploaders. People who want to do things simply.
  • Proposed solution: Description of the proposed tool according to the principles used by the Flickr browser-based uploader tool and then writing the tool.
  • More comments:
  • Phabricator tickets:

Discussion

[edit]
It't the kind of "improvement" that might end up rewriting the whole thing :)--Strainu (talk) 23:07, 27 November 2017 (UTC)[reply]

Voting

[edit]

Allow video uploading from mobile

  • Problem: Currently there's not a straightforward way of uploading video to Commons from a mobile phone, and we must rely on other tools to convert it to webm or ogv. This makes video uploading very far from user friendly.
  • Who would benefit: Video creators, Commons users and, lastly, Wikipedia readers, who could find more relevant videos on articles.
  • Proposed solution: Maybe merging the video2commons system into file uploading.
  • More comments:
  • Phabricator tickets:

Discussion

[edit]

Voting

[edit]

Variable size of Commons categories

  • 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:

Discussion

[edit]

Voting

[edit]

Support 360 photo viewing

  • 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: Proposed in the 2016 survey by Ahm masum, ranking at #15 overall with 58 support votes.

Discussion

[edit]

Voting

[edit]

Use native audio/video player

  • Problem: Current audio/video player is very outdated, additionally the audio player is designed for video playback only. It looks horrible on modern high resolution displays. The player also includes an advert of "KALTURA".
  • Who would benefit: Readers (user experience) and editors (having better looking and more functional pages) alike.
  • Proposed solution: Use native HTML 5 <audio>/<video> controls.
  • More comments: roughly 5% of users' browsers don't support native audio/video[2][3]. We can serve them the old player, or - in the worst case - we can sacrifice being able to play audio/video for them for the sake of vastly improved experience for the rest 95%.
  • Phabricator tickets:

Discussion

[edit]

Issue since at least 2010:

https://phabricator.wikimedia.org/T25965

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

The presence of Kaltura ads looks like a very serious issue, but it can be solved easily on the short-term via local Common.css (as en.wp has already done), and on the longer-term, it looks like the Kaltura player is planned to be replaced by Video.js: phab:T100106. --Yair rand (talk) 17:27, 20 November 2017 (UTC)[reply]

@Borys Kozielski:, I've merged my proposal here because the current player is the same for both audio and video, so it will have to be worked on at the same time. Hope you don't mind. Max Semenik (talk) 01:25, 23 November 2017 (UTC)[reply]

From the merged in proposal:

I don’t know what HTML5 is capable of, but a link to the file description page is needed for copyright reasons, subtitles have no point if they can’t be used, and the quality selection is also useful. —Tacsipacsi (talk) 13:45, 20 November 2017 (UTC)

@Tacsipacsi:, definitely. The native controls will have to be augmented with copyright information etc and that would still look and feel a billion times better than now. Max Semenik (talk) 01:25, 23 November 2017 (UTC)[reply]
I’d like to have a definite “yes” from someone before we start to vote for it, though. Or modify the proposal to use native HTML5 player if it’s feasible, otherwise fork the Firefox/Chrome player (which?). —Tacsipacsi (talk) 13:18, 23 November 2017 (UTC)[reply]
Native HTML5 does support subtitles. --Tgr (talk) 07:05, 28 November 2017 (UTC)[reply]
And the other two (attribution link and manual quality selection)? —Tacsipacsi (talk) 12:23, 28 November 2017 (UTC)[reply]
Comment Comment Sounds reasonable for video files, but for audio files, I'd still prefer some kind of waveform/spectrogram visualization thingy like freesounds.org does it, at least for the file description pages (phab:T103527). --El Grafo (talk) 13:52, 6 December 2017 (UTC)[reply]

Voting

[edit]

Fix problems that FlaggedRevs wikis have with Commons

  • 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:

Discussion

[edit]

To be clear, you'd like Commons images to be treated as always reliable (reviewed)? --Tgr (WMF) (talk) 00:35, 20 November 2017 (UTC)[reply]

@Saint Johann: ^ ? Ryan Kaldari (WMF) (talk) 22:51, 20 November 2017 (UTC)[reply]
  • This is one of the options, yes. There aren’t any solutions for watching over changes in Commons images from files anyway, so it’s not like any reviewers can affect the situation in any way. Especially if the changes are not in the files themselves but in the pages that are describing them (it also triggers the rereview). stjn[ru] 22:59, 20 November 2017 (UTC)[reply]

Voting

[edit]
  • 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]

Voting

[edit]

Turn Stereoskopie into a MediaWiki Extension

  • Problem: With the advent of the IPhone X and the Windows fall creators update people are moving toward a widespread usage of augmented reality applications. If Wikipedia doesn't start to prepare for the future now, people may at some point still read texts that originate from wikipedia, but are presented by social media platforms and presented with non-free media, that was not uploadad to Wikipedia, but to proprietary non-free repositories.
  • Who would benefit: Photographers and Videographers, who can start to contribute content for future AR use, authors who can use VR content, readers, who can view Wikipedia in 3D, deverlopers, who have access to a large repository of 3D content
Dem Wahren Schönen Guten (Click image to view in 3D)
  • Proposed solution:
    • add media type jps to allowed upload formats in commons.
    • tag uploaded videos in cardboard, sbs and ttb formats in Commons as 3D.
    • turn toollabs Stereoskopie into a mediawiki extension
    • support viewing of 3d media in MediaViewer
    • make the android app functional (modes for single device, 2 devices, viewing of content)
    • add apps for iOS and the discontinued WinMobile and Blackberry platforms (or create a Arduino HID project to release cameras via KeyEvent.Volume_Up)
    • make the stereoskopie desktop app functional
    • empower kiwix to support VR
    • integrate with 360° images (→ Wishlist proposal) (funny: ° == Gradzeichen :-)
A Wiki-article employing threedimensional media
  • More comments:
    • Stereoscopy has always suffered from two problems: The sparse availability of affordable cameras. And the problem, that the recording system had to match the viewing system - and for both parts there always was a large number of systems to choose from. This proposal addresses both fields:
      • An app is offered, that turns every camera, that can be controlled with bluetooth or wifi into a stereoscopic camera. And every pair of pictures (old stereoscopic pictures already available at commons, pictures that have been taken with a single camera, that has been moved between to takes) can be converted into a jps-file with the desktop-app.
      • One source (an image in the standard jps-format, a video in sbs, cardboard or top&bottom format) can be played out in basically every thinkable 3D-system (cardboard, 3DTV, pol (cinema system), prisma, anaglyph with any color code and also with systems, that do not require glasses at all: lenticular, crossed eyes and holographic pyramid). New playout-variants can be added and will work with existing content.
    • The Stereoskopie project is unfinished. A conversion to PHP, load scaling, robust caching and a Wiki-CI UI will need to be made. Content on the demo page will be added before voting starts.

Discussion

[edit]

Voting

[edit]

Support CSS files associated to SVG as media files

  • 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:

Discussion

[edit]

Probably doable with the Graph extension? Ping @Yurik: --Tgr (WMF) (talk) 00:41, 20 November 2017 (UTC)[reply]

Yes and no. I don't think you can customize the SVG files, BUT you can store the file as geojson (using .map on commons), and customize its visualization (e.g. specify which region should be shown with what style). Also, graph could allow you to draw an image, and draw things on top of it. --Yurik (talk) 20:14, 20 November 2017 (UTC)[reply]
Hi, thanks for the comments. I think Graph is a good tool and may be very useful. I do not know how practical will be to present the examples above with 36538 occurrences of polygon elements. --Ikonact (talk) 09:23, 21 November 2017 (UTC)[reply]
This would depend on whether our SVG renderer (librsvg) can support external CSS. I'm not sure whether it can or not. Would be good to test. Ryan Kaldari (WMF) (talk) 23:07, 20 November 2017 (UTC)[reply]
That's a good question. I suppose a way to do this is to save locally the svg file with the css included before render it. --Ikonact (talk) 09:23, 21 November 2017 (UTC)[reply]
Note, we intentionally disable network support in librsvg for security reasons (Which is why for example including external images aren't supported except by data: uris). BWolff (WMF) (talk) 23:04, 28 November 2017 (UTC)[reply]

This is a cool use case but I'm not sure how the implementation would look - we don't have any clean way of handling multiple files as one media item, and working around that would make our media handling code more hacky, and it's already a DX horror show. So I am mildly against this - maybe in a few years it can be implemented cleanly on top of MCR --Tgr (talk) 06:31, 28 November 2017 (UTC)[reply]

It would also mean that users would not be able to download a standalone file that just worked, which seems unfortunate. BWolff (WMF) (talk) 23:04, 28 November 2017 (UTC)[reply]
Can still screen-grab it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:00, 4 December 2017 (UTC)[reply]

I would REALLY appreciate this -- I recently made a similar wish in the German WP (or at least parked it because I missed the deadline). -- Christallkeks (talk) 13:00, 6 December 2017 (UTC)[reply]

If anyone's still watching this: I submitted a wish very similar to this one for this year's survey -- Christallkeks 30th October 2018

@Viciarg, Ikonact, Liuxinyu970226, Draceane, Iliev, Thomas Obermair 4, Donald Trung, Swpb, Giovanni Alfredo Garciliano Diaz, Uglemat, Alexmar983, Talmoryair, LikeLifer, Reneman, Psychoslave, Martin Kraft, and יונה בנדלאק: Sorry for the spam, but you may want to vote on my very similar wish for this year's survey: VOTE HERE -- Best wishes, Christallkeks (talk) 13:23, 17 November 2018 (UTC)[reply]

Voting

[edit]

Automatic display of attribution and license information

  • 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 (talk • contribs) 14:38, 15 November 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Yes that could be one of benefits of Structured Data on Commons effort. --Jarekt (talk) 14:36, 16 November 2017 (UTC)[reply]
    We already have structured data for this (and it's already displayed in dedicated image viewers like MediaViewer or the mobile app lightboxes or the slideshow gadget on Commons). The question is to what extent should the information be forced on the reader (who typically does not care). The status quo seems like a good trade-off to me in that regard. --Tgr (WMF) (talk) 00:46, 20 November 2017 (UTC)[reply]
    I assume that since you're saying this as a software developer from your WMF user-account, that you're vetoing the idea? Wittylama (talk) 20:43, 2 December 2017 (UTC)[reply]
  • Currently we don't show proper licence data on the page where the pictures are shown. We rely on linkage to some completely different webpage, called commons, where this data is stored. On the other hand there are photographers who sue users of pictures, who behave in the same manner (link the picture to commons without any more attribution), for a four-digit Euro-value because of massive copyright infringement. OK, there is this far-fetched construct, that Commons and WP are all the same project, despite all this different URL, communities, rules etc., but that's just wikilawyering and sophistry, not helpful at all. It would be helpful, if we behaved in a manner, that could be used as a blueprint for any reuse. If anyone uses a picture anywhere in the same way as in any WP, it should be fine and legally proof. Grüße vom Sänger ♫(Reden) 13:00, 20 November 2017 (UTC)[reply]
I only assume they sent threatening letters via lawyers to users of the pictures, who make minor errors in attribution, and hope for massive payment. It's antisocial, it's perhaps not even legal, but it seems lucrative enough to act this way. Grüße vom Sänger ♫(Reden) 22:42, 26 November 2017 (UTC)[reply]
  • There is something to learn in this from WM-DE's "Attribution Generator" . Wittylama (talk) 20:41, 2 December 2017 (UTC)[reply]
  • Semi-transparent text placed on the embedded image permanently would be annoying (also if only very small on the side or bottom). Information displayed while hovering would be O. K. but I'd prefer either a small credit line below the caption (like in the Norwegian (Bokmal) wikipedia (example) but with all licensing information suggested or requested by the license and, if requested, attribution data) or licensing/attribution-symbol, that shows the information wile hovering over it and after clicking on it (a click may lead to the description page in commons, or to a pop-up window/dialogue showing the relevant information). Especially for the print-version of a page and for the PDF-version I regard it as relevant to give all the information on the page itself so that it's gets printed on paper (maybe with a separately styled footnote at each embedded image/media-file an the corresponding information at the bottom of the last page), so that a user has all necessary information directly from the paper also when he's steadily offline. --X:: black ::X (talk) 10:59, 11 December 2017 (UTC)[reply]

Voting

[edit]

Upload and instant conversion of mpeg and avi etc

  • 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]

Voting

[edit]

Upload wizard for uploading artwork template

  • 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 Community Wishlist Survey 2017/Multimedia and Commons/Improve UploadWizard campaigns. Multichill (talk) 17:17, 17 November 2017 (UTC)[reply]

Voting

[edit]

Allow exploration of categories at upload time

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

Voting

[edit]

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

  • Problem: Many photos have useful information in EXIF, IPTC or in the 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]

Voting

[edit]

Provide file uploading facility

  • 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:

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

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

Added the Phabricator tasks about fixing this within UploadWizard (by allowing it to resume/finish uploads) --Tgr (WMF) (talk) 01:02, 20 November 2017 (UTC)[reply]

@Shagil Kannur: Would you prefer for this be implemented as an improvement to Upload Wizard or as a stand-alone application? Ryan Kaldari (WMF) (talk) 22:43, 20 November 2017 (UTC)[reply]

Voting

[edit]

Client side SVG rendering

  • 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]
There are lots of much more extreme examples, which goes to say: Filesizes get really unpredictable.--Reseletti (talk) 21:58, 9 November 2017 (UTC)[reply]

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

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

I really would like to see this but I also see the problem with large svg-filesizes. We have maps where the svg-file is several MB big while the 250px PNG is just a few kb. And there are cases where browsers will mess up the rendering. I think we will have to introduce a new keyword with which you can choose if the svg or the png is served. I would propose the following:
[[File:Image.svg|thumb|vector|foo]]
Will force the use of svg-file.
[[File:Image.svg|thumb|raster|foo]]
Will force the use of png-file.
[[File:Image.svg|thumb|foo]]
Will use whatever is the smaller file.
This way in most situations the default will be the optimal solution while we can still handle special-cases manually. -- MichaelSchoenitzer (talk) 16:14, 25 November 2017 (UTC)[reply]
  • I am a bit hesitant if this is a good idea. I agree that for some files png offers a possibility to reduce the file size. However, server rendering offers fixed preview that does not depend on client browsers. Although , most of the modern browsers support correctly SVG, there may be some differences in the final result. Another issue is the use of fonts. There may be alignment and positioning issues as the font actually used varies from system to system. If a client side solution is agreed I would prefer to have the option in the Preferences as for the Math expressions - the user should choose client side rendering --Ikonact (talk) 09:03, 28 November 2017 (UTC)[reply]
    • @Ikonact: The current SVG renderer, librsvg, is actually terrible at handling fonts and the display of text – including font size and letter spacing – varies widely depending on the dimensions of the rendered file. Fonts could be stored server-side although I don't think this is possible in MediaWiki yet. Jc86035 (talk) 05:00, 29 November 2017 (UTC)[reply]
  • I would not like this discussion to get too hung up on file sizes. Generally, taking SVG files and turning them into something else is no longer either necessary or desirable. SVG is the best way we have to present many types of image, and that is what we should do. SVG animations would be really good too, but as yet still present difficuilties. Globbet (talk) 21:47, 3 December 2017 (UTC)[reply]

It seems to me that a huge problem is not being mentioned. SVGs on this site are specifically written with he onsite fonts in mind. Pretty much any SVG with fonts will break if rendered client side. Most users will not have the free fonts installed. The wrong fonts can completely mess up images. Unless a method is devised to handle this situation (falling back to PNG if the file has fonts, or maybe automatically embedding the needed fonts into the SVG), I do not think this is a good idea. Trlkly (talk) 07:58, 5 December 2017 (UTC)[reply]

Voting

[edit]

Have the image rotation bot not overwrite existing images

  • 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 picture rotated by bot gets a new name, for instance the old name lengthened by "-rot".
  • More comments:
  • Phabricator tickets:

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

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

Voting

[edit]

Track changes of files and metadata

  • 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:

Discussion

[edit]

Voting

[edit]

Improve UploadWizard campaigns

  • 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]

Voting

[edit]
  • 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]

Voting

[edit]

Audio/video review tool (for mp3s especially)

  • Problem: The Commons community recently enabled 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.
  • 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)[reply]

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

Voting

[edit]

Number of Pixels for images on Commons

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

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

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

  • 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)[reply]
I like the proposed format of Thennicke. Geraldshields11 (talk) 18:29, 11 November 2017 (UTC)[reply]
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)[reply]

Voting

[edit]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2017/Multimedia_and_Commons&oldid=23947738"