Template talk:Keep local

Opening heading

Why do we allow this? It strikes me as pretty stupid. Plrk (talk) 13:58, 17 March 2009 (UTC)

Indeed. I would have hoped that anyone who wanted to help Wikipedia by contributing images would be prepared to let the community decide the best way to organise their freely licensed media files. This is likely to mean moving them to Commons where such content is better managed. Category:KeepLocal suggest there are around 420 files with this. Adambro (talk) 14:56, 17 March 2009 (UTC)

I disagree. Rather than being "better managed" on Commons, there is ample evidence to show that is worse. Until this changes, the ability for an editor (or the editing community) to monitor and maintain media files on Wikipedia must be retained as an option for those who wish to do so. Senator2029 • talk 19:53, 26 September 2012 (UTC)

This template has now been proposed for deletion twice, discussion linked above, and both times the consensus was keep. The issue was also debated here concluding that images bearing a keep local template should be exempt from speedy deletion on the grounds of a Commons duplicate. SpinningSpark 19:58, 31 March 2011 (UTC)

Justification?

Would it make sense to have a field for 'justification' in this template? It is all very well for an uploader to slap a KeepLocal on an image, but as with fair-use justifications, it seems like a useful thing to actually know why an image ought to be kept locally rather than moved to Commons. There may be good reasons for it (like that it is in use by widely used templates which would break if Commons were to rename the files, or that there's a legal reason) but if one is putting a KeepLocal template on a file, it would be useful for other people who work in the File namespace as well as those on Commons to know why the image is being kept locally. —Tom Morris (talk) 13:21, 29 May 2011 (UTC)

It makes no sense to have a justification field while there is no agreed list of acceptable justifications written into the guidelines. At the moment it seems to have been accepted that local copies can be kept for the purpose of monitoring, which is why I do it. In any case, a template talk page is not the right place to have a policy debate. SpinningSpark 15:36, 29 May 2011 (UTC)

I disagree. Some people seem to slap KeepLocal on something because they just don't want to have to deal with Commons. And until there is a list of good reasons for putting KeepLocal on a file, it seems reasonable to ask people placing it on there to provide a reason so that others who frequently move files to Commons can come to a judgment of whether that reason is valid or not. Until we have such a list of acceptable KeepLocal reasons, perhaps a simple common sense test should apply. If I put a banner on articles I created called "DontDelete", the lack of a codified set of acceptable reasons to delete or keep something is not a reason to not ask for some reason.

I did look for a place to start a discussion about policy, but there doesn't seem to be an active place for discussion of policy in the File namespace. —Tom Morris (talk) 18:52, 29 May 2011 (UTC)

It would make more sense if the person wanting to delete an image had to provide a reason against hosting it on Wikipedia.

As things stand, the consensus is that Wikipedians shouldn't be forced to get involved with the Commons if they want to monitor images they've uploaded. SlimVirgin ^{TALK|CONTRIBS} 21:41, 29 May 2011 (UTC)

The problem is that when image on commons is fixed (description added, better version uploaded), the one here doesn't change. This directly hurts the project. Compare File:Bij Bolszewika.jpg and commons:File:Bij Bolszewika.jpg, for example. When one of our readers clicks on the image, he will get the less friendly, tagged Wikipedia page, and he is unlikely to proceed to the better developed Commons page. I am all for being friendly to editors, but when it has detrimental effects on this project, it is a problem. --_{Piotr Konieczny aka Prokonsul Piotrus| talk to me} 16:44, 13 September 2011 (UTC)

Let me say it again: the talk page of a template is an unsuitable place to have a policy discussion (although if you do start yet another policy discussion on this a link here would be appreciated). This page is meant for discussing improvements to the template, not changes to the policies which lead to it. The problem you describe can work the other way round; a change on Commons can screw up an En:Wikipedia article, but in that case it is far worse since the change on Commons does not trigger the watchlist of any of the article editors. See this discussion for instance. SpinningSpark 17:58, 13 September 2011 (UTC)

Links to files send to Ffd or Puf

Sometimes files with a {{Keep local}} is send to Ffd and most times they are kept. Examples:

• Wikipedia:Files_for_deletion/2012_June_1#File:PETA_Lettuce_Ladies_-_keep_local.jpg the file was deleted. Probably because uploader was not the photographer and did not give a reason to keep local.
• Wikipedia:Possibly_unfree_files/2012_June_10#File:Siegfried_roy_statue.jpg the file is a picture of a recent statue located in the US. If files are not free the a keep local can't save it. (Puf is open at the moment).

If you know of some interessting FfD's you could add a link here. --MGA73 (talk) 18:52, 10 June 2012 (UTC)

Well, we just had another one, but it took me throwing a conniption fit to get them to actually respect the tagging. I'm going to try to figure out some wording to put on this tag to see if we can't head off these bad-faith noms. VanIsaac_{WS Vex}^contribs 23:12, 17 February 2013 (UTC)

WP:OWN violation?

The current text says "should not be nominated for deletion as a Commons duplicate without the permission of the tagging editor." What makes the "tagging editor" so special? Someone not using his real name (talk) 21:57, 31 July 2013 (UTC)

What makes the deleting editor so special that he should be allowed to spam deletion requests because he likes Commons better, hoping that by inattention or attrition he gets his way? And if opposed, try again in a few months? It's a balance, the current consensus is that "delete because it's on Commons" is insufficient reason to delete if opposed, and this template serves to indicate that there is opposition. Anomie⚔ 01:23, 1 August 2013 (UTC)

Ok, that makes some sense. I suppose this consensus comes from the fact that the temple (presumably with this wording) was kept at a few TfDs. Someone not using his real name (talk) 09:24, 1 August 2013 (UTC)

What makes the tagging editor so special is that they have some reason to want a copy kept local, and have gone out of their way to tag it as such. That's it. It doesn't prevent anyone from doing anything else with the file. You can copy it to commons, you can put the image on a hundred-foot-tall billboard in Times Square. But someone asked that we not delete the file from en.wiki, so don't. VanIsaac_{WS Vex}^contribs 05:17, 1 August 2013 (UTC)

• WP:OWN mainly uses the word "article", although sometimes other terms such as "content" or "material" are used instead. I'm not sure to what extent WP:OWN is meant to extend to other namespaces. At the end, there is a section about user pages. First it says that users largely are allowed to maintain pages in their user space as they see fit (implicitly meaning that a user owns the pages in his own user space), but after that, the WP:OWN page contradicts itself by telling that users do not own the pages in the user namespace. WP:CSD#U1 also implies some kind of ownership for the user namespace as a user can choose to delete his own user page at will. --Stefan2 (talk) 11:50, 1 August 2013 (UTC)

More to the point, nothing in this template either explicitly or implicitly prevents other users from editing, using, or redistributing the content - which is exactly the criteria of behaviour that constitutes OWN. VanIsaac_{WS Vex}^contribs 20:24, 1 August 2013 (UTC)

Consensus against error handling?

Hello, Spinningspark

In you revert you are implying that there is extensive consensus against error handling both here in the talk page and in the TFDs. Please show me. I don't see such thing on my own.

Best regards,
Codename Lisa (talk) 12:53, 15 March 2016 (UTC)

There is no consensus against error handling. There is consensus, from numerous discussions, that a reason is not required to be given for using this template. It is therefore incorrect to treat failure to give a reason as an error. SpinningSpark 14:18, 15 March 2016 (UTC)

@Spinningspark: Again, I don't exactly see this more questionable consensus. And how can people not have a reason for requesting a local copy to be kept? —Codename Lisa (talk) 14:49, 15 March 2016 (UTC)

I agree. There has been agreement in deletion discussions that if there is no valid reason giving for keeping a local copy, it's a violation of WP:NOTWEBHOST. Kelly ^hi! 16:39, 15 March 2016 (UTC)

It is a fair point, even though I was not going as far. The first TfD was closed with "It's not a requirement, it's a good-faith request". All I did was to make sure the good-faith request is not forgotten. People feel less compelled to keep the file local when a reason (even a weak one) is given.

Best regards,

Codename Lisa (talk) 16:58, 15 March 2016 (UTC)

Interestingly, WP:NOTWEBHOST only proscribes files that are not used anywhere on Wikipedia. I would like to see links to any debates that have used this policy as grounds to delete a file that is actually in use. SpinningSpark 19:54, 16 March 2016 (UTC)

@Spinningspark: - a couple of examples would be Wikipedia:Files for deletion/2015 October 17#Several files uploaded by User:Bedford and Wikipedia:Files for discussion/2015 November 24#Several more files uploaded by User:Bedford. Probably a lot of other examples of individual files, I recall quite a few deleted because the original uploader was long-absent and nobody could see a reason to keep local duplicates. Kelly ^hi! 08:21, 17 March 2016 (UTC)

It's more a question that you need to show that consensus requires a reason has to be given. Wikipedia: Criteria for speedy deletion excludes criterion F8 when a keep local template exists, but does not require a reason to be given. The issue has been discussed numerous times on the CSD talk page (most recent two [1][2], to say nothing of the three deletion debates on this page) but no consensus has ever been achieved to require a reason. There is no sense at all in demanding a reason until policy specifies what are acceptable reasons in the first place. SpinningSpark 17:58, 15 March 2016 (UTC)

None of those discussions discuss what parameters the keep local template should have or require. They only note that a file which is tagged with {{keep local}} do not qualify for deletion under WP:F8, but do not discuss what information the template should present. Therefore, the discussions you linked to do not have anything to do with the matter being discussed here. --Stefan2 (talk) 19:47, 15 March 2016 (UTC)

They very much do discuss what might be reasons for keep local, but no consensus has been established on what reasons are, or are not, valid, and no decision was made to put any of that in the policy. SpinningSpark 22:19, 15 March 2016 (UTC)

Those discussions discuss whether we should keep local copies of files but not how we document this and are thus of no relevance here. Whether a reason parameter is used or not has no effect on whether the disclosed or undisclosed reason for keeping a local copy of a file is valid. --Stefan2 (talk) 22:50, 15 March 2016 (UTC)

• {{Keep local high-risk}} uses this template without using the reason parameter. Instead, an {{imbox}} is used to present a reason above the template. If a warning is added when the reason parameter is missing, then {{keep local high-risk}} should be adjusted so that no warning is presented whenever the template is used. --Stefan2 (talk) 19:47, 15 March 2016 (UTC)

  Correct me if I'm wrong, but doesn't the code that was attempted to add to the template cause thousands of files already using it to be marked with an error condition? If allowed to stand, this will end up with all those files being deleted for the "error" of not providing a reason. Seems like yet another back door attempt to put an end to the practice of local copies by those that oppose it. SpinningSpark 23:12, 15 March 2016 (UTC)

  Hi again. That was actually one of the purpose.

  Even now, these files are not protected against deletion. In the past, I have removed the {{Keep local}} and inserted the speedy deletion tag. In one instance I encountered opposition, took the file to the FFD. The opposing person did come there to say there was a {{Keep local}} on the file. But the file got deleted anyway. Right now, there are 4,377 file with this tag on them and I don't think all of them need to be kept locally.

  Wikipedians are humans; they understand each other. A reason provided by the inserting person prevents all these. In fact, if this template had my error handling routine, it would have never gone to TFD three times. But purely bureaucratic tags and pseudo-consensus stops no one. At the very least, you get into these endless discussions.

  Best regards,

  Codename Lisa (talk) 10:25, 16 March 2016 (UTC)

• "In the past, I have removed the {{Keep local}} and inserted the speedy deletion tag". Please stop doing that. Whether or not you personally believe these should be kept locally, other users have made a good-faith request to do so, and it does you no harm to comply. And providing a reason for that request doesn't stop people from disregarding it, even if it should. You've got no evidence to suggest otherwise, or to say that an "error handling routine" would prevent a TfD request. Nikkimaria (talk) 12:55, 16 March 2016 (UTC)

• @Nikkimaria: And I did a good-faith assessment of the status quo and decided that those files were better off on Commons. (Of course, our dear friend Carrite below seems to believe that I did it because I am afflicted with sadism or something.) Of all the people on Wikipedia, I know best what good faith is. Regardless, persuading people to give reason leads to less problems. Reason always trumps bureaucracy in Wikipedia. Best regards, Codename Lisa (talk) 17:07, 16 March 2016 (UTC)

  @Codename Lisa: But {{keep local}} doesn't prevent the file from being copied to Commons for use on other projects - it simply requests that the file not be deleted here if/when that happens. Can you explain why you would delete a file that someone has asked not be deleted, when nothing prevents you from adding the file to Commons regardless? Nikkimaria (talk) 18:25, 16 March 2016 (UTC)

  In one case, I asked the uploader, FleetCommand. He was okay with it. In another case, the file was not used on English Wikipedia at all but was put to full protection on Commons because of extensive use. Best regards, Codename Lisa (talk) 19:09, 16 March 2016 (UTC)

  If the uploader agreed, great; if not, it's still not clear why you would proceed to delete the file anyways. A file being protected on Commons because of use outside of English Wikipedia has nothing to do with that. Nikkimaria (talk) 19:52, 16 March 2016 (UTC)

  Sure it has. It is the WP:NOTWEBHOST policy. Unused files get deleted. And I am not very comfortable with you putting me as the grammatical subject of the verb "delete". I am not admin and I cannot delete anything. Another admin does. And please don't even think of accusing me of having used deception because this whole affair based on good faith of the actors. I don't deceive. Best regards, Codename Lisa (talk) 20:19, 16 March 2016 (UTC)

  I haven't accused you of deception, I'm simply trying to understand your actions/proposal. For "delete" above, read "nominate for deletion" and the point applies - a lack of |reason= in a {{keep local}}-tagged file is not a reason to remove the tag or seek deletion of the file. There may well be other reasons to delete such a file, but those reasons would exist with or without |reason=, so I don't see how they are applicable to this particular proposal. Nikkimaria (talk) 21:39, 16 March 2016 (UTC)

  Good! Then we can finally put this irrelevant discussion aside. All I am purposing is a way to encourage editors to provide an additional reason. Because a reason helps a lot. Believe me, if I had removed {{Keep local}} in some extreme non-controversial cases, there are definitely editors who have done so in total bad faith. A reason reduces all the removal totals. Can't I at least interest you in a more vigorously-recommending documentation?

  Best regards,

  Codename Lisa (talk) 08:12, 17 March 2016 (UTC)

  No, because I don't believe requiring a reason will in any way inhibit such "total bad faith" editors, nor do I see it solving any other current problem. Nikkimaria (talk) 12:22, 17 March 2016 (UTC)

• So you admit that adding this code to the template was an attempt to get files deleted without having to go to the bother of getting a change of policy first? Please provide a link to the FFD of the file with a keep local template you had deleted. I would like to examine the rationale used in that discussion for myself. Pinging possible users who may have had files deleted in this way—@Magog the Ogre, Fetchcomms, Slim Virgin, Giano, and RexxS: @Vanisaac, Carrite, Bishonen, Kmw2700, and Colonel Warden: SpinningSpark 14:41, 16 March 2016 (UTC)

No, I am saying the exact opposite: To display a big red message, so that the problem is noted and resolved, in the form of a reason supplied. How did you manage to get the complete reverse out of my message? —Codename Lisa (talk) 19:05, 16 March 2016 (UTC)

But it won't be noted and resolved, and it was a non-problem prior to making it one with this template change. A change to the template will not add the files to anyone's watchlist so no one will will even realise this has happened. It still remains clear that it is your intention to delete keep local files that do not contain a reason for keeping. That is a big wodge of unnecessary work for the editors concerned even if they did know about it. I would find this proposal a bit more palatable if a bot was to first add a default reason to the existing files to grandfather them in. SpinningSpark 19:46, 16 March 2016 (UTC)

Okay. First you were saying consensus and now you are saying you have no faith in humanity. You seem to have assumed that someone would delete any file that has a red message on it. That's you pet peeve. —Codename Lisa (talk) 20:19, 16 March 2016 (UTC)

User:Spinningspark, what are you talking about? We have policies, such as WP:C and WP:NOTREPOSITORY and WP:NOTHOST, which stipulate which files we accept on Wikipedia. If the tagging user provides a reason for keeping a local copy, then it is easier for others to tell if the file is in compliance with policy or not. If someone nominates the file for deletion, then it is only possible to take known reasons into account, and if the tagging user's reason is unknown, then that reason can't be taken into account. It is possible that the tagging user reveals his reason in a deletion discussion, but if the user is away, then the user's reason may remain unknown when it is time to close the discussion. --Stefan2 (talk) 23:11, 17 March 2016 (UTC)

You shouldn't be nominating files for deletion in the first place unless they are already in breach of one of those policies. In particular, a file that is actually in use somewhere is not in breach of NOTWEBHOST. SpinningSpark 14:40, 18 March 2016 (UTC)

@Spinningspark: - I linked a couple of discussions for you above, but one of the reasons the local files were deleted was that the Commons versions had superior description pages to the local versions. It does cause extra work to ask volunteers to maintain and improve file description pages on more than one wiki. Kelly ^hi! 19:15, 18 March 2016 (UTC)

The most likely person to do any improvements is the original uploader and if they requested the file be kept on Wikipedia, that is were they are likely to do the changes. Changes at Commons may or may not be helpful/correct for Wikipedia, I believe I have already given some examples of where Commons changes are wrong for en wp. There are arguments for and against uploading files at either location. In any case, the arguments for and against Commons are irrelevant to this discussion; policy does not proscribe uploading here, or asking for files to be retained here. Until it does, marking such files with error messages is entirely wrong. The main argument in the FFDs you linked was that the requesting editor was no longer active on Wikipedia. So that does not set a general precedent, even ignoring the fact that it was set in a backwater location populated with deletionist intolerant bureaucrats. SpinningSpark 20:47, 18 March 2016 (UTC)

• I have been victimized by politically-motivated retaliatory deletions by the Lord of the Flies shipwreck that is Commons. I won't upload there, any file taken there with my name on it is at risk, and any file taken there without my name on it is a violation of my contributors' rights. People need to stop fucking with Keep Local tags if they are fucking with Keep Local tags, they aren't used without reason and storage space is cheap. WMF has tens of millions of dollars in the bank, they can afford to hold duplicate files, they won't melt. Carrite (talk) 15:09, 16 March 2016 (UTC)

@Codename Lisa — This means you... Carrite (talk) 15:11, 16 March 2016 (UTC)

Are you using reverse psychology to make me transfer your uploads first? That'd be fun though. Best regards, Codename Lisa (talk) 17:07, 16 March 2016 (UTC)

I am equally sick of the dubious practice of copying a file from the English Wikipedia to Commons without attribution to the original contributor, in violation of the CC-BY-SA licence. Unless a {{keep local}} template is applied here, this then allows the deletionistas to delete the file here. Later on, the file may be deleted from Commons without the original uploader ever being notified. That in itself is a good enough default reason for anybody to add a {{keep local}} template to a file they uploaded. Removing those templates is disruptive editing and needs to be sanctioned. --RexxS (talk) 21:35, 16 March 2016 (UTC)

@RexxS: That has nothing to do with this discussion. All I did was to implement a reason-checking function. What admins do to a file when they see the {{Keep local}} tag is pretty much admin business. And I don't think they delete the file. Best regards, Codename Lisa (talk) 08:07, 17 March 2016 (UTC)

@Codename Lisa: Sadly you are either naive or disingenuous. Implementing a function that highlights the lack of an explicit reason parameter as if it were an error both enables and encourages the busybodies who spend their wiki-lives looking for any reason to delete files. It is thoroughly irresponsible to use your technical gifts in the service of such low-lifes. --RexxS (talk) 08:21, 17 March 2016 (UTC)

• Comment - just for the record, I think it's a good idea to add an error category for files lacking a reason, just for administrative purposes and to make it easier for interested parties to find files that should have a reason added. Kelly ^hi! 08:23, 17 March 2016 (UTC)

• It is entirely a matter for the uploader, who is giving images to Wikipedia, as to where they are best kept and retained. Keep local ensures a file is just that. I frequently upload images which are works in progress, not intended for huge public consumption, but for the planing and development of an an article. Once lost in the Commons system that are exactly that - lost to quick change and rational arguement; an erroneous/unfinished diagram is allowed to misinform for all eternity. So therefore it us presumptuous of those such as Codename Lisa to have the audacity to presume they know better than the original uploader. Giano (talk) 10:47, 17 March 2016 (UTC)

• @Giano: I said I contacted the uploader. It appears everyone coming from this angle has ample battlefield mentality and comes here to pick a fight. Maybe it is not a good idea to construe what they say as consensus to contribute. —Codename Lisa (talk) 11:07, 17 March 2016 (UTC)

@Kelly: No, it is not at all appropriate to add an error category to files lacking a reason. It merely gives an excuse for dim-witted admins to assume that there is something wrong and delete them. Much as I guess you'd like that, it's not going to happen, because a lack of an optional reason is not an error. If there were a proposal to add a tracking category just to make it easier to categorise them, I'd have much less of an objection. But as it stands this is a naked attempt to delete files that the uploader wishes to keep on En-wp, and everybody reading this discussion can see your motives clearly. --RexxS (talk) 23:36, 17 March 2016 (UTC)

Deleting or keeping files with a keep local

8 years ago I made a post above Links to files send to Ffd or Puf and I wrote that the files often ended as keep. The links I gave actually ended as delete. I can't remember why I wrote keep.

I have made some new nominations in 2020. For example:

• Wikipedia:Files_for_discussion/2020_October_14#File:Stephanie_Biddle_Actor,_Artist,_Professional_Vocalist.jpg
• Wikipedia:Files_for_discussion/2020_September_23#File:Long_shot_of_Iwaki_station_from_the_front_of_Latov.jpg + the following 4 files
• Wikipedia:Files_for_discussion/2020_October_1#File:2014.03.29.west.hollywood.elementary.school.970.n.hammond.st.90069.jpg

The result of those was delete.

So it seems that the general opinion is:

• If the file is a copyvio then it should be deleted even if it has a keep local.
• If the file can be kept on en.wiki but not on Commons (for example {{Free in US media}}) then the local copy should be kept.

If the file have been moved to Commons:

• If uploader provide a good reason it is more likely to keep the local copy.
• If the uploader has many edits it is more likely to keep the local copy.
• If the uploader have not been active of Wikipedia for a few years then it is possible to delete files even if it has a keep local.

This is just meant as information. --MGA73 (talk) 18:55, 6 December 2020 (UTC)

Template-protected edit request on 18 August 2021

Commons:{{{1|{{FULLPAGENAME}}}}}|{{{1|{{FULLPAGENAME}}}}}

to

c:File:{{PAGENAME:{{{1|{{PAGENAME}}}}}}}}|File:{{PAGENAME:{{{1|{{PAGENAME}}}}}}}

