Commons talk:Overwriting existing files

From Wikimedia Commons, the free media repository
Jump to: navigation, search

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.


Change title to "Commons:Changes to existing files", because that is what this is about - when to create a new file and when to upload a new version. It is not about "Overwriting existing files". Moving it will automatically create a redirect from "Commons:Overwriting existing files". Delphi234 (talk) 03:15, 8 September 2012 (UTC)

Overwriting and changing are functionally the same thing. Sven Manguard Wha? 04:55, 8 September 2012 (UTC)
I don't see the need. The "overwrite" terminology and COM:OVERWRITE shortcut for it are quite familiar to many people, so I wouldn't rename away from that without good reason. Rd232 (talk) 10:27, 8 September 2012 (UTC)
Changes seems to ignore the common case of replacing the file with a whole new one.--Prosfilaes (talk) 21:23, 8 September 2012 (UTC)
I oppose the proposal. To create new (derivative as well as non-derivative) files and upload them is (itself) uncontroversial and is not the matter of this guideline. This guideline is focused specific on the problem of overwriting existing files. --ŠJů (talk) 23:59, 5 January 2013 (UTC)

Reproductions of two-dimensional works[edit]

I think, the guudeline should mention a question of reproductions of artwork and documents. I propose to add into the section "DO overwrite" (please correct my ungainly English):

Better version of a reproduction

If the uploaded file is a simple reproduction (copy, facsimile etc.) of the original work (photo, painting), document etc., it can be ovewritten with a better version. However, when the copy or reproduction itself could be considered as a creative or important derivative work, it should not be ovewritten. Usually, photographs of three-dimensional works are considered as creative derivative works and shouldn't be overwritten not even with a better version; simple copies and photographs of two-dimensional works with no perspective distortion and no special illumination are not considered as an additive creative work and can be overwritten with a better version. Don't overwrite a reproduction which should document the condition of the depicted subject.

--ŠJů (talk) 00:27, 6 January 2013 (UTC)

This is not always so obvious. Take as an example my own batch uploads at Category:Chromolithographs at Boston Public Library. There are many duplicate prints in this category and sub-categories, however choosing the best version and just keeping that visible is not to the greater benefit of open knowledge. Wear and tear, printing marks, differences in print runs and even some pencil mark-up in the margins are all useful to notice and may help identify information about the print that is not yet documented (even by Boston Library in their catalogue). This may not be so true with pure digital variations (such as different sizes or crops), but with scans of printed images there needs to be more in the guideline than just encouraging users to overwrite an apparently inferior version. Thanks -- (talk) 01:12, 6 January 2013 (UTC)

EXIF information[edit]

It should be added:

DO overwrite

A file without EXIF metadata or with incorrect or incomplete EXIF metadata can be ovewritten with a file with original, corrected or added EXIF metadata.

DO NOT overwrite

A file with EXIF metadata should not be ovewritten with a file without EXIF metadata (even if the main change falls under "DO overwrite" cases). When you made whatever change of any file, pay attention to sustaining of metadata.

--ŠJů (talk) 01:43, 6 January 2013 (UTC)

collaborative efforts unlikely to be controversial[edit]

I think an addition would be handy, something like

✓ collaborative efforts unlikely to be controversial, such as Commons:Graphics Lab requests.

Penyulap 07:41, 11 April 2013 (UTC)

I don't agree unless the author of the original is a collaborator and the overwrite is shortly after the upload of unedited version. This case is already permitted by the criteria. I don't understand why people want to overwrite rather than upload with a new name. My experience is that the former wastes time and causes conflict. --Walter Siegmund (talk) 17:00, 11 April 2013 (UTC)
I can't see the case of collaboration, there is no tick in the box for it. Penyulap 17:30, 11 April 2013 (UTC)


I disagree with the rule saying QI/VI/FP cannot be adjusted at all. The author/uploader should be able to make some minor fixes or upload a higher-resolution version or change EXIF data, etc. A recent example was where an image passed QI but was clearly rotated and that needed fixed to stand any consideration for FP (yes I know the standards are supposed to be the same, but..) I think instead we should say that the change should be uncontroversially a minor improvement, and generally only by the original author/uploader. For example, someone "helpfully" changing the colourspace or white balance or crudely applying more noise reduction could all be controversial. We really don't want someone to have to renom and delist their FP just to remove a dust spot. Colin (talk) 12:26, 9 September 2013 (UTC)

