Commons talk:Overwriting existing files

Archives 1

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.

Proposal

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)

I agree with the spirit of this proposal, but in lieu of the above concerns, perhaps "Updating existing files" is the best fit for a new name. This would cover all conceivable cases that I can think of, and remains clear (and significantly more accurate than "overwriting"). The concern about moving away from often-used shortcuts is legitimate, but in this case I believe the change is worthwhile: I myself (a new editor) was confused and concerned by the "overwriting" terminology, fearful that I would be eradicating an earlier contributor's work if I "overwrote" a Commons file. FormAllTheHides (talk) 02:36, 30 March 2017 (UTC)

Reproductions of two-dimensional works

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 --Fæ (talk) 01:12, 6 January 2013 (UTC)

EXIF information

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

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)

QI/VI/FP

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?

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. --Fæ (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

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)

Overwriting?

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 http://grin.hq.nasa.gov/ABSTRACTS/GPN-2002-000107.html - 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. --Fæ (talk) 02:12, 5 November 2014 (UTC)

Periodically updated files

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)

• I created Category:Files that need updating annually as a hidden category and am thinking of putting it into the Category:Files that will need updating as an empty category (specify a date or period). Delphi234 (talk) 17:15, 28 February 2015 (UTC)
  • Nice work! bobrayner (talk) 22:39, 18 March 2015 (UTC)

Fixing an invalid SVG

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?

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

or

• File:Wappen Landkreis Weilheim-Schongau.svg → File:DEU Landkreis Weilheim-Schongau COA.svg (809 replacements at October 25)!?
• File:Wappen Bielefeld.svg → File:DEU Bielefeld COA.svg (321 replacements at November 30)

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

Very unlucky example

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

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

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

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

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. --Fæ (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)