Rationale: Right now, if the Commons file name is different you have to enter it as {1} and File: must be appended to the name, or else the link doesn't work. To prevent human error this change makes the use of File: before the name redundant, but if it is there the link still works. Jonteemil (talk) 17:32, 18 August 2021 (UTC)

I've created a sandbox and test case for this. Template:Keep_local/sandbox Template:Keep_local/testcases. The above code had unmatched {,}'s. This is fixed in the sandbox.

For pages in the File: namespace this change does not seem to break anything. However, if the namespace of the page is something other than File: (e.g. this template) it produces an incorrect link. There is one example in the User: namespace User:Sacohen11/Parametric Insurance, one in the User Talk: namespace User talk:Anupmehra/Archive6, one in the Wikipedia namespace Wikipedia:Media copyright questions/Archive/2014/August, one in Category: Category:UCLA-Los Angeles Times photographs. None of these have a working copy on commons, but the use on the category seems meaningful.

I'm not convinced about the need for this change. --Salix alba (talk): 20:27, 18 August 2021 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. * Pppery * _{it has begun...} 14:01, 20 August 2021 (UTC)

Template-protected edit request on 12 May 2022

The comma after "CSD F8" should be removed. JediMasterMacaroni^(Talk) 22:09, 12 May 2022 (UTC)

 Done. P.I. Ellsworth - ed. ^put'r there 09:14, 13 May 2022 (UTC)

