Wikimedia Meta-Wiki

Community Wishlist Survey 2021/Multimedia and Commons

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