Commons:Village pump

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2024/12.

Please note:

  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page:

Search archives:

   

Start a new discussion

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Syrian flag 34 7 Jmabel 2024-12-28 02:48
2 Best practice for Questionable Flickr images 9 7 MGA73 2024-12-27 15:37
3 Categories combining city and photographer 10 6 Adamant1 2024-12-27 19:09
4 Video transcoding maintenance in File:Night of the Living Dead (1968).webm 34 7 TheDJ 2025-01-02 14:48
5 Reindeer symbols 5 4 Smiley.toerist 2025-01-01 14:41
6 Category:Deepin Icon Theme 7 5 999real 2024-12-29 18:50
7 There is a problem with Category:House of Skoropadsky and its related WikiData item. 3 2 OperationSakura6144 2024-12-29 11:51
8 Paths and Walkways 3 3 Jmabel 2024-12-30 04:52
9 Flag of Uzbekistan 3 2 Jmabel 2024-12-30 17:20
10 Bayeux Tapestry 3 3 Herbert Ortner 2024-12-30 19:59
11 Need help with a non-legitimate deletion 9 5 JBouchez 2025-01-02 18:56
12 A healthy new year! 4 3 PantheraLeo1359531 2025-01-02 12:30
13 Commons Gazette 2025-01 1 1 RoyZuo 2025-01-01 23:35
14 Mirroring request 4 3 Jmabel 2025-01-02 18:39
15 Discrepancy 8 4 Ymblanter 2025-01-03 21:35
16 To-do list created 3 3 Omphalographer 2025-01-03 23:32
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.
Turkey Beypazarı district Hırkatepe Village pump. [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive
Template: View   ■ Discuss    ■ Edit   ■ Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

December 24

Video transcoding maintenance in File:Night of the Living Dead (1968).webm

Despite being Featured Media, the file was overwritten in early March and it can't be played unless it gets played directly from the source. I tried transcoding the file without any results; it seems i'll need some help with the admins. --Mayimbú (talk) Mayimbú (talk) 07:48, 24 December 2024 (UTC)[reply]

Hi, I reset the transcodes. Nothing more can be done on this side. The failed transcodes are a server issue. Yann (talk) 10:09, 24 December 2024 (UTC)[reply]
Out of memory. The original is too large to be rescaled by the servers. The easy fix is to revert to the previous version. —TheDJ (talk • contribs) 11:06, 31 December 2024 (UTC)[reply]
@TheDJ: This is very bad. We can upload up to 5 GB videos, so the servers should be able to process videos that large, otherwise there is no point to be able to upload them. More generally, I feel this is (again) bad management by the WMF about Commons. How an organization with a 100 M US$ budget cannot do that??? Yann (talk) 11:23, 31 December 2024 (UTC)[reply]
Yes, I'm seriously considering dialing that back pretty soon for this exact reason. —TheDJ (talk • contribs) 13:00, 31 December 2024 (UTC)[reply]
There is a point in uploading videos larger than 4GiB. Some time in the future videos that cannot be transcoded now, can be transcoded then. However videos that have not been uploaded because of a file size limit can neither be transcoded then nor be downloaded in original size now. They will be lost forever. And if someone takes the pain to transcode a 5GiB video to 4GiB (few are able to do that, less are going to take the pain of doing so), the video will always only be available in a lower quality than was possible in the first place.
In the mean time it is always possible to upload a different version with smaller file size and resolution under a different file name for the purpose of streaming it now.
Different aspect: I experienced a number of my uploads of files with 1GB or less have not gone through but failed with the omnious "some one is doing something with this file" or other fail messages. This seemed to be history after @Bawolff's work on large file uploads, but has returned now. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:16, 31 December 2024 (UTC)[reply]
No one is arguing that there isn't a point in doing so. The thing is that Commons is not a video archive. We have never been. We do not have the hardware and software engineering required to support it, and it has become clear (over the last year in various conversations) that Wikimedia will not dedicate the resources (likely in the 10+ million range) that would be required to get us there. And while it is cool that the file limit was lifted, that doesn't mean that other limits do not apply. When we push boundaries, we find new boundaries.
All of this is not helped by people choosing bad encoding parameters for the video. For instance. The original of this archive.org video seems to be a mpeg2 1080p DVD rip (3.8GB, 20Mbps 30fps). It seems that his has been converted here by the uploader into a 3.8GB 1080p AV1 file, which is terribly wasteful (esp for a black and white video) and it shows a lack of understanding of how video encoding works and this is a recurring pattern that I see with uploads (choosing 'quality' and wasted bits over useful content). It seems to me that the only way from preventing people from continiously shooting themselves in the foot, is to reduce how much ammunition we provide them. This is not YouTube, we can't handle what people are uploading. —TheDJ (talk • contribs) 13:38, 31 December 2024 (UTC)[reply]
@TheDJ: I disagree partly with that. Yes, Wikimedia is not YouTube, and it will never be. But it is essential to me that we should be able to host historical and/or high quality videos with educational value. Wikimedia should also adapt to new paradigms in web hosting. We are not anymore in a a world with text encyclopedias and a few pictures. Video is the main medium now to convey messages on the Internet. It seems especially important now that old movies with sound come into public domain. And excuse me, but saying that it would cost in the "10+ million range" is quite nonsense. We only need a few servers with enough memory. I know what I am talking about, that was my job for 10 years. Yann (talk) 14:36, 31 December 2024 (UTC)[reply]
It is possible btw, that this is a downsampled version of the 4K version that exists on Youtube, but if that is the case, then the sourcing for this current upload is not correct. —TheDJ (talk • contribs) 13:55, 31 December 2024 (UTC)[reply]
See below. The main source is a 1080p Blu-ray. This is not an upscale of the DVD. D. Benjamin Miller (talk) 17:15, 31 December 2024 (UTC)[reply]
@TheDJ I feel we suffer a bit from all or nothing thinking on this. Yes, software development is expensive, much more so than most of the other people on this thread probably realize. We definitely aren't going to be competing with youtube any time soon. However I think there is a middle ground where we could have a team dedicated to backend multimedia stuff. Just look at phab - half the reports nobody is even sure what the cause is because there are very few people familiar with the entire backend stack for multimedia in mediawiki to debug/isolate the issue. We can't possibly fix anything if we're not even sure what is broken. Just look at the bug C.Suthorn mentioned (T358308) - it turned out to be a software upgrade accidentally put a time limit on things that is too short. Stuff like this happens in software development all the time. It is to be expected. The true failure was that there was no monitoring to discover something was wrong, there was no automated tests that failed, and there were very few people who knew enough about how all the components worked together to debug the problem or escalate tickets to the right people (Not entirely evident from that report, but most upload bugs were being bounced between frontend teams who didn't know anything about how uploads work on the backend [not their fault, its not their job to know and nobody can know everything] and operations teams who knew more about the job queue/swift/etc but didn't know that much about MediaWiki file management and didn't really have anyone to ask.). WMF could have a small team dedicated to keeping the lights on and improving robustness for backend multimedia support. It needn't cost 10 million plus, and having a team working on that stuff would mean institutional knowledge is less lost, which would allow for putting together reasonable proposals on where to invest limited resources in this area. Bawolff (talk) 21:38, 31 December 2024 (UTC)[reply]
I wholly agree, but that would just keep the lights on for existing functionality. It does not solve the fundamental issue of large file support, an increased storage demand, hardware encoding and decoding via dedicated gpu's (integrated through kubernetes), adaptive bitrate streaming and all the other many things required for the ever increasing size of video. —TheDJ (talk • contribs) 12:42, 2 January 2025 (UTC)[reply]
@TheDJ: Do you mean reverting the huge overwrite? Should the huge version be moved to a separate filename, or just discarded as unsourced and currently unusable?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:58, 31 December 2024 (UTC)[reply]
Reverting the huge overwrite yes. Only current versions are transcoded, so older versions are straight 4GB to your mobile phone via 3G if you are so unlucky, but people aren't very likely to view the old version of a video. —TheDJ (talk • contribs) 14:01, 31 December 2024 (UTC)[reply]
@D. Benjamin Miller: That was your huge overwrite, do you have an opinion? What was your source for it and how did you process it?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:05, 31 December 2024 (UTC)[reply]
As I say below, the issue is not one of file size, but of glitchy codec support. WMF needs to update to a version of ffmpeg that doesn't choke on AV1 grain synthesis. I figured they would have done so by now, but I have no control over that. This is actually important even for shorter videos (since it causes transcodes to fail for shorter videos too).
Worst comes to worst, I would rather temporarily overwrite this with a manual transcode into AV1 without grain synthesis. This would be a larger file (probably almost 5GB), but this would solve our issue. At the time I uploaded this, the limit was still under 4GB.
I'm not home at my computer where I'd have my own files, but this is my own cut and render of the film. The main source is the Blu-ray, but the credits sequence is at least partly based on another source (since this was edited in the Blu-ray version). Also, I recall that I made the cut frame-conform to the version already on Commons. After cutting it together, I rendered it to this AV1 file using ffmpeg. It's not from an external source. D. Benjamin Miller (talk) 17:14, 31 December 2024 (UTC)[reply]
If the source is the Bluray, the file information and sourcing on the description page should be updated to reflect this. It now pretends to come from the internet archive, and that doesn't seem to be true. —TheDJ (talk • contribs) 12:45, 2 January 2025 (UTC)[reply]
@TheDJ: What is preventing upgrade to the latest ffmpeg?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:30, 31 December 2024 (UTC)[reply]
While i can't say for sure, most likely WMF is using whatever version of ffmpeg that the OS (Debian) they are using ships with. There isn't really a dedicated team responsible for backend multimedia stuff at Wikimedia. Using a different version of ffmpeg (or any software program) than the one shipping with debian requires a bunch of work to test it, make sure it stays up to date, generally be responsible for it, etc. If there is no team volunteering to do the necessary work and be responsible for any unexpected consequences of using a custom version of ffmpeg, than it is not going to happen [This is my personal view, I have no inside knowledge on this, if someone from WMF tells you something different you should ignore me]. Bawolff (talk) 21:08, 31 December 2024 (UTC)[reply]
@Yann: Unrealistic restrictions on memory. Surely, they can provide one machine with enough memory to transcode our biggest videos.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:33, 31 December 2024 (UTC)[reply]
I can't even find who is responsible for that in the WMF with these pompous titles, so pinging some senior management people: @SDeckelmann-WMF, BMueller (WMF), Abittaker (WMF), and ODimitrijevic (WMF): . Please take care of this issue, it is important for Commons, and all Wikimedia projects. Yann (talk) 11:36, 31 December 2024 (UTC)[reply]
No. This is wrong. It has nothing to do with the size of the video. It has to do with the version of ffmpeg used failing to process AV1 correctly. This video uses the grain-related features of AV1. The old version of ffmpeg used by WMF chokes on this because it doesn't properly support the codec. Videos of extremely large size that don't use this codec feature work fine. See phabricator. D. Benjamin Miller (talk) 17:00, 31 December 2024 (UTC)[reply]
@Yann @Jeff G. @TheDJ @C.Suthorn please note this has almost nothing to do with the file's size. Large videos such as File:The Kid (1921).webm which do not use the grain synthesis feature of AV1 work fine. Meanwhile, my test videos of even thirty seconds that use AV1 grain synthesis would fail. The issue is that there is a memory leak in this older version of ffmpeg (it works fine in current versions). It's not that the video files are too big to be processed. D. Benjamin Miller (talk) 17:05, 31 December 2024 (UTC)[reply]
Thanks a lot for this information. Falling to upgrade to the latest version of a free software is even worst that not having servers big enough. :(( Yann (talk) 17:12, 31 December 2024 (UTC)[reply]
I can understand being conservative about updating software for the sake of stability. It's just that this old version of ffmpeg has a bad bug with dealing with this feature of the AV1 codec. There is nothing wrong with the video files themselves.
The best stopgap solution, actually, is for me to re-encode using AV1 without grain synthesis. This will be a little bit worse and/or produce a slightly bigger file, but it will decode properly. D. Benjamin Miller (talk) 17:20, 31 December 2024 (UTC)[reply]
Also, there are a few other videos I uploaded with AV1-GS, and I can re-encode them too. D. Benjamin Miller (talk) 17:27, 31 December 2024 (UTC)[reply]
@D. Benjamin Miller: Yes, please. What advantage(s) is/are provided by grain synthesis?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:28, 31 December 2024 (UTC)[reply]
It's a bit complicated, but the basic idea is that it separates the compression of film grain from the compression of the underlying video. The thing is, a lot of things shot on film have a ton of grain, and the grain is basically random, and, though it being present is desired (you don't want an unrealistically smooth film), the detail of the grain itself does not matter content-wise in the same way the actual image matters. AV1 supports a number of methods for internally separating the grain from the other content, which makes doing a high-quality encode of content shot on film much more efficient. Of course, it is possible to store grain at high quality — look at any Blu-ray — but this normally requires huge file sizes (again, look at any Blu-ray). D. Benjamin Miller (talk) 17:47, 31 December 2024 (UTC)[reply]
@TheDJ @Yann@Jeff G. I uploaded a new re-encode which doesn't use AV1 GS. The file is actually a bit bigger, but of inferior quality. The encodes should work, but the file should be reverted after ffmpeg is updated. D. Benjamin Miller (talk) 03:09, 1 January 2025 (UTC)[reply]
I abhor memory leaks.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:32, 31 December 2024 (UTC)[reply]
Has someone made a bug report about this ? —TheDJ (talk • contribs) 12:32, 2 January 2025 (UTC)[reply]
It was actually reported, it is phab:T357215. If someone wants to experiment with ffmpeg and find a solution, I'm more than willing to adapt the pipeline, but someone will have to invest a couple of hours to find a sustainable change that is smaller than 'update ffmpeg' (I wouldn't be surprised if the issue isn't even in ffmpeg, but in one of its dependencies). —TheDJ (talk • contribs) 14:48, 2 January 2025 (UTC)[reply]
I requested a split: [1]. Yann (talk) 14:44, 31 December 2024 (UTC)[reply]
About this "Commons is not YouTube": No, Commons is NetFlix. At least there is "Wikiflix" created by @Magnus Manske and promoted by the WMF and in at least german Mainstream Media by Manske. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 06:36, 1 January 2025 (UTC)[reply]

December 26

Reindeer symbols

Is there a specific category for reindeer symbols?

Happy christmas, everybody! Smiley.toerist (talk) 10:30, 26 December 2024 (UTC)[reply]

Ha, noticed that last night too when I took the train. The moving snow all over the display was also a nice touch. Multichill (talk) 10:59, 26 December 2024 (UTC)[reply]
Very funny :D. Maybe "reindeers in art" or so? --PantheraLeo1359531 😺 (talk) 16:10, 26 December 2024 (UTC)[reply]
Aw, I was traveling by train during Christmas but somehow I missed this, or maybe the icons didn't appear on my routes?
Reindeers in art is a fitting category but also a very broad one, so I created a category for reindeer icons as well. ReneeWrites (talk) 17:43, 26 December 2024 (UTC)[reply]
The symbol was only visible on the first and second christmas day (25 and 26).Smiley.toerist (talk) 14:41, 1 January 2025 (UTC)[reply]

December 27

Category:Deepin Icon Theme

Category:Deepin Icon Theme contains no subcategories and 11,256 files, which consists of

  1. icons for different file types eg File:Deepin_Icon_Theme_–_vnd.android.package-archive.svg apk
  2. icons for software eg File:Deepin_Icon_Theme_–_deepin-browser_(23).svg
  3. System actions or representations eg File:Deepin_Icon_Theme_–_wireless-40-symbolic_(4).svg

Would it be appropriate to create categories Category:Filetype icons from the Deepin Icon Theme and Category:Software icons from the Deepin Icon Theme? (There exists Category:Filetype_icons_by_theme and Category:Software icons by theme) 999real (talk) 21:19, 27 December 2024 (UTC)[reply]

Offhand sounds reasonable to me. - Jmabel ! talk 02:47, 28 December 2024 (UTC)[reply]
Yes, this sounds very good to me --PantheraLeo1359531 😺 (talk) 16:41, 28 December 2024 (UTC)[reply]

I just looked at this and saw one overpopulated category replaced with three overpopulated categories. What exactly was accomplished here? It's common practice to place navigation templates in categories that size. Since the filenames all begin with "Deepin Icon Theme", I'm not sure that's possible. RadioKAOS / Talk to me, Billy / Transmissions 21:03, 28 December 2024 (UTC)[reply]

I was just looking through this earlier and all the files seem to already be in more specific ones for the set of icons. So I don't see what the point in this whole thing is. Its way pointless to have a single catch all category for a bunch of files that are already subcategorized based on the specific icon set. --Adamant1 (talk) 22:23, 28 December 2024 (UTC)[reply]
I did a lot of categorizing icons of this theme over the last few weeks. But I didn't do all of them and many just by color which I don't think is that useful. 999real (talk) 18:50, 29 December 2024 (UTC)[reply]
Sorry for going ahead with doing the categories. I think the files could be categorized further somewhat like in Category:Silk_icons because there are many icons representing the same subject (just see 80 icons for "application-msword" on the first page of Category:Filetype_icons_from_the_Deepin_Icon_Theme) 999real (talk) 18:48, 29 December 2024 (UTC)[reply]

December 29

Hi. There is a problem with Category:House of Skoropadsky and its related WikiData item. The associated infobox of Category:House of Skoropadsky is broken despite having the data of the related WikiData item changed and reconfigured. Please fix the problem for me. Thank you for hearing me out. OperationSakura6144 (talk) 11:33, 29 December 2024 (UTC)[reply]

@OperationSakura6144: I'm not sure what you mean by "broken", but it seems to more-or-less work now that I've added a Commons sitelink to House of Skoropadsky (Q4422335). --bjh21 (talk) 11:48, 29 December 2024 (UTC)[reply]
Oh, I thought it was unfixable. Thank you, by the way. OperationSakura6144 (talk) 11:51, 29 December 2024 (UTC)[reply]

Paths and Walkways

Hi! Can someone explaine to me the differences between these two categories? Thanks in advance --Lukas Beck (talk) 20:25, 29 December 2024 (UTC)[reply]

The way I've always understood it a path is more informal. Whereas a walkway is usually paved and has a barrier on both sides. Like a walking bridge across a roadway or similar. You wouldn't really call an unpaved back country footpath a walkway though. But its kind of a meaningless distinction in a lot of instances. --Adamant1 (talk) 21:10, 29 December 2024 (UTC)[reply]
I pretty much concur, and there is no sharp line. "Trail" is another word that can overlap both. - Jmabel ! talk 04:52, 30 December 2024 (UTC)[reply]

December 30

Flag of Uzbekistan

At File:Flag of Uzbekistan.svg, there seems to be a dispute over the flag's colours, that may require further effort to resolve at the file's talk page. I post the message here as an uninvolved editor, because the flag is a heavily used image, and the constant tit-fot-tat reverting has a significant impact on the Wikimedia wikis, as well as wikis using InstantCommons. --Minoa (talk) 10:58, 30 December 2024 (UTC)[reply]

As always, the answer to a dispute about colors is that the older version stays where it is, the other version can be put under a different name, and the various Wikipedias are free to use what they will. - Jmabel ! talk 17:19, 30 December 2024 (UTC)[reply]
Well, "always" was a bit much: if there is a strong consensus for one version, "older" doesn't necessarily win the more obvious name just because there are a few dissenters. - Jmabel ! talk 17:20, 30 December 2024 (UTC)[reply]

Bayeux Tapestry

New Bayeux Tapestry website attempts to assert rights over high-res images of this 11th century work, via a "shrinkwrap" terms of use agreement.

Any commercial use of this tool is prohibited, as well as the extraction of images from this panorama.

Thoughts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:40, 30 December 2024 (UTC)[reply]

They might have a case under a EULA, but not copyright. - Jmabel ! talk 17:17, 30 December 2024 (UTC)[reply]
They are located in an EU country. The EU has banned copyright claims on public domain works with the Directive on Copyright in the Digital Single Market (Article 14) in 2019. -- Herbert Ortner (talk) 19:59, 30 December 2024 (UTC)[reply]

Need help with a non-legitimate deletion

Hello everyone, Last October, I helped the new Commons user @erictétreault upload files to illustrate the article CHAA-FM on Wikipedia. However, the user @lachuckthebuck made several deletion requests even though these files are perfectly legitimate.

https://commons.m.wikimedia.org/w/index.php?title=Commons:Deletion_requests/Files_uploaded_by_Eric_T%C3%A9treault&oldid=959165942

The user Éric Tétreault owns the rights and the photos and logos are absolutely not advertisements.

Is there anything we haven't done right with these files, and how can we get them back into Wikimedia Commons?

Thanks alot! JBouchez (talk) 19:01, 30 December 2024 (UTC)[reply]

@JBouchez: You can file an undeletion request for these files at COM:UNDEL ReneeWrites (talk) 20:31, 30 December 2024 (UTC)[reply]
@JBouchez and Eric Tétreault: The correct person to write about is Alachuckthebuck. Once the copyright holder sends sufficient believable permission via VRT relevant to Ticket:2024101610011822, the files will be restored. Evidently, what was received so far was not sufficient and believable.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:17, 31 December 2024 (UTC)[reply]
Hello @Jeff G.,
Thanks for your quick follow up on this topic.
Regarding the process via VRT, what would be a sufficient believable permission? Are there documentation to help us understand what is required?
Thanks alot. JBouchez (talk) 16:01, 31 December 2024 (UTC)[reply]
@JBouchez: Assuming for the moment that Eric Tétreault is the person in charge of that station, and that the station has an internet domain, email from an email system connected to the station's domain should suffice. Alternatively, if no such email system exists, email from an official address referred to on their website or social media (or referral to that ticket on such website or social media) should also suffice. Answering any followon queries is mandatory, or the ticket stays in resolved status with the files still deleted. Good luck.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:22, 31 December 2024 (UTC)[reply]
I see!
I do believe he owns a professional email address linked with the radio station, but I'm not sure if he used it when answering to the request. I'll contact him and check everything. I better understand the process now.
Thanks alot for your great help! JBouchez (talk) 17:05, 31 December 2024 (UTC)[reply]
| link to prior dicussion on my talk page. . Sorry I missed this, thanks for the ping @Jeff G., You covered all the points here. Unfortunately, I am not a VRT agent, so I can't handle the request. All the Best -- Chuck Talk 20:19, 1 January 2025 (UTC)[reply]
JBouchez, we received the mail and the permission was not sufficient. Eric was instructed on how to send permission in the response by an agent but we've received no reply so far. Consider using COM:RELGEN which will make it easier to generate a permission release statement and then send it to VRT. Ratekreel (talk) 22:23, 1 January 2025 (UTC)[reply]
Thanks alot for your follow up. I sent an email to Éric Tétreault to explain what he has to do, via COM:RELGEN. He will start with one file (the official logo of the radio station) and he will use his admin email to answer to someone from the VRT project. He is absolutely not used to that (I'm not as well), he created his Wikipedia account a couple of months ago. JBouchez (talk) 18:56, 2 January 2025 (UTC)[reply]

December 31

A healthy new year!

Hi! I just wanted to wish you all a healthy and beautiful new year with a firm drive. And I would like to thank for all the help! :) --PantheraLeo1359531 😺 (talk) 13:46, 31 December 2024 (UTC)[reply]

@PantheraLeo1359531: You too!   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:23, 31 December 2024 (UTC)[reply]
Happy New Year to everybody! A quarter of the century is over. A century that is being recorded real-time in Wikipedia and its sister projects, including Commons, with everything freely available to everyone. In 1999, I couldn't even dream this would be so, much less that I would be contributing a (very tiny) part of it. MGeog2022 (talk) 12:58, 1 January 2025 (UTC)[reply]
Indeed! More is yet to come. But there is still left to be recorded and archived :) --PantheraLeo1359531 😺 (talk) 12:30, 2 January 2025 (UTC)[reply]

