Community Wishlist Survey 2021/Multimedia and Commons

From Meta, a Wikimedia project coordination wiki
Multimedia and Commons
31 proposals, 399 contributors, 915 support votes
The survey has closed. Thanks for your participation :)



Add wikitext description pages for Commons tabular data files

  • Problem: Commons .tab and .map files cannot have categories, nor be described in wikitext, nor be described in structured data.
    Without descriptions or categories, the files aren't readily discoverable. It is not even currently possible to document what particular rows, or columns, or cells represent. Nor is it possible to describe properly where the data has come from, or any issues with it.
  • Who would benefit: The Commons tabular-data space is available to store tabular-data files up to 2Mb in size. Such files might represent eg the raw data shown on a graph (but in an reusable, examinable form), or important data series about the real world. But at the moment usability is crippled, because the files aren't describable or discoverable. As a result the potential is not used. Also sometimes people instead try to write large time-series into Wikidata items, for which they are utterly unsuited, causing difficulties and unfortunate item bloat on Wikidata. If our aim is making available the sum of human knowledge for every single human being to share, at the moment we are utterly failing to do that for tabular data.
  • Proposed solution: Attach a regular wikitext page to each tabular-data file, in the way we do for image files, to allow wikitext descriptions and categorisations of the files. Ideally also include a structured data slot, to allow the file metadata can be described and queried for using structured statements.
  • More comments: Ideally the description pages would act just like regular Commons pages. As a second-best it's also been suggested to add description pages as subpages (cf the '/doc' subpages used for templates), if that would be easier.
  • Phabricator tickets: T155290, T249896, T242596, T235332, T250919
  • Proposer: Jheald (talk) 19:22, 17 November 2020 (UTC)[reply]

Discussion

Voting

Illustrations should show the current season

  • Problem: Illustrations / photos in the articles should reflect the current season
  • Who would benefit: the users of the encyclopedia
  • Proposed solution: A field for an illustration / photo should be able to be stored with several images so that the appropriate image is automatically shown according to the season: in winter the Vogelsberg in snow or in summer in green
  • Other comments:
  • Phabricator tickets:
  • Proposer: Neptuul (talk) 16:55, 21 November 2020 (UTC)[reply]

Discussion

Voting

Option to load SVG instead of PNG on pages by default

  • Problem: All SVG content is converted to PNG before sent to public.
  • Who would benefit: Servers, readers, and basically anyone.
  • Proposed solution: Load SVGs instead of PNGs on content pages (and file pages by default)
  • More comments: I'm proposing this so as to load SVG content natively (i.e. SVG directly delivered to content) instead of backend renders. Browsers have long been natively supporting SVG content, so it seems weird that vectors are still converted to raster graphics when web browsers genuinely support SVG already for a long time. It can be enabled as default on PC clients before introducing it to mobile though, considering even the lowest end PCs are able to load SVGs in browsers natively, but cannot confirm the state of it in mobile phones. Also, it helps in cases of Math functions where wikicode is transcluded to SVG before transcluding again to PNG content.
  • Phabricator tickets:
  • Proposer: 1233 T / C 18:37, 19 November 2020 (UTC)[reply]

Discussion

Some infos about santizing: https://github.com/scour-project/scour/issues/254#issue-632703337  — Johannes Kalliauer - Talk | Contributions 06:26, 9 December 2020 (UTC)[reply]

With showing SVG files directly, comes the power of SVG animations (SMIL). Comparing SMIL to gif animations is like comparing SVG to PNG or JPEG formats (though Internet Explorer does not support SVG animations). Also it seems that Wikimedia does not support some SVG features like text along path (see the first image) or has problem showing patterns (See the second image). So I think showing SVG files directly would be a good thing.

@JoKalliauer:

  • Could you please provide some examples of different rendering on different browsers?
  • SVGs can be edited to change the fonts (for example to some web-safe font). Also Wikimedia fonts are not comprehensive enough (for example there is not a single Persian font installed)
  • Do all SVG files have longer client-rendering time? I don't think it will be noticeable even for a medium-sized vector.

What percentage of SVGs are 25- and 95-megabyte files? The particular images you mentioned have almost no usage on Wikipedia. Jooja (talk) 18:48, 11 December 2020 (UTC)[reply]

librsvg-rendering of one the view featured svgs
Rendering by most browsers

@Jooja:

 — Johannes Kalliauer - Talk | Contributions 19:53, 11 December 2020 (UTC)[reply]

@Jooja: Your examples are the best example to show, as long as you know the renderer the bugs can be fixed (both are fixed), but without knowing the renderer the rendering is unpredictable and bugs can't be fixed.  — Johannes Kalliauer - Talk | Contributions 21:21, 11 December 2020 (UTC)[reply]

I hadn't seen this page which is for resvg library. It seems a good comparison table for SVG support in some browsers and libraries (including librsvg). Jooja (talk) 10:57, 12 December 2020 (UTC)[reply]

@Jooja: I would also prefer resvg (by @RazrFalcon:), it is imho maybe the most promising svg2png-libary, in terms of supported features and especially for speed. Since it is optimized for speed, maybe an additional png-optimizer for WikiMedia might make sense to reduce file-size (reduces ~10%), but that's no problem. However animated SVGs will be rendered as a static png-image, but native animated svgs are imho also not considered as a web-save-option, so there exist imho no workable solution for animated SVGs.  — Johannes Kalliauer - Talk | Contributions 15:44, 12 December 2020 (UTC)[reply]

@Ralf Roletschek: Special:Diff/20821104

  • German(Deutsch): Wenn man ein SVG-Bild als PNG braucht, dann soll das der Nutzer selbst konvertieren. Kann man online machen, kann man mit Freeware machen,... Außerdem ein Vektorbild als Rasterbild zu bearbeiten ist genauso sinnvoll ein Qualitätsbild mit Fujifilm X-M1 mit einer Auflösung von 200px x 150px aufzunehmen.
  • English: If someone wants a SVG as PNG, than it's the users issue. It can be done online or per Freeware. Converting SVG2PNG is as intelligent as having the best camera and saving the image which a resolution of 200px x 150px.

 — Johannes Kalliauer - Talk | Contributions 08:22, 17 December 2020 (UTC)[reply]

SVG ist in der wahren Welt da draußen nahezu unbekannt und unbrauchbar. Es ist wertlos für Nachnutzer, deshalb sollten wir denen wenigstens PNG anbieten. Ist zwar ebenso wenig verbreitet, kann aber wenigstens fast immer gelesen werden. --Ralf Roletschek (talk) 10:18, 17 December 2020 (UTC)[reply]

Voting

Audio file player

Polski: Odtwarzacz plików audio

  • Problem: Obsolete video player that supports audio
  • Who would benefit: Everyone listening to audio files
  • Proposed solution: Replace the current player with a simpler one used in html-5, or create a new one
  • Phabricator tickets:
  • Proposer: Borys Kozielski (talk) 15:19, 17 November 2020 (UTC)[reply]

Discussion

Świetny pomysł. Najlepiej by było gdy to był odtwarzacz wielofunkcyjny dobrze dostosowany do każdej możliwości. Marek Mazurkiewicz (talk) 15:35, 17 November 2020 (UTC)pa fajnie jakby miał listy odtwarzania i zmianę prędkości odtwarzanania. Marek Mazurkiewicz (talk) 15:37, 17 November 2020 (UTC)[reply]

Is this necessarily different from "Inline Audio-Player for pronunciations and other usages"? --Joalbertine (talk) 18:18, 19 December 2020 (UTC)[reply]

Voting

See Exif without restoring file

  • Problem: Exif plays an important role in copyvio detection. Many files get deleted because of their Exif, especially on Commons. Sometimes an admin needs to check the Exif of an already deleted file (example). The solution to this problem is temporarily restoring the file or downloading the file and checking its metadata offline. It would be good for admins to be able to see Exif of deleted files without restoring or downloading them.
  • Who would benefit: Admins, especially Commons admins
  • Proposed solution: Add an ability to MediaWiki to see metadata of deleted files without restoring them
  • More comments:
  • Phabricator tickets:
  • Proposer: 4nn1l2 (talk) 21:15, 23 November 2020 (UTC)[reply]

Discussion

SDoC is not accessible and also not the entire EXIFs are in SDoC. Christian Ferrer (talk) 18:36, 8 December 2020 (UTC)[reply]

Voting

Image inheritance, a bequest safe for Wikimedia Commons

  • Problem: Thousands of my pictures – probably millions of images from other Wikimedians – would be lost because they can currently(!) not be publicly published. We Wikimedians who are alive today can't upload the images if we're no longer alive, when these images in the future no longer restricted by copyright.