Crop

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. Revent^talk 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. --Fæ (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. --Fæ (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

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)

problems with displaying my overwriting file.

I've just updated a new version of this file [8] which is considerably different from its previous versions. The problem here is that in the article using this file, Nguoi Nung of Vietnamese Wikipedia [9], it is displayed as its previous version instead of its newly uploaded file [10]. How could I make the file to be displayed as its latest version. Thanks. Bookworm8899 (talk) 15:51, 13 March 2017 (UTC)

My question has been replied here [11]. No further answer needed. Bookworm8899 (talk) 18:12, 13 March 2017 (UTC)

Transparency

Nothing mentioned here. Until today I thought a background is not important (especially for coat of arms and icons) and is not a reason for duplicates (case for speedy-deletion). I thought also there is a sentence on the Commons guides for this, but also nothing? Would it be ok to write something here under Minor improvements? -- User: Perhelion 13:51, 3 April 2017 (UTC)

• Adjusting transparency would fall under the category of minor improvements. It's something that's only visible in certain conditions. Wikimandia (talk) 16:23, 5 July 2017 (UTC)

Bad files - overwrite or replace?

I'm trying to eliminate the bad coats of arms in Category:Bad SVG Adobe files with CDATA blocks. All of these files were created by the same user (Oxenhillshaw) who has not been active since 2010. As an example, file:Arms of Baron Alvingham.svg, which I'm working on at the moment, has nearly 1,000 errors. I'm not working with the original files but recreating them, so these are not minor changes. I was uploading a new, original file for this reason, but then I realized this would create extra steps in doing global replace and then proposing deletion of the bad original file. (There is no point of keeping the bad files around, since they are hugely bloated, about 10x the size of the improved). It seems easier just to overwrite the file with errors. But someone just told me I'm violating this policy. I can see the reason behind both approaches, so what is the best way to proceed? I'm fine with reverting and uploading as separate files, but it would be good to have instructions in this guideline on what to do in the future with files that have errors. Wikimandia (talk) 16:36, 5 July 2017 (UTC)

If you deem that an old version is bad enough to be deleted and, fortunately, have a re-created image showing approximately the same picture, then you should boldly upload it over and wait for a reaction. Deletion of the old stuff is a reasonable option in two cases:

• The old image is so bad that shouldn’t be kept even in file histories (usually, due to copyright issues).
• The new version has differences so substantial that some Web pages depending on the old file wouldn’t willingly display the new one.

Incnis Mrsi (talk) 08:56, 6 July 2017 (UTC)

“Higher resolution“

This clause sometimes result in consequences (see February 2012) which reasonable people writing the guideline didn’t probably envisage. I know more cases of clueless tampering with good images. Shouldn’t the clause be restricted to photographic images and other obtained from digitization? Including scans, tomography, remote sensing and alike, but excluding everything which might rely on pixel structure. Incnis Mrsi (talk) 19:57, 8 February 2018 (UTC)

Should be limited to cases where it is a higher quality and more accurate representation of the same original work. Otherwise they must be separate uploads. --Fæ (talk) 20:23, 8 February 2018 (UTC)

A correct heading of thought, but not in every appropriate case the original thing is an [art]work. In File:HXMM01.jpg#filehistory we see a fix of a clear mistake by the original uploader who accidentally degraded the photo, but generally it would not be unreasonable to replace one image with another showing the same things about the same part of deep sky (essentially permanent by our time scale), but of better quality. In more complex cases it would require a great wisdom to judge whether is the original subject identical or not (for example, landscapes in morning and in afternoon are certainly distinct for photography). There is a well-defined “original thing” which didn’t change between images → one can at least consider replacement; otherwise it is prohibited from the onset. Incnis Mrsi (talk) 10:15, 9 February 2018 (UTC)

Nothing should rely on pixel structure, not in a world where the image might be displayed through a 640x480 projector or through a 3840 x 2160 monitor and the person on the other end might be someone with 20/20 eyesight, or someone legally blind with zoom cranked up on everything. The only exceptions I can think of is screenshots of consoles or computers. In the case of your example, the SVG is much better; it will zoom cleanly to the needed resolution, and never blur because it's in general impossible to for algorithms to know whether or not pixel structure should be preserved or interpolated. (Cf. w:Pixel-art scaling algorithms, and note that for that specific case, there's quite a number of choices, with different problems.)

I don't see that we need to change this clause at all, nor that changing it will have a significant effect on cluelessness.--Prosfilaes (talk) 21:59, 8 February 2018 (UTC)

Do not force own understanding of graphics upon all the world, even if it is 99% correct. Compare: I really detest such things as “x” as a multiplication sign and wrappable spaces around it, but deem unwise to restrict Prosfilaes’s freedom to make typographic errors, even considering that they could potentially induce other people into the same habit. Prosfilaes likes SVG incarnation of Zeckendorf – let’m use it everywhere, but my PNG displayed pixel-by-pixel has a better quality than rasterized SVG and, moreover, intrinsically represents the subject in a more straightforward way. Incnis Mrsi (talk) 10:15, 9 February 2018 (UTC)

Do not force own understanding of policy upon all the world.--Prosfilaes (talk) 02:52, 10 February 2018 (UTC)

We now see one user arguing about such remotely related matters as projectors and legal blindness, and two users deeming that the clause needs a more precisely defined domain of applicability because (mis)interpretation caused demonstrable disruption in images hosted here, as they are encoded in digitized form – without any projectors, monitors, and eyes. Incnis Mrsi (talk) 06:34, 10 February 2018 (UTC)

I think we should delete any images that aren't intended to be used with projectors, monitors or eyes, because they're useless to the target audience of Wikimedia, which is people.--Prosfilaes (talk) 18:45, 28 May 2018 (UTC)

I think Commons will better live without censorship, no matter by which ideas may it be substantiated. “Not intended for the mass audience” (or “… end user”) is basically from the same repertoire as “insulting gods” or “promoting immorality”. Commons has a lot of images for archival purposes many of which are manifestly unsuitable for direct consumption, and they take a considerable room on the servers. How reasonable could be a person demanding deletion of pixmaps occupying few kilobytes? Incnis Mrsi (talk) 17:44, 29 May 2018 (UTC)