January 01

Commons Gazette 2025-01

Happy New Year! Happy Public Domain Day!

Volunteer staff changes

In December 2024, 2 sysops were elected; 1 sysop was removed. Currently, there are 181 sysops.

Election:

Removal:

  1. ↑ en:Wikipedia:Deceased_Wikipedians/2024#JarrahTree

Edited by Abzeronow and RoyZuo.

Commons Gazette is a monthly newsletter of the latest important news about Wikimedia Commons, edited by volunteers. You can also help with editing!

--RoyZuo (talk) 23:35, 1 January 2025 (UTC)[reply]

January 02

Mirroring request

See the billboard behind the U and the BBVA building to the right

Hi, where can I post a mirroring request for File:3D bUENOS aIRES - jUL 2019.jpg?

RotationBot offers no mirroring and I cant't find anything in Category:Gadget scripts → bertux 15:14, 2 January 2025 (UTC)[reply]

As the image is in use by two Wikipedias that might prefer the current version I´d rather recommend to keep it unmirrored and to upload a new version under a different file name. --Rudolph Buch (talk) 15:19, 2 January 2025 (UTC)[reply]
Thanks! The question is still: where can I get the mirroring done? We are discouraged from rotating with a photo editor; is mirroring always lossless? → bertux 16:25, 2 January 2025 (UTC)[reply]
I'd just flip it with GIMP. It's not like this was some gem of high-res photography. - Jmabel ! talk 18:39, 2 January 2025 (UTC)[reply]

