Commons:Village pump/Proposals/Archive/2021/08

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Change the cutoff date for files licensed GFDL-only

Proposal (GFDL cutoff date)

I suggest that we change the cutoff date for files licensed GFDL-only from 15 October 2018 to 1 August 2021.

Background (GFDL cutoff date)

Commons decided to ban (or restrict) files licensed GFDL-only with a few exceptions per 15 October 2018 after this accepted proposal to phase out GFDL for most media. The reason for the ban is that GFDL is not a good license and by banning files licensed GFDL-only users that would like to upload files to Commons is forced to choose a better license. I fully support the ban.

Some wikis banned GFDL-only too. For example Japanese Wikipedia, German Wikipedia, Russian Wikipedia and Wikivoyage. However, some wikis continued to allow upload of files licensed GFDL-only.

I have checked most wikis to see if MediaWiki:Licenses included GFDL-only and if it did I proposed that it was removed as an option. So far 38 wikis removed GFDL and 14 wikis have not removed it (yet). 4 of the 14 allow uploads by admins only. Removing GFDL from the list is not a guarantee someone will not add it manually so the best would be if all wikis decide to ban GFDL. But that will require a discussion on each wiki and I do not speak the language on most those wikis. I also propose a ban of GFDL-only at English Wikipedia together with User:Alexis Jazz and community decided the ban per 1 August 2021. I hope it will motivate more wikis to ban GFDL-only. User:Alexis Jazz noticed that English Wikipedia still had some pages and templates that suggested users to license their files GFDL. A few examples: en:Special:Diff/1025155168 and en:Special:Diff/1025615774. Knowing that I searched and found and fixed other pages and templates on English Wikipedia and other wikis that also suggested GFDL.

I hope and think that those changes will more or less eliminate uploads of GFDL-only to local wikis even if the wiki does not have a formal ban.

But since there was not a global ban of GFDL-only on 2018 there are now files on local wikis that can’t be moved to Commons. Not all Wikipedians understand that and since Commons is the central place to host files I think we should allow that wikis move files to Commons. If we change the date to 1 August 2021, it will not give users the option to license new files GFDL. It will allow us to centralize the files without increasing the number of GFDL-only files hosted on wiki projects.

I checked the 50 wikis with most files and the total number for those wikis is estimated to 2,900 new GFDL-only files. Many of those files have FOP issues and many are copyvios. I have asked some of the biggest uploaders for a relicense. If we do that for all wikis before files are transferred to Commons then it should be possible to reduce the number of files with GFDL-only. So a wild guess could be that it would be possible to move 2,000 extra GFDL-only files to Commons. I do not think that 2,000 GFDL-only files will be a problem for Commons but it could make it easier for especially smaller wikis that would like to move free files to Commons.

I have to use Google Translate (or English) on many wikis and that makes it hard for me to find all relevant pages and templates. It is also hard for me to explain why GFDL is a bad license. It would be a big help if users could help check wikis in languages they understand to see if anything should be fixed so we can stop new files from being uploaded as GFDL-only. Including a proposal of a formal ban if the wiki still allow GFDL.

Discussion and votes (GFDL cutoff date)

@Secretlondon: correct it is the date that it was licensed that is relevant here but in many cases the date of license and date of upload is the same. It is not many newly uploaded files that is GFDL but there are some. Sadly some templates and pages on the local wikis were not uploaded so if a user uploaded a file without a license they got a notice that the file did not have a license and the template suggested that they added {{GFDL-self}}. So of course some users did as suggested and added GFDL. That is what I have been trying to stop for months and I hope I have found most of those bad templates/pages. Also some users preferred GFDL so they uploaded files but English Wikipedi stopped that so it is no longer possible. --MGA73 (talk) 19:16, 6 August 2021 (UTC)
  •  Comment Can't we just extend this date for the files imported from sister projects, rather than being directly uploaded to Commons?
    Do we find and delete GFDL-licensed files directly uploaded to Commons now? I have not seen any myself, but theoretically there may be files licensed under GFDL uploaded after the current cut-off date. For example see this deleted file[1] which was deleted for another reason. If we change the cutoff date for all projects (including Commons), we should have accepted File:Persian alphabet presentation blue.webm.
    Are we going to revisit this cutoff date every time a big project bans GFDL? Today because of the English Wikipedia, and maybe tomorrow because of the French Wikipedia... It's hard to make coordination on medium-sized or small projects. For example, I tried to explain the issue at fawiki, but few users care or understand the issue. Most users just want to use the file on a Wikipedia article, and they don't care if its licensed under GFDL, CC, or even a copyvio. 4nn1l2 (talk) 04:34, 7 August 2021 (UTC)
    @4nn1l2: Lawful users on fawiki should care about and police the copyvios.   — Jeff G. ツ please ping or talk to me 12:12, 7 August 2021 (UTC)
    @4nn1l2: You are right that files could be uploaded to Commons and then deleted. I have not included those in my estimate of files. As far as I know there is no easy way to find any files uploaded to Commons and then deleted. But I think that if we allow files being imported from sister projects then it would be hard to explain why we would not accept if any files were undeleted at Commons. My plan was that this is a one time extention. If we extend every time a wiki ban GFDL then users could use that as a backdoor to upload GFDL. --MGA73 (talk) 16:03, 7 August 2021 (UTC)
  •  Oppose for now, since there's no evidence that the other wikis will stop allowing GFDL-only files, so this could end up being repeated in the future to extend the date further. Sort out the other wikis first, then ask for a one-time extension. Thanks. Mike Peel (talk) 07:52, 7 August 2021 (UTC)
    @Mike Peel: nooooo don't say that. I tried so hard to get sister projects to drop GFDL :-( But sadly yes you are right that there is no guarantee. A few wikis refused to remove GFDL. But we can't force them to ban GFDL. Would it be possible to make a proposal at meta and try to make a global ban? My suggestion IS thought as a one-time extension. Lets say we drop this proposal and agree to do an extention later then what will happen? Then users that do not like cc-licenses could upload all their files to a random wiki as GFDL and then wait for the new proposal. That is why I picked August 1 because we have passed that date so users can't use the extention to license new files as GFDL. --MGA73 (talk) 16:03, 7 August 2021 (UTC)
    @MGA73: I'm really sympathetic to this cause - GFDL really isn't a suitable license for images. Is there a summary somewhere of which sites still allow it? A proposal of a global ban on meta sounds like a good way to proceed. Get that passed, and I'd whole-heartedly support a proposal like this here once we know that there wouldn't be a back door still. Thanks. Mike Peel (talk) 17:18, 7 August 2021 (UTC)
    @Mike Peel: thanks. I just did not think that it was possible. Usually each wiki decide what to do. It would be much easier if each wiki did not have own policy. --MGA73 (talk) 19:05, 7 August 2021 (UTC)
    @Mike Peel: I forgot to answer your first question. The short answer is no. I have a list on m:User:MGA73/Media per wiki where I have made notes about GFDL. But it only include Wikipedias and not other sisterprojects. I focused on if the wiki have GFDL on MetaWiki:Licenses or not so my notes only tell if a wiki have it on the list or not. It is possible for users to add the license manually and unless the wiki have a formal ban (and enforce that) then GFDL can still be uploaded. Cs.wiki have it on the list and it seems they do not want to remove it. But they only have 1 file and that is the wiki-logo and only admins can upload files. Pt.wiki also have it on the list and the total number of files is 57,500 but they send free files to Commons so they have very few files licensed GFDL. That is the smallest and the biggest wiki with GFDL on the list. The other wikis are hsb, pl, tg, bar, sw, tt, ta, af, kk, ur, ko and ro. It seems that neither of the wikis have many recent uploads of GFDL-only. --MGA73 (talk) 10:11, 8 August 2021 (UTC)
  • I honestly disagree with Alexis Jazz' original proposal while I do think that it was well articulated and that his arguments were all good, the scope of Wikimedia Commons is hosting free educational files and the GFDL license is both free and unfree at the same time, I would support anything that extends the GFDL acceptance date, but as long as some other Wikimedia websites use it I would almost argue for just supporting it as long as it's acceptable. The "problem" is that it's a free license that requires you to print out a small book to use, that is unreasonably free but still free. So I  Support extending the date and undeleting any files deleted before that date based on the old date, but as long as other Wikimedia websites support it such proposals will return. The only actual solution here is for Alexis Jazz to go to the Meta-Wiki and request a global ban for the GFDL license and knowing his willpower he might actually be able to pull it off. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:17, 8 August 2021 (UTC)
    @Donald Trung: I have tried to reduce the problem with new GFDL-only files as mentioned above. But I know it is not a guarantee. About the global ban I asked on meta. Still no reply. --MGA73 (talk) 15:29, 9 August 2021 (UTC)

