Community Wishlist Survey 2021/Multimedia and Commons

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Multimedia and Commons
36 proposals, 75 contributors
The proposal phase has ended.
Come back on December 8 at 18:00 UTC to vote on proposals!



Flickr-like uploader

Edit proposal/discussion

  • 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 howt he 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)

Discussion

  • How would you add categories to those files? Are they coming with the folder? JopkeB (talk) 16:33, 17 November 2020 (UTC)
    • 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)
  • 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)
    • 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)
  • 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)
    • 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)
  • 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)
    • 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)
      • @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)
        • 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)
    • “[…] 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)
      • 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)
  • 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)
    @Pelikana Drag and drop upload will soon be improved by T47656. ESanders (WMF) (talk) 18:37, 2 December 2020 (UTC)
  • Seems like a reasonable proposal that would entice me more to start uploading images as well. --Ivario (talk) 22:23, 24 November 2020 (UTC)

Using svg and wikidata to allow multilingual images

Edit proposal/discussion

This works but is suboptimal since:
  • Reusability is reduced: For example provided, graph editing will be needed to use the image in more languages.
  • Maintenance work is increased: If I find a mistake in the image in es:wiki I can correct it. But I will need to do three different corrections to ensure all wikis are updated. This may be feasible for a small population (let's say local wiki and en:, as main targets) but is not scalable to a portfolio of projects like Wikimedia with hundreds of local projects.
Some alternative options exist like Kartographer but are not widely used.
  • Who would benefit: translators of content between wikis, people who do commons maintenance work, small wikis that are more reliant on commons and translation tools.
  • Proposed solution: I wonder if a more interactive SVG can be done where a text could be linked to a Wikidata element. For example in the above-mentioned map, instead of the text "Upper Hungary" I'd like to link to Wikidata Element Q999030. This already include the version for several idioms so a local wiki can retrieve localized names. There is already work in Wikidata for using a related language when no local version exist which provides a fallback.
It will reduce the amount of files in commons, facilitate a multilingual review and update of mistakes, facilitate reuse of images (with synergies with the content translator, since currently there is no integration for image translation), reduce barriers for small wikis.
  • More comments:
  • Phabricator tickets:
  • Proposer: FAR (talk) 11:58, 29 November 2020 (UTC)

Discussion

Inline Audio-Player for pronunciations and other usages

Edit proposal/discussion

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

Discussion

Search by image size on Commons

Edit proposal/discussion

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

Discussion

Allow SDC SPARQL queries to more easily inteact with Wikidata queries

Edit proposal/discussion

  • 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: Uses who query o 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)

Discussion

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

Edit proposal/discussion

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

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)

  • I'd be curious to know how this would be technically possible, but would be excited to use it. There are tools like GLAMorgan, GLAMorous, etc. to help identify which images are being used where, but it relies on running those tools every time and there's no way to learn of new uses. I think that most of us who contribute media to Commons do so with the hope that they will be used, but short of checking all the files on a regular basis or adding them ourselves there's no way to find out. — Rhododendrites talk \\ 17:04, 29 November 2020 (UTC)
  • This is the equivalent of making changes in "what links here" appear in the watchlist, right? I would also be excited to use that!--Uwe a (talk) 15:40, 30 November 2020 (UTC)

A proper image and video search results page

Edit proposal/discussion

  • Problem: The search page is not too bad to search text pages, but utterly terrible to search images or videos. On my 1920x1080 computer, this search only shows 5 minuscule thumbnails at a time. On my 1280x720 mobile phone, this search only shows two minuscule thumbnails at a time. The search page shows more white background than anything.
  • Who would benefit: Readers
  • Proposed solution: The search page should show images and videos with a tiled grid format, like Google or Creative Commons. There should be an option to change the thumbnail size. When the user clicks on an image, it should show the full-size preview.
  • More comments:
  • Phabricator tickets:
  • Proposer: NaBUru38 (talk) 18:14, 21 November 2020 (UTC)