"Template:NoCommons" listed at Redirects for discussion

The redirect Template:NoCommons has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 March 11 § Template:NoCommons until a consensus is reached. — Red-tailed hawk _(nest) 03:45, 11 March 2023 (UTC)

Proposed change to policy surrounding this template

Hello, I'm proposing a change to this template that would reduce the number of "orphaned" images (images with no transclusions) and hence bring the backlog down at Category:Wikipedia orphaned files.

Many files (such as this one) are tagged with keep local. They are either used on an article and then removed/replaced with a superior image or just never used on an article. Either way, they are left on enwiki with no transclusions whilst filling up backlogs and generally serving zero purpose.

My point is that it is redundant, unnecessary, and a waste of resources to have uncategorised local copies of an image if it is orphaned and not actually being used anywhere on enwiki. Hence I propose the following solution:

"Keep local" should only be used as long as the image is being actively used anywhere on the English Wikipedia. If an image does not meet this criteria, it can be speedily deleted under F9 F8.

I would also like to make the (obvioius) distinction to avoid any confusion that "keep local" is not the same as "do not move to Commons". The former still allows a move to Commons, it's just it requires a local copy to be kept. — MATRIX! (a good person!)_{[citation unneeded]} 20:39, 19 January 2024 (UTC)

Let's not. What stops someone with too much of an "OMG I have to clean up the backlog" mindset from temporarily orphaning an image so they can delete it, then restoring the use? If you really want to clear out your backlog, perhaps we should have a bot transclude all {{keep local}} images on some page. Also, I think you must have meant something other than WP:CSD#F9, as that is "Unambiguous copyright infringement". Anomie⚔ 22:22, 19 January 2024 (UTC)