Overwriting to remove DW

Users are (ab)using this guideline to revert overwrites that remove or blur derivative works. Halfway the guideline this can be found:

"This is true even if the change is necessary, in one editor's view, to avoid a copyright infringement: in this case, if agreement cannot be reached through discussion, the old file should be nominated for deletion."

I suggest adding " Removing derivative works, but be careful to check wiki projects that use the file and edit them where needed, or put {{Edit request}} on the talk page if you don't know the language." to the summary. - Alexis Jazz ^{ping plz} 17:17, 10 August 2018 (UTC)

Audio clean up

I think these guidelines need to be updated to explicitly allow clean up of audio files, e.g. noise reduction. This is especially relevant for audio-versions of articles and files used for pronunciation examples on Wiktionary. —⁠andrybak (talk) 14:49, 24 August 2018 (UTC)

@Andrybak: how clean up of audio files is different, in principle, from cleanup (such as noise reduction or tweaks in levels) of images? Certainly there are some cases where original record should be kept separately, but in other cases overwriting may be encouraged. The decision depends—both for images and audio—on several factors, such as techniques used for cleanup, “historicity” and quality of the original, digital compression mode, difference in resolution, as well as subjective preferences of the original uploader. Incnis Mrsi (talk) 15:34, 24 August 2018 (UTC)

Breaking consistency with other images

I suggest adding:

Changes that break consistency with other images

Reverted examples of such overwrites can be seen in the history of these files:

• File:Icosahedron flat.svg (breaking consistency with Set of Platonic solids; nets yellow orange)
• File:Hyperbolic domains 932.png (breaking consistency with Hyperbolic fundamental domains; red and white)

Greetings, Watchduck (quack) 12:10, 9 September 2018 (UTC)

In fact, a correct location for the revision of Icosahedron_flat.svg uploaded by Tomruen would be category: Erroneous geometry due to triangles being not equilateral beyond a reasonable error margin. Unsure why did Watchduck prefer the worst image of the three. Incnis Mrsi (talk) 12:45, 9 September 2018 (UTC)

I don't agree with your extremely narrow definition of reasonable. But this does not belong here anyway. File talk:Icosahedron flat.svg is the right place for that topic. Watchduck (quack) 12:57, 9 September 2018 (UTC)

Just for context: The current reason I ask to explicitly add this rule is this discussion. In its course a user decided to replace images that are consistent among each other with new ones that are deliberately inconsistent. Consistency adds to the value of images, and to destroy that value is not a legitimate reason to overwrite. This should be common sense and is implied by the rules as they are, but clarity always helps. Watchduck (quack) 18:23, 11 September 2018 (UTC)

There seem to be no opposing views, so I went ahead. (I would be very surprised if anyone argued that such changes should be allowed.) The translation tags are numbered, so I am not sure how to call new ones in between. Append letters? Watchduck (quack) 20:16, 13 September 2018 (UTC)

Problems with a user that crops too freely

One user has been overwriting other photographs massively and has changed those photographs sometimes very greatly. . Some hours ago I have put nearly two hours of my time in restoring all the damage that he made. I limited it to work that others uploaded. Some photographs were even uniquely OTRS donated to Commons and I found that a number of his crops had been reverted by others. In this way a great deal of the original work is erased: he sometimes cuts of the shoulders or the environment at a photograph. In those cases one can easily upload an extra copy of the photograph, because the server needs the same amount of storage capacity anyway. When cropping, the tool even warns "Overwrite existing file (Please, be careful!)". Afterwards I have friendly informed him about it on his talk page: User talk:Ivar the Boneful#"Overwrite existing file (Please, be careful!)". There he reacting very aggressively towards me and he has reverted a great deal of all my restoration work of this morning. What should be done here? Ymnes (talk) 13:25, 21 October 2018 (UTC)

