Commons:Village pump/Technical/Archive/2025/05

Category:Commons talk archives#Village%20pump/Technical/Archive/2025

Fix Template:Wikiekspedycja 2013

Using the template in a file description is broken. Example: File:Szymonki Ruiny klasztoru 10.JPG. Who can fix this? тнояsтеn ⇔ 18:57, 31 May 2025 (UTC)

тнояsтеn, The issue was not with the template but with broken syntax in the file: see here. --Jarekt (talk) 02:23, 2 June 2025 (UTC)
Thank you, Jarekt. But there are hundreds more, I tried to list all with this search string. Can this somehow be solved by a script or bot on all those pages? --тнояsтеn ⇔ 15:31, 2 June 2025 (UTC)
I used VFC to fix the template syntax for all the images in the search query above. So the problem should now be fixed. Tvpuppy (talk) 20:13, 2 June 2025 (UTC)
Thank you very much! --тнояsтеn ⇔ 20:19, 2 June 2025 (UTC)
This section was archived on a request by: тнояsтеn ⇔ 20:19, 2 June 2025 (UTC)

Tech News: 2025-19

MediaWiki message delivery 00:11, 6 May 2025 (UTC)

We will be enabling the new Charts extension on your wiki soon!

(Apologies for posting in English)

Hi all! We have good news to share regarding the ongoing problem with graphs and charts affecting all wikis that use them.

As you probably know, the old Graph extension was disabled in 2023 due to security reasons. We’ve worked in these two years to find a solution that could replace the old extension, and provide a safer and better solution to users who wanted to showcase graphs and charts in their articles. We therefore developed the Charts extension, which will be replacing the old Graph extension and potentially also the EasyTimeline extension.

After successfully deploying the extension on Italian, Swedish, and Hebrew Wikipedia, as well as on MediaWiki.org, as part of a pilot phase, we are now happy to announce that we are moving forward with the next phase of deployment, which will also include your wiki.

The deployment will happen in batches, and will start from May 6. Please, consult our page on MediaWiki.org to discover when the new Charts extension will be deployed on your wiki. You can also consult the documentation about the extension on MediaWiki.org.

If you have questions, need clarifications, or just want to express your opinion about it, please refer to the project’s talk page on Mediawiki.org, or ping me directly under this thread. If you encounter issues using Charts once it gets enabled on your wiki, please report it on the talk page or at Phabricator.

Thank you in advance! -- User:Sannita (WMF) (talk) 15:07, 6 May 2025 (UTC)

That’s good news. -- Tuválkin ✉ ✇ 23:30, 10 May 2025 (UTC)

Tech News: 2025-20

MediaWiki message delivery 22:34, 12 May 2025 (UTC)

Upload of extremely large image

There's a 108 gigapixel scan of Girl with a Pearl Earring available here. The image is far too large for me to even think of scraping myself. It will probably need to be split into sub-5GB chunks, but is definitely within scope. An example tile URL is https://www.micro-pano.com/GWPE90x/panos/GWPE90x-NEW-2.tiles/l09/185/l09_185_177.jpg. Does someone have the means to take a stab at this? JayCubby (talk) 02:09, 9 May 2025 (UTC)

I should be able to, unless someone else gets to it first I guess ;) --Zhuyifei1999 (talk) 04:17, 9 May 2025 (UTC)
Thank you very much! JayCubby (talk) 04:19, 9 May 2025 (UTC)
Np. This will take many hours just to download.... --Zhuyifei1999 (talk) 07:24, 9 May 2025 (UTC)
Words cannot describe how massive this is. I finally have it downloaded and it's like 50 gigabytes. --Zhuyifei1999 (talk) 07:00, 10 May 2025 (UTC)
Cute, I sometimes have terabyte-datasets to down- and reupload ;D (and 100 gigs upload per day) --PantheraLeo1359531 😺 (talk) 15:05, 13 May 2025 (UTC)
I was tempted to ping you when starting this thread. Given your self-rendered 10-gigapixel fractal uploads, you presumably have quite a bit of computing power at your disposal.
I ran a Quarry query, you've uploaded 23 TB of media! JayCubby (talk) 15:35, 13 May 2025 (UTC)
Yes, a 32-Core processor :), but the but the fractals are only a very small part ;). The main things are orthophotos and other useful large free media across the world. Fӕ uploaded 90 TB or so in comparison --PantheraLeo1359531 😺 (talk) 19:56, 14 May 2025 (UTC)

