Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
introduction
Help deskVillage pump
copyrightproposals
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P · COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

COMMONS DISCUSSION PAGES (index)


Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 

Allowing cross-namespace redirects from (Gallery)/(Main) to Category[edit]

I've been informed that cross-namespace redirects are not allowed on Commons (tho I can't seem to find the documentation). Even if we want to have that as a rule generally, I think a big exception should be from the main/gallery namespace to the category namespace. Since we mostly use categories here and have only a fraction of images as galleries, it will be very useful for incoming links and search until such time as we really populate that namespace in earnest. I think this has high value and I don't see any immediate downsides. What does everyone else think? —Justin (koavf)TCM 03:21, 9 September 2018 (UTC)

  1. Symbol support vote.svg Support, I actually wanted to propose this myself a couple of months ago but got distracted by other projects. It would be very handy if mainspace pages could direct to categories as it would make searching a lot easier, and this would also allow for names in different languages to be redirected to the same subject. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:22, 10 September 2018 (UTC)
  • Pictogram voting comment.svg Comment If you ask me: move all galleries to a dedicated Gallery: namespace and automatically redirect the "main" namespace to Category:. --El Grafo (talk) 11:53, 12 September 2018 (UTC)
  • Symbol support vote.svg Support per nominator. In addition cross-namespace redirects between Commons: and Help: namespaces should be freely permitted as there is overlap between them (see for example the location of pages in Category:Commons help). Thryduulf (talk) 23:34, 12 September 2018 (UTC)
  • Symbol support vote.svg Support per nominator. There are times that a simple gallery is best replaced with a category, but we should possibly still prefer incoming links go to the gallery page until such time that a better curated gallery is made. Carl Lindberg (talk) 01:28, 13 September 2018 (UTC)
  • Symbol support vote.svg Support - Jmabel ! talk 15:42, 13 September 2018 (UTC)
  • Symbol oppose vote.svg Oppose - it gives the false impression that a gallery page exists. Also, allowing this would cause a situation in which random pages redirected to categories. If we want non existing gallery pages to link to the category, we should request a software change instead. Either all non existing gallery pages should redirect to the category or none. Jcb (talk) 15:54, 13 September 2018 (UTC)
    • @Jcb: "allowing this would cause a situation in which random pages redirected to categories"... What? —Justin (koavf)TCM 00:52, 23 September 2018 (UTC)
      • Yes, the presence of such a redirect would depend to whether someone decided to create it. This would end up in a total mess. It's not without a reason that 'cross namespace redirect' is a valid reason for speedy deletion in our policies. Jcb (talk) 11:05, 23 September 2018 (UTC)
        • @Jcb: I think I understand your complaint here: whether or not there are gallery-to-category redirects would be essentially random. Would the solution be to have an automatic conversion, then? That is, some bot or feature of the wiki would always create gallery-to-category redirects? —Justin (koavf)TCM 19:17, 23 September 2018 (UTC)
          • I think that would cause way too much maintenance. Every day a lot of categories are being deleted, so evert day we would find dozens or even hundreds of such redirects in Special:BrokenRedirects. If we would want every non-existing gallery page to link to the category name with that name (I am not convinced that we need that in the first place), we should request a software change instead, so that a non existing gallery of an existing category would redirect automatically, without having to create a redirect page. Jcb (talk) 21:25, 23 September 2018 (UTC)
  • Symbol support vote.svg Support El Grafo's solution, all of the main namespace should be categories, and the old main should be moved to Gallery:Gone Postal ( ) 16:36, 13 September 2018 (UTC)
  • Symbol oppose vote.svg Oppose per Jcb. Good idea, bad way to implement it.--BevinKacon (talk) 22:04, 13 September 2018 (UTC)
  • Pictogram voting comment.svg Comment My first choice is to redirect all non-existent galleries to the category, if the category exists, per Jcb. If the developers tell us this isn't feasible, I'll support this proposal to allow redirects. Guanaco (talk) 00:52, 14 September 2018 (UTC)
  • Pictogram voting comment.svg Comment Some websites with encyclopedic tendencies gives links to other websites that can talk about similar subjects. Those links are, I think, given in an automatic way, with a string of characters (a part of the web adress) and of course the name of the subject treated. I saw it several times, but I remember only one precise example "mycobank". Example, in the page Coprinopsis candidata you go to the section "Link out to external resources" and you will see that a list of links is given automatically. Then if you click on "wikimedia" you come to [1]. However we have good media files for this subject. I think is is really a kind of issue, and I think the sentence "You can search for this page title in other pages or create this page." is far not enough. But I'm neutral on the way to solve this. Christian Ferrer (talk) 17:10, 14 September 2018 (UTC) I add I think that this page should clearly say that we have media files within a existing corresponding category. Christian Ferrer (talk) 17:21, 14 September 2018 (UTC)
A kind of solution could be the creation of a Wikimedia Commons template, a bit as {{Wikidata Infobox}} but with different presentation and specifically intended to the non-existing galleries. Example I just created manually Dytaster, however the totality of what is displayed (included the links to the images) is available in Wikidata, therefore this gallery could very well have been created automatically. It's a fact, and everyone agrees, that not all categories can have matching galleries, however maybe that all subjects that are worth to have both a Wikidata item (therefore notable enough) and a category here, should have a gallery. And when this gallery don't exist, it will created by a bot with a dedicated template which would bring relevant content from Wikidata, and then, we will keep the possibility to add manually some content in addition to the template, or to replace manually the template by some content. This should solve the issues for the incoming links. @Mike Peel: who is used to relationships Wikidata/Commons. Christian Ferrer (talk) 08:39, 16 September 2018 (UTC)
Note for who did not understood what I wanted to mean, I was talking about galleries in this kind : Prionocidaris, almost entirely autonomous, and in some ways a bit useful. Christian Ferrer (talk) 19:33, 23 September 2018 (UTC)
  • Symbol oppose vote.svg Oppose per Jcb. Ankry (talk) 09:06, 19 September 2018 (UTC)
  • Symbol support vote.svg Support, as this will allow to go around the decision to keep some really misleadingly poor galleries upod deletion request taken by some otherwise deletionist admins. Of course the proper thing to do would be to move to the concerning categories the scare gallery content that is not sheer nonsense, and then delete the whole namespace once and for all. (Some content currently in the gallery namespace should be moved to the Commons namespace instead.) -- Tuválkin 23:10, 23 September 2018 (UTC)
    • You are not allowed to circumvent admin decisions even if the policy on such redirects would change. Jcb (talk) 15:47, 24 September 2018 (UTC)
  • You really cannot make this stuff up. -- Tuválkin 22:05, 12 October 2018 (UTC)
@Jcb: You are not allowed to circumvent policies.   — Jeff G. please ping or talk to me 03:28, 13 October 2018 (UTC)
  • Weak support, prefer User:El Grafo's solution. Separately: I think galleries are way under-used. There is a ton of potential there, almost none of which has been exploited. - Jmabel ! talk 15:56, 24 September 2018 (UTC)
  • Symbol support vote.svg Support if this means that searching for "AC power" won't take me to this nearly useless gallery anymore. Or is that what El Grafo said? in that case I support that proposal. - Alexis Jazz ping plz 16:24, 24 September 2018 (UTC)
  • Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 03:28, 13 October 2018 (UTC)
  • Symbol support vote.svg Support. ReaperDawn 11:06, 21 October 2018 (UTC)