Or, maybe even better, have whichever bot is tagging images with {{orphan image}} not do so (or add a "keep local" parameter to change/suppress the category) when it's tagged {{keep local}} if that's a problem for your backlog. Anomie⚔ 22:36, 19 January 2024 (UTC)

@Anomie: You're contradicting yourself. The backlog is about orphaned files - how can a file in Category:Wikipedia orphaned files have a transclusion that someone could remove? As for your assumption that someone would intentionally remove a use just to delete the image, the same could be done in bad faith with any non-free file (remove the transclusion(s) and wait for the bot to tag it) - arguably that would be worse since a bot manages that category. It's just that the community would eventually notice and reverse the actions of the editor. — MATRIX! (a good person!)_{[citation unneeded]} 14:31, 20 January 2024 (UTC)

I'm not contradicting myself, and you seem to have realized exactly what I meant. I'm not so confident the community would catch it when the end result is that the Commons version of the image remains in use. Anomie⚔ 18:17, 20 January 2024 (UTC)

No, largely for the same reasons stated by Anomie. —Locke Cole • t • c 18:27, 20 January 2024 (UTC)

Prevent use of "Keep local" template for files which are not fully or partly own work

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

In this case "fully or partly own work" should be defined as when the uploader has created a new copyright under U.S. law, i.e. fully created the media in question or made a significant effort towards the creation of the media that constitutes a derivative work. This should include taking a picture of a statue, but should exclude mere file format changes (e.g. vectorisation) and scanning a photo.