Deutsch: ("Tausende Bilder von mir - wahrscheinlich Millionen Bilder von anderen Wikipedianern werden verloren gehen, weil sie aktuell(!) nicht veröffentlicht werden dürfen und wir heute lebenden Wikipedianer nicht mehr leben werden und also die Bilder nicht mehr hochladen können, wenn sie in Zukunft keinen Einschräkungen mehr unterliegen werden.")
  • Who would benefit: Wikimedia Commons and all its users.
Deutsch: ("Wikimedia Commons und all seinen Benutzer*innen")
  • Proposed solution: I would like to be able to upload photos to a "private" – with a, to the normal ID, unrelated password – and extra protected user space. I'm thinking of interior photos, information boards, texts and so on. These photos are currently not covered by the Freedom of Panorama and must immediately be deleted. I would like to upload these photos "today", but save them for "later" (my digital "bequest", my "photo inheritance" for Wikimedia Commons).

    The way I envision it is that these files would 100 years after the uploading automatically be made free. Until then, they would just be available for administrators and myself. At the same would I already put these images "hidden" in the "proper" categories – but not available to non-administrators!

    Perhaps a cooperation with the Internet Archive would be useful here.

Deutsch: ("Sehr gern würde ich Fotos in einen „privaten“ - mit einem von der „normalen“ Kennung unabhängigen Passwort – und extra geschützten Benutzer-Bereich hochladen. Ich denke dabei zum Beispiel an Fotos von Innenräumen, Informationstafeln, Texten usw. Diese Fotos unterliegen aktuell nicht der Panoramafreiheit und müssten sofort gelöscht werden. Ich möchte diese Fotos aber „heute“ für „später“ hochladen (mein digitales „Vermächtnis“ / mein „Bild-Erbe“ für Wikimedia Commons ).

Meine Vorstellung ist, dass diese Aufnahmen etwa 100 Jahre nach dem Hochladen automatisch frei geschaltet werden. Bis dahin wären sie nur für Administratoren und mich selbst sichtbar. Gleichzeitig würde ich die Bilder schon „versteckt“ in die „richtigen“ Kategorie einfügen wollen - für Nicht-Administratoren unsichtbar!")

Vielleicht wäre hierbei eine Zusammenarbeit mit dem Internet Archive sinnvoll.

  • More comments:
See also: Community Wishlist Survey 2019/Multimedia and Commons/Image inheritance, a bequest safe for Wikimedia Commons
Since 2015 is there a Phabricator ticket that's touching the same area. I have the impression that only little progress have been made for that project.
Deutsch: ("Es gib seit 2015 einen Phabricator ( phab:T120454 ), der dem nahe kommt. Ich habe aber den Eindruck, dass das Projekt nur wenig voran kommt.")

Discussion

  • A good idea, but I would like to add one more point: I lost tens of thousands of pictures a few years ago when I lost a hard drive. Now, in order to prevent something like this in the future, I would like to upload images to Commons, then edit them there over time and move them to public space. I would also like to allow other people, if they were faster than me, to edit these images, categorize them, etc. So a semi-public space would be needed in which you can temporarily store large amounts of images for a longer period of time, once you're done made for general use. -- Marcus Cyron (talk) 19:29, 16 November 2020 (UTC)[reply]
    • That would be also very useful. I have, for example, about 25 000 photos on my HDD that are perfectly within the scope of Commons. Although I don't really care about image descriptions, categories and geolocating, I'm able to upload roughly as much as 2000 images a year (using Pattypan), but I take at least same number within the same period. So the Marcus Cyron's proposal would probably also help me a lot. — Draceane talkcontrib. 16:03, 27 November 2020 (UTC)[reply]
  • I think this is a cool idea, but I don't think it is the right size for CommTech to handle it, and I'm not strictly certain it should be in WMF's scope at all. Perhaps it is something which could be proposed to Internet Archive. --Izno (talk) 22:10, 16 November 2020 (UTC)[reply]
  • I wonder whether some kind of collaboration with Flickr would be good for this. — Bilorv (talk) 19:43, 17 November 2020 (UTC)[reply]
  • Exactly my thought. Currently this can only be done by uploading, deleting and categorising as Undelete in XXXX, but this method is prone to vandalism. Who knows if someone might remove the cats without notice?
It may not have to be part of commons. It could be a separate project maybe, since commons requires everything to be freely licensed. FOP issues, photos of posters etc. can definitely benefit from this new project for the future generations to see our world.--RZuo (talk) 21:16, 17 November 2020 (UTC)[reply]
  • Very much needed. Ideally the tool would allow us to edit pictures metadata (title/description/depictions) even if the picture is not publicly viewable yet. If it is judged to be fair use, a very small thumbnail could also be helpful to get an idea of the picture's potential. File information such as file size, type, and hopefully a measure of the image's grain/fineness should be publicly viewable. Having this metadata would for instance allow us to make sure we have completely covered a modern art painter's paintings. Syced (talk) 13:46, 18 November 2020 (UTC)[reply]
  • Agree, This is a very desired storage idea for files (contemp art) that might become PD in just a few years, but might get lost due to local hardware changes in between. Pelikana (talk) 15:28, 20 November 2020 (UTC)[reply]
  • Has been proposed many times, and although it's a nice idea there are difficult legal problems. The reason that some personal photographs can't be uploaded is that the photographer is not the sole copyright owner: the creator of some artistic thing being photographed (for example the architect of a building, the sculptor of a statue, or the graphic designer of a product label) is a joint owner of the copyright in the image. Without their consent the photographer can't upload the image, and the WMF can't host it, without risking third party copyright infringement (the details vary by country). Unfortunately the same restrictions still apply even if the repository is kept private for years until the third party copyrights expire: the mere act of storage itself requires the consent of all the copyright owners. And the WMF as provider of such a service could potentially be held in breach of third party rights under US law, even if the repository were hosted elsewhere. The idea may not be totally out of the question if some clever legal exemptions can be found, but so far the Foundation has shied away from it. MichaelMaggs (talk) 17:24, 20 November 2020 (UTC)[reply]
  • An alternative solution, for potential FoP issues, is to upload them knowingly, then to detete the images and to categorize its in the relevant FOP categories (or "Undele in 2080", ect...), so if a country change their law the images can be found and undeleted. Issue: we have already a big DR backlog. Christian Ferrer (talk) 19:01, 20 November 2020 (UTC)[reply]
  • Admins can undelete deleted images and tracking categories containing DRs (and even individual file pages) exist: c:Category:Undelete in 2021, c:Category:Undelete in 2022, c:Category:Undelete in 2050 etc. This doesn’t address the main issue and per se doesn’t mean copyrighted files should be uploaded now to be immediately deleted and undeleted some day, but might be good news for some of the commenters above. Tuvalkin (talk) 21:40, 11 December 2020 (UTC)[reply]
  • I agree with Christian Ferrer above. Every country has its own FOP laws like: only building's exteriors, interiors too, 2D or 3D art as well, only work of artists/architects who died at least 70 years ago, artists still alive and so on. The uploader could choose amongst a multitude of options like Statue, Painting, Legal Graffiti, Building Interior/Exterior, probable year of copyright expiration, Nation... When all the conditions are met in the future or when a country's FOP or Copyright law changes, then the images with the right flags could be undeleted. From a technical/programming point of view it can be done. From a legal point of view, I don't know! ... GiorgioGaleotti 18:33, 19 December 2020 (UTC)[reply]


Voting

SVG to PNG converter that actually works

  • Problem: Current SVG to PNG conversion is buggy, many images that work in Inkscape and major browsers are broken upon conversion on Commons. Blurs are cropped most of the time, clones behave unpredictably, hatch fills work on some resolutions and don't on others. The conversion library, librsvg, is no more being developed.
  • Who would benefit: Creators of highly-desirable high-quality SVG media
  • Proposed solution: Use Inkscape in batch mode for conversion on wikimedia servers - at least for files created in Inkscape, or per uploader's choice. How do browsers render SVG graphics, can their library be used for svg to png conversion?
  • More comments:
  • Phabricator tickets: phab:T243893 phab:T40010 phab:T193352
  • Proposer: Ponor (talk) 04:33, 17 November 2020 (UTC)[reply]

Discussion

  • Yeah not being able to use stuff like textpaths -- which work on every browser MDN lists -- really is annoying. This really doesn't seem like it would be that hard to implement at all, too. DemonDays64 (talk) 09:10, 17 November 2020 (UTC)[reply]
    @Ponor: Every complex software will have some software bugs. How to define "actually works"? If someone worked on this proposal, when to call work finished by which objective criteria? In my personal opinions this proposal is currently not discrete and well-defined. --AKlapper (WMF) (talk) 14:00, 17 November 2020 (UTC)[reply]
    @AKlapper (WMF):No one uses librsvg to make SVG images, but some (or most?) use Inkscape. So if I made my SVG in it, and it worked fine for me in Firefox and Chrome, I'd expect it to work on WP - but it often doesn't, and I need to go back to Inkscape, unlink all my clones, remove all my blurs, and make guesses what else might be "wrong" (nothing's wrong, the library is wrong). I was lucky to find this tool Commons_SVG_Checker so at least I didn't have to beg for speedy deletions of my uploads-gone-wrong. You'll say there are other users who do not use Inkscape. And that's fine, they'll still be able to use the abandoned library for svg2png conversion. Ponor (talk) 14:23, 17 November 2020 (UTC)[reply]
    Forgot to answer your question: call the work finished when we're using the newest stable version of Inkscape to do svg2png conversion (for Inkscape-generated SVGs at least)
  • Since all browsers (that WMF supports) support SVG now, why are we not serving SVG images instead? :) (I can see a case for 'it's a really large SVG don't want to DOS the servers, but that's something that can be worked around with some upper limit.) --Izno (talk) 18:38, 17 November 2020 (UTC)[reply]
    That said, there was a Phab discussion for switching the renderer at phab:T40010. Do consider. --Izno (talk) 18:45, 17 November 2020 (UTC)[reply]
    This is the best solution imo. svg -> png is clearly messy/error-prone and all major browser vendors have supported svg natively for years now. -FASTILY 04:55, 18 November 2020 (UTC)[reply]
    There is at least one other caveat (abuse like background-URL hacks) but these are things that can probably be worked around. --Izno (talk) 05:09, 18 November 2020 (UTC)[reply]
librsvg is actively developed [1], it is still the most common SVG-Renderer on Linux, most common bugs on commons are already fixed, the problem is that Wikimeida uses an outdated version from 2017, see phab:T193352.
Inkscape is developed for generating images, not for batch-converting, therefore it is much slower. (phab:T40010#6635936 @GDubuc (WMF): Can you name the current CPU-costs per day? in CPU-h/d or €/d )
Wikimedia should be used for image-exchange, therefore we don't wan't invalid Inkscape-Files which can only be rendered by Inkscape, we want SVGs that are valid according to the current SVG 1.1-Standard, otherwise it is Inkscape-file but not an more a SVG-file.
SVG-Experts have different opinions on that, because it is a complex topic.
@Glrx: for example: Prefers a native SVG-Rendering by the clients-Browser, however this would be a much larger change than updating or changing the renderer, and has also several disatvantages (Maleware-Safety issues, different rendering on the individual browser, missing fonts, increased client-rendering-time, ...)
I support the proposal, although I expect complications and problems.
However I think resvg by @RazrFalcon: might be a better renderer (very much faster and generally better SVG-Support).
 — Johannes Kalliauer - Talk | Contributions 06:19, 9 December 2020 (UTC)[reply]
I actually go so far as to oppose this proposal as a waste of time. Work instead on serving SVG directly. Globbet (talk) 22:39, 9 December 2020 (UTC)[reply]
@Globbet: I might have been unclear about direct SVG-serving, due to security-reasons, unpredicted client-side-rendering, huge SVG-files with several minutes of rendering, it is imho not a good idea in general. Due to different browser you will get several bugs. Brower-rendering should imho only be an opt-in in the preferences for specific flagged svg-files, see Special:Diff/20781745 for details.  — Johannes Kalliauer - Talk | Contributions 10:54, 10 December 2020 (UTC)[reply]

Voting

New Gadget - Mark Files used in a Wiki or Wikidata

  • Problem: In the different maintenance categories (~ 650,000 images without category; ~ 50,000 categories with infobox not connected in Wikidata) you could use the connected images to set categories to a Wiki or Wikidata faster or then connect them to Wikidata. At the moment you would have to open every picture and scroll down to see this state.
  • Who would benefit: people who are involved in maintenance; like "Wikidata infobox maintenance" or "Media needing categories"
  • Proposed solution: I would suggest to have a new gadget created, which, if you are in a category, marks the images that are connected to a wiki or wikidata. (Maybe, if it is technically possible, only pictures that are in namespace "0"!)
  • More comments:
  • Phabricator tickets:
  • Proposer: Crazy1880 (talk) 18:11, 25 November 2020 (UTC)[reply]

Discussion

Voting

Flickr-like uploader

  • Problem: Many people in the community would like to upload images on Commons, but they don't wan't to, because they say how complicated it is. Adding description, captions, categories, licences and all those things is a pain. Especially for new users who just want to choose a folder and upload. Skilled Commons users can use Vicuna, Pattypan or something similar, but we are still missing and easy and well working option. We don't have to re-invent the wheel – Flickr has the wheel! We should just mimic what they have. Choose a folder, add all the data in an environment similar to a folder in a computer, do the upload WHILE the stuff is being described and just confirm it by the Upload button. So simple, so efficient and proven to work.
  • Who would benefit: Especially newbies but all Commons users
  • Proposed solution: Creation of a better description of how the tool should be designed and eventually designing and making the tool working.
  • More comments: Note: I've submitted a similiar proposal before. I still believe the community would benefit from this. Lack of such a tool still represents a major bottleneck in better metrics results in many projects we have. The concept of such an uploader would differ from Upload Wizzard – the interface would have to be completely reshuffled and many things must be done automatically.
  • Phabricator tickets:
  • Proposer: Aktron (talk) 10:43, 17 November 2020 (UTC)[reply]

Discussion

  • How would you add categories to those files? Are they coming with the folder? JopkeB (talk) 16:33, 17 November 2020 (UTC)[reply]
    • Simple: A filename will be above the icon of the image, description/caption below and category will be below the description. I believe this would work fine with many user cases. Aktron (talk) 15:13, 21 November 2020 (UTC)[reply]
  • When I upload all pictures of my "DCIM" folder, what do you think should be the caption of each file? What depictions/categories should they have? Surely a generic caption and zero depiction is not a great idea, right? Syced (talk) 13:53, 18 November 2020 (UTC)[reply]
    • The user should have an option to write a custom caption/description for each file. This is ok if we do maximum accessibility – just like in Flickr you click below an image and directly input the data. No need to load pages, scroll or anything similar. This is what we should do. Aktron (talk) 15:13, 21 November 2020 (UTC)[reply]
  • What would be the use of thousands of images with no categories and no description? How would one ever find them (without browsing through the uploader's contribs)? However, I agree that adding those new captions is a pain. PiotrekDTALK 15:45, 19 November 2020 (UTC)[reply]
    • The reason why we have thousands of images with no categories or description is that our tools fail to be easy to use so people can use them to add the data. Adding a description by editing each PAGE of the images is utterly slow. This tool was intened to help this, but it was still limited. So we first need a tool that will allow everyone to easily add caption/description/category to an image or a batch of images. The Flickr uploader is tested and works well, the concept I believe can be easily applied here. Disallowing empty values for caption/description/categories will simply guarantee that we wouldn't have files with no descrition. And we should work with coordinates in a much better way in the future too! Wikishootme is a good start, but let's go further! Aktron (talk) 15:13, 21 November 2020 (UTC)[reply]
  • I agree. I decided not to provide images any longer to commons because meanwihle it takes me up to 30 minutes to upload a picture (searching for the right categories, addings structured data, creating WD object and linking it...), although I still have thousands of usable images. But this is complex process with many single solutions and does need more than just one request. Many single solutions could help in the future. E.g. a feature that scans the EXIF keywords and suggests categories or a feature that processes the location and time EXIF data and puts it in these time categories "photographs of Germany taken on..." or these lens and camera and aperture categories (including structured data). And finally thinking of introducing tags as well what makes searching easier. -- DerFussi 09:18, 20 November 2020 (UTC)[reply]
    • I believe the future is when we the Commons will pre-load GPS coordinates from the images and ask you: "This image is within the shapefile: Arc de Triomphe, Paris. Does the image depict it?" And you will click yes and all the data will be added from Wikidata or somewhere else :-) Aktron (talk) 15:13, 21 November 2020 (UTC)[reply]
      • @Aktron: Its just a bit of help. To be honest - frankly spoken, a wiki is the very last kind of software that should be used as a media repository. The whole commons wiki should be thrown into a garbage can and replaced by a new suitable media repository software. Actually I am curious how many hours and live times the users spent for creating categories by hand (and reorganising them later) and how many hours uploaders spent to find the all suitable categories for a picture (and nobody will find them all), although a handful of keywords/tags in the EXIF data have all the necessary information. I am aware, that we all have to live with that short-sighted decision to use a wiki for commons. But some AI may help in the future to suggest suitable categories after sanning EXIF data (location, coordinates and keywords). -- DerFussi 22:10, 21 November 2020 (UTC)[reply]
        • Yeah, but Wiki for image repository is kinda like a QWERTY keyboard. The idea is utterly impractical and outdated and yet so many people use it that despite the utter impracticality everyone does it. Aktron (talk) 22:46, 21 November 2020 (UTC)[reply]
    • “[…] addings structured data, creating WD object and linking it […]” – I find these WD-related parts annoying as well. Actually, what is the point of them? IMO the uploader was better in '17 when there were no fancy “features” like that (if memory serves). Regards, PiotrekDTALK 11:15, 24 November 2020 (UTC)[reply]
      • They do have a sense but adding them manually just doesn't work. We have made a perfect brick but now we need a perfect machine for laying bricks. Nobody builds a huge structure by laying brick by brick by hand. Aktron (talk) 18:11, 24 November 2020 (UTC)[reply]
        • Enter the Captain: laying bricks by hand is the only reliable way to lay bricks. Humans tackled the issue of mechanized bricklaying for the past two hundred years, at least, and each time they failed. To eliminate bricklayers, one has to replace bricks with something else. Back to our "bricks", the problem is that only the uploader can describe the contents of the upload. AI systems can sometimes help, but not in the case of original, never-published material (think of the only existing photo of someone's great-great-grandmother...). So, even in foreseeable future, the uploader has to provide meaningful descriptions, typing with their fingers. If it doesn't work now (I know it doesn't, I'm fixing the backlogs at a snail's pace...), it has nothing to do with the "complexity" of the upload form, and it won't work with any alternative upload protocol. Retired electrician (talk) 19:20, 15 December 2020 (UTC)[reply]
  • I agree. The upload-form is kindof dumb in an annoying way.It does not, but it should support drag and drop and /or point to files in the local image browser. The current method keeps loosing the spot in the local browser if the folder has hundreds of images to pick in a manually selected order of appearance by batches of a few in time. Found out i can drop them on the button. The upload form should remember my only few used languages and have their formfields open and prepared to fill in right away. Now it asks the uploader over and over again which out of hundreds of languages we want to use. At least create a shorlist for this in user prefrences, so language can be picked by typing 1 single letter. (Parts of) carefully crafted titles could be re-used and preproposed as captions, as descriptions and as Data, even as proposed categories. Let users pick and save their preferred upload templates (single file, batch, series, homogenous, misc.) Add buttons troughout the form to copy info from one to the next the file in sequence, not just info from file 1 to all others. Make an opt-out button for reloading page for last step (DATA) or possibly integrate a smarter version (using parts of the already provided info) in the upload form as an optional formfield. Upload form could remember a shortlist of last used categories. Upload form could remember and display till the end of the process, in grey or italics, the old (local) filename for further reference when moving local 'done' files to local 'done' folders, or tagging them alike. Pelikana (talk) 13:07, 20 November 2020 (UTC) Yes, agree ... time could be saved by being able to edit descriptions etc. while the uploads are being done in the background. Pelikana (talk) 16:04, 22 November 2020 (UTC)[reply]
    @Pelikana Drag and drop upload will soon be improved by T47656. ESanders (WMF) (talk) 18:37, 2 December 2020 (UTC)[reply]
    I feel neglected because the upload form has never asked me "which out of hundreds of languages we want to use". It's always in plain English. Why such difference in treatment? Retired electrician (talk) 19:26, 15 December 2020 (UTC)[reply]
    I meant picking the extra especially the 3rd languages for the captions and descriptions is a pain. Say: I want to upload a batch of 10 heterogeneous images and I want to add 2 extra languages for each file description, than I will have to click and pick or type at least 60 times for these 2 extra languages within this short session (unlike the captions that remember my choises). Picking the 3rd language is a 3-click process. So let us select the Constants Caption Languages and Description Languages centrally, in preferences, or at least at the top of the form and apply that choice to all files. Don't treat this choice as a variable, because it's actually a lifelong constant. Don't confront us a n-thousand times in this UploadWizzard with language options that we will never ever pick. Peli (talk) 04:07, 16 December 2020 (UTC)[reply]
What about the bug: the form tells me that I'm already uploading the file? This erroneous error message pops up every time when I stay on the site an click 'Upload More Images' to do next batch - unless I do a reload of the empty form page first by pressing F5. Can this be investigated please? Peli (talk) 14:44, 16 December 2020 (UTC)[reply]
It appears that you're using the unfortunate "upload wizard" in place of the regular, wikitext-based upload form. No triple-clicks required there, which probably explains its longevity. Just type in double-character language codes as you would in a wikipedia article or talk page. Retired electrician (talk) 20:44, 16 December 2020 (UTC)[reply]
  • Seems like a reasonable proposal that would entice me more to start uploading images as well. --Ivario (talk) 22:23, 24 November 2020 (UTC)[reply]
  • Problems to address: let's please focus on specific problems that make uploading so slow and painful. Copying the fields entered helps, but maybe there should be an option to copy down to any below the current image. Uploading from Flickr should allow you to see more files, and upload from a photostream over just an album. Copyright statuses should be able to be copied; right now they cannot. Errors uploading need to be clearly stated, either easily found or searchable, perhaps by saying "Error: XYZ". Right now, finding the error preventing your upload of 200+ files is painstaking. There's other problems beyond just these... (talk) 04:22, 7 December 2020 (UTC)[reply]

Voting

Support 360 photo viewing

  • Problem: Wikipedia Article/ Media Viewer can't show 360° photos as a 360° because it can't Read/Render necessary 'EXIF metadata tags' from the uploaded photo. When uploading from a 360-ready camera, sometimes 'Metadata Stripping' occurs & there is no 'Exif Editor' in Media Viewer/Commons to do a 'Metadata Injecting'.
Just another animated GIF, showing a concept of usability in wikipedia articles.
  • Who would benefit: Editor who want to express the feeling about the surroundings of any place/ architecture in any article.Instead of showing many photos someone can take 1; 360° photo to encapsulate all the information he/she want to show.

Reader who want to feel the surroundings of any Place/ architecture in any Wiki article they read.It puts the reader/viewer in control of what they want to look at within an image, which is like being in the moment when that particular photograph was captured!

Also, Wikipedia's existing 'panoramic photos' look's very small in mobile devices. Adding 360° viewing capability in media viewer will solve this problem.

  • Proposed solution: Integrate a web based 'EXIF editor/Injector' in wikimedia Commons similar to THEXIFER.NET, so that when uploading 360° photos, 'Metadata Injecting' can be possible.

Integrate 'Panoviewer' tool/egjs-view360 into 'Media viewer' & 'Mediawiki's CORE' so that article readers can navigate inside the image by mouse or finger gesture.

An auto generated 'Thumbnail' will be shown in the article when low internet speed/device incompatibility will be detected.

User dschwen did some good work on this.
  • More comments: This has been a wish on the previous wishlists and only slightly missed the Top X several times:
  • Phabricator tickets: phab:T138933
  • Proposer: Ahm masum 30 November 2020 (UTC)

Discussion

Voting

Interactive chess content

  • Problem:
    WMF wikis cannot provide interactive chess content which makes it difficult to convey information. Unlike other websites which allow readers to see pieces move on the board or automatically show a game move-by-move, WMF wikis are limited to static content or less-interactive video/gif content.
  • Who would benefit:
    Wikipedias, WikiBooks, and Wikiversity would most immediately benefit. The featured book b:Chess has openings and example games, and providing an interactive board would improve learning by allowing readers to see the pieces move on the board as they would in a real game. Many Wikipedias have articles on famous chess games such as the w:Evergreen game and the w:Opera game. Adding an interactive chess viewer would provide a critical piece of content for understanding these games that is currently missing, and it gives readers greater control over the pacing of movements than a video or GIF. For Wikiversity, which currently has limited chess content, the new functionality would encourage collaboration on v:Chess and other teaching materials. Future versions could incorporate Stockfish, a free and open-source chess engine, which could be used on Wikiversity for automating chess puzzles or writing quizzes. Development would also benefit the wider wiki-community by providing a high end, freely licensed extension for chess wikis like Chess Programming Wiki and WikiChess.
  • Proposed solution:
    mw:Extension:ChessBrowser is a community-developed MediaWiki extension which reads w:Portable game notation (PGN) and displays a board with arrows to progress through the moves of a chess game. It is based on a javascript gadget used on the Hebrew and Russian Wikipedias, but unlike the gadget, most of the extension's code is run on WMF servers so that it reduces the load time for readers. As a community developed extension, developer time is limited and the deployment process is complex. Support by the community development team would ensure that the extension is well designed and that the deployment process runs smoothly and efficiently.
  • More comments:
    1. Co-proposed, revised, and moved from "misc" to "multimedia" section by Wugapodes (talk) 00:02, 29 November 2020 (UTC)[reply]
    2. in lieu of demo page for the extension (see stalled request phab:T244075), please view the "demo page" for the script used on hewiki and ruwiki, which i set up long ago - w:he:משתמש:קיפודנחש/ארגח 1. hopefully, a real demo for the extension can be set up soon.
      also, see this hewiki article and ruwiki article, and compare each with its English interwiki, to judge the effectiveness and value of showing games interactively. peace - קיפודנחש (talk) 18:23, 30 November 2020 (UTC)[reply]
    3. see enwiki community consensus here: w:en:Wikipedia:Village_pump_(technical)/Archive_175#Enable_chess_PGN_viewer_for_chess_articles. the main objection was the fact that the proposal was for the "standalone" script rather than an extension.
  • Phabricator tickets: phab:T244076, phab:T244075, phab:T246736, phab:T239446, phab:T248272.
  • Proposer: קיפודנחש (talk) 00:02, 29 November 2020 (UTC)[reply]

Discussion

  • We've been talking about this for several years at this point. It just keeps hitting snags and losing momentum as far as I can tell. Maybe the wishlist will get it across the finish line. — Rhododendrites talk \\ 01:48, 29 November 2020 (UTC)[reply]
  • Implementation of this would almost immediately make almost all of our chess-related content on all language Wikipedias and WikiBooks useful to several times more readers and go from incomprehensible to understandable for those without high expertise in chess. It seems like this is not a big task for Comm Tech or something that would interfere with existing projects or interfaces, so I'd ask that it be considered even if it's a bit lower payoff than some larger-scale tasks. — Bilorv (talk) 15:41, 29 November 2020 (UTC)[reply]

Voting

Photo challenge

  • Problem: With a large number of images (> 100), the coordination is very cumbersome and time-consuming.
  • Who would benefit: Wikimedia Commons and all participants in the Photo challenge.
  • Proposed solution: Improvement of the voting through a simple and user-friendly program interface.
  • More comments: It would be helpful, for example, if you could filter out photos that you do not want to award points in order to gradually reduce the number. It may be possible to use the same method as for "Picture of the Year". In addition, a simple integration of the images is desirable, as in my experience this is often done wrong. If it is the aim and purpose of the Photo challenge to win new participants (photos), then IMHO should also provide an adequate user interface.
  • Phabricator tickets:
  • Proposer: F. Riedelio (talk) 10:13, 25 November 2020 (UTC)[reply]

Discussion

I think this can be the proposal. --BoldLuis (talk) 18:00, 11 December 2020 (UTC)[reply]

Voting

Improve graphs and interactive content

Examples of Vega and Vega-Lite graphs we can build

  • Problem: Wikipedia would benefit from more animations, interactive content, and self-updating infographics
When we discuss historical changes, we should be able to view those changes interactively, e.g. side by side. Statistical data should be represented as easy to understand charts, and when the new data becomes available, those charts should update. We already have some of the tools for this (the <graph> tag, the shared data on commons, maps), but the current tools are hard to use, not maintained, and need improvements. The comprehensive vision was presented several years ago in a short I Dream of Content paper.
The Graph extension has many advantages for Wikimedia projects. In brief, it allows data to by displayed by generating graphs on-the-fly (we do not need a picture file anymore, and so we do not need to create a new picture each time the data are updated). However, the Graph extension is currently not widely used, probably partly because the code is not really user-friendly.

In addition, the current extension has not been able to display Wikidata data for more than a year, and since there is no official maintainer for this extension, the problem has remained ever since.

  • Who would benefit: Readers and content creators
  • Proposed solution: Upgrade the Vega library, add Vega-Lite support, and add multilingual support to Graphs.
Develop a GUI Visual-Editor-like tool to help contributors to create nice graphs. This tool could look a bit like those in spreadsheet software (the user selects the data to plot and the type of graph, then fine-tunes it). This tool could be integrated with the Data namespace on Wikimedia Commons (example) and with the Wikidata Query Service. The latter already offers different visualisation methods, with the ability to export results to several formats (html, json, svg). See this example. Adding customizable Vega code as an output would be nice.
Community Wishlist Survey 2016/Categories/Multimedia#Support SVG interactivity and animation in Media Viewer discussed making animation and interactivity easier for SVGs.
  • More comments:

Discussion

Voting

Inline Audio-Player for pronunciations and other usages

  • Problem:
    Pronouncation of Beijing
    Audio files can enrich Wikipedia and it's sister project in a valuable way. One use case is adding recordings of the pronunciation of the article's topic to the intro. Projects like LinguaLibre now make it possible to do this on a large scale. But for adding them to the article it would be desired to embed a minimal sized audio player into the text, that can be clicked to hear the audio. So far our audio player (both the old and the new beta-feature) only allow to add a big audio player (on the right), a lot of wikipedias have templates that create an audio icon that links to the file instead: Listen i, but they have the problem, that the readers' browser leaves the article.
  • Who would benefit: Article editors and readers
  • Proposed solution: Add an inline audio player that looks somewhat like the small version above but if the user clicks the icon plays the file directly. Most online dictionaries have such a feature.
  • More comments: For license compliance there also has to be a link to the file page. Above it's done with the tiny `i` but there might be a better way.
  • Phabricator tickets:
  • Proposer: MichaelSchoenitzer (talk) 10:54, 30 November 2020 (UTC)[reply]

Discussion

Voting

Make subcategory browsing multilingual using Wikidata

  • Problem: Although Commons is a multilingual project, MediaWiki categories can only have a label in one language. Wikidata changes this: when a category is linked to Wikidata (which over 3 million of them now are), you can define labels for it on Wikidata in many languages. The Wikidata Infobox displays those multilingual labels within the category, so you can see the topic info in your language when you are within the category. However, subcategories only appear in the language they were created in (normally English), which can make it difficult for people that don't know that language to browse them.
  • Who would benefit: Commons editors and browsers who do not know English
  • Proposed solution: Use the Commons <-> Wikidata sitelinks to Wikidata to display a category label in the user's requested language. This would be best done within MediaWiki itself rather than having Javascript or similar trying to rewrite the labels after rendering.
  • More comments: A bonus would be if d:Property:P18 (image) could also be used to show subcategory thumbnails, and perhaps also use the descriptions on hover-over to add additional context.
  • Phabricator tickets:
  • Proposer: Mike Peel (talk) 20:33, 20 November 2020 (UTC)[reply]

Discussion

Voting

Separate property and user right for license, author and date

  • Problem: Author, license and date are written down in file decription and are writable to everybody. It happened to me in the past the other (anonymous) user changed the autor information of my images to their own name. If you dont check/use your watch list regularely you have no chance to notice it. Besides people can not change every license to any other license afterwards. Author, file date and license must not be changeble so easily.
  • Who would benefit: everybody and every file
  • Proposed solution: Author, file date and license should be stored in separate (wikitext) features and should be editable only by the uploader himself and by admins and bots with that user right (for maintenance or an official transfer to an other user, if necessary). Or maybe just one more wikitext area for all three information that is just shown after the normal description.
  • More comments:
  • Phabricator tickets:
  • Proposer: DerFussi 09:41, 20 November 2020 (UTC)[reply]

Discussion

There are many legitimate reasons for other editors to be able to change these fields. What you've described is just vandalism, and we could always be more vigilant about that. -FASTILY 23:57, 21 November 2020 (UTC)[reply]

What many legitimate reasons? · · · Peter (Southwood) (talk): 07:50, 22 November 2020 (UTC)[reply]
Who has the time and inclination to be more vigilant about that? · · · Peter (Southwood) (talk): 07:47, 22 November 2020 (UTC)[reply]
To name a few: editor uploading a file form an external website but choosing the wrong license (happens all the time with Flickr uploads, permission submitted via OTRS), license migrations, marking obvious PD-simple files as such. Plenty of folks monitor recent changes for vandalism. -FASTILY 10:00, 22 November 2020 (UTC)[reply]
As stated above. Admins and bots are able to edit this. Monitoring recent changes? As fast as the recent changes run through? And I am sure, the folks have better things to do in their free time than monitoring vandalism, especially if some features can avoid some kind of vandalism. And by the way its not easy to recognize some of this edits as vandalism. Especially when its not that obvious. -- DerFussi 19:59, 22 November 2020 (UTC)[reply]
Yes, plenty of people watch recent changes. It's not difficult to do with a tool like Huggle -FASTILY 02:06, 23 November 2020 (UTC)[reply]

To some point, the question is : Could there be a "localized" fields with protections applied to it (a field receiving author information at upload time) on a mediawiki page ? I've discussed such principle and tools for a different context and it has many alternative applications. I proposed to use templates about this 5 years ago (it can be in 'no show' wikicode). For the discussed case, whenever a change is brought to a file, "authors" (as well as alternative fields) can be compared. And according to the result of a 'diff' command, according to the results and respective situations, a proper management of these cases can be done. It's what I called an "authorship bot" in the JSL protocol, used in an alternative context of research literature production (see related logigramme). Such a tool is very useful whenever there is a primary-'wiki'-source to be taken accountable (artists, authors, journalists, researchers, any primary information producer). (For instance, in France we cannot "give" a work to public domain because moral rights and duties cannot be ceded).

The discuss case can have the following situations:

  • where authors and upload account differ, it can trigger a verification protocol (bot or human-community based)
  • where authors field (or any judge critical) change, it can be a) notified, b) reverted and put under protection etc. according to vandalism diagnostics (is it a case, an attribution error etc. ?)

The fact than it can be done by humans is not an argument for it not to be done by a script / bot / automated protocol (whatever you name it). --RP87 (talk) 13:58, 11 December 2020 (UTC)[reply]

Voting

Upload to current category

  • Problem: When you find the correct category for your images, you have to upload it and then type the category. There are lots of images that could be better categorized directly if uploaded to that category.
  • Who would benefit: Everyone who uses Commons, both newbies (I want to upload something to this category) and experienced users (who are good with categories)
  • Proposed solution: Add an "Upload to this category" button to every Commons category in the top. This should have a prefilled category when uploading.
  • More comments:
  • Phabricator tickets:
  • Proposer: Theklan (talk) 09:37, 20 November 2020 (UTC)[reply]

Discussion

The following snippet in your commons:Special:MyPage/common.js

if (mw.config.get('wgNamespaceNumber') === 14) {
	$(function () {
		// upload in cat
		mw.util.addPortletLink('p-cactions', '//commons.wikimedia.org/w/index.php?title=Special:UploadWizard&categories=' + encodeURIComponent(mw.config.get('wgTitle')), 'Upload to this category', 'UW');
		$("#contentSub").prepend(
			'<a href="//commons.wikimedia.org/w/index.php?title=Special:UploadWizard&amp;categories=' + encodeURIComponent(mw.config.get('wgTitle')) +
			'" title="Upload to this category">' +
			'<img alt="Upload to this category" src="https://upload.wikimedia.org/wikipedia/commons/thumb/4/42/Camera-photo_Upload.svg/30px-Camera-photo_Upload.svg.png"' +
			' style="vertical-align:sub" height="30" width="30">' +
			'</a>');
	});
}

does the magic. Could be added to the global config to allow for all users. --Herzi Pinki (talk) 19:00, 20 November 2020 (UTC)[reply]

@Mike Peel: Not all categories have the infobox. I have checked now the featured picture, for example, and it doesnt: c:Category:Point_Reyes_headlands. When looking to a category with the template, indeed, the link is there, but it wans't obvious that the link would upload an image to that category, because the text is not explicit (this has a really easy solution).
@Theklan: It's present in around 50% of categories now. It could easily be added to the rest, but we've been trying to add it at the same time as the Wikidata sitelinks - although the unlinked version still displays the upload link. The text is commons:MediaWiki:Cx-contributions-upload, if there's a better ux string that can be used while keeping things multilingual, I'm happy to change it! Thanks. Mike Peel (talk) 13:55, 3 December 2020 (UTC)[reply]
@SWilson (WMF): It's not about me, it is about new users who are not used to our tricks (snippets, special codes...). -Theklan (talk) 09:36, 3 December 2020 (UTC)[reply]
  • This feature would be great for campaign organizers that seek attract new collaborators. I know that there are other tools for campaigns, but this button is helpful for understand that you are participating in a campaign by adding the file to a category. Many new users that want collaborate in a specific campaign aren't aware of categories.--Señoritaleona (talk) 00:25, 19 December 2020 (UTC)[reply]

Voting

embedding crop, creating sub images, and possibly other file formats, while retaining reference to the original context

  • Problem: Using parts of Images (compiled documents such as newspapers, Government gazette or otherwise any big images (Tabula Peutingeriana) are such examples) is needed when pointing to an article for example, or even pointing to a typeface or an advertisement, and additional data can be associated with the part (article or other "cropping") that are not applicable to the whole document, or at least not directly; but would still "inherit" information of the "parent" document and preserve the context it came from/within. a crop of a picture of multiple people might also be a good example.
  • Who would benefit: The use case in GLAM related projects would be extremely useful, this would also move the use of commons as a much cleaner digital repository steps ahead, reducing fragmentation and enriching those commons. Without limiting the significance of the current usefulness to wikipedia, the use in other related projects in line with the foundations 2030 vision will be enormous.
  • Proposed solution: Similarly to notes, or even as an extension to it, areas of pages can be marked and data added to it, and a "cropped" view added, this might also be a separate document that is automatically generated (as it might get separate categories for example, annotations, referenced from wikidata, ...etc).
  • More comments: this will make the usability of those files and the value of their presence in any MediaWiki repository exponentially more. the concept of Using parts of files (namely images, and multi-page images (pdf, tiff)) is also to be considered in the audio/video context, important parts of speeches or clips from much longer videos and so on. an ideal solution would be more computational where changes to the parent document file would cascade down to those partial ones; but in the vast majority of the cases, the scale does not change and it will not be a problem unless BOTH the document is heavily "cropped and annotated" and the file radically changes (dimensions, duration) which all can be worked around by uploading it as a new file.
  • Phabricator tickets:
  • Proposer: Uwe a (talk) 15:40, 25 November 2020 (UTC)[reply]

Discussion

  • @Uwe a: the toolforge:croptool can crop images and PDFs and upload the smaller versions as new files. Is this sufficient for your use case? This doesn't work for audio or video of course, but those are generally edited with desktop software anyway. —SWilson (WMF) (talk) 05:17, 2 December 2020 (UTC)[reply]
    @SWilson (WMF): the thing is that "sub documents" are many and "fluid", and what they have in common is their common "Parent" document or compilation so to say, and the connection made to that parent document, more often than not, are "to be" inherited to documents with this "child" relation, apart from the obvious date and place, the publisher or author...etc, the relation between different parent documents, or indirect relation between them give valuable context to the sub-documents, on the other hand, the sub-documents themselves add to the parent document, by annotations for example. So basically creating different files/documents by merely cropping scatters those documents, also finding a better version of a certain document would allow better versions of the subdocuments that might be defined dynamically with coordinates or with timestamps in case we are including audio and video in this discussion.--Uwe a (talk) 20:20, 8 December 2020 (UTC)[reply]

Brilliant idea. Not sure how feasible it is at the moment, but it's worth serious development. It means designing a system that encourages the creation of many different takes on each item; collects all those takes under their common parent, without drowning the general view; and allows each take to act independently and form connections in other relevant contexts (categories relevant only to that specific version etc.). All this without looking cluttered or confusing. Commons already indicates "other versions" in file pages, and these can be easily created with toolforge:croptool. However, there's no way of knowing about the existence of "other versions" without checking the page, and when creating new versions there's always the fear that creating too many would over-flood the category. So basically I assume that one way to start would be adding a small icon that indicates how many versions a file has. Maybe even a preview of all versions on hover? In that case, the solution to "flooding" would simply be not to categorize new versions; they would all be accessible under the main file. If all versions are grouped together and displayed as one item, there's no reason not to create dozens of versions and display them all as a gallery on the original work. --Joalbertine (talk) 19:42, 19 December 2020 (UTC)[reply]

Voting

Allow SDC SPARQL queries to more easily inteact with Wikidata queries

  • Problem: SDC uses a lot of Wikidata items to encode information about files: License, authorship, source, or depict statements are encoded using wikidata item IDs. Wikimedia Commons Query Service (WCQS) allows SPARQL queries to look up this metadata. Unfortunately many WCQS queries that need to access information from Wikidata, needs to use "service <https://query.wikidata.org/sparql>" which can access only few thousand wikidata items before failing. With 65M files on Commons, with number of files with SDC properties quickly unceasing, we need to be able to run queries that can access much lager number of Wikidata items.
  • Who would benefit: Users who query or maintain SDC properties
  • Proposed solution: Integrate WCQS and WDQS more closely to allow more information to be passed in-between
  • More comments: An example query which is hard to do at the moment: Find statements using redirected wikidata items
  • Phabricator tickets: phabricator:T261716
  • Proposer: Jarekt (talk) 04:27, 30 November 2020 (UTC)[reply]

Discussion

Voting

Increase file size limit

  • Problem: Currently file sizes are limited to 4 GB. That is a problem especially for high resolution and/or just long videos.
  • Who would benefit: Users who want to upload and use high resolution and/or long videos or other huge files.
  • Proposed solution:
  • More comments: Limitations to prevent abuse could be realized by limiting to user rights.(like it is currently for mp3 files) This would be a community discussion with the input of the tech team.
  • Phabricator tickets: task T191802
  • Proposer: GPSLeo (talk) 18:36, 16 November 2020 (UTC)[reply]

Discussion

  • We can't even upload files this size reliably anyway, especially PDFs and DJVUs. MER-C (talk) 20:28, 16 November 2020 (UTC)[reply]
  • While I want this too.. this is very unlikely to be picked up by that team, because it is a very complex, cross departmental and expensive problem. In my personal opinion, supporting this would require a significant investment of a dozen or so of engineers with specific domain knowledge, to bring this to 'the next' level. Such an engineering effort would also require continuous sustained development by a team of at least 8 people (eternally forward). (Remember something like Vimeo, is a company with 600 employees and this is the only thing they do). —TheDJ (talkcontribs) 21:29, 16 November 2020 (UTC)[reply]
    There are non-video uses for this proposal of course. --Izno (talk) 22:04, 16 November 2020 (UTC)[reply]
  • I thought its possible under special circumstances, isn't it? Juandev (talk) 20:12, 17 November 2020 (UTC)[reply]
    There's a hard cap of 4gb. This limit is technical in nature, the software wouldn't be able to handle anything larger even if we tried. -FASTILY 04:57, 18 November 2020 (UTC)[reply]
    Google and other media websites make it work. "The cap is technical" is not really a nuanced view of what 4GB actually represents. --Izno (talk) 05:07, 18 November 2020 (UTC)[reply]
    To be clear, I'm not advocating for the 4gb limit. There does seem to be a technical reason however: phab:T191805 -FASTILY 03:46, 21 November 2020 (UTC)[reply]
  • Without specifying the maximum amount of size, this proposal should be archived before the submission phase ends. The WMF's servers wouldn't hold much amount of very larger files as of date AFAIK. George Ho (talk) 08:51, 19 November 2020 (UTC)[reply]
  • I must say this is a safe mechanism: It will be technically possible to break the whole server (and website) through uploading bery large (e.g. 10+TB). Even if there is a hard cap, I suggest this cap not to be used, or at least, limit the right to those who genuinely need it.--1233 T / C 18:12, 19 November 2020 (UTC)[reply]
  • I support increasing the cap like 50GB to allow higher quality or long play videos to be added in commons. Recent historical events are recorded in high definition and even 4K resolution videos. We are now in 2020s and no longer in the dial up era. -- Exec8 (talk) 14:21, 27 November 2020 (UTC)[reply]

Voting

Showcase promoted content (FP/QI/VI) in categories and search results on Commons

  • Problem: Commons has robust procedures to highlight good content: Featured Pictures, Quality Images, and Valued Images. To an outside party, however, it is not immediately obvious how to find them (or that they exist).
  • Who would benefit: All Commons media users
  • Proposed solution: When you go to a category page, the FastCCI gadget is enabled by default to display a "Good Pictures" button, but it's not well integrated into the page, not integrated into search results, and is often broken (I have great appreciation for this gadget that I use all the time, so big thanks to its developer, Dschwen, but it could use more consistent attention). IMO it would probably be better to start from scratch to rethink how to integrate this content into category/search/other pages rather than just taking over FastCCI.
  • More comments:
  • Phabricator tickets:
  • Proposer: — Rhododendrites talk \\ 17:24, 29 November 2020 (UTC)[reply]

Discussion

In addition to the above proposal, c:Special:MediaSearch should maybe be a good place for an additional tab "Sort by: Quality/Featured/ect...", and why not one day a tab with "Sort by: Number of view/Number of fav./number of use/...". Also note that SDoC is promising in this topic. Christian Ferrer (talk) 19:05, 8 December 2020 (UTC)[reply]

Voting

Image Rotation

  • Problem: We often need to rotate the image so that we get two options at once: a horizontal version Podpraporshchik shoulder straps of 5th Special Infantry Regiment and a vertical version Podpraporshchik shoulder straps of 5th Special Infantry Regiment. Now it is very difficult to do this: you need to separately load another file with manual rotation.
  • Who would benefit: Wikimedia Commons and all its users: significant time savings.
  • Proposed solution: Modify the RotateBot. Now the bot only rotates the current file, writing it from the top. This leads to frequent cancellations of such actions, because the design of Wikipedia articles is unwanted.
  • More comments: Make the RotateBot available to authorized users.
  • Phabricator tickets:
  • Proposer: Niklitov (talk) 17:03, 19 November 2020 (UTC)[reply]

Discussion

Here's a tool for rotating jpg/png images. -FASTILY 10:53, 21 November 2020 (UTC)[reply]

Hm. Dear Fastily! This tool asks for a file from my computer's explorer, but it needs from Commons... That is, rotate files directly to Commons with copying, how the ⌗ CropTool works. — Niklitov (talk) 11:06, 21 November 2020 (UTC)[reply]
If you first download the file you wish to rotate from Commons, then this tool can do it for you. Automating this process from end-to-end is a little more involved and not something I currently have time for unfortunately. -FASTILY 11:12, 21 November 2020 (UTC)[reply]

There's also the RotateLink gadget that has a bot come around eventually and do the rotating.--Vera (talk) 12:12, 21 November 2020 (UTC)[reply]

  • Oh, sorry for my English. Dear Fastily and Vera: The SteinsplitterBot does not work as we would like! He rotates the replacement illustration. Ex.: File:1916oir08-pf21.png. Don't do that. And we need to make a copy. That is, you should get two illustrations instead of one! Can you somehow change how the bot works? Improve? Thank you in advance! — Niklitov (talk) 20:30, 21 November 2020 (UTC)[reply]
  • How about an additional parameter in the wikitext syntax? [[File:foo.jpg|90cw]]. It can be implemented in two ways:
    The parser could add a css class or css style with a rotation or
    The wikisoftware creates and saves a separate rotated version of the file automatically (internal, not shown in commons as a separate file) and displays it, if needed. -- DerFussi 22:23, 21 November 2020 (UTC)[reply]
    This is the best long-term solution imo. It could easily be done in CSS with the rotate() function, but will most certainly require buy-in from the MediaWiki devs. -FASTILY 01:05, 22 November 2020 (UTC)[reply]
  • Dear Fastily and DerFussi! This is great advice, but perfect for Wikipedia. Is this possible on Wikidata? For an article Wikidata infobox? — Niklitov (talk) 12:37, 23 November 2020 (UTC)[reply]

Couldn't this be solved using toolforge:crop – rotating and creating new file? --Joalbertine (talk) 20:07, 19 December 2020 (UTC)[reply]

Voting

Comment Comment. The [[File:foo.jpg|90cw]] idea only works on Wikipedia articles, but not in Wikipedia Templates, not in Wikidata infobox articles, not in Commons, etc. Niklitov (talk) 01:58, 10 December 2020 (UTC)[reply]

Crop tool to handle .SVGs

Discussion

Voting

Number of Pixels for images on Commons

  • Problem:

As already suggested in 2017, this doesn't take too much time to implement.

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)

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

Discussion

How would this be useful? · · · Peter (Southwood) (talk): 07:54, 22 November 2020 (UTC)[reply]

You oftentimes need to know how many Megapixels has that image, instead of calculating everytime, it would help to be shown directly. -- -donald- (talk) 17:48, 26 November 2020 (UTC)[reply]
For example when deciding about nominations to c:Commons:Featured picture candidates. — Draceane talkcontrib. 08:29, 27 November 2020 (UTC)[reply]
  • Seems at least a little bit useful, and may be worth it considering how easy it would probably be to implement. I'm thinking less of QI/FP and more of people using the images. There are lots of sites, uses, etc. that call for specific megapixel minimums, and it might be useful for some to see at a glance. Meh. — Rhododendrites talk \\ 17:07, 29 November 2020 (UTC)[reply]

Voting

Support for chemical formats

Discussion

Voting

Watchlisting an image would show when it is added or removed from a page

  • Problem: Watch-listing an image/file does not notify you to changes of its usage, i.e. when the image/file is added or removed from different pages across Wikimedia projects.
  • Who would benefit: Everyone. It would help monitor file misuse and would provide some satisfaction that hey, my image is being used.
  • Proposed solution: Adding a functionality that would show when an image in your watchlist is used (or no longer) across Wikimedia projects.
  • More comments:
  • Phabricator tickets:
  • Proposer: Renata3 (talk) 23:24, 25 November 2020 (UTC)[reply]

Discussion

I'm wondering what the functionality would look like. Would you be able to watchlist a file hosted on commons from, for example, jp.wikipedia? If so, should it show only additional usage on jp.wikipedia, with universal file usage be limited to watchlists on commons? Vanisaac (talk) 14:41, 29 November 2020 (UTC)[reply]

Voting

autoplaying and looping videos

  • Problem: videos currently do not autoplay or loop
  • Who would benefit: would allow better quality animatics than GIF animations
  • Proposed solution: add autoplay and loop methods to our visual file markup
  • More comments: perhaps also add a mute method to our visual file markup
  • Phabricator tickets:
  • Proposer: Extemporalist (talk) 09:47, 22 November 2020 (UTC)[reply]

Discussion

  • Auto-playing risks using up a bunch of people's datacaps and and is generally irritating when attempting to read articles.Geni (talk) 03:42, 2 December 2020 (UTC)[reply]
    • Autoplaying audio is definitely awful, but I can see valid use cases for silent videos to autoplay and loop; i.e. animated diagrams. Perhaps the autoplay feature could force the video to be muted until the user unmutes it. As for the data caps, we could disable autoplay on the mobile site; I imagine this feature primarily being useful for relatively simple short animations that likely wouldn't use much data anyway. --IagoQnsi (talk) 18:49, 8 December 2020 (UTC)[reply]
      • There is already (kind of) autoplay for video only - GIF images. I think this is good enough for most use cases (except maybe the lack of pause button, which would be a nice feature to have for a GIF). Martinkunev (talk) 14:22, 9 December 2020 (UTC)[reply]
It should be an opt-in in the preferences, not per default.  — Johannes Kalliauer - Talk | Contributions 05:17, 9 December 2020 (UTC)[reply]
  • Support silent autoplay only if there is a prominent pause button, and opt-out in Preferences. With opt-in 99% of readers will not know how to turn it on and will never see animation. Chetvorno (talk) 00:43, 17 December 2020 (UTC)[reply]

Voting

Make File syntax processing match the specification and documentation

  • Problem: File: syntax as described at mw:Help:Images is inconsistent and does not work as expected in all cases. Linter fails to identify all problem cases. The "parameters" (for lack of a better word) and options used in the File: syntax do not work in a predictable, consistent way, and their implementation is inconsistent with how template parameters work.
  • Who would benefit: Editors who add multimedia files to pages on all MediaWiki sites would experience more consistent results that are in line with the documentation and the editors' experience with template use.
  • Proposed solution:
    • I think that the entire File: syntax specification, if there is one, needs to be checked and adjusted to deal with the problems detailed in the various phabricator tickets linked below.
    • Then the MediaWiki File: handling code needs to be adjusted to match the specification.
    • Once that is done, the documentation needs to be adjusted to match the new specification.
    • As part of the code update, Linter needs to be adjusted to detect additional errors and to stop reporting false positives.
    • I am open to other solutions, but there is so much inconsistency that I think a thorough checkup is needed.
  • More comments: Note that many of the phabricator bugs linked below are characterized as Linter errors, but some of them identify situations in which an editor would reasonably, based on the documentation and similar syntax in other realms (e.g. templates) expect a certain behavior, and the File: renderer does not meet that expectation.
  • Phabricator tickets:
    • task T216566: Capitalized versions of valid File options are usually (but not always) ignored, but are (usually but not always) not flagged as Linter bogus file options.
    • task T216003: Linter fails to detect multiple "upright" parameters as a Bogus file option (there are multiple variants within this bug report, including inconsistent handling of spaces before and after equals signs in File: parameters. Note also that if there is a space character between alt and the equals sign, the alt statement will be treated as a caption.)
    • task T215999: Linter does not detect invalid "500px500px" as a bogus file option (also "600 px", "left150px", duplicated "300px")
    • task T179605: LintError bogus-image-options triggers on "Thumbtime" (in general, case sensitivity works inconsistently in File: syntax)
    • task T266406: Linter false positive: "Center/Left/Right" as caption for gallery image (no workaround is available)
    • task T264464: Conflicting border/thumb/frame options are not detected as Linter errors (Until October 2020, mw:Help:Images said "If multiple of these options are present, only the first one will be used". That statement was incorrect, in that some options have priority over others regardless of position, leading to inconsistent results for editors and readers.)
  • Proposer: Jonesey95 (talk) 22:00, 16 November 2020 (UTC)[reply]

Discussion

thumb in gallery bug

I would like to add one more Linter bug I have noticed. Most of the times it does not count thumb within the gallery tag as a bogus file option, even though thumb is invalid in gallery. en: H:GT AVSmalnad77 chat 08:58, 14 December 2020 (UTC)[reply]

This is addressed by https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/908671 Arlolra (talk) 23:01, 14 April 2023 (UTC)[reply]
Well, turned it turned into this https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/909340 Arlolra (talk) 20:53, 18 April 2023 (UTC)[reply]

Voting

Add Structured data during file upload with Upload Wizard

  • Problem: When uploading a new file we fill form with separate fields for author, date, coordinates, license, etc. Than that date is converted to Wikitext using Template:Information and several other templates, which then might be than parsed by various bots to populate SDC fields. A better solution would be to populate those SDC fields at the upload time.
  • Who would benefit: projects using the images, and especially the ones that rely on SDC fields.
  • Proposed solution: Many SDC properties should be added to the file during upload process with Upload Wizard. WE might want to have a flag to skip SDC update, for example when user uploads a file with intention to change the metadata latter
  • More comments:
  • Phabricator tickets: phabricator:T245861
  • Proposer: Jarekt (talk) 03:58, 30 November 2020 (UTC)[reply]

Discussion

Voting

Search by image size on Commons

  • Problem: There are many limitations to searching images on Commons. The one feature that's present in nearly every other image search on the web but not on Commons is to be able to search by image size. It can be difficult to scan through page after page of hits looking for a high resolution image necessary for particular purposes, but we only allow searching by text or by date. Once the text is narrowed enough, people are extremely likely to use a resolution sorting/filtering mechanism.
  • Who would benefit: Anyone using images on Commons, including Wikimedians and third parties.
  • Proposed solution: Ideally there would be a way to search for a megapixel range or to set minimum horizontal or vertical resolution for an image, plus a couple presets for e.g. "small", "medium", and "large". Additionally, it would be nice to be able to sort search results by size, too.
  • More comments:
  • Phabricator tickets:
  • Proposer: — Rhododendrites talk \\ 17:15, 29 November 2020 (UTC)[reply]

Discussion

  • With c:Special:MediaSearch there is already a tool in development witch supports this. --GPSLeo (talk) 13:52, 7 December 2020 (UTC)[reply]
    • Thanks. Hadn't seen that. At this point it seems like it's only the small/medium/large, rather than allow for more specific settings (and with the search I just did, nearly all of the results were already "large" so it didn't do much). It also isn't letting me sort that "large" group by size. So I guess this request can be reframed as "modify MediaSearch to be able to..."? — Rhododendrites talk \\ 14:42, 7 December 2020 (UTC)[reply]

Voting

Map in UploadWizard

  • Problem: It takes time to copy coordinates and directions to indicate the location of a photo.
  • Who would benefit: Everyone, especially those who take a lot of pictures for Commons.
  • Proposed solution: Add a map directly integrated in UploadWizard to point to a location, similar to what exists in structured data or on tools like Freeside (many newbies or occasional contributors don't even know their existance). This would save a lot of time and allow us to add more photos or specify location data more often.
  • More comments:
  • Phabricator tickets: T58612
  • Proposer: Baidax (talk) 16:48, 30 November 2020 (UTC)[reply]

Discussion

Voting