Move large DRs to /archive subpage

Proposal

When the DR page is too big (see Commons:Deletion requests/Files in Category:Burj Khalifa for an example), the delete/administrative buttons don't appear and makes it difficult to perform actions on the file. I suggest moving large DRs, such as >5 sections, to an /archive subpage. If the community thinks that this proposal is feasible, I suggest having a bot to do it. --Minoraxtalk 07:55, 8 August 2021 (UTC)

Votes (archiving closed large DR sections)

  1.  Support As proposer. --Minoraxtalk 08:46, 8 August 2021 (UTC)
  2.  Support/ Comment In my opinion if someone think a DR is too big then just move it to archive and problem is solved :-) I do not think we should archive all DR's so it should only be if the size break something. --MGA73 (talk) 11:59, 15 August 2021 (UTC)
  3.  Weak support, though I desire for long-term suggestions such as a suggestion by me below (part of my reply to Jeff G.) and/or having FOP introduced in a particular country (but as they say, "it is easier for a camel to pass through the head of the pin" than to promote FOP worldwide as part of the Wikimedia movement). JWilz12345 (Talk|Contrib's.) 11:12, 18 August 2021 (UTC)
  4.  Support.--Vulp❯❯❯here! 03:22, 19 August 2021 (UTC)

Discussion (archiving closed large DR sections)

@Minorax: Have you determined whether or not having such an archive transcluded allows the buttons to appear? It may be that the architect of the script which provides those buttons can easily compensate for the current use case.   — Jeff G. ツ please ping or talk to me 14:14, 8 August 2021 (UTC)

@Jeff G.: Didn't manage to try it yet, but even if the script can be compensated to fix this, another issue would be that page would be quite big and someone has to manually collapse the whole chunk of closed DR. Perhaps Steinsplitter can give their 2 cents on this. --Minoraxtalk 14:41, 8 August 2021 (UTC)
@Minorax: Another part of the solution in this case could be a stronger / sterner / more high visibility warning on Category:Burj Khalifa about violating COM:FOP UAE and the copyright of architect Adrian Smith.   — Jeff G. ツ please ping or talk to me 15:01, 8 August 2021 (UTC)
@Jeff G.: I doubt that is effective. In my observations the boilerplate warning notices tend to be ignored by uploaders. I also suspect some new uploaders are trying to test if the warnings are true (and they would only realize that it is true once their files got nominated for deletions. I think a possible long-term solution is by creating a list of prohibited elements/components for file names, like "Burj Khalifa", "Burj Dubai", "Burj Al Arab", and "Burj Al-Arab". It is like a blacklist of words that are not permitted to be part/s or component/s of file names. The prohibited elements or components of file names will be exact to the words in that list, but in terms of cases (upper/lower case) it should not be case sensitive so that the list also prohibits "burj khalifa" etc.. Besides the list of names, there shall be reasons as to why those elements of file names are prohibited (e.g. "no FOP in UAE"). The uploaders will be warned that the files they are trying to upload to contain prohibited elements or components, and that a warning box that will appear will have a link to that list so that they can find out why that component of file name is not allowed. Though my suggestion may have disadvantage as well as users may want to upload infringing files under default file names (like IMG5789-041021) to intentionally intrude their no-FOP-violating files to Commons. JWilz12345 (Talk|Contrib's.) 11:07, 18 August 2021 (UTC)

Truth in file naming for symbols

Proposal

Approve the following as a part of the file naming/renaming guidelines, and broadly permit its use as a rationale for rename requests:

Logos, trademarks, flags, insignia, emblems, seals, coats of arms, and certain other symbols serve the purpose of distinctively representing entities, groups of people, and ideas. A file on Wikimedia Commons may only purport to be one of these symbols without qualification if:

  • Accuracy: The file accurately depicts the symbol;
  • Reality: The symbolized entity, idea, or group of people exists or has existed in the real world, within a reasonably well-known work of fiction, or within the scope of a Wikimedia project; and
  • Usage: The symbol has commonly or officially been used to represent the entity, idea, or group of people within the appropriate context.

If a file depicting a symbol fails on any of these three criteria, the top of its description page and the beginning of its name must contain a qualification clearly marking on what grounds it has failed. For example:

  • A logo is used by the TV show Black Mirror, but its representation on Commons incorrectly reflects certain parts of the graphic design. This file fails the accuracy criterion. An appropriate name is "Inaccurate Black Mirror logo".
  • A user creates a seal for the fictional Republic of Wikanistan and uploads it to Wikimedia Commons. This file fails the reality criterion. An appropriate name is "(Fictional) Flag of the Republic of Wikanistan".
  • The city of Provo, Utah, holds a flag design contest. Jane Doe designs a flag, submits it to the contest, and uploads it to Wikimedia Commons. It does not win. This file fails the usage criterion. An appropriate name is "Jane Doe's proposed flag of Provo, Utah".
  • A user uploads an alternative flag of the State of Deseret that was never in use. This file fails the usage criterion. An appropriate name is "Fictitious flag of the State of Deseret".
  • A user uploads a flag purported to represent Uzbek-Laotians. There are no sources, reliable or otherwise, that substantiate this usage, so the file fails the usage criterion. An appropriate name is "Proposed flag of Uzbek-Laotians".

The qualification does not have to take a standard form and may vary between files, even in similar situations. The specific circumstances of each case should be taken into consideration, and—as usual—the suggestion made by this guideline for certain files may be overridden if consensus finds a compelling reason to do so.

Explanation

There has been much ado about the use of fictional/fictitious/fantasy symbols on Commons recently; see Commons:Village pump/Archive/2021/07#Discussion of fictional flags and of deleting files in use and Commons:Administrators' noticeboard/Archive 85#Fictional flags - are they in scope?. This proposal seeks to remedy some (but certainly not all) of the issues with the misuse of such symbols.

This proposal should not be construed as implicitly allowing or disallowing such symbols on Commons; it is scope neutral. It should also not be seen as an alternative to Donald Trung's notification proposal above. While the two proposals are related, they don’t really get in each other’s way, so an entirely separate discussion is warranted.

The purpose of requiring the qualification be first in the file name is to make the potential issues with using such symbols unignorable. This requirement may be removed from the proposal if the discussion below is against it.

Polling (Truth in file naming for symbols)

 Support.   — Jeff G. ツ please ping or talk to me 14:25, 6 August 2021 (UTC)
  •  Support, this is more of problem for non-fiction works. Will reduce risk of accidental usage on other wikis.--BevinKacon (talk) 11:17, 7 August 2021 (UTC)
  •  Support - It's basic common sense - I've uploaded lookalike logos and "lookalike" is stated in the titles although bizarrely having looked at File:Dailymail logo lookalike.png the file is being used virtually everywhere .... but that's not my problem as I've stated "lookalike"..., If a logo is fake then it should be stated in some way, –Davey2010Talk 11:39, 7 August 2021 (UTC)
  •  Support, I actually proposed this during the original village pump discussion and Mysterymanblue called it a good idea then, I actually was planning on proposing this before thinking up the bot notification because of a number of faults with this, for one flags, coats of arms, and maps of fictional places that are exclusively fictional (like Mordor or 1984's Eastasia) probably shouldn't need this as it's "excessive". Furthermore, this year I managed to get a file undeleted uploaded by the Globally Locked Sockmaster Musée Annam undeleted by saying that I will rename it to "fake flag", later during my research I discovered that the flag was actually legitimate. The problem with this proposal is that in fighting misinformation we might spread more misinformation, but weighing these the benefits far outweigh the deficits and redirects should preferably be kept. This policy should be enforced like tagging a "disputed file" and all parties should use as much reliable sources as possible to construct their claims. This should essentially be the [CITATION NEEDED] for disputes and the "Fake news" tag for clear fantasies with educational value. Proposed flags should probably better be called "proposed" and not "fictitious". In a nutshell, this proposal just raises our standards for sourcing, which is a good thing (as I believe that we shouldn't have notability standards, but have reliability standards and point out false information rather than delete it). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:08, 8 August 2021 (UTC)
  •  Oppose - I think this would be substantially disruptive and lead to countless edit and move wars. Traditionally, Commons has not been an arbitor of "truth". Instead we are just a neutral file host, which is why we don't have tons of edit wars despite the added complication of being a multi-lingual and multi-cultural project. There are way too many hotly disputed grey areas around "truth" when it comes to things like flags, maps, and national and ethnic symbols, which are all really just shared fictions anyway. There's also the fact that some cultures have no official governments or nations and thus it is hard to prove their "truth", for example, Native American cultures or the Kurdish culture. In fact, we might inadvertently contribute to their erasure with such stringent demands for verification. At the very least, we would be exacerbating existing biases about how different groups are represented on the internet, as whoever has the most digitized sources to back up their claims (i.e. rich, Western cultures) will get to decide what "truth" is. If we are going to start arbitrating truth, we need to be a lot more thoughtful about how we are going to handle biases, disputes, and grey areas, as this is opening up a huge can of worms. Nosferattus (talk) 17:49, 8 August 2021 (UTC)
  •  Oppose I am with Nosferattus here. This kind of judgment is better left to the final user, and there are subjects where "truth" is very relative. E.g. in the field of heraldry, there is no one true depiction of a coat of arms. All that needs to be met is the so-called blazon, i.e. the heraldic description of the elements included in the coat of arms. The depiction, however, is then left to any artist and their fantasy. So if we introduce a truth check like proposed above, I can foresee countless bickerings and edit wars about how one heraldic element is not truly a lion but rather a leopard or something totally different, and some such. The same goes for common symbols like exit signs, hazard warnings, etc. I fear that we would then see a flood of DRs concerning the lengths, widths and colour hues of allegedly non-officially drawn symbols. This wouldn't be helpful at all and I don't think it is Common's task to take over the editor role for the media content of other Wikimedia projects. We do already have procedures to counter obvious fakes and out-of-scope content, so I don't see a need to enforce the rules for symbols. De728631 (talk) 18:25, 8 August 2021 (UTC)
  •  Oppose: this proposal puts far too much burden on filenames to provide qualifying details. Beside its likelihood of creating new battlefields, I can see it also leading to ever-lengthening names. Sourcing, purpose, relevance, accuracy, and so on are best communicated through descriptions and categorization. (I mostly avert my eyes from the Structured Data myself, but I suppose that too.) Filenames that are distinctly misleading, for example the Jane Doe above’s Official Flag of Provo, Utah, can already be changed under the existing criteria. I would be all in favour of expanding our suite of problem templates or of taking other measures to prominently highlight more specific issues with user-created, inaccurate, or biased content, but filenames are not an appropriate means to do so.—Odysseus1479 (talk) 20:01, 22 August 2021 (UTC)
  •  Oppose as against the spirit of COM:NPOV. The goal of Commons should not be to make a determination of fact. -- King of ♥ ♦ ♣ ♠ 20:10, 22 August 2021 (UTC)

Discussion (Truth in file naming for symbols)

I already left some reasons above, but to add an addendum, I believe that this will have a similar effect on Wikipedia's and will invite more conversation and sourcing here. The problem with fantasies is always bad and / or biased sourcing. Unfortunately, sometimes high quality sources may spread misinformation so discussions should take place over direct deletion. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:10, 8 August 2021 (UTC)

@Donald Trung: Thank you for bringing up this idea in early discussions over this issue. I agree with your comment above that the flags of some entirely fictional places do not require the qualification: that's why the proposal allows for symbols of entities that exist "within a reasonably well-known work of fiction" to satisfy the reality criterion. So, for example, an accurate depiction of the flag of Panem (used in the Hunger Games movie) would satisfy the accuracy criterion for correctly depicting the symbol, the reality criterion for being used in a reasonably well known work of fiction, and the usage criterion for having been "officially been used" to represent the fictional country in the appropriate context (works of fiction are authoritative on their own depicted symbols). This proposal would not require a qualification for such a flag, though clarification could always be provided if it would make the file better. Fan-made symbols from a fictional work would require a qualification because such symbols are generally not "officially or commonly" used, and symbols from essentially unknown sources (e.g. self-published stories by Wikimedia users) would also require a qualification.  Mysterymanblue  18:17, 8 August 2021 (UTC)

@Nosferattus: Hi, thanks for your concern above. The proposal tries to deal with the issue of some symbols not being officially recognized by expressly allowing commonly used symbols to pass the usage criterion. Do you have a specific file in mind that you think might be an issue?  Mysterymanblue  18:18, 8 August 2021 (UTC)

@Mysterymanblue: No I don't have a specific file in mind, but it's not hard to imagine such scenarios. Even in cases that should be relatively straightforward, it's often difficult to define what is "official" or "common". As one example, until 2019, the country of Belize had no standardized flag. Implementations varied widely and the most commonly seen version within Belize was ironically the one from Wikipedia. Thus Commons actually created the "truth" rather than reflecting it. And that was a situation that didn't involve any politics, nationalism, wars, disputed borders, governments in exile, ethnic cleansing, historical erasure, or genocide. I think we should leave such disputes to the Wikipedias rather than bringing them to Commons. That said, I would be much less opposed to a proposal that simply provided guidance for case-by-case discussions rather than implementing hard rules. Nosferattus (talk) 18:57, 8 August 2021 (UTC)
@Nosferattus: My main concern with forcing discussion in all cases is that most people would agree that most of these fictional symbols should have a warning on them, so forcing discussion in every single case would put needless strain on the community's limited resources. Would you be more likely to support a proposal that expressly stated that 1) renaming under the proposal should only be taken without discussion when the file obviously and uncontroversially fails at least one of the criteria, and 2) there may be cases where there are multiple accurate depictions of a symbol or multiple symbols used to represent an entity, idea, or group of people.  Mysterymanblue  19:52, 8 August 2021 (UTC)
@Mysterymanblue: The problem is, unlike for text, it is rather difficult for one person to tell what is actually a common version of a symbol, especially when you are dealing with unofficial, non-standardized symbols. Perhaps the burden of proof should be switched. How about something like: In cases where a logo, flag, insignia, emblem or other symbol representing an entity or group of people has an official status (for example, in law or as a trademark), depictions of that symbol must be accurate (per the laws or trademark), or else the file name and description page must include a disclaimer. That would solve the most obvious cases without creating a battleground for the fuzzier cases. Nosferattus (talk) 21:24, 8 August 2021 (UTC)

Link to COM:FT in Upload Wizard

I was about to upload a new file to Commons and noticed that the Upload Wizard's start page says nothing about file types. It would be quite useful to have a link to Commons:File types inserted at Template:Upload Help notice. —capmo (talk) 14:43, 20 August 2021 (UTC)

@capmo: That makes sense, but begs the question: what type of page is Commons:File types supposed to be? It does not claim to be policy, guideline, or essay.   — Jeff G. ツ please ping or talk to me 01:53, 23 August 2021 (UTC)
Commons has a lot of informational pages, like Commons:Copyright rules by territory and its subpages. They are simply meant to provide facts and don't really fall into the "community consensus" hierarchy. -- King of ♥ ♦ ♣ ♠ 01:57, 23 August 2021 (UTC)

Remove "In case this is not legally possible..." from {{PD-because}}

Proposal (PD-because rewording)

{{PD-because}} is a catchall template that is used for situations where another public domain tag cannot be found. Currently, the text of this template reads as follows:

This file is in the public domain, because <reason>

In case this is not legally possible:

The right to use this work is granted to anyone for any purpose, without any conditions, unless such conditions are required by law.

Please verify that the reason given above complies with Commons' licensing policy.

The proposal is to strike the words "In case this is not legally possible: The right to use this work is granted to anyone for any purpose, without any conditions, unless such conditions are required by law." from the template.

Reasoning (PD-because rewording)

The struck words only apply to cases where a work has entered the public domain due to a grant by the copyright holder and where that copyright holder has also granted "the right to use this work... for any purpose, without any conditions, unless such conditions are required by law." This is a very small subset of public domain works, most of which are in the public domain for other reasons (expiration, threshold of originality, other form of copyright abandonment, lack of fixation, out of subject matter, etc.). Removing the language will allow {{PD-because}} to be correct for all public domain works, even those which have entered the public domain for these other reasons. If people need to add the "In case this is not legally possible..." language to the tag, they may easily do so by appending that text to the end of their reasoning.

There may be concern about removing this text from file information pages where it was rightfully included. I respond to these concerns by pointing out that 1) this text has almost certainly been incorrectly included on more pages than it has been correctly included on, and 2) this text is not an integral part of the copyright status of a file, and I cannot image a situation where we would delete a public domain file because the copyright holder had not also provided a licensed fallback.

I am proposing this change here because 1989 declined my edit request on the template's talk page because there was no consensus for the change, presumably due to lack of discussion.  Mysterymanblue  23:30, 1 August 2021 (UTC)

Discussion (PD-because rewording)

  •  Support as nominator.  Mysterymanblue  23:30, 1 August 2021 (UTC)
  • The reason we have such a text is because in some countries it is not legally possible to declare files as PD. See text on {{PD-self}} as an example. We can perhaps find better wording but I think we need some text. But we should not use the license for new files? So perhaps we can depreciate it? --MGA73 (talk) 17:41, 2 August 2021 (UTC)
    • @MGA73: [Long digression] Actually, there is no country where it is legally meaningful to simply declare a work as public domain (or "release a work into the public domain" as many of our "PD-" templates state. The "public domain" is not a legal entity and is not defined in the copyright laws of any country (including the United States). Legal scholars, the Open Source Initiative, and the U.S. Copyright Office all agree on this. As of 1978, the only way to make a work freely reusable is for the copyright owner to license or waive their copyrights (and those of their heirs). This is why Creative Commons developed the CC-Zero license. The origin of the myth that you can simply declare a file as PD in the US, but not in Europe is that in Europe you cannot license or waive all of your rights in a work (specifically the moral rights). But there is no magical public domain declaration in the US or anywhere else. You still have to specifically license or waive your rights, regardless of the country. And even in the US, you can't effectively abdicate your copyright ownership; you can only transfer it to someone else until it expires. {{PD-self}} is about as legally useful as toilet paper. It is, however, practically useful as a notice that the copyright owner is unlikely to try to enforce their copyrights (although it gives no such assurances about their heirs). Personally, I think {{PD-self}} should be deprecated in favor of {{Cc-zero}}. Nosferattus (talk) 21:36, 2 August 2021 (UTC)
    • @MGA73: That's fine and all, but this is {{PD-because}}, not {{PD-self}}. The proposal only affects files that use {{PD-because}}, most of which are not self-published by the uploader, so the text is unhelpful in most cases.  Mysterymanblue  23:26, 2 August 2021 (UTC)
  • Support if we also explicitly deprecate the use of {{Pd-because}} for own works. Nosferattus (talk) 21:38, 2 August 2021 (UTC)
  • Probably, except for cases where the template has been added by the uploader, as own work; in that case the extra wording shouldn't be removed. I think it's generally used for files found on other sites, but it's probably also misused. On File:Oystercatcher pecking the water.jpg, for example, a site apparently made a file available for "for unlimited free use". I don't think that's a public domain dedication, and there's no indication that they agreed to the wording on the template. --ghouston (talk) 00:57, 3 August 2021 (UTC)
  • Isn't it extremely difficult in almost all countries to dedicate a work into the public domain? The public domain is a lot like darkness, we don't define "Darkness" as something that is, rather we view it as "an absence of light", likewise the public domain isn't something onto itself it is "an absence of copyright ©" and because of this most intellectual property laws only concern themselves with what is (copyrighted) than what isn't (copyrighted). I can kind of support this proposal with the interpretation that "the public domain" is waving all rights (which it is), but many jurisdictions make this extremely difficult which is why CC-0 was invented, because "© No rights reserved" often isn't recognised by many governments because at all times copyrights are assumed. The global copyright © system is broken and the template tries to accommodate that fact, hence the current wording. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:24, 4 August 2021 (UTC)
  •  Support This template isn't really meant for self-published works and in most cases for which it's used, the "In case this is not legally possible ..." wording is not fitting and confusing, as there isn't any granting of rights involved. I, therefore, also agree with explicitly deprecating it for self-published works, as we have {{PD-self}} for that where the provision is fitting. {{PD-because}} is probably needed so we don't have to create templates for every special case; there are reasons for works being in the public domain that can't be expressed with one of the standard templates, but this is not for releasing copyrighted material into the public domain. Gestumblindi (talk) 14:03, 5 August 2021 (UTC)
  •  Support. Gestumblindi's comment, immediately above ("...in most cases for which it's used, the 'In case this is not legally possible ...' wording is not fitting and is confusing, as there isn't any granting of rights involved") summarises the essential problem. One important use for this template is to declare that in a particular jurisdiction, copyright protection has expired. I use it frequently to specify the authority under Australian copyright law for expiry of copyright, such as here. For that purpose, in the absence of a specific template, it's perfect. The words are not only an irrelevant distraction; they also implicitly encourage misuse of the template (as discussed further above) by uploaders using it instead of an appropriate template. I therefore also support Nosferattus's suggestion that we should "explicitly deprecate the use of {{Pd-because}} for own works." How about: This template must not be used to authorise an uploader's own work. Cheers, Simon – SCHolar44 (talk) 01:58, 7 August 2021 (UTC)
Thank you for the suggestion, Ghouston. I will eventually use {{PD-Australia}}, but right now the template is very much out of date because Australian copyright law has changed since it was written; it's unnecessarily complex; and the source quoted was not issued by the Australian Government. Currently I have opened a discussion on {{PD-AustraliaGov}}, which has similar but fewer shortcomings. After that (and following any improvements that others may propose), I'll be starting a discussion on {{PD-Australia}}. SCHolar44 (talk) 11:14, 7 August 2021 (UTC)
I'd like to add a small PS: When the template is amended, the comma should be removed after "public domain" and the words that follow "because" should be disemboldened. -- SCHolar44 (talk) 11:14, 7 August 2021 (UTC)
And a further PS: I'm a visual person, so I made up a mock-up of what I thought the template might look like, especially after removing the comma after "because", and the emboldening. I also modified my tentative wording for implementing Nosferattus's suggestion and added it below the line:
This file is in the public domain because lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

This template must not be used in connection with an uploader's own work. Instead, the {{PD-self}} template, or another, should be used.

I'd like to suggest another "below the line" sentence. Since the template must not appear on its own unless the image originated in the U.S., I've drafted for everyone's consideration a further suggestion covering PD in the U.S., why it's important, and potential restriction in other jurisdictions:

Unless the jurisdiction in which this file enters the public domain is the United States of America, a statement must follow demonstrating why the file has entered the public domain in that country. This is a precondition for publication in Wikimedia Commons because Wikimedia's servers are located there. In other jurisdictions, re-use of this content may be restricted.

What do people think? -- SCHolar44 (talk) 09:40, 9 August 2021 (UTC)

The layout looks good; just I few things I think would improve this:
  • {{self|CC0}} should be used instead of {{PD-self}} so that people are encouraged to use the better public domain dedication.
  • Not sure why the phrasing "used in connection with" is used. Surely the word "for" is just as good and more concise, as in "This template must not be used for an uploader's own work."
  • A below the line statement about having a U.S. copyright tag is not necessary because the template is not specific to the U.S. For example, someone could write the following in for the reasoning: "70 years have elapsed since the author's death and the work is under the threshold of originality in the United States." That reasoning applies to both the country of origin and the United States. You can also have a situation where someone just explains why the work is out of copyright in the source country but not in the U.S.
  • That being said, we could still have a warning about including both reasonings in general. I would recommend wording more like "This file's page must explain why the work is in the public domain in the United States and the country of origin of the work if the work does not originate from the United States." I am neutral on the inclusion of such a warning.
 Mysterymanblue  17:20, 9 August 2021 (UTC)
@SCHolar44: Nice work, although I agree with Mysterymanblue that we should encourage use of {{self|CC0}} instead of, or in addition to, {{PD-self}}, since CC0 actually has some legal validity to it. Nosferattus (talk) 18:22, 9 August 2021 (UTC)
Great points, Mysterymanblue and Nosferattus -- thank you for advancing things further (and curbing my circumlocution, Mysterymanblue!). Here for consideration is a potential implementation:

This template must not be used for an uploader's own work. Instead, one of the alternatives in the {{PD-self}} template should be chosen, such as {{PD-self-CC0}} for a public domain dedication.
Amended, shorter wording of 2nd paragraph ↓
If this work did not originate in the United States, this statement must be accompanied by an explanation of why the work is in the public domain there. In other jurisdictions, copyright law may restrict re-use of this content.
Changes, including added link ↓
If this work did not originate in the United States, there must be an explanation of why the work is in the public domain both in the United States (because Wikimedia's servers are located there) and in the work's country of origin.this statement [[Commons:Licensing#Interaction of US and non-US copyright law|must be]] accompanied by an explanation of why the work is in the public domain in the United States there.

My thinking:
  • I'm keen to give as much guidance as practicable to newcomers, hence the "such as" hint towards {{self|CC0}}.
  • Similarly for linking to the Commons page that explains including the reason why US copyright is so important: in classes that I run in Australia, this requirement frequently produces grumbles about "US control of intellectual property". Then when I mention the servers, there's widespread slapping of foreheads with palms of hands. I bet these people aren't unique outside the US, and I think brief info like this would spread the word. Likewise the next sentence -- I think it's important to make it clear where we know the file is in the PD and it's caveat emptor anywhere else.
It's rather nuanced, so I'm sure a few more iterations will be for the best. -- SCHolar44 (talk) 01:33, 10 August 2021 (UTC)
In accord with the philosophy of continual improvement, I added some amended wording (above, under orange notes) to shorten and simplify.SCHolar44 (talk) 03:53, 11 August 2021 (UTC)

@Mysterymanblue, MGA73, Nosferattus, Ghouston, Gestumblindi, and Donald Trung: Mindful that as discussed earlier on the {{PD-because}} Talk page, we are trying to rectify an addition to this template that was made erroneously 9 years ago without any discussion or support, I'm keen to keep Mysterymanblue's proposal going. We have only three Supports so far. MGA73, Nosferattus, Ghouston and Donald Trung, given the discussion and modifications made, do you feel free to support now? This is where we are:

This file is in the public domain because lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

This template must not be used for an uploader's own work. Instead, one of the alternatives in the {{PD-self}} template should be chosen, such as {{PD-self-CC0}} for a public domain dedication.

If this work did not originate in the United States, this statement must be accompanied by an explanation of why the work is in the public domain in the U.S. In other jurisdictions, copyright law may restrict re-use of this content.

If we end up with seven "Supports", will that be enough? (I don't have experience with management of proposals). If not, should we be asking editors in related Talk page discussions to take a look?  — SCHolar44 (talk) 09:34, 22 August 2021 (UTC)

@SCHolar44: Are there any reasons to keep the template? I think the template is a bit like {{PD}}. If you pick 5 random files from Category:PD other reasons then we could try to see if we can't find a better template or if the file has to be deleted. If we can find a better template then we should perhaps do that. If not then changing the text could be okay. --MGA73 (talk) 10:16, 22 August 2021 (UTC)
@MGA73: Every household has a junk drawer (or something similar) where everything without a place goes. PD-because is our junk drawer. I agree that the junk drawer is not the best and that it should be cleaned out. But even if you take the time to organize everything in the junk drawer, you still need a junk drawer because new stuff is constantly coming into your house, and it often can't be put in its right place right away. If you get rid of the junk drawer, the junk will pile up all over the house, and that's not something anyone wants.  Mysterymanblue  17:16, 22 August 2021 (UTC)
@Mysterymanblue: Lol. Yeah we all have a junk drawer :-) But if we are organized we could say no to junk. If new files can't use an existing template then perhaps it is safer to delete it. Are there any other reasons for a file to be PD than 1) It is not eligible for copyright, 2) The author released the file to PD or 3) The copyright have expired? --MGA73 (talk) 18:57, 22 August 2021 (UTC)
@SCHolar44: Apologies for not getting back to you sooner—I have been a bit busy IRL. While I greatly appreciate the work you've done on the proposal, I still don't see a reason to include the phrase "If this work did not originate in the United States" as part of the disclaimer. Every work on Commons must provide an explanation for free use that is valid in the United States. The provision of such an explanation is not based on the work being or not being a U.S. work. So phrasing that part as an if-then statement does not make sense because it must be provided 100% of the time. I am also concerned that the phrase "In other jurisdictions, copyright law may restrict re-use of this content." may cause people to believe that they do not need to provide an explanation for why the work is in the public domain in the country of origin (since that could conceivably be part of "other jurisdictions"). Perhaps a better wording would be "Even if this work did not originate in the United States, this statement must be accompanied by an explanation of why the work is in the public domain in the U.S. and its country of origin. In other jurisdictions, copyright law may restrict re-use of this content." :Even still, I am weary to include such a statement on having a U.S. explanation because there are a few edge cases. What if the work is public domain in the country of origin but under a free license in the U.S.? What if they have a country of origin explanation in PD-because and explain via a separate license tag why the work is freely usable in the U.S.? The statement should either be very general to cover these cases or it should not be included at all, in accordance with most copyright templates that are not specific to any one country.
I also don't really understand why we need to keep the other PD-self templates around. You say you want to give guidance to newcomers, and that is admirable, but I don't see how giving them multiple option, some of them far worse than others, advances that goal. There are essentially no advantages to using anything other than CC0 because the alternatives are invariably more legally vague. Mentioning these other PD-self templates in the template both makes the template longer than it needs to be and suggests that we have equal preference toward these different styles of PD dedication (we don't.)  Mysterymanblue  17:01, 22 August 2021 (UTC)
@SCHolar44: I'm afraid I don't really understand the part that reads "Instead, one of the alternatives in the {{PD-self}} template should be chosen, such as {{PD-self-CC0}}" {{PD-self-CC0}} isn't a template, and I have no idea what "alternatives in the {{PD-self}} template" refers to. Why don't we just write: "Instead, use {{self|CC0}} or {{PD-self}}." That's much clearer. Nosferattus (talk) 17:11, 22 August 2021 (UTC)

@Mysterymanblue, MGA73, Nosferattus, Ghouston, Gestumblindi, and Donald Trung:
Dear colleagues,
Thank you for your feedback. Although I'm an experienced professional policy developer, my familiarity with the variety of copyright contexts you've mentioned is quite limited, so I very much appreciate learning about them.

Need for the template
MGA73, you commented, "If new files can't use an existing template then perhaps it is safer to delete it. Are there any other reasons for a file to be PD than 1) It is not eligible for copyright, 2) The author released the file to PD or 3) The copyright have expired?

– The problem is that there are not enough templates available to cover all PD possibilities in non-US jurisdictions. I have encountered solid resistance to developing additional ones or even updating outdated ones (PD-Australia, for example, is now factually incorrect; three templates, each dealing with specific policies, are an obvious solution but I don't believe it will come soon, if ever). Conclusion for the time being: until all situations are covered by a template, we need a catch-all.

"If this work did not originate in the United States"
Mysterymanblue, you commented, "I still don't see a reason to include [this] phrase as part of the disclaimer".

– I can see the weakness in the wording. Taking your point that every work on Commons must provide an explanation for free use that is valid in the United States and that wording needs to be very general to cover these cases, how about this, then? (it combines your better words with mention of why the US jurisdiction is important):
Since Wikimedia Commons servers are located in the United States, if this template involves a non-U.S. jurisdiction it must be accompanied by a justification for free use that is valid in the U.S.

Don't give them multiple options
I've implemented the comments of Mysterymanblue and Nosferattus: only CC0 is mentioned now. I've also deleted mention of other jurisdictions.

This file is in the public domain because lorem ipsum dolor sit amet, consectetaur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

This template must not be used to dedicate an uploader's own work to the public domain; CC0 should be used.

Since Wikimedia Commons servers are located in the United States, if this template involves a non-U.S. jurisdiction it must be accompanied by a justification for free use that is valid in the U.S.

I hope I've fully taken your comments on board. If not, I'm listening.  :-)  — SCHolar44 (talk) 06:53, 26 August 2021 (UTC)

I think this most recent proposal is perfectly fine, simple and clear; therefore, I  Support it. Gestumblindi (talk) 10:00, 26 August 2021 (UTC)
 Support SCHolar44's wording of 06:53, 26 August 2021 (UTC).   — Jeff G. ツ please ping or talk to me 11:49, 26 August 2021 (UTC)
 Support the latest wording. Nice work. Nosferattus (talk) 12:05, 26 August 2021 (UTC)

An edit rquest has now been made at Template talk:PD-because. SCHolar44 (talk) 08:15, 9 September 2021 (UTC)

Proposal to have a bot notify sister projects if a file is tagged as "inaccurate" on Wikimedia Commons

Recently there was a discussion about fantasy flags generated by users from the Commonswiki being used on other Wikimedia websites and the potential anti-educational effects that these fantasy flags could have on their readers. Meanwhile on Wikimedia Commons we have many tags like "{{Fact disputed}}", "{{Fictional flag}}", "{{Disputed coat of arms}}", "{{Fake sports logo}}", "{{Fictitious map}}", Etc. to convey the message that these files should not be used in a context that make them seem official, many such images still are used on a large number of Wikimedia websites that have reliability issues because nobody is ever notified of them.

Therefore I would like to propose a bot to operate globally and notify any Wikimedia website when a fact has been called into dispute like when an image gets nominated for deletion now or tagged as "Speedy", in order to prevent vandals from tagging all images with such tags the bot would have to wait 24 (twenty-four) hours or 48 (forty-eight) hours before notifying other communities. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:09, 4 August 2021 (UTC)

Votes (Proposal to have a bot notify sister projects if a file is tagged as "inaccurate" on Wikimedia Commons)

 Support.   — Jeff G. ツ please ping or talk to me 14:29, 6 August 2021 (UTC)
  • Weak oppose, while the underlying idea is good, there are too many grey areas and too much potential for such a system to be abused. People already misuse these templates for political and ideological disagreements, and I fear this would exacerbate that. Nosferattus (talk) 17:16, 8 August 2021 (UTC)
  •  Support can avoid any files that are possibly out of scope. --A1Cafel (talk) 10:00, 14 August 2021 (UTC)
  •  Support it is common for media to get used across projects, only for years later to be identified as inaccurate or fan-made.--BevinKacon (talk) 12:44, 14 August 2021 (UTC)
  •  Support - We already have a bot that adds file copyvio/DR notices to Wikipedia talkpages and that works fine so can't see why this can't too. Unfortunately it will be open to abuse and people will abuse it but at the end of the day unless anyone above has a better solution than I fully support this. –Davey2010Talk 22:18, 14 August 2021 (UTC)
    @Davey2010: This functionality is not in that bot's approved scope or programming.   — Jeff G. ツ please ping or talk to me 11:46, 15 August 2021 (UTC)
  • Apologies if this sounds arguementitive or rude certainly not my intention but I never said it was ?, I said we have a bot that does a similar sort of thing :), Thanks, –Davey2010Talk 12:14, 15 August 2021 (UTC)
    @Davey2010: No, you didn't, and I'm sorry if in replying to you I implied that you wrote that it was. But logically, a next step could be NRodriguez (WMF) or her team planning to modify Community Tech bot or creating another bot with similar code to do this, and I wanted to publicly make sure the community in general and each wiki community approved such before implementation.   — Jeff G. ツ please ping or talk to me 13:19, 15 August 2021 (UTC)
Hi Jeff, No worries, Happy editing my friend, Take care, –Davey2010Talk 14:22, 15 August 2021 (UTC)
  •  Support under the condition that every WMF projects decides if and how they want to be notified. We should not do this without the explicit consent of the respective projects. --AFBorchert (talk) 17:32, 23 September 2021 (UTC)
  •  Support No problem with notification. Of course, there could be abuse, but then any system can be abused. Perhaps he bot should only notify after a period of 72 hours, to allow people to challange the tag. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 06:02, 17 October 2021 (UTC)

Discussion (Proposal to have a bot notify sister projects if a file is tagged as "inaccurate" on Wikimedia Commons)

  •  Some clarification, my personal stance on fantasy bullshit is that they should be included in Wikimedia Commons as more often than not they do have an educational value as often they are based on common misconceptions, incomplete information, misinformation that might have been spread by credible sources like museums and universities (you would be surprised how much bullshit you can find in otherwise "academic" papers simply because the person in question used the wrong sources) and I believe that such things can be used to contrast real Vs. fake and just discuss the meta-history of a subject and its historiography. That aside bullshit becomes misinformation when it's presented as real information. We can have a projection of a pear-shaped earth or a velociraptor-shaped earth, but while an image of a velociraptor-shaped earth can illustrate the beliefs of the Dinosaur Earth Society the same image would be horrible misinformation on any serious article about the geography of the planet Earth.
As the hypothetical bot will most likely notify all talk pages indiscriminately about the tagging it is up to the editors of that particular Wikimedia wiki to decide to remove/replace it or keep it, an article about flag proposals can have images of flag proposals, an article about bullshit land claims can have fake maps, an article about fictional sports teams can have fictional sports logos, Etc. The bot clearly can't differentiate if an image is where it should be, however, it could notify users.
Personally I would have preferred the Community-Tech-Bot to do these notifications but as I am permanently banned from the Meta-Wiki and any time I try to appeal that ban a user that hates me denies the appeal and comments how I should have my talked page access revoked so "I won't waste their time anymore" I can't exactly propose anything at the global tech wishlist and unfortunately there isn't a localised Wikimedia Commons annual tech wishlist, though if it is possible I would like to petition Wikimedia Deutschland (WMDE) to get more involved here and create a "Commonswiki Tech Wishlist" where they would fulfill 5 (five) instead of 10 (ten) "community wishes", but I have no idea if it would be possible to convince Wikimedia Deutschland (WMDE) of doing something like that, so I hope that someone that operates a global bot can pick this request up if there is consensus for it.
Regarding potential vandalism, generally speaking files are patrolled and personally I am more inclined towards a 24 (twenty-four) hour window so other Wikimedia websites are more quickly notified about potential reliability issues, if someone raises an issue about fantasy maps being used at the Indonesian-language Wikipedia that map can still continue to be used at the Wolof-language Wikipedia because nobody is notified of its factual inaccuracies, this bot should solve this issue by not letting such discussions "stay in the talk pages of only one wiki".
A big issue this might create is hypercorrection where a user challenges a claim that later turns out to be correct and other Wikimedia websites will remove all references to that media file, but of course the best action to take here is provide reliable sources and restore it where the user can. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:09, 4 August 2021 (UTC)
  • I think we cannot order anybody to provide such a bot, and we cannot replace any (global or local) bot approval by this discussion. What will be the actual result if this proposal is accepted? --Krd 10:08, 4 August 2021 (UTC)
    I think voting on the principle is fine. As an example, if there was funding for a group-run bot based on consensus, I'd be happy to be paid a small honorarium to write the main code for it and others can operate it, i.e. a teeny fraction of the cost of getting WMF dev to do anything. It would be reasonable for sister projects to opt out of it, but we are only talking about leaving advisory notes on talk pages. BTW, the example of images up for deletion is a bad one, there is already a bot that does this for DRs on images in use in articles on some wikipedias. --Fæ (talk) 10:36, 4 August 2021 (UTC)
    @Krd: , you are right, we can't force anyone to do this, but it would show that there is at least some consensus for this, as "fake information" is rampant and quite recently there were Administrators' Noticeboard and Village Pump discussions about fantasy flags being used on Wikipedia's. We already have a bot for deletion notifications, so this is "the same in spirit". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:23, 4 August 2021 (UTC)
    I'm not opposed at all, I just think it's an unconventional approach. Wouldn't it be better to first find a bot operator who is willing to do it, and then just do it as a nobrainer, instead of making this formal proposal? I mean if there is nobody who does it, the whole story here appears quite pointless for me. Speaking as a bot operator, I would prefer to be asked over being requested to implement what is already decided. Also I think it's better to take into account the needs of the individual projects the bot shall run on, instead of making decisions here for all projects of their heads. Even if that's fair from our point of view, I'm quite sure communities will think different. But, that's just my 2¢, maybe I'm mistaken. --Krd 16:13, 4 August 2021 (UTC)
  • Deletions are flagged on the talk: page, because they're mostly of interest to article maintainers, who can be expected to know about talk: pages. But if the issue is accuracy, then that would presumably need to go on the main page, where all readers would be informed of it. That's a riskier slot, bearing in mind potential for misuse.
There's also the issue of "fictional" flags. Why are these "inaccurate"? If the flag is a fiction, then what's the reality and why don't we use that instead? We might use this for inaccurately-drawn flags (such as edit-warring over the proportions of a real flag), but if a flag is fictional then it either doesn't belong on a page describing reality, it does belong on a page describing that fiction, or it would belong on a page describing hypothetical flags, such as a British flag without a now-independent Scotland. None of which are "inaccuracies" deserving this sort of flagging. Andy Dingley (talk) 13:11, 4 August 2021 (UTC)
It is best to use talk pages because in general people don't want casual readers to see "editor" things. A fantasy flag that is correctly used as a fantasy for a fantastic location is fine, but there are examples where flags with disputed origins are attributed to historical entities. If an issue exists with the content of an article (and media files are article content) then it is up to the regulars to fix it, in some cases Wikimedia Commons "has decided for projects" by deleting files as "fake" that later turned out to be true. Having more eyes on an issue causes more experts to be able to correct any issues. The bot should only indicate that issues have been raised, not that the flag itself is fake, perhaps we can create specific templates for proposed flags that are not "fantasies". For example an alleged flag of a historical province of France that turns out to be a later invention is a "fantasy flag" but not a proposed flag. A specific template for "Proposed flag" should get rid of such things. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:42, 4 August 2021 (UTC)
  • @Fæ: , if you think that the proposal is too short I give you my written permission to adjust it however you see fit, as long as the basic premise (a bot notifying sister projects about reliability issues on Wikimedia Commons and a short window to fight vandalism here) remains the same. I deliberately kept it short because earlier this year I had a large batch of proposals that were ignored (had little engagement) because they were too long and spitting them had little engagement despite being things that are all already the standard on the English-language Wikipedia. So I kept this proposal short and to the point to avoid this with some notes below. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:31, 4 August 2021 (UTC)
  • I think this proposal would do quite a bit to stop image misuse, assuming that Wikipedias would implement its suggestions. I have gone and removed images of fictitious flags from several Wikipedias where they were used erroneously (all in cases where people assumed an entity that didn't have a flag had a flag). I dislike doing this in general because it sometimes looks like I am vandalizing the page because I am unable to provide a cogent explanation in the source language. I hope implementing this proposal would empower these Wikis to seek out and snuff out disinformation on their own terms. Another way to reduce file misuse would be to require fictitious flag file pages to clearly and unambiguously identify themselves as fictitious in their titles, possibly as the first word. This would hopefully prevent people from missing the file page disclaimer by making it an integral part of how the file is used.  Mysterymanblue  15:42, 4 August 2021 (UTC)
I like this non-technical solution. If this proposal could be read as a policy to force the first word in a filename to be on an agreed list of red-flag words like Fictitious, Propaganda or Misleading, this might be enough to get Wikipedias to pay more attention. --Fæ (talk) 15:59, 4 August 2021 (UTC)
  • What about instead of automating the notifications of the wikis, the bot instead lists all globally used files that have those templates in a subpage? The notification (or correction if necessary and possible) will have to be done manually by a human instead. I'm not really a fan of automating the notifications to each wiki since I feel it could lead to misunderstandings. I think the notifications should be done by a volunteer familiar with the wiki involved. pandakekok9 12:10, 14 August 2021 (UTC)
    @Pandakekok9: Where would that subpage be? What would it be named? What would be on it? Who would pay attention to it?   — Jeff G. ツ please ping or talk to me 16:29, 14 August 2021 (UTC)

Maps

A map, in particular, being "disputed" does not mean it is wrong. For example, consider Israel/Palestine. Is all of Jerusalem part of Israel? Is the Golan Heights? Is it OK to show where the 1967 border was on a present-day map? Is it OK to color the West Bank and Gaza two different colors? Is it OK to refer to "the West Bank" (vs. "Judea and Samaria")? etc., and that is not even taking into account some more extreme views on either side. Any map of the area will be disputed by someone, but that does not mean it is wrong, just that any given Wikipedia ought to be clear whose view of the matter it represents.

Similarly for political maps of a dozen other places in the world, not to mention almost any map about linguistic distribution. - Jmabel ! talk 23:02, 4 August 2021 (UTC)

Indeed.
But using any of these maps, an editor should be aware of its controversial nature and carefully choose among the available versions, or abstain from using one if none was appropriate. I don't think a comment on the talk page is overkill. In many cases, the editors were already aware of the controversy, but a bot notifying that the map has been marked as disputed is no worse than an IP editor popping up arguing that all the area should be shown as integral parts of India/Israel/Ukraine/whatever, and we do handle that just fine on the Wikipedias. Just make the note clear, and avoid spamming the talk pages.
–LPfi (talk) 09:38, 7 August 2021 (UTC)
We could easily create a warning template called "{{Disputed map}}" (apparently already exists) and / or a more general "{{Politically sensitive}}" explaining about why the file can be perceived as "offensive" or "partisan" as the Wikimedia Commons doesn't have a NPOV. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:17, 4 September 2021 (UTC)
I suppose the point was to have a bot notify file reusers (by an article talk page message), when such a template is added to the file talk page over here or the file is added to a page. –LPfi (talk) 16:26, 23 September 2021 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2021/08&oldid=607711919"