Discussion

  • Hi, NaBUru38. There is a search view of Commons available at MediaSearch which provides a view more like what I think you are describing. Does that answer your wish? --AEzell (WMF) (talk) 01:30, 1 December 2020 (UTC)
    • Oh wow, that looks awesome!!! So my proposal is to use the MediaSearch by default at Wikimedia Commons or something like that. Thanks! --NaBUru38 (talk) 21:08, 2 December 2020 (UTC)
      • I mean, both the regular search and MediaSearch are useful in Wikimedia Commons. The website needs some changes so people can easily switch between them, depending on the case. --NaBUru38 (talk) 21:36, 2 December 2020 (UTC)

Audio file player

Edit proposal/discussion

Polskie: 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)

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)

  • Z pewnością należy ulepszyć istniejące narzędzie. Mocno popieram propozycję! CelStrzel (talk) 18:43, 17 November 2020 (UTC)
  • @Borys Kozielski: Widziałeś nowy odtwarzacz wideo/audio? Dostępny w Preferencjach jako funkcja eksperymentalna. Może takie coś Ci pasuje? tufor (talk) 20:20, 23 November 2020 (UTC)
  • @Tufor: Nie, dziękuję za podpowiedź. Sprawdziłem i niestety porażka. To nie jest odtwarzacz audio/wideo tylko wyłącznie wideo. Wprawdzie odtwarza audio, ale w oknie z wideo, czyli w przypadku nagrań wyłącznie audio wyświetlana jest czarna plansza Borys Kozielski (talk) 15:42, 27 November 2020 (UTC)

Separate property and user right for license, author and date

Edit proposal/discussion

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

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)

What many legitimate reasons? · · · Peter (Southwood) (talk): 07:50, 22 November 2020 (UTC)
Who has the time and inclination to be more vigilant about that? · · · Peter (Southwood) (talk): 07:47, 22 November 2020 (UTC)
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)
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)
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)

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

Edit proposal/discussion

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

Discussion

  • Agree. Sub-images yes, but also no annotation in time-based media leaves us in bad situation and need to upload to YouTube to be able to do this :-/ Zblace (talk) 06:31, 26 November 2020 (UTC)
  • @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)

Crop tool to handle .SVGs

Edit proposal/discussion

  • Problem: Our current image crop tool cannot crop .svgs
  • Who would benefit: Would make it easier to edit these images
  • Proposed solution: Some discussion here
  • More comments:
  • Phabricator tickets:
  • Proposer: Doc James (talk · contribs · email) 19:34, 28 November 2020 (UTC)

Discussion

Make subcategory browsing multilingual using Wikidata

Edit proposal/discussion

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

Discussion

Hi Mike Peel, trying to explain in English: is this wishful thinking or have I seen somewhere the goal is that infoboxes on the different Wikipedias should no longer be necessary? To give an example: a layout like Maia Sandu where a link to commons is integrated at the bottom of the infobox like here? Thank you for your time. Lotje (talk) 12:53, 21 November 2020 (UTC)

Map in UploadWizard

Edit proposal/discussion

  • 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:
  • Proposer: Baidax (talk) 16:48, 30 November 2020 (UTC)

Discussion

Support 360 photo viewing

Edit proposal/discussion

  • 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

Option to load SVG instead of PNG on pages by default

Edit proposal/discussion

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

Discussion

  • I think this would be an improvement overall, but this would also result in some issues for a small but non-zero number of SVG images that rely on librsvg quirks and would render differently if loaded directly. Jc86035 (talk) 09:57, 22 November 2020 (UTC)
    • @Jc86035: I think that this can be fixed, but not a very large problem. It should be a minor issue but not affecting a lot of things. The loader can also request a PNG version if it is using librsvg quirks (i.e. exemptions).--1233 T / C 10:20, 22 November 2020 (UTC)
      • Please see the discussion on serving/not-serving SVGs (mainly for missing reliable SVG sanitizer) at phabricator.wikimedia.org/T40010#6637830 --Volker E. (WMF) (talk) 18:31, 29 November 2020 (UTC)
        • Interesting question, but I'm curious if this is what this wishlist hope : if passed, the team would need to develop a reliable SVG sanitizer then.--1233 T / C 05:54, 30 November 2020 (UTC)