@Ymnes: COM:ANU is the answer. - Alexis Jazz ^{ping plz} 13:45, 21 October 2018 (UTC)

As I've detailed at User talk:Ivar the Boneful#Pagebreak, you went through my edit history and indiscriminately reverted anything with the word "crop" in the edit summary. No, you didn't "limited it to work that others uploaded", you reverted a number of my edits to images where I was the original uploader, such as File:Robert McClelland 2011-01.jpg. "Cut[ting] off the shoulders or the environment at a photograph" is perfectly justifiable, and is exactly what overwriting was created for. Your message at my talk page wasn't "friendly", it was rude and passive-aggressive. If you want someone to be polite to you, don't go and sudden delete 80 of their contributions without any warning. Ivar the Boneful (talk) 14:07, 21 October 2018 (UTC)

pure svg-scource-code-edits without visual change

I consider validating SVG controversal, and I therefore wrote an essay: User:JoKalliauer/Optimization

Are edits allowed that only

1. validate a correclty rendered file
2. reduce the file-size
3. increase the readability (by humens)

I would consider myself as one of the experts on repairing/validating SVGs on wikimedia, I created 38svgo-bugreports, 57svgcleaner-bugreports and 38scour-bugreports and some phab:-Bug-Reports (Some of them are related to librsvg-Rendering) and Inkscape-Bug-Reports

When I was "Wikimedia-young" I validated SVGs on Wikimedia, just to validate them. From disscussions with SVG-experts like User:Sarang and User:Glrx I learned the uselessness of validating/scrubbing files without visual change. Now I am also creating/editing svg-files, and noticed that some invalid attributes are helpfull in editing and should not be removed, and do not do any harm in rendering, see User:JoKalliauer/Optimization#invalid elements that should be kept for examples.

As descriped in User:JoKalliauer/Optimization#Optimizing SVGs that are already uploaded there is no clear cut if a file should be validated, but in general I consider that most SVG should not be validated. Validating could be done by User:SVGWorkaroundBot (after a permission-request for also doing violations), and would have the advantage to tickle less watchlists (since bot-edits can easyly be filtered). But validating often removes important features for editors, which is undesired, similar to convert real-text to {{Path text SVG}} (since it is more difficult to edit this file afterwards).

The German wikipedia says at original (German) or at translated by google translate to English: >>Important: An edit should always lead to at least an externally visible or effective change<<, contradictingly the Englisch wikipedia explains when you should do en:Help:Dummy_edits. Even if optimization would not remove important informations: Reasons why svg-source-code edits can be seen as problematic: 1)file-storage, 2)watchlist (I am watching over 5000Pages), 3)procesiong time (phab:T40010 or phab:T226318 or meta:SVG_benchmarks); See User:JoKalliauer/Optimization#svg-scource-code-edits without visual change for details. I know validating is something different, but validating often lead to more problems than it solves.

I think it is best to keep the decission about validation to the original author, even if most of them don't know anything about validation. So my suggestion is generally: keep files as they are, but you can inform uploaders to remove e.g. {{Cdata}} before uploading, but do not reupload them.

 — Johannes Kalliauer - Talk | Contributions 14:30, 23 June 2019 (UTC)

@JoKalliauer: Doesn't validating give files wider standards-compliant usage possibilities for our off-wiki reusers?   — Jeff G. ツ _{please ping or talk to me} 14:44, 23 June 2019 (UTC)

@Jeff G.: Yes and No. (In my opinon not.)

A file can contain