@JayCubby: Top left corner, PTAL: File:Girl with a Pearl Earring - Hirox-x0-y0.jpg It will take another many more hours for me to stitch the remaining 131 tiles. --Zhuyifei1999 (talk) 13:57, 10 May 2025 (UTC)

@Zhuyifei1999 thank you very much for this! I think this will have set the record (by quite a lot) for the highest-resolution image on Commons. JayCubby (talk) 18:48, 10 May 2025 (UTC)
Yeah, I'm not aware of anything that has a larger resolution lol. --Zhuyifei1999 (talk) 19:46, 10 May 2025 (UTC)

@JayCubby: This is done. All the tiles, plus a scaled down version, are visible at Template:Tile set/Girl with a Pearl Earring - Hirox/grid. @Yann: Wanna get an FP for this? ;) --Zhuyifei1999 (talk) 21:27, 11 May 2025 (UTC)

@Zhuyifei1999, done, at Commons:Featured picture candidates/removal/File:1665 Girl with a Pearl Earring.jpg. JayCubby (talk) 22:39, 11 May 2025 (UTC)
@Zhuyifei1999: Thanks a lot for doing this, but I think the current FP is OK. There are probably other paintings with such a huge resolution, but I don't know how to get them. Yann (talk) 14:19, 12 May 2025 (UTC)

Is it just me, or has the Special pages link disappeared from the left margin? -- Auntof6 (talk) 05:21, 16 May 2025 (UTC)

See phab:T385346 and phab:T388927.
You can follow mw:Tech news to make sure you avoid disruptions in future. Jdlrobson (talk) 19:41, 16 May 2025 (UTC)

I uploaded two PDFs some time ago (Pietro Budmani - Grammatica della lingua serbo-croata (illirica).pdf and Maretić, Tomo - Istorija hrvatskoga pravopisa latinskijem slovima.pdf), and in the meantime I've noticed they lack thumbnails and don't show up when searching. I fixed the former with ?action=purge as recommended on Help:Purge, but they were still absent from search results. E.g. searching for "Budmani" gives no results when clicking "Other Media", it's declared to be an "Invalid search".

Finally, I changed my search interface from MediaSearch to Search, and now it does show the files! And just to check once more, I switched back to MediaSearch, and now that engine says "Could not normalize image parameters for Historiadaprouin00ganduoft.pdf." Huh? Should I fix my files somehow or does the problem lie in MediaSearch?

— Phazd (talk) 00:58, 17 May 2025 (UTC)

@Phazd I think the problem was caused by File:Historiadaprouin00ganduoft.pdf, I purged it just now since its thumbnail was also not showing, and now searching “Budmani” with MediaSearch works. Tvpuppy (talk) 03:05, 17 May 2025 (UTC)
@Tvpuppy Man, what a mess, so apparently one file broke the searchability of the other one... Thank you for fixing it. But the other book (Istorija pravopisa) still doesn't show up for me with MediaSearch. And I can't get it to produce the sort of error message that I managed to get for "Budmani". — Phazd (talk) 04:22, 17 May 2025 (UTC)

Weirdness with "other resolutions"

