Commons talk:Overwriting existing files

Archives 1, 2, 3, 4

See Archive 1 for the RFC establishing COM:OVERWRITE as guideline. This is the talk page about this guideline. Please use the upload help or a help desk in your language for questions about its application.

Disruptive policy

I find this new policy highly disruptive and in fact insulting. Nobody can update charts (e.g. File:Standard Model of Elementary Particles.svg) after they have done so for many years. It is absolutely usual for any editor to upload a new, improved version of a file. Blocking people from doing so because they are not the original uploader, is disruptive and offensive to the respective contributor. Nobody will want to work on improvements any more. The above mentioned file has been a replacement of a prior file since 2013, and many editors have provided updates over the years. I am the originator of the current version, yet I cannot update the file, nor can any other, while the prior originator is no longer active on Wikimedia. Same goes for many other files. This policy is a middle finger to quite numerous contributors and should to be dropped. Cush (talk) 18:24, 21 December 2023 (UTC)

@Cush: Hi, and welcome. You have triggered Special:AbuseFilter/290 by trying to overwrite a file that you did not originally upload. Please: read MediaWiki:abusefilter-warning-file-overwriting, Commons:Village pump/Proposals/Archive/2023/08#Limit file overwriting to users with autopatrol rights, and COM:OW again; don't trigger that filter again; and request Autopatrol group membership at COM:RFR when you think you are ready (once you have made more than 500 useful non-botlike edits), having that should allow you to overwrite. I also tagged that file with {{Allow Overwriting}} for you and everyone else similarly situated. You may also request that any other particular file or category of files be overwritable at COM:OWR.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 13:18, 22 December 2023 (UTC)

I have been the copyright holder of the mentioned file for ten years now, after the prior design was first adjusted and then replaced. But that is not the issue. This policy goes against the collaborative nature of Wikimedia and against the good faith edits of contributors. I have read the articles you hint at, and I find them appalling. All kinds of scientific charts or other presentations of structured information have been originated, modified, and enhanced by a multitude of contributors over the past decades. This is how this encyclopedia was intended to work. Now they are all blocked and are referred to some obscure policies and groups that require people to live on Wikimedia and not just work for it once in a while. Contributors are forced to join groups where people only manage other people's contributions, just to ask whether they could update material so that their respective edit would not be marked as abuse. That is degrading. If Files are uploaded that violate quality or legal requirements, they can be reverted. That ought to be enough. Furthermore, I resent the implication that I make bot-like edits and that someone judges their usefulness. Cush (talk) 15:53, 22 December 2023 (UTC)

If there would have been other solutions like merge requests for new file versions we would not need the current method of blocking overwrites. But getting complex new MediaWiki features would take many years. The problem you describe also only exists for existing files where the uploaded forgot to mark the file with {{Current}} or something similar as a file that should be overwritten. GPSLeo (talk) 16:43, 22 December 2023 (UTC)

Which contributor knows what {{Current}} even means or that it exists? I have seen it for the first time today, and I have been here over eighteen years. And how are the (many and severe) technical and organizational shortcomings of MediaWiki a just justification for killing collaboration? Editors should focus on the quality of their contributions and not on all the petty politicking about rules that has been going on on this platform for too many years now. With this policy, contributors are expected to debase themselves and beg and wait for some random group's approval, even for files that have had many edits over the years by many editors, and where the original uploader has perhaps long abandoned the subject. Usually, I can alter or fix and then upload files within minutes. If I have to wait for hours or days to perform an upload because someone demands to supervise, I will no longer upload. As I stated before, this is a middle finger to us contributors. Cush (talk) 18:38, 22 December 2023 (UTC)

Perhaps "Current" template needs more publicity, if some people continue complaining about this. Now that many things in Commons are to be redefined, this perhaps could be improved someway, but basically, the 2 Commons are to be differenciated: the Wikipedia-like files, that should include "Current", and the Wikisource-like, static files, that shouldn't. I also wonder why I can edit, even without logging in, works that are already complete in Wikisource, such as this. This goes beyond Commons, but the dual nature of Wikimedia projects should be more clearly defined: some things are to constantly evolve, while others are to remain forever as they are, and allowing edition of the last ones, only could make them worse. MGeog2022 (talk) 19:39, 22 December 2023 (UTC)

Well, first of all, "{{Current}}" is a bad name, as it does not implicate the template's purpose. Second, when a contributor uploads a new file, there should be a checkbox that will automatically place the template or any other collaboration option into the file properties, especially if the file has been released into public domain. And if some group insists on enforcing this policy even to ancient files, then the group members can be expected to go through all files and place the template themselves where applicable. The sheer amount of effort is then no valid excuse. Cush (talk) 09:38, 23 December 2023 (UTC)

@Cush, not all public domain files should be updatable (for example, ancient photos or documents), but I agree that a checkbox to mark a new file as "Current" (or other better name, if the template is renamed) would be a really good thing. Since a technical needs survey is being carried out, I'll suggest it there.

And if some group insists on enforcing this policy even to ancient files: the problem with ancient files is that many of them shouldn't be updated, so it's better to be cautious: when an updatable file is found, it's asked to mark it as "Current" to a user who can do it, and it's ready. That's better than risk overwriting many other files that should remain as they are. MGeog2022 (talk) 10:51, 23 December 2023 (UTC)

