Commons:Village pump

From Wikimedia Commons, the free media repository
(Redirected from Commons:Village Pump)
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 36 8 Ymblanter 2025-01-04 19:09
2 Video transcoding maintenance in File:Night of the Living Dead (1968).webm 34 7 TheDJ 2025-01-02 14:48
3 Reindeer symbols 5 4 Smiley.toerist 2025-01-01 14:41
4 Category:Deepin Icon Theme 7 5 999real 2024-12-29 18:50
5 There is a problem with Category:House of Skoropadsky and its related WikiData item. 3 2 OperationSakura6144 2024-12-29 11:51
6 Paths and Walkways 3 3 Jmabel 2024-12-30 04:52
7 Flag of Uzbekistan 3 2 Jmabel 2024-12-30 17:20
8 Bayeux Tapestry 3 3 Herbert Ortner 2024-12-30 19:59
9 Need help with a non-legitimate deletion 9 5 JBouchez 2025-01-02 18:56
10 A healthy new year! 4 3 PantheraLeo1359531 2025-01-02 12:30
11 Commons Gazette 2025-01 1 1 RoyZuo 2025-01-01 23:35
12 Mirroring request 6 4 Bertux 2025-01-04 22:11
13 Discrepancy 10 5 Ymblanter 2025-01-04 19:08
14 To-do list created 5 4 Omphalographer 2025-01-04 21:52
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.
People of Ngadisan (Java, Indonesia) are filling their cans at the village pump. The old well is defunct and replaced by a water tap. [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 19

Syrian flag

Abzeronow has noted that several sister projects have decided to treat File:Flag of the Syrian revolution.svg, not the existing File:Flag of Syria.svg, as the current flag of Syria. The following are all in agreement, either by discussion or simply by content change:

English Wikipedia: en:Talk:Syria#RfC: Flag? closed as B, Syrian revolutionary flag and en:Flag of Syria shows it.
French Wikipedia: fr:Drapeau de la Syrie.
Arabic Wikipedia: ar: علم_سوريا
German Wikipedia: de:Flagge Syriens
Italian Wikipedia: it:Bandiera della Siria
Spanish Wikipedia: es:Bandera de Siria
Russian Wikipedia: ru:Флаг Сирии

Abzeronow originally proposed one solution for Commons, but Rudolph Buch has suggested several alternatives, and I have a different idea of my own, and I want to make sure we have at least a strong consensus before moving files. Proposals C, D, and E all come from Rudolph Buch; I've done my best not to alter any of his meaning but you can check [1] to verify that. Keep in mind that due to templating, there are many templates on various wikis that will necessarily use File:Flag of Syria.svg.

A) (Abzeronow's original proposal): File:Flag of Syria.svg should be moved to File:Flag of the United Arab Republic (1958–1971), Flag of Syria (1980–2024).svg and File:Flag of the Syrian revolution.svg should be moved to File:Flag of Syria.svg.
B) (Jmabel's variant on that): as in proposal A, the current content of File:Flag of Syria.svg should be moved to File:Flag of the United Arab Republic (1958–1971), Flag of Syria (1980–2024).svg. Unlike proposal A, File:Flag of Syria.svg should then become a redirect to File:Flag of the Syrian revolution.svg (rather than vice versa). This has the advantage that if the new state settles on a different flag, all we have to do is change a redirect (and possibly upload a new flag if they were to adopt something brand new).
C) Do nothing and to trust the wiki editors in updating their pages.
D) Rename File:Flag of Syria.svg to File:Flag of Syria (1980).svg without leaving a redirect. This will lead to a huge amount of broken image links (which is bad) but prompt the editors to check what flag is right for the respective page (which is good).
E) let a bot replace File:Flag of Syria.svg by File:Flag of the Syrian revolution.svg at all wiki pages. [If I understand correctly, this means to bot-edit all of the sister projects, rather than change anything at Commons. @Rudolph Buch, please let me know if that is not what you meant.]

I believe the following remark from Rudolph Buch sums up his objection to proposal A (and presumably to proposal B): "Would that automatically feed the new flag into ~500 Wikipedia pages regardless of context and caption? Like when File:Flag of Syria.svg is now used to illustrate that this is the flag that was adopted in 1980 and after the move it shows the 2024 flag without hint in the page history or any other warning to the Wikipedia editors?" User:The Squirrel Conspiracy replied to that (in part), "Correct. However the projects have backed themselves into a weird corner because there's also templates that - instead of asking for an image - automatically pull the file with the name "Flag of [country name].svg" - and those would have the wrong image if we don't move it."