I feel like I'm probably missing some important detail or an existing discussion, but: when I'm looking at File:Ianto’s Shrine - geograph.org.uk - 7636568.jpg, it says "Size of this preview: 800 × 600 pixels", but the link actually goes to an image that is 960x720px. The 320x240px link is closer to the advertised size but not exact (330x247px), the 640x480px link is the 960x720px image again, and the other links are all working normally and as expected. Clearly something is wrong with the link labels, and especially with the 640x480px link (which is really annoying for me, since I was relying on a 640px image being available for something I'm working on). Suntooooth (talk) 08:38, 18 May 2025 (UTC)

This is definitely an error. I mentioned it here phab:T266155. For your need a specific size you can just request them directly. https://commons.wikimedia.org/wiki/Special:FilePath/FILENAME?width=WIDTH GPSLeo (talk) 11:23, 18 May 2025 (UTC)
Thank you :] Suntooooth (talk) 18:41, 18 May 2025 (UTC)
Hm, actually - using that link with 640 as the width just links to the 960px one again, which is weird considering a 640px version definitely exists (I got that by manually changing the value in the URL). Suntooooth (talk) 18:44, 18 May 2025 (UTC)

Strange bug in WC-render

The image size is 165px (file AX5E1-2D.svg)
The image size is 166px (the same file AX5E1-2D.svg)

If the image size this file is specified as less than 166px, the patterns will no longer be displayed. How to solve this problem? Д.Ильин (talk) 09:17, 19 May 2025 (UTC).

Phab:T20463?
Reordering pattern elements to avoid forward references may be a work around. 
<defs>
  <pattern id="c" xlink:href="#a" patternTransform="matrix(2.05 .564 .0475-.17 81 85)"/>
  <pattern id="a" xlink:href="#d" patternTransform="matrix(-2.05 .564-.0475-.17 123 85)"/>
  <pattern id="d" width="3" height="1" patternUnits="userSpaceOnUse">
    <rect width="1" height="2"/>
  </pattern>
</defs>
Glrx (talk) 15:34, 19 May 2025 (UTC)
Reordered, but now the break is 348px / 349px.
Some notes. The pattern element is at issue here and a topic above.
patternTransform is replaced rather than composed.
https://svgwg.org/svg2-draft/pservers.html#PatternElement
matrix(a b c d e f) →
Scale OK. Rotate OK. Why anisotropic?
ratio 3.6347517730496 3.5789473684211
angle 15.382760067591° 15.611001719729°
lengths 2.1261693253361 0.17651133108104
Glrx (talk) 14:09, 20 May 2025 (UTC)
Say pattern is clipped to paint 1 px × 1 px.
Pattern transform makes that 2.05 px × .17 px.
SVG scale is 165 / 205 = 0.80487804878049.
One pattern pixel is 0.22576829268293 of a PNG pixel.
Glrx (talk) 20:32, 20 May 2025 (UTC)
Touch. Glrx (talk) 04:24, 8 June 2025 (UTC)

Tech News: 2025-21

MediaWiki message delivery 23:09, 19 May 2025 (UTC)

API for accessing Data: namespace or other .json files

Is there a special API or other way to get a raw data table from outside of MediaWiki? Chemistry articles on enwiki (and maybe others) link to an external program to display a graphical representation of chemicals, but the data-set that program uses is limited and not always containing the details that *wiki want. That program can load external data, so I was hoping we could have the data on commons, as we do for map-data and similar back-ends. JSON, CSV, even raw wiki-source would be fine. DMacks (talk) 01:31, 6 May 2025 (UTC)

