Commons:Village pump

Shortcut: COM:VP

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓

COMMONS DISCUSSION PAGES Commons Help desk Village pump (general discussion) Copyright Proposals Technical Graphics and photography discussion Photography critiques Image improvement Illustration workshop Map workshop Photography workshop Video and sound workshop Categories for discussion Undeletion requests Deletion requests Volunteer Response Team/Noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests Oversight requests Telegram IRC webchat Commons mailing list (archive) Commons' bugs on Phabricator 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: 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. Have you read our FAQ? For changing the name of a file, see Commons:File renaming. 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). 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: Please do not make deletion requests here: use the relevant process for it instead. For technical support and graphics talks (PNG, SVG, GIF, etc.), please post on the Graphics village pump. To ask for image improvement, see: Graphic Lab/Photography workshop for photographs. Graphic Lab/Map workshop for maps. Graphic Lab/Illustration workshop for other illustrations. To ask for video or audio improvement, see Commons:Graphic Lab/Video and sound workshop. For translation requests, please post at Commons:Requests for translation. For media requests, please post at Commons:File requests. Search archives:     Start a new discussion

#	💭 Title	💬	👥	🙋 Last editor	🕒 (UTC)
1	Syrian flag	34	7	Jmabel	2024-12-28 02:48
2	Colour difference	8	4	PantheraLeo1359531	2024-12-26 16:16
3	Best practice for Questionable Flickr images	9	7	MGA73	2024-12-27 15:37
4	Categories combining city and photographer	10	6	Adamant1	2024-12-27 19:09
5	Photographic process versus technique	10	5	Adamant1	2024-12-26 23:32
6	Video transcoding maintenance in File:Night of the Living Dead (1968).webm	33	7	TheDJ	2025-01-02 12:45
7	Merry Christmas - A year in Wikimedia	4	4	ReneeWrites	2024-12-26 17:45
8	Reindeer symbols	5	4	Smiley.toerist	2025-01-01 14:41
9	Category:Deepin Icon Theme	7	5	999real	2024-12-29 18:50
10	There is a problem with Category:House of Skoropadsky and its related WikiData item.	3	2	OperationSakura6144	2024-12-29 11:51
11	Paths and Walkways	3	3	Jmabel	2024-12-30 04:52
12	Flag of Uzbekistan	3	2	Jmabel	2024-12-30 17:20
13	Bayeux Tapestry	3	3	Herbert Ortner	2024-12-30 19:59
14	Need help with a non-legitimate deletion	8	5	Ratekreel	2025-01-01 22:23
15	A healthy new year!	4	3	PantheraLeo1359531	2025-01-02 12:30
16	Commons Gazette 2025-01	1	1	RoyZuo	2025-01-01 23:35

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.

Village pump in Sabah, Malaysia. [add]

Centralized discussion See also: Village pump/Proposals   ■ Archive Costumed character files (14 October 2024) Third-party images published by the National Weather Service (26 August 2024) Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Technical needs survey (17 December 2023) When does PDART apply to textile works? (15 November 2023) Does this image contain "love hearts"? (17 August 2023) Definition of country (19 June 2023) Overhaul of categories by period (5 December 2022) Version of Saudi flag to use (11 July 2022) Concern regarding revocability of KOGL licenses (22 December 2021) Should deleting content from your own talk page be forbidden? (11 November 2021) Revise the COM:FOP Sweden section (1 February 2021) Change technical name of LRs to license-reviewer from image-reviewer(2 November 2023) Was the closure of the deletion discussion concerning the current lede image for Philippe Pétain proper under Commons policy? (22 September 2024) 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)

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)

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)

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)

A or B sounds best. איז「Ysa」 • For love letters and other notes 14:36, 22 December 2024 (UTC)

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)

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)

@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)

@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)

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)

@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)

OK, I removed mine after you had removed yours. Abzeronow (talk) 20:30, 22 December 2024 (UTC)

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)

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)

@Mohammed Qays: regarding ar-wiki since they could help with this there. Abzeronow (talk) 02:30, 23 December 2024 (UTC)

@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)

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)

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)

@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)

@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)

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)

@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)

@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)

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)

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)

@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)

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)

@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)

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)

We certainly agree on the need to update the Country data Syria templates, though. - Jmabel ! talk 06:20, 24 December 2024 (UTC)

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)

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)

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)

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)

December 20

Colour difference

Hello