File deprecation feature[edit]

Currently, we only have one method of resolving unwanted files: deletion. This hides the file, its description, and its history from public access, making it viewable only by administrators via Special:Undelete. For copyright violations, severe personality rights issues, vandalism, and aggressive spam, this is entirely warranted. For duplicates, superseded files, low-quality redundant files, and most personal files by non-contributors, a softer approach could be just as useful, while allowing greater transparency and collaboration with non-admins.

File deprecation would be a logged action that can be performed by admins and trusted users in a new user group. It would function similarly to deletion, where one specifies a reason, clicks a box to confirm, and then the file is marked deprecated. This would have the following effects:

  • When viewing the file page, a reader sees a system message informing them that the file has been deprecated. This message is editable via the MediaWiki namespace. Below the system message, the file and description are displayed normally.
  • Transclusion of the file is disabled. If a file is currently in use, it cannot be deprecated.
  • The file page is noindexed.
  • By default, deprecated files do not appear in categories. Logged-in users can show deprecated files via a user preference. If this setting is enabled, they are instead clearly marked as deprecated files in the category listing.
  • Deprecated files may be redirected to other file names. Linking to such a redirect will display the target file (standard file redirect behavior).

I see the new user group having a similar level of trust as a file mover, with about the same risk of damage by a malicious user. An understanding of policies and guidelines would be needed, especially Commons:Project scope and knowing when to nominate a likely copyvio for deletion rather than deprecating.

This would of course require developer support to implement. Before I create a Phabricator ticket, I'd like to see everyone's thoughts, improve the proposal in every possible way, and determine whether this is something we want as a community. Guanaco (talk) 06:40, 19 September 2018 (UTC)

