Jump to content

Community Wishlist Survey 2023/Multimedia and Commons

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2023
Multimedia and Commons
27 proposals, 312 contributors, 816 support votes
The survey has closed. Thanks for your participation :)



Enable a search by image in Commons

  • Problem: Sometimes, e.g. when you have a file in your computer but you don't know its original name, or even if it's a file from Commons, the search for it can be fatiguing, by trying to guess its title.
  • Proposed solution: Enable a basic search engine by image just as Google Lens, showing the thumbnails of the wanted image along with the bests matches, if it doesn't exist yet.
  • Who would benefit: Users who need to find the origin of their images, or have forgotten it.
  • More comments:
  • Phabricator tickets:
  • Proposer: De un millón (talk) 21:49, 4 February 2023 (UTC)[reply]

Discussion

  • Images on Commons are usually well crawled by image search engines (to the point that it can hinder your effort to find if an upload is copyvio), so I doubt there's much demand for this, which I imagine wouldn't be a small undertaking. Nardog (talk) 13:30, 6 February 2023 (UTC)[reply]
    I have a suggestion to this proposal. What about searching for metadata. Example: A photo has a bowling ball or it's related to bowling and it was taken in 2010. I search for: Bowling 2010. Goliv04053 (talk) 06:45, 11 February 2023 (UTC)[reply]
  • The Wikimedia API already can check for file presence by checksum. The Commons Android app uses that to show you what files you have uploaded already. Syced (talk) 08:38, 7 March 2023 (UTC)[reply]

Voting

Tool to copy images from archives to Commons with metadata

  • Problem: Many GLAM institutions make images available on their website which can be copies to Commons. These have to manually be download/uploaded one by one and metadata copied across.
  • Proposed solution: A way for Wikimedia Commons to take a URL and copy the image to Commons with descriptions and relevant metadata, including links back to the source.
  • Who would benefit: Everyone.
  • More comments: GLAM institutions like Libraries Tasmania / Tasmanian Archives have thousands of public domain images on their website (example). To add each one manually to Commons would take forever. A tool like this would help users of Wikimedia projects add more media, help GLAM institutions quickly share their own content, and make sharing images more accessible to new comers during training events.
  • Phabricator tickets: T193526
  • Proposer: Jimmyjrg (talk) 03:59, 24 January 2023 (UTC)[reply]

Discussion

  • It looks like the example above is using a catalogue product from SirsiDynix; I've not been able to find any API info. I think one aspect of this proposal is likely to be whether we can build a general-purpose tool that works with many libraries, or a single-purpose tool. For example, many archival catalogue systems support OAI-PMH, so if we built something that worked with that then it'd be perhaps more widely used. For site-specific scraping requests, there's a register of them at commons:Commons:Batch uploading. SWilson (WMF) (talk) 07:09, 24 January 2023 (UTC)[reply]
    Yes, I'd like something that adapts to the website/database that is being looked at. Some libraries use Spydus (example: Stonnington), which I think has a public API. Ideally it'd be best if there was some way to have it learn how a website works (the first time you visit you have to manually copy and paste all the information) but then it knows how to do it itself after.--Jimmyjrg (talk) 22:05, 24 January 2023 (UTC)[reply]
    @Jimmyjrg Double checking I understand the problem correctly: the proposal is to create a workaround for resources that are available online from institutions that do not have APIs or data dumps that can facilitate sharing data in bulk. Is that correct? __VPoundstone-WMF (talk) 16:55, 26 January 2023 (UTC)[reply]
    Yes @VPoundstone-WMF: That’s a good explanation. Basically I’d like something quicker than downloading and uploading everything myself (and copying/inputting metadata) when there’s a few images to move to Commons. Jimmyjrg (talk) 08:00, 27 January 2023 (UTC)[reply]
    Without commenting on the specific example above, in my experience, creating a generic tool to reliably scrape random websites with the sort of detail required for Commons is probably technically infeasible. c:Commons:Batch uploading exists for a reason. -FASTILY 22:33, 28 January 2023 (UTC)[reply]
  • I think, that there is one big problem. And that is, the source data have always different formats, so every time you have to change your program. And that's why there is a service on Commons, which helps with such mass transfers. Just now, I cannot find a link.Juandev (talk) 19:14, 9 February 2023 (UTC)[reply]
    I was inspired by the Web2Cit project which can learn to add citations using different formats. But you're right, it's likely more difficult for catalogues of images. Jimmyjrg (talk) 23:24, 21 February 2023 (UTC)[reply]
  • en:GLAM (cultural heritage), an acronym for galleries, libraries, archives, and museums, the cultural heritage institutions --Error (talk) 15:56, 13 February 2023 (UTC)[reply]