The whole premise of the keep local template is that you, as the creator of the media in question, should decide its usage and place where it should be stored. Whilst not legally enforcable (since you have released the media under a free license), it is a courtesy to the creator. This makes less sense when you haven't actually created the media in question - you were just the first to upload it.

The practical benefit to the user would be that there is more information on Commons. For instance, let's take File:IPhone 15 (logo).svg. In this case when clicking on the logo at iPhone 15, the user is taken to the local file description page. There are no file captions, localised descriptions, interwiki usage, and most importantly no categories. It is not immediately obvious why these pieces of technology are missing, since they were there for many other files. This is a clear downgrade to the end user's experience, with no tangible benefit per above.

Therefore, this would provide a benefit to the end user, and there would be little downside per second paragraph.

—Matrix(!) {user - talk? - _uselesscontributions} 06:35, 17 August 2024 (UTC)

Yeah, none of that is remotely relevant to the purpose of this template. This template exists solely to allow any en.wiki editor to not have to monitor a separate project, i.e. commons, by keeping a copy here when they have an interest in maintaining it. If the image permissions are appropriate for en.wiki, copyright is completely irrelevant. If image permissions are not appropriate, nothing in this template prevents standard deletion on regular grounds, just not the CSD basis that there's a copy on commons. VanIsaac, GHTV ^cont_WpWS 07:19, 17 August 2024 (UTC)

@Vanisaac: There's no reason someone needs to keep a local copy of an image here for maintainence. The Commons community is more than welcome to maintain the image, as well as provide translations, captions, categories, SDC depicts statements, etc. In fact, it is English Wikipedia where file maintainence is more likely to get neglected. We have >50K orphaned files here with no categories or uses here, which are just sitting around with no easy way to find them (again, no categories). Again, if you are the creator of a file, you may want to maintain it yourself on enwiki and this makes sense.

But what is happening for files such as File:IPhone 15 (logo).svg is that instead of letting the Commons community maintain a file themselves, some random editor says "I'll maintain it on enwiki instead because I want to", in the process downgrading the experience for the end user. They didn't make the media in question, they were just the first to upload it here.

Also, I did not suggest "keep local" images don't have appropriate permission. Most of the time they do.

The simple truth is that a community that's explicit purpose is creating/maintaining media is far more efficient at maintaining files than en.wiki. —Matrix(!) {user - talk? - _uselesscontributions} 09:26, 17 August 2024 (UTC)

If files are hosted only on commons, any changes to that file will be invisible to an en.wiki editor who is unable to watchlist those files here. Nobody, including you, has the right to force them to join in the horror show at commons just to do their due diligence as wikipedia editors, so if someone wants to avoid having to do that, they use this template. That is all the reason that someone needs to keep a local copy for maintenance. Commons can do whatever the heck they want with that file, but it hurts absolutely no one for en.wiki to use its own copy. If you have a file with this template you think needs to be deleted, just do an WP:FfD and inform the person - uploader or otherwise - who asked to keep it local. That's it. VanIsaac, GHTV ^cont_WpWS 00:33, 18 August 2024 (UTC)

Why does the en.wiki editor need to singlehandedly take on maintainence of a file that's - again - not theirs? Is the Commons community incapable of basic maintainence? it hurts absolutely no one for en.wiki to use its own copy - kindly read above. Yes, it does hurt the end user. When they use MediaViewer, they get directed to a local copy, again without SDC statements, captions, categories, easy navigation, etc. I disagree with the "Just put the file at FFD approach". That feels extremely inefficient, considering people will keep doing this nonsense, and then people will have to keeep FFDing. It would be better to generate some sort of policy/guideline around "keep local", otherwise it will just be ripe for abuse (as is happening now). —Matrix(!) {user - talk? - _uselesscontributions} 06:19, 18 August 2024 (UTC)

There's no singlehandedly about it. Anyone can do maintenance here. En.wiki is not a locked box that can only be opened with the master key. If you want to maintain that file here, please feel free to do so. Your obsession with whose file it is does not speak well to your attitude towards the relationship between commons and en.wiki. If it's legal to host here, who are you to tell an en.wiki editor that they can't? When commons does maintenance that ruins files for en.wiki editors, then en.wiki editors have the right to take a copy and leave commons to screw things up for themselves instead of for all the rest of us. Even when en.wiki editors just plain don't trust commons to maintain things correctly, they have the right to let them do their own thing while we do our own thing here. The fact that commons wants to not only use the work that we do here, but also to make changes away from our oversight is a huge issue of trust, and for many en.wiki editors, commons has not earned that trust. Every time you try to undermine the few tools, like this template, that we use to protect ourselves from commons, you just add one more reason why commons isn't worthy of more trust than we already give it. Please use your soapbox to guide commons to procedures that can rebuild that trust instead of coming here to demonstrate to us that commons doesn't deserve it. VanIsaac, GHTV ^cont_WpWS 18:30, 18 August 2024 (UTC)

@Vanisaac: This proposal is all but dead. But out of interest, can you please give me a reason why you (or other editors) don't trust Commons? Also, can you give an example "[w]hen commons [did] maintenance that ruins files for en.wiki editors"? Just wanted to ask. —Matrix(!) {user - talk? - _uselesscontributions} 09:51, 19 August 2024 (UTC)

•  Comment: I agree files should be on Commons because then they can be used on other wikis and Commons have a good set of categories.

Some users added the keep local because the file was highly used and some used the template because they were not sure it could be on Commons for legal reasons. Other users add a keep local because "people on Commons is crazy". Other users add no reason. Earlier some files were transferred to Commons in a bad way but today the use of FileImporter reduce the number of errors and I think admins does a good check files before they delete the local file. So I do not think there is any good reasons for a keep local anymore (except heavy use).