This is too thinly considered to bring it here now. What exactly must MediaWiki do with [[Image:deprecated file name.ext|…]] tags? What namely means “may be redirected to other file names” – do you mean such file may be browsed only with &redirect=no? Should deprecated files be visible in Special:ListFiles by default? Incnis Mrsi (talk) 07:10, 19 September 2018 (UTC)
I agree it's too early for voting, but I know of no better place to discuss such an idea. For [[Image:deprecated file name.ext|…]], it could show an error message similar to template loops or parser function exceptions. If this is implemented as an extension and not on all Wikimedia wikis, I think it would have to be a red link as with a non-existent or deleted file. I imagine redirects would need to be browsed using &redirect=no, which is simple enough to reach by using the (Redirected from File:Example.jpg) link. Alternatively, it could function as a soft redirect. Special:ListFiles could use a check box, right below the "Include old versions of files" option. Guanaco (talk) 07:39, 19 September 2018 (UTC)
  • Making some files noindexed but available for review is IMHO a clever approach. Just some notes about implementation. First, don’t press for development of all desired functionality at once. The core attributes—namely a new field in the image table, access to it from the Web interface, and noindexing—must be deployed before further refinement of the feature by the Commons community. Second, some changes and clarifications in the criteria should follow. Third, an awareness campaign (first, targeting sysops only) must be conducted after deployment and “old-style” deletions should become discouraged wherever the deletion request indicates that the file(s) is to be deprecated. Fourth, a guidelines for converting deleted files to deprecated have to be set and the respective process should start soon – otherwise I don’t see much room for application. Incnis Mrsi (talk) 17:13, 20 September 2018 (UTC)
  • Not sure I understand the "personal files by non-contributors" use-case. Are we not creating a semi private "dropbox" storage space for "trusted" users to host their own out-of-scope photos. Most users would want deprecated files hidden, as would any IP I assume, so such a stash of unwanted images would may lay undiscovered. If such images were to be discussed in a forum or talk page, I'd need to go to preferences, change my setting, view the image, then reverse my preferences. What is this buying us? -- Colin (talk) 18:01, 23 September 2018 (UTC)
    I used the phrase "personal files by non-contributors" because it's one of the new criteria for speedy deletion. Contributors can have some files in userspace, but using Commons as a personal webhost is and still would be unacceptable. It's technically possible someone could upload excessive personal files and attempt to conceal them via deprecation. However, the motivation for this is limited with such abundant, free services as Google Drive, and the risk of being called out on COM:AN/U would be high. Admins can do this more effectively via deletion; so far I've never heard of such abuse. Regarding your second concern, direct links to a deprecated file would work without any change in preferences. They would only be hidden from categories and other content space. Guanaco (talk) 22:47, 24 September 2018 (UTC)
  • Ok, can you describe some use-cases where file deprecation gives us advantage over deletion. I'm struggling to find a reason why non-admins need to see these files, vs the extra admin hassle that people can still try to link to them or edit them with vandalism or upload a new image over the top of them that is problematic. People doing category maintenance would have the problem that they'd either have to (a) also maintain this junk or (b) leave the junk in the wrong place because they don't see it. -- Colin (talk) 11:39, 25 September 2018 (UTC)
  • Symbol support vote.svg Support, but can files be reinstated if they are used on another project? Let's say that a user uploads an image of A famous building in a rather remote area but its not the best quality, another user uploads a better quality image with the OTRS template but the ticket turns out to be invalid because the photographer can only agree to a non-commercial license and is deleted as a copyright violation, would this inferior photograph be unable into the Wikipedia article it was removed from as the only useable free file or would undeletion be have to be requested as with deleted files? Are categories then removed or do they appear as "invisible" unless enabled? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:41, 26 September 2018 (UTC)
    • In that situation, the lower-quality photo should never have been deleted (or deprecated) in the first place. "Better" or "superseded" should never result in deletion. The "redundant" or duplicate type of deletions are the one case where I could sort of see this, but not sure it's worth the development or maintenance effort -- if there an argument on a validly licensed work, it's best to simply keep both. Commons is about providing as many options as possible, and let others decide "best" for their situation. We don't curate, or decide "best" because even if a photo is not as good for one particular Wikipedia article, maybe it is better for some other aspect of a Wikibook, or something like that. I would not want a deprecation feature to give further freedom to deprecating works that we currently keep. And Colin's point of abuse possibilities is a good one; if such files are linkable from the outside (which they would almost have to be, if you can still go to the image page and see the image), such files could be used to simply use Commons as image storage. There have been examples of that in the past (for example see Commons:Village pump/Proposals/Archive/2017/06#Restrict_Video_Uploading), and it may make such things harder to find, and would require careful implementation to not allow additional avenues of abuse. I'm not sure this feature is worth it. Files with different licenses should not be "redundant" and deleted in the first place, for reasons like you give. Carl Lindberg (talk) 16:15, 26 September 2018 (UTC)

Commons:Deletion requests/File:Wikipedia technician.svg could become one of test cases – almost exactly condition envisaged by Guanaco. Incnis Mrsi (talk) 17:56, 23 October 2018 (UTC)

Why is Huggle read-only?[edit]

I have noticed repeated vandalism on Commons, when logged in with Huggle, but since Huggle seems to be read-only on Commons, the program functions cannot be used, why reverts must be done manually, in spite of my rollback rights. have I misunderstood this, or is Huggle read-only? Can the functions in Huggle be activated on Commons? Dan Koehl (talk) 08:28, 8 October 2018 (UTC)

As of 2011 the status was "needs further configuration and api update" (via →Commons talk:Hugglew:Wikipedia:Huggle/Feedback/Archive_16#Commons). I haven't been able to find any further updates. Looks like that's something only the Huggle developers can solve … --El Grafo (talk) 09:19, 8 October 2018 (UTC)
Thank you @El Grafo:, I made a request at en:User_talk:Petrb#Huggle_on_Commons. Dan Koehl (talk) 09:55, 8 October 2018 (UTC)
Hello, you can see phab:T149290 for details, the problem right now is with template parser, commons is only wiki that uses auto translating templates which don't contain any unique strings that could be used for identification of warning level they represent. Solution would be to add some "magic" like invisible comments similar to what we have on English wikipedia, for example <!-- uw-test1 --> etc so that Huggle would know which warning level it is. Without this it's not easy to enable Huggle in write mode as it wouldn't be able to recognize last warning level of template on vandal page. Petrb (talk) 20:21, 8 October 2018 (UTC)
@Petrb:, This is easy to solve, by just changing icon, but the files are protected, I have applied at Commons:Administrators'_noticeboard/Blocks_and_protections#edit_on_Test2_and_Test3 to change the icons, so they can be unique for the different levels. Dan Koehl (talk) 20:32, 8 October 2018 (UTC)
Why was a paragraph removed? ℺ Gone Postal ( ) 05:03, 9 October 2018 (UTC)
Pinging @Dan Koehl.   — Jeff G. please ping or talk to me 12:54, 25 October 2018 (UTC)
Sorry @Jeff G.: if that was my mistake, it was not my purpose. I have been trying to help out with this issue, and hope that Huggle soon will become a helpful tool in Commons anti-vandalism. Dan Koehl (talk) 05:21, 27 October 2018 (UTC)

Missing functionality in the reviewers gadget[edit]

I don't know where to raise this issue but I think it lacks some basic functionality. When the review process fails (if the image is copyrighted), the gadget inserts a {{speedydelete}} template but does not warn the uploader. Shouldn't the gadget warn the uploader as well? --Discasto talk 07:52, 18 October 2018 (UTC)

I often don't know where to ask software-related things either, maybe we should have a Commons:Village pump/Technical for these things. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:52, 23 October 2018 (UTC)

Create a Technical Village pump[edit]

Currently there is no page called "Commons:Village pump/Technical even though there appears to be some demand for it, a lot of talk pages of tools seem to be unmonitored and often technical questions and/or requests seem to pop up here, at the help desk and at the regular village pump all the time, maybe creating a separate technical village pump could benefit users with more technical requests. This would also be easier for users who do have the technical expertise to help other people to only have to monitor a single place for technical questions. Often I see technical questions in the help desk go unanswered simply because that fortnight no technician bothered to check.

I think that the English-language Wikipedia also has one but I'm not certain. Is this viable? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:45, 23 October 2018 (UTC)

  • Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 02:51, 24 October 2018 (UTC)
  • Symbol support vote.svg Support I'm all for it. -- Sixflashphoto (talk) 02:56, 24 October 2018 (UTC)
  • Symbol support vote.svg Support I think that this is really a good idea. ℺ Gone Postal ( ) 13:17, 24 October 2018 (UTC)
  • Symbol support vote.svg Support. ReaperDawn 02:38, 27 October 2018 (UTC)
  • Symbol support vote.svg Support. This makes sense. Dan Koehl (talk) 05:21, 27 October 2018 (UTC)
  • Symbol support vote.svg Support very much needed. --✝iѵɛɳ२२४०†ลℓк †๏ мэ 11:35, 27 October 2018 (UTC)
  • Symbol support vote.svg Support in principle, but before it goes up I’d like to see a more detailed proposal, including revisions to the main noticeboard header (which exists in numerous languages), any other relevant navigation templates, and incoming links from Help pages &c.—Odysseus1479 (talk) 16:21, 27 October 2018 (UTC)
@Odysseus1479: Commons:Village pump/Copyright just has autotranslate templates on it. If this proposal has community support and someone could put those templates together and could set up the autoarchive system after its done, just designing the page Commons:Village pump/Technical wouldn't be that difficult. I don't think i'm missing a step other then implementation. Also I am going on the possibly wrong assumption that one could put together Template:Village pump/Technical/Header put it into a page and you don't have to do each language template individually. -- Sixflashphoto (talk) 16:30, 27 October 2018 (UTC)
  • Symbol oppose vote.svg Oppose I don't think a new board is solving the issue, yet a other board will just confuse new users. --Steinsplitter (talk) 15:20, 7 November 2018 (UTC)

Policy proposal concerning edited images[edit]

Example: source original & result of manipulation

Following a discussion (in Dutch) in De Kroeg, I'd like to make a proposal for a policy change, stating that user edited images from an external source should always be accompanied by a message, either in template or words, that the file consists of an image that is an edited form of the image the given source provided.

The discussion was raised by myself, after I found that a user was (and is) repeatedly and without exception uploading pictures of artworks, which are heavily (although some might say slightly, or not even notice a difference at all) edited images that originate most often from renowned museums, auction houses and other art institutes. By uploading the edited image, and not the original from the source, the impression cannot but be brought into existence, that the uploaded image equals the image from the source given, if any message on the editing done is lacking. Such a way of operating, in my opinion, is descrediting the source, discrediting Commons as well, and is deceiving a possible audience. The user around whom this proposal – that transcends the particular case – is made, has been requested by multiple users to a.) upload the source original as well, and b.) add a retouched-template to the description (which in my view should precede any other file information), but he refuses to do so and there seems to be no way to correct him.

Resume: add to the policy of Wikimedia Commons an obligation for users to state that a file, if indeed so, is an edited version of the file provided by an external source, so that violations of this kind can be tackled. Jürgen Eissink (talk) 19:33, 1 November 2018 (UTC).