• data-name=, inkscape:label Is used to label/find/name a specific element. (id in contrast is used for addressing/refering)
• <rdf:RDF Is used for metadata, see File:SVG_Test_TextAlign.svg, otherwise it might be a copyright violation
• aria-label= Is used when a text is converted to path, and that the text is still searchable.
• <inkscape:grid,<sodipodi:guide Is used in Editors to align Elements, see File:Medellin_Kartell.svg
• sodipodi:cx=, sodipodi:cy=, sodipodi:rx=, sodipodi:ry=, sodipodi:type="arc" used for circular segments saved in path, since circular segements are not supported by the standard, see File:Sodipodi-type="arc".svg
• vector-effect= https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/vector-effect, see File:Municipalities_of_Italy.svg
• inkscape:groupmode="layer" inkscape:label= Layerdefinition in Inkscape
• sodipodi:role="line" https://gitlab.com/inkscape/inbox/issues/427

all of them are invalid, but helpful

for example <inkscape:grid,<sodipodi:guide can help you aligning in inkscape, but since it known edior-data (or even if it is unknown) the renderer ignores them, or aria-label= is used to wirte the text of the text-path into realtext-attribute, and could theoretical be used for blindness people and could be also be used to reproduce this character/word. User:Glrx is more an expert on svg-standards than I am, and he wrote about aria-label= elements in my talkpage and 大诺史 talkpage. Quote: >>Removing the attribute does remove a W3C validation error, so it can be viewed as an improvement. I do not see that as a reason to modify the file. The "error" is harmless because the attribute is syntactically correct and harmless in most agents. If the W3C validator were using SVG 2.0 validation rules, it would not be flagged as an error.<<.

If the file is invalid XML, everyone will agree, this should be fixed and reuploaded, but I am talking about invalid SVG (or invalid DTD, wich is even more strikt).

File:Liberty_Bell_icon.svg is with 3551 W3C-SVG-DTD-errors most likely the file with most errors on commons, but Sarang argued that there is no sence in validating (but in this case also no harm.)

But some features should be converted to SVG1.1, but most users who are doing validation just remove invalid elements without replacement, so they remove informations.

 — Johannes Kalliauer - Talk | Contributions 15:17, 23 June 2019 (UTC)

@Jeff G.: re "Doesn't validating give files wider standards-compliant usage possibilities for our off-wiki reusers?"

For the most part, validation offers little benefit to on-wiki and off-wiki users. SVG is XML, and XML is "Extensible Markup Language". A significant feature is that such markup can be extended. Not only can I use SVG to paint an image, but other information can be added to the SVG file. Editors such as Inkscape include notes so the file can be easily updated. Some chemical structure files include data about bonds. Creative Commons and Dublin Core offer extensions to describe license and publication details.

Many of those extensions are reasonable and even worthwhile. If an off-wiki editor uses or modifies the file, that information may assist her. Unfortunately, SVG validators may look for strict SVG compliance. Consequently, they may flag such extensions as warnings or errors. The W3C validator can be permissive of some extensions, but often not all.

In the early days of XML there were no namespaces. The DTD was touted as a way to make sure that XML documents were compliant. A reasonable approach was to make sure that all XML documents would validate. The DTD even offered a method to include extensions. XML then added namespaces, but DTD technology was awkward for namespaces. (SVG is namespaced.) People tried to graft namespaces into DTDs, but it was too awkward. Users would specify a base DTD, but would not include the extensions. Such documents would not validate. Validation at document read time was also turned off. Not only would the documents not validate, but even if the document would validate, the validation was too slow. The value of the DTD was disappearing. Some document specifications have deliberately chosen to not generate a DTD. HTML has even given up on XML. Current recommendations are to not include a DOCTYPE processing instruction for HTML or SVG.

There are replacements for DTDs. The most modern W3C validator is a schema validator. There can be a schema for the main document, but there can also be schemas for the extensions that mix in. In theory, the XML files could tell such a validator which schemas to use, but that has not caught on. There are a few different schema specifications. Also, just as document authors were not subsetting the DTD, they are not adding xsi:schemaLocation to their documents. If the validator is not told to include a schema that a document uses, then the validator should emit errors and warnings.