I recently created a SVG file of a PNG logo with Inkscape, I used the colour picker tool and everything seemed fine. I then save as optimised SVG and uploaded the SVG file to Commons, but the red square seems darker than on the original PNG (the blue and yellow also seem a bit different).

I then uploaded this original PNG, but its colours are the same as the SVG.

I then took a screen capture of the original, compared it to the Commons files, and the colours are definitely not the same (3rd image in the gallery below).

• 
  SVG
• 
  PNG
• 
  Compared screenshots

Is it a known issue, or am I missing something ?

Regards, Şÿℵדαχ₮ɘɼɾ๏ʁ 19:43, 20 December 2024 (UTC)

I found a thread about it on the Adobe forums where someone with the same issue mentioned they solved it by embedding the file rather than linking it. Does that solution work for you? ReneeWrites (talk) 10:38, 21 December 2024 (UTC)

Hello ReneeWrites. I've done more tests and the problem seems to be linked to the web browser used (see the new version of the screenshots compared above, CTRL+F5 to clear the page cache).

So Firefox seems to display different colours on linguistlist.org and Commons whereas Chrome and Edge don't, but all three browsers seem to display slightly different colours to the PNG/SVG files.

I'm a bit confused and can't figure out where the problem really lies...

Regards, Şÿℵדαχ₮ɘɼɾ๏ʁ 15:56, 21 December 2024 (UTC)

I don't think it's a browser issue necessarily. I notice that the color picker is sometimes slightly off when I'm working on a file in Illustrator, at which point I eyeball the process. ReneeWrites (talk) 23:54, 21 December 2024 (UTC)

I could be wrong, but maybe the SVG is saved in CMYK color space, and the PNG in RGB? Some colors available in (s)RGB are not in CMYK. --PantheraLeo1359531 😺 (talk) 19:44, 22 December 2024 (UTC)

As someone who is not an expert, that doesn't track to me: the SVG defines these colors with hex codes, which are at a re-encoding of RGB values. My eye doesn't see a difference between the SVG and PNG logos and an online color picker calls the PNG's red #800000, the PNG thumbnail of the SVG #810000 (!!!), and the code of the actual SVG itself defines it as #800000. The codes fro the blue and yellow squares have the same values in all three files.@SyntaxTerror: , this warrants a ticket at phab:. Are you willing to make one? If not, I will. —Justin (koavf)❤T☮C☺M☯ 19:51, 22 December 2024 (UTC)

Hello Koavf and thank you for your reply. I was also thinking of making a ticket on Phabricator, but I still don't know if this problem is related to MediaWiki or browsers (or maybe my computer?).

If you'd like to make a ticket, it's no problem with me as I'm not a native English speaker, and technical terms can sometimes be difficult for me. Mention me anyway so I can answer any questions. Regards, Şÿℵדαχ₮ɘɼɾ๏ʁ 00:43, 23 December 2024 (UTC)

SVG uses the sRGB colorspace. librsvg turns SVG into a PNG bitmap. By default, PNG does not have a default sRGB colorspace, but its colorspace can be set to sRBG. Last time I checked, librsvg or the libraries it uses do not set the PNG colorspace to sRGB. Consequently, we should not expect the colors to match. There are also questions about screen grabs and color pickers. Are the colors before or after the system color correction? Glrx (talk) 01:17, 23 December 2024 (UTC)

Afaik Adobe has CMYK as standard color space for software focused on printing, like InDesign. This could also apply to Illustrator in some way. Another topic is (which I found out accidentally), that the color/RGB code can change when you're using the HDR function in OSes like Windows 11 (I measured it with the color picker). Another reason could be a secret color aberration while processing/converting. I have this when I trace a PNG image to have it as SVG. The used colors are not identical. Sometimes Adobe applies a narrow color palette, that is affected by anti alised pixels that have colors between to edge colors --PantheraLeo1359531 😺 (talk) 16:16, 26 December 2024 (UTC)

December 21

Best practice for Questionable Flickr images

At Commons:Questionable Flickr images, there is a list of blacklisted users. Sometimes I think, "Hmmm. This image from that account looks good. I wonder why it is blacklisted?"

Looking at the list, the reason in most cases is "Flickrwashing." Personally, I do not think that it is very helpful. So, I wonder if we could agree that for new requests, it would be good if a link to a discussion is included?