I support in general. However: 1) We need to explicitly allow lossless transformations. I always perform lossless optimisations of files before uploading them here. This does no harm except saving Commons some space and traffic. 2) No user should ever be banned from contributing just for not providing such notices. It would be a shame to start losing contributors just because they forgot to write something about the file. I agree that this can be ascertained when a user is up for getting adminship privileges or somesuch. 3) A user can and should be allowed to contribute without the requirement to jump through several hurdles and having to learn policies before the first upload. We are a community, but sometimes I just want to upload something without having to read guidelines and notices about what I am suppose to say while simply trying my best to help out the project. ℺ Gone Postal ( ) 20:07, 1 November 2018 (UTC)
I agree fully. The proposal is meant to deal with the purposeful visible violation of image integrity as related to the often unique source. Jürgen Eissink (talk) 20:28, 1 November 2018 (UTC).
Symbol support vote.svg Support per what I wrote earlier: Commons:Village pump/Archive/2018/10#Retouched files. Also agree with Gone Postal: this proposal should not be used to bully new users, only those who know full well what they are doing. - Alexis Jazz ping plz 20:48, 1 November 2018 (UTC)
It shouln't bully any user. Ymnes (talk) 20:53, 1 November 2018 (UTC)
That's a matter of choice of words. The user who triggered this proposal will probably consider this bullying. Just like Sol-lol will consider it bullying whenever we delete their copyvios and many other users think we are bullying them when we delete their fair use material. Considering we probably won't ban anyone over this, the user who triggered this may well end up collecting dozens if not hundreds of warnings. We can only hope that at some point this will annoy him enough to change his behavior. - Alexis Jazz ping plz 21:21, 1 November 2018 (UTC)
One or two warnings, otherwise a block sanction. We have to think about the relation with institutions that are more or less suppliers: it's one thing to rip an image, it's quite a different thing to rape a picture and pretend it's a source original. In my view we have a moral obligation to protect the source in this respect. Jürgen Eissink (talk) 21:31, 1 November 2018 (UTC).
As I have stated above, I strongly oppose any sort of blocking for this reason. Just because something annoys you does not mean that the fault lies completely with another person. We already have a huge problems with admins using 'warning' language as if that's a normal conversation only to then coward away saying "it was only a warning", we should not make a problem worse! ℺ Gone Postal ( ) 21:56, 1 November 2018 (UTC)
I must have misunderstood, I thought you meant no banning for forgetting something, and no harsh treatment of new users. My proposal concerns repeated behaviour on a larger scale, and not because it annoys me, but because I think it is wrong to mess with sourced material without mentioning. A warning can only be a warning if consequences may follow. Jürgen Eissink (talk) 22:08, 1 November 2018 (UTC).
Just imagine you find a devaluated, or at least revaluated, picture attributed to your institution, an institution that has a good name for it's conscientious representation of art: how would you feel, and how would you think about Wikimedia Commons? And only because some user refuses to add a template, which would not make the adjustments any different, but would at least justify the claims made. Jürgen Eissink (talk) 22:26, 1 November 2018 (UTC).
Trying to understand just what this means: if we have a low-res JPEG version of a PD photo, and someone goes to a third-party site and obtains a high-res TIFF, converts that to a better JPEG, uploads that, and overwrites the low-res JPEG, are we saying that if they don't make it absolutely clear that they did exactly that then they would be considered in violation? - Jmabel ! talk 22:59, 1 November 2018 (UTC)
Thanks for asking. I see that my proposal, which by the way does not contain a final draft for a policy change, is not as clear as I hoped it would be. The proposal should apply only to the recolouring of pictures of works of art and other, comparable intentional manipulations to such degree that the picture is undeniably estranged from it's source, without mentioning so. I don't consider format convertions manipulations as such. (I added an example.) Jürgen Eissink (talk) 23:20, 1 November 2018 (UTC).
Examples by exaggeration are this and this – on each the left to be seen as the source original and the right as the manipulated upload to Commons, while maintaining that the source given has anything to do with or should even be responsible for the uploaded piece. The example given above to me is of the same nature. Jürgen Eissink (talk) 00:10, 2 November 2018 (UTC).
Would «"trivial removal of watermarks over white background" or "adjusting contrast in black&white cartoons" before uploading» be explicitly allowed then? Anyway, I'm with Gone Postal: One or two warnings, otherwise a block sanction seems a bit ...harsh. Strakhov (talk) 00:25, 2 November 2018 (UTC)
Removal of watermarks and contrast adjusting to me or by all means improvements, and therefore off course allowed, if it doesn't alter the meaning of the represented image. I can't see how a warning can be given if there would be no possible consequences – what's the point of rules if they are not maintained? Jürgen Eissink (talk) 00:47, 2 November 2018 (UTC).
To be extra clear: if you make a picture of a work of art, you can adjust and manipulate that picture however you like, without mentioning that your picture was manipulated: it's your picture. But if you adjust a picture of an artwork that somebody else took, you should be very carefull with manipulations. The given example is an indication of what, according to me, should definitely not be allowed without clearly stating the manipulation on the file page. you cannot just pretend the source to be responsible for a heavily changed upload. Jürgen Eissink (talk) 00:57, 2 November 2018 (UTC).
Symbol support vote.svg Support; if anyone uploads a derivative of a third-party work—especially wherever irreversible operations are applied—then they must obviously declare that the uploaded file is derived from certain source, and isn’t identical to that source. Incnis Mrsi (talk) 17:00, 2 November 2018 (UTC)
  • Pictogram voting comment.svg Comment This seems, currently, to be an over-engineered solution to fix a well discussed problem with one user: Jan Arkesteijn. Have a look at AN/U archives and feel free to open up another topic on this user to get him blocked. IMO Jan Arkesteijn has long passed the point of community patience with him overwriting files with altered files, and yes, modifying professionally made archive images without declaring so. If you can convince me that this is a widespread problem from other users, then it is worth discussion. But this is a simple matter of dishonesty, and we don't really need policy to declare that dishonesty is wrong and you could be blocked for it. -- Colin (talk) 12:02, 4 November 2018 (UTC)
    • I completely disagree. At this moment the user is actually doing nothing wrong. Somebody may dislike what they are doing but that is a problem with their dislike. The appropriate solution is to try to find a common ground. Btw, I do hope that this individual was made aware of what is happening and this is not a witch hunt. I do now agree with the proposal, but I will oppose any sort of "action" taken against a contributor. ℺ Gone Postal ( ) 12:44, 4 November 2018 (UTC)
      • (after edit conflict)(Answer to Colin) In the earlier discussion in the Dutch De Kroeg many experienced (in time at least) users convinced me it's a shame but there is nothing we can do about it, and that's why I came up with this proposal. Policy could prevent any future cases as well, but my priority now is indeed stopping Arkesteijn, not for personal vendetta, but because I deeply think his actions are wrong. I am not familiar with AN/U and I don't know what you mean by it or where to look for such archive, nor how and where to start a topic on it – I would probably do such, if this policy proposal does not reach an accepted form, which to me still seems the best option: it would be a concrete realization of the demand for honest interaction with source material that is implicit in nearly all licenses summed up below. Jürgen Eissink (talk) 12:54, 4 November 2018 (UTC).
      • This isn't like/dislike. This user habitually uploads images and claims they are sourced from the given address, when in fact they are his own artistic modification of an original. Also engages in overwriting files leaving the source declaration untouched and now incorrect. His interpretation of "upload another version of this file" is "upload a different photo of this work of art". He's just out and out dishonest about sourcing, never mind the problem the above policy proposal seeks to change. He doesn't have any respect for the original archive or the need for an honest transfer here. I wouldn't have any problems if he uploaded a "... edited by Jan Arkesteijn.jpg" version but then that wouldn't be so simple to slip into n Wikipedia articles without anyone noticing. We should create policy to deal with wide problems, not one user. Honesty is a basic requirement for human interaction, I really don't see why we need a policy that says "you need to be honest when doing X". Put another way, is there any action in File space where one could be dishonest and that be acceptable?