I dunno. I do not consider rotation to be a minor change at all. How FP QI or VI run their processes should have zero impact on this guideline, in my opinion. If the problem is that FP requires delisting, then the solution should be found within FP, not here. On the other hand I do see that Commons generally allows changes shortly after first upload, maybe within a day. Those cases are covered by the three green-ticked cases under major improvements. And now, having looked at what counts as "minor", I find each can easily be controversial, but I have become quite biased towards the never (or hardly ever) overwrite position. Why? I've seen too much controversy and wasted editor time (e.g. map edit wars), all avoided by having "changed" versions uploaded under different filenames. -84user (talk) 15:06, 12 September 2013 (UTC)
A fraction-of-a-degree rotation to fix a faulty horizon is certainly a minor fix. As is removing dust spots. Or CA. Or any number of other sensible things that people might do that are clear improvements. This is less to do with FP/QI process and more about regulations getting in the way of improving Commons/WP. An image that makes QI or FP has a higher than normal chance of being used on WP. So who is going to change all the links on the various WPs, including ones I don't have an account on? And then we're left with our repository containing two virtually identical images but one has dust spots. Are you really saying we have to waste people's time on QI/FP/Wikipedia re-reviewing images, and changing image links just so someone can fix a dust spot. Looking at the history of this guideline, it is clear this extra rule was invented by someone unfamiliar with the consequences (and who said so themselves). Colin (talk) 16:55, 12 September 2013 (UTC)
I agree with you Colin. Authors should be able to make small changes if they are unambiguously improvements, even on featured images. Others should need to get the permission of the QI/VP/FP author even to make minor improvements. --99of9 (talk) 10:52, 17 October 2013 (UTC)

I have made an edit here. The rule about QI/FP was added to this guideline by someone who doesn't participate on those forums and there is no consensus for it on those forums. It gets in the way of doing the right thing. In addition, users should be much more cautious about editing other people's work -- it is nearly always better to have the creator do the fixes. -- Colin (talk) 13:53, 9 March 2014 (UTC)

I work with a lot of time sensitive data files, like for example File:Global Wind Power Cumulative Capacity.svg, and often update the work of others, but I strongly prefer that they update their own files - and often wait to give them a chance to do that. For myself it is the opposite - I would prefer someone else update the files that I have created - less work for me to do - and I am never going to run out of work to do (6,000 files that need to be converted to SVG, 6,000 SVGs that need to be translated). Photographs and some graphs are different, just because whoever created the original image may have access to more information than anyone else, and thus be better equipped to make the edits. Delphi234 (talk) 18:46, 21 February 2015 (UTC)

Accessibility replacements?[edit]

Where do replacements for accessibility purposes fall into this overwrite/don't overwrite scheme?

Example: An existing .svg map uses low-opacity (0.15-0.25) lines to indicate that a particular transit service is under construction or planned. That is less than 50% gray, leaving almost no contrast with the white background, which means that the graphic is not considered accessible under WCAG 2.0.

It would be better if the graphic used full opacity, and replaced the low-opacity lines with dashed lines.

Does doing such a replacement, provided I have ensured that the various meanings in the legend are still in agreement with the meanings of the original, qualify for direct replacement, or do Wikimedia guidelines prefer a new graphic in this case?

Thisisnotatest (talk) 06:24, 3 January 2014 (UTC)

This sounds like useful work. If the end result is just as likely to be as pleasing in style to most people, I would recommend uploading the new version over the old file. Should the changes be potentially jarring for some (which might be the case for high contrast images) you would avoid any possible debate or controversy if you upload this as a new file and link to it from the original as a derived work. There is a guide at Commons:Overwriting existing files, it is mostly common sense. -- (talk) 09:51, 3 January 2014 (UTC)
It's actually pretty standard on transit maps to show under construction and planned lines as dashed lines; the existing map is the outlier here. The one thing that I would think likely to be jarring is making the yellow line, which cannot provide good contrast against a white background, accessible. Actually that's a good reason for transit agencies not to call a line the "yellow line", but given that transit agencies sometimes do this, we are stuck with the accessibility challenges of mapping it. The only way to provide sufficient contrast is to trace them with black, but that sets them apart from other lines unless those, too, are traced. The other issue is when there are labels in those colors with the lettering punched out in white as is done with this map. Technically, any color lighter than 50% gray should have black text instead of white in the punch-out.
That said, given the new map is likely to be less aesthetically pleasing, I'll take your recommendation and make it a new map. Thank you for your assistance.
Thisisnotatest (talk) 07:02, 4 January 2014 (UTC)