Next is when do we blacklist? What if a user has 99 good images and 1 bad? Or 50 good and 50 bad? Or 1 good and 99 bad? I think in some cases the reason to blacklist has been derivative works and the lack of Freedom of panorama. Personally, I do not think we can set up a general rule, but if a Flickr user is in bad faith and tries to push files to Commons, we should always blacklist. If most of the uploads are bad, we should also blacklist. But if it is only a smaller part of the photos or if the reason is derivative works, we should not blacklist.

What made me write this post is this request: Commons_talk:Questionable_Flickr_images#Removal_of_@wbayercom. I'm not sure we have a good place to discuss this. Commons talk:Questionable Flickr images has 146 page watchers, and Commons:Undeletion requests has 301 watchers. On the first page, requests can go unnoticed for months, but on the second page, there is often a response after a few hours.

You could say, "If you think it's a problem, then just watch the damn page and fix the requests." You would be right. But I also think that it would be good if we had some guidelines about what to add as a blacklist reason and when to add or remove. For example, I have sometimes thought about going rogue and just removing all requests without a link to a discussion. But the result would probably be a lot of bad images and angry users.

So, even if we can't set up a rule saying that if the bad ratio is > 40%, then blacklist, perhaps we can set up a few "rules of thumb"?

If that allready exist perhaps it could be added to Commons:Questionable Flickr images? --MGA73 (talk) 10:50, 21 December 2024 (UTC)

@MGA73: Since Commons:Questionable Flickr images/Users is Admin protected, perhaps COM:AN might be a better venue for this.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:31, 21 December 2024 (UTC)

@Jeff G. Commons:Questionable Flickr images/Users is Admin protected but Commons_talk:Questionable_Flickr_images#Removal_of_@wbayercom is not so it is possible for non-admins to comment. Just like non-admins can share their views here :-) --MGA73 (talk) 17:44, 21 December 2024 (UTC)

FWIW, I don't think it's just a percentage. For example, I would hope no one would consider me to be Flickrwashing for https://www.flickr.com/photos/jmabel/54211685003 where I upload an image to Flickr that has a complicated copyright status, and say so. - Jmabel ! talk 18:30, 21 December 2024 (UTC)

"Flickrwashing" is a fairly specific term. It doesn't mean "uploading images with copyright issues". It specifically means "uploading and taking credit for other people's copyrighted photos". Taking a photo of a painting or a non-FOP architectural work isn't Flickrwashing; copying a photo from a stock photo web site or a newspaper and reposting it is.

QFI listings should generally be reserved for instances of true Flickrwashing, not other rights issues. If we blocklisted accounts just because they took a few photos of paintings or toys or whatever, we'd be here all day (and we'd probably be rejecting a lot of perfectly good photos in the process). Commons users importing content from Flickr need to evaluate it for DW/FOP concerns themselves; QFI should be reserved for sneaky copyright violations which aren't apparent from the image itself or its subject matter. Omphalographer (talk) 22:17, 21 December 2024 (UTC)

I agree 100% with that. So far the accounts I have added to QFI is because they were specifically created for license washing. Yann (talk) 22:56, 21 December 2024 (UTC)

• Some good points above. Two points: 1)Keep in mind that Flickr is in some ways social media, and allows derivative works of copyrighted material (eg photos of posters or book covers, etc) which Commons cannot allow. So Wikimedians copying images from Flickr should keep this in mind as something to consider before uploading a given image to Commons, knowing that while some may be tagged as free licensed on Flickr they are still not properly free for Commons. 2)"Blacklists" are not simply for Flickr accounts that don't live up to Commons standards, nor for accounts that are generally good but the users are sometimes careless with with license claims. It is for accounts that generally or deliberately make false license claims, usually with intent to deceive as to actual license status. -- Infrogmation of New Orleans (talk) 23:06, 21 December 2024 (UTC)

