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 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/2025/11. 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. For questions about copyright, technical matters, or help that does not relate to the general Commons community as well as proposals, please see the other discussion boards linked in the blue panel at the top. Search archives:     Start a new discussion

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 Commons:Village pump/Proposals#Temporary account IP viewer policy (6 September 2025) User talk:CommonsDelinker/commands#Replace images with .svg version (5 August 2025) Category talk:Heroes' Cemetery in the Philippines#RfC: Cemetery name (18 July 2025) Discussion on Copyright law of North Korea (16 March 2025) Hosting of free fonts in Commons (18 July 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.

November 02

Commons:Template requests

On the new page Commons:Template requests, Commons users can request edits to templates, the addition of complex templates to pages, and the creation of new templates. Users experienced with templates can find tasks to work on.

So far, such requests could only be made on dispersed talk pages unlikely to be watched by users experienced with templates (and just very few if any users) and at Commons:Village pump/Technical which Template editors may not watch either and which is more broadly about any kind of technical problems. Moreover, on both of these pages, requests may have gotten archived without gotten implemented.

If you are skilled in editing templates, please help out there.

--Prototyperspective (talk) 14:44, 2 November 2025 (UTC)

Is there a way to display stats like these (these current stats)?:

• 3 solved requests, 5 open requests (8 total)

Prototyperspective (talk) 13:42, 5 November 2025 (UTC)

3 solved requests, 6 open requests (9 total)

Current open requests:

• Parameter auto=yes for ArchiveBox to detect and link/transclude archive subpages
• Parameter for "review impossible" for LicenseReview template (in progress)
• Fix Topic in country template linking to the redlink Template:Byby
• Make template Shortcut show again
• Florida memory – Attribution-FLGov-PhotoColl should contain image number (likely not done)
• Making Template:Search link work with MediaSearch (likely solved)

Prototyperspective (talk) 14:57, 11 November 2025 (UTC)

November 06

Data graphic resources?

Commons:Free media resources/Datagraphics is a relatively new page for databases with free data graphics like charts that could be uploaded to Commons.

It still only has few sites – do you know of any further ones?
-
Recently added this resource but it's mostly just German-language data graphics. It would be great if somebody could upload the graphics from there that aren't yet on Commons. Until now, doing so was just in my private todos but I may never get to uploading more of these. For an example, see Category:Meat Atlas which contains charts and maps about meat consumption (not just in Germany but also worldwide; translatable).

--Prototyperspective (talk) 23:22, 6 November 2025 (UTC)

Seems like Eurostat could be added: according to this page The copyright for the editorial content of this website, which is owned by the EU, is licensed under the Creative Commons Attribution 4.0 International licence. There probably are more sites like it and maybe somebody here knows of or can find more.

There also are a few files in Category:Data visualization by Statista – is there a way to search for the subset of files in Statista that are CCBY/CCBYSA?

May be good to create a Commons:Batch uploading request for these if that's anyhow possible (and it's probably possible to scrape the sites in structured ways even if they don't have APIs). For Our World in Data, the batch uploading is done semi-manually/automatically via the OWIDImporter which is linked on that page. Prototyperspective (talk) 12:03, 13 November 2025 (UTC)

November 08

Warning for users

Time and time again we see users trying to delete their own uploads, only to find out that they cannot do that themselves, and they can rarely convince sysops to delete for them (as the current practices show).

But this reality, the lack of utility to delete one's own content, is not communicated to the users at all. If you go through registration and every step in Special:UploadWizard, this rule is not mentioned at any point. This is a very different rule from what people can expect on any other major file hosting sites such as flickr, youtube... where users can always delete their own uploads anytime for any reason or no reason at all.

So I suggest, that this rule be clearly communicated to the users, and that there should be a write-up documenting this rule as well as its origin and rationale.--RoyZuo (talk) 20:50, 8 November 2025 (UTC)

written as i am fed up with mistreatment of fellow users as recently as Commons:Administrators'_noticeboard#c-Olga_Rithme-20251107145500-Appealing_decisions_that_contravene_a_set_of_rules.--RoyZuo (talk) 20:50, 8 November 2025 (UTC)

It is hidden in the license conditions shown on the "Learn" page at the UploadWizard and at the linked license texts. And of course it is also in the Terms of Use. We could make this more clear if we would have a definitely needed rework of this info graphic. GPSLeo (talk) 21:13, 8 November 2025 (UTC)

it is not explicitly spelled out that "you cannot delete your user-generated content" in https://foundation.wikimedia.org/wiki/Policy:Terms_of_Use .

when all other major websites, which also support certain "free licences" fit under wikimedia commons definitions, allow users delete their uploads, most users dont realise they cannot do the same on wikimedia commons until they want to delete something, and that this surprise is because wikimedia commons prioritises irrevocability of the licence over user experience. RoyZuo (talk) 21:34, 8 November 2025 (UTC)

I find this very clear: "e. No revocation of license: Except as consistent with your license, you agree that you will not unilaterally revoke or seek invalidation of any license that you have granted under these Terms of Use for text content or non-text media contributed to the Projects or features, even if you terminate use of our services." This in theory event forbids making a deletion request. GPSLeo (talk) 22:24, 8 November 2025 (UTC)

Something this vital shouldnt be hidden in the first place at all Trade (talk) 20:23, 9 November 2025 (UTC)

This rule was clearly communicated to this user multiple times. Maybe not at the upload stage but certainly once they started filing deletion requests and had those requests denied. ReneeWrites (talk) 10:12, 9 November 2025 (UTC)

I actually broadly agree with RoyZuo on this. I've always found it weird that there is no warning in plain language in the upload process about the lack of simple deletion procedures for users uploading their own works to Commons. "License irrevocability" is quite a niche topic if you don't spend a lot of time on this and other Wiki project or work professionally in the realm of IP; many if not most people have no idea what that means or just assume it's a technical requirement akin to allowing cookies on a website. I think that's evidenced by the steady stream of users over the years who have tried at the help desk, village pump, and other forums to get their content deleted and were baffled by the idea that they had no recourse to delete their own work. There should be clear, plain language in the upload process that explains how, barring copyright questions or another legal issue and following a 7-day courtesy window, works uploaded to Commons will not be deleted at the uploader's/author's request.