Mentioning the modifications made to the original[edit]

In all CC licenses, we must indicate if we have modified the work — for example, if you have taken an excerpt, or cropped a photo. We must retain an indication of previous modifications to the work too. See this example. I think this should be mentioned at Commons:Overwriting_existing_files#Attribution. Jee 06:55, 16 March 2014 (UTC)


I'm confused by the guideline to not overwrite existing files. I understand the idea, that it is desirable to preserve the original because that's the starting point for any derivative works, and because many changes are apt to lose some information. Let me highlight two examples, beginning with a portrait that's been around for awhile: File:James_Fletcher,_official_NASA_portrait.jpg shows a revision history, beginning with an original, then a crop, then a revert, then "brightening." Should I want to make some improvement upon the picture, I could begin with any of the four versions. There's a similar litany of changes for the better at File:Dick_Cheney.jpg. Given this clear revision history and the evident improvements, what is the problem with minor corrections as in this case? -- Ke4roh (talk) 15:33, 4 November 2014 (UTC)

The problems with not making the corrections directly in these files are that then it becomes necessary to edit however many articles reference the files to take advantage of the improvements, and it adds work on Commons. -- Ke4roh (talk) 15:59, 4 November 2014 (UTC)
I am sure someone will explain the rationale better than me, but the idea is that Commons should serve the reader and reuser as far as possible and not really concern itself with work required by we "editors", or better, "curators". As to that NARA image, the intention behind not overwriting is explained in the template text "Please do not overwrite this file: any restoration work should be uploaded with a new name and linked in this page's "Other versions =" parameter, so that this file represents the exact file found in the NARA catalog record to which it links.". We want, I hope, to keep the original historical image, regardless of any colour or other defects. The decision as to which version (crop, colour balance, what have you) of an image should appear on separate projects should be left to those projects and we should not dictate them ourselves. Your NASA example demonstrates the problem of insufficient source details, but it appears the brightened version came directly from the "Large" version on the NASA page - the file sizes are the same. -84user (talk) 02:01, 5 November 2014 (UTC)
Our approach is inconsistent, so it is a good idea for projects such as NARA to explain when they wish to keep the identical image as the "top copy" and keep derivatives separate. There may be times when removing obvious flaws could usefully overwrite the file, and others where even removing border could damage an archive photograph's value for reusers. I can think of examples of both scenarios among my own GLAM uploads, just today I overwrote Psychoanalysts including Freud. Photograph. Wellcome V0027600.jpg to remove a highly distracting reproduction sticker which most folks would agree has no value, however it is useful that the image can be referred to in the file history. -- (talk) 02:12, 5 November 2014 (UTC)

Periodically updated files[edit]

This section was split from the previous section --09:53, 23 February 2015 (UTC)

A lot of the work that I do is updating images with new data (not photographs, but diagrams), like File:Average Retail Prices for Electricity in the US.png (that one I would probably make an SVG first though, and leave the PNG as is - right now I am holding off for a few days or a few weeks because 2014 data will soon be available). But File:Global Wind Power Cumulative Capacity.svg is used in 32 articles now, and is used to show the growth of and current status of the wind industry, and needs to be updated annually, each February. I am thinking of creating a Category:Files that are updated periodically (at scheduled intervals?) with the subcategories weekly, monthly, and annually. There are as many as a dozen files about the Ebola outbreak that various editors are updating weekly now, as each new situation report comes out. The biggest problem I have been having actually is to lose track of files that should have been updated, and have become out of date, so categories like updated annually in February, or November, for example would help. Delphi234 (talk) 18:38, 21 February 2015 (UTC)

