Commons:Village pump

From Wikimedia Commons, the free media repository
(Redirected from 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 38 9 Rudolph Buch 2025-01-06 02:02
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 Need help with a non-legitimate deletion 9 5 JBouchez 2025-01-02 18:56
5 A healthy new year! 4 3 PantheraLeo1359531 2025-01-02 12:30
6 Commons Gazette 2025-01 1 1 RoyZuo 2025-01-01 23:35
7 Mirroring request 6 4 Bertux 2025-01-04 22:11
8 Discrepancy 10 5 Ymblanter 2025-01-04 19:08
9 To-do list created 9 5 PantheraLeo1359531 2025-01-06 16:27
10 Importing files from de-wikipedia 6 5 Rosenzweig 2025-01-06 04:55
11 Would this picture dated to 1954 have copyright under URAA? 3 3 Ymblanter 2025-01-05 18:40
12 No thumbnail 3 2 ReneeWrites 2025-01-06 02:14
13 Category:Deletion requests/pending 4 3 GPSLeo 2025-01-07 10:12
14 License change at source 2 2 Jmabel 2025-01-06 18:30
15 How can Category:Gallery pages with a wrong format be removed from Help:Biology wikidata glossary? 4 2 JopkeB 2025-01-07 05:51
16 Magic word for SDC date of creation 3 2 トトト 2025-01-06 22:49
17 Upcoming Commons conversation about tool investment priority on January 15 1 1 Sannita (WMF) 2025-01-06 14:56
18 FIDE logo 2 2 Glrx 2025-01-06 21:24
19 Wikidata Infobox 2 2 Jeff G. 2025-01-07 11:01
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]
So what do we do? At some point we clearly need to have File:Flag of Syria.svg redirect to the current flag of Syria, and if we can't inform other wikis in advance, someone is going to feel blindsided, just like zh-wiki appears to have felt first time around. - Jmabel ! talk 00:43, 6 January 2025 (UTC)[reply]
What about Global Message Delivery via the MassMessage function? This seems to have a lower threshold than Central Notice, as it just writes a message in the village pumps of all local wikis and doesn´t include banners. (Sorry if this is a dumb suggestion, I´m not savy with technical things). Rudolph Buch (talk) 02:02, 6 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 29

December 30

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]
Not necessarily. The internal resolution can be set to be 8K, and an original 8K video is played as such (so the whole bitstream must be decoded), but only screen output itself would be in 4K. The rendering process is not smaller --PantheraLeo1359531 😺 (talk) 13:01, 5 January 2025 (UTC)[reply]
I don't see the point of uploading 8K for news type videos. I could find it useful for content where we can zoom in (i.e. scientific, etc.), but a street parade? Yann (talk) 17:35, 5 January 2025 (UTC)[reply]
It has the same utility as uncompressed TIFF images or WAV audio that has frequencies that literally can't be heard. 8K video is not really useful for my purposes, but if someone is projecting a video on the side of a building, that's handy. If we think the content of a piece of media is valid, then the highest quality of that file seems obviously useful to me, particularly since the servers create downgraded versions of thumbnails and videos that can be used in cases where extremely high quality is not needed. —Justin (koavf)❤T☮C☺M☯ 17:52, 5 January 2025 (UTC)[reply]
I think using modern codecs like AV01 could reduce 8K videos a lot in filesize and preserving the higher quality, but it could take some time until this is mainstream procedure --PantheraLeo1359531 😺 (talk) 16:27, 6 January 2025 (UTC)[reply]

January 05

Importing files from de-wikipedia

On the German-language Wikipedia there arfe two files (de:Datei:Boskop-Schädel.jpg and de:Datei:Boskop-Schädel (2).jpg) which the German page says should be checked before transfer. However, they were published in the US before 1918 and should therefore be free. But commons file importer does not want to do this, saying "This file cannot be imported to Wikimedia Commons because it is marked as Vorlage:NoCommons." Joostik (talk) 11:44, 5 January 2025 (UTC)[reply]

@Joostik: Good to know that the file importer works as designed. Why are you stating that here? Or do you have a question? Questions usually end with a question mark.
The date of publication is 1918 so well before the URAA date (1930 now) and author died more than 70 years ago so should be ok to transfer. Multichill (talk) 12:32, 5 January 2025 (UTC)[reply]
@Gerbil: You tagged each file {{Bild-PD-alt}} using de:Vorlage:Bild-PD-alt, which indicates (translated from German): "Due to URAA problem(disk.) for the time being:", "This file may not with the policies of Wikimedia Commons.", "It should be checked individually whether it may be moved to Wikimedia Commons.", and "Do not transfer this file to Wikimedia Commons without an individual review!". Is there a more appropriate tag?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:14, 5 January 2025 (UTC)[reply]