Request added (link). @Cush, you can comment on it if you want. MGeog2022 (talk) 11:07, 23 December 2023 (UTC)

I meant ancient as being a long time on Wikipedia, not depicting something old or of historical value. Maybe overall, files should be categorized by content. If it is of a documentary nature such as photos or scanned documents, the files should be treated differently from charts, tables, or other forms of presenting information that can become inaccurate or obsolete over time. Even so, even pictures of scanned documents or maps etc should be updatable by anyone if newer, better material becomes available. Binding a file to its original uploader is in any case not helpful, especially when considering that updates can occur decades later when the original uploader may not be around any more. Cush (talk) 11:21, 23 December 2023 (UTC)

I also meant that. Many files that have been here for much time, are historical documents (of course, many others not).

pictures of scanned documents or maps etc should be updatable by anyone if newer, better material becomes available: yes, if it really depicts the same document. The problem is when someone "updates" an old map, with a newer one, for example, or replaces "Bus from XYZ company.jpg" by a completely different photo of another bus from the same company, when a photo should remain the same (possible minor changes apart). And it seems that things such as this happened frequently. MGeog2022 (talk) 11:29, 23 December 2023 (UTC)

"I have been the copyright holder of the mentioned file for ten years now, after the prior design was first adjusted and then replaced. But that is not the issue."

that is exactly the issue.

Substantial changes or completely unrelated files

Major changes

Different files on the same topic

Changes to license

all these are not wanted for overwrites. respect for com:copyright is both morally and legally important. RZuo (talk) 10:32, 24 January 2024 (UTC)

Agree, this is the most stupid change done to the site. Why don't we just ban everybody from editing articles in Wikipedia because they could be vandals then? And only allow just a select priviliged caste to edit. Yilku1 (talk) 16:56, 20 January 2024 (UTC)

@Yilku1: Because we aren't. It's not "vandalism" really -- many well-meaning editors make the same mistakes. It's preventing what often seems like a logical action but which is actually a destructive action -- we are trying to prevent users from deleting other users' work, basically. You call it "edit", which sounds benign, but in reality it's deleting a previous contributor's work completely and replacing it with your own. Files are not articles -- for an article, you are trying to get the single best article for a given title. Commons is not trying to get the best image matching a particular file name -- we want as many choices for a topic as possible for others to choose from. Overwriting an image prevents that, and effectively deletes an existing file, and removes a choice. Another difference is that a Wikipedia article's copyright is assumed to be a group ownership of a single license -- but not files on Commons; they have many different copyright license which are owned by a single author. In many cases, "editing" can make a mess of copyright attribution -- there are copyright license aspects as well. The image that User:Cush was complaining about, he mentions that I have been the copyright holder of the mentioned file for ten years now. Right, but the file existed before that, and someone else owned that earlier copyright. Many derivative works were made of the original work, pointing back to that file as a source for the attribution -- but then he changed the author, and possibly the license, when fully replacing with a completely different image. Now the attribution on the previously existing derivative works looks like User:Cush was the original author, when they were not, and you have to dig through both earlier uploads and earlier file page edit history to discover the real author. If he had uploaded under a different filename, like the policy at the time said he should, then there would have been no problems -- he could continue to edit his image, and attributions elsewhere would not have been broken, and the previous user's work would have still been available as a choice rather than being removed from all projects permanently. To be sure, there are some situations where overwriting is a good thing (a higher resolution of the same exact photo). But the large majority of overwrites are done by users -- often experienced, well-meaning editors -- who are thinking along the lines that it's the same as an article, and not realizing the damage it can cause. Basically, if you are changing the author and/or license by uploading a new version, it should not be done on the same filename, but a different filename. Far too often, it's not. Carl Lindberg (talk) 17:36, 20 January 2024 (UTC)

If there is a problem just revert it, don't ban everyone from uploading. Yilku1 (talk) 17:50, 20 January 2024 (UTC)

We aren't banning anyone from uploading. We are trying to prevent overwriting. We want people to upload, just under a different filename. Not many people watch individual images other than their own, so the problem isn't usually noticed until it's far too late to fix with a reversion. And a revert then removes the second user's work, forcing them to upload again (and they may often not bother). That approach to overwrites has been shown to not work. Carl Lindberg (talk) 17:59, 20 January 2024 (UTC)

"We aren't banning anyone from uploading. We are trying to prevent overwriting". No need to be pedantic.

This changes basically ban 99% of people from correcting mistakes in images, and the only way is to be approved is if select priviliged caste deems you worthy enough to make the changes. This go against everything Wikipedia stands for. Yilku1 (talk) 02:03, 21 January 2024 (UTC)

Your assumption that we ban 99 % is totally wrong. 90 % of all edits here edits are done by users with this right. All active editors have this right. If you go to another Wiki or language version you will always have many restrictions until the local community finds you trustworthy enough. GPSLeo (talk) 08:04, 21 January 2024 (UTC)

