Commons talk:Overwriting existing files/Archive 2

Archive 1

Archive 2

Archive 3

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

[OK] 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 "[OK] 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)

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)

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 sense 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:

[OK] 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.

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

[OK] 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)

@Audi1merc2: Hi, and welcome. Please see COM:PURGE.   — Jeff G. ツ _{please ping or talk to me} 21:10, 27 December 2020 (UTC)

Not allowing

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

@A1N2D3R4E5W6: Let you what?   — Jeff G. ツ _{please ping or talk to me} 21:06, 27 December 2020 (UTC)

Substantial crop or un-crop example

Hello everybody, Commons:Overwriting_existing_files#Substantial_crop_or_un-crop considers a crop as minor when it enlarges the subject over an empty background, as opposed to excluding part of the composition. Along the original example, I boldly thought I could add another example of an aircraft in its empty sky:

• 
  original with more negative space
• 
  cropped on subject
• 
  The aircraft is isolated in too much empty sky
• 
  cropped on airplane

This was reverted by Huntster, stating that I should seek consensus on the matter. Any other thoughts? Cheers,--Marc Lacoste (talk) 20:26, 27 December 2020 (UTC)

There is a significant difference between an intentionally null space, like the museum display, and a naturally open space, like the sky. It's still a better idea to simply upload the desired crop to a new filename and leave the old one alone, especially if it's a rather dramatic crop as in your example, because it provides options for end users, rather than forcing them to use a crop that may be too severe for their purposes. After all, we want to make things easier for them, not more difficult. — Huntster (t @ c) 20:33, 27 December 2020 (UTC)

~

The jet photos you post up here misrepresent the disagreement that prompted your edit to the policy. The two variants are

• 
  the 9 year-old photo
• 
  the crop you made of it on Dec 25

The consensus is already pretty clear on your talk page that your preference for very tightly cropped images clashes with the choices of multiple editors. The space left around the subject of a photo is often the result of a deliberate choice. It’s cool if you don’t like it. It literally takes one click to make a derivative file instead of overwriting somebody else’s decisions. Ariadacapo (talk) 18:39, 29 December 2020 (UTC)

@Ariadacapo: This discussion is about illustrating the guideline, we could have a separate discussion on the padding space if you want. No thoughts on the subject of illustrating the guideline?

@Huntster: The given example is your crop, not mine, presented as it stayed for nine years --Marc Lacoste (talk) 09:52, 30 December 2020 (UTC)

Marc Lacoste, yes, that I chose when I uploaded it, to fit a desired use. Which is specifically granted in the guidelines. — Huntster (t @ c) 13:31, 30 December 2020 (UTC)

@Huntster: so you concur it's a fitting example.--Marc Lacoste (talk) 16:42, 30 December 2020 (UTC)

Marc Lacoste, no, because fitting it as an example where you did is calling it a minor crop, which it is not. It would also tell editors it is appropriate to make those crops to pre-existing images, which it certainly is not. Unless *you* have only recently uploaded an image (and I mean, immediately after initial upload), don't overwrite images with substantial crops. — Huntster (t @ c) 16:52, 30 December 2020 (UTC)

@Huntster: Why a distinction between initial upload and later? An improvement is an improvement.--Marc Lacoste (talk) 07:28, 31 December 2020 (UTC)

Because once the file has been available for a little time, it starts being re-used. Editors in WP, users on other websites and on other media make a conscious selection of this version of the photo. Once this has happened we don’t want to overwrite those choices with a change that is controversial. This is the second sentence in the lead of the policy you have edited. It has been explained multiple times on your talk page. --Ariadacapo (talk) 08:01, 31 December 2020 (UTC)

So a crop of a file not used yet is an improvement whatsoever. And the 2d sentence contains minor improvements should overwrite the previous version. Cropping to magnify the subject a minor improvement, like tweaking the levels to enhance contrast. It's already illustrated by the first example, and the second example would be fitting.--Marc Lacoste (talk) 07:14, 1 January 2021 (UTC)