The license I used is specified in the rules of the German-language Wikipedia for “old works”, see: https://de.wikipedia.org/wiki/Wikipedia:Bildrechte#Alte_Werke According to German law, both drawings are in the public domain 70 years after the death of the artist. However, I am not familiar with image licenses and will therefore not make any changes. Sorry. Gerbil (talk) 15:08, 5 January 2025 (UTC)[reply]

@Gerbil: Thanks. Perhaps other users of German Wikipedia will weigh in.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:01, 5 January 2025 (UTC)[reply]
I have transferred both files to Wikimedia Commons, same file names. You have to tweak the license tag at de.wp first (using the parameter Commons=Ja) to be able to do this. --Rosenzweig τ 04:55, 6 January 2025 (UTC)[reply]

I want to upload this photo of Dap Chhoun to Commons. It was taken at the Geneva Conventions in 1954, seems to be PD in Switzerland and Cambodia. I still don't really understand URAA, so a simple explanation won't hurt. — Preceding unsigned comment added by TansoShoshen (talk • contribs) 12:40, 5 January 2025 (UTC)[reply]

It is not clear where the image was published first. Ruslik (talk) 13:16, 5 January 2025 (UTC)[reply]
Not sure what you meant here, if you meant where the image was sourced, reverse image search points to this image being used on this website and this random Facebook post.
If you meant the country where the image was first released to the public, then yeah, it's unclear. However, it's probably either France or Switzerland, but I can't find a definite answer. TansoShoshen (talk) 17:05, 5 January 2025 (UTC)[reply]
Most likely, the URAA makes in unfree until 2050. Ymblanter (talk) 18:40, 5 January 2025 (UTC)[reply]

January 06

No thumbnail

Any idea why File:Vittore Carpaccio - la vie et l'uvre du peintre (1910) (14596474918).jpg won't generate a thumbnail? Underlying file looks fine. - Jmabel ! talk 00:41, 6 January 2025 (UTC)[reply]

File:Art Safari 2024 at the Dacia Building, Bucharest - 05.jpg, too, and I know that used to work. - Jmabel ! talk 02:11, 6 January 2025 (UTC)[reply]

@Jmabel: Both files work for me. I think there's currently a bug with thumbnail generation on Commons, though. I ran into a similar problem with a number of files I've uploaded which I requested a speedy deletion for. I suspect the files looked fine to The Squirrel Conspiracy, who left a message on my talk page about it. ReneeWrites (talk) 02:14, 6 January 2025 (UTC)[reply]

Category:Deletion requests/pending

Is there a reason why we dont use a bot to automate the categorizing of the subcategories? Trade (talk) 03:47, 6 January 2025 (UTC)[reply]

Probably as much as anything, no one having defined the rules by which a bot would know what is needed. If it can be simply described, and you can describe it, then a bot might be in order. - Jmabel ! talk 06:33, 6 January 2025 (UTC)[reply]
Something as simple as "If the images in the category are deleted after the discussion have been closed, move the page to the /deleted category and remove it from the pending category. Trade (talk) 08:25, 7 January 2025 (UTC)[reply]
As everything in the deletion request is only in Wikitext a bot needs to parse the Wikitext and needs check for the deletion status of the linked pages. It is not that simple to build such a bot that does this without many errors. GPSLeo (talk) 10:12, 7 January 2025 (UTC)[reply]

License change at source

I've incidentally found this image (File:Mendebaldeko Sahararen aldeko Iruñeko elkarretaratzea 2020 2.jpg) with a license-review template. It was uploaded on 1 December 2020. I've checked the source and it says "CC BY-NC-SA 4.0". In Wayback-Machine, as of 3 December 2020 license was CC BY-SA 3.0 though (but I can not see every image there, only 2 of them). Is it reasonable assuming good practice, this image being properly uploaded? Do we have a templates in order to register this license incidents? Strakhov (talk) 12:38, 6 January 2025 (UTC)[reply]

If it's OK in Wayback Machine, you can approve it and link the Internet Archive page in the permissions and/or the edit summary. I'm not sure what to do about the pages that don't show up there, though. - Jmabel ! talk 18:30, 6 January 2025 (UTC)[reply]

How can Category:Gallery pages with a wrong format be removed from Help:Biology wikidata glossary?

How can Category:Gallery pages with a wrong format be removed from Help:Biology wikidata glossary as a parent? The format is OK now (User:Prototyperspective have moved it to the Help format) and he already removed this parent category, but it still is popping up. JopkeB (talk) 12:41, 6 January 2025 (UTC)[reply]