"until the local community finds you trustworthy enough" That is not my experience. This seems new and particular to Commons. Who is the local community of Commons beyond admins who use this platform for holding influence over "ordinary" contributors by contriving policies and politics? Why would they themselves be trustworthy enough to make good decisions as a clique? Yilku1 is completely right that editors are discouraged from making updates to files (with changes propagating through all references). Suggesting to use a different filename is not helpful, as it would have no effect in all the national Wikipedias using the prior file or variants thereof. With these policies Commons is not protecting anybody's contribution, it is trying to own it. The once collaborative spirit of Wikipedia and Commons is gone. Cush (talk) 16:30, 23 January 2024 (UTC)

The local community of Commons would be the people who choose to work on Commons. Some of us have uploaded a number of files to Commons that might see use across Wikimedia without stressing about exactly where they might be used. Why would people who use Commons be familiar with problems that show up on Commons? It seems obvious.

"it would have no effect in all the national Wikipedias using the prior file or variants thereof" is exactly the point. Part of the point of this is preventing one user on Commons from changing every Wikipedia at once, no matter the local (and possibly touchy) consensus on, say, borders, or changing parts of the image that are mentioned in body text or caption, like colors.--Prosfilaes (talk) 01:29, 24 January 2024 (UTC)

So, when for a chart conveying a scientific subject new information becomes available, the policy wants only the original contributor to update all files in every variant and every Wikipedia. Same goes for visual/design improvements. Do I get that right?

Making charts and maps is somewhat more effort than just dumping photos into Commons, and the purpose is of course different. Commons is the storage for material used elsewhere, and because sooner or later material originating in other sites gets transferred here, contributors like me are forced to deal with all the bureaucracy and the obscure policies here. I occasionally contribute material but I do not live here. Cush (talk) 10:10, 24 January 2024 (UTC)

the policy wants users to overwrite only if they are making minor changes like updating info or correcting errors.

the policy seeks to prevent users from usurping other users' works and even removing attribution like https://commons.wikimedia.org/w/index.php?title=File:Standard_Model_of_Elementary_Particles.svg&diff=prev&oldid=796858164 .

since this user has violated this point of the policy and is now arguing about it, i think the new restriction is quite rightly introduced. RZuo (talk) 10:23, 24 January 2024 (UTC)

When new information becomes available, we want the upload to be a different file. The previous file was still valid at a particular time, and may still be useful in other situations, possibly even in other existing usages. Make a new file, which probably has a new or additional author anyways (and thus a different copyright owner), and switch links to that file. If you are the author of the original file, you have a lot more leeway. If there is a need to change the "author" field, it's almost always a mistake to overwrite. It is not -- at all -- similar to editing an article, and far too many treat files that way, thinking that changing them is in the same spirit of "anyone can edit" articles. The copyright and licensing do not work in the same way, and overwriting is often destructive. Fixing typos does not create a new copyright thus does not change an author or license, but many overwrites have problems in these areas. That is the crux of the problem -- most users do not intend to create problems with overwrites, and only intend to improve the article they are used in, but are unaware of other aspects (or want to ignore their complexity). You can't ignore the copyright complexity with overwrites -- you have to really understand all the issues, and that's the area most people want to ignore (understandably). So yes, if most files get pushed to Commons, the best way to avoid that complexity is to have a default for uploading changes as a separate file (while mentioning the source file). Most need to get out of the habit of overwriting a file just to change the image seen on Wikipedia; it's a constant source of problems. Carl Lindberg (talk) 14:27, 24 January 2024 (UTC)

I still fail to see the justification for punishing contributors. Look at a file like File:Ancient Orient.png, which is a map completely different from its prior version, but it still depicts the same thing. Why should people be blocked from updating or replacing such a informative depiction, of which there are countless other examples? Those who invent a new and spectacularly restrictive policy ought to be the ones who must also do the work to mark all Files accordingly, instead of enforcing an impractical requirement and expect others to just shut up and never enhance other people's work again, or otherwise beg some obscure group for approval because suspecting abuse is now the default position. This attitude is very uncollaborative if not insulting. Cush (talk) 12:19, 23 December 2023 (UTC)

Because that one should have been uploaded as a separate file, and the links on articles switched. It's a different depiction of the same thing, but not a duplicate image -- we want both available to be chosen. We aren't stopping anyone from improving pages, just from removing existing images when they do so. All we want is for people to upload under a different name -- you are overwriting someone else's work and saying it's worthless to be used again, by anyone on any project, when that happens. If you go back in page histories, you will always see your image, rather than the one which was there for many years before. People watching the article page don't get any notifications of the change, and there is no ability to change back if they disagree (not likely in that case, but not every case is that straightforward). Commons is about having more options. If images are used on other projects, such as say Wikisource which wants that exact image because it was part of a source document, it shouldn't be touched -- there are templates like those in Category:Dont overwrite-file templates because it happens all too often. People modify an image to improve one usage, but an overwrite changes all of them, on all projects, without anyone being notified really. Such an action does not let each project choose the one better for them, but makes the choice for all of them, and rarely do people check (or can read other languages to understand if a caption elsewhere is being invalidated). The COM:OVERWRITE guideline did not exist as it does now in 2010 when you made that change, but it has since 2012, and people still do not follow it. I'm sure another goal is to get more experienced editors the autopatrol right -- no reason for it to be obscure. In general though, I fail to see how it is all that much harder to upload the image under another name then switch the link -- that achieves the same result, and is the path the guideline wants people to take. Carl Lindberg (talk) 15:27, 23 December 2023 (UTC)