Increase file size limit

Edit proposal/discussion

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

Discussion

  • We can't even upload files this size reliably anyway, especially PDFs and DJVUs. MER-C (talk) 20:28, 16 November 2020 (UTC)
  • 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)
    There are non-video uses for this proposal of course. --Izno (talk) 22:04, 16 November 2020 (UTC)
  • I thought its possible under special circumstances, isn't it? Juandev (talk) 20:12, 17 November 2020 (UTC)
    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)
    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)
    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)
  • 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)
  • 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)
  • 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)

SVG to PNG converter that actually works

Edit proposal/discussion

  • 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:
  • Proposer: Ponor (talk) 04:33, 17 November 2020 (UTC)

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)
    @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)
    @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)
    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)
    That said, there was a Phab discussion for switching the renderer at phab:T40010. Do consider. --Izno (talk) 18:45, 17 November 2020 (UTC)
    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)
    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)

Photo challenge

Edit proposal/discussion

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

Discussion

Friendly mobile browser version for OS devices to upload photos

Edit proposal/discussion

  • Problem: The commons mobile app can be used only on android devices and it's not easy at all to upload photos using a OS device via the current mobile browser version.
  • Who would benefit: all Iphones/Ipads users
  • Proposed solution: if a mobile app is not possible at least imporve the mobile browser version.
  • More comments:
  • Phabricator tickets:
  • Proposer: Yamen (talk) 13:27, 21 November 2020 (UTC)

Discussion

  • @Yamen: We cannot create an iOS app from scratch, but we think we could improve the mobile web experience. Could you reword your proposal to focus on mobile web? Thanks! MusikAnimal (WMF) (talk) 04:47, 2 December 2020 (UTC)

Make File syntax processing match the specification and documentation

Edit proposal/discussion

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

Discussion

Improve graphs and interactive content

Edit proposal/discussion

Examples of Vega and Vega-Lite graphs we can build

4StrokeEngine Ortho 3D Small.gifMongol Empire map 2.gif

  • 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

autoplaying and looping videos

Edit proposal/discussion

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

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)

Bulk upload program

Edit proposal/discussion

Deutsche: Programm zum Massenupload

  • Problem: There are programs like Commonist or Vicuña, but they have not been maintained for a long time. For uploading larger amounts of images you need something like that, only in an improved form.
Deutsche: Es gibt Programme wie Commonist oder Vicuña, die werden aber schon lange nicht mehr gepflegt. Für das Hochladen größerer Bildermengen braucht man so etwas, nur in verbesserter Form.
  • Who would benefit:
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: Ralf Roletschek (talk) 13:04, 28 November 2020 (UTC)

Discussion

Das ist keine Alternative. --Ralf Roletschek (talk) 20:29, 1 December 2020 (UTC)
Warum? SGrabarczuk (WMF) (talk) 22:37, 1 December 2020 (UTC)

See Exif without restoring file

Edit proposal/discussion

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

Discussion

Interactive chess content

Edit proposal/discussion

  • 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)
    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. peace - קיפודנחש (talk) 18:23, 30 November 2020 (UTC)
    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)

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

Support for chemical formats

Edit proposal/discussion

Discussion

More Videos on Commons

Edit proposal/discussion

  • Problem: Wikipedia is relaying too much on text whilst video is becoming more important as information source for new generation. To upload a video to commons you have to be a real techies to have the right format which is not obvious for anyone.
  • Who would benefit: all users: new generation and people who has reading difficulties
  • Proposed solution: provide a way to import open licence video from video platforms e.g. vimeo or provide a simple way to convert video to the acceptable commons format.
  • More comments:
  • Phabricator tickets:
  • Proposer: Yamen (talk) 13:18, 21 November 2020 (UTC)