Discrepancy

On File:CDGexpSchema.jpg, this message appeared "There is a discrepancy of 1815 meters between the above coordinates and the ones stored at SDC (49°0′36″N 2°32′53″E, precision: 11 m). Please reconcile them."

On this file the coodinates are the terminal of a train, perhaps the bot refers to the airport itself. How to reconcile that ? --Io Herodotus (talk) 20:19, 2 January 2025 (UTC)[reply]

Both should use a point roughly at the centre of the line. SDC has separate properties for the coordinates of the end points. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:55, 2 January 2025 (UTC)[reply]
I'm not sure if I understand you. What line are you talking about ? At the moment there is no link between this file and the airport. Io Herodotus (talk) 23:04, 2 January 2025 (UTC)[reply]
Revert the bot, it should come back and fix the SDC. In principle, there is interface for fixing the coordinates in SDC manually, but I did not figure out how to use it, for me the "save" button is not clickable. Reverting the bot is easier. Ymblanter (talk) 12:45, 3 January 2025 (UTC)[reply]
Apparently this bot is looking for airport data? Why and how is it doing this? Io Herodotus (talk) 14:14, 3 January 2025 (UTC)[reply]
To be honest, I do not understand which data the boot took. @Schlurcher and Multichill: can one of you explain this to us please? Ymblanter (talk) 16:11, 3 January 2025 (UTC)[reply]
A map with a camera location????
@Ymblanter: In this case the map seems to be using {{Location}} which seems quite incorrect. Multichill (talk) 21:20, 3 January 2025 (UTC)[reply]
I see, thanks. Ymblanter (talk) 21:35, 3 January 2025 (UTC)[reply]

