Shortcuts: COM:VP/T • COM:VPT

👁 Image

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

👁 Image

When importing this file, an error occurred, causing it to appear corrupted. For whatever reason though, this only appears to the importer, and everyone else sees it normally (as evidenced here & here). Note that this isn’t a cache issue as purging both client & server cache doesn’t fix it. As evidenced by here, deleting it and then re‐importing it does fix the issue. ANOTHERWlKlPEDlAN _{wɑit thɑt’s ɑ typo} 09:51, 29 April 2026 (UTC)

@Anohthterwikipedian, It seems to be working for me, and PDF's are normally problematic. Have you considered/attempted converting to djvu and checking? (Just to be safe, what resolution are you trying to generate thumbnails?) All the Best -- Chuck ^Talk 21:38, 18 May 2026 (UTC)

After a recent OnePlus firmware update, photos taken on the device no longer seem to store GPS coordinates in the standard EXIF GPS tags. However, Google Photos still detects and displays the location correctly. On Wikimedia Commons, the coordinates are lost on upload, while other metadata (date, camera model, etc.) remains intact, so this does not appear to be an EXIF-stripping issue.

Example file: photos.app.goo.gl/PeLpeY2eDWoQEYNo8

Could somebody inspect the file and determine where the coordinates are actually stored? My guess is that OnePlus now writes them into some non-standard XMP field, MP4 box, or proprietary metadata structure that Google Photos understands but ExifTool/MediaWiki currently ignore.

If the storage format can be identified, it may be possible either:

• to teach Commons/UploadWizard to extract these coordinates, or
• to add support in ExifTool/media handlers.

Technical analysis would be appreciated.

For my own use, I managed to restore normal EXIF GPS tags by changing a system setting, but the workaround is fairly non-obvious: location access must remain enabled while the "precise location" option is turned off. That does not really solve the problem for other users, though. Анастасия Львова^ru/en 08:38, 9 May 2026 (UTC)

@PantheraLeo1359531 Kritzolina says that maybe you know something about it ;) Анастасия Львова^ru/en 11:38, 9 May 2026 (UTC)

This in an interesting topic! I had something similar. I can imagine that they are in a format that Commons does not recognise. I can bring an example.

👁 Image

👁 Image

These examples show that something little missing is causing a failing geotagging. In the example file, I couldn't find any coordinates (neither in Photoshop nor via Exiftool (as RAW values). I don't know if Google stores the GPS data externally (which would be weird), but at least in this case, I didn't find any hint on the coordinates. --PantheraLeo1359531 😺 (talk) 12:40, 9 May 2026 (UTC)

No, I don't think it is external - if I download them back on the phone I have coords again, and my phone is not a Google phone (okay, maybe it is not a strong argument, I am not technical enough). Maybe you know where to ask further? My ideas are over :( Анастасия Львова^ru/en 12:52, 9 May 2026 (UTC)

Not quite, but maybe we get another answer here --PantheraLeo1359531 😺 (talk) 15:41, 9 May 2026 (UTC)

@Lvova A pal just texted me that in Google Photos, the metadata of his photos are stored in another folder. The Metadata files are in JSON, so we either can convert them in CSV and then EXFITOOL can add the metadata to the respective file, or directly. Anyway, the technique of having the Metadata NOT within the photo files is not appreciated --PantheraLeo1359531 😺 (talk) 09:12, 14 May 2026 (UTC)

It is not a solution, just a barrier to check the situation. I have photos on my phone, I may upload them directly, and they will be without coordinates for Commons; but during the synchronization with Google Photo there is some magic, and GPhoto has access to coordinates (okay, there are in another file, so you cannot check). So the problem is still the same: the phone has coords somewhere for GPhoto, but not for Commons. Анастасия Львова^ru/en 09:46, 14 May 2026 (UTC)

Some phones will remove gps from photos when uploading to a website for privacy reasons. Often its a setting you can disable. Bawolff (talk) 19:39, 14 May 2026 (UTC)

If they are deleted in this case, how GPhoto receives this information, what's the difference with Commons? So no, it is not the solution at all. Анастасия Львова^ru/en 19:49, 14 May 2026 (UTC)