The File I originally referred is File:Standard Model of Elementary Particles.svg and has had 23 contributors in 15½ years, and the new policy now told 22 of them that neither are their past contributions appreciated, nor are new ones wanted. The File is used in numerous articles in many Wikis all over the world, albeit in various language-versions. In the English Wikipedia it is used in the infoboxes about all kinds of subjects relating to particle physics. What kind of "then switch the link" do you have in mind here? Cush (talk) 15:51, 23 December 2023 (UTC)

I do wonder if SVGs should be exempted from this change, as that is the most frequent valid use of updating existing images -- does seem to be blocking usage of tools like User:Rillke/SVGedit.js. SVGs are often incorrectly overwritten as well, but they are more meant to be editable in the first place. For the relatively rare cases where links everywhere should be switched though, you can make requests at User talk:CommonsDelinker/commands. That will at least get page and template watchers notified, and maybe particular uses can be reverted if inappropriate. Carl Lindberg (talk) 16:17, 23 December 2023 (UTC)

SVG files can not be excepted from this as edit wars on them are one of the main reasons for the policy change. GPSLeo (talk) 18:32, 23 December 2023 (UTC)

@GPSLeo: See also Commons:Requests for comment/Technical needs survey/Checkbox to mark new files as current on upload.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 01:51, 29 December 2023 (UTC)

the current version has different layout and design from the initial 2008 version. that's exactly a bad example for Commons:Overwriting existing files. who started the current design and overwrote the old version? RZuo (talk) 20:14, 23 December 2023 (UTC)

I believe that was User:Cush , in June 2013, who made the substantial design change. Much to late to revert now, but that would be against the (relatively new at the time) policy. I'm sure it was a better approach for the SVG, given that nobody reverted it, but that is exactly the type of thing we'd prefer in a separate upload. If User:Cush had uploaded it separately at the beginning, they would be free to continue to make updates/improvements to it as the original uploader. Carl Lindberg (talk) 18:18, 29 December 2023 (UTC)

@Cush: FYI.   — 🇺🇦Jeff G. ツ _{please ping or talk to me}🇺🇦 18:26, 29 December 2023 (UTC)

Feel free to revert the file to the design from before the overhaul. In mid 2020, there was a fuss over a super-urgent split proposal to separate the designs, but nothing came of it. I forget who the User was or where the request was posted. Cush (talk) 16:47, 23 January 2024 (UTC)

for future sake and everyone's benefit Commons:History merging and splitting/Requests/Archive 4#Split between years old revisions. RZuo (talk) 18:49, 23 January 2024 (UTC)

It was User:Speravir. Cush (talk)

Maybe I did not fully understand the matter of this thread, but you, Cush, could yourself still request a split pointing to my archived request and this thread we’re in. On the other hand I get the impression you still not have comprehended that in first place you shouldn’t have overwritten this file, but originally should have uploaded it separately. — Speravir – 00:34, 24 January 2024 (UTC)

I have no problem with anybody else going through all the bureaucracy of a request and then someone performing the split, but to be honest, the process is too convoluted for my laziness.

Maybe I should have started a new file, but a decade ago considerations were different. The focus was on the chart being as accurate as possible and visually pleasing. Ownership was not as important as it is today. Cush (talk) 10:27, 24 January 2024 (UTC)

If someone would like to do my work for me

I was in the middle of editing the page on Wikipedia for this cool plane. I ended up on the Commons page of an interesting but jpeggy and small image. I reverse-image-searched it. There's a higher-quality copy already on Commons under a different filename. File:North American Aviation plant, Inglewood, CA.jpg is in use on several pages. There is a much higher quality version of the photo at File:B-25 final assembly line at North American Aviation's Inglewood.jpg, which is also in use on several pages.

template:merge is only for merging pages. I don't think I can justify using category:duplicate because the higher-quality version has a slightly tighter crop than the terrible one, and the alternative actions suggested at that cat page are to request deletion and then if appropriate make the filename a redirect, or to have it renamed.

Having it renamed would remove it from articles on which it's in use on other projects and I don't know if a page here for a filename for which the file been deleted becomes "up for grabs", if a file: page can even exist without a file, and even if it can, I don't know if I still can't do anything because someone else was its originator and I'm not in the group of 7,000 or so users who comprise the "everyone" in the sentence "Wikimedia Commons uses the same wiki-technology as Wikipedia and everyone can edit it" who get to make edits to all the files on the file repository.

I am here because I want to be helpful. I am a normal user. Unless I go out with a camera or start trawling the rest of the web, this policy makes it so that the only helpful thing I can do specifically right here on Not Wikipedia, without enlisting the support of one of the aforementioned "everyone", is adding categories and metadata to files other people have uploaded. I want to stick the better file up as a new version of the old file, where the original uploader can revert the change if they're for some reason unhappy with it, and I want to make one of the pages redirect to the other. I want to fix the problem.

Commons:Overwriting existing files now tells me to request an exception for a specific file, or preferably, to "consult the creator or original uploader first as they are likely to do a better job of fixing issues".

