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)

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)