@JopkeB: it is presumably on one or more of the pages that are included there in their entirety, all of which are still in gallery space. - Jmabel ! talk 18:32, 6 January 2025 (UTC)[reply]
Thanks @Jmabel: . I renamed Biology wikidata glossary/Double Taxonomic Wikidata Items, and gave a Hard purge to Help:Biology wikidata glossary and now it is gone. Problem solved. JopkeB (talk) 05:50, 7 January 2025 (UTC)[reply]
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. --JopkeB (talk) 05:51, 7 January 2025 (UTC)

Magic word for SDC date of creation

Isn't there a magic word for SDC date of creation? If such thing exists, I don't have to input the date manually in an edit like this. In this case, I had to copy 2011-04 of the date field and paste it in {{Japanc|so|2011-04}}, which is quite tiresome. --トトト (talk) 13:42, 6 January 2025 (UTC)[reply]

@トトト: If "inception" property is present in SDC, and you leave the date blank, then {{Information}} will use the value in the "inception" property. However, that won't give you any Japan-related date category. - Jmabel ! talk 18:40, 6 January 2025 (UTC)[reply]

Upcoming Commons conversation about tool investment priority on January 15

Hello everyone! The Wikimedia Foundation will be hosting the third round of a series of community calls to help prioritize support efforts from Wikimedia Foundation for the 2025-2026 Fiscal Year.

The purpose of these calls is to support community members in hearing more from one another - across uploaders, moderators, GLAM enthusiasts, tool and bot makers, etc. - about the future of Commons. There is so much to discuss about the general direction of the project, and we hope that people from different perspectives can think through some of the tradeoffs that will shape Commons going forward.

Our third call will focus on tool investment priority. There are constant calls from the community for the Foundation to adopt community-made tools in order to maintain workflows for the contributors that depend on them. The range of these tools varies widely, and includes media upload (e.g. Video2Commons), editing (e.g. CropTool), curation (e.g. Cat-a-lot) and metrics (e.g. BaGLAMa) tools. Batch upload and metrics tools are said to be critical for the affiliates and Wikimedians in Residence who partner with libraries and other cultural institutions to illustrate Wikipedia. They need to be able to contribute files efficiently at scale, and report on the impact of these contributions. However, community surveys have identified more than 30 different tools that are used for content partnerships.

More specifically the questions will be:

  1. Does it make sense for the Foundation to invest in supporting the wide range of community-developed tools that don’t have active maintainers, or should a smaller set of critical workflows be enabled through new or improved features in core products?
  2. Which tool would you recommend to prioritise? Something community-facing or GLAM-facing or video-related or something else?

The call will take place at two different time slots:

If you cannot attend the meeting, you are invited to express your point of view at any time you want on the Commons community calls talk page. We will also post the notes of the meeting on the project page, to give the possibility to read what was discussed also to those who couldn’t attend it.

If you want, you are invited to share this invitation with all the people you think might be interested in this call.

We hope to see you and/or read you very soon! Sannita (WMF) (talk) 14:56, 6 January 2025 (UTC)[reply]

Until recently the logo used in the infobox of FIDE was en:File:Fidelogo.svg. This file has a lengthy discussion of licensing, the outcome of which is that it can be used at FIDE but nowhere else in Wikipedia.

With this edit an editor, Bildersindtoll, changed FIDE to use instead Logo FIDE International Chess Federation.svg. The new logo is/was apparently identical except that the silhouette is reversed, i.e. blue replaced by white and white replaced by blue. I do not know why the logo was replaced (no edit summary), but I note that the FIDE website, FIDE.com, is currently using the logo that Wikipedia changed to, rather than the logo that was changed from.

However, the new logo must not have had the same lengthy discussion of licensing as the old. As a result it was deleted from Commons, see Commons:Deletion requests/File:Logo FIDE International Chess Federation.svg. This doesn't seem right. I think licensing of both logs should have been identical.

As a temporary measure, I have restored FIDE to use the old logo. What I would like to see, however, is for the new logo to be undeleted, and the same licensing text added to it as is used in the old. Bruce leverett (talk) 20:37, 6 January 2025 (UTC)[reply]

The old logo was hosted on en.Wiki under fair use. The new logo was hosted on Commons which does not allow fair use. The new logo could be hosted on en.Wiki under fair use.
The only way the logos could be hosted on Commons is if they have a free license. The crux of that DR was whether the silhouette of the knight is public domain. That argument did not carry the day but it could be revisited.
Glrx (talk) 21:24, 6 January 2025 (UTC)[reply]

January 07

Wikidata Infobox

Is there any way to control which statements shows up? On some categories the statements in the infobox are largely useless while excluding actual useful ones Trade (talk) 08:24, 7 January 2025 (UTC)[reply]

@Trade: Please see Template:Wikidata Infobox and be more specific on the talk page there.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:01, 7 January 2025 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=980643433"