On Flickr, I can upload my own file. I can replace my own file with new versions. I can tag another user's file. I can put that other people's file in galleries, which appear on the page for that file, in order to help others find more images on a similar theme. I can embed the image elsewhere on the web. But I CAN'T edit other people's files. If I want to do that, I have to submit a support ticket or message the user and ask if they'll do it for me.

This policy has turned Commons into an image-hosting site with unconventional content policies.

I post on Reddit. When I want to post an image, I drag it to my desktop, stick it on Imgur, and post the link to the site. There's every chance it's already been uploaded and posted in exactly the same manner, it's elsewhere on Reddit, it's elsewhere on Imgur, but I'm not going to go looking, because that's too much hassle.

I like to edit Wikipedia. By its nature, editing Wikipedia involves interacting with Commons, so I do have edits here and if I see something I can fix while I'm here, I sometimes try - but MOSTLY it's just editing Wikipedia. Maybe an eighth of time spent "editing Wikipedia" is doing things on Commons. It could be YEARS before I hit the "more than 500 useful non-botlike edits" threshold, especially since the editing I can do without getting help now amounts to categorisation gruntwork, and I don't think that, if pressed, supporters of this policy would qualify adding [[category:aeroplane]] to things as non-botlike. If something's wrong with an image on Commons and I want to fix it before I use it, there are so many situations where it is now so much less hassle for me to just upload a fixed version with a new filename and use that for whatever than it is to do it correctly. And doing that means I'm using this tool incorrectly, unless I endure a massive amount of faff. Am I going to go to the original file's page and click edit source and copy its list of categories over to my new version and replace the images in articles, perhaps on several languages of Wikipedias, with my new upload, and post a message to the original version's talk page to say I've uploaded a new version and consult the creator or original uploader to tell them they need to to do a better job of fixing issues than everyone???

...actually, it turns out that YES, I will do that, one time. Last week I was here, I found this, I liked it, I looked for a higher quality copy, I found one, I tried to upload it as a new version of the file, I ended up here. I read the discussion and was confused and frustrated. I reuploaded it under a new filename, I copied the cat tags across, I replaced the embed in that article, I posted a message to the OP's talk page, they replied, it worked. But IT WAS SO MUCH FAFF.

I do not want to submit a support ticket. I do not want to grind edits like I'm playing WOW to get autopatrol rights. I haven't even put anything in my user page here yet. I do not want autopatrol rights. I want to be able to be helpful. This change has made it massively more difficult to be helpful on this site, and to use this site to be helpful on the other Wikimedia things. It has turned fixing something here from a manageable diversion while doing work elsewhere by clicking a few things into: typing and waiting and thinking about obtuse wiki politics lore and reading user talk pages to see if they're the sort of person who will be helpful if asked and asking and waiting for responses and so much more and I have definitely forgotten all about the page I was trying to tidy up by now.

"We want to make it easier for everyone to share what they know." That's not from Wikipedia:About, or Commons:About, their individual scopes are not relevant, it's from https://wikimediafoundation.org/about/, and this change has made it harder to use this tool in pursuit of doing that. "Everyone" is not 7,000 gatekeepers. I do not care that there was a discussion at the village pump here. There is a community here, but this tool isn't the community. This isn't a village, it's a website which works as a media file repository, and it's a Wikimedia website which functions as a tool wot's for repositing medias for using on other Wikimedia projects. It's used for all the other projects, all 300 languages of Wikipedia, there are some hundred-million-plus files uploaded here...but only 7,000 users of the tool have crossed this threshold because it's a a community engagement metric and this is just a tool they use, not a community they're a part of. They're not in the village visiting relatives and going for a pint. Users who mainly focus on maintaining other projects rather than checking out all the meaningful banter at the pump here can't use this tool effectively any more. I do not care if reverting this policy would mean a tiny subset of users, the ones who can click a rollback button or whatever steps they have to take will have to do that more often - if it would make their efforts to maintain this site, KEEPING THIS TOOL USEFUL, not worth their time...it's not a job, they're here by choice, if they want to retire there's a template for that and everything. I just want to be helpful. One cookie (talk) 16:50, 12 February 2024 (UTC)

@One cookie dont know what you are talking about. what do you want to do with those 2 files you linked in the 1st paragraph? anything preventing you from just using whichever file you want? RZuo (talk) 19:01, 12 February 2024 (UTC)