• My main issue with the Flickr blacklist is that it's a blanket ban on uploads from a certain account, there was a Flickr account called "Manhhai" (unfortunately, now deleted) which hosted tens of thousands of unique images of Vietnamese history that weren't found anywhere else, Vietnamese images published before 1945 are in the public domain and this account literally had thousands of them, but there was no way to actually import them using any of the Flickr-import tools because of the blacklist. While some public domain images had notices like "©️ All rights reserved", others were copyrighted works with Creative Commons licenses and this user was added to the blacklist because of how often they misreported on the copyright ©️ status, but... any experienced Wikimedia Commons user could simply have imported his supposedly "free to use creative commons works" and add the correct PD license tags to them, especially since he did often include detailed information about date of publication and photographer. In many cases, Manhhai was the only source on the internet for literally thousands of images related to Vietnamese history. What the Wikimedia Commons usually excels at is preserving free educational and historical content from online sources that have since been lost to time, Manhhai is a very unfortunate example where this didn't happen and it's uncertain if several of the images he uploaded to SmugMug's Flickr will ever be found online. Maybe there should be a special tool where experienced users can circumvent the blacklist and that these uploads would have to be reviewed by a human. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:57, 24 December 2024 (UTC)
• Thank you for the input. I agree that the user that import files to Commons is the one responsible for the files. So to me that indicates that a blacklist is not the right thing to use if a Flickr user have uploaded derivative works etc. Unless of course it is done to push files to Commons.

I think the idea of allowing some users to upload files from a blacklisted account sounds interessting. But it may require too much coding. An alternative could be to request a temporary removal and then upload the good files and categorize them in "Files from Flickr user Foo" and then add the blacklist again. If User:Donald Trung finds another case that could be used as a test. --MGA73 (talk) 15:37, 27 December 2024 (UTC)

December 22

Categories combining city and photographer

Hello fellows, we have three categories which (together with their subcategories) sort photos by a combination of the criteria by city and by photographer:

1. Category:Photographs by city by photographer
2. Category:Photographs by photographer by city
3. Category:Photographs of cities by photographer

There’s a clear difference between (1) and (2) – Category:Photographs by city by photographer vs. Category:Photographs by photographer by city – these categories are sorted the other way around and contain different subcategories, fine.

But I don’t understand the difference between (2) and (3) – doesn’t Category:Photographs by photographer by city and Category:Photographs of cities by photographer mean the same thing? Of course I see that there could be a slight semantic difference, but actually the subcategories contained in these two categories are all of the same type, namely “Photographs of <city name> by photographer”. Some subcategories, e.g. Category:Photographs of Dubai by photographer, are actually contained in both supercategories.

So is there a real difference between Category:Photographs by photographer by city and Category:Photographs of cities by photographer, or should we merge these categories? Thank you and all the best, – Aristeas (talk) 19:14, 22 December 2024 (UTC)

The former category is for categories for photos of specific cities by specific photographers. The latter is for photos of unspecific cities by specific photographers. Ruslik (talk) 19:56, 22 December 2024 (UTC)

What's the use case for the latter? Surely all of those files would already be categorized as photographs of cities and photographs by that photographer; the added value of a category specifically for photographs of cities which aren't identifiable as any specific city seems minimal. Omphalographer (talk) 23:23, 22 December 2024 (UTC)

So, the former should contain categories like "Photos by John Doe of London". The latter - "Photos of cities by John Doe". Ruslik (talk) 20:00, 22 December 2024 (UTC)

Hello Ruslik, thank you very much! But right now Category:Photographs by photographer by city and Category:Photographs of cities by photographer contain exactly the same kind of subcategories, namley “Photographs of <city name> by photographer” categories. Subcategories of the type “Photos by John Doe of London” are contained in Category:Photographs by city by photographer. There is just a single subcategory similar to your example “Photos of cities by John Doe” in Category:Photographs of cities by photographer, namely the lonely and empty Category:Photographs of cities by Oleg Yunakov …

So are you saing that all subcategories of the type “Photographs of <city name> by photographer” should be removed from Category:Photographs of cities by photographer and added to Category:Photographs by photographer by city? Then Category:Photographs of cities by photographer could indeed be reserved for subcategories like your “Photos of cities by John Doe” example, i.e. for photos of unspecific cities by specific photographers. OK, that would make sense! But it would be a fairly serious change. Do other users agree that we should do this? Best, – Aristeas (talk) 20:15, 22 December 2024 (UTC)

@Aristeas: If it were me I'd up merge whatever subcategories overlap between the two into whichever one makes more sense and then go from there. It be that a lot of the parent categories end up being empty and/or otherwise pointless once the overlap is fixed though. --Adamant1 (talk) 20:25, 22 December 2024 (UTC)

When browsing these trees I see a lot of incorrectly categorization. Take for example Category:Photographs by Selmoval - Foix - 2005 (permalink). That's a user category and should never be in the main category tree (Commons:USERCAT). Multichill (talk) 17:25, 24 December 2024 (UTC)