That sounds reasonable. Maybe it would be helpful to have a "Files that need updating in..." or "Files that are outdated by..." category for things like that? Especially any graph based on annual data releases.
However, there are likely to be some other files which need updates at less predictable intervals. bobrayner (talk) 21:26, 22 February 2015 (UTC)
Both good points. Top level? "Files that will require updating" "Temporal data files"? There are some, like File:US monthly wind capacity factor.svg where the data is available monthly, but they really only need to be updated about once or twice a year. Delphi234 (talk) 00:07, 23 February 2015 (UTC)
Are you aware of {{current}}? Perhaps your "monthly/yearly" "outdated by" could be managed automatically by adding template parameters? --99of9 (talk) 09:53, 23 February 2015 (UTC)
Can it create a set of hidden categories, so that we can find a list of files? Can it compare the last upload date with the current date to create a stale dated hidden category? Can we change "This file may be updated to reflect new information." to "This file is updated {parameter 1} to reflect new information."? With parameter 1 being "in February", "in July", "in November", "in 2020", "annually", "monthly", "weekly", "daily". The File:Diagram of the United States Census Data.png only shows the decennial census, and would only be updated once every ten years, or to make corrections. There are occasional current events where data changes rapidly - hourly or even shorter periods. Delphi234 (talk) 19:08, 25 February 2015 (UTC)

Fixing an invalid SVG[edit]

Hi, triggered by a question on COM:Upload help I plan to add "fixing an invalid SVG under Rillke's law" as commonly used plausible overwrite reason. –Be..anyone (talk) 06:39, 31 December 2014 (UTC)

Here are a improved version to this file, I am not a computer expert, so it doesn't create an image in SVG. --58inejohns (talk) 06:05, 5 January 2015 (UTC)
I've linked the variants (PNG to SVG, SVG to PNG), users can pick what they like better. Or they adopt your fix for the SVG, and flag the PNG as redundant. Thanks. –Be..anyone (talk) 12:13, 5 January 2015 (UTC)
That seems reasonable. bobrayner (talk) 21:25, 8 January 2015 (UTC)
If nobody objects I still intend do that, i.e., move a subpage of my user page to a subpage of the project page and add a link to it on the project page with a note about overwriting invalid SVGs with a valid version. –Be..anyone 💩 05:31, 13 April 2016 (UTC)
I mean this falls absolutely under non-controversial edit and also minor improvements, so an enlargement seems needless. User: Perhelion 10:28, 13 April 2016 (UTC)

✓ Fixed by AlumnumDelphi234 + –Be..anyone 💩 06:00, 14 April 2016 (UTC) Edited: credits for the fixed credits to Perhelion, see below. 13:44, 14 April 2016 (UTC)

