Wikimedia Meta-Wiki

Community Wishlist Survey 2017/Multimedia and Commons

< Community Wishlist Survey 2017
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