(Not addressing the main point, but might I suggest that we put a link/mention of each file on the other file so that in the future people don't have to do a reverse image search to find out they both exist?) -sche (talk) 19:21, 12 February 2024 (UTC)

Yep, that can be a nice idea. The information template has an "other_versions" parameter for this -- either links, or inside a gallery tag. You can also edit your user preferences under "Gadgets" to add the "Tineye" and "Google Images" tabs on an image page, to make reverse searches easier (and tineye can filter on Wikimedia.org). The other usual way is to look through the categories the image is in (more specific the better) to see if there are other versions of it. Carl Lindberg (talk) 01:50, 13 February 2024 (UTC)

Trying to see if I understand the above. The link to the article in the first paragraph is broken, so not sure which was using the bad image. But I do see we have several versions of that image:

• File:B-25 production Inglewood Oct 1942.jpg pretty small black and white version, but uploaded long ago and probably was used in pages at some point.
• File:North American Aviation plant - B-25 Bombers.jpg Larger, color version
• File:North American Aviation plant, Inglewood, CA.jpg Slightly color adjusted version of the one above, uploaded by the same person a couple weeks later
• File:B-25 final assembly line Inglewood 1942.jpg Very large color but highly JPG-compressed version
• File:View of the B-25 final assembly line at North American Aviation1a35295v.jpg Version scaled down from source version at loc.gov
• File:View of the B-25 final assembly line at North American Aviation's Inglewood, California, plant LCCN2017878501.tif 190 MB archival TIFF version from loc.gov, which is usually the preferred version to start from for someone making edits/crops
• File:B-25 final assembly line at North American Aviation's Inglewood.jpg Very large color-adjusted and cropped version, probably starting from the loc.gov version directly.

If there was a usage of that small grayscale one, by all means edit the Wikipedia article, and change the file reference to the one you prefer. No change needs to be made on Commons. If you want a different crop/coloration, then please upload as a different file, and again edit the Wikipedia article to choose your new upload. There is no action needed (or wanted) on Commons to switch images on Wikipedia articles -- the file reference is in the source text of the article. The links on the image page are all for unrelated operations, none of which you probably want. Correct that there is no merging of images (Commons wants options for projects to choose from). Renaming is pointless (that is only for filenames with errors or some other defined reasons; we try to avoid renaming in most cases). As you guessed, duplicate is only for exact duplicates -- same photo, same crop, same color adjustment, same copyright license. None of the above are duplicates. If you found a better or different version you want to upload, please do -- but do not overwrite; use another filename. We want that new option to be available, but also for projects to choose. If a file is used on two articles or projects, and one project wants to revert while another wants to keep the new one, uploading with the same filename prevents that. Each usage should be able to independently revert per their choices. Overwriting deletes an existing file, basically; we hardly ever want that.

As for your second example, it sounds like you found File:Vickers Vulcan Type 61 G-EBET (148227972) (tight crop, white balanced, grayscale).jpg, and a better/different scan that you then uploaded at File:Vickers Vulcan G-EBET, 1923.jpg because you could not overwrite the first one. The grayscale one itself was extracted from File:Vickers Vulcan Type 61 G-EBET (148227972).jpg, which does look like the exact same image (just lower resolution) than you uploaded. In this case, overwriting the grayscale one (if that was indeed your first instinct) is not a good idea. That is exactly why the new block is here -- the policy, for well over a decade now, is that we do NOT want an overwrite in that situation, as explained earlier -- we want more choices. So if that was your intention, the block prevented you from doing the wrong thing. Nor would we want a direct overwrite of File:Vickers Vulcan Type 61 G-EBET (148227972) (cropped).jpg, as that is also a different crop. However, overwriting the original File:Vickers Vulcan Type 61 G-EBET (148227972).jpg would be fine, as it does appear to be a higher-resolution version of the same scan of the same photo, and there are no copyright differences between them (such as one license on a low-resolution version, and a more restrictive license, or no license at all, on a higher resolution version). So yes, provided you had worked your way back to that source image, that was a correct action which was prevented by the new policy. If your intent was to change the Wikipedia article though, you would have still needed to change the Wikipedia article text to point to that file, same as if you had uploaded with a different filename.

To overwrite the grayscale, you would need to make the same adjustments. Unless you work hard on getting the same exact crop and white balance, it could still be preferable as a separate file. In almost all cases, editing the wikipedia article to point to the new file is a necessary and expected step -- and is more desired as then watchers of the article will be notified of the change, and can discuss there if there is any disagreement. It looks like the other user did that for you on the Vickers Vulcan en-wiki article, but that is something you could have done yourself right after uploading the new version. Notifying other users is certainly nice, but not a requirement. You could add links to the the other crops in the other_versions area of the Information template on the image page so that others viewing it see there are other options, but again not a requirement (though that would tend to notify the original uploaders too, as they would normally have a watch on their file). As long as they are in the same category, other editors can add find them and those links or galleries that too. (For example File:1944 NormandyLST.jpg lists several other scans of the same photo, which all look different -- we don't want to merge or overwrite or anything there; each different scan should be its own file so each project can determine which is best for their usage.) In this case, since you have uploaded under a different file, you could put {{Duplicate}} on File:Vickers Vulcan Type 61 G-EBET (148227972).jpg since that does qualify. Or you could edit the file page to use the {{Superseded}} template so anyone looking at the file knows there's a better version in all respects. None of this requires autopatrol access. When overwriting, you need to make sure it's a near-duplicate in the first place, and be aware of any possible copyright issues. These are often complicated, and not always fully understood, and overwriting should be avoided unless you get familiar with them.

If there is a case where we should replace many usages of a file across many project (Wikipedia and others) with a new file, a request can be posted at User talk:CommonsDelinker/commands.

That all said, we could possibly make this easier for people to do. Right now there is an all-too-tempting "Upload a new version of this file" link for people to use on the image page, but that is what can lead them right into this restriction. A similar link of "Upload a modified version of this file" which starts with a copy of the file page text content, and adds (modified) or something to the filename, while allowing any of the text or filename to be edited might be a nice feature, and lead people down a better path. Carl Lindberg (talk) 01:41, 13 February 2024 (UTC)

Added {{Other versions/B-25 production Inglewood Oct 1942}} to those file pages. Glrx (talk) 05:47, 13 February 2024 (UTC)

Don't argue against individual examples. Even if you're right, proving one example incorrect doesn't negate an argument, that's fallacious.

All of the tagging you suggest would be helpful for people browsing Commons, looking at files, one-by-one. I do not care about that. I pointed out that I do not care about that. I pointed out why I do not care about that. I pointed out why it's pointless, and why being able to tag and add templates and add to categories is inconsequential for my goal. I can see that you've replied elsewhere to people who have the same obvious problems with this policy change, you weren't trying to see if you understood the above. You reframed the argument, and then argued against your new version of it, and started going on about how the examples given didn't apply to your new version of my argument.

I want to be able to improve or fix files hosted on Commons in-situ so that they are fixed where they are in use, outside of Commons. I don't want to suggest an alternative link to people who are browsing Commons reading talk pages, or tag duplicates, or make a new page for a duplicate of an image, fill out all of its tags and rights information, and then individually change the embed on every page on which the bad file features.

Here is a very straightforward example:

• https://commons.wikimedia.org/wiki/File:Weimarer_Republik.png.

I noticed that file had a problem while reading a page on en.wikipedia.org. I fixed it. I uploaded it as a new version of the file.

In doing so I fixed pages on en.wikipedia.org, de.wikipedia.org, mk.wikipedia.org, pnb.wikipedia.org, pt.wikipedia.org and ur.wikipedia.org, all in one go, without ever having to visit those wikis at all, and I can't do that any more.

That is what overwriting files is for -

[OK] As a general rule, use the link "Upload a new version of this file" only for relatively minor improvements. Examples include:

• replacement with higher-resolution versions of the same file, however, without using artificial methods to generate higher resolution
• minor and uncontroversial color correction, noise reduction, perspective correction, etc.
• removal of a watermark
• needful 90/180/270° rotation or minor rotation correction of images that are not upright
• minor cropping
• uncontroversial corrections to diagrams, maps, or charts, if a more accurate version is available
• correction of SVG errors
• adding or correcting translations, fixing spelling errors (e.g. changing "grater" to "greater")

Those are not uncommon problems - so to further repeat myself, out of all users of every language of every wiki site, only 7,000-ish users can solve those problems without having to either go through a multi-step arbitration requiring actual human time, or do it the wrong way - upload a duplicate, use Template:Duplicate to justify a speedy-delete of the original page and the file history, and edit every page the file's used on, individually. Contributing to every wiki has been made more difficult.

Most users who decide uploading a fix isn't worth the time and effort won't come here and write diatribes about this stupidity. They won't go to the Wikimedia village pump. You will never hear from them. They will see that the policy is that they can't help, that they can only ask for help, so they will move along, and they won't contribute.

The lower-resolution duplicate of the photo of the Vulcan is at https://commons.wikimedia.org/wiki/File:Vickers_Vulcan_Type_61_G-EBET_(148227972).jpg. One cookie (talk) 00:00, 19 February 2024 (UTC)

a user who wants to use his/her "correct" version of a file can always simply upload it and then use it on other wmf projects, so none of this analysis about users being stopped is accurate. RZuo (talk) 04:07, 19 February 2024 (UTC)

That is not "simple". All the data and metadata has to all be entered manually, copied and pasted across field by field, every time, which is not simple and takes ages. There isn't a button to copy every bit of information and metadata on a file's page except for the file and use it to make a new page, because if it were that easy, it would result in even more unnecessary duplicate pages (ie, the thing you are suggesting as a solution to the problem that has been created) - do you think it would be good if categories showed every version of every file individually, all at once, in a way which can't be disabled? Thumbnails for high-resolution and low-resolution copies of the same files all next to one another?

If you have OW rights, rather than me uploading it with a new filename and entering all the data and editing the pages on English Wikipedia and Hungarian Wikipedia and Italian Wikipedia and Polish Wikipedia and Portuguese Wikipedia and Turkish Wikipedia and Vietnamese Wikipedia so the images embedded on those pages aren't the old low-resolution version any more, all separately, would you please download the tiff at https://www.history.navy.mil/our-collections/photography/numerical-list-of-images/nhhc-series/nh-series/NH-97000/NH-97885.html, crop it appropriately, save it as a JPEG at quality 10, and upload it as a new version of the file at https://commons.wikimedia.org/wiki/File:USS_Wichita_(CA-45)_underway_during_a_winter_storm_off_Iceland_in_January_1942.jpg?

I'd do it, but I can't. One cookie (talk) 15:34, 11 March 2024 (UTC)

upload and use the tiff. RZuo (talk) 08:31, 12 March 2024 (UTC)

Commons:Overwriting existing files#Substantial crop or un-crop has some guidelines for what users used to be supposed to do in this sort of situation, so what you need to do is replace the file with the tiff and then follow that up by replacing it with your cropped copy. That way, the different file versions are in the "file versions" bit of the file page, and not disparately spread around under awkward slightly-different file names which uselessly won't appear under any single link! And then edit that page, because this change has broken lots of other pre-existing guidelines on it too. One cookie (talk) 02:26, 13 March 2024 (UTC)

File:Felicien Rops, L'idole (1882) heliogravure (27.6 x 20 cm) Michael C. Carlos Museum, Emory University, Atlanta.jpg

This image is a lower-resolution version of the file at its provided source, please upload the source image as a new version One cookie (talk) 11:11, 15 March 2024 (UTC)

They've never replaced the JPEG with the TIFF; it's never been legal to upload a file under an extension that doesn't match its type. TIFF files have always been uploaded separately from any JPEG version.--Prosfilaes (talk) 18:06, 15 March 2024 (UTC)

There are times where an overwrite is appropriate. The problem has been that most overwrites which are actually done, are not. If you think you understand the copyright issues and will keep the overwrites within the guidelines, then please request access to the user group. If you don't want to do that, then you can always upload as a separate file. Instead of copying information field by field, you can use the experienced upload, where you provide the entire file page text, and start with a copy of the one that you are providing an alternative for (just click edit on the image page, and copy all the content). It may be a good idea if we can give people a link to automate that, just as easy as that enticing "upload a new version of this file" link. If you need to replace the image on multiple wikipedias, add a request to User talk:CommonsDelinker/commands. Obviously this is a little harder than simply overwriting the file, but easier than editing each wiki and it should be relatively rare to need it. I don't think anyone is saying there are no legitimate reasons to overwrite a file -- there are. Unfortunately there are also many, many bad reasons to overwrite, and the majority of overwrites were in that area -- ones that were not following the 10+ year old policy, and some were doing a fair bit of damage. The question is how to stop those, and this was the way which seemed actually work. Even longstanding editors, whose habits were set years ago, make these mistakes -- since they seem OK at first blush, treating files like a wiki article, but usually are not. The question is how to stop editors from doing overwrites which don't conform to the guidelines. Carl Lindberg (talk) 20:29, 15 March 2024 (UTC)

"Don't argue against individual examples. Even if you're right, proving one example incorrect doesn't negate an argument, that's fallacious." If there's a reason to offer an example, there's a reason to show that that example doesn't apply.--Prosfilaes (talk) 16:06, 19 February 2024 (UTC)

Ignoratio Elenchi, according to Aristotle, is a fallacy that arises from "ignorance of the nature of refutation". To refute an assertion, Aristotle says we must prove its contradictory; the proof, consequently, of a proposition which stood in any other relation than that to the original, would be an ignoratio elenchi. Since Aristotle, the scope of the fallacy has been extended to include all cases of proving the wrong point ... "I am required to prove a certain conclusion; I prove, not that, but one which is likely to be mistaken for it; in that lies the fallacy ... For instance, instead of proving that 'this person has committed an atrocious fraud', you prove that 'this fraud he is accused of is atrocious'... The nature of the fallacy, then, consists in substituting for a certain issue another which is more or less closely related to it and arguing the substituted issue. The fallacy does not take into account whether the arguments do or do not really support the substituted issue, it only calls attention to the fact that they do not constitute proof of the original one… It is a particularly prevalent and subtle fallacy and it assumes a great variety of forms. But whenever it occurs and whatever form it takes, it is brought about by an assumption that leads the person guilty of it to substitute for a definite subject of inquiry another which is in close relation with it.

— Arthur Ernest Davies, in: "Fallacies" in A Text-Book of Logic

One cookie (talk) 11:20, 15 March 2024 (UTC)

Despite that huge block of text, I stand by my assertion; if you're going to include examples in your arguments, it's reasonable to dispute them. If they don't matter, don't include them. If you argue "this fraud he is accused of is not atrocious", then it's entirely reasonable for people to respond "the fraud he is accused of is indeed atrocious".--Prosfilaes (talk) 18:01, 15 March 2024 (UTC)

Technical guide for overwriting

is there a technical guide about how to overwrite, instead of this policy page explaining why? RZuo (talk) 10:41, 21 February 2024 (UTC)

Remove or move statement.

The following statment disrupts the flow of the information in the Substantial crop or un-crop section.

When cropping a JPEG image, remember to always use lossless cropping.

Personally, I do not think it belongs in this article but if it does it should be somewhere else. User-duck (talk) 05:03, 23 March 2024 (UTC)

Example need copy edit.

• Example: This 1899 portrait of a young man with a fish by Wilhelm von Gloeden was uploaded in 2005 but then overwritten in 2010 by a full length un-cropped version. ...

"a full length un-cropped version" should be linked to an archived version of the file. It has been overwritten a few times since 2010. If the example is intnded to show the history, It should be reworked. User-duck (talk) 05:20, 23 March 2024 (UTC)

semi-protected edit request

In the section: DO NOT overwrite § Exceptions to the minor changes rule

Please change

• Digital restoration

to

• Digital restoration (of historical documents/artworks)

Emdosis (talk) 06:43, 10 September 2024 (UTC)

When in doubt ... upload as a new file.

I understand the reason for that advice. It would be helpful if the page provided instructions on how to actually do the upload, while respecting the copyright of the original file. Maproom (talk) 07:47, 25 September 2024 (UTC)