You can make a request like and then parse the output as json. GPSLeo (talk) 06:57, 6 May 2025 (UTC)
@DMacks:
Please use specific examples because I do not understand your request.
There are many chemistry articles on enwiki. Please link to a specific article and identify the graphical representation of a chemical that illustrates your topic.
Also, do you know the external program being used? AFAIK, the chemical diagrams on enwiki are ordinary SVG, PNG, or JPEG images. Some of those images may have been created by programs such as ChemDraw, but the result held on Commons is just the image file.
Do you want to be able to read that information from data held on Commons? Or do you want Commons to access a data table held at an external source?
Or are you referring to self-contained notations such as SMILES or identifiers such as CAS or InChi? Glrx (talk) 17:50, 6 May 2025 (UTC)
I assume you mean external website not program? In any case, the mediawiki api supports retrieving such data. See and Bawolff (talk) 16:05, 8 May 2025 (UTC)
The goal is to have chemical-structure data that could be loaded by a tool that allows 3D rendering and real-time manipulation. We currently have something close in all enwiki infoboxes for chemicals and drugs, which links to an external instance of en:JSmol which has its own collection of data (or looked up from various even other sources, or guessed). As example, see the "3D model (JSmol) Interactive image" link in en:benzene. But the results are sometimes poor (or even hilariously wrong) for certain classes of chemicals, such as organometallics (we disabled the tool in en:ferrocene) and complex cyclic compounds (see en:vancomycin). The structure data are well-known plain-text formats. So my proposed solution is for commons to host the chemical-structure data, then enwiki articles call external JSmol to load the commons data file. There are lots of reasonable file-formats, such as PDB, XYZ, and MOL, all are tabular and/or easily serialized. DMacks (talk) 19:08, 8 May 2025 (UTC)
Direct benzene link
Direct ferrocine link
Direct vancomycin link
Website can take a file or a URL in the right click directory.
Glrx (talk) 21:24, 8 May 2025 (UTC)
Yup. And the results both those ferrocene and vancomycin links give are very incorrect (compare with correct ferrocene and correct vancomycin). That's why the goal is to be able to host the right data in a file we can hand to it via the source=. Upstream developers are quite receptive to feature requests, so I would not think it will be hard to teach it json or other serialized format if necessary. DMacks (talk) 23:26, 8 May 2025 (UTC)

Some notes...

Glrx (talk) 14:52, 14 May 2025 (UTC)

How about using a .MOL file from outside sources such as ChemSpider?

If the substance has a ChemSpider id, then pass either the ChemSpider id (and let the JSMol app figure it out) or pass a URL for ChemSpider's .MOL file (there should be a mapping from the id to the .MOL URL.) Glrx (talk) 21:36, 17 May 2025 (UTC)

Using ChemSpider .MOL files
Select sheme ball and stick
Can use PDB ids
Poor display from smiles is a limitation of https://cactus.nci.nih.gov/ server? Check the MOL files.
Glrx (talk) 04:26, 22 May 2025 (UTC)

Adding images translated to many language to Wikidata items

Many Wikidata items have images set, for many or most an image could be useful, for most that have just one image set that contains text it is in English, and many items have multiple media files for various languages.

Is there an easy way to add many language versions of an image to a Wikidata item at once along with the language qualifier for each? Examples:

Note that for example infoboxes can and do show the image depending on the language qualifier on some project(s). An issue is that the other versions are specified in very many ways and can have different titles (not just the language name), one usually can't QuickStatements via search&replace due to that (and even if that is pretty laborious, manual and fallible). Is there any issue or ongoing development that would make doing this easier? Prototyperspective (talk) 11:31, 13 May 2025 (UTC)