Jmabel ! talk 01:06, 19 December 2024 (UTC)[reply]

Further thought: in both proposal A and proposal B, if we allow "Move and replace" to take place when we move File:Flag of Syria.svg to Flag of the United Arab Republic (1958–1971), Flag of Syria (1980–2024).svg, that will change all explicit uses of File:Flag of Syria.svg in sister projects to use the new name, which will show up in the relevant page histories, watchlists, etc. It will not affect those pages where a template generates "[[:File:Flag of Syria.svg]]. In contrast, proposal E is likely to change exactly the uses that specifically meant this particular flag, while not solving the issue for template uses, and proposal D will break all the template usages. So 'my own "ranked choices" would be B, A, C, while definitely opposing D or E. - Jmabel ! talk 01:28, 19 December 2024 (UTC)[reply]
I'd be fine with B if we know it won't break any templates so for me I'd favor A or B* (*providing it doesn't break templates) over C. I also would oppose D because it breaks pages and would be out of harmony with variants (which is why I proposed the name I did, it stays in harmony with variants). I also would oppose E since it could break templates. Abzeronow (talk) 17:15, 19 December 2024 (UTC)[reply]
I am for A or B, and oppose E. On Swedish Wikipedia, most of the intentional uses of the old flag are now linked to Flag of the United Arab Republic (1958–1971), Flag of Syria (1980–2024) (stars variant 2).svg, and if links to File:Flag of Syria.svg gives the new flag, not much more needs to be done. JohanahoJ (talk) 11:29, 22 December 2024 (UTC)[reply]
A or B sounds best. איז「Ysa」 • For love letters and other notes 14:36, 22 December 2024 (UTC)[reply]

I am going with "B". Abzeronow, the original proposer says he is fine with it. I think it works best. No one else seems to be saying Rudolph Buch's approaches are better. - Jmabel ! talk 18:23, 22 December 2024 (UTC)[reply]

