Commons:Village pump/Proposals

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

Shortcuts: 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; the latest archive is Commons:Village pump/Proposals/Archive/2024/03.

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?

 

Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days.

Disabling talk pages of deletion requests[edit]

While there now exists Template:Editnotices/Group/Commons talk:Deletion requests that notifies users to make comments on the deletion request pages themselves, it is evidently ignored, as seen in 54conphotos' comments on the talk page of Commons:Deletion requests/File:KORWARM2.jpg (which I transferred to the main page and in Amustard's comment on a Turkmen deletion request which I subsequently transferred to the mainspace. As it is very evident that the edit notice is being ignored, I am proposing that the "Talk" namespace be disabled in all pages with prefix "Commons:Deletion requests/". This should be a permanent solution to the incidents that should have been better avoided. For existing talk pages of deletion requests with comments, the comments (including mine if ever I had responded to uploaders in the talk page namespaces) should be transferred to the deletion requests mainspaces, with consideration to the dates of the comments or inputs. JWilz12345 (Talk|Contrib's.) 09:10, 26 November 2023 (UTC)[reply]

 Support At least, the use of DR talk pages should restricted to power users (admins, license reviewers?). Yann (talk) 09:37, 26 November 2023 (UTC)[reply]
@Yann that may be OK. Restricted to admins and license reviewers. Or the talk pages are still existing visually but those who don't have user rights, even autopatrolled ones, will be barred from editing talk pages and be presented with a boilerplate notice that they don't have the right to edit talk pages and should instead comment on the main discussion page, with a link to the DR itself in the notice (do not expect several new users to comprehend what they are reading in the notices). JWilz12345 (Talk|Contrib's.) 10:09, 26 November 2023 (UTC)[reply]
 Support --Krd 11:23, 26 November 2023 (UTC)[reply]
 Support Christian Ferrer (talk) 11:56, 26 November 2023 (UTC)[reply]
Thank you for pointing out this Template:Editnotices/Group/Commons talk:Deletion requests location in Wikimedia. This was not ignored as you said in your comment, it simply was no where to be found at the time I commented. It's a shame it's too late to place a comment there as I would have done so. Even your notes to me are very confusing as the names of Comments pages do not match up so I can find them as are all the previous notes received by others. Being new to this platform, I have found it very confusing to find things that are suggested when seeing comments by others.
Hopefully I will have the hours to research and better understanding of the workings of Wikimedia Commons in the future. Thanks again! 54conphotos (talk) 13:32, 26 November 2023 (UTC)[reply]
 Support or, if it's easier, systematically turn them into redirects to the relevant project page. - Jmabel ! talk 21:56, 26 November 2023 (UTC)[reply]
 Support --Adamant1 (talk) 00:35, 27 November 2023 (UTC)[reply]
 Support. Some good ideas above from Yann and Jmabel. We could also explore autotranscluding them to the bottoms of the DR subpages themselves.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 00:49, 27 November 2023 (UTC)[reply]
and restricting to admin and LRs per Hide on Rosé below.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:12, 30 March 2024 (UTC)[reply]
 Support. Yes, good idea, esp. with Jmabel’s and Yann’s additions. -- Tuválkin ✉ ✇ 11:34, 27 November 2023 (UTC)[reply]
 Support to restrict it to anyone with autopatrol, I think these users are knowledgeable enough to know that the talk page isn't to discuss the deletion. We must create an informal and easy-to-understand AF notice though. -- CptViraj (talk) 12:19, 9 December 2023 (UTC)[reply]
Another one, this misplaced comment by ApexDynamo, which I have transferred to the main nomination pages. CptViraj, I don't think even autopatrolled users are still knowledgeable enough to know that talk pages are not proper forums to comment. Example: misplaced comments by Exec8 (which I also transferred soon after initiating this proposal). I suggest the use of those talk pages must be restricted to admins/sysops and license reviewers. JWilz12345 (Talk|Contrib's.) 09:38, 14 December 2023 (UTC)[reply]
Still, rare cases for autopatrollers. IMHO we shouldn't unnecessarily take away the power completely, the problem is mainly caused by newbies/non-regulars. -- CptViraj (talk) 18:13, 23 December 2023 (UTC)[reply]
 Support I have never used a talk page of a DR nor have I seen one being used. The DRs are usually also frequented by very few editors and the comments can easily be distinguished from one another.Paradise Chronicle (talk) 22:13, 30 December 2023 (UTC)[reply]
One more problematic use, by @Balachon77: (see this). JWilz12345 (Talk|Contrib's.) 01:00, 8 January 2024 (UTC)[reply]
Another problematic use, by SiCebuTransmissionCorrecter (talk · contribs) – Commons talk:Deletion requests/File:Line construction of Hermosa-San Jose Transmission Line. The line constructs above Hermosa-Duhat-Balintawak transmission line.png. JWilz12345 (Talk|Contrib's.) 00:10, 9 January 2024 (UTC)[reply]
no no no no no no! SiCebuTransmissionCorrecter (talk) 01:12, 10 January 2024 (UTC)[reply]
Commons_talk:Deletion_requests/File:Afrikan_och_Afrikanska_x_Ingel_Fallstedt.jpg ? DS (talk) 14:50, 22 January 2024 (UTC)[reply]
@DragonflySixtyseven the discussion should have been made at COM:VPC or at concerned admin's talk page. Ping @Holly Cheng and De728631: for attention. JWilz12345 (Talk|Contrib's.) 21:35, 7 February 2024 (UTC)[reply]
I was the one who started the discussion about the undeletion date. That's the type of thing that makes sense to do on the DR's talk page. —holly {chat} 21:43, 7 February 2024 (UTC)[reply]
@Holly, do you think this was useful enough to you that you would be opposed to making this change? I don't see a lot of loss if you had to do something like this directly on the DR page. I realize we normally don't touch DRs once they are closed, but we do add categories to them (for example) and I've seen a closing admin go back and add to their rationale. It's also what we typically do on a DR for a single image if the image is kept, then later nominated again for deletion. This seems similar to that, though I think you'd want to put the new content below the {{Delf}} template. - 23:45, 7 February 2024 (UTC) — Preceding unsigned comment added by Jmabel (talk • contribs)
@Jmabel: If we stick the new content below the {{Delf}} and then it gets nominated for deletion again, won't that mess up the bot that does the archiving? In the case of undeletions due to expiration, that would probably be extremely rare. I suppose if that does happen, someone can always manually archive it. I guess I'm not opposed. The benefits seem to outweigh the possible risks. —holly {chat} 17:16, 12 February 2024 (UTC)[reply]
@Holly Cheng: I'm not certain even what archiving you are referring to. There's nothing I'm aware of that any bot does to the individual DR page, and I'm not sure what is Krdbot's rule to remove the transclusion of the individual DR in the page of DRs for a particular day. It's obviously able to cope with categories below the {{Cfdf}}, but maybe not other text. User:Krd, I presume you could answer this. - Jmabel ! talk 01:07, 13 February 2024 (UTC)[reply]
I meant the moving of individual DR subpages from the day page to the day archive page. —holly {chat} 17:58, 13 February 2024 (UTC)[reply]
Exactly. And I don't know User:Krdbot's rule for that, which probably only User:Krd can answer, unless someone feels like doing a bunch of research. - Jmabel ! talk 20:16, 13 February 2024 (UTC)[reply]
"Only Categories" is the answer, though I'm not sure to which exact question. Krd 05:42, 14 February 2024 (UTC)[reply]
That's too bad. Then it sounds like Holly's use case might be reason enough to keep the talk pages for these. Does anyone see a good workaround? - Jmabel ! talk 05:52, 14 February 2024 (UTC)[reply]
I think the use case is invalid, as the objection should better be on a user talk page. Does anybody watch deletion requests? I don't. Krd 06:08, 15 February 2024 (UTC)[reply]
@Krd I only watch DRs that I made, or that have significant interest in me that I am heavily involved, like responding to comments or questions every now and then. Though I heavily encouraged everyone to comment on DR pages themselves, not the DR pages' talk pages. On DRs that I am watching, I force the respondent (typically the uploader of the nominated file) to reply on the nomination page proper by moving their comment from the talk page to the nomination page proper and responding their question or protest, with the addition of a reminder for them to comment or respond on the nomination page proper. JWilz12345 (Talk|Contrib's.) 07:40, 15 February 2024 (UTC)[reply]
 Strong support I see no reason to nominate someone's talkpage for deletion unless there is a strong reason, i.e. vandalism, or purely disruptive nature. However, I think this is only a very small number of them, and it should be handled by senior users. --A1Cafel (talk) 10:18, 15 February 2024 (UTC)[reply]
Support I see no reason why the talk page of a DR is required. Admins should be allowed the edit permissions for maintenance reasons -- DaxServer (talk) 18:56, 14 March 2024 (UTC)[reply]
 Support Restrict to admin and LRs. Hide on Rosé (talk) 14:51, 27 March 2024 (UTC)[reply]
 Info one more problematic use, by BDS2006. I just blanked it and transferred it to the main nomination page. JWilz12345 (Talk|Contrib's.) 07:51, 5 April 2024 (UTC)[reply]

Proposal to prohibit political restriction templates[edit]

(The following policy proposal was motivated by the issue discussed in the above section, Commons:Village pump/Proposals#Require community consensus for new non-copyright restriction templates. See also Commons:Deletion requests/Template:Zionist symbol and Commons:Deletion requests/Template:Chinese sensitive content.)

The licensing/permission section on files must contain (a) copyright template(s), indicating either that the file is in the public domain for a certain reason or that it is licensed according to an acceptable license. This section may sometimes contain some other templates, too, which are found in Category:Non-copyright restriction templates. I reckon that there are generally three types of templates in this category:

  1. Templates which convey that there is a (potential) property or pseudo-property right, other than copyright per se, which may result in reusers needing a license for certain types of use.
    Examples:
    • Trademarks: A form of property whose holder has specific rights (although these aren't the same as the rights associated with copyright). The exclusive rights of the trademark holder can only be used under license. Insignia, emblems, seals and coats of arms may be subject to similar restrictions.
    • Personality Rights: A form of property or pseudo-property where people have certain rights not to have their image used in certain ways. These uses can only be made with permission.
    • Governmental Quasi-IP Rights: Not a form of private property, but a scheme under which certain uses of objects can only be made with permission from a public authority. For example, Italian law requires anyone who makes commercial use of images certain culturally important objects to pay a licensing fee.
    • AI-related: Some templates indicate that images may have been produced by generative AI trained on copyrighted works. The legal implications of that are a subject for a different discussion.
    While none of these are copyright restrictions (and may or may not be applicable at all, depending on the jurisdiction), the basic commonality is that there is some sort of (either private or governmental) owner of some kind of exclusive right, and permission must be received from that owner to make certain uses. I think these kinds of templates can be useful reminders to re-users that some form of permission may be required from someone in certain circumstances.
  2. Templates for events and projects which transclude restriction templates of type 1.
    Most of these are for events where some photos may include identifiable people with personality rights. I think these templates are arguably miscategorized (since they are only really restriction templates by virtue of transcluding a restriction template), but that's not what my proposal is about.
  3. Templates which indicate that some jurisdiction(s) may ban any use of some image/symbol in the file for ideological/political reasons. These are what I'm calling political restriction templates.
    Examples:
Proposal

All political restriction templates should be deleted (along with corresponding categories), and future templates of this kind should be disallowed as a rule.

A political restriction template is a template which indicates or claims that some use of a file may be banned, restricted or considered objectionable by some governmental or non-governmental body on the basis of a point of view which is, or may be considered, expressed by use of the content.

Reasoning behind the proposal

Some starting points from Commons policies:

  • Content with these tags may be objectionable to some. This is not a valid reason to remove it, as Commons is not censored. The use of political restriction templates, although it does not entail the removal of these files, may conflict with the spirit of this guideline, as I'll explain below.
  • Commons is not Wikipedia, and files do not need to express a neutral point of view. However, Commons itself is supposed to be neutral on subject-matter disputes. Certainly, a lot of files that are tagged as representing a banned ideology of some kind express a non-neutral point of view in some fashion (which does not make those files banned). The use of these political restriction templates, however, poses significant problems related to neutrality of point of view.

Some of my reasons for making this proposal:

  • The main point of permissions templates is to indicate that the rights to the files have expired or been licensed (and what limitations apply to the expiry/license).
    • A copyright template may indicate that a file is in the public domain in some countries, but not others, or that a license is granted for its use, but with conditions (such as attribution or sharing alike).
    • Anyone who wants to go beyond what is possible according to that file's status must get permission from the appropriate rightsholder(s). Similarly, anyone who wants to use a file in a way that would require the permission of a trademark holder, or a person whose personality rights would be relevant, etc., must receive permission from the appropriate party before proceeding.
    • By contrast, the political restrictions referred to by these templates are (more or less) universal in application, and unrelated to securing permission. In countries where certain ideologies are banned, there's generally no way to receive permission to engage in prohibited speech.
  • Political restriction templates have the effect of privileging government bans over the speech of those who disagree. This goes against our policy on Commons itself (as opposed to the files hosted on Commons) maintaining a neutral point of view.
    • Some of the existing templates already serve as warnings that some content may be objectionable according to a restrictive authoritarian regime. The creation of these warning templates, especially in cases where the government attempts to block access to Commons due to the fact that it is not censored, seems to express the decidedly non-neutral standpoint of those governments over the viewpoints of their opponents (and, in fact, specifically targeting files which contain the viewpoints of their opponents).
    • If we were operating during the days of the Nazi regime, would there being a restriction template placed on the work of Jewish artists indicating that their work is considered degenerate art? Would we have attached a label to the creations of dissidents during the Cold War? Why should we attach such a warning label to such content today?
  • The act of applying these restriction templates to files may also reflect a non-neutral point of view with respect to what the file actually expresses.
    • Who is to say what is or isn't one of these symbols? It seems to require a subjective judgment on the part of the person who applies the tag to say that the symbols in fact do fall within the scope of a ban, especially considering the many legal disputes over what is and is not permitted speech in various countries.
  • The application of a restriction template serves to potentially stigmatize the content (thus expressing or implying a non-neutral view of the content and/or implying that it should be considered whether or not its valid educational use should be avoided), and may be considered inflammatory by various users (see the various points raised in the "Zionist symbol" deletion discussion).

Some alternate ideas or potential objections (and my response to them):

  • Why not base this on whether or not the restriction is imposed by a democratic/good/etc. country?
    • For one, there's no strictly neutral way to determine whether or not a country is "democratic." The World Press Freedom Index mentioned by GPSLeo is the expression of a viewpoint. I'm not saying that viewpoint is incorrect; I'm just saying it's not neutral. Some judgments may be more or less contentious here, but there would definitely be some level of viewpoint-based disagreement.
      • Besides, what would we do if some country which has a good score now is taken over by a new government, which decides to crack down on the freedom of the press? Would we put a template up pending the release of the next WPFI index? It is better to have a test which is independent of any such country-by-country assessment.
    • The restrictions imposed by the countries with higher WPFI scores tend to be less total. In those countries, it's the promotion of certain totalitarian ideologies that is banned, not the reproduction of the symbols (which is commonly done, for example, in history textbooks). Moreover, defendants in criminal cases have due process rights there. For them to commit a crime, it's hard to imagine that they wouldn't know what they were doing (see also the point below on whether or not we owe our users a warning).
    • The most suppressive regimes can (or already do) block access to Wikimedia Commons on the basis that we do not censor the site.
  • Why not make this a case-by-case community discussion?
    • Having a case-by-case discussion means we're still not being neutral. Instead, the discussions would become a popularity contest, with perhaps some restrictions being more accepted than others based on the content of the restricted ideology or who's doing the restricting.
    • Even putting aside the previous point about the lack of neutrality in accepting the restrictions in principle, if we accept that even some of the restrictions are "OK enough" to have a template, the issue with a lack of neutrality still applies every time the restriction template is applied to a given file. "Is this file prohibited content type X?" is not necessarily clear, and I don't think we should be having these discussions (with the inherent NPOV problems in edge cases) on individual files either.
    • GPSLeo sought to exclude things which are like the existing personality rights templates from the scope of the rule, but did not define the scope exactly. I hope my proposed rule is a bit clearer.
  • But we owe users a warning that they could be violating the law, don't we?
    • We have a general disclaimer, and we're not responsible for what users go and do with free content.
    • As addressed above, even where these restrictive laws exist, there are often completely licit uses for these symbols (e.g., in educational materials).
    • I don't think we need to patronize our users like this. These restrictions tend to be very well-known to the people in the countries where they are in effect. They are a core part of the political culture in that country. Both those who agree with them and who disagree with them know this very well. They do not need to be told.
    • Tons of materials can be used in a way that is illicit for non-copyright reasons in lots of countries, even beyond this. For instances, photographs of identifiable people could be modified in a way that libels the person in the photo (or so on). We do not need to remind people not to do things that are illegal.
  • But the Nazis were really bad, and society should not stand for the promotion of Nazism.
    • I agree, but I don't need a restriction template to tell me that.
      Also consider the legal and political disputes such as Strafgesetzbuch section 86a#Anti-fascist symbols, as well as other problems discussed above (some of which apply even if it you accept the wisdom of the legal restrictions themselves). (By the way, despite the ruling of the German courts on the crossed-out Nazi Swastika, the relevant file on Commons still has the restriction template!)

D. Benjamin Miller (talk) 02:49, 6 February 2024 (UTC)[reply]

Votes and discussion[edit]

  •  Support as proposer. D. Benjamin Miller (talk) 02:56, 6 February 2024 (UTC)[reply]
  •  Support These templates are unnecessary cruft. Nosferattus (talk) 03:12, 6 February 2024 (UTC)[reply]
  • Strong  Oppose. How strong? If we drop {{Nazi symbol}} and do not provide some equivalent, I will resign as an admin and possibly reduce my other involvements in Commons. - Jmabel ! talk 03:41, 6 February 2024 (UTC)[reply]
    1. Why?
    2. I don't see what equivalent could exist which is not simply a renamed version of the same thing. D. Benjamin Miller (talk) 04:11, 6 February 2024 (UTC)[reply]
      1) I don't think I owe anyone an explanation, given that this was taken straight to a vote with no prior discussion stage and that (below) you've shown that anything anyone says here in opposition simply becomes another place for you to challenge them.
      2) Precisely. If there is no equivalent of this, that will be my course of action. - Jmabel ! talk 19:23, 6 February 2024 (UTC)[reply]
  •  Oppose This feels like a solution in search of a problem. "Cruft" can describe a lot of things that get put on file pages. Do people really need to see banners that an image was selected as an FP? Quality Image? Media of the day? Do they need to know an image was acquired by Commons due to a partnership between an external repository and a Wikimedia chapter? Do they need to know a picture depicts a UNESCO World Heritage Site? Until someone can come up with a convincing argument for why these specific templates are disruptive or harmful to the project, I don't see any reason to get rid of them. The Squirrel Conspiracy (talk) 04:15, 6 February 2024 (UTC)[reply]
    The proposal is not saying that they should be deleted due to being cruft. (Another person said that, yes.) There is no issue with the number of templates, and the reasoning given in the proposal would not apply to any of the other kinds of templates you mention. And if you do not believe there is any actual dispute here, see Commons:Deletion requests/Template:Zionist symbol, as well as the other section above the original proposal. D. Benjamin Miller (talk) 04:30, 6 February 2024 (UTC)[reply]
  •  Oppose. Suppose you get your way and some college student in Germany illustrates a paper on WWII including a swastika downloaded from Commons, and gets thrown into jail for it because there was no warning. Are you going to defend them? Are you going to bail them out? Are you going to apologize to their parents? Multiply the likelihood of that by the number of college students in Germany on any given day. We try to protect our reusers, not hang them out to dry.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 04:18, 6 February 2024 (UTC)[reply]
    This is not a scenario that actually happens. It's not illegal for a college student in Germany to use a swastika in a history report about World War II. (Can you imagine how absurd it would be to prohibit using pictures of the Nazi era in history reports about World War II?) The symbols of the Nazi party are included in images in virtually every German school textbook about World War II, just as they are included in textbooks about World War II around the entire world. They are also totally legally included in works of art, such as historical movies. See Strafgesetzbuch section 86a. D. Benjamin Miller (talk) 04:24, 6 February 2024 (UTC)[reply]
    @D. Benjamin Miller: Sorry, I had not read that article.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 04:39, 6 February 2024 (UTC)[reply]
    Even in Germany, where the restrictions on the use of symbols of anti-constitutional organizations (including the Nazi party, but also ISIS, the Kurkish People's Defense Units in Syria and various other groups) are fairly strict, there are exceptions for (among other things) use in an educational context, use in opposition to those groups, research, art, reporting, etc. It is hard to conceive of an scenario in which a user in Germany accidentally engages in unlawful conduct because of Commons.
    Likewise, the goal of Commons itself (to store images for educational purposes) is legal in Germany. In fact, many of the images of Nazi Germany come from the Bundesarchiv (see Category:Images from the German Federal Archive)' these images are distributed by the German government for educational purposes. D. Benjamin Miller (talk) 05:13, 6 February 2024 (UTC)[reply]
  • Selective  Support and  Oppose. Support deleting templates that are purely tied to geopolitics, such as {{Indian boundaries}} and {{Chinese boundaries}}. Every country always gets offended if they see any maps being used on Wikipedia with boundaries that they deem incorrect or inappropriate, but it is not the job of Wikimedia Commons to please their territorial interests. I am actually a bit "surprised" that even if it is highly-offensive to depict the "Nine-dash line" by China here, there is no equivalent {{Philippine boundaries}}, but it is not the job of Wikimedia Commons to please our territorial interests. But oppose deleting templates related to political history as well as racial/cultural politics such as those related to Nazi symbol and Falun Gong, in accordance with current arguments by The Squirrel Conspiracy and Jeff G. as of this writing. JWilz12345 (Talk|Contrib's.) 04:47, 6 February 2024 (UTC)[reply]
    What is the difference between geopolitics and political history? Do you just mean templates specifically related to maps? D. Benjamin Miller (talk) 04:51, 6 February 2024 (UTC)[reply]
    @D. Benjamin Miller: yes. Such templates only add needless "dirt" on the description pages of map images. JWilz12345 (Talk|Contrib's.) 04:53, 6 February 2024 (UTC)[reply]
    If these templates are a solution avoiding the project to be blocked in India or China, why not having them? It is a much lesser evil than a block affecting billions of users. Yann (talk) 10:17, 7 February 2024 (UTC)[reply]
    @Yann Commons hosts a couple of maps that really offend the Philippine authorities because these include Spratly Islands and other South China Sea / West Philippine Sea features to the Chinese territory, such as File:China prefectural-level divisions and administrative divisions (PRoC claim).png (used in an English Wikipedia article), File:China-map ko-kore.svg, and File:North and South China Partition Map.png. Perhaps you are aware of the current tensions between Manila and Beijing that have been existing since 2010s. Still, the PH authorities hasn't issued any order blocking access to either Commons or even Wikipedia because of instances of maps that show the whole South China Sea region as part of China, and I think there is little likelihood of Commons itself being blocked because of the presence of such maps. English Wikipedia would be the first in line of the PH government's censorship if ever, but there is low probability as of now. I do not agree hosting templates tackling boundary disputes (like {{Chinese boundaries}} and {{Indian boundaries}}), these should be taken down. The users are responsible for their actions (as stated in our general disclaimer page); more so, English Wikipedia editors are responsible to ensure that their articles do not cross the line of fire of the PH/Indian/Chinese authorities with regards to insertion of such contentious maps in articles that may discuss territorial disputes. Territorial disputes are English Wikipedia's responsibility, not Wikimedia Commons'. JWilz12345 (Talk|Contrib's.) 22:56, 14 February 2024 (UTC)[reply]
    Yes, I aware of the dispute between China and the Philippines. It came in the news in France. I won't fight for these templates, but still I feel that some information in each of these maps is needed. Only "(PRoC claim)" in the title doesn't really seem sufficient. So if it is not in the form of templates, how to do it? Yann (talk) 23:05, 14 February 2024 (UTC)[reply]
    @@Yann: we do not need to provide extensive information about territorial claims, other than using description fields of {{Information}}. It is the job of individual Wikipedias to provide such information. For other users, it is at their own risk if they offend our government for using Commons-hosted maps of China, the Chinese government for using Commons-hosted maps of the Philippines, and the like. We have COM:General disclaimer, which is repeatedly referenced here. In most cases, we only deal with copyright restrictions (FoP, license plates, stamps, toys, etc.) in safeguarding other users, but in non-copyright restrictions, these are the users' own risks. JWilz12345 (Talk|Contrib's.) 07:54, 22 February 2024 (UTC)[reply]
    I'll wager the vast majority of countries does not throw people in jail for using a version of a map they dont like Trade (talk) 14:10, 22 February 2024 (UTC)[reply]
     Info I now started Commons:Deletion requests/Template:Indian boundaries. The fate of {{Chinese boundaries}} will depend on the outcome of the said template deletion request. JWilz12345 (Talk|Contrib's.) 22:53, 13 March 2024 (UTC)[reply]
  •  Oppose This is far to broad and needs exceptions. I think the assumption on what the neutral point of view means for the project is wrong. The NPOV only applies when it comes to the decision which photo to use and how to describe and categorize content. But for meta topics we are not neutral, there we have the goal to make the project better. GPSLeo (talk) 07:12, 6 February 2024 (UTC)[reply]
    That's not the position taken in the essay Commons:Disputed territories. For example:

    Categorization should either be neutral (ideally), or double. e.g. most of these files will be in the simple Category:Geography of Golan Heights (neutral), which itself is a subcategory of both Category:Geography of Israel and Category:Geography of Syria (double). This will work with all subcategories too. Don't add Category:Flora of Israel. Make a category called Category:Flora of the Golan Heights, then it can be a subcat of both Category:Flora of Israel and Category:Flora of Syria.

    I'll ask you: how could we possibly make exceptions in a way that is not based on whichever viewpoints are popular or not? For instance, should we decide whether to keep the Indian or Pakistani border depiction warnings based on which receives more support? Should we keep Template:LGBT symbol? Template:Chinese sensitive content?
    As far as I can see it, there are three paths we can go:
    • We don't allow for any of these templates — which is content-neutral.
    • We allow for all restriction templates (as we currently do). We've seen contentious back-and-forth editing where these templates are used to stigmatize content (including, in some cases, according to 魔琴, content which isn't even actually banned even under the various authoritarian regimes). Template:Zionist symbol will continue to be stuck as a "badge of shame" (as Mx. Granger described it) on various pictures with stars of David, Template:Chinese sensitive content will be stuck on images of the Dalai Lama and Tsai Ing-Wen, etc. By this standard, someone could create a template, such as "American Imperialist Symbol," and slap it on all images of an American flag, commenting on how it cannot be flown freely in Iran and North Korea. I think these labels can be inflammatory and highly undesirable — and are inherently prejudiced towards the view of the banning party over the view of the banned party.
    • We allow for some, but not all, and the determinations end up based on the popularity of the banned viewpoint. Also, political flame wars ensue over every controversial subject to determine whether or not it should be given the mark of shame. I don't think this outcome is desirable either.
    D. Benjamin Miller (talk) 07:39, 6 February 2024 (UTC)[reply]
    Alternatively, here's the other issue. You mentioned earlier that you do not feel it makes sense to have restriction templates for the legal restrictions created by undemocratic regimes, but that it must be OK to have some for legal restrictions created by democratic regimes.
    (The following statements are very much not viewpoint-neutral. My personal opinions are contained below.)
    In agree with you — sort of. I think that there are things that are morally wrong — say, because they run counter to my concept of justice (which has democracy as a component). I think it is worth condemning and stigmatizing those things. Nazism is one such thing.
    But Nazism's wrongness in no way originates from the fact that it its symbols are banned by the German government. It was wrong when it was first formulated, it was wrong when the Nazis were in power and it is still wrong now. When the Nazis killed my relatives and millions of others for "crimes" such as being Jewish, they did so with the authority of government.
    Government legislation is not a source of morality. Governments can do evil things. Even a bad government has real power over people, and bad governments today can and do subject people to punishment for reasons that are fundamentally unjust.
    As far as I am concerned, the worst reason to not be a Nazi is because it is punishable by law. If the only thing that keeps someone from promoting Nazism is a legal penalty, that is incredibly sad.
    To me, it feels wrong for these warning labels to be mere acknowledgments of the fact that some set of governments has condemned something. The way this is done right now is what I'd call pseudo-neutral. While I think using political restriction templates at all is inherently non-neutral (see above), accepting them indiscriminately is being neutral with respect to which state-sponsored prohibitions warrant mention. However, this means that you are opening the door to include political restriction templates based on the edicts of the most vicious and wrongheaded governments.
    The alternative you suggest — having some templates but not others — inherently involves adopting some set of political ideals. Even just deciding which states are "democratic" (and thus are worth paying attention to for the purpose of restrictions) requires this. After all, the North Korean party line says that the North Korean regime is democratic, though I certainly wouldn't concur.
    Especially given the role of these values themselves, rather than any state identified as sharing them, in determining what is right and wrong, if you're going to have any anti-Nazi (or anti-anything) template, it should be based on the fact that Nazism, etc., conflicts with these core values themselves, not the fact that there is a government out there that imposes some sort of penalty for some use. That would be the reflection of adopting, as Commons and/or Wikimedia, some number of official political positions as a community.
    The real question is what to do when you get to the more contentious templates in the group — really, you get beyond an anti-Nazi stance, every other subject probably elicits significantly less agreement. And I just don't feel it's realistic or necessarily productive for Commons/Wikimedia to adopt official community stances on political issues which don't have to do with copyright, free media, etc. The procedure for proposing and approving such motions sounds like it would be a nightmare.
    D. Benjamin Miller (talk) 11:01, 6 February 2024 (UTC)[reply]
    As I already wrote: We should not be neutral when it comes to the usability of our project. And we can not be neutral when it comes to the en:Universal Declaration of Human Rights. Therefore we should accept warning templates based on laws they are covered by and are made to support these human rights. GPSLeo (talk) 20:35, 6 February 2024 (UTC)[reply]
    Thanks. That is a good point and feels like a better starting point than choosing a particular cutoff from a particular press freedom ranking. I am certainly not neutral towards the values of the UDHR; I support those values. And as of 2021, the WMF has adopted support of the UDHR as a position. So that seems something which could be built on.
    The WMF also has adopted a Universal Code of Conduct in a similar vein. One point of this policy is a rule against the "use of symbols, images, categories, tags or other kinds of content that are intimidating or harmful to others outside of the context of encyclopedic, informational use. This includes imposing schemes on content intended to marginalize or ostracize."
    The presence of such symbols within the appropriate educational context is allowed (which nobody disputes). But my reading of this policy (a policy which adopts a non-neutral stance towards intimidation and hatred itself) is part of why I feel the tags are problematic.
    Putting aside for the moment the issue of whether or not we are making accurate determinations about what is or isn't a Nazi symbol (which I think is problematic in some cases), I don't think that it is really debatable whether or not Nazism is an ideology that is counter to the human rights stance of the WMF. It obviously is; the UDHR itself was formulated specifically in response to Nazism, so there can be no ambiguity about whether or not it is included within the scope.
    Allowing for restriction templates only relating to laws which target ideologies and political views which are counter to the UDHR is a more precise distinction, and I appreciate your suggesting it.
    My difficulty is that, while it is clear that Nazism is counter to the UDHR (I don't think there's any other way to interpret it, given the specific context in which it was written), a lot of these restrictions have to do with things which are claimed to be against the UDHR (but not universally accepted as such).
    For example:
    • Zionist symbol — Many people and governments have characterized Zionism as inherently racist. I don't agree with that assessment — nor do the governments of Israel (obviously), Germany and a number of other countries. But many governments do characterize it as such. From the 1970s to the 1990s, this was a position taken by a UN resolution. South Africa has brought a case against Israel accusing it of genocide in the ICJ. So there are many people who would say bans on "Zionist symbols" target an ideology counter to the UDHR.
    • Chinese bans — China claims to support and implement the UDHR. The Chinese government claims its restrictions on speech are necessary to preserve a public order that supports human rights. I and many Western governments and commentators find these claims dubious, but they do make them.
    • Russian bans — Russia has claimed that Ukraine is run by Nazis and that its war against Ukraine is motivated by a desire to de-Nazify Ukraine. Nazism is obviously the paradigmatic anti-UDHR ideology. The issue here is that the Russian claim that Ukraine's leadership are Nazis is an implausible factual allegation.
    And so on. My question is:
    • Do we want to put ourselves in the situation of having to determine by consensus which ideologies violate the UDHR and who really subscribes to such ideologies?
    • What is the level of consensus needed? Must there be virtually universal assent that the target of the legislation is anti-UDHR? Would this standard of consensus be higher than the usual standard of consensus for other questions?
    D. Benjamin Miller (talk) 22:37, 6 February 2024 (UTC)[reply]
    Yes we are the one to decide as this our project. Consensus is formed like for every proposal or scope related deletion request. GPSLeo (talk) 06:54, 7 February 2024 (UTC)[reply]
    Well, I admire your optimism and I hope you're right to think that it would go smoothly if it were the rule. D. Benjamin Miller (talk) 11:19, 7 February 2024 (UTC)[reply]
  •  Oppose No need to object to neutral statement of facts to inform users about works they should be careful using.--Prosfilaes (talk) 20:45, 6 February 2024 (UTC)[reply]
  • Rather  Oppose. More information is better than less or no information. Some of these templates may be too strongly worded (or unnecessarily display a strong warning), but yet they offer an information pertinent for some users. I would support more neutral templates (not using red warning, etc.), but the deletion isn't a solution. Yann (talk) 10:08, 7 February 2024 (UTC)[reply]
  •  Oppose per Yann and Prosfilaes. --Prototyperspective (talk) 11:06, 7 February 2024 (UTC)[reply]
  •  Oppose per Jeff and others. All it takes is some rogue prosecutor in a country that doesn't have free speech as a guaranteed right, and a re-user could be jailed for using one of our images. Warning them of these laws should be a thing we do. I agree with Yann that some warnings should have a more neutral tone, but generally warning of non-copyright restrictions is good. Abzeronow (talk) 17:08, 7 February 2024 (UTC)[reply]
  •  Oppose, while I am not a fan of the existence of these political restrictions, I think that we have a moral duty to report to potential re-users what restrictions exist outside of copyright-related rights. We shouldn't be providing less information about the consequences of using files uploaded here, especially since some of the fines and penalties are really serious (like desecrating the name or image of a "hero of the People's Republic of China", which can land a person 3 (three) years in prison). I don't think that anyone here is actually a fan of the existence of these restrictions, but warning people of potential consequences doesn't enforce the positions of these unfree governments, it simply informs re-users that there are limitations beyond the copyright ©️ of a file. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:33, 8 February 2024 (UTC)[reply]
    My feeling, however, is that the speech restrictions of some countries (like the PRC) are really pretextual. If you have an authoritarian government, then they're going to censor you or prosecute you however they want. To @Abzeronow's point, I'm not sure that such prosecutors would really be "rogue."
    Besides this, some of the tags we've seen have been inaccurate (or misleading). For example, Tsai Ing-wen's photo was tagged as Chinese sensitive content — but she is in the Chinese news; there is certainly no ban on acknowledging that she exists. The problem would be "advocating for Taiwan separatism." Similarly, defaming (by whatever arbitrary and capricious standard might be applied) a hero of the PRC may cause jail time, but the image of such a person would not be defamatory in itself. So we could say a lot of the files aren't problematic in themselves, but the subject depicted is one which could cause problems for people (depending on the viewpoint expressed about the subject).
    Not to mention, if we really go down this road, we could end up tagging all pictures of Winnie-the-Pooh as Chinese sensitive content, or all pictures of Salman Rushie as Iranian sensitive content. And who knows what might draw the ire of a censor tomorrow?
    As a number of other people have mentioned, the PRC blocks access to Wikimedia projects anyway. They are not the only one to have done so, and a bunch of the censorship templates we have refer specifically to the laws of these countries. If someone is accessing the site from the PRC, they know they're circumventing a block to begin with. If we are worried about inadvertent problematic use, I think we can presume anyone bypassing their country's ban on the site altogether isn't going to be making such a use accidentally. D. Benjamin Miller (talk) 17:17, 8 February 2024 (UTC)[reply]
    Co-signed. Zanahary (talk) 21:15, 21 February 2024 (UTC)[reply]
  •  Support prohibiting anything related to the PRC, which has both famously abysmal press freedom and blocks Wikimedia websites; also support prohibitions for Myanmar, Russia, and North Korea for similar reasons;  Oppose any broad prohibition of political warning templates. I do think some of them should be deleted as frivolous and largely unused but that doesn’t require a policy change. Dronebogus (talk) 14:03, 8 February 2024 (UTC)[reply]
  •  Oppose deletion for templates of democratic countries (Like {{Communist Symbol}} for South Korean users. In South Korea, symbols related North Korea are prohibited under South Korean National Security Act. {{Communist Symbol}} can be used for symbols related North Korea files.)  Support deletion for templates of autocratic countries (Like {{South Korean Symbol}} for North Korean users. Wikimedia Commons cannot be accessed in North Korea.) --Ox1997cow (talk) 15:29, 8 February 2024 (UTC)[reply]
  •  Oppose for the way-too-broad proposal, but also  Weak support for the general idea: this is a sensitive issue. In moderation, "political restriction templates" have their use, which should not be prohibited, as such a prohibition is itself a restriction of the freedom on Commons. Communazi symbols are frowned upon in most parts of the world, and Commons should be a platform for education, not propaganda. For that reason, files that outright show facist or authoritarian propaganda (especially without educative texts to explain the display) should get a disclaimer to show that Commons does not share the authoritarian views promoted in the picture itself. The Chinese-borders template is another example: any map showing any part of the SCS but not the 9Ds is basically illegal in China, but their authoritarian stance should receive blowback here on Commons: Nine-dashed maps are authoritarian propaganda, and planting a template is therefore deserved. Most maps on Commons don't have these 9Ds, anyway. On the other hand, we should not obediently place a "political restriction template" on all other maps, warning our PRChinese users that China considers these maps illegal. Naturally, the previous commenters here have already taken action and DR-nominated templates discussed here, without waiting for consensus on the debate. Now: If a political warning-template would have to be plastered onto hundreds of thousands of files (if fully executed), then something might be wrong with the definition of the template; especially if there is nothing offensive to be seen. On the other hand, if a political warning template (like the Nazi-symbol disclamer) gets plastered onto hundreds of thousands of files with no offending symbols (the text deals with inheritance law issues), then something might be wrong with the application of the template.
    tl;dr: "Political restriction templates" should be used with common sense, and we do indeed need project-wide agreements on how to use them. --Enyavar (talk) 17:16, 9 February 2024 (UTC)[reply]
  •  Support.
  1. most of these nonsense templates only started appearing in recent years.
  2. internet is not kindergarten. users are expected to assume their own risks and not babyfed such warnings/reminders of any kind of restrictions there may be in any country.
  3. quoting Professor James Duane https://www.youtube.com/watch?v=d-7o9xYp7eE&t=310 , there are 10000 different ways you can get convicted by US federal law. there're just infinite number of crimes in the penal codes of the 200+ jurisdictions there are in the world, which can relate to certain files hosted on commons. as shown in the list, some countries by themselves alone need multiple templates because they outlaw porn/maps/blasphemy/lèse-majesté... where does this end?--RZuo (talk) 14:05, 13 February 2024 (UTC)[reply]
    for example, since taliban bans music, should there be a template for all recordings of music to warn afghan users then?
    en:Censorship in China has a super long list. a template for all of them?
    https://www.nbcmiami.com/news/local/roughly-300-books-were-removed-from-libraries-in-florida-last-school-year-heres-the-full-list/3113184/
    Utah primary schools ban Bible for 'vulgarity and violence' https://www.bbc.com/news/world-us-canada-65794363
    ... RZuo (talk) 16:43, 13 March 2024 (UTC)[reply]
  • And also. Nazi symbol is not a reason to create nonsense templates. it will lead our attention to nonsecal issues and will bring to Commons user from all over the world for a political issues which is not in the topic of Commons.-- Geagea (talk) 19:46, 17 February 2024 (UTC)[reply]
 Support. The disclaimer covers what needs to be covered. These templates create needless edit-wars that really add nothing to the commons (how valuable is the Zionist symbol template that it's worth fighting with disruptive editors to have it taken off of pictures of menorahs and cookies?). They also put commons users in the position of interpreting various international laws, many of which have never been transparently enforced. This is also a needless slope to roll down; lots of territories legally suppress imagery and text. These suppressions are often vague and thinly-explained, and don't lend themselves well to creating a template that says "The law here says x". Zanahary (talk) 21:14, 21 February 2024 (UTC)[reply]
 Comment Most of these seem ridiculous and offensive. Putting an LGBT warning on every file with a rainbow in it is patently ridiculous. The Nazi warning seems fine to me, but the rest feel like someone saw a slippery slope and grabbed their toboggan. Bawolff (talk) 07:14, 22 February 2024 (UTC)[reply]
I agree on the LGBT matter, but at the same time... while many are saying here that we don't need even warnings over cultural sensitivity, others are proposing to delete hundreds of images over cultural sensitivity. And it seems to me that a warning tag is a good compromise between deletion and nothing. - Jmabel ! talk 22:44, 22 February 2024 (UTC)[reply]
@Jmabel: the case you mentioned seems to relate to non-copyright restrictions (cultural rules from the museum), and not necessarily cultural sensitivity. JWilz12345 (Talk|Contrib's.) 23:12, 22 February 2024 (UTC)[reply]
The museum itself had licensed the photos on their own account, using one of the usual irrevocable CC licenses. They have now decided for reasons of cultural sensitivity that they wish to suppress the images. The license itself was clearly valid in copyright terms. Yes, the basis on which they want it deleted is a non-copyright restriction; similarly, none of the warnings discussed here related to copyright. - Jmabel ! talk 23:27, 22 February 2024 (UTC)[reply]
Accidental copyright releases reversed for courtesy don't seem relevant to this particular template discussion. Zanahary (talk) 05:04, 24 February 2024 (UTC)[reply]
At the point when I initially made my remark, they were asking for deletion on the basis of cultural sensitivity. They seem to have shifted their ground. - Jmabel ! talk 17:07, 24 February 2024 (UTC)[reply]
That seems like a very different type of "sensitivity" - As far as I understand, the museum accidentally released a bunch of images under creative commons licenses. Then years later they realized they had promised some other groups that they wouldn't do that in order to be "culturally sensitive". Now they are trying desperately to put the genie back in the bottle, and commons has to decide if we want to delete out of courtesy to avoid burning bridges, or stick to our guns that whatever private agreements the museum may have are not our problem years after the fact as long as the museum was legally capable of giving permission at the time. A fraught situation to be sure, but I highly doubt a warning template would satisfy anyone in resolving it. Bawolff (talk) 03:08, 24 February 2024 (UTC)[reply]

 Oppose Way-too-broad of a proposal. I'd probably support something more narrow and less long winded though. Like I mostly agree that the template for Nazi symbols in Germany is totally pointless. But each template should really be decided on separately though. --Adamant1 (talk) 05:31, 14 March 2024 (UTC)[reply]

 Oppose in its entirety: {{Nazi symbol}} and {{Communist symbol}} are established templates that are used in MediaWiki itself (via MediaViewer) to warn potential re-users about the restrictions. Yes, that is a ‘restriction to freedom of speech’, no, that does not necessarily mean these templates are out of order. If the template text / design is a problem, we can re-do that, but even {{LGBT symbol}} is now justified given that, for example, Russia (the country I come from) criminalises any display of LGBT symbols, down to rainbow frog earrings. It is more than valid to try to warn potential re-users about this bullshit. stjn[ru] 14:40, 21 March 2024 (UTC)[reply]
@Stjn how about the territorial dispute templates like {{Chinese boundaries}}? These are needless clutters to files of maps of the Philippines, China, Japan, South Korea, India, Indonesia, and other countries with territorial disputes. I do not agree to deletion of the likes of Nazi templates though. JWilz12345 (Talk|Contrib's.) 15:04, 21 March 2024 (UTC)[reply]
If it has real consequences like in Commons:Deletion requests/Template:Georgian boundaries, I don’t see a problem. The template text can obviously be made shorter/smaller/w/e. stjn[ru] 15:10, 21 March 2024 (UTC)[reply]
 Strong oppose per Yann, Donald Trung and Jeff G. Hide on Rosé (talk) 14:54, 27 March 2024 (UTC)[reply]

Image categories by year[edit]

The more we have images categories divided up by year, the less applicable the categories become when looking for a good image for an article. In my opinion this syndrome/phenomenon has gotten completely out of hand and done very serious damage to the project. A person of royalty, for example, may have 40 different categories of "So-and-so by year" making it practically impossible to find the best image to use notwithstanding what year it was created. Would it be possible by some kind or bot or AI to duplicate all images sorted by year to the subject's main category? SergeWoodzing (talk) 19:47, 5 March 2024 (UTC)[reply]

Year categories are often very useful, especially for maps, charts and so on...the problem you described is not specific to years-cats but lots of other subcats as well. For example, cats for all the countries in Category:Milky Way Galaxy and a place on Earth‎ or Gender subcategories in (1 example) Category:People exercising or and countless other cases.
A problem not quite clear from your description is that also when one intends to subcategorize them by something else such as 'which exercise' it is or what's actually shown in the image rather than common distinguishers, then this becomes very difficult when one has to browse lots of subcategories from where these have then been removed (often even before the cat has been created or despite it missing there; see COM:OVERCAT). There could be further and complementary potential solutions to this issue but for now what I proposed is a Wall of Images view for category pages so you can easily see all images in the subcats on one page like in the search results. And in addition one could sort (and filter) them by things like year or number of uses where these as well as the ability to just scroll through glanceable images make it possible to quickly find a good / fitting image. Prototyperspective (talk) 20:08, 5 March 2024 (UTC)[reply]
Thank you so much! I just voted there. --SergeWoodzing (talk) 20:31, 5 March 2024 (UTC)[reply]
An option to simply disable subcategories for a specific category would be a lot simpler Trade (talk) 20:41, 7 March 2024 (UTC)[reply]
+2 to that. Although there's nothing wrong with Prototyperspective's proposal, but at the of the day there should be multiple options and the issues with people over using "by year" categories should be dealt with regardless of if their idea takes off or not. Really, there should just be a guideline about when it's cool or not to make "by year" categories in the first place. We shouldn't have to create work arounds to compensate for the lack of guidelines or policies about these types of things. --Adamant1 (talk) 02:50, 8 March 2024 (UTC)[reply]
A good rule of thumb is that a by-year division should not be the only or primary subdivision of a given category. While by-year and similar categories are valuable for certain purposes, they are not useful when someone is looking for a general image of the subject or a certain aspect. For that, depending on the size of the main category and other factors, it's better to either have the single main category or have subcategories by aspect.
For example, Category:Construction of the Green Line Extension (MBTA) has about 750 files, which necessitated subcategories. By-year subcategories are useful in this case to see what construction activities were happening at what time - but they would be useless to find a picture of a certain station under construction, so all files are also in categories for what portion of the project was being constructed. Pi.1415926535 (talk) 00:08, 30 March 2024 (UTC)[reply]

New draft of File naming guideline[edit]

There was a discussion recently on the English Wikipedia about whether including the photographer's work in the filename was relevant, specifically with images such as File:Murten Bern Tor photographed by Robbie Conceptuel.png. It was pointed out that Commons' file naming guideline is very terse, kind of a mess, and is actually a failed proposal - the closest accepted guideline is the Commons:File renaming policy. The "blatant advertising" renaming criterion was mentioned but I found a note in Commons:Requests for comment/File renaming criterion 2 that "re-naming a file to remove the author's name is inappropriate". I think that discussion has been resolved but it did bring to my attention that there is a gap in guidance - Commons has a detailed official guideline on renaming files, but no official guideline on what to name them initially.

Therefore, I took it upon myself to create a new draft, User:Mathnerd314159/File naming. I incorporated existing policies, guidelines, and advice from a variety of sources on Commons while trying not to create any novel policy. I was thinking that I would revise the draft to accommodate any comments and then once the draft is in a good state I would overwrite the main Commons:File naming page and there would be a vote on whether to adopt it. Mathnerd314159 (talk) 17:52, 22 March 2024 (UTC)[reply]

Thank you for the work, and the proposal makes pretty much sense for me. Ymblanter (talk) 08:18, 23 March 2024 (UTC)[reply]
 Support thanks for the work, I have made numerous move requests for nonsense filenames.Paradise Chronicle (talk) 08:47, 23 March 2024 (UTC)[reply]
 Support +1 - Jmabel ! talk 09:55, 23 March 2024 (UTC)[reply]
 Support +1 --Robert Flogaus-Faust (talk) 11:11, 23 March 2024 (UTC)[reply]
 Comment — An important Commons constituency are third-party users. In the "Ideal" section I'd like to see a mention of the importance of choosing a name that is suitable for use/linking by third-party users. —RP88 (talk) 18:24, 23 March 2024 (UTC)[reply]
I looked a bit but couldn't find many considerations in naming that were specific to third-party users. There is the general policy of stable filenames, which is partially to ease third-party use/linking, but that does not affect new uploads, so it is only mentioned in the introduction. There is searching for relevant files, but all Commons users appreciate better filenames in this task, so specifically identifying third-party users would be strange. Is there a specific file naming criterion that you had in mind that is important for third-party users but not relevant to first-party users? Mathnerd314159 (talk) 21:13, 26 March 2024 (UTC)[reply]
Sorry, I wasn't as clear as I should have been. I'd like to see a mention of the use/linking by third-party users as an example/justification for the first point (the one that contains "...good idea to stick to graphemic characters, numbers, underscore..."). If I recall my Commons history correctly, linking by third parties was part of the original justification for suggestions of this sort when recommending preferred (as opposed to mandatory) name criteria. —RP88 (talk) 22:16, 26 March 2024 (UTC)[reply]
The line in my guideline is from the original 2009 File naming guideline, there was a discussion on the talk. I see no mention of third-parties, it seems like the justification was that some files were being uploaded with control characters. I think most OS's/CMS's fully support UTF-8 filenames these days so generally any valid Commons name will be usable by a third party. When I kept the advice, I was thinking of stuff like w:Zalgo text. Mathnerd314159 (talk) 04:29, 27 March 2024 (UTC)[reply]
 Oppose there are several problems with that approach:
  • the guidance that "filenames should be in English" violates our core Commons:Language policy.
  • Also, given that your initiative seems to have come from wanting to curbe the inclusion of the name of photographers as advertising or self-promotion, there should be some guidance that including the name of the photographer or archive is acceptable.
  • Also it's unclear if there is actually any added value in another page on the topic (Will we end up renaming because of the "file renaming policy" or because of the "file naming policy"?).
Further, I don't think the following is helpful and might make uploads of archives utterly complicated:
  • "The following styles of names are not allowed: Names consisting primarily of a broad location, such as a city, province, or country." Uploaders might struggle to be more precise than including the a city or province, but other contributors can easily complete descriptions and categories.
Enhancing999 (talk) 04:32, 24 March 2024 (UTC)[reply]
  • On some of these, I think we need to distinguish between what is allowed and what is encouraged. Certainly that is the case for discouraging "broad location, such as a city, province, or country" and such files should probably be subject to renaming. I recently ran across a case where someone took 50 files of a single cemetery and gave titles that were each just the city name plus a number.
    Good catch on English, though. That's generally the case for categories, but file names can be in any language. - Jmabel ! talk 10:11, 24 March 2024 (UTC)[reply]
    Even so, e.g. we have thousands of files from Ray Swi-hymn uploaded from Flickr with somewhat general, but useful filenames. Eventually some files end up fairly well described and categorized, but this is way beyond what can be done or expected from an uploader. Enhancing999 (talk) 10:32, 24 March 2024 (UTC)[reply]
    @Enhancing999: I think you have separate the usefulness of a file name from the ability to categorize an image. Since they different ways of finding media that aren't mutually exclusive. If you want an example, check out how most stamps of the Soviet Union or Russia are currently named and categorized. Sure Russian stamps from 1996 are still categorized appropriately in Category:Stamps of Russia, 1996, but then the individual files are named after a catalog number from an obscure stamp catalog in Russian that no normal person has access to, cares about, or would use a way to search for the images. Especially on something like Google where descriptive file names are pretty important.
Regarding the English, I wrote in the minimum filename standards that any language was acceptable. The question I was attempting to answer was instead, for a multilingual uploader, which language they should use for their upload name. The language policy calls out English in several places (e.g., category names, creator names) so it seemed a good suggestion. I have updated it to prefer the language most relevant to the subject (based on Commons:Galleries#Naming_conventions). There could be further work on this guideline but at least the gallery convention encourages language diversity.
Author in the filename is listed in the minimum standards bullet list under "Names consisting solely of dates, the name of the photographer or rights holder, and/or words like “Flickr".
The "broad location" guidance is in the file renaming policy, there was a vote 15/18 that uploaders should do a "bare minimum" of work to include detailed locations in the filenames. For example File:20170712_ZurichRail_0932_(36101630414).jpg, arguably the filename is a "meaningless or ambiguous name". The only legible information is "Zurich Rail" but there is no Zurich Rail visible in the picture. The file could likely be renamed to a more informative name like "20170712-Lidl-Gretzenbach" without any opposition. Since it can be renamed, it is a bad filename.
There is some overlap between the naming and renaming policies, but the renaming policy actually specifically links to the naming policy page and says "Commons:File naming describes how files should be named." I would say the distinction is that the file naming policy describes how good a filename is (absolute scale), while the file renaming policy evaluates whether there is sufficient justification to rename a file (a certain arbitrary increment on the scale, from new to old). If this guideline does get accepted, likely some of the footnotes and explanations on the renaming page could be omitted as the file naming page goes into depth on those details. Mathnerd314159 (talk) 16:04, 26 March 2024 (UTC)[reply]
  •  Support Per my comment above. We have a longstanding issue with people using file names for images that are to ambiguous or specialized to be useful. I think we should be able to separate the ability categorize something from the usefulness of the file name. Since they aren't mutually exclusive. Like with my example of how Russian stamps are currently named, sure they are "well categorized", but that doesn't mean that specific images are easy to find or that how they are currently named is at all useful to anyone. Anyway, we really need some kind of guideline to curb things like that. Although I do wonder how it would be enforced, but that's another discussion and I trust Mathnerd314159 will iron out the details before a final vote. --Adamant1 (talk) 17:23, 24 March 2024 (UTC)[reply]
"There was a discussion..."
what's that?
 Oppose as @Enhancing999 has elaborated. RZuo (talk) 14:03, 25 March 2024 (UTC)[reply]
  •  Support for the minimum standards. The ideal standards might need more work (vote  Neutral), but there have been improvements after Enhancing999 pointed out flaws. Mentioned is now: local languages are recommended for subjects; English would be standard for generic subjects. I don't know how this can be formulated better, but please imagine that we have the scan from a Polish book that features the 436th portrait of Columbus for Commons. Is "Ritratto Cristoforo Colombo" (it-Standard) better than "Portrait Christopher Columbus" (en-Standard) or shouldn't it be "Portret Krzysztofa Kolumba" (pl-Standard) because of the language of the book? On the other hand, which language can we reasonably expect when naming a photo of the Finnish folklore band that a Korean tourist took on their tour in Paris? en/fi/ko/fr could all apply. I would say all languages would qualify for "ideal" titles, as long as nothing is misspelled. But I'd also support that we focus on correcting file names that don't fulfill the minimum standards; rather than try to bring every name into "ideal" territory.
But we might want to (more clearly) discourage needless abbreviations: "pic org-com 4 wp glam-denco 02'10'2025" is a bad title, even if everyone involved knows that this is obviously a "picture of the organization committee for the Wikipedia-GLAM event in Denver, Colorado on October 02, 2025". Even if the description decodes that title and makes the picture searchable, it's too cryptic. The guideline covers "acronyms", but not abbreviations, so far. --Enyavar (talk) 09:20, 27 March 2024 (UTC)[reply]
I think the policy may be useful for English language descriptions, or possibly filenames in English language Wikipedia, but Commons is not the English language Wikipedia file storage only.
It's still not consistency with our language policy to tell, e.g. Spanish language uploaders that they should use "chair" and not "silla" in the filename.
Also, the proposer's feedback fails to address the issue with large batch uploads, e.g. the thousands of files of the "Ray Swi-hymn" uploads. The "minimum standards" make these practically impossible. Maybe the proposer can try to work out a batch upload that consists of more than a dozen of images and attempt to tackle the issue in practice. The proposed guideline just doesn't scale to Commons size.
We already have multiple ways to describe files, we don't need another one. Filenames are already unambiguous, we don't even need a guideline for that, it's a technical necessity. Enhancing999 (talk) 09:45, 27 March 2024 (UTC)[reply]
The argument for using English for general names is consistency of search results. If I search for "chair" I get pictures of chairs. If I search for "silla" I do not, the main results are an ancient Korean kingdom. There is one chair mixed in there, File:Silla de la Casa Calvet, Antonio Gaudí.jpg, but it is categorized as "furniture" rather than as a chair, so it does not show up when searching for chair. Just because an uploader "can" name their file "Silla de la Casa Calvet" does not mean that they should - there are actually 2 other files File:Gaudi's chair for Casa Calvet - Casa Milà - Barcelona 2014.JPG, File:Gaudi's chair for Casa Calvet - Casa Milà - Barcelona 2014 (2).JPG, so if the uploader knows English then naming it along the lines of "Casa Calvet Chair" would be more consistent. Similarly other terms like "armchair", "loveseat", "butaca", "confident" - they are all harder to search for than "chair". It is not really about language - if there was a really popular German term for something that had little usage in English, then likely using the German term would be appropriate - but I haven't encountered any such terms.
Regarding mass uploads, this seems to be a perennial conflict. For example in Commons:Batch_uploading/US_National_Archives#File_name_maximum_length_and_file_name_cutting_format, Teofilo stated "It is not realistic to correct all these file name errors afterwards one by one [...] The upload software bug must be solved. [...] I think the bot should be blocked until the file-name issue is solved." I certainly have some agreement with that - if Commons was willing to accept files under any name and rename them afterwards, it would not have global filename blacklists. Similarly, if an uploader is not willing to do any work on improving filename quality, how can they be trusted to have checked more important details such as licensing and that the file is of sufficient quality to be uploaded? Tools such as Pattypan allow easily changing the target filename and other details. What Commons needs is high-quality files with accurate and comprehensive metadata, at least meeting some minimum standards, not terabytes of garbage thrown in at random. And yes, I would include the "Ray Swi-hymn" uploads in this category of "garbage"- many photos are blurry, have no clear subject, seem like they have no realistic educational use, or are duplicates or worse shots of similar photos. The bad filenames are the least of the problems but serve as an indicator that minimal effort was made to curate the photos. Commons is not a Flickr mirror and does not need to blindly copy every single freely-licensed photo.
Regarding multiple ways of describing, filenames are not new and were the first method of describing files. I was reading a discussion where many users still reported finding files by their filename, finding categories and description data difficult to use. I suppose we could adopt something like Wikidata where all files are identified by an ID like Q691283, but I think this would make it more likely to have insufficient metadata for files, not less. As long as filenames are in use, it makes sense to have guidelines for how to write them. Mathnerd314159 (talk) 18:50, 27 March 2024 (UTC)[reply]
Oh, so you are trying to fix search with the guideline. I understand, but this isn't the purpose of filenames at Commons. Enhancing999 (talk) 18:52, 27 March 2024 (UTC)[reply]
No, I'm not trying to fix search, I'm trying to write a guideline. As I stated above there is a clear gap in policy, with Commons:File renaming referring to a non-accepted Commons:File naming page. I would be interested in hearing what you think the purpose of filenames is - my view is stated under "Purpose" - "Names are used to uniquely identify the item involved." But search visibility is certainly a consideration when choosing a filename, as are many other factors. Mathnerd314159 (talk) 20:04, 27 March 2024 (UTC)[reply]
Are you trying to write that the descriptive word part of a filename should be unique or merely the string? Enhancing999 (talk) 20:14, 27 March 2024 (UTC)[reply]
Well, clearly the string must be unique, as that is enforced by the software, but I also think that the intelligible part of the filename should be sufficient to distinguish it from other files. Like if there are "File:Duck-1.jpg" and "File:Duck-2.jpg", maybe they should have been uploaded with more detail in the filename, like "File:Duck-Cambodian Farm.jpg" and "File:Duck-Virginia Tech Pond.jpg". Mathnerd314159 (talk) 20:50, 27 March 2024 (UTC)[reply]
Well, the rule is the language / name most closely associated with the subject. So for the Columbus example, if it is an original painting of Columbus, the name most closely associated would presumably be the name the painter used for Columbus. This could be the Italian, Spanish, Latin, or Old Portuguese spelling depending on the painter's preferred tongue. I think it is unlikely that Polish would be closely associated, as Columbus never went to Poland. Also English is unlikely, although I suppose it could be argued that Columbus is a "general subject" and the English spelling is therefore justified based on popularity. For the Finnish folklore band, I would say that the Finnish name is most appropriate if no text advertising the band is visible, otherwise French is most appropriate as it would match the name present in the photo. It is certainly a bit academic - few people are going to read the naming policy, and even fewer are going to put in the effort of finding the perfect name, but I think it is important to define what would be the perfect filename if renaming was zero-cost and we could endlessly debate and argue over filenames.
I added abbreviations to the list. Mathnerd314159 (talk) 17:29, 27 March 2024 (UTC)[reply]
I think you misunderstand the problem. Many images are of general features that don't necessarily have a lanugage associated with it and we don't want English Wikipedia telling Spanish Wikipedia that English is ideal when uploading files in our Common repository. If you want to describe an ideal, don't make a guideline hindering uploads. Enhancing999 (talk) 18:44, 27 March 2024 (UTC)[reply]
How exactly would it hinder uploading? Are you seriously going to argue someone from isn't going to know the dudes name is Columbus or not be able to put it in the file name? Look at it this way, its a global project, English is the prefered language and is spoken by most people in the world. Say you have someone who speaks a niche language like Basque and they want to upload a bunch of photographs they took on trip to the United States. Sure you shouldn't name files purely to help search results, but how exactly does anyone benefit from that user uploading those images in the Basque language? The four hundred thousand other people who speak the language are the only ones who are ever to see or use the files. And yeah, there's categories, but there's also an extremely small chance anyone who speaks the language will come along and be able to properly categorize the imahes to begin with. But hey, screw litterly everyone else I guess. --Adamant1 (talk) 19:23, 27 March 2024 (UTC)[reply]
I think your comment is disrespectful, lenghty and off-thread. Enhancing999 (talk) 19:28, 27 March 2024 (UTC)[reply]
That's not really a response, but whatever. --Adamant1 (talk) 23:32, 27 March 2024 (UTC)[reply]
the premise of this discussion is still not given after a week. i see little value in any discussion. RZuo (talk) 07:49, 4 April 2024 (UTC)[reply]

I'm a native English-speaker, but there is absolutely no reason why English should be favored over any other language for filenames, especially not to "make English-language search easier" and make searching in any other language harder. We want filenames that are decently descriptive in a language the person can actually write. It's bad enough that non-English-speakers have to cope with a mostly English-language category system (where uniformity actually is important) without making them use English where another language will do exactly as well or, in some cases, better. - Jmabel ! talk 22:46, 27 March 2024 (UTC)[reply]

I should add: even as a native English-speaker I often use a different language, or a mix, in a filename when it seems more appropriate (e.g. my most recent upload as of this moment is File:Basilique Saint-Nazaire de Carcassonne from Hotel Le Donjon.jpg). I don't think there would be any gain in calling it the "Basilica of Saint Nazaire in/of Carcassone". - Jmabel ! talk 22:48, 27 March 2024 (UTC)[reply]

@Jmabel: I'd argue file names should be in the most common form for the subject and whatever allows the most people to find, categorize, or use the image. That doesn't mean I think English should be favored, but if it's a subject where the name is in English to begin with and that's what everyone knows it by then the file name should be in that language. Same goes for something having to do with Korea and being in Korean, China and being in Chinese, Etc. Etc.
I could really care less about "English" per say, what I care about is people not writing file names that confuse people and/or make it harder or impossible for them to find the image because no one speaks the language or can decipher the code. Otherwise we could rename every file having to do with Christopher Columbus to "Cristóbal Colón" and call it good. Of course we aren't going to do that, but at the same time there should at least be some uniformity and common sense in file names. Otherwise what's the point in even having them? --Adamant1 (talk) 23:32, 27 March 2024 (UTC)[reply]


Draft v2[edit]

OK, I have uploaded a new draft. It seemed to me that the minimum vs. ideal distinction was perhaps a bit duplicative of the file renaming policy. Also the navigation was a bit difficult as the bullet points were not labeled. So I have collapsed it into a long list of the form "Name - criterion". I expanded the list with criteria from other projects, e.g. Wikipedia's article title policy. It is pretty long now but I couldn't see any obvious duplication and the "mess" of criteria well characterizes the state of affairs. I also added a language-specific section as that structure was on wikidata:Help:Label and it seems clear that a criterion like avoiding articles is language-specific. I also tried to address the language issue, by taking the English-specific guidelines (e.g. wikivoyage:Wikivoyage:Naming_conventions#Romanization) and negating them (c.f. "Language preserving" bullet point). Mathnerd314159 (talk) 02:05, 30 March 2024 (UTC)[reply]

edit: I grouped the criteria so they're a little less messy Mathnerd314159 (talk) 02:59, 30 March 2024 (UTC)[reply]

Usecase[edit]

How does other users feel about maintenance categories like Category:Cosplay at FanimeCon 2023 with bad file names?--Trade (talk) 23:54, 28 March 2024 (UTC)[reply]

@Mathnerd314159 how would you go about such uploads? In terms of practical steps from files on your computer to files actually available for use on Commons? Enhancing999 (talk) 07:10, 30 March 2024 (UTC)[reply]
I would look at the file, devise an appropriate name, and upload it? I guess if it was particularly tricky I might ask on the help desk - I would describe the contents and ask what a good filename would be. Or I would upload it under a bad filename and hope someone else renames it. Mathnerd314159 (talk) 16:04, 30 March 2024 (UTC)[reply]
I don't think the initial method scales. There are 800 files in that category and if you ask 800 questions on help desk you might not get any help or even get blocked over it. So that essentially leaves you with "I would upload it under a bad filename". Can you add this to your proposed file naming policy? Enhancing999 (talk) 16:13, 30 March 2024 (UTC)[reply]
It wouldn't be 800 questions for 800 files, it would be 800 instances of devising filenames and maybe 1-2 instances of asking for help. I myself am not particularly well-versed in cosplay but presumably a skilled contributor or three could go through all of those photos and identify the specific characters involved / media referenced. So if I made a help desk post it would likely be asking for such contributors to get involved.
My guideline already mentions that existing files with bad names will most likely stay. But I don't think it is a good idea to note that new files with bad filenames can be uploaded - it might be seen as encouragement of such behavior. Repeating myself, if someone cannot be bothered to devise a good filename, they likely will not add any metadata, and it is also questionable if they will select high-quality images in the first place. Like in this case, the cosplay photos have watermarks, are not particularly high resolution, and have no metadata relevant to their content. Apparently such images are not completely forbidden but are "strongly discouraged". I'm tempted to nominate them for deletion and see what happens - the uploader does not have a particularly good track record, and it is probably less work to delete them all and re-upload specific characters that do not otherwise have photos, than it is to systematically fix them. Given that Category:Files_with_bad_file_names_by_source lists 45.8k Flickr files, I would say it is definitely too easy to use the Flickr2Commons tool and use of the Commons:Batch uploading page should be required. Mathnerd314159 (talk) 18:36, 30 March 2024 (UTC)[reply]
So practically, you want to prevent mass uploads of files where the uploader isn't sufficiently knowledgeable to devise the full description beforehand? Does this apply to Cosplay only or also to GLAMs or Flickr? Enhancing999 (talk) 09:55, 1 April 2024 (UTC)[reply]
Well, GLAMs generally have good metadata. According to the discussion below, the issue is mainly Flickr. Mathnerd314159 (talk) 20:19, 1 April 2024 (UTC)[reply]
I think you are confusing filenames and metadata, as well as uploaders and hosts. Flickr isn't an uploader. So bad file names if uploaded by GLAMs are ok? Enhancing999 (talk) 08:32, 7 April 2024 (UTC)[reply]
It's more like the rate of bad filenames. Uploading a million files from a GLAM with 90% good filenames is pretty good - the junk doesn't matter, it is mostly invisible. And in the case of a GLAM there is often a metadata field suitable for use as a filename so such a 90% rate is achievable. Uploading 10 files, all with terrible filenames, probably deserves a warning - they are wasting their time uploading junk by hand when they should be writing better metadata, and also there is the w:broken windows theory suggesting that others will follow suite. In the case of Flickr, it seems a lot of files are uploaded by various people without changing the name (or adding a description, or anything really), and most names on Flickr are bad. A consistent effort to improve Flickr uploads could have significant effects. Mathnerd314159 (talk) 01:45, 8 April 2024 (UTC)[reply]
The cosplay filenames aren't actually bad (such as misleading or fully undescript). It's unclear why GLAMs should be favored. We do have thousands of NARA files that don't meet your ideal. Enhancing999 (talk) 10:48, 8 April 2024 (UTC)[reply]
It is simply about what is practical. For the cosplay, the user went through and added descriptions by hand to the ones they knew, like for example File:Cosplay of Denji, Power and Reze from Chainsaw Man at FanimeCon 2023 (53056133958).jpg. When they were uploading, they could simply have not uploaded the files they didn't recognize. With a GLAM / mass upload, simply examining each upload could be infeasible for a single contributor.
And you are seriously saying "the cosplay filenames aren't actually bad"? You are telling me you prefer the name "Fanime-2023-05-28-0362 (53055068002)" to "Cosplay of Denji, Power and Reze from Chainsaw Man at FanimeCon 2023"? In the bad filenames, the only relevant information is "Fanime", and it is unclear what it means. I could list off more criteria one-by-one but that is the point of the guideline, to establish a metric for evaluating filenames even in the absence of obvious comparisons. Mathnerd314159 (talk) 20:55, 8 April 2024 (UTC)[reply]
I wish commons policy would forbid mass uploads with bad file names. Most of them are anyway not in use, many of those files are also just random files of whatever and they'll need to wait for years until someone appears and renames them correctly.Paradise Chronicle (talk) 16:51, 30 March 2024 (UTC)[reply]
The problem are not the mass uploads of original content or GLAM content the only often problematic uploads are mass imports from Flickr or other image hosting pages. GPSLeo (talk) 19:59, 30 March 2024 (UTC)[reply]
We could solve a good portion of the Shovelware and problems that come along with it like the bad file names just by banning mass imports from Flickr. 99% of the images from there are technically OOS, not being used anyway, and I can guarantee a lot of them would be deleted as non-educational if uploaded by regular uses. But for some reason it's totally cool to upload low quality, badly named, OOS scrap in mass as long as it is being imported from another site for some reason. --Adamant1 (talk) 04:39, 1 April 2024 (UTC)[reply]
Usage on other Wikimedia websites doesn't necessarily indicate if a file has educational value or not. I often browse bookstores and check out random books and one thing I notice is that a lot of images I didn't even consider are used in educational ways. Random photographs of streets are often placed side-by-side to explain the evolution of a town if you read the Toen en nu ("Then and now") series of picture-books that are very popular among the elderly in the Kingdom of the Netherlands. Sometimes I think that some users see the term "educational" as something very narrow where if it's outside of the idea of educational materials they can think of they can't see the educational uses of a file.
The images from SmugMug's Flickr aren't too different from those of the national archives of many countries. To me, a random image of a random candle 🕯️ wouldn't be "educationally interesting", but to someone writing a book about different types of candles found around the world such an image would be very valuable. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:13, 1 April 2024 (UTC)[reply]
That's a fair point. I'm just not a fan of how indiscriminate and uncurated (if that's the proper term) mass imports from Flickr are. Like people will just import thousands of photographs without meaningful descriptions or file names and not categorize them anywhere. Then expect us to do all the footwork to figure out what they are images of and how to organize them. It's just a very easy, selfish way of contributing to the project. On our end though we could at least have an approval process for mass imports from other websites like Flickr. I'm totally against them, but there should be some kind of oversight and the person doing them shouldn't just be able to dump a bunch of images on here and expect everyone else to do the work of sifting through them. --Adamant1 (talk) 05:29, 1 April 2024 (UTC)[reply]
There I agree with you. If Universities and Museums upload their content, it is great, but those files usually also have a good filename and if that is missing at least a good description. But mass Flickr uploads are usually just a problem.Paradise Chronicle (talk) 08:20, 4 April 2024 (UTC)[reply]
@Adamant1@Paradise Chronicle@Mathnerd314159 or better still, which may also solve COM:SCOPE debates and also reduces possible no-COM:FOP infringements: why don't we limit importation of Flickr files to just one file per import session? That will enforce discipline among all average users. Batch uploading may be allowed if the user conducting Flickr importation is a sysop/admin. JWilz12345 (Talk|Contrib's.) 23:11, 7 April 2024 (UTC)[reply]
I won’t support Sysop/Admin batch uploading only, trusted users should also be allowed to batch upload. Bidgee (talk) 23:17, 7 April 2024 (UTC)[reply]
@Bidgee perhaps extend to autopatrolled? (But yes, this may be a separate proposal for a new thread here.) JWilz12345 (Talk|Contrib's.) 23:55, 7 April 2024 (UTC)[reply]
That sounds like a great idea. I'd probably support extending it to autopatrollers. Although I agree it's probably best for another proposal. --Adamant1 (talk) 00:07, 8 April 2024 (UTC)[reply]

Final voting[edit]

Since feedback on my v2 draft was limited to one "thank", and comments on the first draft were generally positive, I have updated the main proposal page with my draft. This gives it better visibility and I think the overwrite is also an improvement as the voting on the old proposal was much less positive. I would say the proposal is "provisionally" final - someone could bring up new concerns, but I think all mentioned concerns have been addressed, besides enforcement w.r.t. Flickr imports, but guidelines generally do not include the enforcement process. So the main question now is whether it can become an official guideline. Mathnerd314159 (talk) 05:07, 7 April 2024 (UTC)[reply]

 Support confirm support. Paradise Chronicle (talk) 14:28, 7 April 2024 (UTC)[reply]
 Support, though I've made some edits. You can revert if you dislike them. - Jmabel ! talk 15:29, 7 April 2024 (UTC)[reply]
 Oppose Still has issues that will cause more problems than it solves. “Consequently, new uploads should aim for the highest-quality filenames.” Big expectation and will differ depending on people’s opinion of certain file names.
in the Content-based “Names consisting solely of dates, the name of the photographer or rights holder, and/or words like “Flickr”, “original”, and “crop” are forbidden.”, overly vague (should have an example of what is and isn’t acceptable) and makes it sound like those should never be used when in cases it might be. Bidgee (talk) 16:14, 7 April 2024 (UTC)[reply]
"will differ depending on people’s opinion": the point is that by establishing objective criteria for filenames, it will not depend on opinion. I suppose "highest-quality" is maybe too optimistic and I could instead say to aim for mediocre-quality filenames that are at least not terrible, or else to recommend spending between 10 and 30 seconds deciding on a filename (or some other range) – would either of those be better?
Content-based: This is from criterion 2 for renaming, "meaningless or ambiguous name", a widely accepted guideline. I added some examples. Mathnerd314159 (talk) 19:53, 7 April 2024 (UTC)[reply]
While "meaningless or ambiguous name" in renaming has existed, it has also had its problems due to it being broad and subjective (as explained below, regarding "highest-quality filenames"). There have been times where I have used the camera file name for photographs that I took a large number of photos for (i.e. File:Harvey Hay Run 2020 convoy on Hammond Ave in Wagga Wagga (IMG 4705).jpg, File:Holden vs Ford track challenge at the 2012 Wagga Wagga Show (IMG 3146).jpg and File:Coulson Aviation (N137CG) Boeing 737-3H4(WL) at Albury Airport (IMG 4039).jpg), having it makes it easier to locate the RAW file to make new modifications/fixes if needed. Bidgee (talk) 22:41, 7 April 2024 (UTC)[reply]
@Bidgee: how is "aiming for the highest quality" in any way controversial? - Jmabel ! talk 20:40, 7 April 2024 (UTC)[reply]
Because it is subjective on what a "high-quality" file name is. Example is File:Helicopter A109LUH(NZ) by the NZ Defence Force.jpg, my view is should have been named File:Royal New Zealand Air Force (NZ3402) Agusta A109LUH(NZ) post maintenance flight.jpg, should "by the NZ Defence Force" be in the title? That is subjective also. Bidgee (talk) 22:30, 7 April 2024 (UTC)[reply]
@Bidgee: what is an example where (for example) just "Flickr" and the name of the photographer would be an acceptable file name? Or some other combination of the things in this list? - Jmabel ! talk 20:41, 7 April 2024 (UTC)[reply]
I never said just Flickr or the photographer as the file name. I'm saying they have their place and it doesn't make it clear as it was written but I can see the example given by Mathnerd314159 is exactly what I had been concerned about. Use of "original" and "crop" has its place, I use "original", when I have uploaded an almost unmodified version (separate) File:NT Police Speed Camera Unit (original).jpg (uploaded in 2012) that is different to the modified version File:NT Police Speed Camera Unit.jpg (uploaded in 2008). Then there are times that I have or others have cropped (File:Baby Latrodectus hasselti cropped.jpg) the original (File:Baby Latrodectus hasselti.jpg) file. Bidgee (talk) 22:21, 7 April 2024 (UTC)[reply]
Just in looking, when uploading a modified version of a file, it is typical to use the original's filename and modify it for the upload ("cropped", "2", "3" "altered", etc.) Sometimes multiple versions are uploaded for choosing on feature picture nominations. Calling that practice "forbidden" now is definitely not correct -- this is a guideline I assume, not policy, and I certainly would not want to use this as justification for mass renaming of existing files. Maybe say "discouraged", at most, but once a filename exists then modifications using that as a base seem fine. Carl Lindberg (talk) 22:57, 7 April 2024 (UTC)[reply]
The point is to forbid filenames that consist solely of such identifiers. It is fine if they are there, just not if there is nothing else. I already have a whole sentence "It is not forbidden to include such information" so I am not sure what else would make this clear. Mathnerd314159 (talk) 23:05, 7 April 2024 (UTC)[reply]
Well it implies that, as does the example file name (noted above). Bidgee (talk) 23:19, 7 April 2024 (UTC)[reply]
@Bidgee: I think you may simply be misreading (and I don't know what "example file name (noted above)" you are referring to, since there have been numerous filenames on this page). The sentence you quoted begins, "“Names consisting solely of…" (emphasis mine), but you seem to be flatly saying that it is an exclusion of using these things at all. If I say, "I won't eat a meal consisting solely of broccoli," it doesn't mean I won't eat broccoli. - Jmabel ! talk 14:07, 8 April 2024 (UTC)[reply]
Really? This reads nothing like a guideline. "This page is designed to aid uploaders in selecting proper names for their files, promoting standards of excellence in filename conventions." We are not a university, the guideline should be about helping uploaders to select/pick filenames that are ideally appropriate/suitable. "It is important to note that while this page provides recommendations for creating high-quality filenames, the recommendations are not intended to serve as standalone justification for renaming files." Drop "high-quality" and replace with "suitable" and why do we need to repeat "recommendations" twice? "... balancing the principles outlined here with the costs of renaming files. In general, the costs of renaming are significant, so Commons aims to provide stable filenames and renames are limited." Why use "costs"? And how is it "significant"? Renames are not limited, just recommended not to be done too often. Keep the guideline simple (like Commons:Image annotations, Commons:Galleries), not complex, since it currently reads like a policy. Bidgee (talk) 05:16, 11 April 2024 (UTC)[reply]
OK, I guess the phrasing was a little over-the-top. I have addressed the issues you mention, besides complexity (w:WP:MOS is a lot more complex). In the future you can be bold and fix it yourself, I won't mind. Mathnerd314159 (talk) 05:35, 11 April 2024 (UTC)[reply]
 Support I still have a few issues with the whole thing myself, but Perfect is the enemy of the good and overall this seems like a good proposal. Some guidance on how to name files is clearly better then none. The few objections just seem like nitpicking, or at least things that can be ironed out later. You can't really iron out a guideline that doesn't exist in the first place though. --Adamant1 (talk) 00:12, 8 April 2024 (UTC)[reply]
 Strong oppose: One seldom sees in Commons so many bad ideas bundled toghther with so much support from otherwise serious users. -- Tuválkin ✉ ✇ 23:35, 8 April 2024 (UTC)[reply]
I am a bit confused. I believed, it was quite an improvement. Then what would be your suggestion to prevent uploads like this or this, there are several more of those... They were uploaded in 2020, with ambiguous filename, received a Basel category in 2022, and I eventually moved it to Nature in Basel in 2024. I don't know where in Basel there is such a landscape, its a city and there is not much nature. Or this one with simply Zurich, panoramio and numbers in the filename, uploaded in 2017, received a Zurich category in 2017 and was eventually moved to Nature in Zürich by me in 2024. We still don't really know where it is, what it shows etc. There is a problem with identification and I'd be glad if we could find a solution together. Paradise Chronicle (talk) 23:52, 9 April 2024 (UTC)[reply]
Can you elaborate on these "bad ideas"? Mathnerd314159 (talk) 00:19, 10 April 2024 (UTC)[reply]
No addressable / transparently-explanatory reasons have been given here so this is anything but a "strong" oppose. Agree with Paradise Chronicle but there are way worse filenames than PD's examples like "Jmse-10-01816-g001-550 hor.jpg". Prototyperspective (talk) 11:57, 14 April 2024 (UTC)[reply]
  •  Comment This looks OK for best practice, but it should not be required (guideline, not policy). We basically have five redundant descriptions of the files - the filename, the categories, the caption, the description, and the structured data. Of those, I would argue that the least important is the filename, and the most important the categories, since that's how people currently find files (although that will hopefully transition to structured data in the long term). I reflect this in my uploads - since I upload a lot of files using batch uploading, giving them quite generic filenames (such as 'At Singapore 2023 001') is the most efficient way to get them uploaded to roughly the right place, and after that point my time goes into categorisation/use/QI. Requiring filenames to be more detailed would be a huge blocker to my workflow, although I never object to people renaming my uploads if they want. Thanks. Mike Peel (talk) 17:58, 9 April 2024 (UTC)[reply]
    Did I not say in the beginning "the main question now is whether it can become an official guideline"? I was never proposing this to be a policy. Even Commons:File renaming is not a policy. Mathnerd314159 (talk) 20:41, 9 April 2024 (UTC)[reply]
    There's too much text to easily spot that, but I've happily changed this from oppose to a comment on that basis. Thanks. Mike Peel (talk) 20:57, 9 April 2024 (UTC)[reply]
    It does read the contrary on the page itself and it would still be a guideline GLAMs and users like @Mike Peel are expected to follow. An alternative could be to make an essai somewhere, e.g. MAthnerd's user namespace. Enhancing999 (talk) 21:18, 9 April 2024 (UTC)[reply]
  •  Oppose as per Tuválkin. This all seems like a terrible idea. Strakhov (talk) 21:23, 9 April 2024 (UTC)[reply]
    Could you elaborate on this? In my opinion filenames such as File:-i---i- (3042676940).jpg or File:"1JahrNurBlockiert", Demonstration von Fridays For Future, Berlin, 13.12.2019 (49239439091).jpg are not really helpful, both have multiple duplicates that (I believe, haven't checked all) only vary by a number. Also no helpful descriptions are there. Paradise Chronicle (talk) 16:52, 11 April 2024 (UTC)[reply]
  •  Oppose This proposal does not solve a single problem that, to my knowledge, is not already regulated elsewhere or covered by the renaming rules. Instead, it creates additional hurdles and complicates things further, which will deter many potential uploaders. In addition, such a collection of rules will be used by some regulation and order fanatics as justification for enforcing their own ideas against the wishes of those contributors or creatives who are responsible for the actual content in the media sector, thus causing resentment, disputes and completely unnecessary extra work. --Smial (talk) 12:13, 10 April 2024 (UTC)[reply]
There will be less disputes and extra work if file names are "correct" to begin with. --Adamant1 (talk) 14:35, 10 April 2024 (UTC)[reply]
You are never going to avoid the need for renaming and naming disputes, with or without a File name guideline. Bidgee (talk) 05:18, 11 April 2024 (UTC)[reply]
Sure, but disputes can be greatly reduced, if not totally mitigated, by having guidelines. Instead of people just endlessly bickering about something because we can't be bothered to give people guidance on the best way to do something or how to do it properly for some bizarre reason. --Adamant1 (talk) 06:57, 11 April 2024 (UTC)[reply]
 Support Very much support proper filename guideline. Details could be discussed there but as far as I can see things are fine. I do object to "When it comes to organisms and biological subjects, the scientific (Latin) name is recommended." even though it's just a recommendation. I think the most widely and most reasonable name should be used (except if incorrect/inaccurate). For example the word kidney should be used over phrases with "renal". Prototyperspective (talk) 00:06, 12 April 2024 (UTC)[reply]
The Latin recommendation is from Commons:Galleries#Naming conventions, "An exception to this rule is the naming of galleries of organisms and subjects where Latin names are considered universal." And then I added "biological" as the grammar was a bit strange and I couldn't think of any other "subjects where Latin was universal". And then "scientific" came from w:WP:COMMONNAME, where there is a note "Common name in the context of article naming means a commonly or frequently used name, and not necessarily a common (vernacular) name, as opposed to scientific name, as used in some disciplines." It is certainly something worth discussing. Like there is the w:Terminologia Anatomica, using it as a systematic naming scheme for files would be good, but nobody uses it so it would be hard to adopt. For now I have changed "biological" to "botanical". As w:WP:FLORA says, in the vast majority of cases, the most common name will be the current scientific name. In the cases where it isn't, I expect the common name would not translate. Mathnerd314159 (talk) 03:53, 13 April 2024 (UTC)[reply]
@Mathnerd314159: We have other biological names than botanical ones, so I oppose your change from "biological" to "botanical".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:12, 13 April 2024 (UTC)[reply]
You write "so I oppose" but you didn't give any reason and didn't address the one I gave. People understand and search for certain things like kidney cancer and a few people use some words of a dead language the vast majority doesn't know, search for, or understand. Prototyperspective (talk) 13:18, 13 April 2024 (UTC)[reply]
@Prototyperspective: I gave a reason. Latin is not dead in biological names, or binomial if you prefer. Thus saith a Homo Sapiens Sapiens.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:37, 13 April 2024 (UTC)[reply]
Google is pretty clear that binomial names apply to "animals and plants" and "organisms". Indeed Homo sapiens qualifies as an animal and an organism. You have not given any examples of binomial names that are not organisms or plants. Mathnerd314159 (talk) 15:44, 13 April 2024 (UTC)[reply]
@Mathnerd314159: I will stick with "biological".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:04, 14 April 2024 (UTC)[reply]
And it doesn't mean people can't use the word renal or "cat" instead of "Felis catus". There needs to be some guidelines for descriptive useful filenames but at the same time it shouldn't be overprescriptive. Prototyperspective (talk) 13:36, 13 April 2024 (UTC)[reply]
Perhaps the word you want is "taxonomic"? - Jmabel ! talk 14:03, 13 April 2024 (UTC)[reply]
I don't know if you are you replying to me. No, images like "A cat catching a mouse.png", "Three people operating a robot.png", or "Statue of a dog.png" etc should not be recommended to be called "Felis catus catching a Mus musculus.png", "Three Homo sapiens sapiens operating a robot.png" and "Statue of a Canis lupus familiaris.png".
Categories and file descriptions can be used for that and they can still be named like that without this being in the guideline. This is absurd and partly because Jeff has still not given any reasons for the objection, I won't continue debating this which would just produce a walls of empty text. Prototyperspective (talk) 15:03, 13 April 2024 (UTC)[reply]
@Prototyperspective: you are making a straw man argument. Presumably no one would prefer those file names, especially insofar as they refer to very common species (especially homo sapiens). Personally: I'm still normally going to say "gull" rather than larus, but if I know for sure I've got a Larus fuscus I might well use the species name rather than "Lesser Black-backed Gull." - Jmabel ! talk 06:24, 14 April 2024 (UTC)[reply]
This whole thing about using species names or not seems rather tangential. Is there a reason it can't be ironed out or further clarified after the guideline is implemented (assuming it is. Otherwise, the conversation doesn't really matter anyway). --Adamant1 (talk) 06:48, 14 April 2024 (UTC)[reply]
Not a strawman but showing how ridiculously bad these specific proposed recommendations are. What's in your mind regarding common sense does not undo what's on paper/text. As Adamant1 said, those things can still be fleshed out later on and I support the guideline for adoption except for this part. Prototyperspective (talk) 12:01, 14 April 2024 (UTC)[reply]

Usecase 2: COA[edit]

What's the impact for coats of arms? I see many replaced by files names "USA place COA.svg" like names. Is the general idea that people can continue uploading and we just have a guideline that suggests how they could do it better? Or just we terminate accounts and projects that don't follow it? Enhancing999 (talk) 08:35, 7 April 2024 (UTC)[reply]

In my opinion editors should of course keep on uploading, but uploaders who in the past used bad/serialized filenames will now be able to get suggested that they should use more adequate filenames. In the past I was also reverted as I added some files into a bad filenames category.Paradise Chronicle (talk) 15:06, 7 April 2024 (UTC)[reply]
The obvious impact would be that Commons:WikiProject Heraldry and vexillology#Naming of files would no longer say "There is no Commons standard for file naming", rather it could link to the guideline. (And I guess that would incorporate Wikivoyage's guidelines for place names by reference, which seem quite relevant here). And as you say, @Sarang seems to have made "LLL unitname COA" the recommended pattern - the "spelled-out" criterion would recommend expanding COA to "Coat of arms", and the concision criterion would recommend putting the place at the beginning. So I would say "Coat of Arms, Place, LLL" or "Place Coat of Arms (LLL)" are better naming schemes, more similar to the French and Italian styles. Mathnerd314159 (talk) 20:43, 7 April 2024 (UTC)[reply]

Usecase 3: Several images in some photo contests[edit]

The proposal may be more suitable in the case of randomly-named image files that were submitted in some photo contests. Examples are the following image files that were submitted in the more-recent (like 2020s) editions of the Philippine leg of Wiki Loves photo contests, mostly organized by meta:PhilWiki Community:

The images themselves are good in terms of resolution and quality, but they have obscure file names. "File:Coastal lake.jpg" remains unidentified to the point that I cannot categorize it properly. For "File:Humbled by the Mountain.jpg", I resorted to asking the photographer off-wiki (on Messenger) just to determine the specific mountain for categorization purposes. Some file names do not exactly describe the images but only describe them in poetic or flowery sense, which I think should not be acceptable as hindering proper categorization and usability of files. JWilz12345 (Talk|Contrib's.) 02:22, 10 April 2024 (UTC)[reply]

@Enhancing999 and @Paradise Chronicle, here is the third usecase. JWilz12345 (Talk|Contrib's.) 07:10, 11 April 2024 (UTC)[reply]
If anyone wants another example check out the files in Category:Images misdescribed as postcards. In that case there's a bunch of normal photographs that someone decided to name as postcards for some reason when that's clearly not what they are images of. There's no legitimate reason files should be named that way to begin with though. --Adamant1 (talk) 07:18, 11 April 2024 (UTC)[reply]
I'm not saying files shouldn't have descriptions, categories, annotations or structured data to describe the images. Quite to the contrary. The samples here lack much of it. Weirdly people may support the above proposal or complain about it, but don't bother adding or fixing them. Commons is also platform for collaboratively describing images.
File:A Blooming Flower.jpg as name avoids problems we on project chat with some species database. Photographers may not be biologists and should be able to upload images without consulting one before. When even specialists get the species wrong, other information (photographer, id, date, location) would be the more stable filename.
Interestingly, I don't think the guideline specifically addresses more abstract descriptions (such as "Humbled by the Mountain"). Enhancing999 (talk) 09:24, 11 April 2024 (UTC)[reply]
Such a description is fine, actually it is encouraged by the "correct" guideline ("The title given to a work of art by the artist that created it is considered appropriate"). The only issue is that it is a photo of a place without enough specific or precise information to identify the location. So if it was "Humbled by the Mountain (Tenglawan)" it would be better. Mathnerd314159 (talk) 15:26, 11 April 2024 (UTC)[reply]

Proposal for history maps template[edit]

Hi, if you are interested in "Maps of the history of Europe/Asia/etc" and the template(s) that could provide more order among its subcategories:
Please feel invited to participate in Template talk:Subject by century#Proposal.
Proposed features:

  • New navigation template for "history maps" - well, those that are sorted by region/country, and then by century. Such a template is currently not existing.
  • Switching naming standard from "Maps of 17th-century France/India" --> "Maps of France/India in the 17th century" (for all history-showing "maps of X in Yth century")
  • How to group current and historical countries regionally, within the template (adaptable later)

Hope to see you there. Bring some time and long breath: I don't expect we will wrap up this open topic soon. Also, ancient history is unlikely to be covered, I think we can start with 5th century at the very earliest, but I am rather optimistic about the structure in 12-14th century onwards. --Enyavar (talk) 19:58, 24 March 2024 (UTC)[reply]

Creation of an AI bot to add structured data to files[edit]

Note: I know that most things regarding AI are controversial right now (and for good reason in many cases), but I still think this is an idea worth considering. Also, AI being able to correctly identify items in a photo is still in its infancy, so this is a more long-term proposal/idea.

I hope all is well! AI technology has seen many advances in the past few years, including the ability for it to identify objects in photos. My proposal, simply put, is to create a bot, which uses some form AI, to add and/or adjust current structured data on files. It would mainly identify what is portrayed, from the main parts to the smaller items in a photo, using an identification algorithm, but it would also use the categories included on the file page to also identify object. Structured data is very underused on Wikimedia Commons, but it has wide-ranging effects on how a file is viewed and seen by humans and bots alike. To show an example using this picture, it could quickly deduce that water, glass, sidewalk, skyscraper, etc. are pictured, but then, using categories and possibly text included on its file page, it could deduce that the prominent part of the picture is City Hall, London (Newham), not just a random building, and depending on its knowledge of location, it could tell that the London cable car is pictured, and not just a random structure. Importantly though, it would not adjust anything on an image's file page, including its categories, captions, or descriptions.

I can think of some general reasons why it would be useful for day-to-day use on Wikimedia Commons (not organized in any order):

1. Structured data is mainly used by programs to sort images correctly and properly on the website; so using a computer program to identify structured data would reduce the possibility of lost data due to human error (i.e. it would know what to look out for more in images than humans adding the structured data).

2. It would improve the search engine of Wikimedia Commons, which can sometimes struggle when searching for a broad term or terms with multiple meanings and/or parts.

3. It would allow copy editors, file patrollers, admins, etc. to focus on more important things. As well as that, it would reduce the possibility of new editors incorrectly tagging files (or just skipping the process altogether).

4. Structured data is not like categories, mainly because it doesn't need to be filed into smaller subsections (e.g. using that image again, the term "water" isn't filed under something like "waterways in England"). Though, its identification algorithm could always be fine-tuned to better decide what should or shouldn't be tagged.

If this idea was to be further investigated and approved, I also propose that it be introduced to the community gradually. It could start as an opt-in program, in which users, who approve its use, would allow for it to edit the structured data on their uploaded files only. Then it could go to being automatically used for files uploaded by new users, then older files without structured data. Basically, the AI bot could either be turned into an automatic program like SchlurcherBot or BotMultichillT, or it could stay a permanent opt-in setting in the preferences tab.

Thank you for your time and consideration; I'd be more than happy to answer any questions. Have a great day! -- DiscoA340 (talk) 22:20, 24 March 2024 (UTC)[reply]

What you're describing sounds a lot like the Commons:Structured data/Computer-aided tagging project, which was an abject failure. You may want to review how that system worked and why it failed. Omphalographer (talk) 01:16, 25 March 2024 (UTC)[reply]
Strong oppose per the abject failure (exactly the words I would use as well) of the computer-aided tagging project. - Jmabel ! talk 09:09, 25 March 2024 (UTC)[reply]
Wasn't that AI centuries ago implemented in a suboptimal manner (i.e. mixed with manual edits)? Enhancing999 (talk) 09:18, 25 March 2024 (UTC)[reply]
The fact that it required users to manually approve edits was probably the only thing protecting it from adding even more bad tags, like tagging pictures where the sky is visible with "depicts: blue", or tagging logos with "depicts: graphics". Omphalographer (talk) 17:59, 25 March 2024 (UTC)[reply]
SD/CAT was apparently set up before 2020 and ran (amok) until 2023. "AI" has developed quite a bit since that time: Midjourney went online in 2022-07, ChatGPT in 2022-11, and has since undergone multiple revisions. Now, there is no documentation available, which advancements SD/CAT went through, but I am certain that we (well-meaning enthusiasts) cannot compare with the tech giants who don't seem to think their "AI" is an abject failure.
I think that a new attempt should at some point be started: some general  Support from me. Although I am still sceptical and don't have any interest in getting involved myself. And yes, a review why the SD/CAT project failed is crucial, before committing the same errors again. Sadly, there is no such review readily available on the linked project page. --Enyavar (talk) 09:25, 25 March 2024 (UTC)[reply]
The biggest problem with SD/CAT was that it had no idea what was important for Commons categorization, so it was constantly proposing useless categories ("tree", "stop sign", "building", "person" etc.), often for images that were already well categorized. Yes, AI has advanced, but try feeding an image to even an excellent present-day AI to describe verbally, and then think about how far that description is from actually useful Commons categories. - Jmabel ! talk 11:15, 25 March 2024 (UTC)[reply]
Yes, the category tree is way too detailed for any so-called AI. Good thing: Disco's proposal idea talks about structured data (i.e. tagging), not about categories, except to use the existing categories of a file for better tagging. Myself, I only categorize as deeply and intricately as possible, I don't touch the SD-interface with a ten meter selfie stick if I can help it... But I think there are people who'd like to improve the state of SD, and this could be a way. --Enyavar (talk) 13:52, 25 March 2024 (UTC)[reply]
The tags suggested by "computer-aided tagging" were actually exactly that: tags, not categories. Also they didn't fit into what is expected in SD as a "describes"-statement (whatever that actually is). Maybe we would just need a search interface that can work with such "tags". Enhancing999 (talk) 10:00, 27 March 2024 (UTC)[reply]
instead of trying to build something close to an AGI, how about doing a simple task first?
  1. tag the faces for Category:Unidentified people.
  2. further, identify any pics with human faces that have not been tagged, and then tag them.
RZuo (talk) 13:58, 25 March 2024 (UTC)[reply]
I don't think that would be appropriate. There are a lot of images on Commons which include people but which deliberately don't identify the individuals, either because that's unknowable (e.g. photos of street scenes), or because the subject(s) of the photo would prefer to remain anonymous. Omphalographer (talk) 18:07, 25 March 2024 (UTC)[reply]
then those images should not have been in Category:Unidentified people in the first place. what you said is never a problem of the tool, but of correct categorisation. RZuo (talk) 07:40, 4 April 2024 (UTC)[reply]
@RZuo: I'm not sure I follow that. The fact that someone is not identified does not inherently mean identification would be either possible or welcome. - Jmabel ! talk 10:15, 4 April 2024 (UTC)[reply]
you dont know commons' maintenance practice about the whole tree Category:Unidentified, is it? RZuo (talk) 16:07, 4 April 2024 (UTC)[reply]
  •  Oppose I want to see a specific proposal with a narrow, defined scope - like we'd see in ordinary bot requests. Blanket authorization without those details is a recipe for trouble. The Squirrel Conspiracy (talk) 00:37, 28 March 2024 (UTC)[reply]
  •  Support Commons SD has always been animated with the spirit of “machine readable” data (the 1970s called wanting their terminology back) versus the purportedly messy “legacy” of categories and templates. Well, I want to see this proposal greenlit, so that humans can go on working unimpeded while brainless bots and their likewise fans go on piling up more and more detritus onto their huge GIGO machine. -- Tuválkin ✉ ✇ 00:58, 28 March 2024 (UTC)[reply]
  •  Oppose And strongly per Jmabel and The Squirrel Conspiracy. You can't just make a blanket bot request. And how is this going to be any different or better then the abject failure that we already had attempting to automatically add structured data? Don't tell it would be different "because AI technology" either. If anything AI would just be worse. Otherwise I'd like to see some actual examples of AI being used to do add structured data on other projects has worked out well. We shouldn't be a test bed for new, untested technologies regardless of the potential benefits structured data might provide us though. --Adamant1 (talk) 23:27, 29 March 2024 (UTC)[reply]
  • The quality we need for Commons seems not to be possible with currently available machine learning tools. I would really like to get a tool that could calculate the view direction of an image based on the location and the time as this is the most crucial and difficult task when identifying what is depicted on the photo. But this is a task not even the tools of companies with many billions of dollars could manage. There is not even a tool that identifies photos of buildings when there is Google Street View data available of the building. We definitely do not have the capacity to build such tools. GPSLeo (talk) 11:18, 30 March 2024 (UTC)[reply]
 Oppose, if this is a step towards retirement of all categories. One thing about the usefulness of categories is that these help to track possible violations of copyrights that are subsisting in the images, especially images of France, South Korea, Ukraine, Indonesia, Greece, Slovenia, Lithuania, and most other so-called republics or democracies that do not provide commercial Freedom of Panorama. We tag categories of problematic landmarks with {{NoFoP-category}}, which makes tracking and hunting files down easier. Can the structured data provide similar mechanism that enables users to track and hunt down files that may show copyrighted public monuments? May or may not be, but may not be easy (Visual File Change currently works in categories, not structured data). Note that there are also other derivative works issues, many of which are appropriately warned in the relevant categories, like those of contemporary toy brands, characters, and 20th/21st-century painters and sculptors. JWilz12345 (Talk|Contrib's.) 10:18, 1 April 2024 (UTC)[reply]
(??) Nothing in the proposal hinted towards "retirement of all categories", though. Instead, it sounds that working+existing categories are seen as the prerequisite by the proposer, and also that they intend to help users to focus on more important work. Myself, I don't "tag" or do anything with structured data, because I am a firm believer in categories as well. So the daily work of users like you and me is unlikely to be affected at all, I'd say. --Enyavar (talk) 20:21, 1 April 2024 (UTC)[reply]
@Enyavar just ask one supporter above (Tuvalkin) who suggested retirement of what they called "messy" category system in favor of structured data. JWilz12345 (Talk|Contrib's.) 23:05, 1 April 2024 (UTC)[reply]
I think you're missing a bit of sarcasm in that comment. Omphalographer (talk) 06:17, 2 April 2024 (UTC)[reply]
It’s not even sarcasm: I said «purportedly messy» and JWilz12345 misquoted me as having said only «messy». With this kind of natural intelligence around, who needs the artificial kind? -- Tuválkin ✉ ✇ 06:46, 2 April 2024 (UTC)[reply]
@Tuvalkin: are you implying I have a low IQ? "Purportedly" is some kind of weasel word, but I think you want to tone down your opposition to the "categories" system by the use of that word. I won't entertain your further false accusations of false IQ against me, using indirect words (weasel words and implicit claims). @Omphalographer: , the user already said it is not a sarcasm. JWilz12345 (Talk|Contrib's.) 10:38, 2 April 2024 (UTC)[reply]
@JWilz12345: I will presume your IQ is fairly high, but the point of "purportedly" in a structure like Tuvalkin used is to suggest that someone else purports it to be so, not to endorse the claim; rather the opposite, in fact. - Jmabel ! talk 17:26, 2 April 2024 (UTC)[reply]
Indeed, and to ellaborate: My support of this proposal is not mere “rage against the machine” (ha ha) or a way to troll those I think are not steering this project in the right direction. While I personally would do away with all of this, with the whole concept of structured / machine-readable data, which I consider a giant GIGO machine, my view is this: Since the “depicts” statement was meant as a (ironically) unstructured tagging system for random one-time contributers to use in a gamified, non-involved way, implicitly directed to mobile users — then adding A.I. to that brainless, tentative, stochastic (mis)curation is the logical next step. I expect it become a cancerous mess akin to the keywords one can find in Alamy or Getty, and A.I. would simply get us there faster. That will/would vindicate those who think this is a huge misstep without contaminating serious Human curation made via categories and templates, and will/would, I think, also make happy those people up in the WMF foodchain who would marvel to type in "puppy" in the search bar and be granted with a pageful of puppy images, and feel their work is done. In short: A.I. in S.D.? Yes, please and pass the popcorn. -- Tuválkin ✉ ✇ 20:35, 2 April 2024 (UTC)[reply]
@Tuvalkin: Do you really think there's no value to structured data what-so-ever? I can't think of any examples right now, but I've been under the impression that it would allow certain things down the line once we fully implement it that can't be done currently for whatever reason. --Adamant1 (talk) 10:25, 4 April 2024 (UTC)[reply]
Category:Damaged clocks. -- Tuválkin ✉ ✇ 23:39, 9 April 2024 (UTC)[reply]
If, based on what I said above, you think that I am in any shape or form in «opposition to the "categories" system», then you told me all I need to know about your IQ. -- Tuválkin ✉ ✇ 20:23, 2 April 2024 (UTC)[reply]

Proposal of dual naming convention for galleries[edit]

According to COM:GAL, the naming convention of galleries is very different from the naming convention of categories. Galleries tend to use local names, while categories tend to use English names. This may cause problems with many users who don't understand the local language (for example, you won't know that কলকাতা মেট্রো is about the Category:Kolkata Metro unless you know the local language or have opened the gallery in question).

Therefore, I propose to use dual naming for galleries in the format "[English name] / [local name]". Such dual naming should be used if not more than one non-English local language is associated with the subject. For example, Москва would be renamed as "Moscow / Москва", while India will remain as it is because India is not associated with a particular language. I have seen many galleries that already use dual naming (like New Zealand / Aotearoa, Delhi - दिल्ली). I'm proposing to use slash for dual naming instead of hyphen because slash is more common in such naming. --Sbb1413 (he) (talk • contribs) 18:13, 29 March 2024 (UTC)[reply]

  • Support with English / Local. Very good idea! --SergeWoodzing (talk) 19:06, 29 March 2024 (UTC)[reply]
  •  Oppose IMO gallery names should closely, if not exactly, follow the names of categories. And having multiple languages in a single gallery name is needlessly convoluted. Why not just use redirects? There's no reason there can't be a gallery named "Москва" that redirects to a gallery called "Moscow" or visa versa. That's essentially what redirects exist for already. --Adamant1 (talk) 23:31, 29 March 2024 (UTC)[reply]
    Users don't always browse galleries through the search engine. They can also visit galleries through the corresponding categories. If a gallery is named in a non-Latin alphabet, users will have a hard time looking for that gallery from the corresponding category. I think my proposal should be limited to local languages using a non-Latin alphabet. Sbb1413 (he) (talk • contribs) 04:03, 30 March 2024 (UTC)[reply]
Maybe I'm just misunderstanding what your saying, but wouldn't it be a non-issue if someone is visiting the galleries through a corresponding category regardless of what it's named because galleries show up in the "This category contains only the following page" section of the category? Like if I go to Category:Postcards published by Frank Patterson there's a link to the gallery Postcards published by Frank Patterson in the pages section, which would obviously be for postcards published by Frank Patterson regardless of what the actual name of the gallery is. Otherwise it wouldn't be in Category:Postcards published by Frank Patterson. No one is going to mistakenly think it's a gallery for images of cats no matter what it's called though. --Adamant1 (talk) 04:18, 30 March 2024 (UTC)[reply]
But as a side to that, I still think it's helpful if the names of categories and galleries closely match each other for easier entering in the URL bar. I don't think it's helpful if people have to remember when a gallery has multiple names in different languages or special characters if they just want to get there by way of the raw URL. --Adamant1 (talk) 04:23, 30 March 2024 (UTC)[reply]
  •  Comment, personally, I think that the best solution would be to have the MediaWiki software updated to recognise page titles (preferably through Wikidata) and then translate those titles based on the language a user is searching in. The main gallery name would be in English, the alternative titles would be redirects, and then if you have your standard display language in Russian you'd see all titles in Russian. This would be technically feasible and the current issues with galleries can be considered to be a technical issue rather than a policy issue. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:21, 1 April 2024 (UTC)[reply]
    I have created {{LangSwitch title}} as an experiment to show the page title on the user's preferred language. However, it looks like {{DISPLAYTITLE}} does not work in Commons, otherwise the title of the gallery India would display as ভারত in Bengali and भारत in Hindi. Unless there's a long-term solution to internationalization of page titles, the best we can do is to use English in gallery names and dual "English / Local" in galleries. Sbb1413 (he) (talk • contribs) 06:50, 1 April 2024 (UTC)[reply]
Have you thought about filing a Phabricator ticket? I have to agree with Donald Trung that it should be a technical issue instead needing a change to policy. Especially if we haven't even tried technical fixes yet. Regardless, I think Donald Trung's solution makes sense and you could also see about them supporting {{DISPLAYTITLE}} in Commons. It would probably be worth supporting anyway. --Adamant1 (talk) 08:45, 1 April 2024 (UTC)[reply]
DISPLAYTITLE works fine on Commons. However, I think wgRestrictDisplayTitle is turned on, so it may just be for formatting, and not changing the title -- if a "normalized" version is not the same as the actual page title, it may be ignored (Category:Pages with ignored display titles). Currently, the LangSwitch template in that gallery is returning the text "LangSwitch Error: no default" so there may be multiple issues. Carl Lindberg (talk) 05:47, 2 April 2024 (UTC)[reply]
under what circumstances will a user see "কলকাতা মেট্রো" without opening the gallery page? RZuo (talk) 07:37, 4 April 2024 (UTC)[reply]
  •  Comment I have a sneaking suspicion that by 'galleries' you mean the FP Galleries. Using the 'slash' as in "[English name] / [local name]" for the gallery pages would be very bad since it will coincide with how the addresses (wiki and http) are written for the gallery pages (and other pages). Example: Commons:Featured pictures/Places/Natural/New Zealand. We have bots sorting the images into the galleries and inexperienced users trying to get their nomination in the right gallery. Mixing in a character that is vital to coding is not a good idea on COM:FP or any other page. --Cart (talk) 20:54, 16 April 2024 (UTC)[reply]
    For clarity, my nomination is applicable for mainspace galleries only. Since FP galleries are in Commons, it makes sense to use only English words there. Mainspace gallery names should not be written as HTTP addresses; they should be named according to the target topics. For example, España should not be written as Earth/Europe/Iberia/Spain, but as Spain / España. The space around the slash make it clear that slash indicates dual naming and not an HTTP address. Sbb1413 (he) (talk • contribs) 06:42, 17 April 2024 (UTC)[reply]
Yes, that difference is very clear to you and me and some more experienced code writers. However, after having to correct hundreds of times when normal users get this wrong, I tend to avoid things that are so easy to misspell. --Cart (talk) 07:04, 17 April 2024 (UTC)[reply]

Prohibit copyleft trolling[edit]

Although we have blocked accounts in the past for copyleft trolling, it seems we do not actually have a policy that prohibits it. Last year, Flickr updated their community guidelines to prohibit copyleft trolling: "Failure to allow a good faith reuser the opportunity to correct errors is against the intent of the license and not in line with the values of our community, and can result in your account being removed." Should we adopt something similar? If so, how should it be worded? Here is some background reading on the topic for those that are unfamiliar with it: [1][2][3][4]. Nosferattus (talk) 17:42, 1 April 2024 (UTC)[reply]

I would simply add to the Commons:Assume good faith guideline that this guideline also applies to third party reusers. And I would require users who have a contract for automated copyright enforcement to disclose this. GPSLeo (talk) 18:07, 1 April 2024 (UTC)[reply]
I prefer GPSLeo's approach. --SHB2000 (talk) 05:03, 2 April 2024 (UTC)[reply]
I also prefer to implement the approach suggested by user "GPSLeo", it's the best approach. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:03, 2 April 2024 (UTC)[reply]
Change the ToS so anyone who uploads a file after date XXXX must give an opportunity to cure. Glrx (talk) 18:13, 1 April 2024 (UTC)[reply]
This seems unworkable, since you're essentially advocating for deprecating pre-4.0 CC licenses. We don't have the power to force Flickr or Youtube to do anything, so that would basically result in cutting ourselves off from several massive sources of free content (especially around newsworthy current events such as protests). With GFDL the loss of content was minimal (any new content was mostly people intentionally choosing the GFDL to make their work as unfree as possible), so the tradeoff was worth it, whereas there is still a lot of new content being released under pre-4.0 CC (such as on some websites that do not even have a 4.0 option). -- King of ♥ ♦ ♣ ♠ 19:25, 2 April 2024 (UTC)[reply]
No. It would just add a condition for using WMF websites. If you upload a work here, then you must give violators an opportunity to cure a license violation. It offers a benefit to people who use files uploaded by the creator. If a user is sued, the she can point to the ToS and argue that she was not given the opportunity. It does not change or deprecate any CC license. It just makes it unattractive for a troll to upload more works here because he would have to give an opportunity to cure. (It is not perfect. If a third party uploads a CC 2.0 work, then the original author has not agreed to the WMF ToS. Consequently, a troll might encourage others to upload his works here to get around the ToS.) Glrx (talk) 20:11, 2 April 2024 (UTC)[reply]
A troll doesn't even need to get others to upload their works here - they can import their Flickr photos themselves with a Wikimedia account that is not obviously tied to their Flickr account, and we have no way of proving they are the same person. And because we are trying to defend against users who are trying to game the system, this is precisely the kind of thing that we have to assume they'll do if given the opportunity. The only way to close this loophole is to ban pre-4.0 licenses. -- King of ♥ ♦ ♣ ♠ 17:37, 3 April 2024 (UTC)[reply]
I will agree in part because legal battles are expensive. One would hope that discovery would show the uploader is an agent of the creator. Glrx (talk) 18:16, 3 April 2024 (UTC)[reply]
That effectively bars us from importing CC licensed work from elsewhere if the license version is less than 4. The user here cannot make any promises, if not the copyright owner, and the copyright owner doesn't have to agree to the terms of service in that situation. It's basically a condition you are trying to add to the CC licenses, which you really can't do. And disclosing contracts may have the same problem, if they just post stuff to Flickr and let others import to Commons. It's not an easy problem -- some people may not realize a company they contracted with uses those tactics. The licenses really need to stand on their own, but would be good to do something. Disclosing the contract status, if a user here, could be a help. Do we have a category for uploads from users known to use (or contract to use) tactics like that? Carl Lindberg (talk) 22:49, 3 April 2024 (UTC)[reply]
Why don't we just adopt language similar to Flickr's policy? Is there any reason that would be a bad idea? Nosferattus (talk) 23:24, 3 April 2024 (UTC)[reply]
Reading over this that sounds like the proper approach. Although I wonder if its something we need to consult with the legal department about or get their premisson to adopt considering the nature of the thing. --Adamant1 (talk) 23:58, 3 April 2024 (UTC)[reply]
I've come across this which shows how serious Flickr are about reversing the trend. The poster reported a photographer who'd made a Pixsy claim against him to Flickr. I presume they must have received other complaints about this person, but after a month or two, the photographer was banned from Flickr and all his photos removed.
[5]https://copyrightaid.co.uk/forum/viewtopic.php?p=12772#p12772 Normanlamont (talk) 12:12, 6 April 2024 (UTC)[reply]
I'm glad that Flickr is taking this seriously. However, doesn't deleting images expose all its re-users to copyright claims, since the original CC licence disappears (assuming the image is not available elsewhere)? Julesvernex2 (talk) 12:33, 6 April 2024 (UTC)[reply]

I've read about this case and... this is sad. Anyway, I hope everyone is aware that issuing a "always assume good faith from reusers" clause would render the licenses of this site into something like: 

Hey, you are allowed to use all these files with no attribution or share alike licensing whatsoever. Only in the unlikely event of the creator noticing your reuse, reaching to you and complaining, you might be required to include attribution or a similar license next to the photo.

I mean, there can be not only bad faith uploaders, but bad faith reusers too. Disclaimer: I have uploaded from Flickr a few images that turned to be created and distributed by (at least) one of these copyright trolls (this one). (And since then, every time I upload content from Flickr I fear the creator could be one of them). Strakhov (talk) 18:28, 4 April 2024 (UTC)[reply]

Clarification of proposal[edit]

The proposal is not entirely clear. To clarify, I think the proposal should be:

Anyone who violates the licensing terms of any image on Commons should have a minimum 14 day grace period in which they can rectify licensing problems before charging the consumer with licensing fees or commencing legal action.

I agree with Bidgee that it isn’t clear what change is being requested.

Furthermore, we need some on-wiki way of showing when they were advised of the problems. Currently, as an example, Diliff is keeping all correspondence off-wiki and appears to employing a third party company to go after license violators. Enforcing licensing terms is not a problem, but the manner in which it is done very much does matter. - Chris.sherlock2 (talk) 04:13, 6 April 2024 (UTC)[reply]

I think that wording is too specific and would lead to further arguments (e.g. "14 days from when?"). Also, it's not legal actions that are the problem, as copyleft trolls rarely actually take any legal action. It's terminating the license and using that to make legal threats that is the problem. I would prefer that we just state what we expect in broad terms. Nosferattus (talk) 07:51, 6 April 2024 (UTC)[reply]
Doesn't CC-4.0 already have a 30-day grace period? I would oppose any policy that overrides this but support the general principle of the policy. --SHB2000 (talk) 07:26, 6 April 2024 (UTC)[reply]
There is very little Commons can meaningfully do to enforce this, unless it is willing to allow contributors unwilling to accept the policy change to delete their uploaded media and leave. The CC version 2 and 3 licences say what they say, and contributions were made on the basis of what the licences say. Unless I've missed something, there's nothing in the old licences that allows Commons to retrospectively change those terms. Kahastok talk 17:27, 6 April 2024 (UTC)[reply]

Proposal #2[edit]

I propose that we add the following wording to the end of Commons:Assume good faith#Good faith and copyright: "It should also be assumed that third party reusers are acting in good faith. Failure to allow reusers the opportunity to correct errors in licensing or attribution before terminating a license can result in your upload privileges being revoked or your account being blocked." Nosferattus (talk) 07:54, 6 April 2024 (UTC)[reply]

  •  Oppose The latter is excessive for simply wanting to have your photos attributed properly. SHB2000 (talk) 07:57, 6 April 2024 (UTC)[reply]
    This is about sending a bill about many hundred euros to the operator of a small blog or a small non profit organisation. AGF does of course not apply when the file is used by Reuters, Adobe Stock or in a commercial video of Google or Amazon. GPSLeo (talk) 12:40, 6 April 2024 (UTC)[reply]
    @SHB2000: I'm not sure I understand your oppose. How would this interfere with getting your photos attributed properly? You are still welcome to sue them or send threatening letters or whatever you want to do if they do not correct the attribution. Nosferattus (talk) 16:46, 6 April 2024 (UTC)[reply]
  • OK, so your person who enforced the letter (rather than the spirit) of the old licences got blocked. Well, in cases like the recent one, they're not uploading anyway so why do they care? And if they're blocked, that also prevents them from engaging with the community and hearing the community's concerns and the community's responses to any questions they might have. Kahastok talk 17:34, 6 April 2024 (UTC)[reply]

Proposal #3[edit]

A different possible wording (this is just a draft):

A similar assumption of good faith should be extended to third-party reusers of content, especially reusers who cannot reasonably be presumed to be expert in copyright and licensing matters. It is important that people whose materials are hosted on Commons comply with the spirit, and not just the letter, of free-licensing. In particular, if an online use of an image by an individual or small organization does not give a proper credit, the individual or small organization should be given a reasonable opportunity to "cure" the problem before any demand for payment on threat of legal action. (CC-BY 4.0 and CC-BY-SA 4.0 overtly require a 30-day grace period for this purpose; for differently-licensed images, Commons participants should certainly allow at least a 14-day grace period.) Not to do so constitutes "copyleft trolling."
There is generally no way to "cure" a use in print (as against online) or film/video (unless online), but still any demand for payment should not grossly exceed what might reasonably have been paid for use of the photo under normal commercial licensing.
We welcome our community members to extend such an assumption of good faith even to reusers who can reasonably be presumed to be expert in copyright and licensing matters, but that is not required. Stock photo companies (Alamy, Getty, etc.), media organizations (major newspapers, television and radio stations, etc.), large businesses (really anything past the "mom and pop" level), government agencies for anything other than small localities, major NGOs and international organizations (the UN and its component organizations; major non-profits such as Médecins Sans Frontières or the National Rifle Association, etc.) and companies large enough that they certainly engage with such issues on a routine basis can reasonably be expected to understand copyright and licensing. While we generally encourage that a similar assumption of good faith be extended here, it is not a requirement.
It is also not required to extend such an assumption of good faith to individuals or organizations that are demonstrably repeat offenders.
Commons users who make egregious legal threats or excessive demands of payment from reusers are subject to disciplinary action, up to and including being banned from Commons. Commons reserves the right to delete their work from our site or to retain that work and add warning notices of our choosing addressed to potential reusers, and/or to topic-ban these users from uploading and to blacklist their photos from being uploaded by others.

Jmabel ! talk 18:21, 6 April 2024 (UTC)[reply]

Proposal 4[edit]

Hey, sorry for only proposing this on the VP main page so far: I don't think we should make big fundamental changes that will disturb everyone. Instead:

  1. We first need a help page (landing page) that explains the concept of "copyleft trolling" to unsuspecting users (who will most likely only find it after getting stung, but better than no landing page at all) and where people can also go to alert the community about those who do use trolling tactics.
  2. Those specific users we then need to convince of switching to CC4 (they may continue using those firms, but with the 30 days grace period observed, I don't see dramatic moral/ethical issues).
  3. Those authors/users who we cannot convince of switching and who still file lawsuits, should in my opinion accept forced watermarks (not destructive ones, but like like here in the most extreme cases), so that reusers are given proper warning.

Only the final point would require a policy change, in that we as a community need to agree to make forced watermarks a regular policy - but only in established cases of copyleft trolling. --Enyavar (talk) 18:34, 6 April 2024 (UTC)[reply]

  •  Support This sounds good. But the transfer from 2.0 and 3.0 to 4.0 is a big work. It will take time. Yann (talk) 18:42, 6 April 2024 (UTC)[reply]
  •  Support This I can agree with. --SHB2000 (talk) 21:06, 6 April 2024 (UTC)[reply]
  •  Support an excellent idea! - Chris.sherlock2 (talk) 22:14, 6 April 2024 (UTC)[reply]
  •  Support Seems like a good start. Nosferattus (talk) 16:18, 9 April 2024 (UTC)[reply]
  •  Neutral This proposal might be based on a misinterpretation of the CC BY 4.0 licenses. I checked the license for CC BY 4.0 which I use for my photos. It appears to say in section 6b that the license is reinstated if a copyright violation is cured within 30 days after the person violating the license discovers this (or if the licensor expressly reinstates the license). However, please look at the last sentence of section 6b: "For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License." IMO this could mean that you might still be sued or billed for the copyvio right away, at least before you actually correct the credit line. So you might need to add the watermarks even with CC BY 4.0 licenses. --Robert Flogaus-Faust (talk) 20:24, 9 April 2024 (UTC)[reply]
    Nil Einne has raised similar concerns on another thread [6], we're trying to get feedback from Creative Commons and Cory Doctorow on this. Julesvernex2 (talk) 09:23, 10 April 2024 (UTC)[reply]
  •  Oppose for 1, there are "copyleft trolling" but then you have those who rightfully seek damages for the violation of the CC license. You need to take care when drafting the landing page.
for 2, no way should it be 30 days, at a minimum 14 days is more than enough time for the violator to cure the violation.
for 3, what if the legal action/lawsuit was warranted, as the violator ignored all attempts to "cure"? Do we mark those too? Bidgee (talk) 01:31, 10 April 2024 (UTC)[reply]
1) What is your idea of "rightfully" seeking monetary damage from re-users of a for-free-licensed image? If you can define how those hypothetical people are not copyleft trolls, we can work that definition into the proposed help page and say they are exempted from steps 2+3.
2) the duration is prescribed by the CC 4.0 license - I personally find it rather short, but I'm not complaining.
3) No, @Bidgee: If a creator switches to CC 4.0 license, I don't see problems with their content. If that creator still notifies people about their violations, gives them their due grace period, then processes them for their violations after they haven't taken the warranted action? Good for those creators, what else can I say? --13:52, 13 April 2024 (UTC) Enyavar (talk) 13:52, 13 April 2024 (UTC)[reply]

Proposal 5[edit]

  1. Make a landing page Commons:Enforcement of open license terms
  2. Be informational, define relevant concepts, link to articles
  3. Have no rules or guidance at this time
  4. Develop rules on the talk page there

There are already lots of subproposals here and I do not think we will untangle much without longer discussion. For some things Wikimedia Commons should ping the Creative Commons community and other stakeholders, perhaps Flickr, to be in sync and aware of each other. Other issues may need legal clarification. This seems like a potential months-long project. These other proposals should proceed, and I see the Wikimedia Commons community as the best place to develop these ideas, but this is discussion is too big for this board. Bluerasberry (talk) 00:32, 7 April 2024 (UTC)[reply]

I think you overestimate the ability of the Common community to have productive long-term discussions about thorny topics. Notice, for example, that Commons has no policies on harassment, legal threats, personal attacks, civility, dispute resolution, child protection, or many of the other policies that most Wikipedias take for granted (and it's not for lack of trying). If nothing comes out of the current flurry of interest, I doubt any productive reforms will be made regarding copyleft trolling (at least until the next major incident). Nosferattus (talk) 18:11, 7 April 2024 (UTC)[reply]
@Nosferattus: In most of these things you list, we inherit policies from the WMF rather than having specific policies of our own. - Jmabel ! talk 20:43, 7 April 2024 (UTC)[reply]

Deprecate PD reviewers[edit]

Hello, this is a long overdue request to deprecate Commons:PD files/reviewers and Commons:PD files. This procedure has received little attention in the last 10 years compared to license reviewers. It's time to deprecate and move all files in Category:PD files for review to Category:License review needed. —Matrix(!) {user - talk? - contributions} 16:00, 2 April 2024 (UTC)[reply]

  •  Support The purpose of license review is to record that a trusted user has examined the licensing of a copyrighted file and determined that it has a valid free license as of the date of the review, so that in the future, if that evidence were to disappear, we could continue to retain the file relying solely on the word of the trusted user. On the other hand, PD status is determined primarily by review of evidence that is widely available, so recording the opinion of one trusted user that a file is PD on the file description seems a bit too much to me; their opinion has no more weight than a "keep" !vote at DR. -- King of ♥ ♦ ♣ ♠ 18:16, 2 April 2024 (UTC)[reply]
 Support, both PD/review and LicenseReview are nearly similar to each other, conducting reviews of the licensing. Tags like {{PD-old-expired}} are still considered as license tags. Two categories must he merged into one. JWilz12345 (Talk|Contrib's.) 18:52, 2 April 2024 (UTC)[reply]
 Oppose "move all files in Category:PD files for review to Category:License review needed". RZuo (talk) 07:35, 4 April 2024 (UTC)[reply]
Can we ask why? - Chris.sherlock2 (talk) 04:24, 6 April 2024 (UTC)[reply]
Category:PD files for review is already a subcategory of Category:License review needed. Moving files from one category to the other would generate a lot of unnecessary edit "noise"; we're probably better off focusing on reviewing the files instead of shuffling them around. Omphalographer (talk) 04:45, 6 April 2024 (UTC)[reply]
HotCat makes it particularly easy, though. --SHB2000 (talk) 07:59, 6 April 2024 (UTC)[reply]
There are already many subcategories of Category:License review needed. What's wrong with this one? The files in there are already in License review needed by virtue of being a subcat. Carl Lindberg (talk) 20:25, 6 April 2024 (UTC)[reply]
 Support. Both processes rely on the image-reviewer group, and perform very similar tasks; treating PD review as a type of license review seems like the logical solution. Omphalographer (talk) 04:43, 6 April 2024 (UTC)[reply]
 Neutral Commons:PD files should stay. That is a help page. The review section could change, though many of the tags could still be used. I can see merging the reviewers lists as it's pretty much the same need and many of the same people/copyright knowledge needed. One review process is fine, though the PD stuff can just be subcats of files needing review, such as there are already many breakdowns in subcategories as it is. I would keep the review templates, maybe just to subcategorize, but just mention them on the main license review page as options. Category:PD files for review is already a subcat so I don't see any reason to do anything with that. But I could see merging the review process pages, and the reviewer lists themselves. Carl Lindberg (talk) 22:38, 6 April 2024 (UTC)[reply]

Implementation[edit]

Hello, after this discussion and consensus I deprecated Commons:PD files/reviewers and Commons talk:PD files/reviewers. I also deprecated {{PDr}} and {{PDreview}} for any future uses. However due to opposition, I didn't touch any files in Category:PD files for review, instead I just recommended reviewers use {{subst:lrw}}. Are there any suggestions for any better implementations? —Matrix(!) {user - talk? - uselesscontributions} 20:36, 14 April 2024 (UTC)[reply]

Creating a WikiProject[edit]

Hi. I'm interesting in creating a WikiProject to better coordinate and keep track of things related to "post." For instance postage stamps, postal covers, images of post offices, Etc. Etc. There's currently a category for Category:WikiProject Philately but it seems to be dead and doesn't really cover the same areas I want the project to related to anyway. There's also Category:WikiProject Postcards, which is certainly active, but it's to specific and I don't want to tromp on their territory anyway. Unfortunately Commons:WikiProject doesn't seem to give any guidance of how to create a WikiProject in the meantime. Except that it can be discussed here. So what exactly is the process to create a WikiProject? Can I just create one if I want to or do I have to go through some kind of formal proposal process? Adamant1 (talk) 00:10, 6 April 2024 (UTC)[reply]

You might do better to revive WikiProject Philately (even with a broader scope) rather than start something new. - Jmabel ! talk 01:00, 6 April 2024 (UTC)[reply]
That's actually not a bad idea now that you mention it. Am I correct to assume I can do it without much ceremony? --Adamant1 (talk) 01:23, 6 April 2024 (UTC)[reply]
Correct. Frankly, it doesn't look like this project was ever really active - there's no substance to it beyond that one empty category page! - so you can go right ahead and make it your own. Omphalographer (talk) 04:02, 6 April 2024 (UTC)[reply]
Sweet. I'll probably just do that then. --Adamant1 (talk) 04:19, 6 April 2024 (UTC)[reply]

Discussion about new tool for detecting logos[edit]

We're having a discussion at the Technical Village Pump about a new tool for detecting logos. Our intention is for you to discuss if it could be of use for the community and then, if consensus is reached, to integrate the tool in UploadWizard, in a way that would be beneficial for moderation workflow. If you're interested in the topic, please have your say! Sannita (WMF) (talk) 10:20, 9 April 2024 (UTC)[reply]

If integrated into the MediaWiki Upload Wizard, how would it work? Would it prevent the uploading of a PD-textlogo or would it detect if an incompatible license or attribution is present? Or would it simply add them to a daily page for community evaluation, akin to "User:Minorax/PD textlogo/2020 June 6"? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:00, 9 April 2024 (UTC) My bad, I replied in the wrong village pump. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:00, 9 April 2024 (UTC)[reply]

Introduction of a new role[edit]

(This proposal is an improved version of this proposal where the issues suggested by users are addressed)

In this proposal, instead of bifurcating the role of sysop, I suggest introducing a new role known as "deletion administrators" where this group of users would be able to delete and undelete media (along with roles like renaming files, sending a message to multiple users at once, deleting and undeleting specific log entries and revisions of pages, merging the history of pages, and using higher limits in API queries). This proposal addresses two key problems highlighted by users in the previous proposal; first, the concern over the "presence of a common administrator," as blocking users and performing deletions naturally coincide when dealing with abuse. With deletion administrators, administrators would still be available to address vandalism promptly. Second, the issue of "productivity" is mitigated as users who are less familiar with tasks such as blocking and unblocking users, or adding user groups, can focus on resolving the COM:DR backlog.

In the prior proposal, Rodhullandemu noted that "Admins are expected to be conversant with all policies, but most will take on work most suitable to their interests and talents. So there's no need to have separation because we already have it on an informal basis." While this observation recognizes that admins naturally gravitate toward tasks they excel at, it also highlights the potential for backlog accumulation. This "informal basis" separation, therefore, does not sufficiently address Commons' operational needs. By formalizing the role of deletion administrators, we establish a clearer division of labor and ensure that tasks are handled efficiently, ultimately reducing backlog and enhancing overall effectiveness.

The criteria for this role would mirror those of interface administrators, with the distinction that administrators can assume the role of deletion administrator, or it would be oppposing the whole point of the proposal. Thanks, Contributers2020Talk to me here! 09:09, 17 April 2024 (UTC)[reply]

The role of an Admin light with the permission to delete or undelete files is not possible because of the reasons already discussed in the past. But I also had the idea of a new user right with the possibility to delete and undelete galleries and categories as this often not critical and does not cause copyright problems. GPSLeo (talk) 12:10, 17 April 2024 (UTC)[reply]
If you feel fit for handeling deletions and plan to focus mainly on that, I think you should apply for adminship even if you don't want to to more. I doubt the rest would make much of a difference for support/oppose.
Interface adminship is generally considered more risky. Enhancing999 (talk) 15:06, 17 April 2024 (UTC)[reply]
Would it really be acceptable to the community if admin candidates run solely on the basis of deletions, and pinky-swear that they won't be involved in blocking and other abuse-prevention activities that require such privilege? I'm not informed on the impossibility of this proposal as @GPSLeo hasn't linked to the prior discussions.
I don't have enough visibility into the admins' cabal to see how they coordinate stuff, but it seems rather anarchic in terms of volunteering in specific interest areas, so there is no managed distribution of duties or labor. Small wikis as well as Commons really suffer from a lack of volunteers overall, and it would seem that the bar for entry to adminship is a huge hurdle for people who wish only to specialise, so we do have clerks, non-admin closures, and other unprivileged gnomes who pick up the slack.
In Unix, the sudo and doas interfaces, and fine-grained IAM roles in cloud services such as AWS, permit a granular division of permissions, because in the Bad Old Days they just handed over the root password/Administrator account to any salesman who needed to install software. Commons has a unique status among all the Wikimedia projects, and we often find that the MediaWiki software structure is inadequate to support our specialised operations. So the issues are both technical and social. I'm saddened that this proposal is not possible to implement as described. Elizium23 (talk) 15:56, 17 April 2024 (UTC)[reply]
Deletions on Commons can have a fairly high impact, so this shouldn't be done lightly or as an experiment. Enhancing999 (talk) 16:01, 17 April 2024 (UTC)[reply]
Enhancing999, I'd like to emphasize that in addition to proficiency in copyright matters, candidates applying for adminship undergo evaluation of their ability to effectively handle vandalism, discerning what qualifies as such and what doesn't. Adminship entails a significant qualification hurdle, and therefore reducing the number of people that can qualify for this priviledge. Given the immense backlog of deletion requests we're currently facing, it's imperative that we address this issue promptly to prevent reaching a critical threshold. I firmly believe that the proposal at hand represents our best opportunity to do so. The current workload on administrators exceeds expectations, underscoring the pressure they're under. Also, I am not suggesting that this role would be given to anybody, but the people who are deemed qualified by the community to handle the deletion part. Contributers2020Talk to me here! 16:13, 17 April 2024 (UTC)[reply]
I think anybody who understands deletion requests knows what vandalism is. Enhancing999 (talk) 16:15, 17 April 2024 (UTC)[reply]
Deletion issues are quite distinct from vandalism itself, which is a narrowly-defined subset of disruption. Enwiki has extensive documentation on this particular topic. We on Commons, being separate and unique from other projects, interpret "vandalism" and "disruption" with yet different nuances. Administrators deal with disruption enough to know, from experience, what type they're seeing, usually, but not always. It's perilous for a non-administrator to unilaterally declare disruption or vandalism, without training, experience or insight; accusations are flung around quite often at the boards.
Deletions and deletion reviews, like LTA and complex disruption cases, require community input and consensus, and that's a parallel issue: not only is there a lack of admins to push the mop around, but a lack of knowledgeable participants in deletion discussions to efficiently arrive at a decisive consensus. Admins participate so much in those discussions, that perhaps they should not waste their time until non-admin volunteers have weighed in and reached a decision!
Perhaps a unique role such as Copyright Czar would be appropriate here: drawn from the ranks of admins and others who are experienced with copyright issues, disruptions, and deletions, they could provide a continuum of expertise and labor. But as before, the bigger picture is an overall lack of volunteers and a lack of community interest/participation/person-hours for these tasks. So many Commons editors are really only interested in contributing or organizing content, because that's our mission, the project has a vanishingly small slice of the admin labor pie. Elizium23 (talk) 19:12, 17 April 2024 (UTC)[reply]
I think you and me we both came across nil vandalism in the last six months. Likely because it's not much of an issue on Commons.
It's new to me that we seek consensus in deletion discussions. Are you sure that you didn't want to post on enwiki? Enhancing999 (talk) 19:18, 17 April 2024 (UTC)[reply]
I don't think that this is a good idea, for a couple of reasons:
  • Deletion on Commons is the "hardest" admin-only task, in my opinion. It requires thorough knowledge of Commons policy, and of international and US copyright law. It's not rocket science, but it isn't a task that should be given to people we don't trust enough to make full administrators.
  • Relatedly: which people should have this role, but shouldn't be full administrators? (This is rhetorical: I'm not looking for names. But I can't think of a contributor who can be trusted with the deletion button but not the block button.)
  • Deleting and blocking often come together. Not always, but often enough that it's useful to have both tools in the toolbox.
  • I'm confused about your comment about productivity. Admins who don't want to block or add user groups, but do want to delete, are totally free do so.
Best, —‍Mdaniels5757 (talk • contribs) 19:35, 17 April 2024 (UTC)[reply]
Yeah, as Mdaniels says, deletion is not a tool that we would want to give access to that we wouldn't trust with the other admin tools. I can think of at least one user that I'd trust more with the deletion tool than with the ability to block but that would be an edge case (No, I'm not naming names). Basically, there is no guideline that says an administrator has to use all of the tools available to them. I hardly ever use the tool to block (I've only used it once to prevent vandalism by an IP user). I can also agree that having both deletion and blocking can be very useful as deletion can be used for revision deletion (to deal with spam or inflammatory comments or the inappropriate disclosure of personal info). Abzeronow (talk) 03:37, 19 April 2024 (UTC)[reply]
 Oppose I would support a category-namespace specific right as proposed above by GPSLeo, because that's a highly specialized area that's also badly backlogged, but at the same time, anyone that we'd trust to handle it would probably make a perfectly fine admin. The bar on this project is very low, at least compared to enWiki. The Squirrel Conspiracy (talk) 05:30, 19 April 2024 (UTC)[reply]
 Oppose Per others. Although I'd support GPSLeo's idea. I can think of at least a few people who could probably have a category-namespace specific right but aren't quite admin material for whatever reason. It could also be a good hedge in to having more administrator rights. --Adamant1 (talk) 05:46, 19 April 2024 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=869421623"