Jürgen here is Commons:Administrators' noticeboard, there is a search box. I don't think the licence consideration below helps because nearly all these images are public domain. Even for CC works, the edit history is considered enough, as there is no requirement on any of us to leave an edit summary when editing. I know that that isn't best practice, but I don't think legal documents help. -- Colin (talk) 13:09, 4 November 2018 (UTC)
Now I get the impression that you don't understand the proposal, that precisely intends to stick the obligation to mention made alterations to PD imagery as well. It's a strange argument to say that you oppose the proposal because there are no requirements right now that equal those that the proposal seeks to implement. Jürgen Eissink (talk) 13:19, 4 November 2018 (UTC).
Jürgen, I only mentioned licences because you did. They are, IMO, beside the point. I haven't "opposed" the proposal, but I don't think it will gain sufficient community support unless you can demonstrate that it solves a wide problem with many users. Currently the only user this affects is heading towards an indef block. -- Colin (talk) 16:50, 4 November 2018 (UTC)
Addendum Based on past problematic cases, I suggest that special guidelines apply for professional photographs such as those from GLAM collections. In all cases the verifiably sourced original should be uploaded unchanged with their original EXIF data. Even in necessary cases where the image has to be cropped or rotated to be of realistic educational value, the original should be uploaded as the initial version so that even if the source goes offline, verification is easily done by any reader or reuser. In cases of digital repair, such as removing distracting noise or scratches from old photographs, the original should be kept as a separate file. Where this does not happen, other users should be supported/encouraged to revert, overwrite, or split file history, so that the verifiable original is always available. The one acceptable rationale to not do this is copyright, such as a modern photograph of a public domain painting where a complex frame is included, and must be cropped out to avoid the photograph having a valid independent claim of copyright. -- (talk) 10:22, 10 November 2018 (UTC)
That more or less equals the proposal I meant to make. The case COM:ANU#Jan Arkesteijn – started by Jeff G. and developed by many others, most notabily you – has however shown, I think, that Commons:Project scope (which to me seems sort of the constitution of Commons) as a policy is pretty well suited to tackle cases like that. Given the precedent (was it?), one should not in the future hesitate to use it as the official policy that it is. That said, it might be good to abstract from it a guideline for the special purpose, to make it more convenient to act quick. Jürgen Eissink (talk) 19:20, 10 November 2018 (UTC).
  • Symbol oppose vote.svg Oppose unless the scope of the proposal (colour paintings, black&white photos, black&white scans, tone, contrast, brightness, watermark removal, meaningless side-text removal after a crop, how and where changes should be noted...) and retroactivity (or the lack of it) are clearly determined. Strakhov (talk) 12:35, 6 November 2018 (UTC)
I often upload black and white scans of covers of old periodicals in the public domain (and a little watermark in a corner), and asides removing the watermark I sometimes change a bit the contrast and brightness. Uploading always the "original" scan with the watermark included and after that "the amateur modification" in a separate file when you have the source to check the "original image" I think it's some kind of "not-truth-paranoia". Strakhov (talk) 12:50, 6 November 2018 (UTC)
  • Strakhov, please see below under 'Change of proposal?' – the English guideline would, I think, take away your worries. Jürgen Eissink (talk) 12:55, 6 November 2018 (UTC).
Don't know. After all, all this is summarized in
In general avoid changing the colour of paintings! even if they are in the public domain! the painter would not approve that!
When it comes to images with CC BY or CC BY-SA licenses please do not forget to mention your changes! After all... it's required by license!
I could agree with that. And please remember: Commons is, in fact, an amateur repository. We are not the NASA, so I'd advise to chill out ...about a low-resolution face screenshooted from youtube being a bit more yellow. Strakhov (talk) 13:44, 6 November 2018 (UTC)
I am glad to find that your opinion on the dehumanizing edit tactics of Arkesteijn doesn't seem to be widely shared. Jürgen Eissink (talk) 13:51, 6 November 2018 (UTC).
Well I'm not glad seeing contributors repeatedly dehumanizing other contributors with harsh words such as "fake", "vandalism", "falsification" in these threads. I understand the issue with Jan (specially if they were told to not do that), but I would try to assume some good faith. Cheers. Strakhov (talk) 14:01, 6 November 2018 (UTC)
because you are apparently asumming Jan changed a bit the colour of this photo to discredit and dehumanize Ellie Lust (?)... I do not know, it's a longshot. Occam's Razor would tell me he just thought the image looked better that way. Strakhov (talk) 14:19, 6 November 2018 (UTC)
Changing the colour of the eyes, giving the skin a greyish teint as to appaer anemic... I assume you have not been able to appreciate different earlier discussions in Dutch, where Arkesteijn motivates his actions and point of view: he alteres images for "illustration purposes", to undo "probable aging and contamination of the varnish layer"; he finds "many images in raw form are unsuitable for publication" (mind you: we are speaking about faithfull reproductions of artworks by renowned institutes, that own the artworks, as published on their sites); his opinion is that if he is to be adressed about his editing, one should also be adressing "editorials of newspapers and magazines because they change images to make them suitable for publication" too; etc. etc. Assuming good faith is a point long passed, since Arkesteijn has been asked by a multitude of users to at least denote his uploads as retouched and to upload the original as well, which he just keeps refusing. Jürgen Eissink (talk) 14:57, 6 November 2018 (UTC).

I'm gonna tell you a tale.

  • 01:33 17 sep 2017 I uploaded this pic from here, Apparently I forgot to give the url (which I understand is not explicitly needed when the image is PD and data on original publication is added). I removed a bottom watermark stating "Biblioteca Nacional de España" (a mark in a faithfull reproduction left by a renowned scanning institution, too bad the scan provided by them was that shitty!). I did not include a {{retouched image}} tag because I thought it was a minor adjustement.
  • 18:54 15 sep 2018 I overwrote the scan after a year. The new one taken from Biblioteca Virtual de Prensa Histórica (BVPH). I removed a watermark from the Ministerio de Ciencia y Cultura and other one, older. I did link them and even respect their CC BY license (feel everyone free to remove that). Maybe I increased a bit the brightness/contrast.
  • 18:57 15 sep 2018 I cropped the image and removed part of the foonote «Notable periodista de ingenio chispeante» (linking the full file with {{extracted from}}) for "infobox use".

BTW file history shows clearly there is no such thing as a "true" [sic] version of that cover.

I sincerely ask you: Is this the work of a professional offender? A falsificator? Fraud? Was the professional digitalisation (and watermark) of BVPH dishonored? Are watermarks and scan brightness from a public domain B&W scan something to be honored? Should I have uploaded two times that scan? (never heard of that policy yet, but who knows) If I did, glad to know. One way to honor them would have been, of course, not mentioning them at all. I can only tell you I acted inspired by my best faith. What I expect others give to me, I try to give to other people. Strakhov (talk) 19:04, 6 November 2018 (UTC)