It's probably a lost cause at this point but there's a ton of problems and whatnot with how user categories are organized. This being one of them because some users want to be associated with professional photographs by way of putting their images in the normal category tree. I spent some time trying to organizing it a few years ago but it just led to drama. So I stopped. It would make things a lot easier though if user categories explicitly had to start with "User:" and weren't being randomly mixed in with normal ones. But I really don't see that changing with how much uploaders are coddled to on here. --Adamant1 (talk) 19:02, 24 December 2024 (UTC)

Some users are professional photographers. Some users are notable people and the subject of Wikipedia articles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:39, 27 December 2024 (UTC)

Sure. I don't really care if a professional photographer or notable person who also happens to be a user wants to use normal categories for their files. They aren't who I was refering to. --Adamant1 (talk) 19:09, 27 December 2024 (UTC)

December 23

Photographic process versus technique

It seems like there's a lot of overlap between Category:Photographic processes and Category:Photographic techniques. Anyone have any idea what the difference between a "process" and "technique" is when it comes to photography or what should go in which category? I ask because there's also Category:Photographs of cities by technical criteria, which I was going up-merge to one of the other categories. I have no idea which category to go with or if there's even a difference between them to begin with (there doesn't seem to be). Adamant1 (talk) 14:58, 23 December 2024 (UTC)

I doubt there is a useful distinction. Possibly there are techniques that are not "processes" (e.g. the use of a polarizing filter), but every process is a technique. - Jmabel ! talk 19:07, 23 December 2024 (UTC)

I think the intended distinction is that a photographic technique is something that the photographer does when taking a photograph, whereas a photographic process involves film chemistry and the processes used to turn it into a print in a darkroom. This isn't really borne out by the current contents of the categories, though. (And, of course, this distinction completely breaks down when dealing with digital photography.) Omphalographer (talk) 22:35, 23 December 2024 (UTC)

I would be in favor of removing everything in the category Photographic processes that does not relate to how photo film gets made into photographs. Bastique ^{☎ let's talk!} 23:01, 23 December 2024 (UTC)

Huh. If we are going that way, it seems odd to say that digital post-processing doesn't count as processing. - Jmabel ! talk 00:50, 24 December 2024 (UTC)

Maybe it's of some help to look at how other projects deal with this distinction. This is what the category descriptions on enwiki have to say:

• Category:Photographic processes - "This category groups together articles that describe procedures by which light-sensitive materials are made to produce an image. The category should not be confused with Category:Photographic techniques, which comprises articles describing procedures related to how a photograph is taken or composed, or is manipulated during or after processing."
• Category:Photographic techniques - "This category contains categories and articles relating to the theory and methodology of composing and/or taking photographs, or to their manipulation during or after processing. It should not be confused with Category:Photographic processes, which comprises articles relating to the production of images using light-sensitive materials."

The descriptions are very similar to the ones Omphalographer stated. "Photographic technique" is defined slightly more broadly so it's inclusive of digital photography, while "Photographic process" describes an explicitly analog process. I like these descriptions, they seem clear to me, leave very little room for ambiguity, and solve the issue being discussed above, with maybe one exception: The page for "Post-processing" is a disambiguation page, of which the one relevant to photography is titled "Image editing". This page is categorized as a technique, not a process. ReneeWrites (talk) 14:25, 24 December 2024 (UTC)

Then I noticed earlier that there's also Category:Photography by genre and Category:Photography by style. The former isn't that much of an issue, but there seems to be some over lap with "by style" and the other categories. So there's categories for technique, process, style, and genre. All of which are rather similar and similarly ambiguous. --Adamant1 (talk) 14:54, 24 December 2024 (UTC)

Genre seems to concern itself with subject matter - what a photograph depicts, so that's not really an issue. Style seems to be a bit more problematic. ReneeWrites (talk) 14:58, 24 December 2024 (UTC)

Is the "Style" category something we want to discuss here further, or should I open a CfD for it? The other three categories seem well-defined enough for me. ReneeWrites (talk) 17:40, 26 December 2024 (UTC)

I had it speedy deleted before you asked because everything in it seemed better off in other categories. Thanks for the thought though. --Adamant1 (talk) 23:32, 26 December 2024 (UTC)

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)

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)

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)

@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)

Yes, I'm seriously considering dialing that back pretty soon for this exact reason. —TheDJ (talk • contribs) 13:00, 31 December 2024 (UTC)

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)

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)