A change is generally accepted as an improvement only if it is generally accepted as an improvement. Instead of trying to push your opinions on good crops into policy, why not accept that people disagree on what is a good crop and put them to uncontroversial new version?--Prosfilaes (talk) 07:27, 1 January 2021 (UTC)

It's not my opinion on what is an improvement or not, it's the application of the guideline: cropping much closer to the object was considered a minor crop. Maybe the guideline should be revised?--Marc Lacoste (talk) 10:05, 1 January 2021 (UTC)

Did you read the the part of the guideline that says "Controversial or contested changes. If another editor thinks that the change is not an improvement (even if the editor making the change deems it minor), the change can be reverted, and the new image should be uploaded under a new file name" with a big red cross next to it? It’s becoming hard to assume good faith with your constant arguing back and forth, after years of other editors reverting your changes and patiently explaining to you that your crops are clashing with the choices of the authors and uploaders. -- Ariadacapo (talk) 12:00, 1 January 2021 (UTC)

Marc Lacoste, this is quickly moving into the territory of "I Didn't Hear That". I don't like doing this, ever, but I'm putting on the admin hat for a moment and specifically telling you to stop uploading over existing files, period. If you cannot understand, through reading and through user feedback, that certain actions are unwelcome, then you should not be performing the action at all. Upload all crops to a new filename starting now, please, unless the original upload was your to begin with. The fact that you've continued to tightly crop multiple files just since your last reply here is very telling. — Huntster (t @ c) 13:20, 1 January 2021 (UTC)

replace by file with correct extension

Some people upload fake SVG files, that contain nothing but a PNG. (Downloading them gives a file called index.png.) The fake SVG should be overwritten with that index.png, and the file (extension) should be renamed. Currently the only way is to upload the PNG separately, and then to mark the fake SVG as a duplicate (done here). But it would be preferable, to keep the information about the original upload. --Watchduck (quack) 17:50, 9 May 2021 (UTC)

@Watchduck: We have no way of renaming to a different filetype. You may make a case for one by following mw:How to report a bug.   — Jeff G. ツ _{please ping or talk to me} 18:19, 9 May 2021 (UTC)

Done: https://phabricator.wikimedia.org/T282392 --Watchduck (quack) 20:01, 9 May 2021 (UTC)

@Watchduck: Renaming means that it is a PNG with filename *.svg that should be correct, however your example is a FakeSVG not a PNG, so we need to extract the PNG (not only rename the SVG). Extracting is currently not desired, see Commons:Deletion_requests/Category:Fake_SVG_with_raster_version_available, and also consider traceability of copyright issues. Please start a Commons:Village_pump/Proposals to (a) extract PNG/JPEG from FakeSVG/FakePDF or (b) ban FakeSVG/FakePDF without replacement . I would strongly suppose both proposals.  — Johannes Kalliauer - Talk | Contributions 22:31, 24 May 2021 (UTC)

@JoKalliauer: I would like to overwrite fake SVGs with the extracted PNG. But currently this is not possible, because the extension does not match. What is needed is a combination of overwriting and renaming. I could have made a feature request for that bundle, but following Jeff's advice above, I asked only for the renaming part.

I don't think there will be opposition to overwrite fake SVGs, once it is possible. It avoids confusion about the file type, and there is no disadvantage. Extracting is not desired, when it creates a duplicate file. Deleting the original (like I have done here) is not desired, because it confuses the history. I am asking for a tool, that avoids both problems. As I don't see potential for disagreement, I don't intend to start another discussion. --Watchduck (quack) 11:15, 25 May 2021 (UTC)