Please deal with your own conscience yourself. I think I've made it clear why I made this proposal. Jürgen Eissink (talk) 19:19, 6 November 2018 (UTC).
I've made it clear why I opposed your proposal too. Because it is vague as [...]. Strakhov (talk) 19:34, 6 November 2018 (UTC)

Copyright implications support this proposal[edit]

I finally understood exactly what Jürgen Eissink is trying to propose. I would like to add something to the proposal. Technically not following this proposal is a copyright violation of many free licences. Please note that most free licences are terminated if you violate one of their terms. So technically if you upload somebody else's modified work without stating it's modified, it is a {{copyvio}}. Below I list the licences that I use, feel free to list others, you think are of interest. ℺ Gone Postal ( ) 06:38, 2 November 2018 (UTC)

Thank you so much. It is indeed the friction between the unasked for implication of a source with a derivated work that is not mentioned as such that I tried to address. Jürgen Eissink (talk) 12:22, 2 November 2018 (UTC).

Free Art Licence 1.3[edit]

http://artlibre.org/

2.2 LA LIBERTÉ DE DIFFUSER (INTERPRÉTER, REPRÉSENTER, DISTRIBUER).
Vous pouvez diffuser librement les copies de ces œuvres, modifiées ou non, quel que soit le support, quel que soit le lieu, à titre onéreux ou gratuit,
si vous respectez toutes les conditions suivantes :

1) joindre aux copies cette licence à l’identique ou indiquer précisément où se trouve la licence ;
2) indiquer au destinataire le nom de chaque auteur des originaux, y compris le vôtre si vous avez modifié l’œuvre ;
3) indiquer au destinataire où il pourrait avoir accès aux originaux (initiaux et/ou conséquents).

Les auteurs des originaux pourront, s’ils le souhaitent, vous autoriser à diffuser l’original dans les mêmes conditions que les copies.

It is the 2) that interests us:

2) Indicate to the recipient the name of each author of the originals, including yours if you have modified the work;

GNU Free Document Licence 1.3[edit]

https://www.gnu.org/licenses/fdl.html

In 4. MODIFICATIONS

B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version,
together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they
release you from this requirement.

At first glance it may appear you can get away with not listing yourself, however:

E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

CC Share-Alike 1.0[edit]

https://creativecommons.org/licenses/sa/1.0/legalcode

This appears to be an exception. I cannot find anywhere in the licence a statement that you are required to state that the work is derivative.

There is:

If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any reference
to such Licensor or the Original Author, as requested.

but this requires the original individual requesting to be disassociated with the derivative work.

Right, CC without attribution. Completely forgot that used to exist. - Alexis Jazz ping plz 16:05, 2 November 2018 (UTC)

CC BY and BY-SA 2.0[edit]

https://creativecommons.org/licenses/by/2.0/legalcode

and in the case of a Derivative Work, a credit identifying the use of the Work in the Derivative Work (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). Such credit may be implemented in any reasonable manner; provided, however, that in the case of a Derivative Work or Collective Work, at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit.

CC BY and BY-SA 3.0[edit]

https://creativecommons.org/licenses/by/3.0/legalcode

to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";

CC BY and BY-SA 4.0[edit]

https://creativecommons.org/licenses/by/4.0/legalcode

You must: indicate if You modified the Licensed Material and retain an indication of any previous modifications;

GPL v2[edit]

https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt

You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

GPL v3[edit]

https://www.gnu.org/licenses/gpl.html

The work must carry prominent notices stating that you modified it, and giving a relevant date.

Change of proposal?[edit]

I'm uncertain as to what the above means for the proposal – could one of you elaborate, and maybe even state a proposal that can be voted over? Thanks in advance, Jürgen Eissink (talk) 16:47, 2 November 2018 (UTC).

  • Technically this means that if the file is reused under a free licence that requires you to notify of alterations and you failed to do so, then you are guilty of copyright infringement. However, under most free licences other people, who receive the work from the infringer are still ok. However, if it is Commons project that is not displaying the notice, then it is Commons that is infringing as well. … And I can continue with 'Howevers', however (no pun intended) if we introduce a message along the lines of «History of the work» rather than a single field date/author in the infobox, it will resolve all of the problems. ℺ Gone Postal ( ) 08:45, 3 November 2018 (UTC)
Barbie doll
person
You look a little bleak.
I see you're feeling better.
She's about to turn into the hulk.. or maybe jaundice
Female hulk averted.
Oh noes, another one!
another hulk attack averted
maybe everyone suffers from jaundice
maybe not
too bright
better
  • Overwriting is a different issue. That already is visible and more or less preserves the history (the bigger problem is when people rather than creating a derivative create a completely different work and overwrite with that). The problem here is when a person has create a derivative and then uploaded as if it were original. ℺ Gone Postal ( ) 06:58, 4 November 2018 (UTC)
  • @Gone Postal: Most of these are screenshots from YouTube videos that were altered without providing any indication of the fact they were made green. I've uploaded some proper images from the same source, largely redoing what this uploader did to provide this comparison. If only they could lay off the Photoshop, their contributions would be absolutely awesome. Sadly this uploader is convinced people must be made green and paintings must be blue, so sooner or later all the work they do has to be completely re-done.. what a waste. - Alexis Jazz ping plz 09:16, 4 November 2018 (UTC)
The question here could also be: why, for PD images, the need for a source if anyone can distort the source image without having to say so anyway? I think we must be better than that. Jürgen Eissink (talk) 11:54, 4 November 2018 (UTC).

Jan Arkesteijn's uploads are a problem. Making such severe, and sometimes destructive removal of detail from the originals and not saying so. Jürgen's concerns are valid here. Symbol support vote.svg Support mirroring English Wikipedia's guideline here Wikipedia:en:Wikipedia:Manual_of_Style/Images#Editing_images and adjusting for Commons' use.--BevinKacon (talk) 13:26, 4 November 2018 (UTC)