Voting

Allow category in EXIF data

  • Problem: Using "[[Category:Exif model: $1]]" as value for "MediaWiki:Exif-model-value". This currently adds the category to the file description page, but the file doesn't get categorized in the category. If the file description page already contains an identical category, the category is displayed twice.
  • Proposed solution: see phab:T23795#248878
  • Who would benefit: anyone
  • More comments:
  • Phabricator tickets: T23795
  • Proposer: Shizhao (talk) 02:41, 2 February 2023 (UTC)[reply]

Discussion

  • Would it be helpful to add operators to the search feature to search for images taken by specific cameras? Similar to how you can put filemime:image/png into the search bar? Because that is probably easier. Bawolff (talk) 05:52, 2 February 2023 (UTC)[reply]
    • @Bawolff: I think one of the benefits of the category approach is that photos can be added there even if they don't have the right EXIF data. That said, it does seem that what's wanted here is a way to search by camera, and probably the SDC captured with (P4082) property, combined with a bot that converts from EXIF to that, would be a good way to go. Then the info template could do the categorizing. Hacking system messages to do this doesn't feel all that solid. @Shizhao: Is the problem here, put more abstractly, that it's not possible to automatically categorize based on camera model? SWilson (WMF) (talk) 06:21, 6 February 2023 (UTC)[reply]
      If the native method is difficult to implement technically, using the bot method is also a temporary solution. Also, the mw:Manual:File metadata handling API seems to provide incomplete EXIF data? Shizhao (talk) 03:27, 8 February 2023 (UTC)[reply]
      @Shizhao: You're right, I was looking at this too broadly, sorry. There's definitely a bug in how the wikitext is being treated: it should either correctly add the category and not have it be duplicated, or not allow categories to be added there at all. SWilson (WMF) (talk) 04:04, 8 February 2023 (UTC)[reply]

Voting

Improve patrolling new uploads in Commons

  • Problem: Currently very few uploads in Commons get patrolled, Something along the lines between 4% to 10%.
  • Proposed solution: I made a tool that helps but I think we need something better, I don't have the capacity to maintain it long-term.
  • Who would benefit: Patrollers in Commons.
  • More comments:
  • Phabricator tickets:
  • Proposer: Amir (talk) 07:20, 29 January 2023 (UTC)[reply]

Discussion

Voting

Advanced sorting on Commons

  • Problem: We haven't any advanced sorting parameters on Commons.
  • Proposed solution: Adding sorting features on parameters like date, to Wikimedia Commons.
  • Who would benefit: Wikimedia Commons users
  • More comments: With advanced sorting parameters, we will be able to find images better and faster.
  • Phabricator tickets: phab:T329961
  • Proposer: Kurmanbek 💬 16:40, 2 February 2023 (UTC)[reply]

Discussion

Voting

Special media search to allow filters in a category

  • Problem: Some categories have many images that take a long time to sort through by eye.
  • Proposed solution: Being able to filter a category by image size, licence, etc.
  • Who would benefit: Those searching on Wikimedia Commons for images to use
  • More comments:
  • Phabricator tickets:
  • Proposer: JRennocks (talk) 22:46, 23 January 2023 (UTC)[reply]

Discussion

  • I'd like to note that this kind of filtering is already possible in commons:Special:MediaSearch. Adding something like "is in Category: ________" to that interface might already do the trick. (That probably should include a setting/slider for how many levels of subcategories to include.) Make it accessible from each category page with a link titled something like "search in this Category". Shouldn't be too hard to implement, I guess? --El Grafo (talk) 16:07, 26 January 2023 (UTC)[reply]
    Trick: click in a category on the tab "More" and then on "Search not in category". Now you get a search page. Remove the first part of the search string, including the "-" in -incategory:"Name_category". Now you are left with incategory:"Name_category" and you can edit your search the way you want to. JopkeB (talk) 10:05, 11 February 2023 (UTC)[reply]
  • Without this feature, a lot of users are trying to do this by creating additional layers of categorization that if fine for one perspective of filtering, but can make the categories a mess for everyone else. Hopefully, a good filtering tool will help reduce the urge to create a bunch of extra categorization. Ideally, if done well and integrating structured data, over time we can greatly simplify the category structure, but that would remain to be seen after this feature is implemented. In any case, I think this would be a very good tool to add. Joshbaumgartner (talk) 22:50, 10 February 2023 (UTC)[reply]
    I would like to piggyback this idea of an advanced search engine using structured data. I don't understand why we have structured data if we can't use them to make complex searches. Or am I missing a tool ? BotaFlo (talk) 19:20, 19 February 2023 (UTC)[reply]