Discussion

New Gadget - Mark Files used in a Wiki or Wikidata

Edit proposal/discussion

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

Discussion

Upload to current category

Edit proposal/discussion

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

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)

  • @Theklan: There's a link to do this in the infobox in the Commons categories. Thanks. Mike Peel (talk) 20:54, 20 November 2020 (UTC)
@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)
@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)
  • @Theklan: Good point. Let's have this proceed to voting then. It'd be great to make Commons more newcomer-friendly. —SWilson (WMF) (talk) 09:58, 3 December 2020 (UTC)

Image Rotation

Edit proposal/discussion

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

Discussion

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

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)
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)

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)

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

Improve Graph Extension

Edit proposal/discussion

  • Problem: Our ability to graph data is current poor. We have some examples of our ability here.
  • Who would benefit: All readers across all languages. Rich content was one of the top request in our prior reader survey.
  • Proposed solution: Make our graph extension work like that of OurWorldinData. OurWorldinData is interested and willing to collaborate and use a compatible license. Their content received about 250 million views this year.[1] Currently we have imported static versions,[2] but making our site more interactive would be a plus.
  • More comments:
    I wrote w:Template:Interactive COVID-19 maps using the graph extension and one frustrating piece is that our extension still uses Vega 2. The Vega project is now on version 5 with increased support for mobile devices and simply upgrading the extension to a more modern branch would make a huge difference. Wugapodes (talk) 01:01, 29 November 2020 (UTC)
  • Phabricator tickets: The workboard[3]
  • Proposer: Doc James (talk · contribs · email) 19:52, 28 November 2020 (UTC)

Discussion

Add Structured data during file upload with Upload Wizard

Edit proposal/discussion

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

Discussion

  • This is a great idea. NMaia (talk) 03:15, 3 December 2020 (UTC)

Add wikitext description pages for Commons tabular data files

Edit proposal/discussion

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

Discussion

  • Huh, I didn't realize these were in a separate "Data" namespace, rather than under "File". I realize data files don't display readily as images, is that the reason for the distinction? In any case, aside from display, I can't think of any good reason for treating data files so differently from image files, they should have most of the same metadata fields for example. ArthurPSmith (talk) 16:20, 18 November 2020 (UTC)
  • "Nor is it possible to describe properly where the data has come from, or any issues with it." There is a description, license and a sourcing field in the format for each. I agree it isn't easy to use, but when people read the help pages (which they need to do anyways, to even begin to understand how to use these spaces), then these fields are documented. I'd say we should not confuse ability to document things with people's motivation/desire to actually do so in practice, which i find just as, if not even more likely to be the problem. —TheDJ (talkcontribs) 15:15, 2 December 2020 (UTC)

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

Edit proposal/discussion

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

Discussion

Number of Pixels for images on Commons

Edit proposal/discussion

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

  • Who would benefit: All common users
  • Proposed solution: Add number of Mpix to the image dimesions
  • More comments:
  • Phabricator tickets:
  • Proposer: -donald- (talk) 06:24, 17 November 2020 (UTC)

Discussion

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

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)
For example when deciding about nominations to c:Commons:Featured picture candidates. — Draceane talkcontrib. 08:29, 27 November 2020 (UTC)
  • 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)

Image inheritance, a bequest safe for Wikimedia Commons

Edit proposal/discussion

  • 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)
    • 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)
  • 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)
  • I wonder whether some kind of collaboration with Flickr would be good for this. — Bilorv (talk) 19:43, 17 November 2020 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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 find and undeleted. Issue: we have already a big DR backlog. Christian Ferrer (talk) 19:01, 20 November 2020 (UTC)