Did you upload to gphoto via the gphoto website or use some sort of app integration with gphoto? Bawolff (talk) 01:51, 15 May 2026 (UTC)

"coordinates are lost on upload"

@Lvova how did you upload? which app did you use?

first check whether you actually got this problem Commons:Village_pump/Technical#c-RoyZuo-20260420223600-Phone_stripping_coords_/_geotags_since_April_2026!. RoyZuo (talk) 20:33, 17 May 2026 (UTC)

My default app for uploading is Google Chrome on the phone. I also tried Commons:Mobile app and uploading from the PC (but after GPhoto). I have no idea after reading that topic is it the same or not and cannot repeat the focus with another file manager; I am waiting for reply from OnePlus support also. Анастасия Львова^ru/en 20:47, 17 May 2026 (UTC)

@Lvova you should try copying the file through usb cable to laptop and then upload. this should keep all the exif as they are in the original file.

as far as i know, going through chrome should strip the location data.

commons mobile app presumably keeps the data but i didnt test it so i'm not sure.

going through google photos has other complicated tricky things. RoyZuo (talk) 20:56, 17 May 2026 (UTC)

Finally rechecked, and yes, it is that problem :( Анастасия Львова^ru/en 13:20, 20 May 2026 (UTC)

At https://antiquepianoshop.com/online-museum/connor-francis/ there's a circa 1902 catalog that I want to use, but it's presented in one of those annoying flip-page things. Are there any tools that make it easy to grab a PDF of the whole catalog? If I had to, I could dig out the individual underlying images or screenshot them and assemble the pages myself, but I'm hoping to avoid that if I can. RoySmith (talk) 14:06, 16 May 2026 (UTC)

@RoySmith: Someone who does uploads with a bot may be able to help with this; someone has probably run across one like this before. Commons:Bots/Work requests. - Jmabel ! talk 17:17, 16 May 2026 (UTC)

@RoySmith and @Jmabel, this online tool worked well for me. I can send you the PDF if you are having trouble. JayCubby (talk) 16:17, 19 May 2026 (UTC)

Cool, thanks. I ended up doing the hand-assemble way (MacOS Preview makes this easy once you've manage to assemble all the individual page files on disk), but I'll keep that tool in mind because I've had to do this in the past and I'm sure I'll have to do it again in the future. RoySmith (talk) 16:26, 19 May 2026 (UTC)

We have a gadget for reverse image search using Google Lens, TinEye and Yandex. This worked for years and allowed to search for copyvios. However, recently it ceased to work. Google Lens, for example, reports simply “Something went wrong” and details ”No image at the URL. Try again with a different URL or image”. This is possibly due to a current development according to which our infrastructure is to be protected from abusive scraping by introducing a provenance of image requests. This has been discussed previously at MediaWiki talk:Gadget-GoogleImagesTineye.js#Reverse Image Search - Google and TinEye failing to retrieve source images from Commons. Apparently, image fetches can be blocked due to violations of the user-agent policy. Right now, Google fails but TinEye and Yandex work. --AFBorchert (talk) 07:45, 18 May 2026 (UTC)

I have the same problem, although Google sometimes works, but usually not. Wouter (talk) 08:16, 18 May 2026 (UTC)

• Google Lens doesn't work for me since May, 18. It makes categorization much harder. Юрий Д.К. 19:05, 19 May 2026 (UTC)
  • I've had some problems on that front, but it's straightforward to download a moderate-resolution version of a photo and then load it from your own drive into Google lens. - Jmabel ! talk 22:14, 19 May 2026 (UTC)
    • This works but is a hassle when handling large numbers of possible copyvios. Checking for possible copyvios should be easy and convenient. --AFBorchert (talk) 22:17, 19 May 2026 (UTC)
      • It works (I've used this method) but yes, it is a hassle a bit. Quite difficult to categorize some photos without Google Lens (birds, plants, notable buildings etc) Юрий Д.К. 16:15, 20 May 2026 (UTC)

Never heard of the gadget, but https://github.com/dessant/search-by-image works and I use it on my laptop and phone. Ponor (talk) 08:15, 20 May 2026 (UTC)

I've installed it as a Firefox addon, sadly the same problem. Юрий Д.К. 16:15, 20 May 2026 (UTC)

I see what you mean. Though it worked when I first replied, I'm getting the same error. The add-on has in its settings different modes, and the default mode is to send Google the image's URL. I guess their servers cannot get it any more. But there are also options to "select image" and to "capture", and they both work (for me). That's, I'm guessing, because we're sending Google what's on our screen. Give it a try. Ponor (talk) 16:51, 20 May 2026 (UTC)

Since some days, i get often following error message (used different files for check): Upload konnte nicht gespeichert werden (MediaWiki\Upload\Exception\UploadStashFileException): „Im Speicher-Backend „local-swift-codfw“ ist ein unbekannter Fehler aufgetreten.“.

Anyone know how to fix this, or is this a global problem at the moment? Grunpfnul (talk) 12:03, 18 May 2026 (UTC)

I had this, too, today. 1 hour later, it worked again --PantheraLeo1359531 😺 (talk) 13:18, 18 May 2026 (UTC)

MediaWiki message delivery 20:18, 18 May 2026 (UTC)

Has anyone changed Special:Upload (not the 'wizard') during the last ~year?

I've put a full description (Template:Information plus license and categories) in the freeform box:

{{Information
|description={{en|1=Re-drawn version of Figure 1 in https://www.frontiersin.org/journals/psychiatry/articles/10.3389/fpsyt.2022.856084/full#F1 showing only people diagnosed with ASD vs normal distribution of IQ}}
|date=2026-05-19
|source={{own}}
|author=[[User:WhatamIdoing|WhatamIdoing]]
|permission=
|other versions=[[:File:Bimodal IQ distribution in autism.png]]
}}

=={{int:license-header}}==
{{self|cc-by-4.0}}

[[Category:Common autistic traits]]
[[Category:Intellectual disabilities]]

The preview on the first page looks correct. On the second page, it tells me that it's changing the file name (to add _under_score_ characters).

It also shows none of the information (except the file name) that I put on the previous page. Several key fields are empty red boxes. The four buttons at the bottom of the page:

• "Submit modified description"
• "Preview"
• "Ignore warning and save file anyway"
• "Return to the upload form and choose a different name."

do nothing. If I use the 'back' button in my web browser, and tick the 'Ignore any warnings' box, then it finally uploaded. But what's wrong with the form, that it doesn't work? WhatamIdoing (talk) 00:25, 20 May 2026 (UTC)

@WhatamIdoing: Is this about File:Bimodal IQ distribution in autism.png, File:Bimodal IQ distribution in autism 2d line chart.png or something else? Both of those files seem to have uploaded correctly (I assume after the back button thing). Are you saying that you did click "Ignore warning and save file anyway" (the correct choice) but it didn't work? - Jmabel ! talk 03:40, 20 May 2026 (UTC)

The "2d line" one, and yes, what worked was:

• Back button to get off the mostly blank (except for the red error warnings) screen
• Tick the checkbox on the first page to ignore warnings.

On the second (with red error warnings) page, the "Ignore warning and save file anyway" button never did anything. WhatamIdoing (talk) 03:51, 20 May 2026 (UTC)

Not sure if that's the best place for my question - does anyone know what's going on with PagePile? The service seems to be up and running, but the recent piles page is empty, and generating a new pile from PetScan fails with an error ("PagePile generation did not return valid JSON: expected value at line 1 column 1" or "PagePile generation did not return a pagepile ID: {"status":"ERROR: Server error. Please retry."}"). Fl.schmitt (talk) 17:33, 22 May 2026 (UTC)

to implement Commons:Village_pump/Proposals/Archive/2022/12#c-A455bcd9-20221213122400-Enable_ProveIt_or_Citoid_on_Commons.

looking for technical help especially from interface sysops to enable citoid according to mw:Citoid#Configure_Citoid_on_a_Citoid-enabled_wiki. i'm busy for a while so i'm hoping someone could tackle this. RoyZuo (talk) 19:22, 22 May 2026 (UTC)

Hi there! On this page that I picked randomly as an example File:1 Mercado do Bolhão.jpg, you can see above the image - at least on the Vector and Vector 2022 themes on desktop - there are icons and links as follows: "Download", "Use this file" [icon: web], "Use this file" [icon: Wikipedia], "Email a link", and "Information". I find these quite useful, in particular "Use this file", because it gives me the text of an attribution I can copy into wherever I'm using it (off-wiki).

By contrast these options are missing for me on the page File:Wisteria floribunda5.jpg. I am curious if that's intended behaviour and if so what the cause is. CharredShorthand (talk) 04:55, 23 May 2026 (UTC)

After some research I came up with the hypothesis that this is based on whether there is machine-readable author information, so I've added {{Information}} to the page and that's made those links indeed appear. Resolved! CharredShorthand (talk) 05:06, 23 May 2026 (UTC)

MediaWiki:Gadget-Stockphoto.js is the tool. your analysis seems correct. RoyZuo (talk) 17:17, 23 May 2026 (UTC)

MediaWiki message delivery 21:49, 25 May 2026 (UTC)

Starting in May 20, 2026, “Lua error: too many expensive function calls.” have been appearing on COM:DR. 6D (talk) 04:18, 26 May 2026 (UTC)

I've updated Module:Deletion_request_counter (diff) to remove an unnecessary call to title.exists, which seems to have done the trick. ~Kevin Payravi (talk) 06:56, 26 May 2026 (UTC)

(if I'm not mistaken, this took the expensive function call count from 512 to 312, with 500 being the limit). ~Kevin Payravi (talk) 08:51, 26 May 2026 (UTC)

I don't know if this is the doing of Upload Wizard or structured data bots or both. I go to edit a file and the date field reads June 31 or July 32 or similar. It's definitely not human editors doing this. RadioKAOS / Talk to me, Billy / Transmissions 17:25, 26 May 2026 (UTC)

Hello @RadioKAOS, can you provide some examples of the files with this error? I don't know which files you are referring to, but the date field in a file description is usually provided by the uploader, and the uploader may have unintentionally entered an incorrect date. Thanks. Tvpuppy (talk) 20:33, 26 May 2026 (UTC)

I generally prefer not to do examples, because that gives people an excuse to dwell on the example and not acknowledge the bigger picture when it exists. I also fixed the date fields with my edits, so you won't see it in the current revisions. Therefore, I had to go back and look for them. On all revisions of File:U.S. Air Force members transfer recovered remains from 1952 C-124 crash site on Mount Gannet - Joint Base Elmendorf-Richardson Hospital, Anchorage, Alaska - June 2021.jpg prior to my edit, the date shows "1 July 2021" in the file description page, but shows "2021-06-31" while in edit mode. The other one I noticed was File:U.S. Army SSgt Berg climbs out of a crevasse after searching through debris at Colony Glacier, Alaska - July 2024.jpg. All revisions prior to my edit show a date field of "July 2024" in the file description, but shows "2024-07-32" in edit mode. If it helps to determine what the problem might be, both files were uploaded by ERcheck and the information inserted into the date field was different from not only the camera date in the metadata, but the actual date taken as found in the description and the caption. RadioKAOS / Talk to me, Billy / Transmissions 15:43, 28 May 2026 (UTC)

Thank you for your reply. I notice both files were uploaded through UploadWizard, and it seems the date was incorrect from the beginning. I don't think the date was automatically extracted by the UploadWizard from the EXIF data, as it would have also included the time from the EXIF data. So, it is possible it was the uploader who simply entered the incorrect date unintentionally.

Note that the UploadWizard only checks if an inputted date is "in the future", it does not check if the date is correct or not.

The {{Information}} template uses {{ISOdate}} to display the date from the date parameter. So, if an incorrect date is provided, then the date displayed will be inaccurate.

• {{ISOdate|2021-06-31}} => 1 July 2021
• {{ISOdate|2024-07-32}} => July 2024

So, in my opinion, these are most likely just human errors. Thanks. Tvpuppy (talk) 16:02, 28 May 2026 (UTC)

It has been almost a year since I uploaded the files, and I do not remember the details of the uploading. It is possible that I had typos in both of those dates. I just did a test edit, with preview, entering the yyyy-mm-dd format. I saw in the preview the same inaccurate rendering of the dates described above. It would be great if automatic error checks warned of these human errors. — ERcheck (talk). 18:55, 28 May 2026 (UTC)

For the past few days, a bug with labels has been occurring occasionally. Screenshot (labels in any language). Label is being added over the place and there is no way to save it. Eurohunter (talk) 17:48, 26 May 2026 (UTC)

Hello @Eurohunter, this appears to be a Wikidata issue, perhaps you can ask for help at d:Wikidata:Project chat. Thanks. Tvpuppy (talk) 18:45, 26 May 2026 (UTC)

@Tvpuppy: It was supposed to be added there, but I just added it to wrong place. Eurohunter (talk) 18:48, 26 May 2026 (UTC)

Hi! I was trying to add a "depicts" thing to a few images, the first one went through but on the second one I got a red textbox that said:

• The save has failed.
• To edit this page, please solve the following task below and enter the answer in the box (more info):

but no captcha actually appeared. Reloading does not fix the issue. I'm guessing this is a bug related to the switch to hCaptcha?

(Also, the text on Special:Captcha/help appears twice, but that's probably unrelated.) ~2026-31778-15 (talk) 13:40, 27 May 2026 (UTC)

I'm not sure. Try bypassing your cache when reloading. HyperAnd [talk] 08:05, 28 May 2026 (UTC)

@KHarlan (WMF) @WBrown (WMF) FYI in case this isn't known / is something related to the hCaptcha rollout. With apologies if you're the wrong folks to ping about this :) ‍—‍a smart kitten_[meow] 08:12, 29 May 2026 (UTC)

Thanks for the ping. I'll test this now WBrown (WMF) (talk) 10:24, 29 May 2026 (UTC)

I was unable to reproduce this just now. I was able to add a structured data item using a temporary account and didn't see this CAPTCHA. Let me try a few more things, but it would be helpful to know if there was anything other that was different about the structured data edit form when you made the change WBrown (WMF) (talk) 10:30, 29 May 2026 (UTC)

I can't be sure about whether or not this might be relevant context; but it just occurred to me to look at this TA's Special:AbuseLog, and it appears that they may have hit an abuse-filter a few times that resulted in the showcaptcha action? Best, ‍—‍a smart kitten_[meow] 10:36, 29 May 2026 (UTC)

Yeah, you had the same thought as me at the same time :D. Triggering an AbuseFilter during a change then caused it to show this for me. I'll file a Phabricator bug report WBrown (WMF) (talk) 10:42, 29 May 2026 (UTC)

So further investigation shows that:

• The user gets presented with a FancyCaptcha challenge and not hCaptcha
• AbuseFilter forces the CAPTCHA to be shown, which does not work because it seems that the structured data editor does not have support for any type of CAPTCHA

As far as I can see, it seems like this would have been broken before hCaptcha was rolled out. However, we should be able to fix it WBrown (WMF) (talk) 11:18, 29 May 2026 (UTC)

(I'm assuming that this is now phab:T427608 — thanks for reporting this @~2026-31778-15, and thanks for filing @WBrown (WMF) :)) ‍—‍a smart kitten_[meow] 12:01, 29 May 2026 (UTC)

The main cause here is the broken abuse filter interpretation of structured data that always adds a link to the new lines parameter. GPSLeo (talk) 18:43, 29 May 2026 (UTC)

I can get right up to starting the file upload, but after a few seconds it returns "Origin https://flickr2commons.toolforge.org is not allowed by Access-Control-Allow-Origin.". It was working fine just 2 weeks ago.

Not sure if related, but I also tried to upload a video from Flickr using Video2Commons, and that also returned an error. LetmeEditit (talk) 10:46, 28 May 2026 (UTC)

Just tried again, still not working. It also hangs on "running" for 2-3 minutes after I enter the URL, but lets me through eventually. The error shows after I hit "Transfer selected files to Commons". LetmeEditit (talk) 10:10, 31 May 2026 (UTC)

Same issue, I also got “Load Failed” when I hit "Transfer selected files to Commons". 6D (talk) 02:53, 5 June 2026 (UTC)

Still not working... is there anywhere I can report this? I assume it's run by a volunteer who has better things to do than sit around tinkering all day... but worth a shot. LetmeEditit (talk) 13:38, 12 June 2026 (UTC)

Still not working, but I found a copy that works! https://flickr2commons-ng.toolforge.org/ — see Commons talk:Flickr2Commons#Tool down, use this copy. LetmeEditit (talk) 13:26, 16 June 2026 (UTC)

But it don’t support CC 4.0 licenses… 6D (talk) 11:39, 17 June 2026 (UTC)

I was wondering why it wasn't working for one specific user! Well, at least it's something. LetmeEditit (talk) 12:50, 17 June 2026 (UTC)

For several days now, I've noticed that when using the search engine (both on desktop and Android), the image upload results often show missing or corrupted images. For example, when searching for Einstein (this happens with any search term): https://commons.wikimedia.org/w/index.php?search=einstein&title=Special%3AMediaSearch&go=Go&type=image

--Xabier (talk) 13:47, 28 May 2026 (UTC)

@Xabier Thank you for the report :) I could also reproduce this myself, & I notified the relevant folks on Phabricator at phab:T424032#11965264. Best, ‍—‍a smart kitten_[meow] 08:05, 29 May 2026 (UTC)

You are invited to voice your opinion on a new community-proposed direction for the Community Wishlist. Thank you! MediaWiki message delivery (talk) 03:07, 29 May 2026 (UTC)

is there a tool that downloads the file, as well as the metadata (wikitext of the file page; com:sdc; and possibly entire file page history) in a machine readable format (json/csv/readme.md...?)? requiring as few clicks as possible? one click on one button, or two clicks on two buttons? and a batch download tool for multiple files?

the use is, i save a bunch of files, but i also want to keep track of what each file is and the url they come from. RoyZuo (talk) 21:10, 31 May 2026 (UTC)

before a solution is found i'm just taking screenshots of the wikitext and save them together on my pc. RoyZuo (talk) 21:11, 31 May 2026 (UTC)

gallery-dl should be able to download files within a cat and JSON files with their respective metadata. You may add a sleep timer parameter to avoid too many requests --PantheraLeo1359531 😺 (talk) 13:07, 1 June 2026 (UTC)

i've noticed that people quite often copy the url when they "preview an image in a category" for attribution purpose, e.g. https://commons.wikimedia.org/wiki/Category:Tsai_Ing-wen_in_2009#/media/File:Tsai_Ing-wen_2009.jpg . if commons is serious about "protecting reusers" by "ensuring hassle-free attribution", this should be prevented. RoyZuo (talk) 07:37, 1 June 2026 (UTC)

What do you mean ? 1. we can't stop what people do. 2. links are how all our images are attributed throughout all the wikis. —TheDJ (talk • contribs) 08:50, 1 June 2026 (UTC)

🤷‍♀️ you could fix this design that leaves room for error? as simple as by for example not making these "preview links" when "Media Viewer" is used? then dummies will not see such links to copy from in the first place? RoyZuo (talk) 10:44, 1 June 2026 (UTC)

I proposed some changes to the Module and am looking to hear opinions on that: Module talk:Countries#Reduce expensive function count -- DaxServer (talk) 19:28, 1 June 2026 (UTC)

MediaWiki message delivery 21:05, 1 June 2026 (UTC)

Per a little discussion on Village Pump, I would like to request the change the prefixes of the units mentioned on Special:MediaStatistics. Although units like MB, GB or TB (soon PB) are used, they have the base 1024, and not 1000, like SI prefixes should have. So we should change them to MiB, GiB or TiB, as described in Byte#Multiple-byte_units. --PantheraLeo1359531 😺 (talk) 08:19, 2 June 2026 (UTC)

See the related Phabricator task and its extensive discussion here: phab:T54687. It appears currently your request is unlikely to be accepted. Thanks. Tvpuppy (talk) 09:38, 2 June 2026 (UTC)

it's just not that important. the page isn't a wikipedia article and most people know what it means. MediaStatistics is also just an approximation to begin with. There's a lot of issues to deal with and correcting this is not very high on most peoples todo list, sorting out peoples opinion about this topic is even lower on that list, and thus things stay the way they are for a little longer. —TheDJ (talk • contribs) 10:23, 3 June 2026 (UTC)

People have been flamewaring about these units since the 90s. You don't need devs permission to change it on commons though, you can just edit mediawiki:size-megabytes and related pages. Bawolff (talk) 22:53, 4 June 2026 (UTC)

It was incredibly fast, but just today it's slowed to a crawl — about 1 file every 3 seconds. Were there any changes? LetmeEditit (talk) 13:49, 4 June 2026 (UTC)

Seems to be fixed today. Strange... LetmeEditit (talk) 13:24, 5 June 2026 (UTC)

HotCat is client-side application. It might be because of your internet connection. Nemoralis (talk) 21:14, 5 June 2026 (UTC)

Suddenly slow again today. It's so strange, my internet seems to be working fine. All other editing etc is snappy as usual. LetmeEditit (talk) 11:26, 12 June 2026 (UTC)

Sounds like you're talking about Cat-a-lot, not HotCat. Am I right? Ponor (talk) 09:49, 14 June 2026 (UTC)

If it is Cat-a-lot then it will slow down if there is high database load and it will switch to sequental editing instead of parallel which could cause effect described. In any case, please report Cat-a-lot slowdowns here MediaWiki_talk:Gadget-Cat-a-lot.js also. --Zache (talk) 09:58, 14 June 2026 (UTC)

You're right, sorry! I do mean Cat-a-lot. LetmeEditit (talk) 10:05, 14 June 2026 (UTC)

Hello,

I just wrote MediaWiki_talk:Gadget-VisualFileChange.js#Blocking_bug_in_VFC,_existing_since_2025-03-08_at_least. I'm posting this info here for possibly raising broader awareness. Regards, Grand-Duc (talk) 00:40, 6 June 2026 (UTC)

MediaWiki message delivery 21:27, 8 June 2026 (UTC)

I'm not sure if these files are eligible for deletion or some other remedy, but it seems like there's some issue with the unused files File:Location of Baixo Alentejo in 1936.svg and File:Location of the Baixo Alentejo Province in 1936.svg, which are very large at 2,211,320 × 6,148,917. They don't seem to render properly on my device. One is marked as having invalid SVG and the other is not. — Wracking ( talk / contribs / uploads ) 23:58, 11 June 2026 (UTC)

For me, in both cases, Commons fails to give me a usable PNG thumbnail (I just get a blank) but if I click through to the "Original file" it renders fine. Obviously if someone can make them render better, that's good, but I don't think deletion is in order, since they aren't useless. - Jmabel ! talk 03:12, 12 June 2026 (UTC)

I fixed File:Location of the Baixo Alentejo Province in 1936.svg by uploading a new version manually edited from File:Portuguese Provinces in 1936.svg (and tagged File:Location of Baixo Alentejo in 1936.svg for deletion as a duplicate). the wub "?!" 07:59, 12 June 2026 (UTC)

Those dimensions would make whopping 13,597,223,140,440 (13.6 terapixels) :O --PantheraLeo1359531 😺 (talk) 16:06, 12 June 2026 (UTC)

Note that the SVG has no size (and definitely no pixels). It has a coordinate system and it scales infinitely. But the renderer to png DOES need a size and it likely takes this SVG ‘size’ as its initial starting size, before it scales down to whatever you requested. Dividing all coordinates and ‘sizes’ of the SVG by a factor of a 1000 might actually make this SVG work, by reducing the starting drawing surface for the png renderer. But I don’t know if there are any SVG authoring tools that allow you to do that easily. —TheDJ (talk • contribs) 08:39, 13 June 2026 (UTC)

vte buttons in Template:Navbox are invisible in dark mode. i could trace the problem only to Module:Navbar but not any further. RoyZuo (talk) 11:52, 15 June 2026 (UTC)

Not sure what the cause of the problem is, but I think the CSS styles for the navbox are defined in MediaWiki:Common.css. Thanks. Tvpuppy (talk) 14:56, 15 June 2026 (UTC)

Whenever a background color is defined, so should be the text color. But in Special:Permalink/576723076#L-87 that's not the case. I don't really see the need for having the bg color set here to anything TBH. Ponor (talk) 16:28, 15 June 2026 (UTC)

Module:Navbar clearly states that it is imported from English Wikipedia. English Wikipedia moved it´s css to templatestyles. It has been 12 years since it was updated, someone needs to go over the parameter changes, whether the arguments are handled differently and whether they are all still there. If not, some navbox usage might break. Only when that is okay it is safe to update it. Snævar (talk) 10:13, 16 June 2026 (UTC)

MediaWiki message delivery 16:45, 15 June 2026 (UTC)

There is currently a strange problem in de.Wikipedia: for some reason File:Mühlgrabenmündung.jpg and File:Mühlgrabenquelle.jpg cannot be included in articles. What makes the situation even more confusing: Parsoid always fails, while the Legacy Parser can sometimes load the files. Here is a comparison using the migration tool. Purging (action=purge) is not fixing the problem. Is this a known problem that can be fixed here on commons? Kallichore (talk) 21:11, 15 June 2026 (UTC)

It seems like some sort of cache on the parsoid side. I haven't heard of anything like this before. I would suggest filing a ticket in phabricator Bawolff (talk) 01:16, 16 June 2026 (UTC)

Ok, I created a task.--Kallichore (talk) 18:18, 16 June 2026 (UTC)

@Kallichore looks more like a commons problem.

when i visited File:Mühlgrabenquelle.jpg, "No file by this name exists, but you can upload it. If a file used to exist, try to purge this page's cache"

even though https://upload.wikimedia.org/wikipedia/commons/thumb/3/34/M%C3%BChlgrabenquelle.jpg/250px-M%C3%BChlgrabenquelle.jpg https://upload.wikimedia.org/wikipedia/commons/3/34/M%C3%BChlgrabenquelle.jpg could be accessed.

so i purged the file page, then the file appeared again.

not sure how long it takes until de:Mühlgraben (Aubach) shows it. or maybe it needs to be edited and saved to force it? RoyZuo (talk) 20:23, 16 June 2026 (UTC)

Any idea why File:09.06.2026 – Vizita de studiu a Comisiei pentru integrare europeană la București - 55324258433.jpg is still displayed in Category:Photos from Parlamentul Republicii Moldova Flickr stream to be reviewed in spite of said category being deleted a while ago? Gikü (talk) 14:15, 17 June 2026 (UTC)

All I had to do is ask :) Can't see it anymore, although like I mentioned it was there for a week. Gikü (talk) 15:15, 17 June 2026 (UTC)

Is Google bans requests from Commons directly or there is some technical error here? As Google lens not working, categorizing files and searching copyvios becomes harder. Is there is a chance that the issue will be fixed? Regards, Юрий Д.К. 17:45, 17 June 2026 (UTC)

I decided to give another overview of some of the technical changes that have happened in the media support corner of MediaWiki. This is mostly an overview of activity since may 15th.

• The reduction of allowed thumbnails sizes (to deal with excessive scraping and storage problems) is still ongoing, but most rough edges have now been tackled. The peak disruption of 429 error you might have experienced should be mostly dealt with. Still to do are: T56035 and T401668. Over 22 other tickets have been solved in this area.
• The foundation is implementing a way to keep track of what part of MediaWiki has generated a media url. This is called media provenance. Because of it, you might notice utm parameters in the urls of images
• Work on the migration towards new database tables T28741 for the media files remains ongoing. A few Wikipedias now read from the new tables, and several bugs have been fixed or are being fixed in preparation for the larger switchover.
• Media viewer has seen a lot of action. Myself, simon04 and Krinkle worked on simplifying the existing code and removing lots of legacy code. There were changes for the new thumbnailsizes and the WMF Growth Team has been working on the Image Browsing-feature.
• An issue arose with excessive usage of storage due to uncompressed TIFF uploads that is still under investigation. T427949 There is also an active discussion on the Village Pump about this topic.
• UploadWizard can now make use of captchas (usually this is an invisible captcha) T426126
• A longstanding bug where some of the information in the imageinfo api was missing if a filerevision was missing, has been fixed T239213
• Zoomviewer has been down for several months T428524. If you are interested in picking up maintenance of this tool, you might want to indicate your interest.
• Most devices now support native decoding of our video, and thus the support for software decoding was removed. Software decoding was in place from the very first support of video in 2007 and was actively in use on especially Apple devices all the way up to 2021 T376842.
• And many improvements to keep things working with newer versions of php and MediaWiki itself, code maintenance and technical debt that all have to be done but that are invisible to most users (I estimate some 80+ changes, excl translations).

—TheDJ (talk • contribs) 22:02, 17 June 2026 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Technical&oldid=1233127496"