And to be clear, I'm not saying it's good that so many people don't understand free licensing or the preexisting written warnings/caveats in the upload process; it just seems to be a fact. I believe we could avoid a lot of headaches by adding plainer language. But that would also probably lower the rate at which users complete the upload process, as a warning like that might scare some people off, which, if I were being cynical, I would assume is why the language has never been added (after all, who wants to be responsible for on average less content being added to Commons?). But the ethical choice appears to be better informing uploaders about the long-term deletion policies in the clearest, most non-technical language possible. 19h00s (talk) 13:26, 9 November 2025 (UTC)

I agree with this. Ymblanter (talk) 16:50, 9 November 2025 (UTC)

"works uploaded to Commons will not be deleted at the uploader's/author's request." But we already do delete works uploaded to Commons at the uploader's request. It's just not consistently Trade (talk) 20:30, 9 November 2025 (UTC)

Provided the deletion is requested within 7 days after upload and the work is not currently in use on a Wikimedia-project. --Túrelio (talk) 20:53, 9 November 2025 (UTC)

We have deleted files long after 7 days several times Trade (talk) 14:30, 10 November 2025 (UTC)

Sure, but that is not the rule. In such cases often the file is also out of scope and there may be further aspects. But the uploader should be communicated the valid rule, because they have a right to it. --Túrelio (talk) 15:43, 10 November 2025 (UTC)

I disagree. A lot of the files i see deleted after a week would not have survived a typical "out of scope" deletion request Trade (talk) 22:23, 10 November 2025 (UTC)

@Trade: We are allowed, but not required, to extend a courtesy. Lying to us and/or threatening legal action certainly both decrease the chance of us extending a courtesy. - Jmabel ! talk 23:03, 10 November 2025 (UTC)

Can you expand on this? I believe you're hinting at a perceived double standard or deference on the part of Commons or WMF to certain users or rightsholders (or types of users/rightsholders) when they request their content be deleted, but I don't want to incorrectly assume. I think that's an important separate conversation in that we shouldn't, for example, allow large corporations to remove validly licensed content while not allowing individual authors/uploaders to do the same simply because one has more structural and financial power. But this conversation seems to be specifically about the average, or very new, user, who does not fully grasp the ramifications of their choices when freely licensing and uploading their work to Commons. Again though, I could be misinterpreting you. 19h00s (talk) 16:50, 10 November 2025 (UTC)

Where do we allow large corporations to revoke their licenses? We hand mass deletions because an employee published something without the corporation having the permission from the rights holders to do so. But this is something totally different. GPSLeo (talk) 19:06, 10 November 2025 (UTC)

