Oh, then I don't think we can do much more. I'll close this but if we find some file that is differently encoded, perhaps we can try again (but I haven't seen any that would be a better candidate).

@Krinkle The updates to the gadget are great, for future use. However it doesn't solve the problem of users on external sites using this gadget to embed images on their sites which now have broken links as described under What should have happened instead?:. (Last weekend I found two examples of the same problem on my own site with images as recent as from Wikimania 2024.)

So far I have added a license lookup and link to the back to the data provider source so that it can be investigated if it looks suspect.

FYI, just a few hours ago svwiki added a gadget doing this, perhaps it could be resued or inspiration. The gadget is: https://sv.wikipedia.org/wiki/MediaWiki:Gadget-sensitiveViewer.js and uses a json file where the community can list the images they want to blur.

Sorted by count is what I would expect.

Practically, I think we would never need more than 1 or 2 even.

In T415752#11582765, @Sebastian_Berlin-WMSE wrote:

No I'm encountering another error. Some of the files, like File:Hall in Tirol, Haus Rosengasse 9.JPG, have copyright status = copyrighted, dedicated to the public domain by copyright holder. Should these also have https://creativecommons.org/publicdomain/mark/1.0/ as rights statement? I only check for public domain. If so, are there other items that should result in the same rights statement?

There were 38 licenses missing P856, which I just added: https://www.wikidata.org/w/index.php?title=Special%3AContributions&target=Ainali&namespace=all&tagfilter=&start=2026-02-04&end=2026-02-04&limit=38

In T415752#11582030, @Sebastian_Berlin-WMSE wrote:

In T415752#11581091, @Ainali wrote:

Is there a way to easily check the list of allowed license against Wikidata and see if there are others that are missing URLs? It would be helpful to fix those pre-emptively.

I am guessing that the four first are licenses that CommonsDB do accept, but that the Wikidata statements are missing or not formatted exactly like what CommonsDB wants as values. I think I fixed the first one (Hungary). The next three are likely failing because they have the deed.en in the end of the URL. I am not sure if that should be fixed in Wikidata, or if we could just disregard it when present. The last one, though, is definitely not in the accepted CommonsDB licenses.

Ok! I added structured data to the pdf and ogv files and changed te webp and mp3 files so that these four now also should be possible to declare: https://se.wikimedia.org/wiki/Special:Diff/131623

Thanks @Zache for linking to the project. Our meta page is perhaps more detailed in regards to what Wikimedia Sverige is working on. See https://meta.wikimedia.org/wiki/CommonsDB

I don't think we ever should use the license on the Wikidata item as that may not match the license of the file (even though it should most of the cases)..
This because even if a a work is in the public domain (so that it is marked on the Wikidata item), individual images depicting it may have other licenses.
Sometimes rightly so, if it includes enough of an original frame that is still not in the public domain, and sometimes that's what the source claims (copy fraud or not), like this one where Commons says CC BY 2.0 even though the work should be PD.
Since it is already unclear what we sign with our certification, I definitely think we should play it safe and stick with "this is what it says on the file page on Commons".

It's not only possible, it is very common.

The discussion has been stalled for 4 years, so I find it unlikely that they will come to a conclusion before this project ends. Which means that we will have no PD images from us in the CommonsDB.

Almost no images that are in the Public Domain have SDC. That's why I had to resort to use Petscan to find images through their license template. So you don't really need to look at the wikitext for these images, we know from the selection that they are PD100.

I have been running into this a couple of more times now, it's really frustrating and difficult to work around when it feels like it should just work.

It's apparently a bug in the Commons SPARQL data, see for example this: https://w.wiki/Egiu that shows multiple schema:contentSize, schema:contentUrl and schema:url for the same entity.

I am curious what failed in the download though, because downloading a file should be possible regardless of the file format, right?

Yes, I have updated the two Petscan queries to only get jpg files now.

In T398696#10984615, @Sebastian_Berlin-WMSE wrote:

At least some of the duplicates come from T396124: Make 1,000 declarations. I had a look at the qurey for those and it looks like that also is for CC-BY-SA. @Ainali, can you double check this? On the wiki page it says "Exempel-query på 1 000 bilder med CC0 licens: https://w.wiki/EEgJ".

Do we know anyhing about why they caused errors? Just looking at the first file: https://commons.wikimedia.org/wiki/File:Himantoglossum_hircinum,_Sorges_(Dordogne,_Fr).jpg it looks just like a normal image that should work.

When I am searching for something, and not clicking any of the suggestions but the search button instead, I end up on the main page rather than on the search results. See screenrecording.

In T393861#10834010, @Sebastian_Berlin-WMSE wrote:

I think that depends on what we want to test. While we probably don't need all images to be big at least some of them should be so we now we can support them.

I'm also guessing that as part of some report we want to say something about performance. If so the images should to some extent represent what's on Commons.

If it helps to keep the size down, we can query for smaller images. For example, this query gives us 100,000 CC0 images smaller than 1MB: https://w.wiki/EAa9

For our own memory, due to the deadline, we decided to only use images with license information in SDC. Complex cases with more variation in the public domain rationale will be dealt with later.

Or even simpler call: https://commons.wikimedia.org/w/api.php?action=query&format=json&prop=imageinfo&titles=File%3AJohannes%20Vermeer%20-%20Het%20melkmeisje%20-%20Google%20Art%20Project.jpg&formatversion=2&iiprop=extmetadata&iiextmetadatafilter=LicenseShortName%7CUsageTerms

Yeah, grabbing it from Wikitext is too challenging. But even for images without SDC, it may be retrievable in a structured form through the API, like this for example: https://commons.wikimedia.org/w/api.php?action=query&format=json&prop=imageinfo&titles=File%3AJohannes%20Vermeer%20-%20Het%20melkmeisje%20-%20Google%20Art%20Project.jpg&formatversion=2&iiprop=timestamp%7Cuser%7Cextmetadata

The list is ready!

Another use case, I would like to do two different types of charts of data that logically makes sense to keep in the same Data file (one of the lines in the first chart is the sum of all lines in the second one).
Now, to achieve this, I had two make two different Data files.

This might be a duplicate of T383446 (I didn't see that one before creating this feature request).

On this file, it still overlaps in Swedish: https://commons.wikimedia.org/wiki/Data:Swedish_aid.chart?uselang=sv

In T383109#10449769, @CCiufo-WMF wrote:

Thanks for reporting this. I agree the rounded values in this scenario are not particularly useful (actually, they are misleading). Maybe this is just a tweak we need to make for Swedish?

In T382806#10426718, @TheDJ wrote:

Additionally, it would be cool if the charts definition file on Commons in turn would feature an edit button to directly take you to the tabular series data.

In T246901#10362412, @donmccurdy wrote:

... for artists and contributors trying to upload 3D models? And if so... what would be the best place to share that?

Here is a good use case: This weather data for New York has so many columns, that the chart gets very busy. The possibility to select just temperatures would be nice.

@Danny_Benjafield_WMDE Not really, here's a screenshot from just now in my watchlist on svwiki.

Great that it is being done!
(This task could have been made a subtask as it is quite specific and not mentioned explicitly in the task you are referring to. But perhaps the huge table disappears completely?)

Sure! Here are a few from my watchlist on Swedish Wikipedia. (Unrelated weirdness, why is the Wikidata edit summary not in English when I set the rest of my interface to that?)

Has this already been deployed? The project added by ReleaseTaggerBot, the roadmap and the Tech News suggests so, but my watchlist is still full of irrelevant changes.

Just a note that the need for this was mentioned in at least two sessions on Wikimania. In one, an editor from enwiki noted that usage of the new Charts extension might not be received well unless it also will be possible to pull in a reference along with the chart. The question. This could be enabled through SDC on the data namespace. Ping @CCiufo-WMF

Note that it needs flexibility, as in some cases, one would like to be able to link to a specific form. For example Sv-anden (wild duck).ogg should link to L251549#F2

Seems to just work now, unclear if anything got fixed or if it was just a temporary glitch.

A thought I had when talking to Alex at Wikimania: It would probably be useful if these lists had Wikidata items, and that the inclusion of the topics were made through the Wikidata property "on focus list for WikiProject (P5008)". It fits really well, as this is a focus list by definition. It would also enable other ways to use the knowledge that this is a prioritized topic.

Fixed! Now available at https://shuffle.toolforge.org/

I'll keep this open and assigned to me as I intend to finish this on the upcoming minihackathon in the Netherlands.

@Jdlrobson If it was fixed in Vector 2022, then it has regressed because I find the language links in the bottom again on the main pages of enwiki, svwiki and frwiki when using it. Screenshot from enwiki.

Oddly enough, the query below uses DISTINCT and VALUES but correctly returns 4 results. So there might also be a connection to wdt:.

Related, right now when opening a map without lat/lon/zoom in VE, it adds it, possibly ruining the map.

In T166094#8310375, @TheDJ wrote:

I have some other points that should be taken into consideration

2. Review... In much the same way as default content from wikidata was a problem for en.wp, I suspect that default content for alt tags from Commons might be a problem for that community. It would be the first text content from Commons that by default becomes part of wp articles, sourced by search engines etc. There is a vandalism angle possible there, and they may argue that Commons' review processes are not setup to detect that, so that might become a conflict point.
3. Per the law of levels of investment required to get something useful... This is likely only to benefit en.wp in any sort of substantial level. Other languages will stil mostly be left out.
4. It could be a distinguishing feature to have multi lingual alt text of very popular media items.

In T166094#8307437, @Pigsonthewing wrote:

In T166094#8202790, @El_Grafo wrote:

1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.

If the image is used on the article about the species of fungus, would that be good alt text? No.

In T188291#8278395, @Spinster wrote:

I would also like to include links to Wikipedia articles but am stuck.

In T264751#8276999, @valerio.bozzolan wrote:

I suggest to remove the Commons Tag and set a generic Cloud-Services and rename this Task to:

In T305121#8008184, @TheDJ wrote:

Apparently this is still broken ?

For legibility, I would prefer single quotes rather than escaping, but if there are some queries where single or double quotes matter (I wasn't ware it could be), then escaping is of course a better solution.

Yes, for example this one that relies on a query which uses several ' : https://sv.wikipedia.org/wiki/Mall:Maplink/Lista_%C3%B6ver_kommun-_och_regionstyren_i_Sverige

I was trying again, and it seems to actually only load twice. But on the other hand, there is a lot of scrolling to even get it to load the first reload, so it seemed infinite. In fact, my screenshot app reached maximum image limit before even hitting the first reload (screenshot attached). I suggest that to change the behavior to reload automatically.

An alternative would be to crop the images so that they can't be recognized. I don't think the important part is seeing them in use, but just getting an understanding of how the clothing look like to inspire others.

Yes, I can confirm that this somehow has been resolved. Not only in the small example in the description, but also this larger map finds all municipalities: https://sv.wikipedia.org/wiki/Lista_%C3%B6ver_kommun-_och_regionstyren_i_Sverige_2018%E2%80%932022#/map/0