Voting

Make Commonist work again

Discussion

So this proposal wants WMF to take over a random tool that isn’t being maintained? Why would they want to do that when many other alternatives exist?Aaron Liu (talk) 18:58, 23 January 2023 (UTC)[reply]

WMF came to the conclustion last year, they will develop stand alone upload tool. One year have past and I havent heard about any progess. Thats why its again on the table. And we can put it on the table again for other stand alone upload tools like Pattypan or Vicuna. --Juandev (talk) 21:13, 23 January 2023 (UTC)

Commonist isn't working because of WMF, them developing their own solution after breaking some of the major community developed upload tools, would to say the least not be very nice. Let's have them get back to basics instead. They could improve the APIs, the half baked structured data support, and allow for uploading large files. Such changes would make it much easier to maintain and support the many community built upload tools. --Abbe98 (talk) 20:25, 23 January 2023 (UTC)[reply]

What exactly is wrong with the current list of upload tools? With the exception of Commonist, they all work fine, if not better. -FASTILY 01:27, 24 January 2023 (UTC)[reply]
At least for Vicuna, it hasn't been smooth sailing either lately. For a while, nobody felt responsible for it and major bugs were not addressed. With a Rapid Grant, a couple of the most gaping holes have been plugged, but that's about it. Without proper maintenance, it will break again. PattyPan was patched up too after last year's proposal, but how long will it last? I don't see the point in trying to CPR Commonist back into existence. We don't need more poorly maintained community tools, we need one fully featured, cross-platform mass upload tool. And we need it to be maintained properly, long-term (i.e. not by an unpaid volunteer who may just disappear tomorrow). --El Grafo (talk) 13:58, 26 January 2023 (UTC)[reply]
Yeah, but all of the above-mentioned tools are currently working right? You're speculating that something will break. Upload tools are non-trivial to create/maintain, and imo if it's not broken, then it doesn't need fixing. Also shameless plug, I've created an upload tool: c:Commons:Sunflower. -FASTILY 22:15, 26 January 2023 (UTC)[reply]
This is not about devloping tool and leaving it. I think that if WMF will overtake commonist or create a new app, they will also continue to maintain it. But as I indicates above, the question is wheter it will happen. One year have passed and no sighn of it. Juandev (talk) 19:10, 9 February 2023 (UTC)[reply]