Slightly off topic.
There are multilingual SVG on Commons, but I'm disappointed with the display of File:Conic Sections.svg in conic section (Q124255). For example,
displays the Wikidata page in German, but it does not display the multilingual image in German.
Glrx (talk) 16:07, 13 May 2025 (UTC)
Yes, that's a related issue. I wondered what it would do for SVG files that have been translated on Commons, thanks for the example. I think largely Wikidata is not designed for people (other than few contributors themselves) to look at the Wikidata items – instead the data in these is used for example in listeria lists and infoboxes like the infoboxes in Commons categories. It would need to read (and cache?) the languages the used SVG file is available in. I doubt there would be some synergy in addressing both issues at once so I think it would be good to focus on one issue first which itself is quite tricky already. It also can't be a solution to have Wikidata users add the same image dozens of times each with a different language as qualifier if that's what one may think a solution would be so some reading of data specified on Commons on the side of Wikidata would probably be best either indirectly or via some tool that is used for adding such files to an item. Lastly, when having something like ?uselang=de set or certain preferences, it may be best to collapse or hide any long list of files and just display those in German, English (often the only files, often translatable, understood by many, understood according to my prefs), and no language set. The Commons category infobox already shows video files depending on the configured language. Prototyperspective (talk) 22:26, 13 May 2025 (UTC)
There isn't really any reason not to show svgs in tge viewed language on wikidata except for cache splitting and potential confusion of different users seeing different things. I think the main reason it wasn't done originally (or that svgs dont default to wiki content lang) was that it was easier than thinking through all the implications. However i dont think there is any fundamental reason not to. Bawolff (talk) 16:23, 23 May 2025 (UTC)
I thought the main or possibly only reason for why it wasn't done are technical difficulties of doing so or the difficulty of developing this combined with that not many people have noticed this. I read Glrx' comment as not suggesting anything else and slightly as also a description of a technical issue. May be good to create a phab issue about this, which is similar and related to the subject of the thread, if there is none so far. Another subject related to this is the categorization of translated SVG files, many files are not as well-categorized as the example file above and it's currently done manually – see here. Prototyperspective (talk) 17:24, 23 May 2025 (UTC)
Multilingual SVG files do have tough issues on Wikidata. If an image is specified as multilingual, then displaying it in the user's language makes some sense. If an image is marked as German, then should it be displayed in German rather than the user's language? Should users be required to specify &lang=de? If and when MediaWiki directly serves SVG, then the browser will decide which language is displayed. Should multilingual SVG be entered for each language they cover? That would make queries for an image in a specific language simpler.
Glrx (talk) 19:09, 23 May 2025 (UTC)

How does commons reject duplicates？

from my experience, it seems that if a file to be uploaded is already existing on commons, url2commons (and many other tools such as uploadwizard) will show an error and cannot upload it, but Commons:Flickr2Commons seems to be able to upload them? i dont understand how f2c can "force" the upload? RoyZuo (talk) 08:13, 19 May 2025 (UTC)

Probably: F2C does not use Upload Wizard (or does it?) and thus does not use its javascript that checks for and prevents duplicates. Prototyperspective (talk) 11:06, 19 May 2025 (UTC)
I imagine just use special:upload and click ignore all warnings. UploadWizard treats warnings as errors often. Bawolff (talk) 16:17, 23 May 2025 (UTC)

I'm asking because the camera model in the EXIF data of File:Bobruisk 0.jpg is saying "Camera manufacturer Fly" and the word Fly is linking to the English Wikipedia page on flies 🪰 (insects) instead of to the camera manufacturer. Where and how can this be changed? The camera used is one from a smartphone. There's a Ru Wiki article on the smartphone model: w:ru:Fly IQ4516 Octa Tornado Slim. And for the manufacturer

Could someone fix the incorrect hyperlink in the EXIF data? Nakonana (talk) 09:40, 24 May 2025 (UTC)

We also have Category:Fly mobile phones. Nakonana (talk) 09:53, 24 May 2025 (UTC)
The link is controlled by {{Exif-make-value}}; make an edit request on its talk page to add a case for this manufacturer. Omphalographer (talk) 21:02, 24 May 2025 (UTC)

VFC broken

Hi, VFC seems broken. Nothing loads today. Tested on several categories. The look is also different. Please see MediaWiki talk:Gadget-VisualFileChange.js#VFC broken. Thanks, Yann (talk) 18:14, 24 May 2025 (UTC)

Tech News: 2025-22

MediaWiki message delivery 20:01, 26 May 2025 (UTC)

Several images from 2019 are not available in smaller resolutions

There are several images uploaded on 2 May 2029 by the same user, where smaller resolutions are not always available, often with the error "Too Many Requests", sometimes with "Our servers are currently under maintenance or experiencing a technical issue". See . I did not check any uploads from other users from that day. Is this a temporary error, or is something wrong with these images? Wimmel (talk) 16:55, 27 May 2025 (UTC)

Created phab:T395363 for this. Mbch331 (talk) 17:50, 27 May 2025 (UTC)
Category:Commons talk archives