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/05.
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.
Latest comment: 8 days ago212 comments33 people in discussion
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
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.
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.
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.
Someone said recently in another proposal that most people don't find files through categories, but mainly through file names. I think that's true. Categories are mainly a backend thing that are exclusively used by people who specifically spend their time sorting files, not re-users. They mainly, if not exclusively find images through the file name. So it's important not to have ambagious file names. Let alone ones that create a situation where someone has to browse through, and/or be an expert in, a specialty catalog's numbering system in order to find an image. --Adamant1 (talk) 17:11, 24 March 2024 (UTC)Reply
@Enhancing999 Since you insist on the Ray Swi-hymn files. Which one of his files would you like to use in an article? I went through them and well, I didn't find one used in an article. Many, many of those files will wait for a long time for some local who can eventually describe what is shown, likely more than the 5 years that some are waiting already. The files of Ray Swi hymn are to me rather the reason for why we need an update of the file name guideline. Paradise Chronicle (talk) 18:24, 27 March 2024 (UTC)Reply
A few are directly used, others are useful providing more context around articles.
Maybe you can outline how an upload for 30000 photos should work in the proposed "enwiki"-Guideline. You can also use Panoramino or a GLAM (ETHZ, CH-NB) as a sample. Enhancing999 (talk) 18:41, 27 March 2024 (UTC)Reply
If you look at single person portraits, obviously so, but landscapes less so. They even published their images archives among others to enable the general public to determine what is visible. Enhancing999 (talk) 18:51, 27 March 2024 (UTC)Reply
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
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
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
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 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'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 ! talk22:46, 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 per se, 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
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
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
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
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
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
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?
@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 ! talk20:41, 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
@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 ! talk14: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
Oppose it's one thing to describe an ideal filename, but we shouldn't use this as a guideline to stop GLAMs and other users from uploading files that meet current standards while not being as detailed as a user with 10 uploads might expect. Glad the current version at least dropped the academic ideal of requiring English filenames. Wonder what academic current that guideline comes from. Enhancing999 (talk) 10:52, 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
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
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 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
The point here is to avoid the need for renaming, by specifying how to make a good name in the first place. Nothing here changes the renaming rules. - Jmabel ! talk14:30, 10 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
You're right that this is generally duplicating the renaming rules. However I absolutely do not expect new users to be aware of our renaming rules, whereas there should be a guideline accessible to them on how to name filenames correctly in the first place. Today, as far as I know, the only guidance they get is Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg on Special:Upload. Consigned (talk) 11:17, 19 May 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
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
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
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
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 ! talk06: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
To clarify: I still oppose this part. It doesn't diminish the overall support since details like that could also be changed later on and because a recommendation doesn't mean it has to be applied while Latin names may be useful in some cases. But this part really needs to be removed. You know humans are organisms right? Are file titles really recommended to use e.g. "Felis catus" instead of "cat"? I also oppose the part about "Language preserving" – I want to use file titles of the most widely understood and on WMC most widely-used language, English, for probably all media I upload. I think RZuo raised a few segments of the text where weakening them away from "should" may be a good idea. Prototyperspective (talk) 12:02, 19 May 2024 (UTC)Reply
The following was removed from the draft: When it comes to organisms and botanical subjects, the scientific (Latin) name is recommended. Could this be reworded as When it comes to organisms and botanical subjects in a scientific context, the scientific (Latin) name is preferred, but local languages are acceptable.? I think it is useful to recommend using Latin names in scientific areas. Consigned (talk) 16:15, 19 May 2024 (UTC)Reply
I'd have no active problem with that, but it is getting fairly long. I'm wondering if we'd do better to have somewhere that we lay out weird exception cases rather than the main flow of the document. But, yes, I think that should be said. - Jmabel ! talk16:55, 19 May 2024 (UTC)Reply
Oppose There isn't a good policy reason why English must be preferred for file names. Status quo works, and is more fitting for a multilingual project. Abzeronow (talk) 20:46, 14 April 2024 (UTC)Reply
@Abzeronow From where do you take that English must be preferred? The phrases on languages I see in the proposal are: These guidelines apply to names in English. Speakers of other languages may define guidelines for their language in the relevant translations. Paradise Chronicle (talk) 21:05, 14 April 2024 (UTC)Reply
Support per nom. this would presumably be a nice starting guideline for someone who may not know how to name things well or otherwise want a nice "standard" to stick to. something that I also would like adding as a possible template is {source} - {name}, this I have seen mostly batch uploads, such as in fonts (see Noto) and I have used for magazine issues at lipu tenpo illustrations. Juwan (talk) 20:03, 9 May 2024 (UTC)Reply
Support. Thanks for your work in codifying something that is referenced in many places but lacks a guideline. It seems to accurately summarize the various other references to this topic as well as best practices followed today. Consigned (talk) 18:53, 16 May 2024 (UTC)Reply
Support Well, a lot of consideration and re-writing has gone into this, and as long as this is just a guideline (no new restrictions on uploading will directly follow from this, right?) for anyone read and consider when naming files, I will gladly Support this, also per MikePeel and Adamant: Better have a good-practice guideline rather than having none. I checked the oppose-voices and and didn't find compelling arguments against the new proposal. I have a feeling that English will remain the only additional "Language-specific guideline". --Enyavar (talk) 19:21, 18 May 2024 (UTC)Reply
I don't think we already have such guidance on naming files, we only have a policy/guideline on renaming (Commons:File renaming). Special:Upload currently just says Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg. but ought to link to a more detailed policy/guideline page with more information. Consigned (talk) 01:11, 19 May 2024 (UTC)Reply
As far as I have read the guideline, there is nothing in there to announce sanctions against people who don't comply with it.
But just to clarify: Would an uploader of material like File:Colorado -Adams County - Las Animas County (part)- - NARA - 17443770 (page 700).jpg get blocked, if they persist to upload material like the linked one, after this guideline goes into effect? Note how the name only indicates that this is a NARA document of any place in Colorado located in a county with a name alphabetically between "Ada" and "Las". That example file is following a naming scheme, but a very very bad one with respect to our guideline. Now, if such an uploader cannot be convinced to use a better naming scheme: would we use THIS guideline as a cudgel to block them? As it is currently outlined, I don't think so. The only consequences that the guideline announces, is that files which don't comply with the guideline, may get moved. --Enyavar (talk) 08:52, 19 May 2024 (UTC)Reply
I don't think that that filename is horrible, and I would hope that a person who consistently uploads filenames like that wouldn't get blocked, as there is likely a good reason why the filename is so (e.g. bulk uploads). Enhancing999 does raise a good point - should the guideline clarify what the consequences are? Is there a policy somewhere that explains when guidelines become blockable? Personally I don't think that this guideline should be creating new blocking criteria - the same norms today regarding blocking for disruption and wasting community time (which could feasibly happen due to file name issues) ought to continue to apply. Consigned (talk) 11:09, 19 May 2024 (UTC)Reply
Users are expected to follow guidelines. Or is it just users except NARA?
Supposedly they are likely also to get in trouble with getting their filenames into neutral POV. Historic materials tends to not necessarily reflect current enwiki views on the topic. Enhancing999 (talk) 15:37, 19 May 2024 (UTC)Reply
If an uploader wastes community time today by uploading useless filenames, e.g. IMG12345.jpg, and the community reaches out and they continue to waste community time, I expect they could be blocked today. This guideline just helps to clarify the reasons why. That said the level of disruption would have to be quite high, and I don't expect "bad but not useless" filenames would rise to the level of blockable disruption, today or in the future with this guideline. Consigned (talk) 16:08, 19 May 2024 (UTC)Reply
If this is your only point, we don't need the new guideline.
Such filenames are already not possible today and were by the previous version. The explanation in the upload wizard is fairly explicit.
If you think the guideline shouldn't be applied in some cases, but should be applied in others, the guideline should say that. Otherwise contributors might not appreciated to be blocked while some archive continues with the same. Enhancing999 (talk) 16:20, 19 May 2024 (UTC)Reply
I agree that the guideline should make it clear what the consequences are of violating it. But it is a problem today that we might block on something that does not a clear guideline; users should not have to understand our file renaming procedure or vague community norms in order to learn how to best name files. Consigned (talk) 16:24, 19 May 2024 (UTC)Reply
As I've pointed out in other comments, to my knowledge the only guidance users get at Special:Upload is Use a descriptive filename. Avoid camera filenames like IMAGE1234.jpg. Is there other guidance that I'm missing? Consigned (talk) 16:37, 19 May 2024 (UTC)Reply
@Enhancing999: I have never uploaded a file with the Upload Wizard (or maybe one or two just to try it, years ago). Does that disqualify me from discussing file naming? I think not. - Jmabel ! talk16:58, 19 May 2024 (UTC)Reply
Well, you don't seem to have problems picking good filenames and you don't lecture Commons about using English or Cyrillic.
I do think you need to have some experience with Commons to contribute anything of substance to this discussion. Merely attempting to reason based on English Wikipedia article titles is obviously not working.
From you personally, I'd expect you'd explain how archives should change their filenames to comply with the guideline so they can continue to upload. I would deem an explanation like "no it's doesn't apply to NARA; but only Flickr" as not acceptable. Enhancing999 (talk) 17:05, 19 May 2024 (UTC)Reply
I believe there should be more guidance than that on how to choose a good filename. I think it would be helpful for that note on Special:Upload to link to a broader guideline on how to name a file. Consigned (talk) 16:53, 19 May 2024 (UTC)Reply
Please note: If there are dire consequences for not following the guideline, I will change my vote against it. The worst that should happen for "offenders" (unless it's disruptive material) should be consistent nagging to pretty-please choose better naming schemes, and maybe getting placed on a watchlist. Disruptive material (like obscene/insulting filenames, or notably on-purpose bad names to create a mess, like uploading penises as "cute teddy bear") gets people banned for other reasons anyway. --Enyavar (talk) 21:08, 20 May 2024 (UTC)Reply
While I support the proposed text as-is and if we get to consensus it ought to be published, I agree that its length is a weakness. I wonder if the introduction could be rewritten into an effective summary so that a new user can understand the file naming recommendations at a glance? Consigned (talk) 11:13, 19 May 2024 (UTC)Reply
"The name should not consist primarily of a broad location, such as File:Paris 319.jpg, Ontario hill, or Japan train station, where the location is so large that only someone who knows the area very well can identify the image."
"For place names, the basic name of the place, without a whole bunch of localizing addenda, is the best, e.g. "Denver" instead of "Denver, Colorado" or "City of Denver"."
Strong oppose "Refer to the Neutral point of view and No original research guidelines of Wikipedia."
"Language preserving – Follow the conventions of the source(s) appropriate to the subject and avoid translation or romanization unless these are present in the source(s). If a subject has strong ties to a particular language, the name should use that language."
whoever came up with these ideas probably have never dealt with multiple writing scripts.
say i find a photo of Zelenskyy on the ukrainian govt website to upload. i have zero knowledge of cyrillic alphabet. how am i supposed to use ukrainian written in cyrillic? or a photo of a mountain in tibet on a tibetan blog. how many commons users can write tibetan?
how many users know the tibetan mountain well enough so that "The name should not consist primarily of a broad location"?
this discussion has no merit at all because what led to this discussion is still not revealed for 2 months now. jokers want to exclude photographers' names from filenames? such absurd proposal if started on commons gets discarded straight. yet yall choose to be happily carried away by this absurdity that's hidden from users here. RZuo (talk) 12:48, 19 May 2024 (UTC)Reply
I think the important thing is that this guideline uses the word "should" rather than "must". How would new users know what to do in the scenarios you bring up today? We have no guidance for them, and some type of guide is better than a free-for-all. Consigned (talk) 12:54, 19 May 2024 (UTC)Reply
@RZuo Nowhere in the guideline it says you have to use Cyrillic for a Ukrainian file nor that you have to use a specific language for any file. Write in the language you are proficient in. Paradise Chronicle (talk) 13:11, 19 May 2024 (UTC)Reply
Please note that the example with the broad location is an example from Commons:File renaming, which is a guideline already. This kind of nonspecific file names is even common in quality images that are supposed to have meaningful file names according to the rules. E.g., this is a major nuisance during quality image categorization, even more so if the description is exactly as meaningless and contains half a Wikipedia article of text about the city or the country, but nothing at all about what is actually shown on the photo. The rather common preference for this kind of essentially meaningless file names is one of the major reasons why I support even this very lengthy guideline. Renaming this kind of material would very likely enrage the authors because the new names would not match their naming conventions. Therefore, avoiding this by encouraging short but meaningful names would be great. However, a much shorter version of this guideline would be very much better, possibly with a link to the longer version for the extremely few people who wish to know more about the subject. --Robert Flogaus-Faust (talk) 22:27, 20 May 2024 (UTC)Reply
as part of Commons:File renaming it's ok, because it means it's reasonable to "change from a generic filename to a more descriptive one". as part of a guideline on naming files during upload it's not ok.
imagine if Kimiko Nishimoto took photos of towns on board a plane from munich to zagreb. how would you expect a foreign elderly tourist give filenames more specific than "european towns seen from flight ab789 012.jpg"?
those who came up with this proposal have never had experience of uploading or handling something they dont know about, which is not uncommon for travelling photographers.
i myself have taken a lot of photos of things i have no clue about. all i can offer is the location where i took them. RZuo (talk) 20:06, 25 June 2024 (UTC)Reply
If you don't know what is being depicted then this is valid explanation for why the title is not more descriptive, no problem at all...one could also use a title like "Close-up of unidentified animal in Ecuadorian Amazon" or "Animal in Amazon, 345" which already would be descriptive. Prototyperspective (talk) 22:22, 25 June 2024 (UTC)Reply
There's no mandate with this that anyone has to use descriptive file in cases where they either don't know or have access that information. "The law of least resistance" or whatever it's called should apply though. In other words, "provide whatever description that you can. No more, no less." Just like with everything else on here. --Adamant1 (talk) 09:25, 27 June 2024 (UTC)Reply
Here's the thing: I'm not quite sure what this does. It sets forth some best practices, but to what end? It doesn't say what should happen if a file doesn't satisfy these best practices, and that's probably a good thing because there's a lot of room for disagreement in the interpretation/application of these guidelines. It seems oriented towards getting the filename correct at the time of upload, but what happens when it's not correct? It doesn't address the issue that inspired it, which is about inclusion of the photographer name, but does open cans of worms by e.g. introducing the [English?] Wikipedia's NPOV policy. The relationship between this page and Commons:File renaming needs to be worked out as a fundamental element of how this page works in practice. In short, it's fine to say "please think about how to make your filenames precise" but when I think of making something a guideline I think of giving people a tool for enforcement. Absent clarity on what's to be done with this guideline, I'm inclined to Oppose, with thanks to the proposer for putting work into a challenging project. — Rhododendritestalk | 21:55, 19 May 2024 (UTC)Reply
Of course they are. Otherwise just have an "information page" or something. The whole point of having a big discussion to formally make something a guideline is to give it teeth. — Rhododendritestalk | 15:00, 20 May 2024 (UTC)Reply
The guideline is to clarify existing practice regarding renaming, and to help uploaders create filenames that do not need to be renamed.
As far as "teeth", I think the only thing this guideline really does is establish a standard for what filenames can be renamed to. So if a user is consistently renaming files to *worse* names according to this guideline, then there would be a strong argument to revoke their renaming privilege. Mathnerd314159 (talk) 17:43, 20 May 2024 (UTC)Reply
How can you ask persistently uploading problematic filenames like "sdf.jpg" or "Jmse-10-01816-g001-550 hor.jpg" to choose beter filenames? And if they're willing to use proper names or are looking what proper filetitles would be, what page would give for guidance? I really don't get all this conservatism "if a policy on this doesn't exist since around the time of Wikimedia founding then let's make it near impossible for it to pass for no good reason". File renaming cited by Rhododendrites is only about moving files but this is about naming files at the time of uploading which is a separate subject and important for many reasons such as reducing workload and establishing good naming practices right from the get go (e.g. many problematic filetitles will never be changed). Prototyperspective (talk) 21:43, 20 May 2024 (UTC)Reply
@Bidgee right, the current standard there is "A user repeatedly renaming files under invalid reasons can be stripped of the filemover privilege." If this guideline passes, there would be one more reason to consider a rename invalid (the filename is "worse"). In particular, for renames under reason 2, "change from a meaningless or ambiguous name to a name that describes what the image particularly displays", one would consider the various factors of the naming guideline and could conclude that the resulting name is not better. Currently, the renaming policy links the naming guideline, but it is not accepted as a guideline, so it cannot actually be cited as "common sense".
Or something like that, I am not a wikilawyer. Personally I am done - I wrote the guideline, nobody has any more constructive feedback on it, it has been months. Y'all have fun. Mathnerd314159 (talk) 02:01, 21 May 2024 (UTC)Reply
Honestly I don't think the 15 different versions really helped. Especially since they were actively being changed while voting was going on, which at least IMO is a huge no no. You might try cutting it back and proposing something in a few months that just involves the basic points and makes it clear that it's only a guideline, not an enforceable guideline though. Since some people were/are still clearly confused about that aspect and it was never properly addressed. From what I've read so far I don't think anyone would necessarily reject a basic "guideline" about how to name files at the time of upload. There was some obvious things that could have been made clearer and done better from the get go about this particular proposal though. So it's not surprising that it didn't go anywhere. But again, that can probably be dealt with by simplifying it and not making the same mistakes next time around. --Adamant1 (talk) 03:36, 21 May 2024 (UTC)Reply
There were only two substantial versions, and I stated up front "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." The process has been going exactly as I envisioned it, save for the fact that people can't read and keep bringing up points that have been discussed to death. Mathnerd314159 (talk) 16:01, 21 May 2024 (UTC)Reply
From what I saw there was a vote on draft 1, draft 2, and then the "final proposal." That's to many iterations. It's just confusing and makes it hard to tell what exactly people have or are voting on. It's also rather tendentious to expect people to keep track of the various conversations, your edits, and repeatedly vote on the different proposals in the meanwhile. ou should have proposed and refined the draft in another venue and then done the final one here. Or conversely proposed the draft, gave it plenty of time for people to comment, and then edited it and created the final proposal after some time has passed. You can't just edit and propose 3 different versions of something in real time as the vote is happening though. There's no reason you couldn't have just proposed the draft to get feedback on it, made the changes, and proposed the final draft at some point in the future after you were sure all the kinks had been ironed out. --Adamant1 (talk) 23:03, 21 May 2024 (UTC)Reply
Oppose In my opinion, we need not much more of a filename guideline than that the name should be unique, preferably fairly descriptive (in any language) and not contain anything defamatory or unnecessarily rude. Also, large-scale uploads by GLAMs often use rather short and not very descriptive file names but are valuable nonetheless; after all, a good description is more important than the file name. Gestumblindi (talk) 19:24, 26 May 2024 (UTC)Reply
What, this is about the title not lengthy descriptions. You prefer filenames like "Jmse-10-01816-g001-550 hor.jpg" "PA166123135.png"? What's your rationale, have you thought about this? Prototyperspective (talk) 12:29, 20 June 2024 (UTC)Reply
When you have a look to my uploads you can clearly see what I prefer. And yet, files are still occasionally renamed (in my opinion, without justification). This proposal will make this even worse instead of better. Stepro (talk) 12:46, 20 June 2024 (UTC)Reply
@Stepro after looking at your recent uploads, I'm pretty comfortable in saying that what you seem to prefer goes against general consensus. Putting your name in photos of people, and leaving out the name of the person you photographed is, at best, confusing, and makes the filenames useless as anything other than unique identifiers (which they have to be by system requirements). - Jmabel ! talk17:21, 20 June 2024 (UTC)Reply
That's exactly what I mean. My file names are anything but "meaningless", the respective event is always included in the file name due to the automatic naming. The description of the content of the photos is in exactly the right place - namely in the "description" field. And without wishing to praise myself, I think that my image descriptions are generally comprehensive, detailed and factually correct. The photos are also categorized accordingly. They are easy to find via both internal and external searches, as evidenced by the numerous external reuses (new ones almost every day).
And then "colleagues" like you come along and write that I'm doing everything wrong and that my uploads are against the "general consensus". This is extremely demotivating, especially when it comes from admins of this project.
I just have the faint hope that it's not "against general consensus", and I just keep working (for now!) to make free content available. Both for the Wikipedia projects and for external users. Stepro (talk) 23:00, 20 June 2024 (UTC)Reply
You're not doing everything wrong, just the part of not including the name of the person pictured in the image title. I also think it's general consensus to name files in ways that are somewhat descriptive but it's not yet a policy hence this proposal. On category pages, one does not see the descriptions but only the filenames for instance. Prototyperspective (talk) 09:04, 21 June 2024 (UTC)Reply
Sounds like you are trying to assume there is consensus for this draft while the point of this discussion is gather input about it.
Obviously, this reminds us where it came from: suppress the name of the creator/photographer from filenames. Oddly, people advocate adding the name of the uploader. Enhancing999 (talk) 09:10, 21 June 2024 (UTC)Reply
I have had this discussion (too) often. So in a nutshell: a) I am not in a position to edit each file name individually when uploading several hundred (up to more than a thousand) photos of an event, these are generated automatically, and b) no one has yet been able to explain to me how file names should look when several people are pictured. Should the file names then span three screen lines? I think they are already very long.
And all in all, I stand by the argument I used to justify my vote: Descriptions of the photos belong in the Description field, and not in the file name. This is an attempt to solve a problem that simply does not exist. Stepro (talk) 10:24, 21 June 2024 (UTC)Reply
@Enhancing999 it's more about what the established practice and expected titles are I think. I don't have an issue with including the uploader/photographer name but the person depicted (or content) should also be there.
@Stepro You are in that position by scrolling through the page and spending 5 minutes to add the name of each person depicted to each title (e.g. at the end of it). When 3 or more people are pictured name them all or add sth like "discussion at event", just something descriptive and people could extract an image of the individual person. This problem exists as demonstrated by your uploads as well as by already mentioned uploads like "Jmse-10-01816-g001-550 hor.jpg" "PA166123135.png" which make it harder to find the images, make image unclear where they're used, and degrade the usefulness of category pages. Your argument is just saying they belong somewhere else without explanation why and I gave several reasons why the file titles are meant to be descriptive. This really is kindergarten and should be self-explanatory, no idea why this proposal is still somewhat controversial. To anybody who has WMC best interest in mind it should be clear that file titles should be descriptive and useful. Prototyperspective (talk) 10:35, 21 June 2024 (UTC)Reply
I think it's an error to assume filenames should somehow look good on category pages.
Even so, it's unclear what would be better in your approach. A picture of persons A, B, C will be in the categories for these persons with a filename that indicates when it was taken, at what event and by whom. You don't need to read the name of that person again. Enhancing999 (talk) 11:32, 21 June 2024 (UTC)Reply
They shouldn't look good, they should be useful for the reader/user to see whether or not the file is about what they searched for / interesting to them (descriptive of the file content). Good point but these are also in other categories, not all files in the categories actually depict the person, and there's further reasons such as image content being unclear when editing Wikipedia in nonvisual mode. Prototyperspective (talk) 11:37, 21 June 2024 (UTC)Reply
This is an attempt to solve a problem that simply does not exist. Just because it's not a problem for you doesn't mean it isn't one. There's plenty of files on here that never will be meaningfully categorized because the file names are to ambiguous. Photographers like you don't really care about the curation aspect of this though. You just want to have the benefit of uploading files to Commons as your own personal project without caring about other people's ability to curate then or anyone else's to find the images. And yes ambigious file names do get in the way of both. Especially people's ability to find the images since most people find images on here through Google Image Search, where file descriptions are essentially worthless. So at the end of the day your just screwing yourself with your attitude about it. Although your also screwing over every one else's ability on here to organize your uploads. --Adamant1 (talk) 10:37, 21 June 2024 (UTC)Reply
a) People obviously find my pictures, I have new re-uses nearly every day.
b) Wording like "kindergarten" and "Commons as your own personal project" let me end this discussion. I am not prepared to be insulted like this. Stepro (talk) 10:44, 21 June 2024 (UTC)Reply
@Stepro: People obviously find my pictures, I have new re-uses nearly every day. That's why I said "Just because it's not a problem for you doesn't mean it isn't one." Anyone can come along and derail a discussion by acting like something doesn't exist just because they don't have a problem with it. Have fun sticking your fingers in your ears about it though. You clear know better then the people who are actually do the work organizing files and are effected by it. Maybe mine and Prototyperspective are a little insulting, but not anymore or less then you acting like we are just making up the problem or otherwise participating in this when you clearly have no clue what the issue is or how the proposal would resolve it. --Adamant1 (talk) 11:00, 21 June 2024 (UTC)Reply
Whether we adopt this particular proposed guideline or not, there is a very basic principle called "the law of least surprise". in building a web site, you want to give people as much useful information (and as little misleading or inaccurate information) as you can. Given that on Commons file names are exposed, they should be as revealing as possible of information that is potentially useful to the end user. - Jmabel ! talk19:05, 21 June 2024 (UTC)Reply
I think some GLAM-archives rather take the opposite route: they add as little as possible to avoid anything that might be wrong, no dates, no creator, and we end up with endless files that mostly consist for their name, and their ids, but sometimes not much of any substance. I got the impression you participated in these uploads as you approached me once about one.
The advantage of Stepro's approach is that it includes event, date and creator. It's not even clear if that is contrary to the proposed guideline, as at some point it recommended repeating the category name and adding a number. Enhancing999 (talk) 19:18, 21 June 2024 (UTC)Reply
I think the proposal aligns with the reality of Stepro's history. Stepro does not need punishment due to their filenames - they aren't entirely useless and this type of filename sometimes happens when uploading in bulk - but a few have been renamed, justifiably, because they could certainly be better. This proposal is aligned with our current practices of preferring most useful filenames (with recommendations and guidance, which is missing today) but does not suggest any kind of punishment for less-than-perfect filenames. Consigned (talk) 19:35, 21 June 2024 (UTC)Reply
Oppose (translate.google) There are no good or bad file names. Even 123456789.jpg is acceptable. The description belongs in the description, the file name is just a technical crutch. There is no point in regulating this. --Ralf Roletschek11:39, 25 June 2024 (UTC)Reply
The file name is not just technical, it shows on category pages, in the search results when hovering over an image, and is also used by external and the Commons search engine. I wonder why some people are so opposed to this, the only thing gained is a degradation of the quality and usefulness of WMC. Like the other opposers your rationale does not really include any explanation and makes two refuted claims. Prototyperspective (talk) 11:44, 25 June 2024 (UTC)Reply
This proposal is about policy asking photographers to use descriptive useful titles, not so much about changing titles. Your example is descriptive in that it has the nonphotographic work's author and the work's name in the title rather than "paint03434.jpg" or "my photo of a picture 02353, by photographer Sam Donald in 2024, latest.png". This is not about what people "like better". I think your assumptions are quite disrespectful and not thought through while none of the claims have been addressed by your comment which rather clarifies that you don't see what this policy is proposing. You're still free to name your files as you want, they should just include some descriptive info. Prototyperspective (talk) 12:15, 25 June 2024 (UTC)Reply
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
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
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.
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
Comment I think the wall of text now requires a new write-up with a summary. If I counted correctly there are now 9 support vs 7 oppose (assuming Enhancing999 maintains the opposition; at least 3 of the oppose-votes were without rationale or clearly disproven explanation). I don't see why a reasonable baseline policy wouldn't be needed and useful. Would a structured arguments tree (Pro/Con format) help to visualize/provide an overview of the different points made and their respective objections? Re the clearly disproven rationale: file names don't need to be in English per this draft; I would however suggest that if EN is configured as language it could be made to show a specified or machine-translated English title even when the filename (default and url) is different. Currently file names like "flower.jpg" "sdf.jpg" or "Jmse-10-01816-g001-550 hor.jpg" are prevalent and it would be very useful to have descriptive titles when scrolling through a category page for example or searching for files. Much of this policy can already be inferred from the file-moving reasons, so having a policy just provides some guidance and reduces filemoving workload etc. --Prototyperspective (talk) 09:48, 16 May 2024 (UTC)Reply
Some of the support votes don't really go beyond what we already have, so why do you try to assess some of the reasons, but not others? Enhancing999 (talk) 16:23, 19 May 2024 (UTC)Reply
It appears that some of the participants who support this are neither active users of Commons nor have actually uploaded files. -- Enhancing999 (talk) 16:35, 19 May 2024 (UTC)Reply
Now's a good time to follow up on Prototyperspective's comment. What's the right way of moving forward here? Is there sufficient consensus to publish this guideline? Should the proposed text be worked on to try to resolve some of the opposition before gathering feedback again? Consigned (talk) 10:08, 25 May 2024 (UTC)Reply
I think we can archive the proposal and return to our respective WMF projects. Thanks for bringing the controversy at English Wikipedia about Commons photographers names to the attention of the Commons community and raise awareness about a need to better communicate issues users may have with non-English filenames and descriptions. Enhancing999 (talk) 10:13, 25 May 2024 (UTC)Reply
This comment says nothing about the validity of the proposal, you're just attacking the participants. Please follow the UCOC and treat all Wikimedia contributors with respect. BTW I'm assuming that your comment was directed at me since you accused me of being a sockpuppet and of not being a real Commons participant, but it might also be directed at others; for your information I have no idea about any ENWP/Commons photographers controversy (do you have a link to that discussion?). Consigned (talk) 10:36, 25 May 2024 (UTC)Reply
From your comment, I gather you didn't read the discussion about this proposal in full. The proposal was presented as one coming from the English language Wikipedia project to somehow remediate several perceived issues there. Do we need to censor comments on this aspect?
I'm not aware you participated in its elaboration. Maybe you can explain if and how you did and what brought you to this discussion. This would allow me (or others) to better help resolve an issues you may have. Enhancing999 (talk) 10:55, 25 May 2024 (UTC)Reply
Ah I see, my mistake - I somehow missed that in the initial proposal, which I probably skimmed before going to the draft itself and finding that I supported it. I arrived here just by poking around the Commons Village Pumps. Consigned (talk) 11:28, 25 May 2024 (UTC)Reply
I don't think there is sufficient consensus to adopt this. I think a good idea would be using it for some time, referring to it whenever you see somebody upload badly named files or when moving files and discussing things on its talk page so it naturally develops and gets changed to be in a better shape. Then it could be proposed again at a later version where any issues are sorted out and corrected. But maybe more people will weigh in, I doubt it though given that this discussion has been open here for quite some time and because of the wall of text and confusing sections here now. (Next time please try to avoid these two things so that more people will participate and things are clearer.) Prototyperspective (talk) 11:35, 25 May 2024 (UTC)Reply
For what it is worth after such a long discussion, that seems almost to be closed:
Support File naming guideline. Thanks Mathnerd314159 for the research and proposal. It looks good, very useful, also as a guideline to reference to when addressing uploaders who continue uploading files with problematic file names.
I do think that proper filenames are important, no matter how well the descriptions, structured data and categories are. In an overview (like search results in Special Search and categories) you always can see the file name (in MediaSearch: use the cursor to see the URL with the filename, on the bottom left on my pc), but not the other elements, and then it is good to know what the file is about.
A bold proposal: can the controversial elements be left out, can the guideline then as soon as possible be implemented and can the issues/details be discussed later (for instance in the Talk page of the guideline) and then be adjusted piece by piece? As Adamant1 says: Perfect is the enemy of the Good, and then we have at least a guideline with the most important "rules".
I hope that there will also be a short version for end users, who just want to upload a couple of files (which indeed should be linked in the Upload Wizzard). I would already be happy if all filenames would include subject, location and year, as precise as possible, in whatever language that Google Translate supports.
My opinion about some of the discussed issues:
Generally accepted abbrevations does not need to be a problem if the full text is in the description and the title includes at least the subject, location (both fully written) and year.
Scientific (Latin) or ordinary names for organisms? My preference: Files uploaded by "ordinary" people can have ordinary names (do not make uploading more difficult than necessary); those uploaded by people who are familiar with taxonomy terms can have file names with scientific names and preferably have a description including the ordinary name.
English or other languages for general subjects/names is not a problem in most cases, as long as:
there is a Wikidata item for the subject, which has descriptions in many languages,
the structured data in the file are filled in (which might not alway be necessary when the file is in the correct category) and
you are searching with MediaSearch, which is the standard search and I guess will be used by most end users.
There is indeed a problem when a general word (like the Spanish silla/chair) has another meaning in another language. But should we make a "rule" that effects all uploads for these kind of exceptions?
Still one Question: what do you mean by "on CDs"? Compact Disks?
Latest comment: 9 days ago87 comments31 people in discussion
This discussion has run its course, and I am hence closing it. Out of these proposals, it is clear numerically that proposal no. 4 is the most successful.
The help page Commons:Copyleft trolling has been created, and subsequent comments can be made on its talk page.
Idea is we can convince users to switch to CC4, and then they can continue to use firms such as Pixsy.
Authors who still do not switch to CC4 should accept forced watermarks so proper warning is given to reusers.
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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
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
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.
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
Hi everyone! Currently, it seems that proposal #4 (the one I suggested) has several supporters, while the other ideas seem to have been of less interest yet. The discussion itself however has died down considerably, and I think that we could move forward with a cool head on this one.
Sounds good. I just wanted to prevent the ArchiveBot taking an interest into this whole debate before we had reached a conclusion like this; and also didn't want to move this topic further all on my own, since it's not my personal priority. --Enyavar (talk) 22:53, 24 May 2024 (UTC)Reply
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
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. Kahastoktalk17:27, 6 April 2024 (UTC)Reply
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
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. Kahastoktalk17:34, 6 April 2024 (UTC)Reply
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.
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:
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.
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).
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
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
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
That Medium article you link in 1) seems to be about people pursuing large damages and paying to send legal threats to small bloggers who attribute a CC image but miss some formality or even doing it correctly. That's a pretty big jump from "collecting from companies that should know better just taking images off the internet with no attempt to credit the creator", which from my understanding of the proposal would still be prohibited without allowing a 30-day grace period. AlexandraAVX (talk) 07:28, 7 May 2024 (UTC)Reply
The trolling legal firms are pursuing large damages without regards to the size of the "offending party": they threaten bloggers, charitable organizations, and companies all alike (except that big business usually pays for professional stock images in the first place); and the troll business model apparently pays itself. / The 30 days grace period is a feature of CC 4.0, and has little to do with the proposal. My proposal was just an idea how to bring as many creators as possible to update their licences. Other CC-license platforms like Flickr (to my understanding) are much more proactive in banning users who engage in copyleft trolling. For Commons this is hopefully the start of dealing with the problem. --Enyavar (talk) 13:13, 7 May 2024 (UTC)Reply
@Bidgee: Have you taken a look at Commons:Copyleft trolling? No one is going to add forced watermarks to the images of someone legitimately seeking commercial damages for copyright infringement. As that page makes clear, we are only talking about when a photographer "sues people indiscriminately for licensing violations, whether major or minor". In these cases, forced watermarking is a last resort in order to protect our good faith reusers. If you have ideas for how we can make this distinction more clear, please feel free to edit Commons:Copyleft trolling. Nosferattus (talk) 03:16, 8 June 2024 (UTC)Reply
But define "legitimately seeking commercial damages for copyright infringement", what do you call "sues people indiscriminately for licensing violations, whether major or minor"? Commons:Copyleft trolling is a mess. Bidgee (talk) 06:21, 8 June 2024 (UTC)Reply
This is something I think I can do by example, but not from an a priori approach.
Clearly legitimate bases to threaten or bring legal action:
Movie uses your content without attribution.
Someone that you have already warned on a prior usage uses your content online without attribution.
Major media organization that clearly should know copyright law (major newspaper; TV station) uses your content without attribution.
Someone uses your content in a widely distributed advertisement or on a billboard without attribution.
Blatant misattribution, especially by a major media organization.
Clearly copyleft trolling to pursue these; however, all of these examples can be qualified by the remark above about you having given prior warning:
Someone posts a copy of your content to Facebook or to a non-notable personal blog without attribution, but on contact is completely willing to credit you or to take it down.
Your photo is used online and credit is given to Wikimedia Commons or to Wikipedia, rather than to you. On contact, they are completely willing to credit you or to take it down.
Your photo is used online and they credit you, but don't provide the particular links that may be required by the license in question. On contact, they are completely willing to cure this or to take it down.
Your photo is used online and they misspell your credit. On contact, they are completely willing to cure this or to take it down.
Use by a child on a class project.
In between: I'd be concerned if I saw repeated, large claims on this basis, but requesting two to five times what they might reasonably have paid in advance to use such in image seems OK to me.
Almost any completely unatttributed use in print with more than a tiny circulation, since you can't "cure" print media.
@Bidgee: "Legitimately seeking commercial damages for copyright infringement" means when there are actual commercial damages, i.e. a commercially significant use, not someone using a photo as the banner for their LinkedIn profile or in a blog post for a small veterinary practice. And even in those cases, if someone failed to fix the attribution after being notified, the author would certainly be entitled to sue them. If you have different ideas, please share them. Just saying that the page is a mess is not very helpful. If you agree that copyright trolling is a problem, please help us figure out how to address it. Due to your extensive experience as a Commons contributor and community member, your collaboration would be very valuable. Nosferattus (talk) 19:46, 9 June 2024 (UTC)Reply
Support, though the watermarking only resolves the issues after the fact, allowing copyleft trolling by new actors until they are noticed and their files flagged. I'm not familiar enough with the scale of copyright trolling to know if this is sufficient, but even if not sufficient, it's a good start. Consigned (talk) 11:52, 25 May 2024 (UTC)Reply
Comment A longer comment both because this is the only proposal going anywhere constructive and because it came before the clarification below. Switching to CC4 does nothing to prevent people/companies from demanding money from people. None of the stories we've heard about the case that started this involved people being sued multiple times, so I don't think it's realistic to think e.g. Pixsy would stop demanding money from people just because they know they won't be able to do it more than once. Yes to an information page about copyleft trolling, but we don't need a formal proposal for that. Someone can just write it. I don't think it's realistic that people who use these companies are going to be persuaded to switch to CC4 (as Diliff made clear he would not). What's left is forced watermarking. We would need very clear guidelines as to the criteria for users whose images are to be watermarked this way, how those watermarks are enforced (many Wikipedians will complain and try to crop, after all), clear guidelines the form/content of those watermarks, clear guidelines about when the watermarks can be removed, etc. I say all this because I think it will be hard in practice. There's also one element missing from these proposals: what to do with the users whose behavior leads to forced watermarking? Seems to me if we get to that point, we should not be accepting further uploads from that person? — Rhododendritestalk | 12:58, 25 May 2024 (UTC)Reply
Support only for the Copyleft trolling landing page. I don't know what copyleft trolling is and wonder since quite some time what this discussion is actually about. I tried to look for some explanation in the discussion, but after two paragraphs I gave up. Paradise Chronicle (talk) 10:51, 26 May 2024 (UTC)Reply
@Paradise Chronicle: "Copyleft trolling" is basically when someone publishes an image with a free license, but then threatens a lawsuit with substantial damages for relatively innocuous violations of copyright when that image is not properly attributed. I'll add that to Commons' glossary. - Jmabel ! talk20:52, 26 May 2024 (UTC)Reply
Be informational, define relevant concepts, link to articles
Have no rules or guidance at this time
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
I also think that we should go forward incrementally here, just like Bluerasberry suggests. So first, implementing the landing page idea, and discussing further action from there. --Enyavar (talk) 12:00, 11 May 2024 (UTC)Reply
Comment This is an extreme solution but it would almost entirely protect all re-users against copyleft trolling; it would also incentivize users to use more modern licenses. Ideally this would be done systematically without the need to reupload new files, and there be a way to download/use the file without watermark at the re-user's own risk, both of which would require a significant software enhancement. Consigned (talk) 11:54, 25 May 2024 (UTC)Reply
I'm certain that most uploads using the older licences have been done by users before the new license was published, and not as a ploy for copyleft trolling. And even newer uploads using the old thing may have been done out of routine or ignorance of the updated license. That is the reason why I suggested creating a greylist of users (we currently have like... just three names?) who have engaged in copyleft trolling, and to only force watermarks on their material. If it turns out there are a dozen more cases, we also treat those images. But the thousands of people who uploaded under older licenses without intent to sue others, should be left alone. --Enyavar (talk) 11:39, 25 May 2024 (UTC)Reply
According to [11], isn't the problem much more significant on older licenses, where there is no grace period for the re-user to correct the issue? Consigned (talk) 13:10, 25 May 2024 (UTC)Reply
As discussed below, it does nothing to prevent people from being sued for minor violations. All it does is allow reinstatement of the license once the problem is fixed. For older licenses, once there's a violation you're not allowed to use the image anymore and can be sued. With CC4, you can get the right to use the image back, but you can still be sued (and you can be sued multiple times if there are multiple minor violations of the license). — Rhododendritestalk | 13:36, 25 May 2024 (UTC)Reply
No, no, no. We don't need ugly forced watermarking on a huge chunk of the site. Like, could my images hypothetically be used for "copyleft trolling"? Maybe? Am I going to do it? Hell no, and neither are most users. Dronebogus (talk) 14:26, 25 May 2024 (UTC)Reply
As the user whose reporting of a photographer's activity using Pixsy started this whole discussion, I've been encouraged by another user to add my views. I'm not a photographer or a Wikipedia administrator, I'm writing just as an ordinary user. I want to address:
· the small time 'offender's' viewpoint
· Pixsy's modus operandi
· the photographer's viewpoint
· the proposals so far
All the cases I reported involved charities or very small-bloggers. Other contributors mentioned others. When Pixsy claims damages it's very threatening and quite a shock. I'm not asking for pity here, bear with me. The way the demand is worded asserts clearly that ignorance of copyright, carelessness and a willingness to correct the attribution will have no effect on the demand. You MUST pay a large amount of money, and quickly, or you will have legal action taken against you which could result in you paying a much larger amount in legal expenses. So in each case we're talking about someone who is shocked and scared. In many of the cases quoted the offender tried to contact the photographer to see if something was negotiable, to no avail. Not everyone did. At least one was so afraid they closed down their website and business completely. In my case I didn't try because Pixsy said they represented the photographer and communication should only be through them.
(I'm using Pixsy as an example here because they were involved in these cases - as you know there are many organisations working in this field.)
In my case, and I'm sure in the other cases I reported, had I been simply been reminded 'you didn't attribute that photo correctly (and if you don't then ...)' I would have immediately corrected it. I wouldn't need a 30-day grace period.
I'm well aware that during the discussions that followed my report, there's been scant sympathy for Pixsy and similar businesses, even from supporters of the photographer, however I still feel I should reiterate the user's point of view.
In this case the photographer expressed some regret that small users were 'caught up' in what he sees as a legitimate process. Looking at Pixsy's Trustpilot page shows many photographers praising them for recovering thousands of pounds from illegitimate commercial use of their images. It seems that in many cases they're actually providing a valuable service to photographers. However, when it comes to images that are licenced under CC we can see that:
a) Pixsy does not distinguish between careless use of CC and abusers who, for example, re-sell photos, change metadata, use them in advertising campaigns etc. Indeed in my experience, Pixsy automatically categorises websites as 'commercial' and CC use as breach of licence. (I know that technically it is, but that is an expedient according to Cory Doctorrow.)
b) Pixsy offers little justification for the amount they charge. Their justifications change over time and are never verifiable.
c) Pixsy offers no suggestion that this can be resolved in any way other than paying what they demand. There's no question of negotiation or of approaching the photographer.
d) their legal arguments are not valid (too much to go into here but at least under UK law, and the UK court, their claims are simply incorrect)
From the photographer's point of view, there's obvious benefit; an arm's length relationship keeps it simple, and removes the need to spend valuable time looking into individual cases. I think, however, this gives them a skewed idea of how the claim process goes. The photographer Diliff for example suggests that because what he is eventually paid is in some cases less than the original claim, then some mitigation has been accepted and some negotiation has taken place. In all the cases I know of, this is not so. Many site owners will just pay up immediately out of fear and shock, with no challenge or negotiation. Others may attempt to negotiate, but this may never reach the photographer. (For example I offered to go the the UK mediation service instead of a full court case. Pixsy refused to even comment on this, so I have to assume the photographer was never told.) Finally Pixsy will offer a reduction or 'discount' after several months if the user shows they are going to argue. This is not presented as a concession by the photographer, in fact they say they are not authorised to negotiate but to speed things along they can offer a discount. So the photographer should be under no illusion that Pixsy are dealing with small users and CC claims in any 'softer' way than commercial abusers.
Also from the photographer's view, we are told they should be able to claim retrospective damage for the time the photo was used, and should be able to claim for the work involved in bringing the claim in the first place. This may work in the US, but UK courts will only look to reinstate the photographer to the position they would have been in had it been correctly attributed; and legal costs other than very small expenses such as travel are not reclaimable. As others have stated it's a false dichotomy to say the alternative to an unattributed photo is a paid licence - it's an attributed photo or a different photo altogether.
It's been suggested here and there on the web that claims for CC misattribution rarely reach court. I don't know if it's true, but even if it is, many people will have paid these companies immediately out of fear, so it's no consolation.
I was surprised how much discussion my report produced and the depth and care taken around the proposals for remedying the situation.
I won't comment on the proposals to delete this particular photographer's contributions or put other sanctions on him. Flickr have adopted a harder stance and at least one photographer has been completely removed because of Pixsy activity. But that's different governance, different situation. This is a matter for Wikipedia and the discussion here has been thorough.
Proposal 4 includes a landing page that explains the risk of misattribution. In my case that would have caused me to take better care of attribution. My failure to attribute was due to nothing but haste and carelessness; I normally attribute everything including libraries like Pexels. So it would have worked for me and, I imagine, most of the cases I reported.
The grace period - as I said in my case a 5-day grace period would have worked - it was an 'oops!' moment, but the CC4 30-day period, or the reduced 14-day period suggested are all perfectly good to me. However it requires photographers who use services like Pixsy to authorise them to issue a takedown notice before bringing out the heavy guns. They do have that choice, at least with Pixsy. Diliff for one argued against that, but I think his arguments don't stand up for the majority of cases, they were only about photos being used in a short term ad campaign. Clearly this is something between the photographer and their copyright chasing agency and WM have no power to force them to do anything; but an education programme for contributing photographers about the reasons for using CC4, bringing in the arguments of Cory Doctorrow and the change of policy at Flickr might help. Many photographers will, like Flickr, not want to be associated with the hounding of CC violators as collateral damage for photographers seeking redress for serious commercial theft.
The problem is that you don't attribute photographers at all (you mentioned earlier). It's not a question of a mere detail that went wrong. (Did you also get claims for Getty Images? How did that work out?) Enhancing999 (talk) 12:04, 24 April 2024 (UTC)Reply
Yesterday I had the chance to speak with Creative Commons about copyleft trolling. I've summarised my understanding of their feedback below, a warm thank you to Kat Walsh, Anna Tumadóttir, and Cory Doctorow for their time!
The 30-day grace period in CC4 does indeed only apply to reinstating the licence, meaning that users are still liable for damages before the attribution was corrected or the image taken down. However, experience suggests that this makes the business model significantly less interesting for companies such as Pixsy, as most courts will hesitate to award material damages for temporary infringements. As long as there are CC2/CC3 licences out there, Pixsy has bigger fish to fry;
Upgrading to CC4 can only be made by adding the licence on top of existing CC2/CC3 licences. Existing attributions, if the user does not update the attribution to CC4, continue to be governed by the old licence. Existing misattributions also continue to be governed by the old licence, but Pixsy would have a harder time convincing a court to award damages. Again, bigger fish to fry;
In theory, deleting images of copyleft trolls does not impact existing attributions, as the licences are irrevocable. However, this business models hinges on fear mongering and information asymmetry, so anything that makes it harder for users to prove they were using the images correctly can help copyleft trolls. One possible solution is to leave the image page online, but only with a small resolution preview of the image;
Regarding Proposal 4, which currently gathers the widest consensus:
A landing page needs to fall short of providing legal advice but can nevertheless be very useful if it includes statements such as "Pixsy is less likely to pursue a case if you do X and Y" and "in scenarios Z and W, the likelihood that Pixsy takes you to court is small";
Upgrading CC2/CC3 to CC4 may be the single most effective action to address copyleft trolling;
Forced watermarks run the risk of rewarding trolls with extra publicity and weakening the position of other photographers that do not have watermarks. Deleting images has proven to be more effective, although at the cost of potentially losing valuable content.
Thanks a lot from me, this seems indeed helpful. I fully agree that the landing page should not give legal advice - in fact, I only expected it to explain the concept of copyleft trolling, and urging (our uploaders) to change to CC4 and linking (the re-users who get threatened) to the page where they can report uploaders that have sued them. But helpful statements on how to withstand Pixsy's legal threats are also a good idea.
Upgrading the licenses is obviously the best way to proceed; but the "bad apples" (I mean those who already engage in copyleft trolling) are unlikely to do so. Four years after the CC-inventor published his article on the supposed Commons-troll from Serbia, the image of his mouse is still up under CC2 and actively used in WP articles.
We are completely lacking the teeth to do on Commons, where Flickr has it a policy to even ban users who upload in bad faith: There are no community rules that are in support of deleting images just because they are used for copyleft trolling. From experience, I don't think we can implement such drastic rules anytime soon: Just notice how many users seemed to support the idea that Diliff did not even do anything wrong - after all it was totally legal and backed by the Commons Rules, so why should anyone outlaw the legal rights of poor Diliff? Also speaking against deletion is that this robs current legal re-users of their proof that they downloaded it from Commons under that free license that they are displaying. The alternatives to deletion are, as I see it: giving copyleft trolls free reign on Commons (status quo, not preferable), or forcibly altering the images in some way. You report that we could only keep thumbnails (the CC lawyers suggestion); the other idea is watermarking the images (still my favorite). I also don't want to encourage watermarking, but if the watermark includes "do not remove this license text, or User:XYZ is likely to sue you", this should not advertise the practice (both of watermarking and of copyleft trolling) to most users, and seem more like punishment. --Enyavar (talk) 21:30, 24 April 2024 (UTC)Reply
Thank you for this, and for getting the discussion moving again. I'd like to ask a few questions.
Re the proposed landing page - when would this be shown? Is it when someone clicks on an image?
The proposer of Proposal 4 links to an image by the photographer Philpot as an example of watermarking. I assume some sort of similar discussion must have taken place regarding him and Marco Verch, who have more clearly and explicitly embraced the practice we've called copyleft trolling. I was surprised they are still allowed to do this and have pictures in WM but there must have been reasons. Can anyone point me to the previous discussions?
Finally I don't know how these WM discussions work - how many people have to vote for one of these proposals to be enacted? Is there a closing date when a decision gets made, or are these discussions advisory to some committee who makes the decision and starts action? Normanlamont (talk) 16:29, 25 April 2024 (UTC)Reply
@Julesvernex2: "Pixy has bigger fish to fry". This completely misses the point. Pixsy doesn't care about enforcing copyrights. They are an extortion scam. They don't actually take people to court, they just harass and intimidate you until you pay them something. They don't actually monitor the infringements, they don't care what actions you take, they just send you various form letters with escalating threats and offers and then apparently keep 50% of the money. It's up to the photographer and photographer's lawyer to initiate any actual legal action (which they almost never do unless its a significant commercial use). Honestly, I don't think forcing people to use CC 4.0 licenses will do much of anything, but since this is the only proposal that has support, I'm supporting it. Right now one of Diliff photographs is on the main page of English Wikipedia because we haven't taken any action. This will probably cause hundreds of additional good faith reusers to get harassed by Pixsy and generate of nice bit of profit for both Pixsy and Diliff, at the expense of the entire free culture movement. We are getting completely exploited and it's sad that so many people are supporting this behavior. I hope we can work together to get this successfully addressed in some form or another. Nosferattus (talk) 17:17, 26 April 2024 (UTC)Reply
"Pixsy doesn't care about enforcing copyrights. They are an extortion scam. They don't actually take people to court, they just harass and intimidate you until you pay them something." hyperbole. Most of law is actually about settling out of court, all with the mutual threats of actually going to court. We might not like it, but let's not pretend that this isn't normal. Maybe people are too young these days to remember w:Napster, but this is just how the legal system works in most place around the world. —TheDJ (talk • contribs) 17:35, 26 April 2024 (UTC)Reply
I don't think it misses anything. All of the copyleft trolling cases I've read about involved CC2/CC3 licences, and even Pixsy seems to have gotten their facts about CC4 wrong ("However, users of images with a Creative Commons license release type 4.0 (or above) are granted a 30-day grace period in which they can resolve breaches of license terms, before it is considered copyright infringement.", [12]). Switching the analogy from culinary to burglary, no lock is unpickable but can nevertheless be effective if it takes too much effort to break in. I do agree though that continuing to promote these images in Wikipedia is perverse. Julesvernex2 (talk) 17:55, 26 April 2024 (UTC)Reply
"Forced watermarks run the risk of rewarding trolls with extra publicity and weakening the position of other photographers that do not have watermarks. Deleting images has proven to be more effective, although at the cost of potentially losing valuable content." Forced watermarks largely prevent the images from being used on Wikipedia, which is how 99% of reusers discover them. So I think it is largely effective at reducing copyleft trolling. I too would prefer deletion, but it seems that the Commons community does not support this. Nosferattus (talk) 00:23, 2 May 2024 (UTC)Reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Latest comment: 21 days ago21 comments13 people in discussion
Dear community,
I believe that the VRT verification system is awful and a major headache to all of us contributors. Major issues can be listed as:
Its extremely hard to get some (in my case, most) people (especially if there is distance, lack of technological understanding and language barrier) sent permission statements directly.
VRT permission text is scary. Some old people genuinely feel like "I am grifting them/trying to get them in some mafia style trouble" or that "they will allow selling their body like prostitutes" (I am not joking, that's a real quote I got from and old fellow) while they generate VRT request text and read the legal yada yada of it because CC-BY SA license clauses are explained in a scary way (and those fellows don't have any issues with clauses of those licenses when they are explained in a basic, non-legal-court-style-scary way).
It makes all of us lose our valuable time that we could be spending for something better, and outcome is not satisfying most of the time even when positive because we go through all the hustle of convincing technologically-illiterate old people to make scary legal consent on a piece of photo/vector recreation that in reality no one gives a single fly about.
End of ranting. So what is my solution(s)?
Allow third party/email forwarding verifications. It will save lots, lots of time and make both parties' job much, much easier. We contributors that spent most of their free time to help Wikimedia aren't grifters. Just try not being paranoiac and assume good faith from a regular contributor.
For VRT: Try using common sense time to time. The 60ish years old aunt won't give a fly about her father's black and white photo in the office from 70s having a free license. If she told me "Yeah, sure" that should be more than enough consent for an individual like her.
How exactly would the third party/email forwarding verification work? Like should we just take any random users word that they got permission or eould they be required to send the VRT team copies of the emails? (I could maybe see that work with a email template that the person would have to sign or something, but I don't see how a random user emailing someone a vague question about it and them replying with something like "sure, whatever kid. Just stop bothering me." would ever hold up in court). --Adamant1 (talk) 21:42, 1 May 2024 (UTC)Reply
I think we accept forwarded mails if they have a signed document attached. For the problem you describe a possibility to send the permission as an actual letter could be a solution. We only would need to have a person at the WMF or a chapter who scans these letters. GPSLeo (talk) 05:48, 2 May 2024 (UTC)Reply
I believe scanned paper permissions are accepted, if done the proper way. They should be joined with some ID document, etc. And no, "Yeah, sure" is not a valid permission for a free license. We have daily dozens of people uploading copyrighted files under wrong assumptions about what is a free license. Yann (talk) 06:35, 2 May 2024 (UTC)Reply
For the family member above the simplest way would be to state that one user is allowed to upload and grant a free license in behalf of the copyright owner like we do it GLAM institutions. Then the copyright owner does not need to think about licenses and only needs to trust the person to whom they delegate the decision. GPSLeo (talk) 12:18, 2 May 2024 (UTC)Reply
An actual signed document would be a lot scarier than an email for old folks. Besides many grifters are able to convince them with email but when it comes to old-style signed verification old folks are more hesitant than any other way around. Maybe an "elderly friendly" verification process can be established that works with a video verification or "simpler and friendly" VRT mail text that states its not that of a big deal. VectorVoyager (talk) 18:57, 4 May 2024 (UTC)Reply
Oppose I am not convinced that there is actually a problem with the VRT process, aside from that - like every process on Commons - it is critically understaffed. It feels like we're one Krd retiring from Commons VRT falling apart, but that's true for about half the project (CU will fall apart if Elcobbola leaves, for example.) The Squirrel Conspiracy (talk) 18:17, 4 May 2024 (UTC)Reply
There are a lot of things on Commons (COM:HMS to add another example) like that. It's also on small-to-mid Wikipedias, Wikisource, etc. and most, if not all open source projects. Maintainence and communication is boring work, and very little people actively have time to do it, let alone to do it for a while. The problem gets worse once you realise VRT agents have to sign a confidentiality agreement. —Matrix(!) {user - talk? - uselesscontributions} 20:16, 16 May 2024 (UTC)Reply
What is so terrible about the confidentiality agreement? It's not exactly prestigious nor exciting work anyways Trade (talk) 06:35, 30 May 2024 (UTC)Reply
Several years ago this elderly Wikiphotographer got a request from Warner Brothers who wanted a signed release for a photo of a Manhattan parade. This was not so much scary as annoying, as I had to download the document and the software to read its format, unjam my printer, print and sign, find my flatbed scanner, and remember how to operate it to send back. Darn nuisance; the picture was already released for free in Commons and I should have charged a $100 paperwork fee. My picture eventually became a background for a Manhattan barroom scene in the "Miracle on the Hudson" movie. I was kind of surprised Warner Bros didn't have an office within a couple miles of me in Midtown Manhattan where I could simply walk in and sign. I guess it would be a dream, to have sign-on-the-dotted-line services in several major world cities with a local Wikimedia Chapter. Or does some commercial chain such as Staples offer such a service? Jim.henderson (talk) 14:53, 9 May 2024 (UTC)Reply
@Jim.henderson: FWIW, I personally have a policy that if anyone wants paperwork filled out to give them more confidence about using my photo, that starts at $50 (and if it were something like Warner Bros. I'd probably say "since you don't want to use this on a free-license basis, what would you normally pay a commercial photographer or a stock company for a photo like this? I expect the same." - Jmabel ! talk17:56, 9 May 2024 (UTC)Reply
It's probably tangential, but why wouldn't someone want to use it on a free-license basis? Like what's the advantage to having the original creator signing a form saying they can use the image when it's already freely licensed for any purpose, including that one, to begin with? --Adamant1 (talk) 19:29, 9 May 2024 (UTC)Reply
If it is not CC-0 this might be needed as there are cases where attribution is not possible or just not wanted. GPSLeo (talk) 19:37, 9 May 2024 (UTC)Reply
"there are cases where attribution is not possible or just not wanted" Doesn't film credits exist for this reason? Trade (talk) 06:36, 30 May 2024 (UTC)Reply
@Adamant1: in my experience there are two reasons: (1) publishers who want paperwork on file with someone swearing up and down that they really are the person who created the work and (2) institutions or businesses that have significant publicity/illustration budgets and would much rather pay someone than give a visible credit. On the latter front, I once got paid quite a bit -- I won't mention the number but let's say a normal month's rent for an urban apartment -- by a beer company that used one of my photos on a set of billboards (they also paid the person who was the subject of the photo about three times as much). Also, a few times when a museum has wanted to do a print to include a photo of mine in an exhibit, it would absolutely have gone against their policies not to pay me. The New Yorker even once paid me (modestly) because they wanted an artist to do a derivative work of one of my photos as an illustration. Etc. - Jmabel ! talk14:40, 10 May 2024 (UTC)Reply
For an additional reason, for a commercial project I'm working on, I'm generally avoiding CC-BY-SA images. I feel I can follow a CC-BY license such that any reasonable licensor isn't going to have a problem. I'm not so comfortable using CC-BY-SA images, with a project that's by and large not CC licensed, in such a way that I know a reasonable licensor can't object.--Prosfilaes (talk) 19:18, 10 May 2024 (UTC)Reply
Strong support - I exchanged 14 emails with a sexagenarian who wanted to release a photo that their daughter took of them specifically for use in their Wikipedia article. After painstakingly walking them through the VRT process (and apologizing for how difficult it was), VRT rejected it anyway since the copyright technically belonged to their daughter. In the end, they just gave up rather than jumping through more hoops. Why do we make this so difficult? Nosferattus (talk) 23:30, 25 May 2024 (UTC)Reply
if setting up an account on wikimedia or flickr/fb/twitter/ig/blog and then posting your images with the cc licence is still too much for you, then really no one can help you.
@RZuo: I agree, but for photos of famous people (i.e. photos with potential commercial value), we sometimes require VRT even if the image is self-uploaded. We need to have a better solution in those cases. Nosferattus (talk) 15:26, 18 June 2024 (UTC)Reply
famous people should have social media, right?
if it's so hard for them to use their social media to make 1 public post declaring the authenticity of copyright of their uploads, nothing can be simpler than that. certainly not VRT.
Latest comment: 5 days ago15 comments8 people in discussion
I asked this first on bot permission page, where they suggested that I should make this as proposal first.
So, I propose that the addition of perceptual hash (phash and dhash) values will be extended to all images on Wikimedia Commons as Structured Data on Commons (SDC) values. Currently, values are added only to a subset of images, such as images from Finna.
Background
Perceptual hashes are checksums which can be used to identify visually identical images even if they have been scaled, re-compressed, or subjected to minor alterations. Proposed hashes are effective for detecting if the images are identical but they are not effective for detecting similarity in cases involving cropping or rotation changes. Hashes are also implementation specific and in this proposal I am using Python Imagehash library.
Confirm that images in the Finna repository match those on Wikimedia Commons, ensuring higher resolution re-uploads and metadata updates are done to correct images in Wikimedia Commons.
Prevent duplicate image uploads.
Find existing duplicate photos.
Update identifiers pointing to external repositories if they have been changed.
These are common use cases for developers of mass upload tools and usage could be extended for other tools also. Adding perceptual hashes to SDC would enable users to easily access the hash values without needing to download the commons image files first, allowing for wider use of the hashes. Additionally, SPARQL queries can be used to detect duplicate photos. Example query: https://w.wiki/A6qZ
Currently, we have hashes for 70 million photos out of the approximately 100 million in Wikimedia Commons in our database. Plan is to calculate phash and dhash values for all Wikimedia Commons jpg, tiff, png, and webp photos during the summer of 2024.
About 40,000 photos from Finna have phash and dhash SDC values.
Web ui imagehash.toolforge.org and REST API for querying the hashes. Hash database can be also accessed usin SQL via imagehashpublic_p Toolforge user database.
For broader accessibility, adding hash values to SDC is the most straightforward approach. As adding hash values to all 100 million photos on Commons using bots is impractical, I suggest the following approach:
Begin by adding hash values to photos uploaded from GLAM archives and Flickr using bots. This would create a platform for tool creators to match photos between archives and check if a photo already exists on Commons. It would also serve as a shared platform with external parties such as GLAM and Flickr Commons to develop the idea further.
Investigate how to implement better methods for including automatically generated information in SDC without the need for adding these using bots. Other similar automatical values could include mime type, image width, image height, file size etc.
Support: This seems to me to be a good idea. Do you have any idea how you'll handle invalidating the hashes when a user uploads a new version of a file? --bjh21 (talk) 15:56, 23 May 2024 (UTC)Reply
One solution could be to track recent changes to index all uploads and then set the latest value as "prominent" and the rest as normal if there are multiple values. --Zache (talk) 20:38, 23 May 2024 (UTC)Reply
@EugeneZelenko: You are actually wrong. If we can calculate similarity by comparing the hashes it contains structured information about the content they represent. --Zache (talk) 14:19, 28 May 2024 (UTC)Reply
Hashes could not create links between items (regular properties) or external sources (identifier properties), so why they are claimed to be structural? --EugeneZelenko (talk) 14:33, 28 May 2024 (UTC)Reply
Structured information can contain other data types than URI:s and identifiers, such as numbers, booleans, strings, timestamps, etc. In this case, perceptual hashes contain information about the content's features in a well-defined format. --Zache (talk) 14:59, 28 May 2024 (UTC)Reply
Support: I agree with the proposal. I already do it for the files imported by User:OptimusPrimeBot. I'm really happy to see new people interested in making things move forward for the perceptual hashes/detection of duplicates. It's still a pain to detect duplicates accurately and this proposal will help to improve the tooling. vip (talk) 22:20, 28 May 2024 (UTC)Reply
Oppose. There may be value, but there is also cost. My watchlist is sometimes hammered with SD additions such as this SVG file is an SVG file. Make additions to millions of files, and the cost might be millions of seconds of people's time. Glrx (talk) 16:12, 17 June 2024 (UTC)Reply
I am sure that you know, but you can also change visibility of the bot edits in the watchlist from settings. -- On more general level comment, I understand your argument, however, there is ongoing flow of files all the time and it is normal (ie. there are bot and other automated edits to categories, wikitext fixes, SDC additions) and solution for that it will fill the watchlist should not be banning those edits as it would block improving the metadata of the files, but improving the filtering/grouping of the changes so that only relevant are visible by default. --Zache (talk) 12:21, 4 July 2024 (UTC)Reply
Question did the already added hashes turn up any duplicates?
Latest comment: 27 days ago4 comments3 people in discussion
Hello community,
Given the somewhat intermittent and consistent issues with CropTool (see talk), I think a user-friendly alternative (read: backup) would provide some help to the community. Allowing a way, on an existing image, for a user to upload an image (such as an "upload as derivation" button) that doesn't replace an image, but automates the existing description templates, existing copyright templates, existing categories, and creating an extracted from template, so the user doesn't have to worry about that connection (and potentially fumbling it). Users can, and often do, make derivations of images outside of Commons, and not only just cropping. Often times, these new uploads may lose a previous detail or lose its connection with the source file because some of these derivation steps are ignored, forgotten, or are too cumbersome for the average user. --Engineerchange (talk) 14:12, 23 May 2024 (UTC)Reply
Latest comment: 10 days ago11 comments8 people in discussion
Processing deletion requests on empty or moved categories is a very often needed but not very critical task that has to be limited to admins. Therefore I would propose that we introduce a new right that allows trusted users to delete categories, galleries and (if possible) own user pages. GPSLeo (talk) 17:09, 24 May 2024 (UTC)Reply
Comment The bar for adminship on this project is pretty low. Are there specific people you can identify that you think should have this new right that would not make good admin candidates? The Squirrel Conspiracy (talk) 17:26, 25 May 2024 (UTC)Reply
I don't think this is technically possible. Per mw:Manual:User rights, it doesn't appear that rights like "delete" can be restricted to specific namespaces. (And given that pages can be moved between namespaces, it's not clear that any such limitations would be effective.) Omphalographer (talk) 03:58, 26 May 2024 (UTC)Reply
It is currently not possible but we need consensus that we want this feature before we can request the development that is requited to enable such a feature. GPSLeo (talk) 16:36, 26 May 2024 (UTC)Reply
Of the last 5000 (un)deletions, >90% were files; just 371 (7.4%) were categories, 3 (0.06%) were user pages, 8 (0.16%) were templates, and <10 were galleries. While I have no objections on principle to unbundling deletion rights, this doesn't seem like it would address any deletion backlogs. It would probably be better to focus our energies on cultivating well-rounded users who would make good admins. Pi.1415926535 (talk) 05:34, 28 May 2024 (UTC)Reply
Support although not technically possible atm, we can request a phab task. Maybe ability to delete everything except files and MediaWiki stuff (similar to eliminator right on some wikis) is a better idea. Thoughts? —Matrix(!) {user - talk? - uselesscontributions} 15:45, 12 June 2024 (UTC)Reply
Oppose No concept shown. Who appoints them, what is the requirement? Can the delete only, or also restore and view deleted versions? If or if not, how is this helpful, and why don't they become regular admins? --Krd18:02, 20 June 2024 (UTC)Reply
Oppose No satisfactory answer to my question above. I'd be happy to entertain an RfA from someone that does category work and wants the mop to do categories for deletion closing, though. The Squirrel Conspiracy (talk) 05:54, 30 June 2024 (UTC)Reply
I could certainly use it. I doubt anyone would give me full privileges just to delete categories though. Nor would even necessarily want them. --Adamant1 (talk) 06:04, 30 June 2024 (UTC)Reply
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Commons:AI-generated media, which was created in 2022, had a lot of debate and refinement last year, but has been completely stable this year and seems to have calcified into something that more or less reflects the community consensus on how to handle AI-generated media. It's been cited in dozens of deletion discussions as well as user talk page and village pump discussions. Should it be made an official guideline? Nosferattus (talk) 19:23, 24 May 2024 (UTC)Reply
Mostly looks good. A few concerns, though: the scope question isn't actually answered; the implications of some of the legal points aren't explained; and AI-modified images are included alongside AI-generated images. For the latter, there are a variety of denoising, sharpening, scaling, "enhancing", colorizing, etc. applications, some of which are AI-based and some not, but with similar effects. e.g. Photoshop has some new AI tools to replace selected areas, which is just a somewhat better version of a non-AI feature called "content aware fill" that's been part of the software for years. We should probably be documenting when a lot of those are used, but in general if it's not an image that's generated by an AI, but rather the modification of existing images, I probably wouldn't include it in this guideline. Otherwise I'd rename the guideline and add a clear section about AI-based, or non-AI-based but powerful editing tools that do the same thing, software used to modify existing images as opposed to the generating new images. — Rhododendritestalk | 14:57, 26 May 2024 (UTC)Reply
At the end of the day there should probably two different guidelines/pages for AI generated images versus AI/normally enhanced ones. Although I think at this point both AI enhanced and AI generated issues have a lot of the same issues, but there probably needs to be separate guidelines for both regardless. --Adamant1 (talk) 16:31, 26 May 2024 (UTC)Reply
The more aggressive end of AI upscaling is very much generating (and occasionally hallucinating) new content that wasn't there before, when the starting image is of low quality or resolution and the software is being asked to serve back a much higher quality version. Something like File:Napoleone Ratti.jpg (derived from the very low quality historical photo File:Napoleone Ratti original.jpg) is basically asking AI to generate an original human face - but using the outlines of a blurry photo as the constrained input, rather than a detailed text prompt. Belbury (talk) 15:07, 4 June 2024 (UTC)Reply
@Rhododendrites: I have removed the small amount of content related to AI-modified media so that the guidelines focus solely on AI-generated media. Could you clarify what specific "implications of some of the legal points aren't explained"? Thanks! Nosferattus (talk) 19:49, 3 June 2024 (UTC)Reply
Thanks. I went ahead and removed another piece related to AI-modified rather than AI-generated content (and a few other minor edits). Hope that's alright. Support — Rhododendritestalk | 21:11, 3 June 2024 (UTC)Reply
Support The European Union passed a law regulating AI. This project should pass the proposed guideline as well, especially for the good of this project. Well, I realize that jurisdictions vary when reading the guideline. Furthermore, certain cases are subjective. The guideline might change substantially... or not? George Ho (talk) 08:08, 31 May 2024 (UTC)Reply
Neutral. While I certainly feel that a policy on AI-generated and retouched content on Commons is necessary, it's not clear to me that this document provides any substantial guidelines yet - as it currently stands, it's primarily focused on the legality of AI-generated content, not whether it's appropriate for Commons. Omphalographer (talk) 21:39, 2 June 2024 (UTC)Reply
The only one that concerns me is you are expected to document the prompt used to generate the media in the file description. I'm not sure that is, strictly speaking, necessary to have freely-licensed content and may be something that users may not want to document. Not sure why we would require that in general, though maybe could be proof of authorship for previously-published works to avoid VRT. Most everything else seems OK. Carl Lindberg (talk) 00:43, 5 June 2024 (UTC)Reply
Agreed. This guideline doesn't make a lot of sense anymore, given that many popular hosted image generators (e.g. ChatGPT, Bing Image Creator, Midjourney, etc) don't use a textual prompt in a way that's visible to the user, and are frequently updated in ways that would make results non-reproducible anyway. Omphalographer (talk) 02:40, 5 June 2024 (UTC)Reply
I believe I was the first to put forward the proposal that prompts be documented; if not, I was one of the first, and I still stand by it. It was never about reproducibility. It was/is about two things: (1) if an AI image is being put forward as representing something in particular, it seems important to know whether that was present in the way the AI was prompted, vs. someone saying after the fact "hey, that looks kind of like such-and such." (2) There may be some historical value in knowing what might have been a typical output for a given generative AI at some point in its (presumably ongoing) evolution. Frankly, for most outputs of generative AI, that documentation of the AI itself is about the only reason they should be of any educational value at at all. - Jmabel ! talk05:05, 5 June 2024 (UTC)Reply
They would certainly be helpful, and maybe could be encouraged, but this seems to say they are required, and seems like it would generate DRs on that basis alone. Changing "expected" to "encouraged" would be fine for me. Carl Lindberg (talk) 10:16, 6 June 2024 (UTC)Reply
Even if you can't make a 100% accurate reproduction of an image with a prompt they are an important way to know if it's potentially a derivative work or not. --Adamant1 (talk) 05:53, 5 June 2024 (UTC)Reply
Striking Oppose.0xCollection Dvorak DreamsMuch or most of these proposed guidelines such as How should AI-generated media be handled? seem to be written entirely for specifically user-generated content created with prompt-based text-to-image generators of the past couple years, rather than for AI-generated media in general. At the very least, this would need to add clarifications that this proposed guideline is for the subset of AI-generated media that is created through prompt-based software. For example, I am including here a photo of AI-generated media by Refik Anadol. For this type of image of AI-generated media or anything similar, it doesn't seem helpful to have this guideline saying "give the name of the specific AI engine used, followed by the name of the person who created the prompt ... you are expected to document the prompt used to generate the media in the file description." Elspea756 (talk) 17:13, 5 June 2024 (UTC)Reply
I have no idea what software was used for that work, and I also have no idea whether any prompting was used or not in creating that work, or who would have created any prompt(s) if they were used. I suppose anyone who thinks this a good proposed guideline as it currently is should then feel free to follow the proposed guideline and provide "the specific AI engine," "prompt used for that image," and "name of the person who created the prompt" for that image. I have added it to my watchlist, so I will see any of your updates as you follow this guideline. Elspea756 (talk) 18:42, 5 June 2024 (UTC)Reply
I am not interested in any of this information, but, yes, anyone interested in the "the specific AI engine," "prompt used for that image," and "name of the person who created the prompt" being called for in these proposed guidelines would likely have to try to contact those three. I have already added the image to my watchlist, so I will see any of your updates as you get responses from them as you follow this proposed guideline. Elspea756 (talk) 19:11, 5 June 2024 (UTC)Reply
The fact that there may be a few AI images where this cannot be determined is not much different that the fact that we have some anonymous older artwork, or things that are clearly in the PD for which we don't have clear sourcing. Those don't change the general requirement that images should indicate author and source. -Jmabel ! talk05:13, 6 June 2024 (UTC)Reply
Yes, "images should indicate author and source" is a guideline I would support. The proposed guideline of "the specific AI engine," "prompt used for that image," and "name of the person who created the prompt" is not something I support. Elspea756 (talk) 13:43, 6 June 2024 (UTC)Reply
If we know that little about it, how do we know there is no human authorship, making it a copyrightable work and the photo therefore a derivative work that needs someone else's permission? Carl Lindberg (talk) 10:22, 6 June 2024 (UTC)Reply
The uploader says "I, the copyright holder of this work, hereby publish it under ... the Creative Commons CC0 1.0 Universal Public Domain Dedication." I don't think the uploader following the proposed guideline and also listing a "specific AI engine," "prompt used for that image," and "name of the person who created the prompt" would make any real difference. Elspea756 (talk) 13:49, 6 June 2024 (UTC)Reply
That's fine for the photograph, but what about the pictured artwork? What is the license on that? If copyrightable, the photograph is a derivative work. Carl Lindberg (talk) 01:29, 7 June 2024 (UTC)Reply
At the end of the day guidelines are just that, guides. They aren't policies. But its good to say it would be worth including the prompts then not, because I can guarantee most people don't or won't think about it to begin with. No one is calling for anyone who doesn't include a prompt to be blocked or anything though. So this whole side thing just comes off as super nitpicking. Since when are we not allowed to make suggestions about best practices or guide people on the best way to do something? Because that's literally all this is. --Adamant1 (talk) 02:08, 7 June 2024 (UTC)Reply
If this is written entirely as a guideline for specifically user-generated content created with prompt-based generators, rather than for AI-generated media in general, I think that should be clear, rather than being described as for all "AI-generated media." Elspea756 (talk) 03:09, 7 June 2024 (UTC)Reply
I don't even necessarily disagree, but then that alone isn't a valid excuse to hold up the whole thing either. It's not like the few minor issues can't be resolved once it's implemented. Otherwise it's just bikesheding. --Adamant1 (talk) 09:58, 7 June 2024 (UTC)Reply
I get the feeling you think that's of gotcha or admission of something about this on my part. Regardless, I'd totally support improving the guideline after its implemented of course. That's usually how it works with guidelines. Proposals are just that though, proposals. They aren't meant to be 100% accurate documention of every single possible edge case or over exaggerated scenario and you can't really improve a guideline that exist to begin with. So...I'm all for improving things once they are implemented though. --Adamant1 (talk) 12:54, 7 June 2024 (UTC)Reply
No, that is not a "gotcha" at all. That is a sincere "thank you" for saying you don't disagree with the changes I've suggested to the proposed guideline. I wasn't not expecting so much disagreement from others to what I thought was a very reasonable, clear, and simple suggestion for clarifying the scope of much of the proposed guideline. I am currently making some of those changes to the proposed guideline so that I can hopefully support this proposal. Thank you again. Elspea756 (talk) 13:03, 7 June 2024 (UTC)Reply
Uh OK. Thanks for clarifying what you meant. I guess I just always assumed it was exclusively for AI created artwork since the guideline is literally called "AI-generated media", not "AI enhanced media" or whatever. It would probably be to everyone's benefit to just create Commons:AI-enchanced media as a side thing to main guideline specifically for that aspect of AI software though. --Adamant1 (talk) 13:12, 7 June 2024 (UTC)Reply
To be clear, yes, I am talking about "AI-created" media. Not all AI-created artwork is created with a system that uses prompts, but this proposed guideline was largely written as if that were the case. I've made the sort of edits that I'd proposed in my original post here, making clear that certain sections are only for the subset of AI-generated media that is created through prompt-based software, and clarifying in other sections that the proposed guidelines are referring to all AI-generated media, not just that created through systems that use prompts. These changes can be seen here.[13] I will wait maybe 24 hours to see if these changes are accepted, or wait to hear from any of the people above who opposed my suggestions, and if my changes are accepted, then I will switch to "support." Thank you again, Adamant1, for not opposing my proposed changes. Elspea756 (talk) 13:31, 7 June 2024 (UTC)Reply
I think it's inherent to the thing that if someone can't provide a prompt for whatever reason that they don't have to. Just like it's a guideline that people provide the original author of something but there's still exceptions for anonymous works. Although I can't think of an AI image generator that doesn't involve some kind of prompting to begin with. But then it doesn't really matter, because no one is being forced by this guideline to provide a prompt if there isn't one to begin with. --Adamant1 (talk) 13:39, 7 June 2024 (UTC)Reply
Support Yes, with the clarifications I've made, that Adamant1 said they don't necessarily disagree with, that have survived the weekend, yes, I can now support this proposed guideline. Elspea756 (talk) 23:39, 10 June 2024 (UTC)Reply
@Elspea756: Yes I have, including the section Copyright of AI-generated media modified by humans. If the image was entirely AI-generated it's fine, but if there were significant human alterations later, it's not (the additional human contribution can easily have a copyright). If we know nothing about the image, it's dangerous to assume how it was made. Carl Lindberg (talk) 13:46, 7 June 2024 (UTC)Reply
There is a bit of a stretch between "we need all the detail" by Carl Lindberg and "Nah, it`ll be fine" by Adamant1 and associates. Having looked at most of the stuff uploaded for one week, I tend to go with we need all the info. Alexpl (talk) 14:05, 7 June 2024 (UTC)Reply
I wouldn't say that's my position. I'd just like see a proposal get approved for once instead of getting dragged down by pedantry. Although I have yet to see a legitimate argument for why prompts should be required, not just suggested. Let alone why AI enhanced artwork should be included in this. So I'm more then willing to throw chum to the people who think they don't matter as a compromise so this doesn't just get derailed over something that probably doesn't really matter in the grand scheme of things, if at least at this point, anyway.--Adamant1 (talk) 17:45, 7 June 2024 (UTC)Reply
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Add new speedy deletion category: "F11. Non-notable fictional flags, maps, and coats of arms"
Latest comment: 22 days ago48 comments24 people in discussion
A significant percentage of recent DRs are of flags, maps, and coats of arms created by the uploader for their personal fantasy projects. These DRs pretty much universally end in deletion because they fall outside of COM:SCOPE. Being able to speedy delete these would go a way towards alleviating the chronic backlog at DR. Therefore, I am proposing an addition to Commons:Criteria for speedy deletion as follows
This wording should allow for flags, maps, and coats of arms of notable fictional entities (i.e. ones with articles on sister projects, such as the coat of arms in en:Gondor) but disallow everything else.
An argument can be made that these images are already covered by F10, but it would be better if there were clear community consensus (either for this F11, or that non-notable fictional flags, maps, and coats of arms are covered by F10). The Squirrel Conspiracy (talk) 03:55, 28 May 2024 (UTC)Reply
Support This is long over due. I think its also in alignment with the guidelines that people don't use Wikimeida projects to spread misinformation to. There's a big difference between uploading a flag related to a fictional universe and uploadong one that solely exists to misinform people and spread discord. There's no reason we shouldn't be able to speedy delete the later as OOS. --Adamant1 (talk) 04:06, 28 May 2024 (UTC)Reply
Support I do think this is covered by F10, but it's a boilerplate deletion argument that deserves a clear and concise template. I also think it's time for an "F[x]: images of genitalia that do not substantially differ from existing ones" but I'll wait for this proposal to go through before proposing it. Dronebogus (talk) 04:17, 28 May 2024 (UTC
Neutral. I appreciate the intent, but I'm not sure how useful this would be in practice. In my experience, it's relatively uncommon for fictitious flags to be explicitly called out by the uploader as fictional/fantasy images; it's more common for them be described as a "National Flag of the Greater Fleemistan Empire" (or whatnot), where it only becomes clear that the flag is fictitious after one confirms that there is no real or historical Fleemistan, or that its maximum extent was the creator's apartment. Whether a flag is "fictitious" at all can be a bit of a matter of opinion, especially when it comes to micronations; I don't think it's sufficiently clearcut for a CSD. Omphalographer (talk) 04:18, 28 May 2024 (UTC)Reply
I had thought of that myself but the occasional undeletion request if someone gets it wrong would be way less taxing on the system then DRs. Plus maybe it will encourage people to better source images of flags going forward, or at least make them think twice about uploading the image if they can't. No one has any business uploading unsourced, self created "flags" (or really anything else) anyway. --Adamant1 (talk) 04:44, 28 May 2024 (UTC)Reply
Support I strongly agree with having an explicit speedy deletion criteria for these files. They are unambiguously out of scope and tend to be very easy to spot (much of the time, they're uploaded for use in enwiki sandboxes, which are used for off-wiki forums and games.) The few that are less obvious can go to DR. F10 also wouldn't cover files uploaded by users who do have some good edits, whereas this would. @The Squirrel Conspiracy: Thanks for this proposal. How would you feel about adding election apportionment diagrams, which tend to be misused for the same purposes? Pi.1415926535 (talk) 05:13, 28 May 2024 (UTC)Reply
Weak oppose I do not think it is good idea to have this as a highly visible reason for speedy deletion as this will be missused for edit wars by people how want a file deleted for political reasons. But we should write this as a deletion reason into the longer description of reasons. GPSLeo (talk) 08:52, 28 May 2024 (UTC)Reply
Weak oppose because the notability is sometimes very difficult to determine, and an SD does not give a chance to discuss that. - Jmabel ! talk17:50, 28 May 2024 (UTC)Reply
@Jmabel and GPSLeo: How would Flags, maps, and coats of arms of fictional entities created by the uploader work for you? Micronations are of arguable notability, so I agree they're poor candidates for CSD, but a lot of what we get is uploaders' personal fiction, or things like the flag they made for their Minecraft clan. That's really what this proposal is aiming at. The Squirrel Conspiracy (talk) 02:17, 29 May 2024 (UTC)Reply
* The problem is, how do we know that is what they are? (I'm not saying that problem can't be overcome, but I don't see how.) For the most part, flags will be "own work" whether notable or not, because for "legitimate" flags the user will have worked from a blazon. I don't know enough about Minecraft to know, but I take it that a "Minecraft clan" is inherently non-notable, so that will presumably be deleted one way or another. Do we actually get a lot of that and I've just been lucky enough not to see them? How large a problem are we talking about here? What I don't want to see is something where (for example) someone might see an unfamiliar (to them) variant of a pride flag, or an unfamiliar regional flag such as the now pretty well-known Category:Doug Flag ("flag of Cascadia") and have that go to a speedy deletion rather than discuss whether the flag in question has any real-world currency. - Jmabel ! talk02:56, 29 May 2024 (UTC)Reply
*:As an aside, most images of the Doug Flag (which probably includes most of the ones currently in the category) can be speedily deleted as copyright violations, as the flag isn't freely licensed. Omphalographer (talk) 03:31, 29 May 2024 (UTC)Reply
I'll wager the micronations with any kind of scope presents makes up a very small minority compared to the overall number of micronations Trade (talk) 07:02, 30 May 2024 (UTC)Reply
Oppose A content-based IDONTLIKEIT instant deletion excuse is the antithesis of what speedy deletion is for.
Yet again, speedy deletion is only there for when a deletion is 'unarguable', and thus we can save time because it's assumed that no reasonable editor here would be against that case. This absolutely does not apply when we get into subjective issues like this. Speedy deletion is not here for "I can't be bothered making a case at a DR" or "I want it gone before anyone notices" deletions. Andy Dingley (talk) 18:18, 28 May 2024 (UTC)Reply
I really struggle to see how you get from my proposal to IDONTLIKEIT. Fantasy flags, coats of arms, and maps where the entity being depicted isn't notable are pretty unarguably out of scope. I can't recall a single case where the flag of someone's CoD clan or the map of their D&D world wound up being kept. The Squirrel Conspiracy (talk) 01:02, 29 May 2024 (UTC)Reply
Again, though: what is the threshold of notability for a fictional entity? Is it often so clear-cut as to allow a speedy deletion? Yes there will be clear-cut cases one way or another (delete the map of the world of a particular user's unpublished novel; keep the map of Tolkien's Middle-earth) but there may be others much harder to decide, e.g. a map related to a story that shows up in a magazine but was never anthologized, a map related to the imagined wanderings of Shakespeare in some published but not famous piece of historical fiction, etc. - Jmabel ! talk03:03, 29 May 2024 (UTC)Reply
What's a 'fictional entity' ? And more to the point, what's acceptance criteria for media associated with it? (WP:NOTABILITY is not the relevant criterion). Shakespeare and Tolkien are both fictional, yet notable. If I draw a flag of Orsino or of Gondor, then that's a candidate for a DR. If JRRT drew one, it isn't (licensing apart). This sort of distinction puts it outside of CSD's scope. We have Category:Doug Flag which is fictional and the notability of which could be questioned. Yet we have File:2015 Fremont Solstice parade - Cascadia 04 (18695948883).jpg that surely belongs here as reportage. Should it now be speedy deleted without discussion because it's a 'fictional flag'?
We've had deletions in the past on flags that were fictional, but also INUSE and notable to the point of having articles on that specific flag: en:Proposed flag of North West England. Yet they'd now be up for speedy deletion. We even have File:Flag of Yorkshire (Flag Institute).svg, a "Fictional, and mis-described, flag for a fictional region." yet it was opposed (just to argue with the nominator!) and then kept. The DRs on fictional flags are far from clear-cut and replaceable by CSD. Andy Dingley (talk) 13:52, 30 May 2024 (UTC)Reply
after considering the matter, I will stay Neutral - I don't think there has been a recent increase in that material. Most is years old and just wasn't noticed before. If there is an increase in uploads, then it's only because we have been more lenient in the past, but the more we manage to purge here, the less inviting we are for more of it. Aren't we on a good way already? The many recent DRs might have been noticeable because I went on a spree against such non-categorized maps and flag maps. Yes, most of the stuff gets rightfully deleted in the end, but this gives material a chance to get reviewed: maps may be of notable work of fiction (that I don't know) after all. The formalized DR gives the uploader some time to respond. --Enyavar (talk) 09:30, 29 May 2024 (UTC)Reply
Why is it 'regrettable' that something is INUSE? It's just not within Commons' scope to tell other WMF projects that they shouldn't be using particular content (licensing apart). It's not 'rightful' to delete content that's INUSE elsewhere. Andy Dingley (talk) 13:52, 30 May 2024 (UTC)Reply
Several things are true here. I want to express my belief as a hobbyist historian that any usage of 'history maps' where the Roman Empire conquered half of Scandinavia, or the invented 'flags' of Bronce-age Sumer, are regrettable and should by all rights get deleted. But that is my view. If the Volapük Wikipedia decides that their rules don't prohibit people to show seven-fingered AI-art and fanfiction flagmaps for their educational articles about the Proto-Atlantian Empire: Also true, Commons cannot do anything about that. (But editors can, and in extreme cases I will continue to replace/remove fake imagery in other projects, to ensure it is no longer in use.)
On yet another hand, I'm not convinced that we need this specific speedy criterion. I don't even think it could save much time: Admins still have to judge those images and decide if the DR (or Speedy DR) has merit. What is gained by adding urgency? --Enyavar (talk) 22:58, 30 May 2024 (UTC)Reply
So for anything for which there's a fanart site which might overlap with us as a potential host, that's a reason for an undiscussed deletion? Andy Dingley (talk) 15:06, 30 May 2024 (UTC)Reply
Support But requirements for notability should be relatively low, e.g. not requiring lots of reliable sources to report about this flag, it's enough it's fairly popular and/or some non-notable sources reported about it. The latter could still get DRs, just not speedy ones. Prototyperspective (talk) 15:01, 30 May 2024 (UTC)Reply
Some users often claim this is a requirement-type criteria for one type of content and I always opposed that. Here it is proposed as a requirement for fictional flags. I agree that for this type of content fictional flags need to be notable. As for what constitutes notability for this type of content: I don't think this needs to be very explicit and it's exactly what's addressed in my comment. I hope this answers your two questions. Prototyperspective (talk) 22:27, 5 June 2024 (UTC)Reply
Some users often claim – Which still doesn't make it Commons policy. If they claim that, they should be reminded of what the policy is.
We should not change COM:SCOPE (because that's what this is) for one subject area (!), especially not when it's only because some editors don't want the trouble of going through a DR. That's all this is. Anything you think is against SCOPE already, just DR it. We've always been able to do that. But this proposal (and any like it) should never change SCOPE, we should never change SCOPE to deal with a single subject (putting special cases like this outside SCOPE is a truly awful idea), and we never need a CSD reason on the basis of exceptions like that; if they're exceptional then they're DR territory at the very least. Andy Dingley (talk) 22:37, 5 June 2024 (UTC)Reply
This isn't changing COM:SCOPE - these files are already consistently deleted at DR on scope grounds. This is simply making official the consensus from those DRs: that uploads of this relatively common type do not belong on Commons due to COM:SCOPE, and thus can be speedily deleted rather than needing a DR in order to reduce administrative work. F10 and G10 are existing speedy deletion criteria of this exact same nature; like this proposal, they are simply implementations of the existing scope consensus. Pi.1415926535 (talk) 01:32, 6 June 2024 (UTC)Reply
That's simply not true: uploads of this relatively common type do not belong on Commons due to COM:SCOPE implies that just being 'of this type' is a sufficient condition for deletion. It isn't: the situation is complex and even if most are deleted (yes, most should be) that still doesn't make it a blanket rule, beyond any challenge. 'Fictional' is broad and vague, and that's why this should never be a condition for CSD.
Secondly, we should also remember a couple of bits of fundamental Commons policy that this proposal is casually changing. the consensus from those DRs – but DRs don't set a consensus. We operate by policy, not by precedent. And even though we regularly do, those are mistakes and we should stop doing that! Past DRs don't change policy.
Even the title of this proposal is a problem: Non-notable fictional flags, maps, and coats of arms. Notability just isn't a thing at Commons – it's not how Commons is constituted. You can't replace COM:SCOPE with en:WP:EN just like that! Andy Dingley (talk) 02:27, 6 June 2024 (UTC)Reply
Support Agree with Prototyperspective, though. Should only apply to really unknown personal inventions (of which there are a lot). Gestumblindi (talk) 16:01, 30 May 2024 (UTC)Reply
Oppose Not common enough to be a CSD criterion, and not sufficiently clear-cut since SCOPE is debatable. For example, a fictional map created using a particular map creation software may be in-scope as an illustration of the capabilities of the software. -- King of ♥ ♦ ♣ ♠16:48, 3 June 2024 (UTC)Reply
Support - This is a sensible rationale on its own, and a helpful clarification of speedy deletions that are already allowed and proper under F10. Opposition above is without merit. There is no reason to believe a new F11 criterion would increase or enable nationalistic edit warring (as long as any deletion whatsoever is allowed, those so inclined will fight over it), and admins (those carrying speedy deletions) are not automatons and are perfectly capable of differentiating garbage fictional maps/flags (which are, in fact, very, very, very common) from non-official maps/flags that may have educational value. We admins are generally not credulous fools, and are able decline speedy nominations and convert to DRs. Эlcobbolatalk19:56, 3 June 2024 (UTC)Reply
Oppose There is a significant grey zone that needs discussion (or more than one pair of eyes) and saying "only clear cases" won't stop speedies of files in that grey zone (including maps and flags for notable fiction, as noted above). Also, I think Enyavar is right in that the work needed to create and decide on a DR doesn't take much more time than doing the research for this kind of speedy. –LPfi (talk) 12:34, 4 June 2024 (UTC)Reply
Speedy deletion has almost no categories which are related to COM:SCOPE, because such things should be extremely obvious and many scope discussions are not. G10 is the only one that involves project scope at all, and is limited to advertisements where there is no scope argument. This expands speedy deletion into areas which are normally project consensus, not one person's opinion. The concept of "notability" is nowhere else in the speedy deletion criteria, because that can often be contentious. Speedy deletion allows one person to make that decision, can be rude to new contributors, and leaves no record of why someone thinks it was non-notable, making it harder to argue or know if it was a bad decision -- if someone disagrees with such a decision, is that grounds for an automatic un-deletion to convert to a regular DR? I do understand the sentiment, that flags etc. for entities invented by the uploader themselves are not really educational. I could maybe see something with more narrow wording, but not sure I like it as-is. Carl Lindberg (talk) 10:49, 6 June 2024 (UTC)Reply
Support we already have vaguely defined speedy deletion criterions that can go either way in edge cases (G10, U3, F10, etc.). In these cases we rely on the admin's judgement, and ability to be more conservative, so 75% of the obvious junk is out, 20% of the questionable stuff gets sent to a DR and then deleted, and 5% is kept (not accurate figures but you get the idea. This is more efficient than going to DR every time, and there won't be that many false positive deletions as well. Having said that, I would want to make one suggestion: this does not overrule INUSE, i.e. if files are INUSE they are not valid under this criterion. —Matrix(!) {user - talk? - uselesscontributions} 16:03, 12 June 2024 (UTC)Reply
Yeah, but those have strong unwritten precedents as to their exact use— F10 is basically "vacation snapshots and selfies from people who never edit anywhere else", G10 is just another term for spam, and U3 is deliberately vague and broad because it's mostly an "I know it when I see it" thing— we don't need to enumerate that a userpage consisting of a giant image of a penis goes against community standards, because it obviously does. I think this proposal might need to be rewritten slightly, as I outlined below, to make it sufficiently specific. Dronebogus (talk) 19:31, 17 June 2024 (UTC)Reply
Oppose, yes fictional flags and costs of arms are definitely a problem, but I don't think that speedy deleting them is a good idea. For one, sometimes flags deemed "fictional" by some later turned out to be true, while working with Vietnamese political parties at Wikipedia I found that a lot of documented real flags were already deleted here because people kept tagging them for speedy deletion or because they were merely unsourced (sometimes people source Wikipedia but not the images). Another issue is that flags and emblems are often misattributed, it's not uncommon for some Medieval flag book to contain false information on flags of various countries that never had flags or that 19th (nineteenth) century flag charts misattribute various flags. Often questions surrounding flags are so complex that these are better discussed in more details at a deletion request than through a speedy deletion. If a fictional flags is deleted and then re-uploaded they can easily be deleted through the G4 criterion. The flag of the Ilkhanate is another great example of a flag that is likely fictional, but because it was often used in the 1375 Catalan Atlas it is commonly used to depict this historical nation. Personally, I would prefer for there to be a policy that notable fictional and speculative flags have their names changed from something like "File:Flag of the Ilkhanate.svg" to "File:Fictional lag of the Ilkhanate.svg" or "File:Speculative flag of the Ilkhanate.svg" to clear up confusion. Oftentimes fictional flags are notable and educationally useful by themselves, it's just that they are uploaded with file names that lends false legitimacy to them which can spread misinformation.
Re-reading the proposal I see that it's about non-notable flags of fictional entities rather than fictional flags as the title implies (I should probably sleep rather than read these at 01:28). I still see potential issues with these as a book can be a best seller with a large fan community online and not s single Wikipedia dedicated to it, not because it's not notable but because nobody has bothered to write it or if someone did it was by a fan that didn't know how Wikipedia works and got the article deleted because they don't know how to properly add secondary and tertiary sources. There are plenty of notable topics that don't have a Wikipedia article yet, I don't see why Wikipedia should be the arbiter of which best selling novel should or shouldn't have media about it here. --Donald Trung 「徵國單」 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:32, 16 June 2024 (UTC)Reply
@Donald Trung: You think something like "personal" or "made up" flags would be better? Because I mostly agree with the sentiment of your comment but then there's clearly a problem with people uploading images of non-exiting flags that we need better way to deal with then just sending them to DR. --Adamant1 (talk) 23:42, 16 June 2024 (UTC)Reply
But people obviously aren't. This is some strange circular logic— "this wouldn't be a problem if it wasn't a problem", as Yogi Berra might put it. Dronebogus (talk) 19:19, 17 June 2024 (UTC)Reply
Oppose. Yes, the flags may be a problem, but the proposal troubles me. First, "notable" may need debate. Second, the rule is about narrow content rather than a general category; that could invite more narrow rules. Glrx (talk) 15:59, 17 June 2024 (UTC)Reply
Comment I think the problem is we're failing to distinguish between non-notable, but serious flags (like most proposals for real groups/entities), flags that are otherwise out of scope (i.e. overly speculative historical reconstructions) and user-generated fantasy flags for made-up concepts, which nominally fall under F10 but could have their own template since F10 is typically used for "not your vacation album" type photos. Maybe the proposal should be reworked around this specific, third concept (F11: user-created flags for personal or facetious entities) and be exactingly clear about what it means. Dronebogus (talk) 19:19, 17 June 2024 (UTC)Reply
I was actually just going to say that. We need to better define our terms here and make it clear that things like legitimate flags from fictional universes aren't included in it. The main problem we are trying to solve here is with overly speculative historical reconstructions and user-generated fantasy flags for made-up concepts that shouldn't have to be sent through the DR process. --Adamant1 (talk) 19:40, 17 June 2024 (UTC)Reply
Latest comment: 18 days ago19 comments11 people in discussion
As I wrote at Commons talk:Copyleft trolling, "Let us consider either rearranging file description pages to put the licensing first, or putting a "Licensing" link (in the appropriate language, to the licensing selection further down) above the file display. I don't know how feasible either would be." — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:18, 31 May 2024 (UTC)Reply
I think before proposing options for people to vote on, it would be better to discuss. The "licencing" box itself isn't particularly useful. It is more about declaring what I, photographer, allow you to do and rather vague on what you, reuser, must do. Also people don't tend to reach the Commons file description page via Wikipedia as most readers on that project will get the image page that has a different appearance and layout for licence/reuse (try browsing Wikipedia logged out to see it, if your preferences are to go straight to Commons). But for our pages, there is actually a box at the very top. It might have "nominate for QA" as the first thing, if you are a logged in user, otherwise it has links for Download, User this file (HTML and Wiki), Email a link and Information. But if you click the red [x] box on the right, it goes away and I don't know how to get it back (delete cookies?). So that's a steaming pile of crap that could be improved. How about it never goes away and has a big bold warning "This file is not public domain. To reuse, you must follow the licence conditions" or similar. -- Colin (talk) 14:16, 1 June 2024 (UTC)Reply
@Colin: Does that box's code alter how it is displayed depending on PD or license template? It wouldn't do to tell users a file is not PD when it is. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:25, 1 June 2024 (UTC)Reply
We already have a link with "cite this page". This tool should be adjusted to create a citation for the file instead of the file page. GPSLeo (talk) 14:36, 1 June 2024 (UTC)Reply
@GPSLeo: That tool links to special page Special:CiteThisPage, which would still need consensus and Developer help to change. Reusers who get in trouble are already ignoring the Attribution section in the "Use this file (on the web)" link in that tool, what makes you think they would click "Cite this page" instead? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:45, 1 June 2024 (UTC)Reply
The "cite this page" link always works. The "Use this file" Javascript popup has an outdated layout and might not work on all platforms. GPSLeo (talk) 16:01, 1 June 2024 (UTC)Reply
Sounds like I'm talking about the "Use this file" Javascript header. It looks like something from last century and really small. And the fact you can dismiss it and never see it again is awful UI. Jeff, yes, whatever code would need to detect the licence template and show different message for PD vs CC. But I do think a pretty message banner would be really useful to reusers, particularly those with limited attention and care and who think everything on the internet is free. -- Colin (talk) 06:24, 3 June 2024 (UTC)Reply
I appreciate the idea, but I don't know if this fixes it. Most users will see the Media Viewer page first rather than the file page, which does put license and attribution information right there next to the image. However, it relies on someone knowing what in the world this "CC BY-SA 4.0" thing is. Yes, professionals should know, but it's the independent/individual reusers that we most need to protect, and for that we need language that's visible, yes, but also clearly explained (in a way that shows up on either the file page or the media viewer). — Rhododendritestalk | 14:14, 3 June 2024 (UTC)Reply
Comment a huge bunch of files don't have proper licensing - most often that is "Own work - CC 4.0" as suggested by the Upload Wizard, when in fact it is pd-old, or even copyrighted. Will we restrict the changed license display to files that have been reviewed to actually be the proper license, and how would that review process look like? --Enyavar (talk) 16:32, 21 June 2024 (UTC)Reply
Rearrange file description pages to put the licensing first
Oppose Most reader don't want to directly use an image but would find info in the description very helpful. Often the description includes important context. It shouldn't be buried underneath the license info which can be easily found when needed or even right away. --Prototyperspective (talk) 12:30, 3 June 2024 (UTC)Reply
Oppose. Let's not rearrange page layouts every time one editor thinks it should be different, especially since the reasons are so subjective anyway. IMO, the description is more helpful to have first. --P 1 9 9✉13:53, 3 June 2024 (UTC)Reply
Hi @Schlurcher, yes, this tool has been developed prior the survey, in line with our research about relieving moderators from some burden of work. I know for a fact that the results of the survey has been presented to higher management, and I know that they have been considered for this fiscal year (1 July 2024 - 30 June 2025), but I don't know yet which one will be implemented. I'll try to keep you posted on this. Sannita (WMF) (talk) 12:39, 5 July 2024 (UTC)Reply
I'd first want to see evidence that, in general, IPs are bad at creating categories, not that one person bad at creating categories happened to be editing without logging in. - Jmabel ! talk05:22, 16 June 2024 (UTC)Reply
@Jmabel: You are right, there are some, spread over several years, but that cannot be labeled as a pattern.
Latest comment: 12 days ago22 comments6 people in discussion
Hi all,
Following an idea I've brought up before, I've drafted the first version of a new project to be named WikiProject Earth.
Its main goal is to outline a workflow to upload and organize georreferenced image sets (mostly UAV but not exclusively). If this project runs well and we get enough data sets that match these conditions, the applications of the data we'll collect will be virtually limitless. Potential uses include creating an open-source Google Earth-like app, producing detailed orthomosaics of relevant places, geolocating any photograph depicting covered sites, and much more.
Anyone interested should feel free to comment with support and suggestions, and, by all means, be bold and edit anything you'd like on the drafts above. Any contribution will be greatly appreciated. I'd particularly like feedback on the guidelines for file naming and categorizing.
Pinging @GPSLeo, Pigsonthewing, and RZuo: since they participated in the original conversation.
"WikiProject" doesnt need approval on commons. you just need to find a bunch of users working together. afaik.
as long as the photosets are put into their own categories which are nested under the location categories (e.g. "cat:aerial photoset ab1234 of london, england" somewhere under "cat:london") so that the photos dont bombard the main location categories, for me it's perfectly in scope and beneficial.
@RZuo: thanks. I do realize there's no formal requirement of approving a WikiProject here but I'd like to run it by the community anyway because:
each set typically includes hundreds or often thousands of pictures. Any upload will potentially "flood" monitoring pages and post-upload changes can be time consuming and confusing, so it's best to incorporate any contributions before uploading starts;
several, probably most of the individual photos will not be particularly relevant for Commons even if the entire set is. So this is potentially something of a paradigm shift for which some of the usual processes (i.e. dealing with photos individually, say, in a RfD) will not do.
These are off the top of my head and there might be additional considerations to be made. Once the community has had a chance to weigh in I'll gladly publish the Project and promote it through the relevant channels.
Once again, thanks for the input. I'll be sure to go over the discussion you mentioned and gladly support it however I can. Cheers.
I'd like to note that I strongly oppose this name of the WikiProject: it is misleading and inappropriate. One would think it's about environmental protection, nature, and Earth sciences etc but it's not. Please choose another name, for example "WikiProject GeoEarth" "WikiProject Geolocations" "WikiProject Mapped Files" or something of that sort. Prototyperspective (talk) 10:29, 26 June 2024 (UTC)Reply
Don't know if it's just a joke. Something of that sort could also be fine but not Street View as it wouldn't only display media taken from streets / with views from streets. Prototyperspective (talk) 11:04, 27 June 2024 (UTC)Reply
Sort of. It's not really clear what exactly the Wikiproject is suppose to be focused on though. So I agree that "WikiProject Earth" is probably misleading. But then I guess "Wikiproject Street View" would be to. Since it doesn't sound like it's only for images taken from the street. So then I guess whatever is between the street level and the earth would be a good name. Who knows what that is though. --Adamant1 (talk) 12:10, 27 June 2024 (UTC)Reply
I'm not married to "Earth" but I'd avoid something that sounds specific to geography. This project could be useful for different scales (for example, you could reconstruct the roof of Notre Dame of Paris with great precision with the kind of material gathered here). GeoEarth is good but strikes me as somewhat redundant (kinda like the Mojo Dojo Casa House, heh). Here are a couple of alternatives:
WikiProject Globe
WikiProject Earth4D
WikiProject EarthMapper (or GeoMapper)
WikiProject EarthScan (or GeoScan)
A gun to my head right now, I'd pick Earth4D :) I'm still fine with any of those and am happy to hear any other suggestions.
@Rkieferbaum: Google could argue that "Earth", despite the colloquial use, is a trademark of Google in the Internet provision of proprietary geomapped imagery which predates your posts above, and they have a team of litigious lawyers. Do you want to take that risk? — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:15, 27 June 2024 (UTC)Reply
@Jeff G.: in all honesty, that hadn't occurred to me, but that possibility makes me all the more inclined to pick "Earth", heh. If they can trademark such a broad word for such a broad scope... ¯\_(ツ)_/¯ Rkieferbaum (talk) 13:22, 27 June 2024 (UTC)Reply
Don't copycat the name then though. Agree that Google couldn't (and wouldn't) argue that but this is beside the point anyway: the name is just not fitting and somewhat misleading. Of the proposed names I think all would be fine except Globe (same problem and this is not about Globe in any way), and EarthScan (unclear and suggesting satellite-type scanning). I'm not sure about Earth4D: I think it's also unclear and people wouldn't know what is meant with the fourth dimension there (places over time) + images aren't 3D and for videos it's also debatable. Prototyperspective (talk) 22:26, 27 June 2024 (UTC)Reply
Totally agree. I thought 4D had to do with the 4 directions. North, south, east, and west.
At the end of the day a lot of this stuff is way pedantic but not totally meaningless and worth putting some forethought into because its much harder to change later. --Adamant1 (talk) 23:21, 27 June 2024 (UTC)Reply
I just don't see how your going to enforce uploading guidelines. Nor do I think Wikiprojects should (or do) have the ability to do that anyway. More so considering that there's clearly no consensus for uploading guidelines more broadly. Wikiprojects shouldn't be mini-fiefdoms that get to overide wider consensus or policy. --Adamant1 (talk) 23:12, 25 June 2024 (UTC)Reply
@Adamant1: hi there. I'm not sure I follow. These aren't rules to be enforced. These are guidelines that volunteers are welcome to adhere to if they're interested in contributing to the project for this specific type of content. They are and always will be welcome to not follow them, which would mean their contributions wouldn't be (easily) used in whatever applications are developed with this type of image set in mind. That's absolutely fine and part of what the Commons is about. I don't see how this is to become a "fiefdom" and much less how any of this overrides any consensus or policy. I'm grateful if you'd elaborate. Cheers. Rkieferbaum (talk) 00:05, 26 June 2024 (UTC)Reply
There's still no broader consensus to implement uploading "guidelines" anyway. Otherwise do a proposal for that specific aspect of it or make it an essay. Calling it a "guideline" comes with a certain weight behind it regardless if you actively enforce it or not and then a huge issue at least on Wikipedia with Wikiprojects creating "guidelines" that don't have wider consenus and then pushing them on the community at large. Which I rather not see happen on Commons. As much for your own sake as anyone elses. Just make it an essay though. That's "Wikiproject postcards." Maybe check out how we do it therw. There's no "guidelines" with it per se but we still have best practices that we recommend people follow. No one acts like they are "guidelines" or follows them at the cost of wider consensus though. --Adamant1 (talk) 00:29, 26 June 2024 (UTC)Reply
Latest comment: 10 days ago2 comments2 people in discussion
Hello, my name is OperationSakura6144. I need to replace File:Palestine Red Crescent Society.png with File:Palestine Red Crescent Society logo.svg in the Persian Wikipedia article "جمعیت هلال احمر فلسطین", but I cannot do that manually because my IP is blocked there. (Please don't tell me to appeal the IP block. I tried it all, but it's no use. I'd wait 5-6 months for the block to expire. Until then, please help me.) I hope you hear me and help me in this situation. I need to have it done real quick.
Also, I wish File:Palestine Red Crescent Society.png to be deleted, because it is a low-quality duplicate of File:Palestine RCS.png and File:Palestine Red Crescent Society logo.svg, and that logo has claims of being Saltanat ebli's own work, which would be a bit misleading as File:Palestine Red Crescent Society.png reperesents the logo of a third-party organization, which, in this case, shouldn't have claims of being someone's own work unless that person is the original logo designer. I hope you fully understand my opinions about deleting File:Palestine Red Crescent Society.png, and also, the file was made the earliest as far as I can know, but sometimes, older things has to be ditched for newer ones, and that's what I think about everything. I hope you hear me out and help me, and reply me if you're done and/or I'm wrong. I'd like to have that job done as soon as possible, because I want to spend my time in the holidays. So, do it as quick as possible. I'll see you again if it's done. Bye. OperationSakura6144 (talk) 05:35, 30 June 2024 (UTC)Reply
Support Per my comments in the Village Pump discussion. Cross-wiki uploads are clearly an issue and making it only available to autoconfirmed users seems like the best option at this point baring anything else. But it doesn't seem like there's a workable solution for now beyond that. --Adamant1 (talk) 10:40, 30 June 2024 (UTC)Reply
Support That research report confirmed what we already knew: that cross-wiki uploads are primarily used for out-of-scope promotional images and copyvios. Unless massive changes are made (restricting to experienced users, removing it from User: and Draft: namespaces, etc), the only solution is to turn it off. Pi.1415926535 (talk) 20:45, 30 June 2024 (UTC)Reply
Support – Re-reading the study, the one you're proposing isn't listed as one of WMF's recommendations. Still, this should stave off un-autoconfirmed users (of any wiki) from abusing the cross-wiki upload tools. I can't help figure out why WMF doesn't list the idea you're suggesting. Maybe WMF wants all projects to be too newbie-friendly or something? Anyways, I'm thinking about creating a Phabricator ticket if there's overwhelming consensus favoring this. George Ho (talk) 21:02, 30 June 2024 (UTC)Reply
The review of the study by the Commons community mostly came to the above conclusion. Several recommandations in the study could be summed up: do what UploadWizard already does. Enhancing999 (talk) 10:42, 1 July 2024 (UTC)Reply
@George Ho Just FYI, the study did not suggest ideas on purpose, since WMF thinks policy decisions should be taken by the community, and that there should be no interference from WMF about these decisions. Sannita (WMF) (talk) 11:09, 1 July 2024 (UTC)Reply
Reading over the comments in that ticket gives me the impression that this might one of those things that needs a lot of follow up and push back on our side about. --Adamant1 (talk) 11:18, 1 July 2024 (UTC)Reply
Support. If need be, we should just use an edit filter to prohibit the cross-wiki uploads. The upload wizard on Commons is capable of guiding complete newbies as to whether or not they can upload a file (in most cases). But the way that visual editor works on other wikis is insufficient, and leads to a lot of work from volunteers here. — Red-tailed hawk(nest)04:21, 2 July 2024 (UTC)Reply
Support With the current situation this is needed. But we should allow uploads during editing of Wikipedia when the full UploadWizard is embedded there. GPSLeo (talk) 12:08, 2 July 2024 (UTC)Reply
Limit "chronological" categories based on notability and/or the subject's rate of change
Latest comment: 1 day ago28 comments10 people in discussion
There's been several discussions recently about limiting the creation of "chronological" categories. While there doesn't seem to be a consensus to ban them outright, they can still clearly cause problems depending on the particular situation and what "chronological level" it is. Especially when you get down to "by year" or "by day" categories. So I propose limiting "chronological" categories to two instances:
1. If the particular subject is known for taking place on a specific date, then it's OK to create or categorize it in a particular "by date" category. For instance the September 11th Attacks are widely known for and discussed as taking place on September 11th 2001. So it's fine to organize it in (or create) a category for that specific date. Whereas if it's a subject where the date has no notability or usefulness in categorizing images to it what-so-ever then there's no point in creating a "by date" category to put it in.
2. Sorting images related to a particular subject "by date" is appropriate in cases where the rate of change for that subject warrants it. But not where it doesn't. For instance, if there are two images of the same tree taking days apart then it is pointless to put said images in separate "by day categories." Likewise, if a product doesn't change from year to year, then there's point in putting images of it "by year" categories. Whereas, if there are clear changes to the subject over time that are reflected in the images of it that we have Commons then it makes sense to organize said images by date categories that accurately reflect those changes. Otherwise doing so doesn't serve a useful purpose. Adamant1 (talk) 04:22, 1 July 2024 (UTC)Reply
I also support this but we should have a clear guideline in this. I would suggest that events should be organised in by month categories. Photos of people can be sorted into by year category. For geographical features there should not be a separation by years, but they can be sorted into cross year seasonal categories. GPSLeo (talk) 05:49, 1 July 2024 (UTC)Reply
I don't have a problem with any of that or making it a guideline once the specific details are figured out and agreed on. --Adamant1 (talk) 06:07, 1 July 2024 (UTC)Reply
Are you talking about the "category:Subject in YYYY" categories, or are you talking about categorizing images of, let's say a temple in Delhi in the "category:MM-DD-YYYY in India" categories? Kritzolina (talk) 06:43, 1 July 2024 (UTC)Reply
I'm not sure if your asking me or GPSLeo, but on my end I guess I'm talking about both depending on the situation. I guess I don't really care if a category for a temple in Delhi is put in one for "MM-DD-YYYY in India" because there's obviously going to be more that can or will go in there along with it. I don't think a category like "MM-DD-YYYY in India" should be created simply so there's somewhere to dump the "temple in Delhi" category into. Like I think creating a specific "MM-DD-YYYY" category for the location of the temple when that's essentially the only there that we have pictures of for that day, month, and year is counter productive. I have zero problem with "MM-DD-YYYY" categories for countries though, becuase there's obviously going to be media to put in them. Conversely, I don't think "MM-DD-YYYY" categories should be made specifically for the temple itself. Unless there's actually something that's notable about the date or there's changes over time to it that are worth documenting through chronological categories. --Adamant1 (talk) 07:11, 1 July 2024 (UTC)Reply
My "You" actually was a plural you, I wanted to hear from both of you, so thanks for answering this question so clearly. I see your points and agree with all of them. Kritzolina (talk) 07:15, 1 July 2024 (UTC)Reply
I'm not sure that you actually mean Category:07-31-2023 in India, because that is definitely not how Category:Photographs of India by date subcats are formatted. Now, Category:2024-04-08 and the like are formatted differently, and in fact, as I barely scratch the surface, I find an extremely haphazard and "free-for-all" mix of date formatting styles. Dates formatted MM-DD-YYYY do not sort properly, for starters. There are date formats which are all numbers, and there are date formats which include month names such as "April", which are undesirable on several counts. There are date formats which are partially specified, and there are formats which are fully specified.
So perhaps as we codify a guideline or at least approach a way to describe current valid usages, we should regularize the formatting of these dates. And, we should consider formats which could optionally include timestamps as well: photographs of September 11th events may indeed benefit from ordering by the hour and minute they occurred and were photographed. Elizium23 (talk) 07:31, 1 July 2024 (UTC)Reply
Unless I missed something important, I think you mean September 11th 2001, not 2021! But yes - I believe I mentioned the "rate of change" standard in Commons:Categories for discussion/2024/06/Category:Bicycles by year, and that seems like it could be a broadly useful guideline for the granularity of chronological categories.
Are we talking here about classification of categories or of individual files? I'd certainly want to see, for example, Category:May 2021 in Seattle on any photo to which it applies (or on a category it belongs to, if it was part of some larger event). You never know when it might be useful to know (for example) that a particular picture of a person was taken at a particular place and time. - Jmabel ! talk19:31, 1 July 2024 (UTC)Reply
I have to disagree. I was just editing "by year" categories for bicycles and there's rarely any difference from year to year. At least not that's readily viewable for most people. Maybe a 1980 bike is different then one made in the mid 1970s, but that's what "by decade" categories are for. We need to stop making categories in mass for minor things that no one can actually see in the images without a manual or specialized degree. --Adamant1 (talk) 11:14, 2 July 2024 (UTC)Reply
Agree on that but not an argument for years cats as is: it just suggests there need to be subcats such as "2020s electric bikes" or "{novel feature/technology/component/event}" – such would be much more reasonable and useful than arbitrary by years cats in cases like this. Prototyperspective (talk) 15:32, 4 July 2024 (UTC)Reply
Oppose (edit - changing to clear "Oppose" in light of other comments below -- Infrogmation of New Orleans (talk) 16:01, 8 July 2024 (UTC) ) Tend towards oppose the proposal as stated as being rather vague and not helpful. I have no objection to discussion as to when chronological categories are recommended and when they are not. A few thoughts on my experience in this issue: I was at first skeptical that categories any finer than by decade were widely useful, but came to see their utility. The usefulness of some categories may not be obvious to some casual users, but sometimes can be very informative to others researching particular topics. For example, I've worked in audio for over 40 years, and have interest and have written about historic audio technology as well. I have some interest in microphones. We have many photos (and some diagrams and other media) related to microphones - for a time almost all just in "microphones" category, which became something of a huge dump. Some users started creating subcategories like "Women with microphones", "Men with microphones", etc. That may be of interest to others, but not very useful to me, so I created year and decade categories. I had another user make fun of me for doing so, but once categories were set up, Commons had a good overview of technological development and use. I don't know enough about bicycles to state what granularity of chronology is useful, but will defer to those actively categorizing such images. We certainly have year categories for automobiles - they are commonly marketed with model years. Chronology categories are also useful in subcategorizing what would otherwise be very huge categories. Guidelines might be helpful as recommendations, but hard rules might be difficult since there can be exceptional circumstances. For example, Pie Town, New Mexico is a rather small and generally undistinguished place, not somewhere of great notability, and there is no need of a full category tree by year - but Category:Pie Town, New Mexico, 1940 is entirely appropriate, since FSA photographer Russell Lee spent time making a series of photographs there then. I find it sometimes useful when for example I spend a half day taking photos of some historic cemetery or district to have a category collecting all the photos. As to "subject's rate of change", that may not be obvious until some frame of chronology is established. I certainly found much more change then I expected to see with centuries old historic monuments when media on Commons was organized chronologically - for example one might see gradual decay, then restoration, additions then slow decay again, then some disaster, another restoration that removes additions to restore a more historic appearance; changes in signage and visitors - perhaps the point at which visitors are no longer allowed to climb all over the monument - social contexts, etc. So IMO there should be no obligation to categorize everything chonologically - but many topics can benefit from it from the perspective of some users. The categories may not be of obvious usefulness to other users, but I don't see their existence as harmful. -- Infrogmation of New Orleans (talk) 15:22, 2 July 2024 (UTC)Reply
Comment IMO another consideration is the amount of media in a category. When a category is filled significantly beyond the default display of 200 media, IMO creation of subcategories should be considered. Chronology is certainly not the only option and not always the best, but is often a useful one. -- Infrogmation of New Orleans (talk) 15:29, 2 July 2024 (UTC)Reply
Whatever you mean with "the plague of chronological categories" – your comment is unexplained and makes no sense, you want black and white videos from 1920 crowd out recent up-to-date recordings of a subject, old outdated charts bury useful ones, and 1900 photographs of a city or subjects relating to ancient history be intermingled with recent subjects and media? …and these aren't even good examples. One could say reduce the plague of locational categories such as by country subcategories. --Prototyperspective (talk) 11:49, 4 July 2024 (UTC)Reply
Yes, that's what I mean. As long as the dates are recorded in structured data associated with the files, there is no need for date intersection categories. They may still provide some usefulness in certain cases, but that usefulness is outweighed by their overall damage to the category system. We would be much better off with no chronological intersection categories (with maybe a few limited exceptions). That is my honest opinion. Nosferattus (talk) 01:50, 7 July 2024 (UTC)Reply
Thank you. Without examples, I was unsure what chronology categories you find objectionable. The first two I see little justification for either. I think categories with only 1 or 2 members are seldom useful (I won't say never, as I'm sure there can be at least occasional counter-examples). Still, they look to me more "not particularly useful" rather than "actively harmful"; "plague" to me implies the latter. -- Infrogmation of New Orleans (talk) 17:40, 8 July 2024 (UTC)Reply
Agreed that categories with only one or two photos are usually a liability, especially when they are intersection categories. Still, there are a few times when such small categories are appropriate:
A Wikipedia article on the topic already exists, or clearly should exist. This is especially the case for individual people, places, buildings, etc.
The category is very likely to grow. E.g. in an area where we routinely have enough photos every month to merit by-month categories, if it's the 2nd of the month and you are uploading the first photo from that area this month, there is no reason not to create the category now.
Where there happens to be one poorly-populated category in a clear sequence of mostly well-populated categories. For example, if there were a 19th-century magazine where we sub-categorized images by which issue they were in (hopefully not the only categories they'd get!) and we turned out to have only one image from a particular issue, where 20 or 30 was more common, we'd probably still want to make a category for that issue.
"As long as the dates are recorded in structured data associated with the files, there is no need for date intersection categories." Disagree strongly. IMO this makes multiple questionable assumptions. Commons still has a large amount of media without structured data, along with a large amount of media where the categories are of much greater accuracy, granularity, and usefulness than the structured data. For media from before EXIF became common - and such media can be very important for historic subjects - too often the date information is simply false, even when true date is clearly stated in the text or can be found by a look at the off-Wiki original source. This has unfortunately been greatly exacerbated by people copying media from Flickr while completely neglecting their responsibility to make the information correct - resulting in much media having date of digitization or Flickr upload, unrelated to true date of the media. Also the hand curation of categorization allows selection of media that are actually representative of the categories. -- Infrogmation of New Orleans (talk) 16:21, 8 July 2024 (UTC)Reply
Support Agree, subcategories should have the fidelity that makes most sense. Media are buried in deep chronological subcategory branches that sometimes are as specific as the month even though the rate of change is decadal and most of the media haven't been subcategorized with this fidelity, making things even more dispersed than already by introducing these cats.
It would be good if there were more categories by decade and century like Category:Sleeper trains in the 21st century by country that then that then get subcategorized by subject not by ever finer chronology and/or subject-specific-irrelevant criteria (like gender rather than exercise/sport in Category:People exercising). Chronological categories are useful for many reasons (some hinted at above) including making it possible to see the media on recent subjects such as from studies of a year, but for all subjects there is a level of fidelity that stops making sense.
The few opposers have not thought this issue through and it greatly reduces the usefulness and navigability of WMC while year-specific images can still be put in year-specific categories like "{year} in transport" for an image previously in "Bicycles by year" that is actually truly relevant and due there. It doesn't mean all by year/month cats are inappropriate, just many of them. It just makes things hard to find and organize (even if there was a way to easily view files in cat including those in its by-year subcategories in a modern wall-of-images view).
Relevant: Category talk:Videos by year#Criteria? Bot?. And I think we'd need to discuss what should be done in regards to the issue discussed here: a new board where the level of fidelity can be discussed or upcoming upmerging of by year/month/day categories into larger time-span categories can be notified in advance? And what about the templates (example) that add these cats?--Prototyperspective (talk) 11:49, 4 July 2024 (UTC)Reply
Please replace two PNG files with SVG files across all Wikipedia articles.
Latest comment: 4 days ago2 comments2 people in discussion
Hello, my name is OperationSalura6144. I was trying to replace File:Palestine RCS.png and File:Galatasaray Sports Club Logo.png with File:Palestine Red Crescent Society logo.svg and File:Galatasaray Sports Club Logo.svg respectively across all Wikipedia articles, but I can't do it wholly because my IP is blocked on the English, Spanish and Persian Wikipedias and that problem made the whole process incomplete. I would like you to help me in this situation. I tried the best as I could in replacing files, but I hope you help me in these challenging situations. I'd be happy if you do that.
There has been a lot of discussion on this general topic already, and a general replace of images in other formats with SVGs is not wanted. So you should reach out to the individual wiki's noticeboards for them to perform the change, if they agree. (other global replaces [that do not have restrictions as in the warning section] can be requested on this talk page of User:CommonsDelinker/commands). --Schlurcher (talk) 06:43, 5 July 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).svg/15px-Pictogram_voting_comment_(orange).svg.png)
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)
Oppose there are several problems with that approach:
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.
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)
Question: what do you mean by "on CDs"? Compact Disks?
Strong support - I exchanged 14 emails with a sexagenarian who wanted to release a photo that their daughter took of them specifically for use in their Wikipedia article. After painstakingly walking them through the VRT process (and apologizing for how difficult it was), VRT rejected it anyway since the copyright technically belonged to their daughter. In the end, they just gave up rather than jumping through more hoops. Why do we make this so difficult? Nosferattus (talk) 23:30, 25 May 2024 (UTC)
Weak support and I agree this should ideally not be done by bots. See also Commons:Requests for comment/Technical needs survey/UploadWizardSDC. If there is interest I could add this to GLMA files as proposed with my bot. Just let me know. --Schlurcher (talk) 07:05, 23 May 2024 (UTC)
.jpg){kind=link}
.JPG){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg){kind=link}
.jpg){kind=link}
_Boeing_737-3H4(WL)_at_Albury_Airport_(IMG_4039).jpg){kind=link}
_by_the_NZ_Defence_Force.jpg){kind=link}
_Agusta_A109LUH(NZ)_post_maintenance_flight.jpg&action=edit&redlink=1){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
-_-_NARA_-_17443770_(page_700).jpg){kind=link}
Weak oppose I do not think it is good idea to have this as a highly visible reason for speedy deletion as this will be missused for edit wars by people how want a file deleted for political reasons. But we should write this as a deletion reason into the longer description of reasons. GPSLeo (talk) 08:52, 28 May 2024 (UTC).jpg){kind=link}
.svg){kind=link}
I withdraw my nomination. JopkeB (talk) 06:23, 17 June 2024 (UTC)_aerial_02_(9454373737).jpg){kind=link}