@Fastily actually Rillke's bigchunkedupload.js script is the only free (free, as in everyone can use it without having to install software first) tool that allows to upload files of more than 1.2GB (I use my own tool, but UploadWizard should be able to do that) --C.Suthorn (talk) 11:27, 25 January 2023 (UTC)[reply]

  • If the WMF decided to choose an "official" upload tool, Commonist doesn't seem like a good choice. It's written in Java, which makes it hard to install and has little expertise overlap with other WMF-maintained software (parts of the search system are in Java, but that's the only thing I think), the author seems to have rolled his own library for everything from JSON parsing to build tools, and in general, it would be hard to justify putting the efforts into a desktop app as opposed to something that just works via the web, when there's very little benefit of a local app for an upload workflow. Probably UploadWizard should just be improved instead. Also "maintain tool X forever" isn't really fit for the wishlist.
    If the goal were to just make the minimum effort to make Commonist work again, that would be a more sensible wish. I think that would just involve a simple change in API parameters (#25) and maybe some decoding fixes (#24). --Tgr (talk) 00:51, 1 February 2023 (UTC)[reply]
    Commons hat zwei Hauptzwecke: 1) Mediendateien bereitzustellen, so dass sie genutzt werden können. 2) Leuten, die diese Mediendateien hinzufügen wollen, dies zu ermöglichen. Punkt 1) funktioniert weitgehend und weitgehend zuverlässig. Punkt 2) funktioniert nicht so toll. Wenn jemand sich bereits mit MW auskennt und eine kleine Zahl von kleinen Bildern mit klarer Quelle und eindeutigem Copyright hochladen will, funktioniert das meistens (aber umständlich) mit dem Upload Wizard. Probleme beginnen dann, wenn eine große Anzahl von Medien oder sehr große Medien hochgeladen werden sollen. Für eine bedeutende Zahl von Usern, die bedeutend zu Commons beitragen, ist dabei Commonist das Tool der Wahl (für mich nicht). Natürlich ist eine bessere Alternative denkbar. Aber es gibt Commonist und wenn Commonist funktioniert, sind eine Reihe produktiver User zunächst mal zufriedengestellt. Warum laufen beliebte und teils ausgezeichnete Tools wie Commonist, CropTool, V2C, F2C entweder garnicht oder nur fehlerhaft? In erster Linie weil die Maintainer, die sehr viel Arbeit darin gesteckt haben diese Tools überhaupt erst zu erstellen, in einer Reihe von Fällen unnötig vergrault wurden. Und weil sich keine neuen Maintainer finden, die sich sowas ans Bein binden wollen. Eine Person hat mehr als 6 Millionen Dateien hochgeladen und wichtige Tools erstellt, wurde aber derart gedoxxt und bedroht, dass diese Person fluchtartig das Projekt verlassen hat. Es gibt viele Bekundungen, was für ein großer Verlust das doch ist, aber so weit ich sehe keinerlei Bemühungen das Doxxing abzustellen, Bedingungen herzustellen, dass die Person sich sicher fühlen kann oder bei der Person um Entschuldigung zu bitten. C.Suthorn (talk) 08:37, 1 February 2023 (UTC)[reply]

Voting

Fix CropTool

  • Problem: Lossless cropping of images using the CropTool does not work. Crop of TIFF, GIF, and PDF files does not work, and files with high resolution can only be rotated by 90, 180, or 270 degrees.
  • Proposed solution: Find a new maintainer for the CropTool.
  • Who would benefit: Everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: C.Suthorn (talk) 10:50, 30 January 2023 (UTC)[reply]

Discussion

Voting

Add status messages to assembling and publishing stages of upload process

  • Problem: Upload to Commons consists of the three stages uploading, assembling and publishing. During the assembling and publishing stages (that can take minutes each) the server does not send progress reports to the upload tool (like upload wizard)
  • Proposed solution: Server can be queried for progress reports (JSON) during assembling and publishing by the upload tool
  • Who would benefit: Users, Uploaders and developers who get better error reports for failed uploads.
  • More comments:
  • Phabricator tickets: T309094
  • Proposer: C.Suthorn (talk) 17:44, 28 January 2023 (UTC)[reply]

Discussion

This already exists, and can be retrieved via the API: mw:API:Upload#Additional notes. -FASTILY 22:37, 28 January 2023 (UTC)[reply]