January 03

To-do list created

Per a comment at phab:, I have created Commons:Very large files to upload (COM:2UPLOAD, COM:VLF) to keep a running list of files that could be uploaded here were it not for technical limitations on file sizes. I did search ahead of time but did not see any other such list. Pardon me if I duplicated efforts. Thanks. —Justin (koavf)❤T☮C☺M☯ 08:02, 3 January 2025 (UTC)[reply]

I don't think storing such large files for mundane things where resolution is not important even if it wasn't mundane makes much sense. Thus, I already oppose the large file-size of those videos without being merged and think their size should be reduced and people asked to upload smaller-sized videos for such things where the current file-size limit now seems more reasonable seeing what people would upload if the limit was larger. I'm not referring to the "The Black Watch" film but the other files linked on that page. Prototyperspective (talk) 09:58, 3 January 2025 (UTC)[reply]
Agreed. Especially for files like File:CSD Hamburg 2022 001 part 1 of 26.webm - the solution for these video files is to downscale them to a more reasonable resolution and upload that. Hardware which can play back and display 8k (at ~140 Mbps!) video is essentially nonexistent, and Wikimedia's video transcoding services would probably choke on a single file of that size. (As it stands, some of these segments consumed over 24 hours of CPU time to transcode to other formats - for less than five minutes of video which isn't even referenced from any content pages.) Omphalographer (talk) 23:32, 3 January 2025 (UTC)[reply]

January 04

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