I was responding to Trade, asking about what they were implying with their comment about policy not being applied "consistently". I gave theoretical examples of what I believed they were implying (e.g., that there may have been deference or double standard in the way certain rightsholders' requests were handled). I never said Commons in fact does these things. 19h00s (talk) 19:32, 10 November 2025 (UTC)

I am moreso implying that some users lean heavily towards courtesy and others towards keep. Whether or not the deletion goes through is mostly dependent on which group of users decided to stumble upon the DR at the given time

At this point dealing with courtesy deletion requests is little different than using a random number generator to determine the outcome Trade (talk) 22:27, 10 November 2025 (UTC)

@19h00s while i dont know what User:Trade might actually mean, here's a separate answer to your question:

Commons:Village pump/Archive/2025/03#March 2025 update from WMF Legal on "Vogue Taiwan and possible Copyright Washing" discussion, not that long ago.

the unfortunate thing here, is that these good hearted contributors dont have money to lawyer up.

Conde Nast can get away by merely saying they made an error.

meanwhile, the absolutists here and there (Commons:Administrators'_noticeboard#c-Olga_Rithme-20251107145500-Appealing_decisions_that_contravene_a_set_of_rules) dont realise that commons users are at the most only given t&c in "browsewrap manner via hyperlinks alone" which is void as per Nguyen v. Barnes & Noble, Inc.

also, when users are never displayed the full t&c, it's probably invalid as per Specht v. Netscape Communications Corp.

and clearly, the t&c linked in the uploadwizard doesnt refer to the file uploaded, because in a single sentence it says "By clicking "publish", you agree to the terms of use, and you irrevocably agree to release your contribution under the Creative Commons CC0 License." even if you are releasing your photo in any licence other than cc0. the only logical understanding is this only explicit mention of "terms of use" here covers "your contribution" related to "captions and other additional information such as main subjects and location (NOT the file)".

so if they have a lot of money, they could quite possibly do something to have the same treatment as corporations.--RoyZuo (talk) 22:30, 11 November 2025 (UTC)

I'm not a very sympathetic ear on the Vogue Taiwan case, as I vocally approved of deletion and still agree it was the correct decision; corporate structures are opaque for a reason, they give companies plausible deniability and legal/ownership "air-gaps" for situations just like that one, meaning our obligation to protect the project and reusers from possible (and possibly valid) litigation or damages must necessarily trump our desire to retain the content. Indeed though, Vogue Taiwan is what I thought Trade was referring to (clearly I was wrong), and I do believe we generally shouldn't let corporations with capital or power dictate our decision-making purely because they have the means to fight a legal battle. But that is a complex calculation that involves different levels of risk for WMF, Commons, and the Wiki community broadly.

On the whole though, I still completely agree that clearer language in the upload process about the slim prospects of courtesy deletion and lack of long-term deletion procedures would solve a lot of issues and prevent a lot of stress for both uploaders and Commons. 19h00s (talk) 23:34, 11 November 2025 (UTC)

and i'll end off my comments by this. what disgusts me the most, is certain users' hostility against other users and indifference to other users' needs. they choose to needlessly antagonise and bash other users instead of seeing and understanding people's needs and working kindly and gently with them.

i see this problem, i come up with this solution of a warning. those users see this problem, they bully the users in need and drive them away. technical solutions cant solve attitude problems. RoyZuo (talk) 22:30, 11 November 2025 (UTC)

 Support for the proposal to very clearly explain/state our current rules for the deletion of own uploads in the basic tutorial for new users and also during the upload-procedure. --Túrelio (talk) 20:58, 9 November 2025 (UTC)

The Commons:Upload page does have a warning (in bold even!) that licenses cannot be revoked. If people overread that part of the formular, it is their own loss.

However, I am surprised that the much-advertised Upload Wizard does not have a warning (I could find): The licensing part says currently: All media uploaded to Wikimedia Commons are free for anyone to use and share anywhere on internet or off internet. To ensure the work you upload is copyright-free, please provide the following information. (...)
That means I  Support the suggestion: Between these two sentences in the Wizard, we should add another sentence, that could read like this: "Please note that you can usually not revoke your permission later."(en), "Bitte beachte, dass du die hier gegebene Einwilligung später nur in Ausnahmefällen wiederrufen kannst." (de), "Veuillez noter que vous ne pouvez pas révoquer votre autorisation ultérieurement, que dans des cas exceptionnels." (fr) and so on. In the spirit of making the sentence less legalese, I exchanged "licence" with "permission", and kept it short. If someone is alarmed by this statement, they should stop uploading and find the relevant rules. --Enyavar (talk) 14:35, 14 November 2025 (UTC)

Concur, though "usually can not" is better English than "can usually not". - Jmabel ! talk 19:44, 14 November 2025 (UTC)

Support.✅️

I'm not sure if this is still under discussion, but I agree with @RoyZuo and others who say that this should be stated clearly in plain English on the upload page (prior to uploading). Also, deleting from the website doesn't unilaterally equate to revoking the license, contrary to what someone suggested earlier. BetsyRogers (talk) 07:53, 15 November 2025 (UTC)

November 09

Date Own work Author

I've noticed numerous uploaded files where the Date, Author, and Source metadata fields are filled in a standardized but potentially misleading way : the uploading date for the Date property, the uploader's user name for the Author property, and the template "Own work" for the Source property, the latter triggering a bot to add the mention "source of file: original creation by uploader". However, in many cases—such as this file, that file or that one—it seems highly unlikely that the uploader actually created the content in 2023, as some of these files appear to date back to the 16th century. Without any supporting information beyond the file's upload history, how can we verify their true origin and actual creation date? This also raises concerns about the legitimacy of applying a "self CC-BY-SA-4.0" license. What steps can be taken to address this issue? 00:29, 9 November 2025 (UTC) William C. Minor (talk) 00:29, 9 November 2025 (UTC)

In the three linked examples, the underlying content is clearly old enough to be out of copyright everywhere in the world. It would be safe to treat these as {{PD-100-expired}}. You cannot (and need not) license public-domain materials. If the license has any meaning at all in these cases it would be to license any intellectual property that the photographer might somehow hold with respect to these images. Since they presumably have no copyright on any aspect of any of this, it is exactly as if I offered to license you my portion of the ownership of the Hope Diamond. - Jmabel ! talk 06:34, 9 November 2025 (UTC)

it seems highly unlikely that the uploader actually created the content in 2023 good point and this may also / does also affect other files where it's less clear. Maybe the UploadWizard should clarify that the date field is supposed to be the creation date (and if it's a scan / photo of an old document for example the old date should be in the date field). Currently, how that field is used makes it ambiguous.

One could also do a scan of all files in categories about old years and check whether the date field has any recent date in it to correct these. Prototyperspective (talk) 21:34, 9 November 2025 (UTC)

• Every noob does this, the hope is that they listen to the feedback and upload correctly next time. The upload form has been modified to help people choose the correct settings, but we easily have thousands of images historically loaded incorrectly. --RAN (talk) 02:10, 11 November 2025 (UTC)

I think. I am in a similar situation though I am the one who uploaded... Not about date but about "own work".

So there is an example https://commons.wikimedia.org/wiki/File:Gray_code_number_line_arcs.svg I found a png file and created a vectorized version of it. What should I write there. Is what currently on the page correct?

Upload wizard doesn't give you a way to convey semantics that image is made by you but it is derived from another from wikimedia... :/ At least it was when I was uploading for my last time... DustDFG (talk) 12:40, 11 November 2025 (UTC)

Agree, good point. The field is too ambiguous and the UploadWizard should provide more guidance on what to enter there. For example, it could display a prompt if the user enters an old-year category but a recent date or if the user enters an old date but declares the file to be "Own work". Such cases could (and imo should) also be queried and then corrected / disambiguated retrospectively.

See also the thread below – setting year categories based on the value in the date field can result in a few miscategorizations because of this ambiguity and lack of guidance. Prototyperspective (talk) 14:26, 11 November 2025 (UTC)

What I think would be sufficient is one clear notice to uploader which clearly distinguishes properties of depicted object like an old manuscript and properties of a medium like a photo/video probably with one or two examples. It is general enough to not repeat for every property and seems to be not too abstract so user can understand it and apply for every asked property.

But I understand that probably one notice is too perfect to really work and each case can be different and still have different ways to interpret so I think near each question should be icon of question symbol which will reveal detailed explanation (type of like you provided below "...be date of first publication where that is the key date (films) or date of recording where that is the key date..." DustDFG (talk) 15:01, 11 November 2025 (UTC)

I don't fully understand the first part of your reply such as what you mean with "for every asked property" when we were talking about the date field or where and how it would be similar for the other input boxes.

Yes, a hoverable info icon could be good enough and I'll ask about adding it at Commons talk:WMF support for Commons/Upload Wizard Improvements if nobody else does. May be best to additionally display something like "Date of recording" as the placeholder text in that input box (it disappears when the input box is clicked). Prototyperspective (talk) 00:15, 13 November 2025 (UTC)

In first part I meant that there can be added one big warning: "we are asking about properties of the object itself not a medium of it". It is general. But when uploader who read this notice applies this idea to date field for scroll, they understand it is about creation date of that scroll and not when uploader photographed it. When they apply that idea to author field, they understand it is about original author who wrote that scroll and not the uploader who is an author of photo. So the first part is about "generic" notice which user must apply themselves.

In the second part I meant that idea from first part maybe is too idealistic. Waiting from user to so each field will need to have their own explanation. The same "we ask about object itself not a medium" but sharpened for that specific field "we ask about date of first publication not about date of upload from place where you took it from and not about date when you upload it". So generally the second part is about the fact that generic way is probably unrealistic and people won't evaluate that generic thing to each field by themselves...

Second placeholder text! DustDFG (talk) 08:15, 13 November 2025 (UTC)

Thanks for the explanations! Got some doubts whether a sufficiently large fraction of users who would read that abstract guidance would understand it and correctly apply it to the date field. For example, many things in media aren't objects – such as a video of some event. Moreover, I don't think it really applies much to fields other than those two fields and the author field is already handled at the UploadWizard's license selector where e.g. 'contains the work of others' is part of it. Maybe it would good to have such a general note regardless, don't know. Prototyperspective (talk) 12:37, 13 November 2025 (UTC)

Criteria for setting Category:Videos by year categories? Set them by bot?

• Is there some rough criteria to which files videos-by-year categories should be added? (Category:Videos of 2024 etc)

I've mostly only added it to videos that are either notable (such as videos of films or year-specific events) and/or

where the year is important metadata such as videos extensively portraying cities (which look/ed quite different 50 years ago or 50 years in the future) or of events that occurred in that year.

If there are (or should be), please add this as info. The criteria may be less relevant to items in subcategories.

• Is there some script/bot that automatically adds years cats to videos depending on the year in the Date field of the file description?

This is tied to the question above – whether or not there is or should be criteria for which files should be in these cats (however, there could also be a subcategory that contain less notable/relevant files from a given year). If simply all videos of a year are supposed to be in there, I don't see why people waste their time manually categorizing files by year when this info is already there in the date field. However, it may be best to limit it somehow and/or require things to be in certain subcategories. In that case, a bot or multiple bots doing this categorization would still be useful.

• A small fraction of files have false date set but they'd either also be miscategorized when handled manually or could rather be identified later on, for example if they are underneath seemingly contradicting categories like 2022 events or 1980 works. Those are the exception.
• This is probably also related to thread the VP thread #Date Own work Author above, to Commons:Categorization requests#NASA videos from unidentified year, Template:Taken on discussion, and to VP/T: How to search fields of files' Information template?.

Prototyperspective (talk) 22:13, 9 November 2025 (UTC)

A small fraction of files have false date set I would think nearly all videos of archival film/video materials would have a false date in the in-file metadata. Is that not the case? - Jmabel ! talk 23:08, 10 November 2025 (UTC)

I don't know and it would be new to me; good question. Checked some files in Category:Videos of films by year and some (example) had the correct year set while some had the date of publication on YouTube (example imported from video2commons with the default date unchanged).

This category also makes clear how Commons categories could be used to check and change these ambiguous values in the date field. I think the date should consistently (expectably & standardized) be date of first publication where that is the key date (films) or date of recording where that is the key date (more or less any other videos; and these date values could be converted to use {{Taken on}}). Prototyperspective (talk) 14:34, 11 November 2025 (UTC)

November 11

The Commons brochure needs an update

File:Illustrating Wikipedia brochure.pdf is very outdated. Things look very different now. Maybe parts of the text need updates too but the images would be very confusing if anybody reads this.

That file is used on many pages, including en:Help:Pictures, en:Help:Files and meta:Commons brochure.

Alternatively, the document could be replaced by an entirely new up-to-date document. Note that in that case, most file-uses should probably also be changed.

See also Commons:Simple media reuse guide and Commons:Welcome. The file is of course relevant to the entire global Commons project.

Also posted this to Commons:File requests#Updated version of the Commons brochure and I suggest discussion continues there once this thread here is archived. Prototyperspective (talk) 23:25, 11 November 2025 (UTC)

November 13

How to remove exif fields from a published image

I have published on Commons an image taken in a home. This has the camera GPS coordinates. I want to delete the GPS coordinates from the EXIF in the Commons image file. I know how to delete EXIF fields on my laptop. If I upload a new version, will the GPS coordinates disappear from the image page? If not, how do I delete the EXIF lat-long fields? Any help would be appreciated. --Tagooty (talk) 04:25, 13 November 2025 (UTC)

@Tagooty: they will disappear from the page, but still be accessible in the file history. If you want them completely gone, ask for a REVDEL to get them out of the file history (admins will still be able to access them, but no one else will). - Jmabel ! talk 05:21, 13 November 2025 (UTC)

@Jmabel: Thanks! Tagooty (talk) 08:27, 13 November 2025 (UTC)

In my view re If you want them completely gone, ask for a REVDEL to get them out of the file history I think this process should be fairly quick and easy to protect privacy of users and info about this more findable. I'll check the FAQ whether it has info on this. Prototyperspective (talk) 11:50, 13 November 2025 (UTC)

@Prototyperspective: the really right way to do it is to remove such private data from the EXIF before you upload. Unless we can automate it to the point where little or no admin time is involved, I wouldn't want to encourage a lot of people to think it is "normal" to upload confidential content, then have it deleted. - Jmabel ! talk 18:50, 13 November 2025 (UTC)

Yes, of course. That could also be added to the FAQ and/or other places where users may see or look for it. I think there was a thread not long ago about making it easier to see and possibly change EXIF data during upload. The question I was adressing was how to remove EXIF data from an already published file which is the subject of the thread. One could suggest EXIF data to be displayed during upload at Commons talk:WMF support for Commons/Upload Wizard Improvements. Nobody wants to upload confidential content they don't want to have uploaded and then be required to do things to get it deleted anyway – this isn't about what people think is normal. Prototyperspective (talk) 19:15, 13 November 2025 (UTC)

November 14

Stopping MediaWiki message delivery from messaging me

Every few months, MediaWiki message delivery will leave a message on my talk page, informing me about picture of the year/month/day/hour/second votes, and honestly I couldn't care less. It's also very annoying whenever I get stressed about one of my files being deleted and I realize it's that. I would very much like t turn this off. Is there any way that would be possible?

I very much hope this signs me message automatically.

edit: it did not. Mohammad.darg (talk) 07:07, 14 November 2025 (UTC)

1. In the notification preferences in the preferences (at Special:Preferences#mw-prefsection-echo) you can disable the notifications for Web and Mail. Please comment whether this solves your issues or not. I don't know if there is a way to unsubscribe from / disable notifications for just MediaWiki message delivery & DR notifications.
2. If you press the Add topic button at the top as one is supposed to or alternatively the other large blue well-described button "Start new discussion", it will automatically sign your message. (And I agree talk page posts should be automatically signed instead of users having to worry about learning that they should do so and the wikitext syntax to do so.)

Prototyperspective (talk) 14:48, 14 November 2025 (UTC)

Thanks you for the response. Unfortunately, it doesn't allow me to disable notifications for one specific user. Thank you very much nonetheless. Mohammad.darg (talk) 17:51, 14 November 2025 (UTC)

Best way to migrate from unclear but widespread category naming system?

The naming system of many categories related to frescoes in Pompeii does not seem to match the spirit of Commons' hierarchical naming system.

Specifically, the paintings generally have two hierarchies, one rooted at Category:Ancient Roman frescos in Pompeii then descending to house → room (and sometimes a subcategory for a specific painting) and another rooted at Category:Ancient Roman frescos of Pompeii by Irelli-Aoyagi-De Caro-Pappalardo number (with 561 subcategories for specific paintings, walls or rooms).

This second system is based on the figures in volume 2 of a book called La Peinture de Pompéi edited by Irelli, Aoyagi, De Caro and Pappalardo. Volume 1 also has other paintings with their own numbering but those are __not__ part of the Commons categorisation system. Volume1 numbers overlap with volume2 numbers but refer to different paintings, however the category names do not mention that they refer to volume2. The pictures in volume 2 are no where close to a complete catalogue of paintings at Pompeii.

Just about everyone who goes to Category:Red oecus q, north of the peristyle is going to have a hard time discovering the painting/subcategory they're looking for, whereas descriptive names (e.g. 'Cupids making wine') would help greatly. Another example of confusion is described here.

Improvement?

Shouldn't this situation be improved? Does anyone have an opinion on the best course of action?

The Aoyagi-Irelli.. categories refer to specific paintings (or sometimes whole walls with multiple paintings) so it doesn't make conceptual sense for a painting to have both this category and a hypothetical new category that describes the painting. It also doesn't seem right to rename the category because then it loses the numbering information.

Would the right way be to create a new category with a descriptive name and then "tag" that category with the Aoyagi-Irelli number? This makes sense to me but I don't know how to "tag" the new category. Also, this would be a very large change (over 500 categories) and I don't know if the rest of the community agrees?

- User:BeakheadIntrados — Preceding undated comment was added at 10:51, 14 November 2025 (UTC)

I don't have any expertise here, but it sounds to me like your main problem here is with the naming of the categories based on Irelli-Aoyagi-De Caro-Pappalardo number. Is that correct? Is there another problem as well (in which case, please spell it out; if there is more than one other problem, a bullet list of issues at hand would be useful). At the very least, if those are drawn from two different volumes and the numbers overlap, it would seem that the volume should be part of the category name. As for the issue of whether the Irelli-Aoyagi-De Caro-Pappalardo number should be the primary way of naming individual paintings, I bet needs will vary wildly: as a rule, the more scholarly users will probably prefer those, the less scholarly will not. At the very least those should be preserved within the category pages, one way or another.

One possible pattern for a solution is the way we handle ships, with a category for an IMO number and a subcategory for a ship name. In that case, this is partly because a ship can have more than one name over the course of it existence, but still something like that might be workable.

Another possible pattern for a solution would be to pick a handful of languages and try to have descriptions for as many categories as possible be given in all of those languages. That would help greatly with the search problem.

Another possible pattern would be to add another hierarchy under Category:Ancient Roman frescos of Pompeii: Category:Ancient Roman frescos of Pompeii by subject matter, leading down to the same "leaf" categories. - Jmabel ! talk 20:04, 14 November 2025 (UTC)

Sorry for not being totally clear. Yes, my problem is that I don't think the Irelli-Aoyagi number should be the primary way of naming individual paintings, for the following reasons:

• It is not a standard way of referring to the paintings by scholars. Scholars use the title or subject matter along with the house, room and wall compass position (House, Room, north/east/.. wall). (There's no inventory numbers like in museums.) The Irelli-Aoyagi book is not 'canonical'. It would typically only be referenced by scholars indicating where a reproduction of the painting is to be found (but they could equally refer to another book or none at all).
• Further, the paintings in volume 1 (which has 200+ large colour plates, unlike volume 2 which has smaller black and white photographs) are mostly more "important" than those in volume 2. So it doesn't make any sense to arbitrarily pick volume 2 of this particular books.
• The way that the scholars refer to paintings seems much more intuitive for non-scholarly people too: it's common to read about (or see in real life) a painting and its location (particular house and room).
• If we really wanted to pick a book to number from Irelli-Aoyagi would not be the one but rather Pompei : pitture e mosaici in 11 volumes (1990-2003) which did try to be complete. However more paintings have been excavated since then so even this would not be adequate.

I really don't understand why this particular book has been chosen and it greatly degrades the name- and location-based categorisation system that would be more understandable to both scholars and non-scholars.

Adding 'volume 2' to the category names would not solve the problem, it would only entrench the situation.

The ship-like subcategory idea could work! It would conceptually be a bit weird because the Irelli-Aoyagi category would refer to the files in the subcategory rather than any files in itself, but that would be a good trade-off to preserve automatic 'tagging' of paintings in the main category with this number. An alternative would be to remove the Irelli-Aoyagi categories from the location-based hierarchy and but maintain them as a parallel, but they would quickly become out of sync because few people are going to be thinking in terms of this particular book's numbers.

Again though we're talking about 500+ categories and I would like to get some sort of consensus before making a change on that scale.

BeakheadIntrados (talk) 07:30, 15 November 2025 (UTC)

I agree with BeakheadIntrados that any system based on Irelli et al. is misguided, for all the reasons listed, and especially because this work is not a scholarly standard and is not normally cited by professionals in the field as a primary means of identifying a given painting. By far the best organizing principle for Pompeian wall paintings that are still in situ, or for which the original location is recorded, is the traditional numbering system by region, insula, and house numbers (e.g., VI.8.3), subdivided further by room and location within room as necessary. This has the advantage of being (a) universally intelligible to anyone interested in Pompeii, whether they are scholars or casual visitors, and (b) completely independent of any particular publication. It's the system adopted in Schefold's Die Wände Pompejis (available here for those with access to The Wikipedia Library), which, although it is three-quarters of a century old and lacks illustrations, is still the most convenient one-volume index of Pompeian wall paintings available, and is regularly cited in the scholarly literature. As the OP notes, the multivolume Pompei: Pitture e mosaici is more complete, because it includes the results of more recent excavations, but it's also much bulkier and more expensive, and most readers on both sides of the Atlantic will find it harder to locate a library that owns a copy. For wall paintings in the Naples museum (or, in a few cases, other museums) whose original location is unknown, citation by inventory number is universal. Cluttering up category names and hierarchies with identifiers other than these two widely recognized systems is not, in my opinion, helpful to anyone. Choliamb (talk) 19:31, 16 November 2025 (UTC)

link rot: digitallibrary.usc.edu

for example:

File:Spectators watching a bicyclist on Beacon Street, San Pedro, ca.1907 (CHS-4783).jpg

https://web.archive.org/web/20150928155242/http://digitallibrary.usc.edu/cdm/ref/collection/p15799coll65/id/17161 is broken because w:archive.org can fail archiving w:Ajax (programming) web pages, more than w:archive.today

http://digitallibrary.usc.edu/cdm/ref/collection/p15799coll65/id/17161 is now at:

https://digitallibrary.usc.edu/asset-management/2A3BF16PKMY

Piñanana (talk) 11:56, 14 November 2025 (UTC)

Are you asking for these files to be corrected? Checking insource:http://digitallibrary.usc.edu/cdm/ref/collection/ (assuming that's the url part to search for) suggests over 36,000 files are affected.

Since the identifier also seems to have changed I have no idea how this could be fixed – does somebody know? Maybe the organization can be asked to unbreak these links so they redirect?

I also noticed link rot (404) for source links of files in Category:Videos by Terra X where I notified the creator account. Prototyperspective (talk) 14:54, 14 November 2025 (UTC)

COM:INUSE and outdated charts

When files with old data are in use and there is a file with newer data but otherwise the same, does COM:INUSE mean the file with the older data can't be redirected to the file that also shows the newer data which preserves the file uses?

If it does mean that, should that policy be changed to enable this method / kind of updating data graphics?

See also Category:Wikimedia updating and Category:Charts by year of latest data.

• 
  Moore's Law Transistor Count
  1971-2016
  (closed DR)
• 
  1971-2018
  (closed DR)
• 
  1970-2020
  (the file I asked the two other ones to redirect to)

Prototyperspective (talk) 15:16, 14 November 2025 (UTC)

Have you looked at some of the places these are used and seen whether such a substitution would be appropriate? (In this case, I would guess it would). Commons Delinker can do a global substitution even without us redirecting the older files, but (just as much as with your redirect proposal) you'd want to make sure global substitution is really desired. - Jmabel ! talk 20:08, 14 November 2025 (UTC)

It's the same image except that the third one has more data. A substitution would be appropriate – the design and so on haven't significantly changed and the trend also hasn't. It would just mean data graphics aren't as outdated anymore in Wikipedia. This may not be a big problem in this case and more important for cases where the data shown for some disease is outdated by a decade but it's nevertheless appropriate and useful to do this here too.

Commons Delinker can do a global substitution Interesting, didn't know that. How can it be used for that? On User:CommonsDelinker it says It aims to prevent image links from visibly breaking on local wikis after a Commons file is deleted.. If it's nevertheless possible, I think just very few users know about it, and it's not as straightforward and known as a making DR (with a request to redirect the file). Moreover, the outdated files will still be on Commons instead of only having the up-to-date file which I think is very desirable unless the target file has a significantly worse/undescriptive file-title. Prototyperspective (talk) 18:28, 15 November 2025 (UTC)

Sorry but setting this as a general principle is a bad idea. The role of Commons is to act as a repository and not dictate which files other projects use. If one language version of Wikipedia chooses to present and discuss a set of data available in 2018 and another language version of Wikipedia chooses to present and discuss a set of data from 2020, what right do we have to enforce a substitution with a version containing 2025 data? Who is going to jump into those various language versions and update the narrative of the articles to align with the new data? If you want to investigate an individual case and make educated substitutions, then that is fine. Encouraging mass substitutions without proper consideration will create more problems than it solves. From Hill To Shore (talk) 19:18, 15 November 2025 (UTC)

The file used is outdated not on purpose and one could just replace all of the files manually but that would currently be a lot of work and won't be done as often. You're right though,

• Sometimes the dataset changes instead of staying the same and just getting new data points.
• It may be rare but sometimes articles may deliberately choose an older time-span, probably because newer data is thought to be of lesser quality (haven't yet seen any of these but if these DRs would be done more often it could be that some charts are used deliberately with old data as the article is about an old time-period/event albeit I don't think it's likely such a chart would get a DR)

Maybe the better approach would be to have for example a bot or a Commons script leave a notification on the article's talk page that one of the files has a newer version available so that users watching the Wikipedia article can manually edit. For a bot to do this one would have to mark a file as an older version of another chart with newer data somehow. Prototyperspective (talk) 20:11, 15 November 2025 (UTC)

Replacing a pseudo-SVG image with a real one

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 10:25, 16 November 2025 (UTC)

Basically, I've recreated Crystal Clear app home.png as an SVG and I want to upload it under a similar name. The problem is that the name has already been taken by a pseudo-SVG (SVG wrapper of a PNG) and I wonder if it makes sense for me to upload my version under the existing SVG file name, scrubbing the old one from existence since that one has no purpose if a real vector image exists. ManuelB701 (talk) 17:59, 14 November 2025 (UTC)

I think that is reasonable, with appropriate rewrite of the file page content. I see you don't have autopatroller rights. You should request them so that you are allowed to overwrite files. Please make sure you are completely familiar with COM:OVERWRITE, though. - Jmabel ! talk 20:15, 14 November 2025 (UTC)

a pseudo-SVG (SVG wrapper of a PNG) never heard of that – is it explained on any Commons page what such a "pseudo-SVG" is? Prototyperspective (talk) 17:56, 15 November 2025 (UTC)

I made up that word but they're all SVGs viable for {{FakeSVG}}. ManuelB701 (talk) 19:44, 15 November 2025 (UTC)

Thanks for explaining. So it's just a PNG file inside a SVG but not an actual SVG. In that case, just upload it as a new revision and in that case, scrubbing the old one from existence will not happen as the prior revision will still be there and could if needed be reverted to. Prototyperspective (talk) 19:58, 15 November 2025 (UTC)

Yes, but/and if the author information is about who wrote the SVG, that should also change. - Jmabel ! talk 21:56, 15 November 2025 (UTC)

It's like that for every new-revision upload. Prototyperspective (talk) 22:05, 15 November 2025 (UTC)

@ManuelB701: I added a template to File:Crystal Clear app home.svg that allows you to overwrite the file with your version. The old version is still available in the file history, but will no longer be in use. ReneeWrites (talk) 22:24, 15 November 2025 (UTC)

Done! Thanks everyone for you help! ManuelB701 (talk) 05:47, 16 November 2025 (UTC)

Vyshyvanka/Вишиванка

Can someone who's familiar with this type of dress take a look at File:Альона Ігорівна Мовчан.jpg and see if this is in fact a Vyshyvanka and if I've added the right category? This is a really beautiful dress she's wearing and the portrait is high quality. Thanks for your time. Geoffroi 20:59, 14 November 2025 (UTC)

Vyshyvanka basically just means embroidery. Вышивать (vyshyvat') = to embroider (literally).

I'd say the outfit qualifies as vyshyvanka. Nakonana (talk) 21:04, 14 November 2025 (UTC)

Thanks for the quick response. Can this be QI? Also, could it be VI for blue vyshyvankas? Geoffroi 21:13, 14 November 2025 (UTC)

What do QI and VI stand for? Nakonana (talk) 21:14, 14 November 2025 (UTC)

Com:Quality images and Com:Valued images. Geoffroi 21:16, 14 November 2025 (UTC)

I see, thanks.

If the image meets the quality criteria for QI / VI, then sure, why not.

It features classical vyshyvanka motives like rhombuses and crosses. Nakonana (talk) 21:28, 14 November 2025 (UTC)

I think File:День Вишиванки. Молода україночка у вишитій синій сукні серед квітів 14.jpg or one of the others in that series is probably better because they show the whole dress. Thanks for the help though. Geoffroi 21:47, 14 November 2025 (UTC)

Both dresses are modern variations and factory made. Apron (and it was part of many other ethnic female costumes) is obviously missing on second photo. Please note that pendant on first photo may be variation of w:en:Black_Sun_(symbol). EugeneZelenko (talk) 15:47, 15 November 2025 (UTC)

Looks more like a Svitovit (Свитовит), a pagan symbol. Nakonana (talk) 20:05, 15 November 2025 (UTC)

Thank you for the research. I've added this to the file's description. From my own research, I see that the reverse swastika (in the middle of the pendant) was never used as a separate symbol by the nazis. They only used it as a background for their version. Geoffroi 23:41, 15 November 2025 (UTC)

Also, the Ukrainian image caption which was added by the uploader says: "Красуня у вишиванці" (literally: Beauty in embroidered dress). Nakonana (talk) 21:13, 14 November 2025 (UTC)

November 15

Categorization question

File:Seattle Water Department worker driving ditch digging machine, 1927.jpg I don't think I've ever seen a machine quite like this. I did my best at categorization, but I suspect I didn't do well; I won't be surprised if we need some category we haven't got. - Jmabel ! talk 06:01, 15 November 2025 (UTC)

Nice photograph. There is an enwiki article about something called a w:Ditch Witch (for which we also have a category here c:Category:Ditch Witch). This might be related. (I haven't dug into it in any detail.) -- Cl3phact0 (talk) 07:25, 15 November 2025 (UTC)

Seeing that a cat about excavators was already set at the time of upload, would putting it in Category:Unidentified excavators or a new subcategory of it like Category:Excavators of unidentified types solve this? (Note: "Identify unknown objects" is already a task-type highlighted at Commons:Welcome and maybe it could get highlighted more if adding the file to the cat is seen as too unlikely to result in identification+categorization.) Prototyperspective (talk) 11:42, 16 November 2025 (UTC)

I added Category:Barber-Greene, the manufacturer. You can see part of the name "Barber-" above the driver's head. Commons has a good photo of a similar B-G machine in action: File:Drainage, machine, graven, sleuven, barber greene, Bestanddeelnr 160-0317.jpg. Mrwojo (talk) 16:49, 16 November 2025 (UTC)

I'd say it belongs to Category:Chain trenchers, although it is old, small and retractable - and that makes it look different -, and the chain has buckets instead of just teeth as most of the examples in the category. Pere prlpz (talk) 17:07, 16 November 2025 (UTC)

Icons of Madonna and Child

Shakko seems to have taken it upon himself to unilaterally empty Category:Icons of Madonna and Child and soft-redirect it to Category:Icons of Virgin Mary. Surely this is not the sort of uncontroversial move that should be made without discussion. I see that for at least some of these (e.g. File:Bucharest - Biserica Schitul Darvari interior 02.jpg, one of my uploads) he has substituted Category:Hodegetria instead. Literally no ancestor category of that indicates the presence of Jesus as part of such an icon (that could, of course, be remedied), so there is a loss of information.

Also related: I see that Category:Eastern Orthodox icons of the Virgin Mary was emptied and redirected to Category:Icons of Virgin Mary.

Again: my main issue here is not whether this is right or wrong, but that this is the sort of change that certainly merits a CfD or other discussion. I would like to have at least an after-the-fact explanation of what other related changes may have been made to the category hierarchy, and a (belated) opportunity to discuss what is desirable here. - Jmabel ! talk 22:08, 15 November 2025 (UTC)

Also, on File:Muzeul Vasile Grigore 05 - Madonna and Child with Saints Ermolaos and Mina, prophets and apostles.jpg I see similar changes; at least Category:Panachranta has an ancestor category indicating that it is a Madonna and Child. - Jmabel ! talk 22:16, 15 November 2025 (UTC)

November 16

Moving categories without leaving redirect causes broken links at Wikipedia

I noticed when moving categories without leaving a redirect – as one may want to for titles with typos or flaws or that are just the plural/singular form etc (pollutes the autocomplete) – links to the category in Wikipedia can become broken.

The move page doesn't inform the user much about this potential issue – it says The old title will become a redirect page to the new title. Be sure to check for double or broken redirects. You are responsible for making sure that links continue to point where they are supposed to go. but the user may not be aware that the category is linked from a Wikipedia page. One also can't see which Wikipedia pages do – Special:WhatLinksHere doesn't show them and the they're also not listed on the move page. Many Wikipedia articles just link dynamically to whatever Commons category is linked on the/a Wikidata item but apparently many(?) also specify the exact category title.

This is especially problematic when one wants to move a set of categories all named by the same schema. Usually, Wieralee moves files in the moved category to the target category but that's not the case for moves when no redirect is left. When moving multiple categories, one would have to check for each where it's linked on Wikipedia and also correct that(?)

See also Commons:Village pump/Technical#How to move (rename) many categories?

I think there may be quite a few moved categories where the links have not been updated on Wikipedia – is there any way to find them (if possible just the ones with broken links) so these can be corrected? Is there maybe a tool for category moves that would also change these similar to "Move & Replace" for files? Prototyperspective (talk) 00:16, 16 November 2025 (UTC)

Another benefit for those wiki's to just rely on Wikidata for this. Sjoerd de Bruin (talk) 22:45, 16 November 2025 (UTC)

Category:World War II ships of the Netherlands

A non-registered user is empying the categoies "World War II ships of the Netherlands]] the previous days. Is that a correct move? Stunteltje (talk) 12:22, 16 November 2025 (UTC)

Examples? Functional wikilink: Category:World War II ships of the Netherlands. Prototyperspective (talk) 13:15, 16 November 2025 (UTC)

Category:Hr.Ms. Sumatra (ship, 1926) from Category:World War II cruisers of the NetherlandsStunteltje (talk) 19:42, 16 November 2025 (UTC)

Why is my file being marked?

My file has been marked for Sppedy deletion due to copyvio. It was a screenshot for a discussion I was active in in the English Wikipedia Dispute Resolution board.

I understand the pictures inside the screenshot are not freely available and were used for fair use.

The screenshot was only taken and uploaded to English wikipedia for reference in the board discussion. Can there be no alternative? I don't want to commit copyright violations every time I want to have a screenshot in a discussion. — Preceding unsigned comment added by Kingsacrificer (talk • contribs) 15:09, 16 November 2025 (UTC)

There are several points to observe, Kingsacrificer.

1. Refrain using screenshots despite wanting them, use links and plain text instead.
2. Inform yourself about local policies - Commons:CARES.
3. Read and carefully follow en:Wikipedia:Non-free content, use en:Wikipedia:File upload wizard.

Regards, Grand-Duc (talk) 15:25, 16 November 2025 (UTC)

Also note that fair use is not acceptable on Commons, only on Wikipedia. Nosferattus (talk) 15:51, 16 November 2025 (UTC)

Thank you both for your response.

@Nosferattus I am aware that fair use is only acceptable on Wikipedia. As you know, when one tries to paste a screenshot in a Wikipedia discussion, the file is uploaded on Commons and then transcluded.

@Grand-Duc I appreciate your point about refraining from using screenshots. I do. In this case, I had to use it because the file history was gonna get wiped out as the file was going to be deleted even before the DRN discussion concluded.

I understand your view, but I want to re-iterate. If we have no other option and must include a screenshot, is there no way to do so without it getting uploaded to commons?

As can be seen, the screenshot that was taken was of a Wikipedia page, not of a Commons page.

Kingsacrificer (talk) 16:29, 16 November 2025 (UTC)

You can only rely upon local fair use guidelines, like one the linked EN-WP rule, as fair use is not allowed on Commons. Or use an external en:Image hosting service à la Imgur. Regards, Grand-Duc (talk) 16:35, 16 November 2025 (UTC)

If you open the main menu on Wikipedia and choose "Upload file", it gives you 2 options: "Upload your own or a freely-licensed file" or "Upload a non-free file". You need to choose "Upload a non-free file". There is also a link for this when you paste an image into the editor on Wikipedia. Finally, you can just go straight to "Special:Upload" on whatever Wikipedia you are using. Nosferattus (talk) 16:57, 16 November 2025 (UTC)

Okay, thank you @Grand-Duc @Nosferattus

I think Imgur would be the best way to go about it in the future. Cheers! Kingsacrificer (talk) 18:14, 16 November 2025 (UTC)

If a non-free file does not meet the requirements of the en.wikipedia policy for hosting non-free content on en.wikipedia, you cannot bypass the en.wikipedia policy by uploading that non-free file to Commons, because such a non-free file cannot be on Commons anyway. -- Asclepias (talk) 17:16, 16 November 2025 (UTC)

That was not my aim. Kingsacrificer (talk) 18:14, 16 November 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 22:34, 16 November 2025 (UTC)

Big PNG and small JPG dupes

User:Killboy010 uploaded:

File:Γκάντατζ.png 2,560 × 1,920 (9.98 MB)

File:Γκάντατζ1.jpg 640 × 480 (188 KB)

what to do in this situation? RoyZuo (talk) 15:29, 16 November 2025 (UTC)

Convert the large PNG into a JPEG and delete the other two? Nosferattus (talk) 15:53, 16 November 2025 (UTC)

Keep both, but add the higher resolution image as "other versions" to the smaller image. Wouter (talk) 16:42, 16 November 2025 (UTC)

Convert the large PNG into a JPG and overwrite the small JPG with the large one. Keep both files, but have them link to each other in the "other versions" field. ReneeWrites (talk) 16:58, 16 November 2025 (UTC)

Keep both versions or delete low-quality JPEG. Юрий Д.К. 18:50, 16 November 2025 (UTC)

Delete the jpg per F8 The file is an exact or scaled-down duplicate of an older existing file. but I haven't checked which of the two files was uploaded first and think an older would be good to change to another in that policy. Prototyperspective (talk) 22:37, 16 November 2025 (UTC)

We can retain different file types of the same image. See Commons:File types#PNG for details of a bug affecting thumbnails of PNG images. It is normally a good idea to retain a JPG version of a PNG file, where available. The PNG file is a lossless file type that is a good starting point for any crops or file conversions, while JPG is a lower quality compressed file that avoids the thumbnail bug. In this case, ReneeWrites' solution provides us with the best of both worlds; retaining high quality PNG and JPG files that serve both roles. From Hill To Shore (talk) 23:40, 16 November 2025 (UTC)

It is normally a good idea to retain a JPG version of a PNG file, where available Strongly disagree and a JPG is available for all files because they can/could all just be converted to jpg. It clutters search results and category pages and comes with lots of other problems without any benefit if the file-title isn't significantly better. Transcoding a jpg version at upload of PNG files could be something to consider. The bug needs fixing (and/or a workaround) instead of images being uploaded twice. Prototyperspective (talk) 23:46, 16 November 2025 (UTC)

Please read Commons:File types. There are plenty of advantages and disadvantages between file types, so saying this is "without any benefit" is incorrect. Instead, you see the increased categorisation burden as outweighing the problems with the different file types. Your preference does not negate the existence of other benefits. If you wish to change this, push to get the bug fixed (if it can be fixed) and gain consensus that the other issues explained in Commons:File types are secondary to categorisation issues. From Hill To Shore (talk) 00:01, 17 November 2025 (UTC)

No, I don't. There are lots of downsides and I named more than just that one. Another examples is bloating up feeds that people patrol or watch by up to twice the size. The file with the highest quality is best and can be converted to other file types if needed or alternatively be transcoded by the Commons software so that e.g. all PNG files have a jpg file version available in the file description page. Moreover, that bug doesn't even affect the file this thread is about or does it? Prototyperspective (talk) 01:01, 17 November 2025 (UTC)

Agree with User:Prototyperspective. The PNG is inherently a better, lossless format. It's only drawback used to be the demand for larger file sizes, but the internet has moved on since then. The thumbnail problem seems to manifest itself mostly in two-tone graphics and drawings. It is not particularly important and should be solvable. For those of us who do a fair bit of categorization, needless doubles are indeed a nuisance. Cheers Rsteen (talk) 02:58, 17 November 2025 (UTC)