No. What you are linking to are the results of a (failed) upload.
"getting EXIF from file"
"inserting XXX in database table 1"
"inserting XXX in database table 2"
"checking for malicous code in uploaded file"
"adding file to database"
"updateing file counter"
"writing EXIF to database"
"creating file desciption page"
"moving uploaded file to file system"
"updateing "patrolled" entry
or whatever "assembling" and "publishing" actually do, while you wait 5 minutes for your upload to appear, until it does not for some reason. C.Suthorn (talk) 00:41, 29 January 2023 (UTC)[reply]
You should spend some time to familiarize yourself with how chunked uploads work. "publishing" and "assembling" are meaningful statuses. A robust api client will be making use of this endpoint. -FASTILY 01:15, 29 January 2023 (UTC)[reply]
I Should not need to do this. The Upload process should work. It is not meaningful, of the upload is stuck for 5 minutes in "assembling" and if you poll for information you neither get a progress report like "7%, 23%, 51%" , nor an information what the sevrver is actually doing. Only ever "assembling", "assembling", "assembling". BTW: Have you tried in the lasst 6 month to upload a file of 600MB, 1.2GB or 4GiB with the Upload Wizard, Rillke'd tool and your own Upload tool? Did you succeed in the first try, second try, at all? C.Suthorn (talk) 12:23, 29 January 2023 (UTC)[reply]
  • This feels like a solution in search of a problem? Error reports need a unique identifier for the upload process that can be correlated with system logs (not sure if this exists but you should at least get a unique error ID which is close enough), not random status labels. --Tgr (talk) 00:43, 1 February 2023 (UTC)[reply]
    @Tgr have you uploaded af file of more than 1.2GB in the last 6 month? About "unique identifiers": In the past I have created phab tasks with the available identifiers from failed uploads, but either these are not helpful, or there is no interest to fix uploading to MW. C.Suthorn (talk) 08:19, 1 February 2023 (UTC)[reply]
    @C.Suthorn let me rephrase: this suggestion feels like the politician's syllogism to me. Commons large file upload is broken; here is a random feature that wouldn't make it any less broken; it is something so we must do it. There are all kinds of things that might help; I'm not convinced that trying to get the user interested in what specific technical steps are being taken in the background is one of those things. (A single end-to-end progress bar is nice, when the total timespan of the operation can be reasonably well estimated. For file uploads, that's probably not the case.) Tgr (talk) 20:19, 1 February 2023 (UTC)[reply]
    Wrt phab tasks, I think it's mostly the latter: it isn't anyone's job to deal with upload bugs, and it's both more complicated and arguably less productive than other kinds of technical improvements so few people spend time on it. Figuring out the immediate reason an upload failed is usually not hard (and often something mundane along the lines of "the file was too big and something timed out / ran out of memory"). Fixing uploads that ended up in some half-broken state does tend to be hard, but that would require an entirely different kind of logging. Tgr (talk) 20:24, 1 February 2023 (UTC)[reply]
    Ich hatte gefragt, ob Du in letzter Zeit mal eine sehr große Datei hochgeladen hast. Offensichtlich haben überhaupt nur 15 User in der Zeit von 2017 bis 2023 webm, ogv oder tif Dateien von 4,2GB bis 4.0GiB hochgeladen. Die Hälfte davon vor 2020 und teilweise per Server-Side-Upload. Seit 31. März 2022 haben nur @PantheraLeo1359531 und ich solche Dateien hochgeladen. Ich mit meinem eigennen Tool, PantheraLeo1359531 mit bigChunkedUpload (und das muss eine Qual gewesen sein, 10 Teile eines Videos hochzuladen, weil bigchunkedupload immer nur eine Datei hochlädt - wenn es denn klappt). Warum werden kaum solche Dateien hochgeladen? Weil es mit fast keinem Tool klappt (zuletzt auch nicht per ServerSideUpload, siehe @Urbanec). Ein Grund dürften TimeOuts, Deadlocks und Lifelocks sein. Diese treten aber immer wieder auch bei kleineren Dateien auf. Und wenn das passiert, gibt der User (häufig ein Neuling) gewöhnlich auf - und eine möglicherweise wichtige Datei ist für Commons auf immer verloren. Ja, es wäre nett, wenn es möglich wäre, dann einen Devloper zu rufen, der in die Logs schaut, das Problem findet, die Ursache erkennt und dann repariert - oder jedenfalls in phab dokumentiert, damit irgendein Developer es später tut. Leider sagt meine Erfahrung (die ich mit viel eigener Lebenszeit bezahlt habe), dass es so nicht funktioniert. Natürlich ist es den meisten Usern komplett Wurst, was schief geht und welche Fehlermeldungen angezeigt werden. Aber eben nicht allen. Und wenn dann eine Meldung aus der Assembling- oder Publishing-Stage mitgeteilt wird, dann gibt es jedenfalls einen Ansatz mit dem Developer arbeiten können -selbst noch wenn die Logs längst Geschichte sind. Profitieren werden davon alle, weil diese Fehler bei kleinen Dateien zwar viel seltener aber eben doch auftreten. C.Suthorn (talk) 22:02, 1 February 2023 (UTC)[reply]

The stages you mentioned above (Well the ones that actually exist, and it depends how loosely I interpret what you are saying) should already be reported by the API. e.g. you would get an error code of stashfailed, but the error info would be different depending on the cause. I suspect you never see them, because that is not where the upload is failing. Anyways, chunked upload is really fragile and could use lots of love. Bawolff (talk) 06:37, 2 February 2023 (UTC)[reply]