The English guideline is nearly exactly what I was looking for! Thank you. To avoid misunderstandings there could be added that the guideline applies (of course) also to PD images. How could anyone not agree with such guideline? It would make it possible to, in this case, address Jan Arkesteijn properly.
If there would be no objections to adding such a guideline, how to proceed from here? Jürgen Eissink (talk) 13:43, 4 November 2018 (UTC).
That user had warned several times, and already in an edit restriction. I don't know anyone else behaving similarly. If true, a general guidelines is good. Jee 14:10, 4 November 2018 (UTC)
@Jürgen Eissink: create a page here (like COM:Mention your changes or come up with a better title), ask us here to look at it and fix issues, start new proposal to make that page policy. - Alexis Jazz ping plz 14:58, 4 November 2018 (UTC)
I Symbol support vote.svg Support the creation of a page like Commons:Mention your changes and implementing such a guideline for users, we should be restricting problematic edits and not people, and this should also apply to these edits happening in the future by other users, honestly I thought that this discussion was mostly about the colourising of Nazi images (which I had no issue with as those images didn't overwrite the originals), but it's better to have derivatives uploaded as separate images and not used to overwrite the files, and unproductive changes to a(n existing) file simply for stylistic reasons (personal preferences) should always be discouraged. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:05, 10 November 2018 (UTC)
@Jürgen Eissink: you might be able to draw some inspiration from my essay COM:Colorization#A few things to consider. - Alexis Jazz ping plz 20:11, 10 November 2018 (UTC)
Wasn't this inspired the other way around by my conversations early september? Face-smile.svg. Jürgen Eissink (talk) 20:16, 10 November 2018 (UTC).

Updating Template:Dont remove warnings[edit]

This thread at ANU most recently highlighted the incongruity between this template and Commons:Talk page guidelines, where the template warns users to "not remove legitimate warnings from your talk page", while the guideline simply recognizes the practice as discouraged, while explicitly allowed.

This seems to be a perennial issue. The template's talk page has threads about this very issue going back as far as 2007, and the template has been nominated for deletion twice in 2009 and 2013, with many of the keep !votes themselves observing that the wording was problematic and should be updated to better reflect actual community standards, rather than trying to make policy by fiat via template.

So I'd suggest we update the wording of the template, given that with the checkered history, we can predict with relative certainty this problem is going to come up again if left unaddressed. I propose we update the wording to the following:

العربية | Català | Deutsch | English | Español | فارسی | Suomi | Français | עברית | Magyar | Italiano | 日本語 | Македонски | Nederlands | Polski | Português | Русский | Svenska | Українська | +/−


Dialog-warning.svg
Hello. This is a reminder that removing legitimate warnings and notices from your talk page without addressing the identified issues is discouraged according to our community guidelines. Removing messages does not remove them from the page's history, and doing so is often seen as rude or hostile by the community. You are encouraged instead to archive past discussions. You can have this done automatically for you - simply place {{subst:User:MiszaBot/usertalksetup}} at the top of your user talk page and old messages will be archived after 1 month (see User:MiszaBot/usertalksetup for more details).
If you have received warnings for copyright issues please familiarize yourself with our policy on licensing. You can also ask for help at the village pump or the help desk if you need assistance.
Detailed changes

العربية | Català | Deutsch | English | Español | فارسی | Suomi | Français | עברית | Magyar | Italiano | 日本語 | Македонски | Nederlands | Polski | Português | Русский | Svenska | Українська | +/−


Dialog-warning.svg
Hello. This is a reminder for you to not remove that removing legitimate warnings and notices from your talk page without addressing the issues you received these warnings for identified issues is discouraged according to our community guidelines. Note that removing warnings from your talk page will Removing messages does not remove them from the page's history, and doing so is often seen as rude or hostile by the community. You are welcome to archive your talk page. You are encouraged instead to archive past discussions. You can have this done automatically for you - simply place {{subst:User:MiszaBot/usertalksetup}} at the top of your user talk page and old messages will be archived after 1 month (see User:MiszaBot/usertalksetup for more details).
Please read Commons:Licensing if you have received these warnings for copyright issues.If you have received warnings for copyright issues, please familiarize yourself with our policy on licensing. You can also ask for help at the village pump or the help desk if you need assistance.

This more closely follows the wording in the guideline, and also includes links to VPC and HD for users who may have questions but need assistance. The rest is comparatively minor tweaks in wording, in addition to piping the wikilinks, mostly because, in my personal opinion, we should be doing that anyway when dealing with newer users. GMGtalk 13:48, 6 November 2018 (UTC)

@GreenMeansGo: Perhaps we could expand it a little by adding "and notices" to form "warnings and notices" in two places?   — Jeff G. please ping or talk to me 14:02, 6 November 2018 (UTC)
Why don't see split the difference in the interest of flow? Added "and notices" in the first instance, but then simply downgraded to the more generic "messages" in the second. GMGtalk 14:04, 6 November 2018 (UTC)
@GreenMeansGo: Thanks, that works.   — Jeff G. please ping or talk to me 14:26, 6 November 2018 (UTC)
  • Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 14:26, 6 November 2018 (UTC)
  • Symbol support vote.svg Support I would have said "identified issues is strongly discouraged" but let's not sweat the small stuff. This is certainly an improvement. -- Sixflashphoto (talk) 21:21, 6 November 2018 (UTC)
  • Symbol support vote.svg Support --Packa (talk) 21:34, 6 November 2018 (UTC)
  • Symbol delete vote.svg Delete I still see the wording of this template is not supported by any of our policies. Our "user talk page" policy is very brief. No wonder as people expect much freedom on handling it as it is not a serious business of others. The same in one of our sister project is more clear. "Although archiving is preferred, users may freely remove comments from their own talk pages. Users may also remove some content in archiving. The removal of a warning is taken as evidence that the warning has been read by the user." This is exactly the situation here too, and I see no reason to think other way. And if we read this which made some storm here too in the past, we can easily understand that a civilized community never wish to interact with a fellow using a Badge of shame. When we go through the history of this template, we can see several attempts to mark it as {{deprecated}}. When we go through the talk page, we can see that Lar (one who created this) had a strong feeling that it should be deleted. In the deletion request, Denniss stated that "this template is typically only used for copyvio uploaders resistant to talk page notices and is used as a higher level warning". But it is nowhere documented and we have examples that this template is recently used on the talk page of very legitimate uses which is the immediate reason of this discussion. In my opinion, we work in several Wikimedia projects simultaneously, and having entirely contradicting behavioral policies in different project are difficult to remember and deal with. For all these reasons stated above, I will not support the use of this template. Jee 03:33, 7 November 2018 (UTC)
  • Symbol support vote.svg Support, although I can't see that I often see this template being used. Often I see users who let a wall of warnings pile up, but honestly I think that there should be a special project to help educate users more on copyright rules and what applies to what (including geographically) and that these automated templates will probably get ignored because of their inpersonal nature, but I strongly encourage this form of archiving over the "archived into page history" "archiving". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:45, 7 November 2018 (UTC)
  • Pictogram voting comment.svg Comment I agree with "discouraged" but have reservations about using this template where it may cause escalation. I have seen users blocked for repeatedly blanking warning notices from their talk pages. As per the guidelines, this may be discouraged, but should not be taken as so hostile as to warrant administrator action. So long as a notice can be presumed as read, there is no need to hound a user who may in truth be annoyed or confused by very large angry sounding notices. If anyone doubts the notices are understood, they can discuss and if necessary take the discussion to a noticeboard. -- (talk) 12:13, 7 November 2018 (UTC)
  • Symbol delete vote.svg Delete per Jee. Agreeing to this wording is agreeing to it being used. Administrators are no different to other users except for some extra buttons, and any user may choose to edit their talk page, remove edits, refuse to engage with individuals as they see fit. I support a shift to the Wikipedia practice/viewpoint where removal of a notice or message is simply taken as acknowledgement that it has been read. If there are certain messages/templates that the community feels absolutely must be retained on talk pages (e.g. serious copyvio notices) then let's have a discussion about them. -- Colin (talk) 12:31, 7 November 2018 (UTC)
I'm fine having a discussion also about updating the guideline. In the meantime, this seems like a comparatively easy fix to at least bring the template and the existing guideline in line with one another. If some folks really are blocking users solely for removing talk page warnings (rather than for the reasons they're getting those warnings to begin with, like repeated copyvio), then I'd say they're out-of-bounds as far as existing policy goes.
Other than that, I'm not really sure I understand the relevance of Administrators are no different to other users. This is mostly to do with our copyvio and vandalism patrollers leaving a template that doesn't conform to existing guidelines. I'm not sure our administrators are really the ones doing most of the front-line patrolling in those areas. GMGtalk 13:37, 7 November 2018 (UTC)
GreenMeansGo, yes some admins have indeed blocked users simply for removing a talk page message (not even an official warning message). And community agreement on this template would be taken as de facto guideline that talk page messages must not be removed. While you may consider this template wrt copyvio/vandalism there are other admins who view anything they do and say as holy and requiring of obedient respect from the proles. -- Colin (talk) 11:53, 10 November 2018 (UTC)
@Colin: Such behavior is unprofessional.   — Jeff G. please ping or talk to me 11:57, 10 November 2018 (UTC)
Jeff G., who's behaviour? The admin or the user being blocked? -- Colin (talk) 12:02, 10 November 2018 (UTC)
@Colin: The admin, of course.   — Jeff G. please ping or talk to me 12:14, 10 November 2018 (UTC)
Well, I'd say that if we have admins and other experienced users who are misapplying current guidelines, that probably isn't helped by a template that itself misunderstands guidelines. Keeping in mind also that for many or even most users here, this isn't their home project. So it would maybe make even more sense to just take a template at its word, and assume that the community did its due diligence in making sure they two align.
But it's looking like the solution here is to 1) update the wording of the template, and then 2) immediately nominate it for deletion. If it survives deletion, then keep the updated wording, and if it don't then it don't. GMGtalk 12:22, 10 November 2018 (UTC)
  • Symbol support vote.svg Support. Whatever our policy is, this is de facto policy. It can't be enforced, but users can be informed about our customs. This template can help with that. - Alexis Jazz ping plz 13:03, 7 November 2018 (UTC)
  • Symbol delete vote.svg Delete the entire template. "The removal of a warning is taken as evidence that the warning has been read by the user". Users should be discouraged from watching other users' talk pages. This will decrease a lot of drama and tensions. 4nn1l2 (talk) 15:38, 7 November 2018 (UTC)
    Exactly! Jee 15:55, 7 November 2018 (UTC)
  • Symbol delete vote.svg Delete the template and add to our guideline something in the kind "Removing legitimate warnings and notices from your talk page without addressing the identified issues is discouraged. Removing messages does not remove them from the page's history, and doing so is often seen as rude or hostile by the community. You are encouraged instead to archive past discussions. The removal of a warning is taken as evidence that the warning has been read by you." Christian Ferrer (talk) 17:33, 7 November 2018 (UTC)
  • Symbol delete vote.svg Delete the template, per Colin and Jkadavoor. "The removal of a warning is taken as evidence that the warning has been read by the user". -- Begoon 12:23, 8 November 2018 (UTC)
  • Symbol support vote.svg Support Deleting it does not seems reasonable. --Steinsplitter (talk) 12:29, 8 November 2018 (UTC)
  • This is not a deletion discussion. To request it's deletion, please start a COM:DR discssion. Per policy it is not speedie-able, and the only other way to delete a page is after a deletion request discussion - something this venue is not. This dicussion is about chaning the wording of the template. --Jonatan Svensson Glad (talk) 13:32, 10 November 2018 (UTC)