I'm not axiomatic. I'm a pragmatist. I generally agree that we should not turn optimize SVG just for the sake of optimization, but there may be reasons to modify SVG files even if that modification does not change the visual appearance. I could see a robot inserting RDF license information and a cc:attributionURL to every SVG file. A robot might replace width and height attributes with a viewBox attribute. Some edits could be done even for the benefit of off-wiki users. My system does not have the font "Liberation Sans"; when I display such an SVG in my browser, instead of a sans serif font I will get a the "Times New Roman" serif font. Editing font-family="Liberation Sans" to font-family="Liberation Sans, sans-serif" could be viewed as a minor improvement. Although such a change may be worthwhile in some sense, I'm queasy about unleashing a robot to edit every SVG file on Commons.

A note about size. Although I'm not a fan of optimization (it is often too agressive and wrecks structure), neither am I a fan of bloated SVG files. Commons caps SVG uploads at 10 MB. There are many SVG files that are overweight for what they display. It may be worthwhile to trim some of those files, but I'm not sure when it becomes worthwhile. Optimizing a file that is viewed once a month has little value. Eliminating path text can be reasonable for files viewed often on several wikis; it enables translation. There's also a long term issue. I'd like to see MediaWiki directly serve SVG files, but that will not happen if most SVG files are in the >100 kB category. I'd like something that encourages lightweight SVG files. The goal of optimization is reasonable, but we do not know the right balance yet.

Glrx (talk) 17:43, 23 June 2019 (UTC)

Minor improvements

I suppose to change/insert that clarification:

Minor improvements for textual elements include correcting spelling on a map's labels.

By contrast, translating a map's labels from English to German is a major change, and should be uploaded as a separate file.

But changing SVG code from path text to embedded text, or vice versa, is a minor improvement, as well as

changing to text switch, or the adding of more languages to a text-switch multilingual file.

-- sarang♥사랑 08:39, 10 February 2020 (UTC)

@Sarang: I agree on those four points, however I have some minor comments:

1. agree
2. I would write it more general it is also valid for diagrams,...: "Changing a language (without switch) of a file is a major change, and should be uploaded as a separate file."
3. changing SVG code from path text to embedded text, or vice versa, is a minor improvement, if you change it to path text please keep the embedded text (in an hidden layer, see Help:SVG#Fonts,_text)
4. maybe a more cleaned up example such as File:SystemLanguage.svg.?

 — Johannes Kalliauer - Talk | Contributions 07:39, 27 June 2020 (UTC)

I cant upload the file properly relating to File:Visa requirements for Abkhazian citizens.png

Hello

I uploaded the file to Wikimedia but I noticed some errors, I fixed those errors and tried to re-upload the file. For some reason when I uploaded the updated file, it reverted to the original one, for some reason this isn't working, and I tried to modify the file 3 times, however none worked, does anybody have a reason for this? Because its really annoying that I am making "updates" to the version history despite the picture looking the same. On the version history you can see that I uploaded the file 3 times even though there aren't any changes. --Audi1merc2 (talk) 20:15, 27 February 2020 (UTC)

Proposals#Commons:Overwriting_existing_files_update

Discussion at Commons:Village_pump/Proposals#Commons:Overwriting_existing_files_update.--BevinKacon (talk) 12:09, 30 March 2020 (UTC)

Overwriting existing pronunciation files

Hello, I regularly upload German pronunciation files to commons. Unfortunately I uploaded files with sound only on left channel in December 2019, see discussion. Standard for German pronunciation files is mono sound, see Sprechen von Hörbeispielen (last sentence). As I mentioned in discussion I could produce 4,573 new mono files with reasonable effort. But how can I overwrite the files on commons not in a manual way? Thank you for your support. --Jeuwre (talk) 12:05, 28 April 2020 (UTC)

Found a solution with Pywikibot. Uploading is at the moment in progress. --Jeuwre (talk) 12:52, 30 April 2020 (UTC)

Not allowing

How come MOST files don’t let you but SOME do? A1N2D3R4E5W6 (talk) 19:46, 17 May 2020 (UTC)