@Watchduck: Sorry I misunderstood you. So you suggest that under File:filename.svg you could safe a PNG-file, if the previous version was a fake-svg? I also support this request, however having a png under *.svg will lead to problems. E.g. many *.js work dependent on the file-extension (e.g. Sarang's skript). Also then a PNG with filename *.svg could now be a duplicate of *.png or the other way round. I think having a png safed under *.svg is not a good idea, I prefer to move the file to *.png after extracting.  — Johannes Kalliauer - Talk | Contributions 15:48, 25 May 2021 (UTC)

Somehow we are still talking past each other. So I will describe it step by step:

overwriting a fake SVG with the wrapped raster image

Aquaman uploaded File:Ducks and weird black bird.svg, which is actually just a wrapped JPG. I download it and extract the JPG. I go to Special:Overwrite-with-different-filetype and enter three things: Old file name: "Ducks and weird black bird.svg" (Then the old image is shown on the page.) New file: I upload the extracted JPG. (Then the new image is shown next to the old one, simply to avoid mistakes.) New file name: "Ducks and common coot" (The old name is already filled out, but can be changed. The extension is taken from the upload.) Then File:Ducks and weird black bird.svg will redirect to File:Ducks and common coot.jpg. The fake SVG appears in the file history and in Special:ListFiles/Aquaman. That is the use case I was talking about. It should be uncontroversial.     There is also a second use case, which would require some discussion:

overwriting a raster image with its vectorization

Someone (*cough*) uploaded File:Syllogism-Set-Diagrams.jpg, which should have been a vector file in the first place. Someone else downloads it, creates a vector version based on it ... ... and goes to Special:Overwrite-with-different-filetype: Enters the old file name: "Syllogism-Set-Diagrams.jpg" Uploads the SVG. Keeps the name unchanged. Then File:Syllogism-Set-Diagrams.jpg will redirect to File:Syllogism-Set-Diagrams.svg. I have to stress, that this would be only legitimate, when it is a faithful vectorization, that looks practically the same. Other examples would be File:Greek letter sigma.png and File:Greek letter sigma serif+sans.svg.

BTW, I disagree with your opinion, that the upload of fake SVGs should be forbidden. It is perfectly possible, that some archive has thousands of JPGs wrapped in SVGs, to store author names and image IDs. Then we still want these images, if they are willing to donate them. --Watchduck (quack) 20:44, 25 May 2021 (UTC)

e/c

@Watchduck and JoKalliauer:

I disagree with the premise.

"The fake SVG should be overwritten with that index.png, and the file (extension) should be renamed."

Yes, it is odd that a fake-SVG file is merely a wrapper for a standalone PNG file, but why is that important to fix? The SVG file will still display the expected image. Why not just leave the SVG file as is?

I understand that such PNG files offend sensibilities, but there have been poor actions in the past. Somebody uploaded an SVG; it was noticed a couple years later; the PNG was extracted to a new name and the original SVG was deleted and the contribution record of the original uploader lost. We understand that should not be done.

Leaving the original name as a redirect saves the history, so it is a better option. But why not just live with only the original SVG? You don't need to rely on a reference left on the new PNG page.

Many of the fake-SVG files can be improved by using additional SVG elements. Consider the first file in Category:Fake SVG with raster version available and its PNG:

• File:2020 Rat HANT.svg first uploaded 8 Jan 2020, 304 kB
• File:2020 Rat HANT.png first uploaded 8 Jan 2020, 209 kB

Arguably, Sanmosa should have just uploaded one format since the image is the same. But look what happened. In August 2020, TKsdik8900 came along and converted the fake-SVG to real vectors. The size came down from 304 kB to 32 kB (it would be more if the Chinese characters were not converted to curves). TKsdik8900 did not remove the fake-SVG tag, but it shows that the {{Fake SVG}} can be viewed as an invitation to improve the SVG file rather than extract the PNG and replace the SVG.

Many of the fake SVG files can be improved. Replacing bitmapped text with text elements is a simple improvement. File:Arm Bones-eu.svg and others could be improved that way. File:Bandera de Encío (Burgos).svg has block colors and a constant border width; it should be easy to vectorize. File:Coat of Arms of Joan of Bourbon.svg is more involved, but it could be improved with pattern fill or an feTile while a PNG version could only have its resolution adjusted.

File:Donate stamp.svg is a fake-SVG. Its rendering is a little off (there is unrealistic ink in non-stamp areas), but if librsvg supported textPath, then it could be a compact SVG using the filter element. But that file (like many files on Commons) is little used, so why worry about it? Files with low usage do not need to be improved. Conversely, if a file is heavily used, then improving the SVG would reach a larger audience.

As to the comment

"I don't think there will be opposition to overwrite fake SVGs, once it is possible. It avoids confusion about the file type, and there is no disadvantage."

I oppose overwriting fake SVGs. The file-type confusion is insignificant, and there is no significant advantage to the replacement. In fact, there is a disadvantage if the SVG is subsequently improved as in the File:2020 Rat HANT.svg case above.

Yes, there are nonsensical SVG files, and it would be both absurd and inefficient to upload File:Mona Lisa.jpg as an SVG. But most of the fake-SVG files should be left alone while they await possible improvement.

Glrx (talk) 22:21, 25 May 2021 (UTC)

"The file-type confusion is insignificant" The file extension creates the justified expectation, that the image can be edited with the software for that file type. And the extension ".svg" creates the justified expectation, that the image is in fact scalable. (Some people find that important, and think it is automatically useful to replace PNGs with SVGs.) Anyway, If you think this is not important, I do not intend to convince you otherwise. But I want to make clear, that there is in fact no disadvantage.

"the original SVG was deleted and the contribution record of the original uploader lost." That is exactly what I want to prevent. That is why I propose this tool.

"You don't need to rely on a reference left on the new PNG page." Exactly my point. See the first use case above. ("The fake SVG appears in the file history and in Special:ListFiles/Aquaman.")

(Answer by Grlx at this point.)

"In fact, there is a disadvantage if the SVG is subsequently improved" No. See the second use case above. If File:Wrapped_raster.svg is overwritten with File:Raster.png, that keeps no one from again overwriting it with File:Vectorised.svg. Then there will be three files in the file history. (This happens within years - if at all - so there is no reason to worry, that frequent file renamings would be annoying.)

"But most of the fake-SVG files should be left alone while they await possible improvement." I find your choice of words misleading. A vectorisation is not an "improvement" of a raster image. It is a completely new image, and that kind of overwrite is likely to be controversial, except in very clear cases like File:Greek letter sigma.png. --Watchduck (quack) 00:02, 26 May 2021 (UTC)

@Watchduck: "But I want to make clear, that there is in fact no disadvantage." Please revisit the discussion about File:2020 Rat HANT.svg. Assume that the creator had never uploaded File:2020 Rat HANT.png Your scheme would create that PNG, and that PNG would always be redundant to the fake SVG and inferior to an improved SVG. So why have both files? That does not sound advantageous. The SVG-shrouded bitmap will scale just as well as the replacement PNG. Glrx (talk) 23:40, 25 May 2021 (UTC)

"that PNG would always be redundant to the fake SVG" No, it would take the place of the fake SVG. There would be one file page with two entries in the file history.

I agree with you, that this image is so vectory in nature, that the second use case would be legitimate. It would make sense to overwrite the PNG with a (potentially partial) vecorisation. But that would also be true, if this image had only been uploaded as a PNG.

The community will have to decide, if and when overwriting raster graphics with vector graphics is legitimate. I think it might be accepted for cases like this, that or your example.

Whatever the consensus may be, it should be irrelevant if the uploader chose the wrong file extension or not. In cases where it is legitimate, it should also be legitimate, if the user uploaded the PNG with a PNG extension.

TL;DR: If you think that vectorizing vectory raster graphics makes sense, and should not lead to duplicates, then you are actually for my proposal. :D --Watchduck (quack) 00:38, 26 May 2021 (UTC)

No, I am not for your proposal. I oppose it.

"No, it would take the place of the fake SVG. There would be one file page with two entries in the file history."

There would be two file pages. Redirects are normal file pages that have a redirect command.

For example, some time ago, I requested that File:Copie de Medio-lateral-episiotomy.png be renamed. If you follow that link, you will end up at the renamed file File:Medio-lateral-episiotomy fr.png. The original name ("Copie ...") page is now a redirect page that can be seen at https://commons.wikimedia.org/w/index.php?title=File:Copie_de_Medio-lateral-episiotomy.png&redirect=no . There are two file pages, and the file histories of two pages are different.

If someone uploads a PNG, then the vectorization of that PNG into an SVG will be a second file page. After uploading the SVG, the PNG should remain as a separate file and should not be deleted and should not be redirected. The history of the original PNG should not be merged into the history of the derivative SVG.

Files may be overwritten with minor improvements. For example, JPEG and PNG files may be cropped to remove white borders. SVG files are also overwritten with improvements.

Glrx (talk) 18:49, 26 May 2021 (UTC)

"There would be two file pages. Redirects are normal file pages"   No need to fight about words. When I say "file page", I mean a page showing a file.

"the file histories of two pages are different."   And when I say "file history", I mean the section with that heading. (e.g. here)

(1) "The history of the original PNG should not be merged into the history of the derivative SVG."   That is a pretty common opinion, and I do not mean to convince you otherwise. But if that is what you think, it does not make sense to make an exception for PNGs with the wrong file extension.

(2) "that PNG would always be [...] inferior to an improved SVG. So why have both files?"   (1) and (2) just don't fit together. Above you have made the point, that it is better to have the original raster graphic in the file history below the vectorisation.

You can be for overwriting some raster images with vectorisations, or you can be against it. But you can not pretend, that an SVG wrapped raster graphic is already a vector graphic, that is only "improved" by its vectorization. --Watchduck (quack) 20:08, 26 May 2021 (UTC)

The flag of Theseus ?

See File:African Britain Flag.svg

If an editor, not the original uploader, uploads a new version, changes the description and then requests a rename, then is it still the same upload?

Surely this should have been done as a new upload? Andy Dingley (talk) 13:06, 24 July 2021 (UTC)

It seems there is a disagreement on dimensions. I reverted. In this case there would have been little harm, as the file was based on a photo from which dimensions are not easy to see and the file was recently added to the Wikipedia articles by the uploader of the new version. The change per se might have been OK, especially with the summary ("boldly ..."), but combined with the renaming request, with no note to the original uploader that I see, this seems like an attitude we should not encourage. –LPfi (talk) 15:59, 24 July 2021 (UTC)

Support Andy and LPfi's revert. The cited source says the dimensions of the flag at the Tate are 130 x 267 cm, so the flag is 2:1 and not 5:3. Glrx (talk) 16:03, 24 July 2021 (UTC)

LPfi "No note to the original uploader" is an ironic gripe to express - I wasn't notified about this discussion! Glrx The dimensions are in fact easy to see, and are plainly 3:5. A 1:2 flag would have diagonals that are quadrilateral. The original does not. The dimensions given are either in error, or there is more than one physical flag. GPinkerton (talk) 23:41, 24 July 2021 (UTC)

@GPinkerton: The dimensions are easy to read. You added that reference. Why are you trying to eyeball a ratio when it can be read in the source? The image you point to looks like 1:2 to me: estimate the midpoint and the left half looks square. It is certainly not 3:5: arc the height to the base and another arc (not 2/3 of an arc) is left. You have been involved in a previous instance of arbitrarily overwriting flag ratios. The sources you supplied do not mention a second flag. Glrx (talk) 00:39, 25 July 2021 (UTC)

@Glrx: The image I linked to is clearly 3:5 and is even more clearly not 1:2. The diagonals are plainly not those of a 1:2 flag and the angle are clearly about 31 degrees. Why are you trying to estimate a size when the pattern of the flag shows the size is clearly the standard ratio: 3:5. I have never once "been involved in a previous instance of arbitrarily overwriting flag ratios", what are you speaking about? GPinkerton (talk) 03:42, 25 July 2021 (UTC)

Unlike the press release you've cited twice the gallery's catalogue lists the flag with a 3:5 ratio, measurements: 1445 × 2590 mm. Certainly not 1:2! GPinkerton (talk) 03:52, 25 July 2021 (UTC)

This discussion should be held on the file talk page, not here, as it is about facts. The fact that is relevant on this page is that the right dimensions are disputed in good faith, and in such a situation upload under a new name should be the obvious solution, and the one this guideline points out. –LPfi (talk) 17:00, 26 July 2021 (UTC)

I now did so, linking them to each other. You might want to check I didn't get anything wrong with the descriptions. I am also not sure about what the attribution should look like. @SpinnerLaserz: –LPfi (talk) 17:40, 26 July 2021 (UTC)