As mentioned above, opining upon a wording change implies that using the template is ok, something which those in favour of deleting the template obviously do not believe. I see no problem with expressing that opinion here. Since no feasible changes to wording will fix the problem I cannot support or oppose them, as there is no wording I would support - the template should not be used. Supporting implies the template would then be ok, opposing implies there is other wording I might support - neither is true. Fiddling with the wording may actually encourage people to use this officiously offensive, bitey, big scary warning which is unsupported by policy, believing it to be "fixed" in some way, continuing to needlessly upset users and cause further issues such as those causing this discussion in the first place. I oppose that. I hope that's clearer. Face-smile.svg. -- Begoon 10:01, 11 November 2018 (UTC)
  • Symbol oppose vote.svg Oppose. I propose the following text: "Dear user, this is a reminder that you are in almost complete control over your user space. If anybody attempts to harass you for removing any templates or any other text from your user page, talk page, or their subpages, please report them to COM:ANU." ℺ Gone Postal ( ) 19:44, 10 November 2018 (UTC)
  • Symbol delete vote.svg Delete the template - Unblock requests aren't allowed to be deleted, Other than that you can add and remove anything else as you please. –Davey2010Talk 20:14, 10 November 2018 (UTC)
  • Symbol support vote.svg Support.Vulphere 05:03, 11 November 2018 (UTC)

PD Indonesia license tags renewal[edit]

Since 2014, Indonesia has changed It's copyright regulation from Law of the Republic of Indonesia No. 19, 2002, on Copyright to Law of the Republic of Indonesia No. 28, 2014, on Copyright. According to article number 124 of Law of the Republic of Indonesia No. 28 of September 16, 2002, on Copyright, At the time this Act comes into force, Act No. 19 of 2002 on Copyright (State Gazette of the Republic of Indonesia Year 2002 Number 85, Supplement to State Gazette of the Republic of Indonesia Number 4220) is revoked and declared invalid.

Here's the list of templates that are expired: Category: Expired PD Indonesia license tags

Here's the list of new templates and renewed templates:

  • Edit request:
    • If anyone could help me to grant me request or at least put the new edit text for this template, it would be very helpful.

When this finished, I hope we can use a bot to change earlier used template with the new ones we made.

Thank you.

--Hilmanasdf (talk) 17:57, 8 November 2018 (UTC)

Nice update, big thanks for your contributions.ReaperDawn 02:15, 9 November 2018 (UTC)
I'd like to complete the edit request concerning Template:PD-IDGov, but I am wondering if I may correct the English copyright law translation before introducing it to the template, as the translation contains a few grammatical errors. FYI, article 43 is the relevant one for PD-IDGov. --HyperGaruda (talk) 05:46, 9 November 2018 (UTC)
I found the official english version document from Directorate General of Republic of Indonesia Regulations website, which also make me want to revise the previous translation I quote from the previous source. I think you can also use it for the PD-IDGov revision. You can access it through this link. Thank you.
— Preceding unsigned comment added by Hilmanasdf (talk • contribs) 07:52, 9 November 2018 (UTC)
You can access the English translation here. ReaperDawn 08:44, 9 November 2018 (UTC)
Thanks, Reaper! But what I actually need is the access to translate the Template:PD-IDGov template, haha. --Hilmanasdf (talk) 07:57, 12 November 2018 (UTC)
Also, PD-IDGov doesn’t quite cover 43 e (portraits of officials and national heroes) since the law implies that it doesn’t have to be published by the government - though I guess it’s almost the same but still. Juxlos (talk) 12:46, 11 November 2018 (UTC)
Yup, I guess that's why we should update the template with at least things mentioned in section (1) article 43. Thanks. --Hilmanasdf (talk) 07:56, 12 November 2018 (UTC)