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.
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)[reply]
"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 helppages (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 (talk • contribs) 15:15, 2 December 2020 (UTC)[reply]
Support Yeah, this is just way-broken right now. That said, I have seen techniques (e.g. in people's JS and CSS pages) for escaping stuff and making it MW content, e.g. to add categories, or apply w:en:Template:Italic_title, etc., so maybe there's a way to do that with these pages already (perhaps variable on a per-format basis)? Still, it would be better to just have a wiki "frame" around the actual content file. — SMcCandlish ☺☏¢ >ʌⱷ҅ᴥⱷʌ< 07:35, 15 December 2020 (UTC)[reply]
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
Make it based on localisation. Reason- seasons are different between Northern and Southern hemispheres. Some places at equator have no "seasons" so they can ignore. CaribDigita (talk) 06:46, 14 December 2020 (UTC)[reply]
Oppose This is an intriguing idea, but the encyclopedic record of a place should reflect how it appears in all seasons, so I'm not sure it's something that'd be desirable. And even if it is, it's not something we'd need developer help to accomplish, as we already have templates/magic words that can detect the time and date and display different material accordingly. {{u|Sdkb}}talk09:42, 9 December 2020 (UTC)[reply]
Oppose Basically, the idea could be good if we had good photos for all seasons. We should first of all choose the best and most representative photo. In a lot of places, snow doesn't fall every year and it would be weird to assert a default image that rarely represents the subject. To be honest, this raises even more problems for small gain. However, I still haven't done it (so I'll try to do it today): it would simply be necessary to ask to add the property winter view (P5252) to the infobox. — Baidax💬17:33, 21 December 2020 (UTC)[reply]
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.
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)[reply]
@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)[reply]
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)[reply]
It can be implemented as a beta-feature in the preferences for specifically flagged files, but due to several reason (Maleware-Safety issues, different rendering on the individual browser, missing fonts, increased client-rendering-time, ...), it should not become a default option for svg-files. PS: You do not want to render files such as GermanyMap, World Map, many blurs, or just lines and circles locally, some browser will crash.
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.
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 svgsRendering by most browsers
2a) Times/Times New Roman/Arial/Calibri/Helvetia are licensed and are not available on linux (and not on WikiMedia), however those licensed fonts are handled as most web-savest fonts, so basically if you want to support Linux (I'm currently on Linux) there are imho no web-safe fonts (ok linux has some replacements, but that's problematic as well) Basically if Wikimedia does not have a font, Linux won't have the font either, therefore don't use it.
@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 | Contributions15:44, 12 December 2020 (UTC)[reply]
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.
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]
Support My endorsement as it allows svg animation. As for the problem pointed out by @JoKalliauer:, we can set the default display format to png and add an option to display in original svg for those animated ones.IamCristYe (talk) 12:56, 12 December 2020 (UTC)[reply]
@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)[reply]
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
@4nn1l2: What is the use case? Could you give an example? I don't know that we could always show EXIF data to everyone. This data can be manipulated and could contain something offensive or otherwise inappropriate that shouldn't be visible. MusikAnimal (WMF) (talk) 21:21, 23 November 2020 (UTC)[reply]
I made my proposal clearer. Of course, I meant to add an ability to MediaWiki so that only admins could see Exif of deleted files. I am searching for a good example, but it may take some time. 4nn1l2 (talk) 23:08, 23 November 2020 (UTC)[reply]
@MusikAnimal (WMF):I tried to write a query to search for the word "exif" among deletions by User:Túrelio on Commons. I am almost sure that I have seen them restoring a file temprorily to see its Exif. Unfortunately, the query does not work: quarry:query/50029. Could you please take a look and help me fix it. Sorry for the trouble.4nn1l2 (talk) 00:19, 24 November 2020 (UTC)[reply]
Thanks! I think the proposal is very clear and well-written now :) I have a tiny bit of doubt this sort of feature belongs in MediaWiki, but we could certainly build a gadget to do this, also checking if the EXIF data is available in structured data (as Geert Van Pamel notes below). MusikAnimal (WMF) (talk) 04:09, 24 November 2020 (UTC)[reply]
But I think here we arrive back at the original question: when the image has been deleted, the SDoC most probably is not accessible any more since the image is not available on Commons any more, so the structured data is not accessible neither? Or maybe the data is still searchable? Who can confirm this? Geert Van Pamel (WMBE) (talk) 18:31, 26 November 2020 (UTC)[reply]
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.
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.")
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. — Draceanetalkcontrib.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]
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]
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! ... GiorgioGaleotti18:33, 19 December 2020 (UTC)[reply]
Support, with a twist. My own photo stack is 99% raw. Right now, Commons won't host proprietary Sony or Canon formats. Dead end? probably. But, maybe, there is some workaround possible. Retired electrician (talk) 18:55, 15 December 2020 (UTC)[reply]
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?
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]
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. -FASTILY04: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).
@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 | Contributions10:54, 10 December 2020 (UTC)[reply]
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"!)
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.
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. PiotrekDTALK15: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. -- DerFussi09: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). -- DerFussi22: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, PiotrekDTALK11: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]
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]
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]
Support But, if "flickr-like uploader" will be for newbies, why would disscussing experienced users problems? And i think, that upload-wizard is fully ready for new users. (Do you try this in few last months? I am!) Frettie (talk) 22:49, 8 December 2020 (UTC)[reply]
Support We need better tools. this proposal should solve the problem with categorisation. And there are many upload(er)s with simple copyying description and filenames, so this tool wouldn't make it worse.. JAn Dudík (talk) 20:03, 9 December 2020 (UTC)[reply]
Support Uploading images should be made more user-friendly, at the moment it's too complex and time consuming to encourage users to add more images. Piensaimnieks (talk) 12:59, 10 December 2020 (UTC)[reply]
Support Agree this is an issue that needs solving, I think some user research is needed to understand the best ways to ask people to add additional information needed on top of what Flickr does, also would suggest looking at Instagram, Facebook etc interface to see if there's anything we could use John Cummings (talk) 17:16, 10 December 2020 (UTC)[reply]
Support At least 1) make possible to annotate the files while they are uploading 2) make adding categories more intuitive as navigation in cat-tree in HotCat is. — Draceanetalkcontrib.13:23, 15 December 2020 (UTC)[reply]
sort of Support, as long as there is an opt-out provision. I certainly would appreciate a good built-in mass upload tool, but I also remember the spectacular failure of the "upload wizard"... so don't expect much. Retired electrician (talk) 19:34, 15 December 2020 (UTC)[reply]
Support Please make the UploadWizzard more ergonomic by supplying the option of centrally setting /remembering the few Caption and Description Languages to be used Peli (talk) 12:04, 16 December 2020 (UTC)[reply]
Neutral In my opinion, the UploadWizzard is easy enough to use as it is. Licensing files does require some basic knowledge, and a simpler design won't change that. Nachtbold (talk) 17:34, 21 December 2020 (UTC)[reply]
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.
Support Let's try to be ahead of the curve rather than behind the curve on this one. 360-degree photos are only going to become more popular over time, and we should want to promote them. {{u|Sdkb}}talk09:50, 9 December 2020 (UTC)[reply]
Support There are many stunning 360° panorama works on Commons. It'd be nice to be able to view these photos or even videos in an interactive, straightforward way. WindowPain (talk)02:23, 16 December 2020 (UTC)[reply]
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.
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]
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. — Rhododendritestalk \\ 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
Support Would be useful to have, volunteer created extension is a good start but could use some WMF support for review and deployment DannyS712 (talk) 18:04, 8 December 2020 (UTC)[reply]
Support as it provides engaging interactivity in a manner that will degrade gracefully for readers using browsers with fewer features/resources. Isaacl (talk) 04:32, 11 December 2020 (UTC)[reply]
Support There is a dedicated volunteer community of people who produce and publish chess content in other platforms. If we did this, then that community would migrate to the Wikimedia platform because we would meet a lot of needs. The chess community is international, multilingual, highly collaborative, and enthusiastic about data and archiving. Chess articles which could better show boards would translate very well. This is a small technical development which can attract a large volunteer publishing community which needs a multilingual data friendly home. Blue Rasberry (talk)16:24, 12 December 2020 (UTC)[reply]
User:Bluerasberry: actual storage is somewhat a different issue. currently, wikidata hosts several games such that the pgn of the game can be extracted, but i doubt this method is appropriate for large number of games. see, e.g., d:Q936161 and d:Property:P5286. you may want to propose another wish (next time around, maybe) to allow storage of chess games, and optionally "game sets", e.g., for tournaments, in a common repository, either commons, a new one, or some better way to do it in wikidata. see this module on hewiki: he:Module:Chess, which pulls the pgn from wikidata, and can feed it to other templates or modules, either for drawing chess diagrams of any or all positions in the game, or for interactive display. see he:User:קיפודנחש/ארגח 2, and look at its source. peace - קיפודנחש (talk) 19:42, 13 December 2020 (UTC)[reply]
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.
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.
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)[reply]
Support My experiences trying to add graphs and interactive content to articles give me a clear impression that there is a lot to be desired. {{u|Sdkb}}talk09:56, 9 December 2020 (UTC)[reply]
Support Vega's interactive graphs are outstanding. It would be a powerful tool to be embedded into Wikipedia. Since the syntax can be quite complex for unexperienced users, a collection of presets and examples would be of help to start editing. Lion-hearted85 (talk) 12:09, 9 December 2020 (UTC)[reply]
Support the graph extension desperately needs some love. Currently it is causing 10% of all our JavaScript production errors partly due to a spike in usage this year. Jdlrobson (talk) 15:52, 15 December 2020 (UTC)[reply]
Support This is a much and very long needed feature for Wikipedia. I have been quietly advocating for something like this for years now. Discott (talk) 09:46, 16 December 2020 (UTC)[reply]
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: 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.
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.
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)[reply]
@Mike Peel:, I'll just leave if for what it is. Not interested/motivated enough to search al all over the place to put a question forword to which I might never reeive a reply. Thank you for your time anyway and sorry having bothered you. Lotje (talk) 06:51, 12 December 2020 (UTC)[reply]
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.
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. -FASTILY23:57, 21 November 2020 (UTC)[reply]
To name a few: editor uploading a file form an external website but choosing the wrong license (happens all the time with Flickr uploads, permission submitted via OTRS), license migrations, marking obvious PD-simple files as such. Plenty of folks monitor recent changes for vandalism. -FASTILY10:00, 22 November 2020 (UTC)[reply]
As stated above. Admins and bots are able to edit this. Monitoring recent changes? As fast as the recent changes run through? And I am sure, the folks have better things to do in their free time than monitoring vandalism, especially if some features can avoid some kind of vandalism. And by the way its not easy to recognize some of this edits as vandalism. Especially when its not that obvious. -- DerFussi19:59, 22 November 2020 (UTC)[reply]
To some point, the question is : Could there be a "localized" fields with protections applied to it (a field receiving author information at upload time) on a mediawiki page ? I've discussed such principle and tools for a different context and it has many alternative applications. I proposed to use templates about this 5 years ago (it can be in 'no show' wikicode). For the discussed case, whenever a change is brought to a file, "authors" (as well as alternative fields) can be compared. And according to the result of a 'diff' command, according to the results and respective situations, a proper management of these cases can be done. It's what I called an "authorship bot" in the JSL protocol, used in an alternative context of research literature production (see related logigramme). Such a tool is very useful whenever there is a primary-'wiki'-source to be taken accountable (artists, authors, journalists, researchers, any primary information producer). (For instance, in France we cannot "give" a work to public domain because moral rights and duties cannot be ceded).
The discuss case can have the following situations:
where authors and upload account differ, it can trigger a verification protocol (bot or human-community based)
where authors field (or any judge critical) change, it can be a) notified, b) reverted and put under protection etc. according to vandalism diagnostics (is it a case, an attribution error etc. ?)
The fact than it can be done by humans is not an argument for it not to be done by a script / bot / automated protocol (whatever you name it).
--RP87 (talk) 13:58, 11 December 2020 (UTC)[reply]
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.
if(mw.config.get('wgNamespaceNumber')===14){$(function(){// upload in catmw.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&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>');});}
@Mike Peel: Not all categories have the infobox. I have checked now the featured picture, for example, and it doesnt: c:Category:Point_Reyes_headlands. When looking to a category with the template, indeed, the link is there, but it wans't obvious that the link would upload an image to that category, because the text is not explicit (this has a really easy solution).
@Theklan: It's present in around 50% of categories now. It could easily be added to the rest, but we've been trying to add it at the same time as the Wikidata sitelinks - although the unlinked version still displays the upload link. The text is commons:MediaWiki:Cx-contributions-upload, if there's a better ux string that can be used while keeping things multilingual, I'm happy to change it! Thanks. Mike Peel (talk) 13:55, 3 December 2020 (UTC)[reply]
This feature would be great for campaign organizers that seek attract new collaborators. I know that there are other tools for campaigns, but this button is helpful for understand that you are participating in a campaign by adding the file to a category. Many new users that want collaborate in a specific campaign aren't aware of categories.--Señoritaleona (talk) 00:25, 19 December 2020 (UTC)[reply]
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.
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)[reply]
@Uwe a: the toolforge:croptool can crop images and PDFs and upload the smaller versions as new files. Is this sufficient for your use case? This doesn't work for audio or video of course, but those are generally edited with desktop software anyway. —SWilson (WMF) (talk) 05:17, 2 December 2020 (UTC)[reply]
@SWilson (WMF): the thing is that "sub documents" are many and "fluid", and what they have in common is their common "Parent" document or compilation so to say, and the connection made to that parent document, more often than not, are "to be" inherited to documents with this "child" relation, apart from the obvious date and place, the publisher or author...etc, the relation between different parent documents, or indirect relation between them give valuable context to the sub-documents, on the other hand, the sub-documents themselves add to the parent document, by annotations for example. So basically creating different files/documents by merely cropping scatters those documents, also finding a better version of a certain document would allow better versions of the subdocuments that might be defined dynamically with coordinates or with timestamps in case we are including audio and video in this discussion.--Uwe a (talk) 20:20, 8 December 2020 (UTC)[reply]
Brilliant idea. Not sure how feasible it is at the moment, but it's worth serious development. It means designing a system that encourages the creation of many different takes on each item; collects all those takes under their common parent, without drowning the general view; and allows each take to act independently and form connections in other relevant contexts (categories relevant only to that specific version etc.). All this without looking cluttered or confusing. Commons already indicates "other versions" in file pages, and these can be easily created with toolforge:croptool. However, there's no way of knowing about the existence of "other versions" without checking the page, and when creating new versions there's always the fear that creating too many would over-flood the category. So basically I assume that one way to start would be adding a small icon that indicates how many versions a file has. Maybe even a preview of all versions on hover? In that case, the solution to "flooding" would simply be not to categorize new versions; they would all be accessible under the main file. If all versions are grouped together and displayed as one item, there's no reason not to create dozens of versions and display them all as a gallery on the original work. --Joalbertine (talk) 19:42, 19 December 2020 (UTC)[reply]
Support Or more generally, a way to create derivative images with way less hassle. Often I just need to crop out crooked edges from poorly scanned files, and it can sometimes take half an hour or so (adding categories, copying over the license info, noting who the original author was, adding in the "Other versions" stuff, etc.), when it really shouldn't take more than about 30 sec. beyond the time it took to do the image editing. E.g., I should be able to click something like "Add a new variant of this image", pick the file to upload, add a description, and click "Submit". — SMcCandlish ☺☏¢ >ʌⱷ҅ᴥⱷʌ< 07:32, 15 December 2020 (UTC)[reply]
Problem: SDC uses a lot of Wikidata items to encode information about files: License, authorship, source, or depict statements are encoded using wikidata item IDs. Wikimedia Commons Query Service (WCQS) allows SPARQL queries to look up this metadata. Unfortunately many WCQS queries that need to access information from Wikidata, needs to use "service <https://query.wikidata.org/sparql>" which can access only few thousand wikidata items before failing. With 65M files on Commons, with number of files with SDC properties quickly unceasing, we need to be able to run queries that can access much lager number of Wikidata items.
Who would benefit: Users who query or maintain SDC properties
Proposed solution: Integrate WCQS and WDQS more closely to allow more information to be passed in-between
More comments: An example query which is hard to do at the moment: Find statements using redirected wikidata items
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.
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 (talk • contribs) 21:29, 16 November 2020 (UTC)[reply]
There's a hard cap of 4gb. This limit is technical in nature, the software wouldn't be able to handle anything larger even if we tried. -FASTILY04:57, 18 November 2020 (UTC)[reply]
Google and other media websites make it work. "The cap is technical" is not really a nuanced view of what 4GB actually represents. --Izno (talk) 05:07, 18 November 2020 (UTC)[reply]
Without specifying the maximum amount of size, this proposal should be archived before the submission phase ends. The WMF's servers wouldn't hold much amount of very larger files as of date AFAIK. George Ho (talk) 08:51, 19 November 2020 (UTC)[reply]
I must say this is a safe mechanism: It will be technically possible to break the whole server (and website) through uploading bery large (e.g. 10+TB). Even if there is a hard cap, I suggest this cap not to be used, or at least, limit the right to those who genuinely need it.--1233 （T / C） 18:12, 19 November 2020 (UTC)[reply]
I support increasing the cap like 50GB to allow higher quality or long play videos to be added in commons. Recent historical events are recorded in high definition and even 4K resolution videos. We are now in 2020s and no longer in the dial up era. -- Exec8 (talk) 14:21, 27 November 2020 (UTC)[reply]
Support in spirit, after issues discussed above are worked out. I do like the idea of having a user right like "LargeFileUploader", to stop people from doing asinine things like uploading Blu-ray rips and other copyvios, or just hitting Commons with a form of DoS attack sending enormous files of garbage. — SMcCandlish ☺☏¢ >ʌⱷ҅ᴥⱷʌ< 07:39, 15 December 2020 (UTC)[reply]
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.
Not anymore! :-) But hey, this is awesome to see this proposal! Apologies for the recent absence, life has way of keeping me busy.. Anyhow, I think the low hanging fruit would be to add additional maintainers to the project, so that I'm not the single point of failure, if the server goes down. I'd be happy to sit down with potential volunteers to explain the code (which is on GitHub as well) and the basic concepts behind it. --Dschwen (talk) 22:15, 4 January 2021 (UTC)[reply]
Support "Highlights" projects are a significant part of Commons life, and a great way to promote content. Any development in this direction will be beneficial for everyone and for the Wikimedia projects. Christian Ferrer (talk) 19:05, 8 December 2020 (UTC)[reply]
Support. I'm not sure exactly what I'd want to see (just boosting those images in search results could be problematic, as search results are supposed to reflect pertinence rather than quality), but some attention to this would be helpful. {{u|Sdkb}}talk09:45, 9 December 2020 (UTC)[reply]
Support Commons is flooded with content of not-so-great quality, and e.g. for teaching you need the most clear, meaningful and telling media. So a function like this is a must, it saves much time in contrast to browsing the whole categories. Nefronus (talk) 07:24, 15 December 2020 (UTC)[reply]
@Iketsi: The FastCCI (CCI = Commons Category Intersection) tool does just that! If you have specific research needs, I'd be happy to work with you. --Dschwen (talk) 23:50, 5 January 2021 (UTC)[reply]
Problem: We often need to rotate the image so that we get two options at once: a horizontal version and a vertical version . 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.
Hm. Dear Fastily! This tool asks for a file from my computer's explorer, but it needs from Commons... That is, rotate files directly to Commons with copying, how the ⌗ CropTool works. — Niklitov (talk) 11:06, 21 November 2020 (UTC)[reply]
If you first download the file you wish to rotate from Commons, then this tool can do it for you. Automating this process from end-to-end is a little more involved and not something I currently have time for unfortunately. -FASTILY11:12, 21 November 2020 (UTC)[reply]
Oh, sorry for my English. Dear Fastily and Vera: The SteinsplitterBot does not work as we would like! He rotates the replacement illustration. Ex.: File:1916oir08-pf21.png. Don't do that. And we need to make a copy. That is, you should get two illustrations instead of one! Can you somehow change how the bot works? Improve? Thank you in advance! — Niklitov (talk) 20:30, 21 November 2020 (UTC)[reply]
How about an additional parameter in the wikitext syntax? [[File:foo.jpg|90cw]]. It can be implemented in two ways:
The parser could add a css class or css style with a rotation or
The wikisoftware creates and saves a separate rotated version of the file automatically (internal, not shown in commons as a separate file) and displays it, if needed. -- DerFussi22:23, 21 November 2020 (UTC)[reply]
This is the best long-term solution imo. It could easily be done in CSS with the rotate() function, but will most certainly require buy-in from the MediaWiki devs. -FASTILY01:05, 22 November 2020 (UTC)[reply]
Comment. The [[File:foo.jpg|90cw]] idea only works on Wikipedia articles, but not in Wikipedia Templates, not in Wikidata infobox articles, not in Commons, etc. — Niklitov (talk) 01:58, 10 December 2020 (UTC)[reply]
You oftentimes need to know how many Megapixels has that image, instead of calculating everytime, it would help to be shown directly. -- -donald- (talk) 17:48, 26 November 2020 (UTC)[reply]
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. — Rhododendritestalk \\ 17:07, 29 November 2020 (UTC)[reply]
Problem: Data formats for chemical structures exist for long time: w:Chemical Markup Language, w:en:Protein Data Bank (file format), but WMF projects on chemistry topics still used rendered files, generic SVGs and projections of 3D structure on plane without possibility to view structure in 3D.
Who would benefit: All editors who work on chemistry topics.
Proposed solution: WMF need to allocate resources to add support for feature proposed back into 2008 or may be one of local chapters may take a lead on this as Wikidata was implemented by Wikimedia Deutschland.
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.
I'm wondering what the functionality would look like. Would you be able to watchlist a file hosted on commons from, for example, jp.wikipedia? If so, should it show only additional usage on jp.wikipedia, with universal file usage be limited to watchlists on commons? Vanisaac (talk) 14:41, 29 November 2020 (UTC)[reply]
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. — Rhododendritestalk \\ 17:04, 29 November 2020 (UTC)[reply]
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)[reply]
Auto-playing risks using up a bunch of people's datacaps and and is generally irritating when attempting to read articles.Geni (talk) 03:42, 2 December 2020 (UTC)[reply]
Autoplaying audio is definitely awful, but I can see valid use cases for silent videos to autoplay and loop; i.e. animated diagrams. Perhaps the autoplay feature could force the video to be muted until the user unmutes it. As for the data caps, we could disable autoplay on the mobile site; I imagine this feature primarily being useful for relatively simple short animations that likely wouldn't use much data anyway. --IagoQnsi (talk) 18:49, 8 December 2020 (UTC)[reply]
There is already (kind of) autoplay for video only - GIF images. I think this is good enough for most use cases (except maybe the lack of pause button, which would be a nice feature to have for a GIF). Martinkunev (talk) 14:22, 9 December 2020 (UTC)[reply]
Support silent autoplay only if there is a prominent pause button, and opt-out in Preferences. With opt-in 99% of readers will not know how to turn it on and will never see animation. Chetvorno (talk) 00:43, 17 December 2020 (UTC)[reply]
Oppose Playing a video is something that should be decided by the user. "I want to see this so I will click on it" is better in terms of usability than "I never wanted this to play but the site forces me to stop it". Martinkunev (talk) 23:17, 8 December 2020 (UTC)[reply]
Strong oppose I do not have the words to express how much I detest autoplaying videos; especially those with sound! If I want to watch a video, I want to push a button to tell it when to go.ONUnicorn (talk) 21:43, 11 December 2020 (UTC)[reply]
Problem: File: syntax as described at mw:Help:Images is inconsistent and does not work as expected in all cases. Linter fails to identify all problem cases. The "parameters" (for lack of a better word) and options used in the File: syntax do not work in a predictable, consistent way, and their implementation is inconsistent with how template parameters work.
Who would benefit: Editors who add multimedia files to pages on all MediaWiki sites would experience more consistent results that are in line with the documentation and the editors' experience with template use.
Proposed solution:
I think that the entire File: syntax specification, if there is one, needs to be checked and adjusted to deal with the problems detailed in the various phabricator tickets linked below.
Then the MediaWiki File: handling code needs to be adjusted to match the specification.
Once that is done, the documentation needs to be adjusted to match the new specification.
As part of the code update, Linter needs to be adjusted to detect additional errors and to stop reporting false positives.
I am open to other solutions, but there is so much inconsistency that I think a thorough checkup is needed.
More comments: Note that many of the phabricator bugs linked below are characterized as Linter errors, but some of them identify situations in which an editor would reasonably, based on the documentation and similar syntax in other realms (e.g. templates) expect a certain behavior, and the File: renderer does not meet that expectation.
Phabricator tickets:
task T216566: Capitalized versions of valid File options are usually (but not always) ignored, but are (usually but not always) not flagged as Linter bogus file options.
task T216003: Linter fails to detect multiple "upright" parameters as a Bogus file option (there are multiple variants within this bug report, including inconsistent handling of spaces before and after equals signs in File: parameters. Note also that if there is a space character between alt and the equals sign, the alt statement will be treated as a caption.)
task T215999: Linter does not detect invalid "500px500px" as a bogus file option (also "600 px", "left150px", duplicated "300px")
task T179605: LintError bogus-image-options triggers on "Thumbtime" (in general, case sensitivity works inconsistently in File: syntax)
task T266406: Linter false positive: "Center/Left/Right" as caption for gallery image (no workaround is available)
task T264464: Conflicting border/thumb/frame options are not detected as Linter errors (Until October 2020, mw:Help:Images said "If multiple of these options are present, only the first one will be used". That statement was incorrect, in that some options have priority over others regardless of position, leading to inconsistent results for editors and readers.)
I would like to add one more Linter bug I have noticed. Most of the times it does not count thumb within the gallery tag as a bogus file option, even though thumb is invalid in gallery. en: H:GTAVSmalnad77 chat08:58, 14 December 2020 (UTC)[reply]
Support Anything that brings consistency and predictability to File: options and hunting for lint errors gets my vote. Both of these areas have learning curves in places they shouldn't. Pauli133 (talk) 17:25, 9 December 2020 (UTC)[reply]
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
Support We should cater for cases where the uploader is stating "own work", and can tell us that they are the subject of a Wikidata item; or that the work is that of a third party who is the subject of a Wikidata item. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits22:56, 9 December 2020 (UTC)[reply]
Support Only if it replaces manual fields. Otherwise Oppose, there's already a lot of clutter on UW brought by SDC which significantly complicates uploading. - DarwinAhoy!01:26, 10 December 2020 (UTC)[reply]
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.
Thanks. Hadn't seen that. At this point it seems like it's only the small/medium/large, rather than allow for more specific settings (and with the search I just did, nearly all of the results were already "large" so it didn't do much). It also isn't letting me sort that "large" group by size. So I guess this request can be reframed as "modify MediaSearch to be able to..."? — Rhododendritestalk \\ 14:42, 7 December 2020 (UTC)[reply]
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.
Support Only if it rounds the coordinates to D°M′S″ with no decimals, or if that is technically difficult, exactly four decimals in the decimal format, i.e. D.dddd°. Abductive (talk) 09:04, 9 December 2020 (UTC)[reply]
support though I have to say, I don't know what this would look like and how you would prevent it from being too resource intensive with lots of uploads — Rhododendritestalk \\ 14:54, 9 December 2020 (UTC)[reply]
If it's about the Exif, most files don't have such coordinates and therefore they must be added manually. If it's about Commons metadata, it's much easier to add them directly at the upload, rather than going through the metadata, which often takes more time and doubles a task. Small contributors may not even know what it is. — Baidax💬17:42, 21 December 2020 (UTC)[reply]
Support * Pppery * it has begun 02:07, 9 December 2020 (UTC)
Oppose This is an intriguing idea, but the encyclopedic record of a place should reflect how it appears in all seasons, so I'm not sure it's something that'd be desirable. And even if it is, it's not something we'd need developer help to accomplish, as we already have templates/magic words that can detect the time and date and display different material accordingly. {{u|Sdkb}} talk 09:42, 9 December 2020 (UTC)
Neutral if it's adaptable to the user's position on Earth. Golmore (talk) 07:02, 18 December 2020 (UTC)
Strong support GiorgioGaleotti 17:50, 19 December 2020 (UTC)
i, but they have the problem, that the readers' browser leaves the article.
Similar/identical proposal: Community Wishlist Survey 2021/Categories/Support multilingual category names czar 18:43, 11 December 2020 (UTC)
and a vertical version 
. Now it is very difficult to do this: you need to separately load another file with manual rotation.
Comment. The 
— Niklitov (talk) 01:58, 10 December 2020 (UTC)
Weak support only if it's an easy change to make — Rhododendrites talk \\ 14:22, 9 December 2020 (UTC)
Strong oppose per all of the above. Wikipedia is not some lousy site on the web. Firestar464 (talk) 05:48, 9 December 2020 (UTC)
_location_map_2013.svg){kind=link}
.jpg){kind=link}