Files with a keep local can be deleted but not as F8. They can be deleted at FfD or PROD especially if uploader is no longer active. So a keep local is not a guarantee file will not be deleted. --MGA73 (talk) 13:01, 17 August 2024 (UTC)

You seem to have something against this template, this is the second proposal you've made with the goal of removing its use. As Vanisaac said, none of what you said here is at all relevant to the uses of this template. Anomie⚔ 13:11, 17 August 2024 (UTC)

Yes, I do have something against this template. Because it detriments the end user for no reason other than "I don't like Commons". This would make sense if you created the file, but again in this scenario, you didn't create the file. You're just saying "I'll maintain it" when you don't have to, in turn downgrading the experience for everyone (less people on enwiki actively maintain files than Commons, and I've already spoken about the downgrade to the end user). —Matrix(!) {user - talk? - _uselesscontributions} 06:09, 18 August 2024 (UTC)

Or is it that you have 2.5× as many edits on Commons as you do here, and you're an admin there too, so you're here to push a pro-Commons POV? Anomie⚔ 11:39, 18 August 2024 (UTC)

@Anomie: Really didn't need the ABF. No, I just believe that hosting files locally is just a bad experience for the end user. I'm not pushing any POV (and if I was doing so I'm failing miserably!!!), and that was an unwarranted PA which I have redacted. Per WP:WIAPA, "Serious accusations require serious evidence, usually in the form of diffs and links." —Matrix(!) {user - talk? - _uselesscontributions} 09:44, 19 August 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Slight change in wording to point new users in right direction

In the above section, I pointed out some flaws with keeping images on Enwiki when it wasn't the user's own work. A few users had trust issues with Commons for some reasons or another, which is totally fair. But I think it is important to point new users in the correct direction, especially with categories/captions. In Template:Keep local/sandbox I just added "where categories and captions may be viewed" to the first sentence. This should clear up confusion with new users unfamiliar with the difference between Commons and Enwiki. @Anomie, VanIsaac, and MGA73: Thoughts? Good/bad idea? —Matrix(!) {user - talk? - _uselesscontributions} 17:58, 17 September 2024 (UTC)

This is more a follow-up to the above closed discussion, but you'll probably have more luck discussing this at a village pump. As evident by the above discussion, this template is largely watched by people who use this because they just don't like Commons. Sincerely, someone with more edits on Commons (nevermind how much more time it takes to rack up edits writing articles vs. categorizing images), and therefore not a member of the Pure class of enwiki editors. — Rhododendrites ^talk \\ 18:17, 17 September 2024 (UTC)

I do think the above discussion probably suffers from WP:LOCALCONSENSUS issues, but maybe I'll address that at a later date. This change should be uncontroversial. —Matrix(!) {user - talk? - _uselesscontributions} 16:04, 19 September 2024 (UTC)

I note the sandbox has other changes besides yours, left over from #Template-protected edit request on 18 August 2021 above. Other than that I have no objection to the proposal. Anomie⚔ 23:33, 17 September 2024 (UTC)

I have no problems with the change but I'm also one of the "Mudbloods" that mostly edits on Commons ;-) --MGA73 (talk) 08:46, 18 September 2024 (UTC)

Edit request per consensus

Implement changes in Template:Keep local/sandbox per above section. —Matrix(!) {user - talk? - _uselesscontributions} 16:15, 19 September 2024 (UTC)

 Done Sohom (talk) 03:02, 20 September 2024 (UTC)

RfC: Limit usage of this template to files which are fully or partly own work

Should we limit usage of this template to files which are fully or partly own work? —Matrix(!) {user - talk? - _uselesscontributions} 15:28, 21 September 2024 (UTC)

Definition: In this case "fully or partly own work" is defined as when the uploader has created a new copyright under U.S. law, i.e. fully created the media in question or made a significant effort towards the creation of the media that constitutes a derivative work. This should include taking a picture of a statue, but should exclude mere file format changes (e.g. vectorisation) and scanning a photo.

Possible options:

1. Allow the uploader of a file to tag it as keep local for any unspecified reason, even if it is not their own work (e.g. File:IPhone 15 (logo).svg) (current situation)
2. Only allow the uploader to tag a file as keep local if it is fully or partly own work, or another reasonable reason (such as high-risk upload or technical bugs). (proposed)

—Matrix(!) {user - talk? - _uselesscontributions} 15:28, 21 September 2024 (UTC)

Survey

• As proposer, option 2. There was an earlier discussion but a couple of users pointed out it suffered WP:LOCALCONSENSUS issues. When a file is locally uploaded here, we get a complete mess of a file category system (e.g. in this photo why are some categories hidden and others not hidden?), no multilingual descriptions, no SDC statements, no captions, the list goes on. There is the argument that if you create media, you should be allowed to decide where it should be uploaded, however, in this scenario where this RfC applies you didn't create the media, you just uploaded it. You are just downgrading the experience of new users, who likely don't know the difference between a locally uploaded file and one on Commons. The notion that Commons is incapable of maintaining a file is also false - in fact it is English Wikipedia where file maintenance is more likely to be neglected, with for example 50K orphaned files with no easy way of finding them, many being in that category for >15 years. —Matrix(!) {user - talk? - _uselesscontributions} 15:28, 21 September 2024 (UTC)
  • Your objection to the good faith use of this template to force en.wikipedia editors to join another project in order to monitor changes to images that impact their en.wiki content is duly noted, but it is hard to take the misstatements of fact and irrelevancies in the RfC formulation and your survey comment in good faith. Mutlilingual descriptions are unnecessary for files used only on an English language-only project, and improvements in captions and categorization can be freely done by anyone who wishes, and probably should be for the sake of all the en.wiki files which are not eligible for copying to commons. Nothing in this template prevents files from being copied to commons, where that information for use by the multilingual projects can and is routinely created, just as intended. This RfC misstates the current situation, which has been explained to you before - that ANYONE can tag a file to be kept local because they don't want to deal with commons dysfunction and bureaucracy - in order to imply a non-existent WP:OWN, a disingenuous poisoning of the well that can only be considered purposeful at this point. Please retract this RfC and leave us in peace. VanIsaac, GHTV ^cont_WpWS 16:29, 21 September 2024 (UTC)

    "good faith use of this template" - forcing maintainence on enwiki, where files are more likely to get neglected, with a good proportion of files not even having {{Information}} is not justified because one random editor wanted to "maintain" the file on en.wiki. En.wiki has very little free-file infrastructure, and that is because it is not focussed on maintaining files - it is focussed on maintaining articles. Commons has a community focussed on maintaining files, and therefore actually cares more about file categories, templates, maintainence, etc..

    If you think there are no effects from keeping a local copy on enwiki, think again. Let's assume a user goes to iPhone 15 and clicks the logo image. They then go to the local file. Immediately, there's no {{Information}} template. This is very common. {{Information}} has ~97K transclusions but Category:All free media has ~144K files. Do the maths. There are no categories on the image, except categories from templates. Contrast to Commons: There is a caption, information template, interwiki usage, SDC statements, etc. This is much more useful to any end user.

    Keeping local copies provides no tangible benefit when you didn't create the media in question, other than "I don't like Commons" (barring technical reasons and high-risk files). —Matrix(!) {user - talk? - _uselesscontributions} 17:16, 21 September 2024 (UTC)

    Not being forced to join a completely separate project is a tangible benefit. You may not like it, you may not agree with it, you may hate that people don't trust a project that you have dedicated over 10k edits to in the last two years. But the people that use this template don't care how it makes you feel, they care about protecting the integrity of the work they've done. You frankly have no right to force them to join your pet project to do their due diligence in protecting their work from vandalism. If you want people to trust commons, get commons to demonstrate trustworthiness. But too many people have had works that we used or uploaded here that were ported over to commons, deleted from here, and then get absolutely banjanxed by the dysfunction over there, with no accountability to the damage they do here. I get that you are a commons denizen who wants to come here and show us the light of all that is wonderful if we would just learn to love Big Brother.. I mean Commons. But we have memories that are much longer than you've been around, and we're not buying it.

    Again, if you want to take on a project of making the en.wiki file categorization system better, by all means do so. If you want to add some template so that the self-explanatory iPhone 15 logo that literally has text saying "iPhone 15" with an apple logo has some plain text that explicitly says that it's the iPhone 15 wordmark, and it was created by Apple, then just do it. But don't sit here and tell me that an image combining one of the most recognized corporate logos on the planet with explicit identifying text is somehow confounding beyond comprehension to someone who innocently clicks on it. If it's that important to you, have someone create a tool like User:This, that and the other/For the Common Good for porting information back to local files. But trying to kill off our tools for protecting ourselves while still preserving access for the ingrates at commons doesn't fool anyone. People just want to live their life without getting screwed, and commons has shown in the past that it will gladly screw us and not care about the damage left behind. So get your act together, maybe put some pressure on WMF to enable cross-project watchlisting so that we can monitor and prevent your screw-ups before they negatively impact us, then come back and let us know so we can see if the systems have caught up to the reality this template is addressing. Until then, stop trying to tell us your two buck Chuck is Dom Perignon. VanIsaac, GHTV ^cont_WpWS 21:30, 21 September 2024 (UTC)

    The iPhone 15 wordmark was an example, but you've excessively focussed your argument on it's specific details, clearly a fallacy of composition. Really any image in the keep local category that fits the above description (we can take File:06-claycenterchautauqua-ad.jpg would work. Your comment about cross-project watchlisting is also debunked earlier. You don't need to watchlist a file that you didn't create, the Commons community can do that and protect your file from vandalism, whilst helping to add i18nised descriptions, captions, etc. Also, you keep stating that Commons cannot maintain files properly, but provide little examples. —Matrix(!) {user - talk? - _uselesscontributions} 22:28, 21 September 2024 (UTC)

    I am limited to responding to the actual arguments made. If the first file you choose as your exemplar is self-explanatory to the point of ridiculousness, that's not my fault. It's also not my fault that the second contains a full description along with a justification for its PD tag. VanIsaac, GHTV ^cont_WpWS 04:20, 22 September 2024 (UTC)

    Also your statement that people care about protecting the integrity of the work they've done is questionable given the whole premise of this RfC is about this template's applicability to uploading works they didn't create. —Matrix(!) {user - talk? - _uselesscontributions} 22:31, 21 September 2024 (UTC)

    And that's precisely the problem with this argument - the insistence that the only legitimate interest in protecting content lies in creating the actual image - that using an image is some shameful thing with no creative interest in being protected from corruption. That seems uniquely editor hostile and unworthy of this project. VanIsaac, GHTV ^cont_WpWS 04:20, 22 September 2024 (UTC)

    Not being forced to join a completely separate project I mean, it's not a "completely separate project". It's Wikipedia's image repository. The whole point was to take all the images hosted on individual Wikipedias and put them there, and it's been twenty years. People are really shaking their fist at it still? I don't much care about this proposal and don't even really care if a handful of wiki-old-timers refuse to do what absolutely everyone else does so they can feel like they have control over their wikiworld. It feels coddling, but meh, hard to articulate a real harm. But the responses to Matrix have bit a bit tribalist/battlegroundy and really do a disservice to those who use this template by making it sound like it's entirely done in bad faith (i.e. isn't you may hate that people don't trust a project that you have dedicated over 10k edits to saying the quiet part out loud?). Meh — Rhododendrites ^talk \\ 22:34, 21 September 2024 ( UTC)

    I don't think hiding the truth of how Commons has different values, purposes, and procedures than en.wiki is helpful, and I don't think it's ethical to pretend that en.wiki editors with experiences of that divergence don't view Commons the way they do. If that's saying the quiet part out loud, then I'll have to have the courage to speak the uncomfortable truths. The second uncomfortable truth is that Wikipedia does have its own image repository, but it is not Commons, it is the file namespace. Commons is a Wikimedia image repository that due to WMF architecture can also be used natively on Wikipedia. But it does not belong to Wikipedia, and it serves no one to pretend that it does. It cannot be monitored from Wikipedia, and it does not follow our policies on things like notability, so it is disingenuous to pretend that it isn't another project. Closely related sure, but definitely separate. If we have files that because of policy, values, purpose, or procedure are best handled under the auspices of en.wiki, we have our actual image repository to do that. VanIsaac, GHTV ^cont_WpWS 04:20, 22 September 2024 (UTC)

• Neutral for now, and this may really need to be a different kind of discussion. Some of the concerns raised by the OP don't actually seem applicable or material (e.g. no multilingual descriptions, and other Commons features). The {{Keep local}} template does not mean a copy cannot (if compliant with Commons requirements) be uploaded also to Commons, where those features would be available, it simply means to not move the file to Commons (i.e. copy to Commons and delete from en.WP). At en.WP, we really have no use of multilingual descriptions, since this site is entirely in English. However, this is not the first user to raise maintenance and other concerns with {{Keep local}}. There need to be clear criteria for why a local copy would be kept after a file is already available on Commons. That might really be a matter to settle at Village Pump instead of on a template talk-page RfC that nearly no one but watchers of this page (and a handful of WP:FRS users like me) will notice. Use of this template in a purely "I just don't wanna bother with Commons" vein is clearly not appropriate.  — SMcCandlish ☏ ¢ 😼  22:58, 21 September 2024 (UTC)
• Oppose And a WP:TROUT for Matrix for learning nothing from when they proposed the same thing just last month where Vanisaac already rebutted all their claims at length (and did so again just above). As already noted, if people want the file on Commons this template does nothing to prevent them from copying it there. It doesn't even stop someone from taking the local copy to WP:FFD. All this asks is that we don't speedy-delete the copy here. Further, I oppose requiring people to provide a reason for using this template. The stakes are not that high here, reasoning can be discussed at an FFD if necessary. Personally I used to like Commons, and still like the idea of it, but after some truly stupid actions by various Commons admins I gave up on the project. I'd rather not have to watch a separate project I have no trust in to make sure someone doesn't do something stupid again to files I care about. Anomie⚔ 23:30, 21 September 2024 (UTC)

  I don't really want to take a file to FfD/PROD every time and deal with potential local consensus issues. It's better to get sitewide consensus on this issue once, and then I can take actions from there. —Matrix(!) {user - talk? - _uselesscontributions} 09:10, 22 September 2024 (UTC)

  Perhaps you should give up your crusade against this template then? Although personally I'd hope that, if you started prodding or FFD-ing every {{keep local}} file with no better reasons than you've given here, people would start WP:TROUTing you for that too. Anomie⚔ 15:02, 22 September 2024 (UTC)

• Option 1 per previous discussions - not seeing anything compelling to warrant a change. Nikkimaria (talk) 01:45, 22 September 2024 (UTC)
• What, in the context of option 2, would you not consider a "reasonable" reason? (And why on earth would we, under any circumstances, broadly forbid the uploader of an image to tag it "keep local" while continuing to allow everybody else?) —Cryptic 02:07, 22 September 2024 (UTC)

  @Cryptic: This is a pretty unorthodox interpretation of my statement. I'm pretty sure no one can just tag any file as keep local for no reason if they aren't the uploader - that seems to be common sense. —Matrix(!) {user - talk? - _uselesscontributions} 09:55, 22 September 2024 (UTC)

  It's what the template says. —Cryptic 11:37, 22 September 2024 (UTC)

  While the template does say any editor can tag a file with keep local, I do think it is convention that random editors don't go around tagging random files as keep local for no reason. —Matrix(!) {user - talk? - _uselesscontributions} 14:08, 22 September 2024 (UTC)

  Who said anything about randomness, or no reason? I'll reword - why is the option 2 you're pushing adding a restriction to why only the uploader can tag a file? And what is the unreasonable reason you're trying to forbid? —Cryptic 14:21, 22 September 2024 (UTC)

  Strong oppose both. Option 1 is not the status quo as claimed, and the attempt to present it as such is a deliberate lie. Any user may tag any image as Keep Local for any reasonable reason, whether explicitly stated or not, and there's been no reasonable reason presented why we should change that. —Cryptic 23:26, 27 September 2024 (UTC)

• Option 1. I've read everything above, and re-read the discussion at Wikipedia talk:Criteria for speedy deletion/Archive 89#F8 and keep local, and I've still yet to see any convincing rationale for restricting the use of keep local. While I do upload all my images to Commons, I fully understand why not everybody does, because I too trust the en.wp processes far more. Here I can be certain that the actions following a discussion will represent the consensus of that discussion and that good-faith questions about actions taken will be answered. At Commons I was subject to about a week of accusations of bad-faith editing for suggesting that when an image has been deleted despite a deletion discussion being closed as "keep", that the reason should be noted at the deletion discussion rather than requiring people to dig through deletion logs to see if a reason was given there (iirc it was just "copyright violation" or similar, despite the discussion apparently not considering this relevant). The likelihood of an apparently random deletion on Commons is greater for files that are not one's own work than for work that is, for example material that is believed to be out of copyright in the United States and the originating country but where the latter is arguably unclear. Thryduulf (talk) 08:32, 22 September 2024 (UTC)
  • Retain the status quo. Having just seen Cryptic's comment above re option 1, I am clarifying that I see no need or benefit to changing the status quo. Given that option 1 is not the status quo, then I cannot support that. Thryduulf (talk) 10:35, 8 October 2024 (UTC)
• Option 1 - I read over the previous discussions on simply deleting this template, and the reasons given there were that commons is a separate project from us, with different standards and different procedures and methods to get things done, and so there is a valid reason to sometimes simply want a local copy on our project-- which, if it really is as copyright free as a file being on commons would suggest, is perfectly fine and acceptable to do. This means there are valid reasons to tag images you did not create with keep local. Nothing has changed this situation to my knowledge. Fieari (talk) 06:13, 8 October 2024 (UTC)
• Both options are bad First, another reasonable reason is ambiguous, leading to disputes on what is a reasonable reason and what is not a reasonable reason. Secondly, both options appear to violate WP:OWN. No one owns the file, so no one can decide that the file should use {{keep local}}. Also, no one owns the file, so no one can decide that the file shouldn't use {{keep local}}. What we need instead is a method to dispute the use of {{keep local}} if an editor adds the template and another editor thinks that the template shouldn't be used. There could also be a reason for adding the template which isn't immediately obvious for the editor who wants to remove the template. If two editors disagree on the use of the template, we need a discussion, not a dictator who decides on the use or non-use of a template.

The use or non-use of {{keep local}} is only ever relevant if the file is present on Commons, so a discussion of a file would always be about the potential deletion of the file, so the appropriate forum for discussing this would seem to be WP:FFD. Instead of discussing the use or non-use of this template, what we should discuss is guidelines to be applied at FFD to determine if a file should be kept or deleted. --Stefan2 (talk) 10:00, 30 October 2024 (UTC)

Reading more carefully, I see an additional problem. The proposal only discusses when the uploader may add or may not add the template, but doesn't say anything about when someone else may or may not add the template. The two are obviously related. --Stefan2 (talk) 10:10, 30 October 2024 (UTC)

Discussion

Pinging @MGA73, Rhododendrites, and Anomie as previous participants. —Matrix(!) {user - talk? - _uselesscontributions} 15:28, 21 September 2024 (UTC)

• The reasons for the use and retention of this template have been well-documented at the previous TfD discussions: [3], y_for_discussion/Log/2011_February_20#Template:KeepLocal, and [4]. There is no logical or functional reason to limit its usage, and to do so would violate the express reason for this template's previous good-faith usage as explained in those TfD discussions. VanIsaac, GHTV ^cont_WpWS 16:52, 21 September 2024 (UTC)

  There is no logical or functional reason to limit its usage - see above response in survey section. —Matrix(!) {user - talk? - _uselesscontributions} 17:17, 21 September 2024 (UTC)