@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)

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)

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)

@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)

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)

@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)

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)

@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)

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)

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)

@TheDJ: What is preventing upgrade to the latest ffmpeg?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:30, 31 December 2024 (UTC)

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)

@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)

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)

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)

@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)

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)

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)

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)

@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)

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)

@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)

I abhor memory leaks.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:32, 31 December 2024 (UTC)

Has someone made a bug report about this ? —TheDJ (talk • contribs) 12:32, 2 January 2025 (UTC)

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)

I requested a split: [3]. Yann (talk) 14:44, 31 December 2024 (UTC)

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)

December 25

Merry Christmas - A year in Wikimedia

Merry Christmas and Happy Holidays to the good people of Wikimedia who have helped me learn the ropes and supported me. Obvious flagrant exceptions, especially from veteran editors who don't respect the Wiki policy of not biting newbies -- still worth it though, to contribute to the project and be a volunteer. It's year one for me, and I've focused on ordering the category of Category:Nuevo Laredo. When I came it was barely there but I've managed to structure it. Being a newbie, I took as a basis how the categories of other cities such as Berlin, Dallas or Phoenix where structured. Additionally, I've populated and/or organized the Category:People of Nuevo Laredo with notable persons as well as images of public places or public events. This has attracted some of you to help me organize or twitch things that I may have missed, which I thank. Other categories I have heavily organized are those related with People of Mesoamerica, People of Mexico, images from Montreal, images of Mexican people or places. Recently I started to upload my videos, which I will continue. And finally, it is amazing that websites, media and news outlets use these contributions -- which I have listed on my personal user page, an idea I took from an experienced contributor who does the same thing. Some of you may have my differences with me, but I'm not going anywhere since I am not only learning but also it is imperative for the Wiki project to have a diverse of insights and way of thinking. To new Wiki editors, do not be discouraged! For many upsetting experiences you may have (and will have) with other user, there are others who will be not only friendly but also will teach you and guide you. And if you want to team up in the topics of my interest, I'll be more than delighted. Cheers! Miguel Angel Omaña Rojas (talk) 00:32, 25 December 2024 (UTC)

We are glad to have you here :) --PantheraLeo1359531 😺 (talk) 13:07, 25 December 2024 (UTC)

happy christmas dear christian brothers and sisters! greetings from turkey! modern_primat ^{ඞඞඞ ----TALK} 16:27, 25 December 2024 (UTC)

Merry Christmas to you too, and best wishes for 2025 :) ReneeWrites (talk) 17:45, 26 December 2024 (UTC)

December 26

Reindeer symbols

Is there a specific category for reindeer symbols?

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

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)

Very funny :D. Maybe "reindeers in art" or so? --PantheraLeo1359531 😺 (talk) 16:10, 26 December 2024 (UTC)

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)

The symbol was only visible on the first and second christmas day (25 and 26).Smiley.toerist (talk) 14:41, 1 January 2025 (UTC)

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)

Offhand sounds reasonable to me. - Jmabel ! talk 02:47, 28 December 2024 (UTC)

Yes, this sounds very good to me --PantheraLeo1359531 😺 (talk) 16:41, 28 December 2024 (UTC)

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)

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)

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)

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)

December 29

There is a problem with Category:House of Skoropadsky and its related WikiData item.

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)

@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)

Oh, I thought it was unfixable. Thank you, by the way. OperationSakura6144 (talk) 11:51, 29 December 2024 (UTC)

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)

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)

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)

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)

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)

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)

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)

They might have a case under a EULA, but not copyright. - Jmabel ! talk 17:17, 30 December 2024 (UTC)

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)

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)

@JBouchez: You can file an undeletion request for these files at COM:UNDEL ReneeWrites (talk) 20:31, 30 December 2024 (UTC)

@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)

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)

@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)

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)

| 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)

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)

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)

@PantheraLeo1359531: You too!   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:23, 31 December 2024 (UTC)

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)

Indeed! More is yet to come. But there is still left to be recorded and archived :) --PantheraLeo1359531 😺 (talk) 12:30, 2 January 2025 (UTC)

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:

• User:Auntof6 was elected (38/0/1) on 5 December.
• User:Triplec85 was elected (19/4/0) on 9 December.

Removal:

• User:JarrahTree passed away on 2 December. He had served as sysop from 29 March 2010.

  A big loss for our community. We thank him for his service.

---

---

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)

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)

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)