Made the moves, but the "replaces" apparently did not work as I wished. It looks like there were a lot of uses of things like {{Flag entry|Width=200|Image=Flag of Syria.svg|Caption=Syria}} even for things that were about a specific year. Not a great choice. I think there is a ton of hand work to do, no matter what.
I'll do my best to take this on, starting with Commons itself, then en-wiki. If someone wants to help on some other wiki, please say so here and have at it. - Jmabel ! talk 18:39, 22 December 2024 (UTC)[reply]
@Abzeronow: are you sure about that Commons Delinker command you just gave? I'm going through these by hand, and seeing some I don't think should be changed, although admittedly the bulk of them should. - Jmabel ! talk 20:03, 22 December 2024 (UTC)[reply]
@Jmabel: If you want me to remove the command, I will (since I'm willing to let the redirect stay). Abzeronow (talk) 20:12, 22 December 2024 (UTC)[reply]
I think it probably should be removed. I'm finding it runs about 60% should change, 20% certainly shouldn't, and an awful lot of tricky judgment calls where I am trying to leave messages for more appropriate people to decide. - Jmabel ! talk 20:19, 22 December 2024 (UTC)[reply]
@Abzeronow: I'm finding more and more that should not change. Yes, we should definitely remove the command. In fact, since you said you are OK with that, I'll do it. - Jmabel ! talk 20:23, 22 December 2024 (UTC)[reply]
OK, I removed mine after you had removed yours. Abzeronow (talk) 20:30, 22 December 2024 (UTC)[reply]
Now that I have a larger sample: at the early time of my remark above, I just happened to hit a bunch that should change. I've looked at maybe 1500 pages now, and less than a hundred specifically wanted the Assad-era flag. So (1) this is overwhelmingly correct as it is and (2) there is still going to be a lot of hand-correction in a lot of wikis, way more than I personally can do. - Jmabel ! talk 22:37, 22 December 2024 (UTC)[reply]

I have left this note at en-wiki. Similar notes on other wikis would be useful. ar-wiki would be a priority, and I don't read, write, or speak Arabic. - Jmabel ! talk 23:45, 22 December 2024 (UTC)[reply]

@Mohammed Qays: regarding ar-wiki since they could help with this there. Abzeronow (talk) 02:30, 23 December 2024 (UTC)[reply]
@Abzeronow I'm ready to help, In the Arabic Wikipedia[2], there is a discussion on the subject and I will write a note about it.  Mohammed Qays  🗣 19:55, 23 December 2024 (UTC)[reply]

My edit has just been reverted without discussion. I have contacted User:Ericliu1912 who did this (he is an admin on zh-wiki, but not here on Commons). - Jmabel ! talk 05:01, 24 December 2024 (UTC)[reply]

I'm not opposed to the proposal itself (in fact I do support it!), but the point is we should first clean up old usage of the flag, and then change the redirects, since this is a national flag widely used on all wikis. The issue was brought to me by members of the local community finding lots of articles showing historically erroneous Syria flags, which could not be instantly changed at once, and need time or outside assistance (e.g. global replace tool) for doing so. —— Eric Liu（Talk） 05:07, 24 December 2024 (UTC)[reply]
@Ericliu1912: Based on my experience so far in cleaning up several hundred of these in en-wiki, it is going to be very hard to identify what needs to be cleaned up if we don't make the change first. How do you propose to identify the places that are affected? - Jmabel ! talk 05:11, 24 December 2024 (UTC)[reply]
@Jmabel: If a consensus has been reached, I suggest we update Template:Country data Syria in every wikis first, adding a 1980 variant to the templates. —— Eric Liu（Talk） 05:15, 24 December 2024 (UTC)[reply]
And is it possible to have a one-time global replace done, replacing all non-Country data usage of "File:Flag_of_Syria.svg" with "File:Flag_of_Syria_(1980–2024).svg"? I guess that would ultimately do the job. —— Eric Liu（Talk） 05:18, 24 December 2024 (UTC)[reply]
@Ericliu1912: No, that would definitely not do the job. It's a long story, some of which is above. I want to give you this quick reply now, because explaining in detail will take 15+ minutes. I'll write out the more complicated picture and then post that. - Jmabel ! talk 05:27, 24 December 2024 (UTC)[reply]
@Ericliu1912: one other quick thought before I start that: any idea how we get word out that the template needs to be changed to handle this? - Jmabel ! talk 05:31, 24 December 2024 (UTC)[reply]
I guess it is appropriate that we leave notes to the communities using Country data Syria templates on their Village Pump respectly. —— Eric Liu（Talk） 05:39, 24 December 2024 (UTC)[reply]
But I wonder why it'd not work? As all direct (non-Country data) global usage of "File:Flag_of_Syria.svg" currently were indeed just "File:Flag_of_Syria_(1980–2024).svg", the replacement should mostly be smooth and sufficient. Even is it not enough in some cases like certain template wrap usage, we could still go ahead and replace most of the current links first, that should also decrease the burden for the remaining manual changes. —— Eric Liu（Talk） 05:41, 24 December 2024 (UTC)[reply]

@Ericliu1912: Why a global search-and-replace is a bad idea here (and also almost impossible to do in an effective manner):

  1. Many—I strongly suspect most—of the places where the Syrian flag is used should switch to the new flag. The following is a representative set of examples, though certainly not exhaustive.
    • All geographical articles should be using the current flag, not the flag of a prior regime.
    • There are presumably a lot of templates in Category:Templates related to Syria that use a flag. Those should all use the current flag, not the flag of a prior regime.
    • Any infoboxes related to geography that contain a flag should all use the current flag, not the flag of a prior regime.
    • As far as I'm aware, the new government of Syria, presuming it is widely recognized, which appears to be happening, will inherit (or already has inherited) all of Syria's positions in international organizations, e.g. the UN and its various affliates, the organization of non-aligned states, status as a signatory of various treaties unless the new government were to renounce those. All of those should update to the current flag.
  2. If you think about how flag files are used, search-and-replace is very tricky. They are almost never used in a syntax that writes out File:Flag of Syria.svg in the wikitext. For example, there are templates that effectively do File:Flag of [COUNTRY].svg, or that get at these other ways. If that's not clear, I'll elaborate; I'm trying to get you a response quickly, so I'm not approaching this at essay length.

Also: when the template is updated, if there is anything that should permanently use the current revolutionary flag regardless of future regime changes, there should be a way to specify that, too. Let's not get caught in the same thing again! (en-wiki has already done this.) - Jmabel ! talk 05:50, 24 December 2024 (UTC)[reply]

I understand the difficulties, so I suggest that we at least (1) replace direct file links and update about ~110 Country data Syria templates (which is the most obvious and widely-used template), adding a "1980" alias for them (and maybe an "opposition/revolution" alias too, just in cases which do "permanently use the current revolutionary flag"); (2) list the rest of the templates that indeed embed File:Flag of Syria.svg (in a historical context) and try to do the replacement; (3) regretfully ignore the rest like File:Flag of [COUNTRY].svg you mentioned above and change the redirect to the opposition flag, at the same time also notifying the communites, reminding them to finish rest of the work. —— Eric Liu（Talk） 06:05, 24 December 2024 (UTC)[reply]
@Ericliu1912: In my experience (mainly Commons and en-wiki) there is very little correlation between how the file was used (in a technical sense) and why it was used (to refer to a regime or a country). I think each wiki is going to have to work out for itself what is right for how usage is shaped on that wiki. No matter how we do this, there is going to be a LOT of hand-work, because neither case ("it meant the country" or "it meant the regime") is clearly dominant. This isn't going to be an 80-20 case, it's more in the range of 60-40. My personal guess is that more cases mean country than regime, but (on en-wiki, at least, which I'm guessing is typical of the Wikipedias in this respect) it's not dramatically more.
The more a given Wikipedia covers events relative to how much it covers geography, the more often it will mean a regime. But right now it is totally jumbled together.
This suggests a large area in which we have not at all future-proofed (for the hundreds of other countries in the world). Wikipedia wasn't around in 1989-1992, or we would have recognized this as a potentially major issue up front when we designed flag-related templates. - Jmabel ! talk 06:16, 24 December 2024 (UTC)[reply]
Which is to say, among other things: be cautious about replacing direct file links, they might have either meaning. - Jmabel ! talk 06:18, 24 December 2024 (UTC)[reply]
We certainly agree on the need to update the Country data Syria templates, though. - Jmabel ! talk 06:20, 24 December 2024 (UTC)[reply]

I've done my best to update Template:Country data Syria here on Commons (also to add some redirects that it incorrectly presumed would exist). It would be greatly appreciated if someone would check my work. - Jmabel ! talk 06:37, 24 December 2024 (UTC)[reply]

I believe I've successfully gotten the word out to the English, Spanish and Romanian Wikipedias, and I presume Ericliu1912 is driving this on the Chinese Wikipedia, but does anyone have a way to spread the word more broadly? - Jmabel ! talk 02:32, 25 December 2024 (UTC)[reply]

Please note the discussion at Commons:Deletion requests/File:Flag of Syria (2024).svg.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:26, 25 December 2024 (UTC)[reply]

Getting word out to sister projects

Again: is there some way to get word out to a large number of the sister projects? - Jmabel ! talk 02:48, 28 December 2024 (UTC)[reply]

This went stale and was archived; I've brought it back, because this still needs to reach a resolution. - Jmabel ! talk 06:25, 4 January 2025 (UTC)[reply]

The only way I can think of is the central notice, but I can not imagine WMF agreeing to this. Ymblanter (talk) 19:09, 4 January 2025 (UTC)[reply]

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: [3]. 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]
Isn't this what {{Flopped}} is for? Thuresson (talk) 12:14, 4 January 2025 (UTC)[reply]
Thanks! Applied. Also removed the photo from article space in eswiki and nlwiki as there are plenty of better alternatives available for es:Letrero gigante de ciudad and nl:Lettermonument → bertux 22:11, 4 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]
Updating the coordinates manually in the Structured Data tab works for me, but depends on the internet browser: Firefox no, Edge yes. Has not been fixed for a very long time now... --HyperGaruda (talk) 11:19, 4 January 2025 (UTC)[reply]
I have indeed Firefox. Ymblanter (talk) 19:08, 4 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]
140 Mbps for 8K is actually rather low (Video cameras can take 8K with 400 Mbps, 600 Mbps or more), and there are many hardware products which are able to play files with these bitrates (I tested back in 2019 with an RTX 2080; the bitrate alone is not enough; it also plays a role what type of chroma subsampling, bit-depth, frame rate, color space and more it uses (4:0:0 or 4:4:4)). Furthermore, I assume that the device that captured in 8K is not able to catch that much details 8K would be able to --PantheraLeo1359531 😺 (talk) 19:25, 4 January 2025 (UTC)[reply]
What I mean is that almost nobody has an 8K display to watch it on - even if you have a 4K monitor and you're viewing this video full screen (which, realistically, most users won't do), it's still being scaled down by 50%. Omphalographer (talk) 21:52, 4 January 2025 (UTC)[reply]

January 05

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