? The reason SVG fixing was included by Delphi234 on 14 March 2016 (as example of minor-improvements.[1] User: Perhelion 12:52, 14 April 2016 (UTC)
I am not sure what "Rillke's law" has to do with fixing invalid SVG, but if someone asks can I fix SVG that means it needs to be either disallowed and say that or allowed and say so. I see no reason for disallowing, although I would encourage anyone who has created invalid SVG to make a note something like this SVG is invalid but please leave it like that as it is being used as an example of invalid SVG. Delphi234 (talk) 09:57, 7 October 2016 (UTC)

Question of principle: How much sensible?[edit]

How ingenious is to improve a file, and then replace it (with GlobalReplace) with more than 500 usages⁉ I ask this because this is not an individual case and gets a new recommendation for some users (in particular CoA SVG-artists). User: Perhelion (Commons: = crap?) 15:57, 29 November 2015 (UTC)

Additionally, how ingenious or useful is it if the (previous) files get then deleted? User: Perhelion (Commons: = crap?)  14:32, 16 December 2015 (UTC)

Examples (of the last month, what I mean)
File:Wappen Landkreis Helmstedt.svg (>400 replacements at Nov.) 7. Dez. 2015
File:Wappen Landkreis Lüneburg.svg (850 replacements at Dec. 06) 16. Dez. 2015
File:Wappen Landkreis Cloppenburg.svg (324 replacements at Nov. 12) 29. Nov. 2015


User: Perhelion (Commons: = crap?)  15:17, 16 December 2015 (UTC)

Very unlucky example[edit]

The File: Wappen Kottmarsdorf klein.gif got overwritten by an SVG rendering, which violates "normally" the redundant and duplicate policy. This was also a part for the occasion for creating the whole Superseded images policy thematic. I suggest to remove this example. I always revert such images. User: Perhelion 15:38, 6 June 2016 (UTC)

Global detection[edit]

I noticed many times that any image was overwritten inappropriately. Sometimes by mistake (I myself overlooked the warning and overwrote even my own files several times), sometimes from ignorance (somebody overwrite an image with better or "better" one, not knowing that a new file should be uploaded under a new name) etc.

Should'nt somebody find and tag ALL overwritten files and filter them systematically to find and save (restore) all inappropriately overwritten files, and to enable to mark the suitably overwritten files as approved to the date of the check? Some bot should take care of it permanently. --ŠJů (talk) 19:39, 7 August 2016 (UTC)

This is not a rule, only a guideline. Jan Arkesteijn (talk) 21:08, 7 August 2016 (UTC)
Yes, "it illustrates standards or behaviors which most editors agree with in principle and generally follow." I do not assert that ALL overwriting files should be reverted to the first version. I propose that all overwritten files should be considered to be saved. Previous version should be restored especially in cases of inappropriate overwriting, and the new image ("version") can be uploaded under a new name (or the old version under a new name), if it has a valid license and attribution. Reasonable overwritings can be tagged as approved. --ŠJů (talk) 23:12, 8 August 2016 (UTC)

Cropping issue for Tangyes Lantern Slide Collection[edit]

Category:Tangyes Lantern Slide Collection needs to be cropped to make the images usable. How should this be done? Is there any virtue to re-uploading under new names, or is the old form not useful enough to need any more than the image history? See Tangyes Lantern Slide Collection#Cropping? Andy Dingley (talk) 13:52, 24 August 2016 (UTC)

Redundant non photographic images[edit]

I would like to state just another small negative side-effect of this policy: A possible amount of redundant personal interpreted user images. Which problem then get spread over the whole Wikipedias. Example: Commons:Deletion requests/Fictional Papal Arms User: Perhelion 21:42, 28 August 2016 (UTC)

This does not seem to be about personal images, but whether or not to keep coats of arms that do not follow the official blazon. Calling them redundant or saying they should be overwritten with each other is distracting from the real issue. This real issue should be solved case by case or category by category, not by changing this policy. Rewriting different versions of CoAs with each other is a not too uncommon edit war topic, much better solved on the Wikipedias. --LPfi (talk) 11:08, 29 August 2016 (UTC)
What have out-of-scope files to do with overwriting policy? --ŠJů (talk) 14:45, 29 August 2016 (UTC)
@ŠJů: The Papal Arms at generally is not out-of-scope. Maybe it was an unlucky example. But yes the question is, when is it out-of-scope!?
@LPfi: Maybe you're right, thanks for response. But compare also Commons:Village_pump/Proposals#Proposed_mass_deletion_of_Latin-named_coats_of_arms_uploaded_by_Ssolbergj of this issue (on Wikipedia are mostly not that people which solve this for all Wikipedias).
I do not want generally a change of the policy, only an indication of the subject matter. User: Perhelion 18:52, 29 August 2016 (UTC)
@Perhelion: Here is discussion about Commons:Overwriting existing files policy. I did not understand what fictional coats of arms have to do with overwriting policy to be discussed here. --ŠJů (talk) 18:57, 29 August 2016 (UTC)
@ŠJů: I mean not really fictional (that's only in the title of the link). You are right, if an thematic question should be, what is fictional!? Often we can not view each policy separate. Redundant files (Coat of arms was only an example) of a possible side-effect of the result of this policy (if NOT Overwriting). I see now the relevant section is high probably #Controversial or contested changes =COM:UPLOADWAR. I see you are Czech, what do you think about this:[2]vs[3] or [4]vs[5] or [6] or [7] etc... (changed dozens of sign sets from silver to black border without source). Okay or not? You were also here, not redundant? User: Perhelion 23:02, 29 August 2016 (UTC)
As regards the Czech road signs, I mean that the image from the official ordinance should be not overwritten with "improved" versions. And an image with full name and full description should be not deleted when any undescribed derivative with unclear source is the "better version". Czech road signs have a white margin only, not a black. The subtle silver shadow is better to depict it. --ŠJů (talk) 23:25, 29 August 2016 (UTC)
Thanks for your opinion, I fully agree. (the relevant user has admitted in his last sentence, that the black border is only his own point of view, after many trouble and block of us both). In short, I mean people made often her own very similar redundant (most likely unnecessary) copies and push them. That's the problem what I mean and thereby files without source (we can't say fictional). User: Perhelion 23:47, 29 August 2016 (UTC)

This guideline should be reopened for discussion with notice to all Wikimedia Foundation projects[edit]

Because the Commons community failed to notify the Wikipedia community that this was being proposed as an official guideline back around 2012, I was unaware of this guideline and uploaded newer versions of about 20 to 25 of my own photographs---that is, where I was passing by the same subject and took the opportunity to get a better photograph (either because the lighting was better, the subject had changed somewhat, or because I had since bought a DSLR). To bring those photographs into compliance with this useless guideline is going to take about 50 hours of work, which I am quite irritated about. Because I have higher priorities (like improving the University of California article) than redoing work I already did years ago, it is going to take over two years to complete that task. It is because of poorly-thought-out guidelines like this one that all Wikimedia Foundation projects are hemorrhaging editors at an unsustainable rate.

It seems to me it would be much better to get rid of this guideline, because I do not understand why there is any need for it. As a matter of common sense, this guideline creates far too much unnecessary work; then all editors on all Wikimedia Foundation projects have to constantly scour Commons and/or other Wikimedia Foundation projects for updated images of the same subject matter (e.g., the Alameda Avenue entrance to the Walt Disney Studios), when an update can be propagated to all Wikimedia Foundation projects through a simple overwrite. (For example, earlier this year, the Walt Disney Company redecorated their Alameda Avenue entrance with a more conservative design and added the Mickey Mouse shape to the entrance gate, but it is unlikely that any article will discuss that change, as it did not draw any media coverage which could be cited in article text as a reliable source.) I propose reopening this guideline for discussion with proper notice to all Wikimedia Foundation projects. --Coolcaesar (talk) 06:21, 17 October 2016 (UTC)

Yep; when Crimea gets absorbed in Russia, it can be updated on all pages simultaneously. Then Wikinews editors who used a map can go back and revert, to be reverted by Russian Wikipedia editors, to be reverted by Ukrainian Wikipedia editors, to get changed to a "neutral" version, which won't satisfy any of the previous editors ... Loads of fun, as every long-term Commons editor can tell you.
If the Alameda Avenue entrance changes, then overwriting the image causes two problems:
  • We don't have a picture of the old entrance available, except hidden in history.
  • Any page that uses it to display the Disney Studios at a certain point in time, or to show how Disney is moving away from the Mouse, now has an inappropriate image.
Yes, Wikipedia pages need to be updated every so often. Go ahead and upload the new pictures and update the English Wikipedia, and other Wikipedias will likely follow suit, or sometimes not, upon looking at the changes.--Prosfilaes (talk) 16:17, 17 October 2016 (UTC)
You're begging the question without actually answering it. You're making the silent assumption that there would be any need to display the prior appearance of the Walt Disney Studios' entrance at a certain point in time. Under current Wikipedia guidelines, that specific issue would never go into an article (or would not remain there long) because we don't have a reliable source on it. The dramatic change to the Alameda Avenue entrance has not been covered in any reliable sources. In turn, there is no need for a photograph to illustrate a point that will never come up in an article. --Coolcaesar (talk) 05:38, 28 October 2016 (UTC)
Photographs on Commons are not just here for encyclopaedic value, there is a wider brief for a likely educational value. For this reason the project has many images that will never be used by a Wikipedia project. In the hypothetical case you put, I can imagine a commercial historian would find historical images of the Disney Studios (and therefore their branding) educationally useful for illustrations. As you are discussing policy, then yes, overwriting images that are in use on Wikipedia articles is a concern and remains poorly managed. This is one of the reasons that the live report at BLP overwrites was created, as this 'blindspot' for Wikipedia and Commons was being used for serious vandalism of biographic articles. -- (talk) 08:12, 28 October 2016 (UTC)
We are not an archive of pictures for Wikipedia; we serve all Wikimedia projects and to some extent a far larger community. Your interpretation of the English Wikipedia rules is your interpretation, and certainly not binding on even all Wikipedias.
In this specific case, yes, a Wikipedia editor could chose the older image for aesthetic reason or any number of reasons. That would be a discussion that should be had on Wikipedia, not Commons. The idea that it is known that there is no reliable source seems silly; has anyone checked all issues of the Alameda Sun, the San Francisco Examiner, Oakland Tribute, as well as any other newspaper that might cover it? That no one in the wide world has published a journal article or even a book on the subject that might have escaped notice? That no one will?--Prosfilaes (talk) 21:14, 28 October 2016 (UTC)


I have an argument over cropping as a minor modification : I scan through many aircraft pictures and often there is much empty space of sky around the subject (aircraft are often far away and need a long telephoto, and the uploader often transfer from other websites without editing). Since there is the lossless croptool, I often crop them to better fit the frame and avoid thumbnails with a tiny speck somewhere. I made this in compliance with Commons:Overwriting existing files, specifically #DO overwrite > Minor improvements [...] removal of a watermark/ cropping ("where the essential composition is not altered") as in File:Miyasaka Hakuryu II - Tigress with Two Cubs - Walters 71909.jpg where the useless background cropping is considered a minor improvement as the main subject isn't altered. But others thinks it is a #Substantial crop or un-crop and thus should be uploaded as a separate file. I think it could be a good thing to establish more clearly that a neutral background crop is a minor improvement. It was discussed before in Commons_talk:Overwriting_existing_files/Archive_1#RFC--Marc Lacoste (talk) 09:19, 6 December 2016 (UTC)

@Marc Lacoste: Read COM:UPLOADWAR. If an editor contests your change (by reverting it) you may not simply put your version back on top... instead, upload it under a new filename as a derivative version. Croptool is capable of doing so automatically. Reventtalk 10:15, 6 December 2016 (UTC)
Indeed but when an edit complies with a policy the revert could be misled.--Marc Lacoste (talk) 20:47, 6 December 2016 (UTC)
We need to keep in mind that though how images may appear when in use in Wikipedia articles is important, and hence images that look good in thumbnail sizes are needed, it is also true that reusers may want original uncropped versions to make their own versions, such as enhancements, or their own crop preferences or where they are using the original where extra space may be a useful feature of reuse such as for mixed presentation slides. Though images are always in the history, our reusers are likely to find these overly complex to view and recover, hence the importance of sticking to creating significant crop as new files. Exceptions should be obvious, such as removing artificial margins, handing very poor framing or an unhelpfully angled image which distracts from the subject, and in those cases we rarely see reverts. -- (talk) 10:30, 6 December 2016 (UTC)
It doesn't seem more accessible to search a file origin for an hypothetical uncropped variant than for its history. --Marc Lacoste (talk) 20:47, 6 December 2016 (UTC)
I'm unsure of your exact meaning, however it's normal to link to derivatives by using the parameter 'other_versions'. I tend to use the gallery tag to link to and from the original, which makes them literally easy to see. -- (talk) 23:02, 6 December 2016 (UTC)
Yes, like that it is similar to the file history--Marc Lacoste (talk) 06:08, 7 December 2016 (UTC)
Two things: 1. As was already pointed out, if an editor contests a change, upload as a new version. The change obviously was not "uncontroversial". 2. I personally find the tight crops that aviation photographers seem to prefer hideous. Give the poor planes some room to breathe. Tight crop vs. non-tight crops is clearly an artistic choice. The wording about "small crops" is in my opinion targeted at cropping away unclean borders or distracting detail in corners or on borders. --Sebari – aka Srittau (talk) 14:05, 6 December 2016 (UTC)
I don't like too tight crops either, I dislike too thin aspect ratio images and stay with a 3:2-2:3 frame. --Marc Lacoste (talk) 20:47, 6 December 2016 (UTC)

All I was saying wasn't to defend my position, but if the example shouldn't pass now it should be changed and the rule clarified. --Marc Lacoste (talk) 20:47, 6 December 2016 (UTC)

"You cannot overwrite this file." message[edit]

How about explaining Why and what options i have available in such a case. Also, it would help if this message were a bit more visible... -- Random20161229 (talk) 22:17, 29 December 2016 (UTC)

PS Using the Special:Upload, i am told the reason ("because your account is too new") and given a potential course of action: "Please go back and upload the file under a new name. Once you've done that, you can ask someone at the Help desk to move your file to the name you want."... But in such a case, can users actually "merge" the two images (the existing one and the new version i am trying to add to its "version history")?! -- Random20161229 (talk) 22:25, 29 December 2016 (UTC)
Apparently, admins have that options, but i don't think regular users do... -- Random20161229 (talk) 21:04, 30 December 2016 (UTC)