There are three stages (of four, if you count "queueing" as stage): "uploading", "assembling" and "publishing". While "uploading" you can poll for information and get the number of bytes already uploaded. If you poll while "assembling" or "publishing" you only get "assembling" or "polling" as answer. After "assembling" has finished you get the metadata. If the upload fails for a valid reason "user has no right", "database is down", then you get this reason and that is fine. But if the upload fails even though it should have succeeded (and it actually will succeed, if you try once more (with luck) or thousend times more (with less luck) ) you don't get any status at all. You say chunked upload is really fragile. I don't think so. I think it actually is very stable, but it fails under specific circumstances. As i have written before: Upload Wizard will succeed with files of upto 600MB, it may succeed with 600MB to 1.2GB, and it will always fail with 1.2GB+ . Rillke's tool (and my own tool) will (at the moment) upload 4.0GiB in most cases with the first try (because chunked upload is actually stable). However both in Rillke's tool and in my tool you can see that "assembling" and "publishing" both takes minutes and while you are waiting you only get the status "still assembling"/"still publishing" until it either fails without any status message or it succeeds with either a published file or an error like (filename not allowed, already uploaded, user has not right, ...).
And I repeat: Upload a file of 4GiB (or at least more than 1.2GB) and see what happens. It will succeed with Rillke's tool and with mine, but fail with every other tool without any information why it failed.
And then: Why do I actually discuss this: My own uploads work, and what do I care, if the uploads of other users fail? C.Suthorn (talk) 09:52, 2 February 2023 (UTC)[reply]
I agree with the points that C.Suthorn made up. The upload process of larger files sometimes fails. For example, I upload some public domain textures that are sometimes larger (above 1 GiB) with recurring errors (server didn't respond within a timespan, ...). This sometimes needs much time. And the point is that some files (especially videos and more detailed meshes) will have file sizes above 1 GiB more often in the near future, as recording systems get more capable (especially videos in 4K longer than 5-10 minutes). And it is sad that it is sometimes buggy, which leads some users to give up. I think it is very important to support uploads of larger files (for example as suggested), and also higher file size limits, to be prepared for the future. --PantheraLeo1359531 (talk) 15:23, 2 February 2023 (UTC)[reply]
Addendum: While uploading the FAILED: stashfailed: Could not connect to storage backend "local-swift-codfw". error occurs --PantheraLeo1359531 (talk) 15:43, 2 February 2023 (UTC)[reply]

Voting

Make Special:Search on Commons show all requested thumbnails

  • Problem: Special Search on Commons does not show all thumbs (example).
  • Proposed solution: Make it show all due thumbs after 1 user request, for example build in an automatic ctrl+F5 page refresh till all are loaded ... but better: clean up the code that prevents pages to load fully in one go. Make PDF-search optional by default. Investigate endless loops.
  • Who would benefit: Categorizers of large collections of images
  • More comments: Thumb display changes and loading issues were already discussed in 2022 here, but the issue of never loading of all of the thumbs in large searches (100-500 items) was never solved yet.
  • Phabricator tickets: T266155
  • Proposer: Peli (talk) 18:54, 23 January 2023 (UTC)[reply]

Discussion

Thank you. Peli (talk) 13:44, 20 February 2023 (UTC)[reply]

Voting

Provide example code for adding depict statements with a command line script

Discussion

Did some digging, and the page we'll probably want to improve is mw:Wikibase/API. It appears that pywikibot is also capable of adding structured data: phab:T213904, phab:T223796, release notes, proof of concept -FASTILY 22:48, 28 January 2023 (UTC)[reply]

Example for python3: commons:User:SchlurcherBot/commonsapiaddclaimsoauth (please read the wikitext, the page does not render well). Let me know if you need another working example. --Schlurcher (talk) 18:07, 29 January 2023 (UTC)[reply]
After a quick look: It adds copyright and license. But I am after an expample for getting the ID for a category and then adding the depict statement. For license and copyright the P-number are known and do not change, so they can be hard coded in the script. C.Suthorn (talk) 00:10, 30 January 2023 (UTC)[reply]
What does the ID for a category exactly mean? --Matěj Suchánek (talk) 16:52, 30 January 2023 (UTC)[reply]
Upload a picture of a blue-red stripped cat that is hunting an Uber car. While uploading you assign "Category:Images of blue-red cats hunting Uber cars". As uploader you have the knowledge, what depicts are useful. You can derive it (programmatically supported) from the category. A script would be able to fetch the Q-numbers and add the depicts to the image. Adding statements, if the Q-numbers are already known. C.Suthorn (talk) 22:50, 30 January 2023 (UTC)[reply]
Is there actually a way to do that? I.e., is the relation between the category and suitable entity IDs for depicts stored somewhere? Because I believe that's the key, and I believe there is not at the moment. Maybe bringing this up to c:Commons talk:Structured data can make it clear. By coincidence, a similar topic is being discussed there right now: c:Commons talk:Structured data#Using categories as a proxy for P180 depicts values. --Matěj Suchánek (talk) 09:13, 31 January 2023 (UTC)[reply]

@C.Suthorn: Could you elaborate a bit more on the requirements? I could provide an compliled "command line tool that adds depict statements" in case the above code would not work. The call would look like this:

APISchlurcherBot.exe "Username" "Password" "M66593822" "Q68"

This code would perform this edit: [1] Questions:

  • Windows or Linux (the code I have is Windows)
  • Is password provided in command line ok (only ok for non-shared PCs, but easier)
  • Is M id ok, or title of page better (M id easier, but conversion can be done as well)

If that fulfills the need, I can share an executable for this task. If more complex is envisioned, then not. --Schlurcher (talk) 10:46, 4 February 2023 (UTC)[reply]

While I could integrate such a tool (on Linux, and User,Passsword is no problem), I think, it would be better not to have a complete working software, but example code (which could be in a pseudo language, or basically any language like php, java, perl, python, c, whatever - as this is not about high performance operations like computing raytracing images, or implementing social scoring algorihms) for these basic tasks:
1 computing Q, M, and P numbers from a text string (like page name to Q number, ...)
2 setting an SDC value for a file
3 testing for values already set
From such examples other people with other tools could profit too C.Suthorn (talk) 12:47, 4 February 2023 (UTC)[reply]

Voting

Native SVG support

  • Problem: SVG files are currently rendered out as PNG files on pages that use the image.
  • Proposed solution: Embed the SVG into the page output, only using PNG as a fallback on devices that don't support SVG.
  • Who would benefit: Readers on various devices when zooming in on the image within an article.
  • More comments: Currently SVG files are rendered out in a fixed resolution PNG file which, when scaled, suffers from the usual issues when zooming into a raster image. Embedded SVG (allowing clients/web browsers to render the images instead) would allow these images to be scaled infinitely with the only restriction being the client/browser.
  • Phabricator tickets: T5593 (see related tickets)
  • Proposer: —Locke Cole • t • c 18:59, 23 January 2023 (UTC)[reply]

Discussion

  • I wonder how worthwhile it would be to give users the option to forcibly use the PNG fallback for individual images if performance improvements are necessary, such as [[File:Example.svg|forcepng]]. -BRAINULATOR9 (TALK) 19:52, 23 January 2023 (UTC)[reply]
    We can't rely on that. If someone adds a 28MB SVG to the frontpage... there has to be some sort of technical protection against that. Also we have the problem with fonts not being consistent across browsers, so for that you also need some sort of processing before you can have files included (these are details which are already mentioned in the relevant tickets). —TheDJ (talk • contribs) 19:54, 23 January 2023 (UTC)[reply]
    Just a clarification. I think this wish is very much doable. But it's going to be a little bit more involved than 'just switch to the original svg'. Will easily take a few weeks of work. —TheDJ (talk • contribs) 23:48, 26 January 2023 (UTC)[reply]
    Huh? I'm talking about, if this proposal is implemented and SVGs default to being rendered as SVGs, then the option should exist to use the PNG format as a fallback. -BRAINULATOR9 (TALK) 18:16, 16 February 2023 (UTC)[reply]
    @Brainulator9: I understand what you're asking for, but is there a reason someone concerned about that couldn't just simply upload a PNG rendering of the SVG for such a use-case? I think @TheDJ and I are thinking of technical restrictions to (as TheDJ suggested) limit gigantic SVG files from being sent as-is. But if there's some edge-case where a PNG is desired, simply uploading a PNG and then the SVG source for future editors to make changes to as-needed would suffice, no? —Locke Cole • t • c 18:41, 16 February 2023 (UTC)[reply]
    That could work, as long as the end users remember to update the PNG fallback alongside the SVG original. -BRAINULATOR9 (TALK) 02:01, 17 February 2023 (UTC)[reply]
    I definitely think there should be a cutoff for how large of an SVG we'd want sent to clients. For all SVG < 32KB *or* where the SVG is smaller than a PNG, I'd presume we just send the SVG. For situations where the SVG is larger than 32KB AND the PNG is smaller, then it might make sense to send the PNG still. 32KB is a purely arbitrary number, I'd hope we'd look at the existing average sizes of SVG files throughout the projects and do some data crunching to come up with a number that makes sense. —Locke Cole • t • c 19:59, 23 January 2023 (UTC)[reply]
  • There's a script I used to test how native SVGs would work on Wikipedia... and they worked okay unless they were detailed geo maps with many tiny polygons, in which case large parts of the wikipage would stop rendering, text and pics. This is the code for your common.js: //mw.loader.load( '/w/index.php?title=User:Opencooper/svgReplace.js&action=raw&ctype=text/javascript' ); ponor (talk) 21:27, 23 January 2023 (UTC)[reply]
  • Why can't Wikipedia clean up svg pictures before uploading them to the server? There are resources with an open license such as SVGo. This will ensure the safety of this format of images. It is also possible to make a limit on the size of uploaded svg for example in 56Kb (talk) 12:07, 26 January 2023 (UTC)[reply]
    Limit the size of the SVG is not a good idea. Or at least if limited, should be some reasonable big number (at least 25-30 MB). I have some maps in svg that require details and easily go over 10-15 MB. Ikonact (talk) 08:33, 27 January 2023 (UTC)[reply]
  • It's will be awesome, because SVG is can contain not only vector graphics, but also animated and also interactive graphics. Although, it was a security and peroformace issuie if WP will embed every SVG image. Maybe, we need special tag or something for svg-images, that checked for issues to decide, embed this image into page or make png thumbnail.--Tucvbif (talk) 15:38, 11 February 2023 (UTC)[reply]
    I understood embedding SVGs to mean "using the original SVG wherever PNG thumbnails are currently being used". That being said, there's no risk of interactive graphics screwing with the page, as an SVG's code needs to be embedded directly into the page in order to respond to user activity. Moreover, this feature wouldn't introduce new security issues, as WP already blocks SVG uploads that contain scripts and other "problematic" content. Alhadis (talk)

Voting

Update Vega to the latest build

  • Problem: MediaWiki currently uses an older version of the Graph rendering library Vega (our build released seven years ago) that has issues with accessibility, syntax, functionality, and security. To work with it, you have to resurrect outdated manuals - this, in turn, prevents users from creating cool new graphics.
  • Proposed solution: Update Vega to the latest build
  • Who would benefit: Readers and Editors
  • More comments: Related previous wishes: 2022, 2021, 2019.
  • Phabricator tickets: T165118
  • Proposer: Iniquity (talk) 19:32, 25 January 2023 (UTC)[reply]

Discussion

Voting

  • Problem: If you want to know, which pages / items link to a specific page, you can click on "What links here" in the left column under Tools, example. But you can't see the number of items which links until you click on "500 search results per page" or sometimes you need "5000" to see the line: "Displayed 1,846 items."
  • Proposed solution: Add this line (how many items) everytime and independently of an enough big number of search results per page.
  • Who would benefit: probably every editor
  • More comments: Thank you!
  • Phabricator tickets: T6394
  • Proposer: W like wiki (talk) 04:28, 5 February 2023 (UTC)[reply]

Discussion

Voting

Ease the creation of diagrams

  • Problem: Create a diagram in Wikipedia is tedious. You have to basically create an SVG file. It makes updates on the diagrams difficult. SVG code is quite verbose.
  • Proposed solution: Use a high-level language for describing diagrams. For instance PGF/TikZ which is the somehow main stream solution for making figures/diagrams in a LaTEX document.
  • Who would benefit: Any contributor that wants to create/update a diagram/picture for a Wikipedia article.
  • More comments: Supporting PGF/TikZ language would be in some sense in the same spirit that the already existing support of Lilypond language (for music notation). The benefit of PGF/TikZ over other diagram languages is that it also offers support for LaTEX formulas directly. Of course, we should discuss the choice of the supported language. We could also offer the possibility to describe a diagram in many languages (PGF/TikZ, graphviz, etc.). In case this wish is selected, I would be glad to participate to development.
  • Phabricator tickets:
  • Proposer: Fschwarzentruber (talk) 18:37, 5 February 2023 (UTC)[reply]

Discussion

Voting