Jump to content

Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

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

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

 

Start a new discussion

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

RfC: Changes to the public domain license options in the Upload Wizard menu

[edit]

Should any default options be added or removed from the menu in the Upload Wizard's step in which a user is asked to choose which license option applies to a work not under copyright? Sdkb talk 20:19, 19 December 2024 (UTC)[reply]

Background

[edit]

The WMF has been (at least ostensibly) collaborating with us during its Upload Wizard improvements project. As part of this work, we have the opportunity to reexamine the step that occurs after a user uploads a work that they declare is someone else's work but not protected by copyright law. They are then presented will several default options corresponding to public domain license tags or a field to write in a custom tag:

It is unclear why these are the specific options presented; I do not know of the original discussion in which they were chosen. This RfC seeks to determine whether we should add or remove any of these options. I have added one proposal, but feel free to create subsections for others (using the format Add license name or Remove license name and specifying the proposed menu text). Sdkb talk 20:19, 19 December 2024 (UTC)[reply]

[edit]
Tracked in Phabricator
Task T376522

Should {{PD-textlogo}} be added, using the menu text Logo image consisting only of simple geometric shapes or text? Sdkb talk 20:19, 19 December 2024 (UTC)[reply]

 Support. Many organizations on Wikipedia that have simple logos do not have them uploaded to Commons and used in the article. Currently, the only way to upload such images is to choose the "enter a different license in wikitext format" option and enter "{{PD-textlogo}}" manually. Very few beginner (or even intermediate) editors will be able to navigate this process successfully, and even for experienced editors it is cumbersome. PD-textlogo is one of the most common license tags used on Commons uploads — there are more than 200,000 files that use it. As such, it ought to appear in the list. This would make it easier to upload simple logo images, benefiting Commons and the projects that use it. Sdkb talk 20:19, 19 December 2024 (UTC)[reply]
Addressing two potential concerns. First, Sannita wrote, the team is worried about making available too many options and confusing uploaders. I agree with the overall principle that we should not add so many options that users are overwhelmed, but I don't think we're at that point yet. Also, if we're concerned about only presenting the minimum number of relevant options, we could use metadata to help customize which ones are presented to a user for a given file (e.g. a .svg file is much more likely to be a logo than a .jpg file with metadata indicating it is a recently taken photograph).
Second, there is always the risk that users upload more complex logos above the TOO. We can link to commons:TOO to provide help/explanation, and if we find that too many users are doing this for moderators to handle, we could introduce a confirmation dialogue or other further safeguards. But we should not use the difficulty of the process to try to curb undesirable uploads any more than we should block newcomers from editing just because of the risk they'll vandalize — our filters need to be targeted enough that they don't block legitimate uploads just as much as bad ones. Sdkb talk 20:19, 19 December 2024 (UTC)[reply]
"we could use metadata" I'd be very careful with that. The way people use media changes all the time, so making decisions about how the software behaves on something like that, I don't know... Like, if it is extracting metadata, or check on is this audio, video, or image, that's one thing, but to say 'jpg is likely not a logo and svg and png might be logos' and then steer the user into a direction based on something so likely to not be true. —TheDJ (talk • contribs) 10:52, 6 January 2025 (UTC)[reply]
 Oppose. Determining whether a logo is sufficiently simple for PD-textlogo is nontrivial, and the license is already frequently misapplied. Making it available as a first-class option would likely make that much worse. Omphalographer (talk) 02:57, 20 December 2024 (UTC)[reply]
 Comment only if this will result in it being uploaded but tagged for review. - Jmabel ! talk 07:14, 20 December 2024 (UTC)[reply]
That should definitely be possible to implement. Sdkb talk 15:13, 20 December 2024 (UTC)[reply]
 Support Assuming there's some kind of review involved. Otherwise  Oppose, but I don't see why it wouldn't be possible to implement a review tag or something. --Adamant1 (talk) 19:10, 20 December 2024 (UTC)[reply]
 Support for experienced users only. Sjoerd de Bruin (talk) 20:20, 22 December 2024 (UTC)[reply]
 Oppose peer Omphalographer ,{{PD-textlogo}} can use with a logo is sufficient simply in majority of countries per COM:Copyright rules (first sentence in USA and the both countries peer COM:TOO) my opinion (google translator). AbchyZa22 (talk) 11:02, 25 December 2024 (UTC)[reply]
 Oppose in any case. We have enough backlogs and don't need another thing to review. --Krd 09:57, 3 January 2025 (UTC)[reply]
How about we just disable uploads entirely to eliminate the backlogs once and for all?[Sarcasm] The entire point of Commons is to create a repository of media, and that project necessarily will entail some level of work. Reflexively opposing due to that work without even attempting (at least in your posted rationale) to weigh that cost against the added value of the potential contributions is about as stark an illustration of the anti-newcomer bias at Commons as I can conceive. Sdkb talk 21:36, 3 January 2025 (UTC)[reply]
 Oppose. I think the template is often misapplied, so I do not want to encourage its use. There are many odd cases. Paper textures do not matter. Shading does not matter. An image with just a few polygons can be copyrighted. Glrx (talk) 19:47, 6 January 2025 (UTC)[reply]
 Support adding this to the upload wizard, basically per Skdb (including the first two sentences of their response to Krd). Indifferent to whether there should be a review process: on one hand, it'd be another backlog that will basically grow without bound, on the other, it could be nice for the reviewed ones. —‍Mdaniels5757 (talk • contribs) 23:57, 6 January 2025 (UTC)[reply]
 Support New users which upload logos de facto always use wrong tags such as CC-BY-4.0-own work. Go to bot-created lists such as User:Josve05a/Logos or cats like Category:Unidentified logos, almost all logos uploaded by new users have such invalid licencing - all of which has to be reviewed & fixed at some point. People will upload logos that are too complex/nonfree etc regardless of this option, but adding the option might increase the change that they familarize themselfes with the requirements for uploading logos and apply the correct tag. ~TheImaCow (talk) 21:12, 22 February 2025 (UTC)[reply]
Note that {{PD-textlogo}} should probably be applied together with {{TM}} (possibly restricted by trademark) ~TheImaCow (talk) 21:40, 28 February 2025 (UTC)[reply]
  •  Question Why {{PD-textlogo}} instead of for example {{PD-ineligible}}? I can understand the reason that keeping it simple is prefered and in that case PD-ineligible could be more usable. I do not think adding a review is a good idea. Or well a review is a good idea but realisticly it will never be reviewed. We had {{PD-review}} but it was dropped. --MGA73 (talk) 10:10, 6 March 2025 (UTC)[reply]
    The idea is definitely to keep things simple. There are so many possible reasons something could be PD that we can't list them all; the ability to add a custom tag in the last line will always be a significant bucket. But we do want to provide the specific PD tags for common use cases, and as argued above logos falling under PD-textlogo is one of those. PD-ineligible, by contrast, is a much more generic tag, and is generally not a good idea to use when there is a more specific tag available. I think adding it to the default options list could be risky, since people might use it for "I want to upload this but I don't know if it's actually PD or how so I'll just use PD-ineligible" situations. Sdkb talk 16:59, 6 March 2025 (UTC)[reply]
  •  Support, but only for experienced user, who knows the copyright policies inside Commons and copyright rules outside. ZandDev (talk) 19:30, 15 March 2025 (UTC)[reply]
    I understand keeping it simple, but the copyright tags I use most are absent, instead "copyright NASA" and "US federal government" (the rest of the world?) seems questionable, as it must be the result of careful evaluation and not simply localism. So for the same principle at least the most common upload copyright tags should be present. -- ZandDev (talk) 19:36, 15 March 2025 (UTC)[reply]

General discussion

[edit]
This is for discussion about the menu options as a whole. Put discussion about specific add/remove proposals in their respective subsection.

Courtesy pinging @Sannita (WMF), the WMF community liaison for the Upload Wizard improvements project. Sdkb talk 20:19, 19 December 2024 (UTC)[reply]

Thanks for the ping. Quick note: I will be on vacation starting tomorrow until January 1, therefore I will probably not be able to answer until 2025 starts, if needed. I'll catch up when I'll have again a working connection, but be also aware that new changes to code will need to wait at least mid-January. Sannita (WMF) (talk) 22:02, 19 December 2024 (UTC)[reply]
Can we please add a warning message for PDF uploads in general? this is currently enforced by abuse filter, and is the second most common report at Commons talk:Abuse filter. And if they user pd-textlogo or PD-simple (or any AI tag) it should add a tracking category that is searched by User:GogologoBot. All the Best -- Chuck Talk 23:21, 19 December 2024 (UTC)[reply]
Yes, please. Even with the abuse filter in place, the vast majority of PDF uploads by new users are accidental, copyright violations, and/or out of scope. There are only a few appropriate use cases for the format, and they tend to be uploaded by a very small number of experienced users. Omphalographer (talk) 03:11, 20 December 2024 (UTC)[reply]
Why not just prohibit new users from PDF uploads? Trade (talk) 23:05, 15 March 2025 (UTC)[reply]
They already are, by way of an edit filter. But once an account is old enough to upload a PDF, the first PDF upload is still usually out of scope. Omphalographer (talk) 23:07, 15 March 2025 (UTC)[reply]
@Omphalographer, you beat me to it. PDFs are normally more trouble than it's worth. All the Best -- Chuck Talk 23:08, 15 March 2025 (UTC)[reply]
My bad, I've corrected it above. For whatever reason I thought that he was a German woman because I remember seeing the profile of someone on that team and I probably confused them in my head, I just clicked on their user page and saw that it's an Italian man. Hopefully he won't feel offended by this mistake. Just saw that he's a fellow Whovian, but the rest of the comment remains unaltered as I think that the wording misrepresents "free" as "copyright-free", which are separate concepts. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:09, 24 December 2024 (UTC)[reply]
(Hello, I'm back in office) Not offended at all, it happens sometimes on Italian Wikipedia too. Words and names ending in -a are usually feminine in Italian, with some exceptions like my name and my nickname that both end in -a, but are masculine. :) Sannita (WMF) (talk) 13:15, 2 January 2025 (UTC)[reply]
Wiki markup: {{gender:Sannita (WMF)|male|female|unknown}} → male. Glrx (talk) 03:07, 3 January 2025 (UTC)[reply]

Unarchiving, as unclosed. Sdkb talk 07:50, 6 February 2025 (UTC)[reply]

@Sdkb I used {{DNAU}} (substituted) with no params. This thread will not be archived for a long time (until resolved). -- ZandDev (talk) 19:26, 15 March 2025 (UTC)[reply]

Major damage to Wikimedia Commons

[edit]

As far as I can see, major damage has successively been done to Wikimedia Commons over the last few years by chopping up categories about people into individual "by year" categories making it

  1. virtually impossible to find the best image to use for a certain purpose, and
  2. virtually impossible to avoid uploading duplicates since searching/matching imges has become virtually impossible.

Here is a perfect exsmple. I have a really good, rare picture of her, but I'll be damned if I'm willing to wade through all the "by-year" categories to try to see if Commons already has it. The user who uploaded this didn't even bother to place it in a personal category. Why should they, with all the work required to try to find the category at all & fit the image in there?

I am mot objecting to the existence of categories "by year", Searching is the problem.

What if anything can be done about this mess which is steadliy getting worse all the time? Could some kind of bot fix it?

I really feel that this is urgent now and cannot be ignored any longer. The project had become worth much much much less through the problem described. Or have I missed/misunderstood something here? SergeWoodzing (talk) 10:00, 23 January 2025 (UTC)[reply]

This is a duplicate discussion of Commons:Administrators' noticeboard#URGENT! Major damage to this project. CMD (talk) 12:22, 23 January 2025 (UTC)[reply]
Yes, but the user was told there to bring it here. - Jmabel ! talk 17:28, 23 January 2025 (UTC)[reply]
Contemporary VIP´s produce a ton of images. Sorting them by year makes sense - otherwise you would have to deal with hundreds of files in one category. As for Wikipedia: Go to the most recent useable photo of "Sophie" and use that. And if it is not the most flattering... well that´s life. Alexpl (talk) 12:33, 23 January 2025 (UTC)[reply]
Uh, I don't think that's really what we ought to do. I've tried for many years always to use the best possible images. --SergeWoodzing (talk) 17:52, 23 January 2025 (UTC)[reply]
It feels like the fear is a bit too huge to me, but (if you're looking for images of Donald Trump), you can enter deepcategory:"Donald Trump by year" in the regular search for example, et voilá! You can see many Donald images at once without looking into each subcat :) (Also see COM:Search for tags and flags) --PantheraLeo1359531 😺 (talk) 12:51, 23 January 2025 (UTC)[reply]
Splitting images by year is often counterproductive, but that's necessary when there are a lot of them for one person. Yann (talk) 15:45, 23 January 2025 (UTC)[reply]
See Help:Gadget-DeepcatSearch and TinEye image reverse search among other things. Prototyperspective (talk) 16:04, 23 January 2025 (UTC)[reply]

Please! I have not suggested that images should not (also) be sorted by year, so there is no need to defend that kind of sorting. I've asked for a search remedy & will now try the tips we've been given here. Thank you for them! --SergeWoodzing (talk) 17:52, 23 January 2025 (UTC)[reply]

@SergeWoodzing: Another solution I've seen is addition of a flat category for all of a topic's files, to achieve your purpose but still allow for the granularity that others like to achieve.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:31, 23 January 2025 (UTC)[reply]
I agree with the general issue brought up by SergeWoodzing. "By year" in many cases only makes sense if a large number of files cannot be meaningfully sorted in another way. Non-recurring events, certainly. But things that undergo little changes from year to year, do not necessarily need atomized categories, and I also noticed that by-year categories are steady on the rise since 2018. Not always for the better. The following examples are not what literally exists right now, but it would be easy to find real cases just like them.
  • I have recently encountered more and more "books about <topic> by year", and that means that either a very broad topic like "biology" is split up by year (which later makes it much harder to split the topic by "botany" vs. "zoology", or as "by countinent", "by language", or to meaningfully search the publications) or that a very narrow topic like "American-Mexican War" gets splintered into single-file categories. How can two books about the same war be categorically different because the one was published in December 1857 and the other in March 1858?
  • "Maps by year" are my pet peeve. Nearly all maps before the 21st century had many-years-long production processes. The further back we go in time, the less the publication year of an (old) map matters, the categories should rather differentiate the location and topic, not the day/month/year of publication. An old city plan of Chennai, an old topo map of Rajasthan, and an old geological map of Bengal all from the same year, have so little in common that it is pointless to primarily group them under "<year> maps of India". (I have been vocal about this several times here on the pump already, and got some support too).
  • "Tigers by year": I think everyone should see the absurdity. Photos of tigers should be grouped by location (zoo, country) or by growth stage (juvenile, adult...), not whether they were photographed in 1998 vs. 2015.
  • Location by year. Without exif/metadata, one photo of Taj Mahal looks like the other, with no telling that one was created 2008 and the other 2021. It makes much more sense to primarily sort them by architectural elements (main building, gates, interior...) than by year. Thankfully, this is done too, but not always. And sure, with some events even two years make a huge difference, like Verdun 1913 and Verdun 1915; but many "non-changing" locations are fine without a by-year split-up.
  • "Person by year" is the OP topic already. Actually, in my opinion this makes mostly sense as long as MANY files exist. If there are just 25 files of a celebrity, please do NOT split that collection up into 12 by-year subcategories. Doing so is a case of well-intentioned obstruction, as access just gets harder with no further benefit.
Much more could be said. So while I am cautiously supportive of several important use cases of by-year categories, atomization has to stop. --Enyavar (talk) 02:12, 24 January 2025 (UTC)[reply]
While I also find it annoying to search through "by year" categories, there's merit in them.
  • Books about <topic> by year: Theories change and new discoveries are made. From a historical perspective, it is interesting what biologists from the 19th century thought and assumed about biological processes and how those assumptions and thoughts differ from those in the 20th century. There is merit in stuff like "history of medicine" and similarly there's merit in stuff like "history of biology".
  • Maps by year: the year helps to determine the copyright status of a map (because not all take that into consideration when uploading files). The year puts the map in context, like right now with the war in Ukraine: maps of Ukraine produced by Russia in 2024 will look different from those produced in 2010, and they will also look different from those produced by Ukraine in 2024 despite being from the same year. Such maps show how borders have changed throughout the years (be it a factual change or be it because someone thinks that they have changed).
  • Tigers by year: This may seem ridiculous now, but you have to keep in mind that everything will become history one day. Wouldn't it be cool if we had photos of mammoths by year? If we had them, we'd be able to determine precisely when their population started to decline and in what area first and in which area last, and eventually, we'd be able to tell in what year exactly the last mammoth was photographed. The "tigers by year" category only seems ridiculous if one assumes that things are not going to change throughout the years. I mean, what if tigers start to change evolutionary by starting to grow saber-tooths again? Wouldn't you want to know when and where exactly the change started to occur? Don't you think that future generations would want to know how tigers looked like in 1950 vs 2000 vs 2050? You might think that such a change would take very long, but a look at the German Shepherd dog says otherwise: the dog that was first entered into the breed registry in 1895 was quite different from the one we now know as a German Shepherd (see [1][2][3]). It would even make sense to have a category for "tigers in zoos by year" because it would document how conditions regarding animal welfare have changed over the years.
  • Location by year: Things do change. There are repairs, there are implementations of new regulations (such as ramps for people in wheelchairs etc.), there is deterioration of condition, etc. A building can be gone in no time, even without there being some major events causing the change but just through neglect (see this building in 2023, 2023 vs. 2024).
I think it would be helpful if files were automatically added to hidden time-related (and maybe rough location-related) categories based on EXIF data (if available) instead of having to add this information manually and retrospectively[4]. It would save time for the uploader and it would help to focus more on content-related categories when categorizing a file, yet still keep time-related categories accessible for those interested in them. Nakonana (talk) 17:20, 23 February 2025 (UTC)[reply]
There are a lot of hypotheticals in your response, and I cannot see practical usability for most.
  • Books: Category:1894 books about geography. Not helpful, because geography has so many sub-topics. The structured data approach would be much more helpful here, because you could search for "1890s books" & "Alps" & "books about geography", without having to click through each single by-year category. And you might think that Category:Books about World War I is rather specific already, right? The problem is that once we subdivided them by year (or language), we can no longer comfortably subdivide them by topic as well. 1919 book=1920 book=1926 book (books about the history of specific regiments in WW1); 1928 book=1919 book=1917 book (personal war testimonials/memoirs); 1919 book=1920 book=1923 book (books about naval warfare in WW1). By contrast, the by-year subcategories about WW1 books are fully arbitrary, depending how quickly an author produced their own book.
  • Maps: Just a 'lil map of an American Civil War battlefield, be my guest and identify which year the map belongs to and copyright status. Photos are snapshots of reality, made in a second. Maps are not like that at all. Yes, context is important, but structured data can handle that just as well. Once you determine "category:1907 maps of Paris" you claim that this file is categorically just as different from "1908 maps of Paris" as it is from "2019 maps of Paris" - the situation is roughly the same as with the WW1 books above.
  • evolution of sabretooth tigers by zoo by year? Because humans will selectively breed them for sabretooth traits like they bred German Shepherds? Oh-kay. Sure. I am aware that this is just an example, this could be any organism. Categories are the wrong tool to document such changes, though. And by-year categories are even wronger.
  • Location by year. Eh. Yes sure, the Eiffeltower undergoes major architectural rearrangements every year, but we have all those by-year categories because we have so many photos of it; and not because we try to document all those changes in its construction. For most locations that are not overflowed by mass tourism, the structured data approach is best.
Categories should be there to group "files about the same subject/". If the same subject is "Press Conference in Brussels, 2014 July 13th" with several photographs uploaded: Yes, the presser category belongs into "July 2014 in Brussels", dated not just by year but even by month. By contrast, if there are in total three photos of a statue in the Brussels suburbs, these three should be grouped together primarily; the years in which each was taken is of secondary importance. And we do NOT need "1999 photographs of <some statue in Brussels-suburb>" vs. "2005 photographs of <some statue in Brussels-suburb>" vs. "2019 photographs of <some statue in Brussels-suburb>", for three files. --Enyavar (talk) 12:02, 24 February 2025 (UTC)[reply]
  •  Comment I did a proposal a few months ago to confine "by year" categories to images that show a meaningful distinction by year. For instance something like a yearly event where there's actually a difference between the years. Whereas, say images of tigers per Enyavar's example aren't worth organizing per year because there's no meaningful between a tiger in 2015 and one in 2016. Anyway, it seemed like there was general support for the proposal at the time.
The problem is that there's no actual way to enforce it because people will ignore consensus, recreate categories, and attack anyone who disagrees with them. It's made worse by the fact that admins on here seem to have no will or ability to impose any kind of standards. They just cater to people doing things their own way regardless of consensus as long as the person throws a big enough tantrum about it. There's plenty of proposals, CfD, village pump and talk page discussions, Etc Etc. that should already regulate how these types of categories are used though. They just aren't ever imposed to any meaningful degree because of all the limp wristed weak pandering to people who use Commons as their own personal project. --Adamant1 (talk) 06:47, 24 January 2025 (UTC)[reply]
So should they ban you promptly for using a homophobic slur ("limp wristed"), or should they just let you continue going on your way ignoring consensus?--Prosfilaes (talk) 08:16, 24 January 2025 (UTC)[reply]
@Prosfilaes: I didn't actually know it was a homophobic slur. I just thought it meant weak. I struck it out though. Thanks for letting me know. Not that I was saying anyone should banned for ignoring the consensus, but if people intentionally use homophobic slurs then yes they should be banned for it. With this though it's more about the bending over backwards to accommodate people who don't care about or follow the consensus then it is sanctioning anyone over it. people should just be ignored and the consensus should be followed anyway. There's no reason what-so-ever that it has to involve banning people. Just don't pander to people using Commons as their own personal project. It's not that difficult. --Adamant1 (talk) 09:28, 24 January 2025 (UTC)[reply]
For this topic at least, I don't think I have seen actual attacks against other users, thankfully. SergeWoodzing has used some strong condemnations of the status quo in general on Commons, but I do not perceive his statement as an attack against some users. Now, Adamant points out the problem, which is that we seemingly don't have a guideline or even policy on which topics may be organized by year and which ones should rather not get a by-year categorization. I'm almost sure that people are creating by-year categories out of the best intentions, and mostly because they are boldly imitating the "best practice" of other users, ignorant of some consensus that may or may not have been formed among a dozen users in the village pump. Which means that such users have to be talked out of the idea individually once they start by-year categories for an unsuitable topic. --Enyavar (talk) 16:33, 24 January 2025 (UTC)[reply]
There's certainly an aspect to this where people indiscriminately create by year categories because other people do. But it still comes down to a lack of will and/or mechanisms to enforce standards though. You can ask the person doing it to stop, but they can just ignore you and continue. Then what? No one is going to have repercussions for ignoring the consensus by continuing to create the categories. I've certainly never there be any and I've been involved in plenty of conversation about over categorization. The person usually just demagogues or outright ignores the issue and continues doing it. --Adamant1 (talk) 16:54, 24 January 2025 (UTC)[reply]
Tbf I didn’t really know it was either. I wouldn’t even call it a “slur”— more of a general insult with homophobic connotations, like “sissy” or “pansy”. Dronebogus (talk) 17:57, 27 January 2025 (UTC)[reply]
 Support resolving concerns reported by user "SergeWoodzing". such "alternative overcategorization" by year, or even worse by state, makes useful files hard to find. Not for "Contemporary VIP:s" brewing gazillions of useless images, but for relevant topics, especially if the total number of files is low. Taylor 49 (talk) 00:18, 5 February 2025 (UTC)[reply]
The fix for this problem is to lobby the Wikimedia Foundation to finish implementing structured data on Commons, then use that instead of our antiquated category system. — Rhododendrites talk |  22:51, 23 February 2025 (UTC)[reply]
The category system is in no way antiqued. Structured depicts data is currently a barely populated totally-unused time sink where all of it can be captured by the categories. Display categories in a different way maybe – more like many other websites which have tags – or improve how categories can be queried, searched & qualified. Prototyperspective (talk) 00:41, 24 February 2025 (UTC)[reply]
I have to agree with Rhododendrites. Categories on Commons have become completely useless (mostly thanks to "by year" categories). Structured data is the best way forward. Nosferattus (talk) 00:57, 24 February 2025 (UTC)[reply]
If the reason you think these are "useless" is because of "by year" categories then that just shows how incredibly irrational and weak your argumentation would be. It makes no sense and is actively harming Commons based on some strange SD ideology that exists because people try hard to bury their head in the sand. The solution for this minor issue is simple: a) use other/by subject subcategories instead or b) use search methods like deepcategory:"Donald Trump by year" which can be made more accessible via a cat-search-box. Prototyperspective (talk) 01:43, 24 February 2025 (UTC)[reply]
c) finally implementing date sorting & range-filters including reading the data in the already-existent Summary template. phab:T329961#10041982
Wouldn't mind if the data in these templates would be synced/copied ~at once into structured data if that's the easiest/best way to implement it but categories are still best for subjects and would just be combined with such metadata in structured data (e.g. sort by or specify year on the category page). Prototyperspective (talk) 01:54, 24 February 2025 (UTC)[reply]
Structured Data is not an "ideology", it is just a good way to have files organized flexibly and without a rigid category structure. I argue that we need both categories and SD.
"By year" categories are often but not always handled terribly. I have no problem with "Category:1919 in Paris (10 C, 57 F)": it is a big place, and that amply filled category allows you to browse. I also have no problem with "1919 elections in Brazil (1 F)" because it is part of a whole scheme about a very specific topic. I do have a problem with "Category:1919 in Farmton-upon-Runlet, Ruralshire (2 F)", especially if that is the only by-year category from there until "Category:2013 in Farmton-upon-Runlet, Ruralshire (6 F)".
That last example from above shows the antiquated approach of using categories to build elaborate trees around singular files. "Category:<Church> in the 20th century" which has "Category:<Church> in the 1920s" which has "Category:<Church> in 1921". That last category could also be the single child category of "Category:<Town> in 1921" (for a town like this with a total of 3 photos in the whole 20th century). There is also "Churches in <country> photographed in 1921". Now that category should be handled by a structured data query, not rigidly coded into each file. The structured data would add a tag of "date=1921"; and if it later turns out that the 1921 photo was actually taken in 1905 already, only one little thing needs to get changed. --Enyavar (talk) 10:06, 24 February 2025 (UTC)[reply]
The primary problem with the hierarchical category system (along the language problem) is that it creates false statements. For example we have a mountain in a nature reserve with a communication tower on the summit. The tower in not part of the nature reserve. The tower is categorized unter mountain and the mountain under the nature reserve. Then we get photos of the interior of the tower we looking for photos of the nature reserve. This could be solved by building parallel category structures and only linking them as "see also". But this is far to complicated for people who do not work with the category system in the particular topic every day. GPSLeo (talk) 10:45, 24 February 2025 (UTC)[reply]
This thread is only about the "by year" category subtree, though? --Enyavar (talk) 12:05, 24 February 2025 (UTC)[reply]
I think not really. But the the same problem applies to by year categories also. GPSLeo (talk) 12:29, 24 February 2025 (UTC)[reply]
I agree that this is a problem but it's not a problem with the categories and isn't about statements (at least mostly; or entirely as of now). This is a problem if you use deepcat – e.g. using the Help:Gadget-DeepcatSearch – on the category about the nature reserves or even the grandparent cat about all nature reserves. However, I don't think your example is very good: in that case the tower including its interiors is actually part of the nature reserve and it would be fine to have these photos show up, they just shouldn't be all over the page and preferably more near the bottom of the results. It's still a problem that they show up in the cat "Nature" etc since "Nature reserves" are their subcat. In any case, here is how this can be addressed (and this problem warrants a separate thread):
  • Tools for deepcat can be made so that one can easily adjust the depth and have it exclude special categories (it could use these some by default and have premade filters one can readily switch on): I've described this here at phab:T376440#10354943
  • Some tool(s) are needed for contributors to more easily spot and fix miscategorizations. FastCCI is such a tool but most of the time when trying to use it, it somehow fails to load and more importantly, that is not its primary or a dedicated purpose of it but more some ancillary feature. The tool would function like so: first the user spots some image they think doesn't belong into the deepcategory results – for example I used this on a photo showing some road sign or sth somewhere underneath Category:Microscopic images relating to biology. Then they use that tool to quickly see how that image relates to the given category (the one I just linked) which would show the category-path from the image to the given category (the shortest one or all if there's multiple paths). Then the user identifies the miscategorization and fixes it which can involve adding a category-see-also or the creation of a new category or simply removing a categorization. One can't expect categorization to be good if people don't have such tools. English Wikipedia actually has the same problem but I guess to a lesser extent where e.g. articles about people, films and events were in the category tree about novels iirc. Please see talkFastCCI:Not loading, showing offoptic images, and proposal for a forked gadget that shows the cat-path why a file is in cat. This is important and the earlier it gets done the better and the more accurate the categorization tree and useful the deepcat results will be.
Prototyperspective (talk) 12:33, 24 February 2025 (UTC)[reply]
The category system is in no way antiqued. Structured depicts data is currently a barely populated totally-unused time sink where all of it can be captured by the categories - It's web 1.0 technology that's been replaced everywhere else on the internet. Manually creating semantic categories with no logic other than a basic hierarchy and piling them together. Nevermind the people by year, how about A of B in C in D type categories, where the [English-only] prepositions might be "in" or might be "of", and A, B, C, and D might be repositioned. Structured data makes all of that a non-issue. You're talking about depicts, but depicts was just supposed to be the first of many data points. Structured data being "barely populated" doesn't mean it's a worse system; it means it's not fully implemented or adopted. The only good argument I've ever seen for categories over structured data is "we already have it, and volunteers have put a ton of time into creating it, and they'll be unhappy/demotivated if we lose any of it". It's a totally valid point, but has nothing to do with it being a superior system... the strength of the argument comes from the value of volunteers. Similar argument, I guess, for consideration of economic devastation in coal-mining communities when there's a concerted push towards renewable energy. IMO the priority should be lobbying to finish implementing SDC, and then focus on bots that can translate category data into structured data so as not to lose that volunteer time. — Rhododendrites talk |  21:24, 24 February 2025 (UTC)[reply]
The last time I checked the semantic web was dead on arrival. At the end of the day most people don't know or care about structured data. There should really be a more modern, widely used (I. E. usable by most people) way to organize images. Be that tags or some other system but it seems like a pointless time sink to fully implement SDC when most people can't or don't want to use it anyway purely because categories suck. I don't think fixing the issues with SDC on here is going to magically create a market for it over categories either. It's just a convoluted, half-baked system at the core that there's no actual enthusiasm for. A solution looking for a problem if you will. --Adamant1 (talk) 22:29, 24 February 2025 (UTC)[reply]
It's semantic web technology/methodology and even if it wouldn't be, that something isn't the shiniest new concept doesn't mean it's antiqued. You can define how these categories via a) how the categories are titled and b) via the Wikidata items of the categories where they relation can also be defined. Similar methods&systems have not been replaced on other websites, that is false. They generally have well-visible (not at the bottom or even hidden) tags right beneath or above the image.
--- Just on top of this refutation of your points, Structured data makes all of that a non-issue is plain false. People don't take a minute to tag a picture in some sophisticated SD way, they only add plain depicts and either mark it as prominent or not and even that isn't done for >95% of files and not done sufficiently or as much for remaining ~5% (probably much less). Again, SD for metadata that is mostly in the EXIF data wouldn't be an issue. Reread what I wrote earlier about SD, it's not a better system which is also why it's barely used (read and written to) and why when it is written, it's just copying from the categories. The categories are currently better for example because they have category pages and because they have a category tree relation which is absent here and when you click the SD tag you just land on some Wikidata item. Maybe something that syncs categories to the SD wherever matching WD items exist would be useful but it shouldn't replace that which is currently useful and I don't see why much resources should be spent on something that is largely redundant and importantly not used at all except for some niche experiment tool used by virtually nobody that shows images based on SD depicts which could also be done (with much better results) by querying the Commons categories or using the Commons search (which needs improvements). There is no benefit, no need (agree with A solution looking for a problem if you will when it comes to depicts SD), and lots of drawbacks. Prototyperspective (talk) 23:31, 24 February 2025 (UTC)[reply]
Prototype, Adamant describes a notorious problem with SD: there are no standards which attributes should be applied to a file, and there is no easy way how to apply them; and as a result SD is used in most haphazardous (I love that word, it comes up so rarely. =) way possible, and also basically not used in total. The SD editor we implemented here on Commons is truly a disaster, and this proposal was my only point on the wishlist for the Community Call this year. I have no idea what became of the suggestion, besides the promise it would be brought up; but there is no protocoll or transcript. So who knows. Maybe @Sannita (WMF): can provide/link some insight what happened since? I'm highly curious.
Anyway, so yes, SD implementation is bad currently; but our category tree is mostly maintained manually, usually by combining several "SD terms" in one category name, and then searching for random files that fit the description, and place them in the category.
If I may compare Commons to a library: we don't use those pesky new-fangled book catalogs! They would allow indexing and consistent searching, but it's soooooo much work to compile them! Drag each book to the desk, input lots of info into a computer that the book already has printed in it anyway, and then bring it back where it came from. No, we just place each new book on the shelves which are all thematically organized and subdivided, and then we trust all readers to navigate the shelves. / Now, with the catalog, you could just assign barcodes to all the books, then search for them in the catalog and retrieve them easily, even with fully unordered shelves. / The optimal approach is however to catalog the books and also use the thematic shelves. And most public libraries do that, despite the double work. Shelves (i.e. categories) are great in general, except the overly specific - like "Tigers in European zoos in 2023" or "1944 diaries of women in World War II". Oh yes, there are the files that hit these two spots, but it's not a superior way to organize the library. --Enyavar (talk) 16:32, 25 February 2025 (UTC)[reply]
No, that is false. 1. He did not describe that as the problem in that comment at least. 2. That is not the problem at all.
Also it's good that SD is not used at all since volunteer time is valuable and adding redundant SD is a large waste of time ever and if anything should be disincentivized since we got many better things for volunteers to do than writing metadata that is of no use to anyone to 0.1% of files that is already present at the file. For example, by working on readily implementable things that could feasibly double or quadruple Wikipedia readership or improving the MediaSearch or adding content to Wikipedia. Those roundabout explanations for why SD would be useful or even needed are not convincing and based on pipedreams – SD won't magically allow the items to be tagged. If you want that to be done, it needs work on some bots or simply what I have proposed here. I don't see a reply of you there. SD will take "soooooo" much work while the easy-to-use familiar category system make things quick and easy with tools like cat-a-lot and there are several further ways of how to have things more reliably categorized, a second of which is reading the fields of the Summary template which can be used to set categories. If structured data is used for subjects, then make it read-only for users and automatically infer the tags from the categories. "Tigers in European zoos in 2023" would automatically get the SD "tiger" and year "2023" instead of some redundant doublework. In addition, people could use a deepcat viewmode in e.g. the Tigers category where the most useful images are sorted near the top (once again MediaSearch improvements) or use the daterange filter based on the date in the File information template (again see the phab issue). I think for tigers most people would not use such an overspecific cat and people should not move the file only into a year subcat but also into a subject-specific one and at wherever the scope of cats is what one is interested in, one could then use something like a successor of the deepcat gadget or FastCCI to have a modern nonoverspecific view to scroll through. By year categories are just a minor aspect of Commons, the solution would be to have year-categories set (semi-)automatically based on the date in the file info Summary template. Prototyperspective (talk) 00:28, 26 February 2025 (UTC)[reply]
People tend to act like the WMF and/or developers on here are just incompetent slackers but I image if SDC was really the be all end all people treat it is that they would be putting the time and resources into making it viable. This isn't rocket science. They must know it's a hot mess that know one wants. Tangentially, something that I think would solve some is better and or more descriptions templates for specific types of media. As it currently is for something like a postcard, we are forced to use the general description template or one for photograph. Both leave out fields that are important to postcards. But it would help make searching for them a lot easier if the publisher, photographer, location, subject were included in the file description and in specific fields for them. Then the categories for organizing postcards based on those criteria could be axed. Like a couple of thousand categories for postcards by publisher right now that are probably pointless, but the publisher isn't included in descriptions in a lot of instances. So it's really the only option there is to postcards by specific publishers baring people writing better descriptions or using creator templates. Creator templates are another thing like see alsos that are way under used on here BTW but there's already solutions to the problem SDC is meant to solve. People just need to use them. SDC is redundant at best, if not totally worthless at worst though. --Adamant1 (talk) 10:56, 27 February 2025 (UTC)[reply]
Then the categories for organizing postcards based on those criteria could be axed I don't see how that follows; instead one could use a mentioned functionality to read the fields of the file Information template to set the cat (semi-)automatically. Prototyperspective (talk) 13:49, 27 February 2025 (UTC)[reply]
@Prototyperspective: There's a postcard publishers that we're never going to have more then a few images of postcards for and/or where the publishers information just isn't available for whatever reason. Plus ton of them are just two letter initials, if even that. Not to mention a lot of publishers have multiple ways their name is printed on the postcards. Like there's at least a couple of publishers where I knew they published the same postcards because of how the stamp box is designed but a category like Category:Brown square stamp box (postcard publiser) isn't practical. It's not practical to create multiple "by publisher" categories for the same publiser based on if they used there initials, full name, Etc. Etc. on particular postcards. But something like a note about it in the description would be fine. There's also a huge problem with people categorizing images of postcard by publisher but not subject or location. The thing is categorizing an image of a building in a category specifically for that building. It just doesn't happen though. Hundreds of images get dumped in a category like Category:Postcards published by Detroit Publishing Co. and still aren't put in subject based categories years later. So "by publisher" isn't a practical, scalable, way to categorize postcards IMO. Categories are really only good for one or two criteria and in instances where those criteria are totally unambiguous. --Adamant1 (talk) 17:45, 27 February 2025 (UTC)[reply]
  •  Comment I have been frustrated about categories for years. It is a pain to have to look through 100 categories with 1-5 photos in each category to find a good photo. Personally I think 100-200 photos in a category are more suitable because it is very fast to find a photo in a category. If there are 1,000 files in a category sorting in subcategories is a good idea. At least I know now that deepcategory can help a bit. --MGA73 (talk) 19:24, 24 February 2025 (UTC)[reply]
@GPSLeo: What you refer to as "The primary problem" is only a problem if you assume that the subcategory relation is always an is-a relation. And, yes, Pinging @Enyavar there is a bit of "ideology" involved: not in the idea of having SD so much as in the idea that SD is inherently superior to categories. This is almost always based on an argument comparing, on the one hand, what would happen if SD were used in something close to an ideal manner to, on the other, the actually existing state of categories.
And these two issues (failure to tag the nature of a particular category inheritance, ideological preference interfering with synthesizing the two systems) come together. Since the advent of SD, WMF has (as far as I can tell) devoted exactly no resources to improving categories. I don't think the neglect has been consciously driven by ideology, but ideology rarely functions on a conscious basis.
Leaving maintenance categories aside, and sticking to topical categories, the two biggest deficiencies in categories are, as noted, (1) lack of support for multiple languages and (2) lack of ability to express the relationship between a category and its parent categories. (Conversely, the largest disadvantage of structured data is that (3) users access it through an entirely different mechanism than the wikitext with which virtually all experienced Wikimedians are familiar.)
I believe all three of these problems are completely addressable. I won't go into details here, and I'm about to be traveling the next 5 weeks so this isn't a time for me to flesh this out, but if I were a developer trying to address these, here's the general directions I'd be looking at. If someone wants me to flesh this out, hit me up in early April when I should be more available again. Some of these involve integrating wikitext and SDC, some do not.
1) lack of support for multiple languages in categories. If a category has an associated Wikidata item (associated via Commons category (P373) in Wikidata, or possibly just with the interwiki link for the item; I'm going to skip that latter alternative throughout the rest of this and stick to P373), then a bot should be perfectly capable of copying all of the item names, in whatever language, including aliases, into a templated structure on the Commons category page. This would only need to be updated when the Wikidata item changes or the P373 value changes.
2) lack of ability to express the relationship between a category and its parent categories. I see several ways to address this; from an information-theoretic point they are very similar, and a mix-and-match via a bot is possible.
2a) A template-driven structure in the category to express its relation to each parent category. Probably optional, with the default to presume an is-a (instance of (P31)) relationship. It might be simplest to name these precisely from the P-codes of the relevant Wikidata items, ideally with a tool to make that more human-readable (see (3) below). Again, wherever Wikidata is aware of the category via P373, a bot could do an enormous amount of this work.
2b) An extension to "Category" in mediawiki that would allow an equivalent to 2a to go directly into the [[Category]] element. (e.g. a markup like [[Category:Seattle|P=276]] for Category:Buildings in Seattle to say it is located in Seattle. However, I think this is less good than 2a because (1) it would require a change to mediawiki rather than just to tools and (2) it is not good at expressing things like "this category is an intersection of year YYYY and place PLACE".
2c) I could imagine something more dynamic that does all of the calculation of Wikidata relationships among categories on the fly when needed. However, I would have to guess that is more computationally intensive, so a less good idea.
3) users access SDC through an entirely different mechanism than the more familiar wikitext. I believe this could be solved by a serialization/deserialization approach (serialization: SDC => wikitext; deserialization: wikitext => SDC). Presumably the relevant wikitext would be in the form of templates. Admittedly, the serialization side of this is much easier, so it might make sense to think of it first as a read-only mechanism. However, I could imagine a slow, steady implementation of the deserialization side to let more and more SDC content be edited through the wikitext editor. And, of course, something parallel could be done for less technically-inclined users, using the same approach the WYSIWYG editor on Wikipedia has taken to turn several templates into forms. - Jmabel ! talk 20:10, 24 February 2025 (UTC)[reply]
To a certain extent, what you are saying sounds like reinventing Semantic MediaWiki. But hey, maybe that is a better model for commons. SDC kind of just grafted wikidata on to commons, but commons does not have the same requirements as wikidata. I've only recently tried playing with SDC. So far I think its really cool, but as a newbie to SDC there are lot of ambiguities as to how the data is supposed to be (Is depicts anything in the picture or just the main things?). From what I've seen so far though, i think the big problem with SDC is UI. Its hidden away in a separate tab. Interesting and uninteresting data is mixed together (Why oh why do we a bot manually adding properties for SHA1 of files? That makes no sense. Why is something like a checksum displayed at the same prominence as the creator). More to the point though, there is no way to browse the results (Except externally). How can we expect users to care about entering metadata if they can never see the results? With a category, you click on it and get to see other things in that category. Not so with structured data. SDC is never going to succeed as a way to catalog commons if we don't implement the browse through the catalog part. Bawolff (talk) 05:07, 1 March 2025 (UTC)[reply]
Where do you find the time to be so involved on this website may I ask? It’s rather queer. Jon.schmon4862 (talk) 07:34, 19 March 2025 (UTC)[reply]

Make Commons:Civility, Commons:Harassment and Commons:No personal attacks a policy

[edit]
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Clear consensus for making these policies. The Squirrel Conspiracy (talk) 22:49, 31 January 2025 (UTC)[reply]

Recent disputes discussed on the admin boards and concerns from the meta:Universal Code of Conduct/Coordinating Committee showed the need for better conduct policies on Commons. In 2019 there were multiple drafts for such policies created based on the ones from enwiki. These drafts were never proposed to be accepted as official policies. I therefore would now propose that we make the following pages policies:

For the procedure I would propose that the pages can now be edited and discussed for two weeks to make a final version. In two weeks the vote on making these final version a policy can start. GPSLeo (talk) 12:03, 27 January 2025 (UTC)[reply]

  • It's embarrasing that these aren't policies.  Supporting this Bedivere (talk) 13:20, 27 January 2025 (UTC)[reply]
  •  Support Obviously. It's ridiculous that they aren't policies already. --Adamant1 (talk) 13:24, 27 January 2025 (UTC)[reply]
  •  Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:05, 27 January 2025 (UTC)[reply]
  •  Support --Yann (talk) 15:35, 27 January 2025 (UTC)[reply]
  • Support in principle, but it's worth stepping back an evaluating how these guidelines are presently written. As far as I can tell, they all started as copies of the enwiki policies. Wikipedia-specific language was changed, but I don't see any additional specificity for Commons. To some extent "civility is civility" but this is a different project in at least two regards: first and most importantly, Commons is much more diverse than the English Wikipedia. I mean that culturally, but especially linguistically. We primarily communicate in English but unlike a Wikipedia it cannot be taken for granted that everybody speaks English proficiently. A large number of misunderstandings on Commons emerge because of this, and I'd like to see some editing of these policies to explicitly acknowledge this. Second, and less importantly, there are genres of disputes on Commons that are unlike enwiki. Uploads are "owned" in a way that's different from anything on enwiki, discussions like DR can be closed based on correct/incorrect rather than consensus, etc. I'm not certain how these should affect such policies, but it would be a good idea to think about how discussion formats/styles could influence the wording. — Rhododendrites talk |  15:59, 27 January 2025 (UTC)[reply]
    @Rhododendrites: Please feel free to share any specific changes here, as !voting has already started.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:15, 27 January 2025 (UTC)[reply]
    As written in my proposal my intention was not start the voting immediately but to have two weeks for discussion and changes. I am not sure if the current votes are "we need them as policies somehow", "we need them as policies in the current version" or "even if they are changed I would support having them". GPSLeo (talk) 17:11, 27 January 2025 (UTC)[reply]
    I think it's the latter Bedivere (talk) 18:21, 27 January 2025 (UTC)[reply]
    @GPSLeo: To make my vote clear, I mean I support the principle, and the general content of these pages. Yann (talk) 20:30, 27 January 2025 (UTC)[reply]
 Support These aren’t policies yet? Dronebogus (talk) 17:55, 27 January 2025 (UTC)[reply]
 Support. The enwiki policies may not be ideal for Commons, but they're an adequate starting point. Omphalographer (talk) 20:10, 27 January 2025 (UTC)[reply]
@GPSLeo: Where do you intend the discussion to take place? Here, or on the talk pages of the relevant proto-policies? Assuming, of course, that discussion is still expected. --bjh21 (talk) 21:40, 27 January 2025 (UTC)[reply]
  •  Support Libel and wikihounding should also be prohibited, probably as part of the anti-harassment policy. No matter how many FP's you uploaded (dream on)... --A.Savin 23:14, 27 January 2025 (UTC)[reply]
Hopefully the same goes for admins. At least from what I've seen lately it doesn't seem like you guys are much better then normal users at this point. --Adamant1 (talk) 23:28, 27 January 2025 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Additional discussion (Make Commons:Civility, Commons:Harassment and Commons:No personal attacks a policy)

[edit]
@The Squirrel Conspiracy Do you think it is good to close this that fast? There are many comments mentioning that there is some need to adapt the pages for Commons. If they are now a policy every not very minor change would require separate community confirmation. GPSLeo (talk) 08:45, 1 February 2025 (UTC)[reply]
That's fair, but if the proposed changes are uncontroversial, it should be easy to get a consensus for them, and if they are controversial, they shouldn't be in the policies in the first place.
Candidly, I'd like to think that after 15 years, I have a good sense for what does and doesn't get done on this project, and I suspect that no one is going to step up and rewrite the policies regardless of whether the discussion stays open for two weeks or not. Happy to be proven wrong, but there are lots of gaps in Commons' bureaucracy and infrastructure that have never been fixed.
If you want to revert the close, go ahead though. The Squirrel Conspiracy (talk) 10:34, 1 February 2025 (UTC)[reply]
As for the procedure, I would at least wait until one weekend is over, to include people who only find volunteer time in weekends. While I agree with the observation that there have been policy gaps for a long time, but I think the long time span also means that it wouldn't hurt to spend a few more weeks, or at the very least, the proposed 2 weeks. Using Template:Centralized_discussion or even MediaWiki:Sitenotice wouldn't be unreasonable for this, consdiering most users don't frequent to COM:VPP, but are affected. Sitenotice might be more suited for the final decision, though. whym (talk) 02:03, 2 February 2025 (UTC)[reply]
@GPSLeo: Do you think it was premature to promote those pages? I do. Whether we should un-promote them might be a different matter (unless The Squirrel Conspiracy voluntarily undo the changes), though. One remedy might be to recognize that they have community consensus at a general level, and that they are adapted policies and might still have rough edges in specifics. --whym (talk) 10:32, 7 February 2025 (UTC)[reply]
I think is was to early but I would just keep the discussions going in the current way and in some weeks make a final vote to get clear consensus on the final versions. GPSLeo (talk) 18:17, 14 February 2025 (UTC)[reply]
In the past before these stringent rules even became "policy" I already saw at least weekly users clashing because of linguistic and cultural misunderstandings.
How many sysops remember to give the benefit of the doubt before wielding this weapon against minority users?
LOL.--RoyZuo (talk) 14:02, 5 February 2025 (UTC)[reply]

@The Squirrel Conspiracy and Matrix: FYI, the promotion of Commons:Harassment to policy has been undone. Nosferattus (talk) 14:22, 6 February 2025 (UTC)[reply]

To be clear, it was undone by Matrix.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:37, 6 February 2025 (UTC)[reply]
Sorry, I didn't see this discussion, I reverted my reversion. —Matrix(!) ping onewhen replying {user - talk? - uselesscontributions} 18:46, 6 February 2025 (UTC)[reply]
I think this indicate that we could have advertised more before voting: putting a notice on the proposed policy page and its talk page. (Not the fault of the proposer - they specifically said voting was to be done later, not immediately.) whym (talk) 11:39, 7 February 2025 (UTC)[reply]
Is there some way we could specifically mark these as draft policy? - Jmabel ! talk 21:15, 7 February 2025 (UTC)[reply]
There's {{Proposed}} which is close and I think includes what you want. —Justin (koavf)❤T☮C☺M☯ 01:11, 8 February 2025 (UTC)[reply]
But does nothing to suggest that it is a largely agreed-upon draft, and we are just hammering out details. - Jmabel ! talk 04:21, 8 February 2025 (UTC)[reply]
Why not use someting generic like {{Notice}} to insert a short text describing that? I realize the repetitiveness but on the other hand, it's just 3 pages. whym (talk) 06:12, 23 February 2025 (UTC)[reply]
I think it would be a mistake to try to mark these documents as not-quite-policy. That would lead to arguments about which bits were really agreed upon and which bits weren't, which isn't going to help anyone. Much better in my opinion to accept that they're policy now, and to put our efforts into correcting any faults they might have. --bjh21 (talk) 22:18, 4 March 2025 (UTC)[reply]
Why not say both? We can say that they are policies, and that we are still (and we know we should be) making non-trivial corrections to them. It might be somewhat contradictory but I think it would be an accurate reflection of what people here in this discussion thread think collectively. whym (talk) 03:10, 30 March 2025 (UTC)[reply]

Possibly easier way to contact local oversighters via Wikimail

[edit]

Hello,

I had recently the need to contact our Commons oversighters. I knew from my home wiki, DE-WP, that an option to contact the German oversighting team through Wikimail, using de:User:Oversight-Email, is offered. I was a bit disappointed by that Commons is a notable exception of projects where such an easy-access way is not implemented (it may be the largest project where this is not given, according to the description on de:Benutzer:TenWhile6/OSRequester). Could a Wikimail way of oversight contact be enacted, parallel to the existing way of the mailing list? Regards, Grand-Duc (talk) 12:08, 14 February 2025 (UTC)[reply]

 Support Major issue with commons oversight. That and adding a T&S role account for wikimail. I think they attached the emergency account, but I'm unsure. All the Best -- Chuck Talk 17:55, 14 February 2025 (UTC)[reply]
I do not think that it is needed to implement this now as we will soon (I think before the end of 2025) have the new meta:Incident Reporting System made exactly to solve this problem. GPSLeo (talk) 18:15, 14 February 2025 (UTC)[reply]
"Soon" and "Before the end of 2025" is somewhat contradictory! Worst case, that's more than 9 months in the future. Can somebody knowledgeable please inform me and whoever is interested on the amount of work needed to setup such a "contact user account"? The lesser the effort, the sooner it should come, even if it is only for a limited amount of use time. It's kinda the same reasoning as a military who refurbishes a warship, only to put it into reserve status a few months later (like it was done on the carrier USS Franklin (CV-13) or several other US Navy ships after V-J day). The use case is clearly shown, the potential replacement functionality has no clear ETA given yet, so waiting for it is non sensible. Regards, Grand-Duc (talk) 19:01, 14 February 2025 (UTC)[reply]
The problem with an account for this is the question who has access to the account. It would need to be all oversighters that they are able to check each other but everyone who is able to access the account would also be able to change to password and exclude everyone else. Additionally the account should definitely use 2FA what makes it hard to be accessible for all oversighters. The worst scenario would be that someone with access to the account changes the email address unnoticed to fish reports. We could decide on one oversighter who owns this account but in the case of problems (loss of rights and not handing over the account or lost contact/dead) we would need to figure out a solution to regain access through the WMF MediaWiki operations team. Because of the potential serious trouble I think we can keep it as we did for more than one decade or one more year until we have a much better solution. GPSLeo (talk) 19:45, 14 February 2025 (UTC)[reply]
"Potential serious trouble"? Do you hint to that people who sign a confidentiality agreement and identify themselves in front of the site operator would regularly go postal and make nasty trouble, breaching privacy for whatever reason? What's the base for the whole adminship, checkusership and trust in licensing, then? Pinging user:Ra'ike and user:Raymond, the first as OS on DE-WP and the second as local OS: do you have any insight on how the German contact user is set up and if a similar thing is also suitable here and now? Regards, Grand-Duc (talk) 21:14, 14 February 2025 (UTC)[reply]
They don't need account access, they just need the email access, someone from the WMF can have the password. this account only needs to forward all emails sent to it from commons to the oversighter's mailing list. En-wiki can do it for 4 different role accounts, we can do 1. All the Best -- Chuck Talk 22:44, 14 February 2025 (UTC)[reply]
It is not possible to have different mail addresses for wikimail and password reset. Therefore the only thing that could be handled by the WMF could be the second factor. But then setting up the account and logging in would be very complicated. GPSLeo (talk) 05:39, 15 February 2025 (UTC)[reply]
@Grand-Duc Some thought from me as Commons OS. Not discussed with the OS colleagues. First I do not see a big advantage of such a Wikimail: One click to open the Wikimail form and one click on the current e-mail-address to open the mail program. Anyway. Technically it is easy: Creation of the OS user account on Commons with the current mailing list email-adress in the preference. All mail will be forwarded to our mailinglist (not moderated!) and can be handled as usually. One caveat: we do not have a safe place to storing the password. Any of us can have it, of course, but when oversighters change, there is no guarantee that the password will be passed on.
I will ask my OS colleagues today. Raymond (talk) 08:49, 15 February 2025 (UTC)[reply]
Couldn't the foundation have the password? All the Best -- Chuck Talk 23:46, 15 February 2025 (UTC)[reply]
The password doesn't matter much because anyone with access to the mailing list can reset it. AntiCompositeNumber (talk) 03:23, 28 February 2025 (UTC)[reply]
The IRS does not currently support oversight requests, if you select the option for "doxxing" it tells you to report it on a public page like it does everything other than threats of harm. The future plans for the tool are unclear, and I have no further information at this point. AntiCompositeNumber (talk) 03:25, 28 February 2025 (UTC)[reply]
 Support unless this is somehow tremendously more difficult than I can imagine it to be. - Jmabel ! talk 19:44, 14 February 2025 (UTC)[reply]
@Grand-Duc @Adamant1@Jmabel @GPSLeo @AntiCompositeNumber @Alachuckthebuck After discussion in the OS team I have created User:Oversight Commons . I have fully proteted the user and user talk page to prevent abuse. Raymond (talk) 09:55, 18 March 2025 (UTC)[reply]
@Raymond, Thank you so much, shouldn't the account be blocked to prevent abuse? All the Best -- Chuck Talk 15:31, 18 March 2025 (UTC)[reply]
Why should the account be blocked to prevent abuse? If an oversighter would want to abuse the account they could just unblock the account. GPSLeo (talk) 16:31, 18 March 2025 (UTC)[reply]
And if it's compromised we have bigger problems. None of the other role accounts are, there is no reason for this one to be. AntiCompositeNumber (talk) 02:10, 19 March 2025 (UTC)[reply]

Add an outcome of LicenseReview

[edit]

Add an outcome "indeterminable / review impossible" for Template:LicenseReview.

Reason:

for example, File:Jordan protest in front of police2.PNG claims to be made by VOA, but because the youtube video is gone it's impossible to verify. nonetheless, the claim appears trustworthy, so it doesnt seem appropriate to either pass or fail it. a sensible thing to do would be to simply remove the Template:LicenseReview.

But, simply removing it will not prevent certain users slapping the template on it again.

As such, add an outcome, termed "indeterminable" or "review impossible", to signify that users have tried to review the file but could not succeed because source is gone, but there is no significant doubt about the authenticity of the claim, so the file is tolerated. RoyZuo (talk) 10:40, 25 February 2025 (UTC)[reply]

 Support - Jmabel ! talk 21:14, 25 February 2025 (UTC)[reply]
 Support per Commons:Village_pump#Category:License_review_needed and the links mentioned there. --MGA73 (talk) 07:49, 28 February 2025 (UTC)[reply]
 Support Christian Ferrer (talk) 08:44, 28 February 2025 (UTC)[reply]
 Support --Yann (talk) 09:24, 28 February 2025 (UTC)[reply]
 Support --Grand-Duc (talk) 13:25, 28 February 2025 (UTC)[reply]
 Support only if there is some sufficient method to reduce cases of this being set mistakenly. People should not set it if a youtube video is down and they can't check it anymore. They should only set it if they also checked the Wayback Machine properly to see whether it has it archived. Prototyperspective (talk) 14:41, 5 March 2025 (UTC)[reply]
 Support 1989 (talk) 19:32, 5 March 2025 (UTC)[reply]
 Support good idea. and also... if another LR finds another source about image, he should change it to passed. modern_primat ඞඞඞ ----TALK 02:34, 19 March 2025 (UTC)[reply]

 Comment Your example of File:Jordan protest in front of police2.PNG is actually one on which I, as a reviewer myself, found a roundabout way to pass the review. Fortunately, VOA maintains a directory of contributors, including the editor named as author in the example file. Google made me find the listing of contributions of Elizabeth Arrott on the VOA page, where this is listed: https://www.voanews.com/a/jordanian-protests-call-for-revolution-toppling-of-king/1547601.html . The date and general appearance of the images there fit our upload, hence I passed the review. Regards, Grand-Duc (talk) 13:25, 28 February 2025 (UTC)[reply]

  •  Question I wonder if it should be a simple "indeterminable" or if there should be a field where reviewer could explain why the file could be kept even if it could not be reviewed. I imagine that if reveiwer think the file should be deleted then the review would be failed instead. --MGA73 (talk) 11:08, 4 March 2025 (UTC)[reply]
    it's not "kept". it's merely tolerated. anyone could send it to DR if they have a significant doubt of the claimed licence. RoyZuo (talk) 12:55, 5 March 2025 (UTC)[reply]
    Yeah but then the question is if reviewer should (be able to) add a reason why they tolerate the file. --MGA73 (talk) 14:09, 5 March 2025 (UTC)[reply]
    I think it's hard to explain the "lack of significant doubt". RoyZuo (talk) 19:27, 6 March 2025 (UTC)[reply]
    Any of the following would be "significant doubt":
    1. can be found by reverse image search, and some results might suggest the image has been published elsewhere by different claimants of copyright predating commons upload.
    2. uploader has rampant copyvio history.
    3. the claimed source doesnt seem to exist.
    4. unlikely claim (e.g. claims to be ccbysa from disney but disney most probably doesnt publish ccbysa; photo of north korean soldier in north korean tank but claims to be us-army photo and pd; claimed source website has weird domain that's more typical of content farm / spam...)
    ...
    if the reviewer cannot find a way to critique it, that will be the lack of significant doubt. RoyZuo (talk) 19:42, 6 March 2025 (UTC)[reply]
    I agree that it may be easier to explay why something looks fishy than why not. So I guess your plan is that reviewer just add an "indeterminable" and then the template would add a suitable text. I can live with that. Next question is what such a text should be. Perhaps something like "A reviewer have reviewed this file but it was not possible to confirm the license because the file is not available on the provided source. However, reviewer did not find significant doubt about the validity of the license claim. If you disagree you may start a deletion request and explain why you think there is significant doubt as of why the license claim is valid."? --MGA73 (talk) 09:14, 7 March 2025 (UTC)[reply]
    Yes something along those lines will work. RoyZuo (talk) 09:59, 7 March 2025 (UTC)[reply]
    An optional "reason" parameter is helpful too.
    For example #c-Grand-Duc-20250228132500-Add_an_outcome_of_LicenseReview is commendable, but still that's just circumstantial evidence because the exact image or the video was not found at the VOA website. So if I were to decide, instead of "passing" it, I would let it be "indeterminable", with reason=Grand-Duc's analysis. (Because there's a mini concern: VOA sometimes reuses other news agencies' works, sometimes even mixing external and their own together in one article.) RoyZuo (talk) 10:11, 7 March 2025 (UTC)[reply]
    Please visit COM:Questionable YouTube videos if you would like to view (and maybe add) YouTube channels who have used phony/suspicious CC BY licenses. JohnCWiesenthal (talk) 18:14, 7 March 2025 (UTC)[reply]
[edit]

In theory, photographs licensed on Commons are expected to have the informed consent of the people depicted in the photo: Resolution:Images_of_identifiable_people (2011)

In practice, this is rarely even asserted, let alone documented or enforced. There are less than 20,000 files with consent assertions: Consent tracking

I propose that this might be improved by adding {{consent|query}} to photos that meet some set of criteria. Perhaps those where:

  1. An individual is the prominent focus of the photo
  2. An individual is not posing or making eye contact
  3. An individual is in a state of undress ("Nudes, underwear or swimsuit shots")

If nothing else, adding the consent query tag will increase awareness that informed consent is an expectation. And I'm assuming that this one of the reasons the consent query template was established.

What is a responsible and productive way to go about this? Jerimee (talk) 22:41, 25 February 2025 (UTC)[reply]

Are you saying that any one of these criteria triggers a need for consent, or only the combination of all three?
Even if the latter, I can immediately think of photos I've taken that fall under all three of the criteria you have mentioned and which certainly does not require more explicit consent (examples are necessarily NSFW because of criterion 3):
I'm not sure exactly; I appreciate input. I understand why photos of that activity may not require (additional) consent. I appreciate that example.
I expect the criteria will need to refined based on response and what is learned by doing more of this. For my part, I know I will often get it wrong and apply the tag where it isnt much needed, especially at first. I will need to learn and improve.
One thing that I find confusing/tricky is "What constitutes public space?" I feel like this is highly circumstantial and varies considerably from culture to culture etc.
I feel strongly that people who take photos in the context of cultures they do not belong to... I feel like that is more problematic than people taking photos of cultures they belong to or are culturally fluent in. (I've phrased this poorly!) Jerimee (talk) 18:45, 26 February 2025 (UTC)[reply]
As reference: Commons:Deletion requests/File:Kochendes Paar in einer Küche 2017-01-15.jpg and Commons:Deletion requests/File:Little-girl-570864 1280.jpg, which both touch on your very subject. I support your notion of processing and documenting consent, though. Regards, Grand-Duc (talk) 19:57, 26 February 2025 (UTC)[reply]
I'm no expert, but those look to me like photos where the subjects are clearly posing/posed, especially the first one. This seems visibly apparent to me; I don't exactly know why... They seem professional, deliberate, staged/not candid, purposefully arranged, and studio lit. So excellent examples of what we are not trying to flag. Jerimee (talk) 06:02, 27 February 2025 (UTC)[reply]
I don’t like the overt focus on perceived nudity. Nudists or Himba women probably do not care that they are being photographed in what western society considers a “state of undress”, and even in fairly conservative western nations most people would not consider photographing someone in a swimsuit a violation of privacy on a public beach. Dronebogus (talk) 15:38, 28 February 2025 (UTC)[reply]
Whether you like it or not, nudity is great. Lack of consent is not, especially when the unconsented media is globally licensed such that the depicted person has no control over how their likeness is used.
Nudists and Himba women do not need you to speak for them. Unless of course you are a Himba woman in which case your comment is entirely appropriate and appreciated. Unsourced hypothetical assertions about groups of people made by people who do not belong to those groups aren't especially helpful.
Who goes to a beach and intentionally photographs strangers without their consent? Nudists, since you mentioned them, explicitly do not do this. 1 2 3 4
This discussion is not meant to be a forum for criticizing our existing consensus guidelines. When you say you don't like the overt focus, was that meant to suggest that consent queries be focused elsewhere? If so, where would that be? How can we improve our work together? Jerimee (talk) 05:05, 1 March 2025 (UTC)[reply]
There are many files like this one - File:Pyrotechnic show at the 2013 Ostrov rock festival.jpg - where the depicted persons are clearly performing, but where it also seems unlikely they gave consent to have their likeness licensed for anyone in the world to do whatever they want with. Performers make a living by selling their likeness; there is no (implicit or other) agreement to allow strangers to give it away for free without reservation. These photos are often released requiring the person photographer to be attributed, but with little thought given to the rights of the person photographed. Jerimee (talk) 16:07, 12 March 2025 (UTC)[reply]
I don't know the Russian laws on that and whether doing a performance like that is implicit consent to be photographed (it would be in the U.S.). Normally the way we handle that for U.S. photographs it to add {{Personality rights}}, indicating that there are likely to be many potential uses for which you would need the subject's consent. - Jmabel ! talk 16:32, 12 March 2025 (UTC)[reply]
There are moral as well as legal considerations. That said, perhaps my idea that the photos are actually licensed with the licenses attributed to them is overly literal. If that is the case, it would be nice to have that made more explicit in the licenses themselves. Jerimee (talk) 16:42, 12 March 2025 (UTC)[reply]
A photographer (or other copyright-holder) can only license the rights that they own. Any picture of a living human has some limitations on how it can be used, and some of those rights either cannot be waived, or someone would be out of their mind to waive them. For example, virtually no picture of a living human that we have on Commons could legitimately be used in the U.S. in a context where it implied that they endorse a particular product, politician, etc., and we would not expect anyone ever to waive a right like that. - Jmabel ! talk 06:04, 13 March 2025 (UTC)[reply]
I may be confused on what our licenses are/do. I am assuming "use for commercial purposes" permits usage in commercials, among other things. Jerimee (talk) 06:21, 13 March 2025 (UTC)[reply]
@Jerimee: in the case of a picture of a living human being absolutely not, and yes that word "commercial" is confusing because in the U.S. that is the common word for a radio or television advertisement (in the UK, they are generally "adverts"). What "commercial use" means in the CC licenses is that you can (for example) use it in a book or newspaper (or even a post card or calendar) which is "commercial" in the sense that is is sold for money. This is still limited by personality rights. In theory, you could slap {{Personality rights}} on any picture of a living person (and some uploaders do that). In practice, I think most of us use it only where we think something might be more than routinely sensitive or where the personality rights issues might be more than usually extensive.
Reuse of any image is always subject to the laws of the country where you are using it. - Jmabel ! talk 14:47, 13 March 2025 (UTC)[reply]
The personality rights tpl says this: Wikimedia Commons only accepts free content, that is, images and other media files that are not subject to copyright restrictions which would prevent them being used by anyone, anytime, for any purpose.
I'm not sure your claim denying images "... could legitimately be used in the U.S. in a context where it implied that they endorse a particular product, politician, etc...." is as strong as I first took it to be.
I appreciate your input; thank you for your replies. Jerimee (talk) 07:01, 15 March 2025 (UTC)[reply]
That is a non-copyright restriction. Nowhere does it say "are not subject to personality rights restrictions" or "are not subject to trademarks". - Jmabel ! talk 16:41, 15 March 2025 (UTC)[reply]
File:Purple people eater (50350528136).jpg I share this example because
  1. it is ambiguous if this person knew they were being photographed (my read of "candid shot" is "creep shot")
  2. highly unlikely they gave informed consent
  3. they aren't easily identifiable, but certainly possible
What do you think? Jerimee (talk) 21:33, 20 March 2025 (UTC)[reply]
I certainly would not have uploaded that. It is certainly legal in the U.S. (no expectation of privacy on a public beach), but it seems out of scope, of only prurient interest, and potentially embarrassing to its (probably unknowing) subject. If you wish to nominate it for deletion, I would certainly vote to delete. - Jmabel ! talk 23:29, 20 March 2025 (UTC)[reply]
I don’t really view it as prurient or even OOS, but it’s a rather unflattering image of an unaware subject as well as a very common topic illustrated poorly. I would not really feel grotesquely violated if this was me and it was just hanging around commons among countless other images, but it wouldn’t necessarily want it broadcast to the world on a high traffic page. Dronebogus (talk) 06:06, 21 March 2025 (UTC)[reply]
What do you think about tagging photos with the consent-query template, as an interim step toward, or perhaps in place of, a delete request?
I picked this one as an example because I (incorrectly, as it turns out) thought this particular image was not eligible for personality rights.
I appreciate you mentioning the personality rights template. I prefer the consent query template because, in my mind at least, it better addresses our code of conduct re moral rights (Commons:Photographs of identifiable people). I agree that the pr tpl is more ubiquitous and serves a similar purpose, but the focus on the legal aspect does little to enforce or inform about the equally necessary moral requirement for consent. Jerimee (talk) 17:15, 21 March 2025 (UTC)[reply]
@Jerimee: how would any image of a living or recently living person in the U.S. be "not eligible for personality rights"?
Consent, in a legal sense, is present. Again: no legal expectation of privacy at a public beach in the U.S., consent is implicit.Still, it's an unflattering picture, and I see no educational value in it. Since I take it you do not plan to nominate this for deletion I will. - Jmabel ! talk 18:05, 21 March 2025 (UTC)[reply]
OK. I mean, I don't mind doing it, but it sounds like you are. I thought photos had to have at least half of the face visible; my mistake. Jerimee (talk) 18:28, 21 March 2025 (UTC)[reply]
Jerimee (talk) 22:34, 20 March 2025 (UTC)[reply]

Proposal (change GFDL cut-off date)

[edit]

I (User:MGA73) suggest that we make a one-time change to the cut-off date for files licensed GFDL-only from 15 October 2018 to 31 December 2024.

There are estimated 153.8 k files uploaded to other wikis than Commons. Many of those are dual licensed or uploaded before the cut-off date so they are eligible to move to Commons provided there are not other reasons not to do so (COM:DW and lack of COM:FOP for example). But around 2.1 k files are GFDL only and uploaded after the cut-off date. It means they can't be transferred to Commons. It makes it harder for other wikis to use them because they have to be uploaded to every single wiki that would like to use them. It also means that wikis that do not allow local upload can't use the files.

If we change the cut-off date it will help us centralize the files allready uploaded on a wiki and make it easy to use them on all other wikis. It will not give users the option to bypass the restrictions on GFDL on Commons by uploading new files licensed GFDL only to a wiki and then move them to Commons because the suggested cut-off date are two months prior to this proposal.

Background and rationale (change GFDL cut-off date)

[edit]
Why GFDL is not a good license for media files

Commons decided to ban (or restrict) files licensed GFDL-only with a few exceptions per 15 October 2018 after this accepted proposal to phase out GFDL for most media. The reason for the ban is that GFDL is not a good license. By banning files licensed GFDL-only, users who want to upload files to Commons are forced to choose a better license.

Some wikis have banned GFDL-only files too. For example, English Wikipedia, Japanese Wikipedia, German Wikipedia, Russian Wikipedia and Wikivoyage. Other wikis do not formally have a ban but have removed GFDL from MediaWiki:Licenses, meaning users can still upload files as GFDL but only if they choose the template manually.

In August 2021, I suggested changing the cut-off date on Commons to 1 August 2021 after English Wikipedia decided to restrict GFDL-only files too. However, there was not enough support for the proposal at that time.

I think there were two reasons for the lack of support for the proposal:

  1. It was not clear how many files it would affect.
  2. As long as it is possible to upload new files licensed GFDL-only at some wiki projects, there is a risk that someone will use that as a backdoor to get the files to Commons if Commons changes the cut-off date again and again.

Since 2021 I have been working on files across all wikis:

  1. I have checked and made sure that categories and templates related to GFDL are now linked via Wikidata on all wikis. That will help us get a more correct number of files.
  2. I have been working on w:en:Wikipedia:GFDL standardization and the GFDL update and moved thousands of files to Commons and have been nominating invalid licensed files for deletion. That have reduced the number of files outside Commons and have given me an idea how many new files are licensed GFDL.
  3. I have been checking wikis to see if they have files uploaded and if GFDL is listed in MediaWiki:Licenses. If GFDL was listed as GFDL-only and wiki was still open for uploads I have often suggested to remove GFDL and several wikis have now removed GFDL. See this list. That should reduce the number of new files licensed GFDL-only. It also gives me an idea how many wikis agree to remove GFDL.
  4. I have made a list of all files licensed GFDL and counted/estimated how many are not eligible for Commons because of the cut-off date. See table below:
Family Files Date issues
Wikibooks 2,370 6
Wikinews 40 0
Wikiquote 5 0
Wikisource 189 6
Wikiversity 30,633 0
Wikivoyage 133 0
Wikipedia 118,608 2,060
Wiktionary 103 0
Special wikis 635 0
Grand total 152,716 2,072

Some of the files licensed GFDL can't be moved to Commons because of FOP issues, and many are copyright violations. I have tried to exclude those in the count of files with date issues above. But I have to use Google Translate on many wikis. Also some files may be uploaded to more than one wiki but they should only be moved to Commons once. So the numbers are not 100 % accurate.

Based on the above, it is my conclusion that the number of new files licensed GFDL-only is limited. Since GFDL has been removed from a number of MediaWiki:Licenses or are now only there as a dual-license, the number of new uploads with GFDL-only should be very limited in the future.

It was suggested to make an RfC on meta to establish a global restriction for GFDL. However, I do not think that it will be approved. First because some wikis seem to be more open to accepting GFDL for example Wikibooks communities, Wikiversity communities, and some (often smaller) Wikipedias. Second because even when it is reported on meta that some wikis have thousands of unlicensed or invalid non-free files, there seems to be an opinion that it is not something meta or other communities should interfere with because each community are independent.

I have some lists like m:User:MGA73/GFDL files and User:MGA73/GFDL-list if anyone would like more details. If anyone would like to help check and move files and perhaps contact the wikis that still have GFDL files uploaded and/or have GFDL listed on MediaWiki:Licenses it is ofcourse most welcome.

List of wikis with files and GFDL-only in MediaWiki:Licenses (change GFDL cut-off date)

[edit]

Update: m:User:MGA73/GFDL_files/Licenses#Wikis_with_GFDL_or_variants_and_files this list shows the wikis that have GFDL in MediaWiki:Licenses and have files uploaded. I think those are the wikis that are in risk of still uploading GFDL-only files. I have listed if GFDL is there as GFDL-only or as a dual license. Circa 60 wikis have GFDL-only but many of those send user to Commons if they click "Upload file" and some of them said it was a waste of time to remove GFDL when local uploads don't happen. Everyone is welcome to help check and update and contact the wikis to ask them to remove GFDL. — Preceding unsigned comment added by MGA73 (talk • contribs) 14:45, 5 March 2025 (UTC)[reply]

Update 2: Copied the wikis here with info about the number of files licensed GFDL and those with date issues

Wiki Mention Files GFDL-files Date issues File list Remarks Latest upload any license Latest upload GFDL-only
n:ar:MediaWiki:Licenses GFDL 2 0 0 n:ar:Special:FileList GFDL-only 2018 N/A
s:ar:MediaWiki:Licenses GFDL 4041 0 0 s:ar:Special:FileList GFDL-only 2021 N/A
w:bar:MediaWiki:Licenses GFDL 1152 318 0 w:bar:Special:FileList GFDL-only (latest GFDL-only file a bit unclear because of dual license). 2023 2017
b:de:MediaWiki:Licenses GFDL 3539 669 0 b:de:Special:FileList GFDL-only (not recommended) 2024 2018
v:de:MediaWiki:Licenses GFDL 2904 43 0 v:de:Special:FileList GFDL-only 2024 2009
wikt:de:MediaWiki:Licenses GFDL 92 0 0 wikt:de:Special:FileList GFDL-only 2024 N/A
n:fa:MediaWiki:Licenses GFDL 23 1 0 n:fa:Special:FileList GFDL-only 2012 N/A
wmf:MediaWiki:Licenses GFDL 816 39 0 wmf:Special:FileList GFDL-only (only admins and editors) 2025 2010
b:he:MediaWiki:Licenses שימוש חופשי עם קרדיט 1708 87 2 b:he:Special:FileList GFDL-only (not recommended) 2024 2021
voy:he:MediaWiki:Licenses GFDL 124 1 0 voy:he:Special:FileList GFDL-only 2023 N/A
b:hr:MediaWiki:Licenses GFDL 167 157 0 b:hr:Special:FileList GFDL-only 2017 2007
q:hr:MediaWiki:Licenses GFDL 4 0 0 q:hr:Special:FileList GFDL-only 2013 N/A
b:hu:MediaWiki:Licenses GFDL 21347 127 0 b:hu:Special:FileList GFDL-only 2025 2021
q:hu:MediaWiki:Licenses GFDL 54 5 0 q:hu:Special:FileList GFDL-only 2014 N/A
w:kk:MediaWiki:Licenses GFDL 11613 292 0 w:kk:Special:FileList GFDL-only (one file deleted and three are most likely incorrectly licensed) 2025 2021
w:ko:MediaWiki:Licenses GFDL 14539 1,366 0 w:ko:Special:FileList GFDL-only (only if not possible to upload to Commons) 2025 2014
n:ko:MediaWiki:Licenses GFDL 1 0 0 n:ko:Special:FileList GFDL-only (only if not possible to upload to Commons) 2010 N/A
mw:MediaWiki:Licenses GFDL 2761 87 0 mw:Special:FileList GFDL-only (only admins and uploaders) 2025 ?
wikt:ml:MediaWiki:Licenses GFDL 4 1 0 wikt:ml:Special:FileList GFDL-only 2012 2008
b:nl:MediaWiki:Licenses GFDL 20 12 0 b:nl:Special:FileList GFDL-only 2023 2006
w:pl:MediaWiki:Licenses GFDL 261 50 0 w:pl:Special:FileList GFDL-only (seem only files with FOP-issues are uploaded) 2025 2018
s:pl:MediaWiki:Licenses GFDL 129 41 0 s:pl:Special:FileList GFDL-only 2024 N/A
b:pt:MediaWiki:Licenses GFDL 520 270 0 b:pt:Special:FileList GFDL-only 2012 2011
w:ro:MediaWiki:Licenses GFDL 117792 515 0 w:ro:Special:FileList GFDL-only (only meant for documents - Appears to be "good", see note below) 2025 2017
b:ro:MediaWiki:Licenses GFDL 47 0 0 b:ro:Special:FileList GFDL-only (only accepted for documents) 2014 N/A
w:ta:MediaWiki:Licenses GFDL 9005 528 0 w:ta:Special:FileList GFDL-only 2025 2015
q:ta:MediaWiki:Licenses GFDL 8 0 0 q:ta:Special:FileList GFDL-only 2016 N/A
s:ta:MediaWiki:Licenses GFDL 41 0 0 s:ta:Special:FileList GFDL-only 2020 N/A
wikt:ta:MediaWiki:Licenses GFDL 194 46 0 wikt:ta:Special:FileList GFDL-only 2015 2013
w:tg:MediaWiki:Licenses GFDL 527 0 0 w:tg:Special:FileList GFDL-only 2025 N/A
w:tt:MediaWiki:Licenses GFDL 6780 1 0 w:tt:Special:FileList GFDL-only 2025 N/A
q:ur:MediaWiki:Licenses GFDL 9 0 0 q:ur:Special:FileList GFDL-only 2018 N/A

Comments from c:Commons:Village_pump/Copyright#GFDL_license_across_wikis:

Note on ro.wikipedia: listed under Alte licențe libere (other free licenses), with a warning that it is more intended for documents. There is no explicit statement that the licenses in this section are acceptable, but given that the section includes things like Imagine asupra căreia s-a renunțat la drepturile de autor (images were the copyright-holder has given up their rights), it would appear so. - Jmabel ! talk 16:01, 20 October 2024 (UTC)[reply]
The situation is not necessarily a lot clearer for ro.wiktionary and ro.wikisource, both of which say simply Licențe libere - Licența GNU pentru o documentație liberă ("Free licenses - GNU license for free (libre) documentation.") There is nothing explicit there about whether the license is acceptable for images or not. - Jmabel ! talk 16:07, 20 October 2024 (UTC)[reply]

The list shows that the wikis that have the most number of files licensed GFDL no longer mention GFDL at MediaWiki:Licenses or they now only mention it as a dual-license.

Feel free to check the wikis and if you can persuade them to remove GFDL or change it to a dual-license it would be great. Please strike out or remove wikis if you it works. --MGA73 (talk) 20:12, 9 March 2025 (UTC)[reply]

I have removed a number of wikis that removed GFDL. --MGA73 (talk) 06:21, 12 March 2025 (UTC)[reply]

List of wikis with GFDL date issues

[edit]

Update 3: The list User:MGA73/GFDL-list show wikis with GFDL-files and if there are any with date is-sues. Date issues are files uploaded after 15 October 2018.

Someone commented on what has been done to make users stop using GFDL and relicense files already uploaded. So I have made a list of wikis and users with 5 or more GFDL-files with date issues.

Wiki Category Files Total Files GFDL Date Issue Remarks. (Blocked users are ignored. Users with no edits for years are ignored. Month/year for latest edit added for non-active users.)
w:ar: w:ar:Category:صور جنو منشأة بواسطة المستخدم
w:ar:Category:صور رخصة جنو
w:ar:Category:لقطات شاشة لويكيبيديا
w:ar:Category:ملفات رخصة جنو للوثائق الحرة مع إخلاء المسؤولية		 53,836 574 17 ar:User:MGA73/GFDL (Latest GFDL upload 2020):
w:az: w:az:Category:Fayl:GFDL 14,854 1,310 390 az:User:MGA73/GFDL (Latest GFDL upload March 2023):
w:bs: w:bs:Category:GFDL slike
w:bs:Category:Screenshot Wikipedije		 5,520 228 23 bs:User:MGA73/GFDL (Latest GFDL upload 2020):
w:de: w:de:Category:Datei:GFDL 129,648 15,671 106 de:User:MGA73/GFDL (latest upload 2019 or 2024 - uploads after 2019 are uploaded on old files, copied from Internet or likely PD-old):
w:en: w:en:Category:GFDL files with disclaimers
w:en:Category:GFDL files
w:en:Category:Screenshots of Wikipedia
w:en:Category:User-created GFDL files		 931,667 47,742 510 en:User:MGA73/GFDL (Latest upload 2021. Later uploads are reuploads from other wikis (FOP-issues)):
w:hr: w:hr:Category:GFDL slike
w:hr:Category:Slike GFDL-ja
w:hr:Category:Slike snimke ekrana Wikipedijinih stranica		 21,900 1,140 620 hr:User:MGA73/GFDL (Latest GFDL upload 2021):
w:id: w:id:Category:Berkas GFDL dengan penyangkalan
w:id:Category:Berkas GFDL
w:id:Category:Gambar berlisensi bebas (GFDL) (Karya sendiri)
w:id:Category:Tangkapan layar Wikipedia		 59,483 4,611 90 id:User:MGA73/GFDL (Latest GFDL upload 2022 + later reuploads):
  • Some FOP issues and internet files.
  • id:User:Aryphrase 60 Asked user to relicense. No response. (Latest GFDL upload 2020 + later reupload 2022)
  • id:User:Jajang Surahman 8 Asked user to relicense. (Latest GFDL upload 2022, latest edit October 2023)
w:lij: w:lij:Category:File GFDL 18 16 16 lij:User:MGA73/GFDL (Latest GFDL upload 2025):
  • Spoken Wikipedia should be CC-BY-SA-4.0.
  • lij:User:Arbenganese 7 Asked user to relicense. (Latest GFDL upload 2025)
  • lij:User:N.Longo 7 Asked user to relicense. (Latest GFDL upload 2024)
w:lt: w:lt:Category:GFDL paveikslėliai
w:lt:Category:GFDL-self paveikslėliai		 28,061 1,713 48 lt:User:MGA73/GFDL (Latest GFDL upload June 2024):
w:mk: w:mk:Category:ГЛСД-слики
w:mk:Category:ГЛСД-слики-with-disclaimers		 9,392 478 15 mk:User:MGA73/GFDL (Latest GFDL upload 2021):
  • mk:User:Carshalton 14 Asked user to relicense. But most are from web with permission. (Latest GFDL upload 2021)
w:ml: w:ml:Category:ജി.എഫ്.ഡി.എൽ ചിത്രങ്ങൾ
w:ml:Category:വിക്കിപീഡിയ സ്ക്രീൻഷോട്ടുകൾ		 7,351 97 33 ml:User:MGA73/GFDL(Latest GFDL upload 2021):
w:sr: w:sr:Category:ГЛСД слике са одрицањем
w:sr:Category:ГФДЛ слике
w:sr:Category:Снимци екрана са Википедијиним страницама		 38,728 2,622 90 sr:User:MGA73/GFDL (Latest GFDL upload 2025):
w:tr: w:tr:Category:GÖBL dosyaları
w:tr:Category:Vikipedi ekran görüntüleri		 42,577 214 3 tr:User:MGA73/GFDL (Latest GFDL upload 2021):
  • A few may not be eligible.
  • None with 5 or more
w:uk: w:uk:Category:Знімки екрану із Вікіпедією
w:uk:Category:Зображення GFDL, завантажені до Вікіпедії їх авторами
w:uk:Category:Зображення GFDL		 114,105 6,874 5 uk:User:MGA73/GFDL (Latest GFDL upload 2025):
  • Many have FOP-issues or lack proof of permission (COM:VRTS)
  • uk:User:Polonskiy 7 FOP-issues. Asked user to relicense. (latest GFDL upload 2019, latest edit December 2023)
Total 83,416 1,966 List is updated March 31 2025.

The list shows that there are 14 wikis (all Wikipedias) and 42 users with 5 or more files with date issues.

4 users have more than 100 uploads. One is blocked and the 3 other have not uploaded GFDL files since 2021.

You can also see there are almost no uploads in 2024 and 2025. I have checked and new up-loads are mostly reuploads of existing files (crops, edits etc.) or copying files from other wikis because there are COM:FOP-issues. Some are also likely to have a wrong license so they should be fixed or deleted.

So I think GFDL uploads are not really a problem anymore. I see no indications that any users try to get around the ban on Commons by uploading the files to another wiki somewhere.

If someone would like to see the files you can click the links above named "xx:User:MGA73/GFDL". Everyone are of course welcome to check files and talk to users.

I will ping the users later so they know that they are being mentioned. --MGA73 (talk) 09:30, 20 March 2025 (UTC)[reply]

Votes and discussion (change GFDL cut-off date)

[edit]

As proposer of this suggestion I  Support the change of cut-off date. I hope many users will join this vote/discussion and comments and questions are ofcourse welcome. MGA73 (talk) 19:29, 4 March 2025 (UTC)[reply]

 Oppose. This feels like it's just kicking the can down the road. So long as GFDL-only uploads are still allowed on some wikis, we'll inevitably end up with more of these files; extending the cutoff for migration without fully addressing the problem at the source just establishes a norm that the cutoff doesn't actually mean anything. I might be willing to support a proposal which was limited to wikis which have committed to no longer accepting new GFDL uploads. Omphalographer (talk) 22:59, 4 March 2025 (UTC)[reply]
There are like 800 wikis and if you want all of them to ban GFDL it is impossible. The top five wikis no longer mention GFDL on MediaWiki:Licenses. --MGA73 (talk) 06:57, 5 March 2025 (UTC)[reply]
I added a link above that should hopefully make it easier to see which wikis still have GFDL on the list of licenses. --MGA73 (talk) 06:40, 6 March 2025 (UTC)[reply]
@ Omphalographer Hello, I have now also added #List of wikis with GFDL date issues where you can see more about the users that have uploaded files licensed GFDL. I think it shows that GFDL is not really in use anymore.
I would really appriciate it if you could tell me what more should be done before you would support the proposal. --MGA73 (talk) 12:11, 20 March 2025 (UTC)[reply]
 Oppose The decision to stop allowing that license was done to protect our end users. That makes me loath to undermine it. The sister projects have had years to sort this out and have chosen not to ("If you choose not to decide, you still have made a choice" -Rush). That said, I don't know what outreach has been done to either the projects still allowing it or the uploaders still using it, so I don't know if additional outreach would be effective at getting at existing files dual licensed. The Squirrel Conspiracy (talk) 23:51, 4 March 2025 (UTC)[reply]
I do not think that GFDL pose a danger to our end users it is only a difficult license to use on non-electronic products. As I wote English Wikipedia and other (main) wikis have removed GFDL-only as an option. But there are more than 800 wikis and some of them does not even care about copyright. As it is now English Wikipedia have banned GFDL but around 480 files are stuck there because the ban was not made untill August 2021. --MGA73 (talk) 06:57, 5 March 2025 (UTC)[reply]
Some of the wikis I have been talking to had no idea GFDL was bad. So it is not always because they do not want to remove GFDL. --MGA73 (talk) 06:40, 6 March 2025 (UTC)[reply]
@ The Squirrel Conspiracy Hello. You mentioned the outreach to the projects still allowing and the uploaders still using it. So here is a summary:
  • There are 868 wikis and I have in most cases ignored those have no files (388 wikis) even if GFDL in theory could be uploaded there. I have generally also ignored wikis with only a few files and without GFDL on the list of licenses (MediaWiki:Licenses). If wikis and users only use GFDL as a dual license I have normally only said something to that if they used an old version of Creative Commons instead of 4.0.
  • For wikis with GFDL-only I have suggested that they removed GFDL from the list. Until recently I ignored wikis that had no uploads for years but based on the comments, I have also started suggesting them to remove GFDL.
  • If I noticed active users that still uploaded GFDL-only I have suggested that they relicensed the files and uploaded with a CC in the future. In many cases they agreed.
  • I can only think of one wiki where some users insisted on GFDL and that was English Wikipedia. There I suggested to ban GFDL and that suggestion was met in 2021.
  • Then there are a few wikis where users sadly just uploaded Internet files and licensed them GFDL. There admins have a cleaning up to do. For example in hr:Kategorija:Slike GFDL-ja. But according to petscan the latest upload there is from 2021. I have not asked users to relicense because its a waste to relicense copyvios.
  • Right now I can only think of one wiki where users still upload GFDL-only: lij:Categorîa:File GFDL. It is spoken Wikipedia articles so the license should be CC-BY-SA-4.0. I told them and hope for a response.
Can you perhaps provide any further actions I could do that would make you support the suggestion? --MGA73 (talk) 12:00, 12 March 2025 (UTC)[reply]
@ The Squirrel Conspiracy Hello, I have now also added #List of wikis with GFDL date issues where you can see more about the users that have uploaded files licensed GFDL. The biggest uploaders no longer use GFDL. In most cases GFDL is only used when reuploading old files and in some cases by a mistake.
As I wrote above I would really appriciate it if you could tell me what more should be done before you would support the proposal. --MGA73 (talk) 12:11, 20 March 2025 (UTC)[reply]
 Weak oppose I agree with The Squirrel Conspiracy that our sister projects have made a decision and some have decided by inaction to do nothing. I would support increasing outreach (if that would be effective) to get these existing files dual licensed but the community had decided after many years to finally stop accepting GFDL-only uploads and I would rather not backslide on that. Abzeronow (talk) 00:20, 5 March 2025 (UTC)[reply]
Sadly many of the files are uploaded by users no longer active (some are dead). So it is not possible to get all files relicensed. --MGA73 (talk) 06:57, 5 March 2025 (UTC)[reply]
I'd be open to finding a way for GFDL-only files by deceased users that have this date issue to be uploaded to Commons, but if there isn't a way for a very limited exception to current policy, I can live with these files just not being on Commons. Abzeronow (talk) 23:26, 6 March 2025 (UTC)[reply]
I would hate to see a very complicated rule and for us to ask for proof that a wikimedian is actually dead. Personally I think that allowing 2k files to be moved is a limited exception compared to the 115m files hosted on Commons :-) Also many wikis did not discuss it for example because 1) they had no idea Commos was going to ban GFDL, 2) they had no clue why or what it would mean, or 3) someone never bothered to start a discussion because the wanted to focus on something else. For example I have just spend a year trying to get Wikinewses to update the license from 2.5 to 4.0. It have taken a lot of time and some angry comments. I was even blocked at one wiki. And if you look at the proposals here on this page many of them get very few comments so it is not a surprise if many users do not think it is worth the efford to suggest something. --MGA73 (talk) 09:05, 7 March 2025 (UTC)[reply]
@ Abzeronow Hello, I have added two lists: 1) #List of wikis with files and GFDL-only in MediaWiki:Licenses (change GFDL cut-off date) a list of wikis that still have GFDL in MediaWiki:Licenses and 2) #List of wikis with GFDL date issues a list of the users that have uploaded files licensed GFDL (5 or more files). I think the two list show us that the number of new files licensed GFDL have more or less stopped. I can't take credit for it all but in 2021 and 2024 I wrote to many wikis. Others have done the same. To me it seems that in most cases GFDL is only used when reuploading old files and in some cases by a mistake. I see no indication that any user is trying to get passed the ban on Commons by uploading to other wikis.
I would really appriciate it if you suggest any actions I could do before you would support the proposal. If possible :-) --MGA73 (talk) 12:33, 20 March 2025 (UTC)[reply]
 Oppose. Reasons are given why the previous extension was turned down, but I do not see reasons why the new extension should be made. Yes, there are thousands of files that are GFDL-only files on other wikis, but Commons does not want that license used here. Commons does not allow other licenses such as -NC or -ND. This request is really about revisiting and overturning a previous decision. We did not want those files before, and I do not see an argument about why we would want them now. For an example issue, users are being hurt by failing to follow the minimal requirements of CC-BY 2.0 licenses. I do not see why we should allow more onerous license requirements that are less likely to be followed. Glrx (talk) 01:29, 5 March 2025 (UTC)[reply]
I do not think you can compare with NC or ND because those licenses were never allowed and they are not allowed on other wikis either. GFDL was the main license for many years and Commons have millions of files with the license GFDL. If a file was uploaded to a wiki in September 2018 it can be moved to Commons but if it was uploaded to a wiki in November 2018 it can't be moved. So its not like Commons do not want GFDL-files to be here it that we do not want new files to be licensed GFDL. All free files belong on Commons and the existing cut-off date makes it impossible. When the proposal to ban GFDL-only on Commons was made similar proposals should have been made on all wikis to make sure all wikis knew about it and implemented a similar ban. Sadly that did not happen so now some free files can't be moved to Commons. --MGA73 (talk) 06:57, 5 March 2025 (UTC)[reply]
Some people want NC or ND files on Commons because they are free to use in some circumstances. The community chooses not to accept those licenses, and the community can choose to start or stop using other licenses. Your statement, "All free files belong on Commons and the existing cut-off date makes it impossible," indicates that your actual position is Commons should always allow GFDL-only licenses — not just those grandfathered by the 2018 cutoff date or your proposed 2024 date. In a few years there will be more GFDL-only contributions, and a like-minded person would want to reset the date again. I'm OK with the 2018 cutoff date excluding thousands of free files because Commons no longer likes the license. I'm also OK with Commons sunsetting CC-BY 2.0 and CC-BY 3.0 licensed contributions because those licenses have issues that cannot easily be fixed. Glrx (talk) 18:57, 5 March 2025 (UTC)[reply]
NC and ND is not allowed per wmf:Resolution:Licensing_policy so it does not matter if someone want them or not. It is simply not possible for Commons to allow NC or ND. I do not know where you get the idea that I think that Commons should allow GFDL-only licens. I have been spending hundreds of hours trying to get wikis to stop allowing GFDL-only. If you check this you can see that it was my suggestion to ban GFDL from being uploaded to English Wikipedia. I also spend hundreds of hours trying to persuade users to relicense their uploads. Actually I do not think you can find anyone who spend more time on wikis trying to eliminate GFDL than me. As I wrote it should be a one-time change now that most wikis have stopped using GFDL-only. As an example of a wiki that did not want to remove GFDL I can mention cs.wikipedia. They only have one file uploaded: The Wikipedia logo and it was uploaded in 2016. They simply think its not relevant to change anything per this. Should we let wikis like that be the reason that we do not want to move files to Commons because they could in theory upload a new file tomorrow? I know I wrote that all free files belong on Commons and I might want to modify that a bit to all usable free files should be on Commons. There are junk out there that should just be deleted. As you can see above the files that are relevant in this proposal are almost all uploaded to Wikipedias and the main part of the good files are from English Wikipedia. When I made the first suggestion in 2021 it was mainly to make it possible to move the files from English Wikipedia to Commons but as I wrote above someone prefered that it should include all Wikis. Sadly it is not possible because some wikis don't really care about it because either they do not see a problem with GFDL or they have no users uploading files there and do not want to waste time on what to them is a non-existing problem. --MGA73 (talk) 20:07, 5 March 2025 (UTC)[reply]
@Jmabel: (I moved your comment to the discussion section - hope you do not mind). The comment have been "hidden" in my user space so I do not think anyone noticed your comment. Except me. I have read it and I do not think it is easy to understand because I have to use a translator. But as I understand it the meaning of the text is that GFDL is a free license but it should only be used for documents (similar to what apply on Commons). As for the rest of the wikis that mention GFDL and have files uploaded I checked in m:User:MGA73/GFDL_files/Licenses#Wikis_with_GFDL_or_variants_and_files if it is GFDL-only or dual license and on many of the wikis I suggested that they remove GFDL-only. I have not added my suggestion on that page. But it would be great if someone who speak the language would check too and help remove GFDL. --MGA73 (talk) 20:54, 7 March 2025 (UTC)[reply]
  •  Support Although I'm on the weak side since changing the licenses for files that are obtained from other sites seems questionable. Someone could argue it's a form of licensing laundering. That said, I doubt it's that big of a deal. So whatever. Hopefully there's at least efforts to depreciate the license on other wikis. Otherwise it's just kicking the can down the road per another comment. --Adamant1 (talk) 01:38, 11 March 2025 (UTC)[reply]
Thank you! The only change of license is the license migration of files uploaded before August 2009 and if someone upload a random internet file and claim it to be licensed GFDL. Hopefully someone will notice if internet files are licensed incorrectly so they are not moved to Commons. I have checked 868 wikis and 388 of those have no files so no work is needed for those wikis. Closing for local uploads have without doubt prevented many problems and many files licensed GFDL (thanks to User:Nemo_bis and other that helped close for local upload of files on smaller wikis). A number of other wikis have files but does not allow new uploads or uploads are only allowed for admins. I and many others have since 2009 worked to get GFDL removed and now 347 wikis have files but not mention GFDL as an option during upload (MediaWiki:Licenses). 133 wikis (with files) mention GFDL during upload but most only as dual-license. So only 50 wikis mention GFDL-only as an option per the table above. But as you can see some of those have no actual uploads and others write "not recommended" or mention that it is only for documents. I am trying to get GFDL removed from the last few wikis that still have uploads. Another good news is that even if some wikis mention GFDL in 2025 then almost none of them had any actual uploads of GFDL-only since 2018. If anyone speak the language of the wikis above they are very welcome to help depreciate GFDL. --MGA73 (talk) 07:54, 11 March 2025 (UTC)[reply]
"depreciate" => "deprecate". Two similar-looking words with entirely different meanings. - Jmabel ! talk 16:44, 11 March 2025 (UTC)[reply]
 Comment I'm not sure how feasible it is, but could we have a different date per wiki if it's a transfer? Keep the current date for any direct uploads to Commons, but use the date each wiki banned GFDL-only for transfers from that wiki -- and if they have not, keep the current Commons date until they do? I think we still accept files that are naturally GFDL-only from other non-Wikimedia sites, but that should be very rare (outside of documentation). Carl Lindberg (talk) 12:58, 24 March 2025 (UTC)[reply]
If we make such a rule it will not be easy to find any files that violate the ban. But since there are almost no new uploads of GFDL-only I doubt it will be a big problem. It may ofcourse be hard to explain to users that they can only move some files and not other files. I have one question: Should a ban be written in a license policy like Commons:Licensing#GNU_Free_Documentation_License or en:Wikipedia:Image_use_policy#GNU_Free_Documentation_License or is it enough that the license have been removed from MediaWiki:Licenses? Latest status: The estimated number of files is 2,000 and almost 500 of those are from English Wikipedia where there is a ban. Around 600 files are from Hungarian Wikipedia and 400 from Azerbaijani Wikipedia but many are probably incorrectly licensed so the actual number of files to move to Commons is likely lower. The remaining 500 are from a number of wikis. --MGA73 (talk) 16:04, 24 March 2025 (UTC)[reply]

Change colour of

[edit]

the arrows in Turn 0.svg Turn 180.svg Turn 270.svg Turn 90.svg to something that works well on both white background and black background.

I dont know what's good. 0099FF might be a bright blue that might work? RoyZuo (talk) 19:46, 6 March 2025 (UTC)[reply]

I recommend you upload your own versions under new names. The Squirrel Conspiracy (talk) 04:02, 8 March 2025 (UTC)[reply]
Template:Rotate#Example. RoyZuo (talk) 08:57, 1 April 2025 (UTC)[reply]

Phase out some categories for black and white photographs in favor of SDC data

[edit]

A lot of the categories for black and white photographs are super pedantic and get in the way of people organizing images by date, subject, location or another criteria. They are also super pointless in a lot of instances because all photographs by a particular photographer or of a specific location and/or date are black and white to begin with. People also don't seem to know what a black and white image is. Like to give Category:Black and white postcards of Piran and it's parent category Category:Historical black and white photographs of Piran as examples, most or all of the photographs in them are in fact sepia. Either that or blue tinted. Neither of those are "black and white" though and it seems to be a pretty regularly occurring issue.

So my proposal is to up-merge a good portion of the more pedantic categories for black and white photographs where it clearly doesn't serve a meaningful purpose and use SDC data for what type of photograph it is instead. There's currently color (Q1075) and black-and-white (Q838368). As well as sepia (Q767608). All three of them can be used for labeling photographs as black and white or sepia. I don't think using categories is a good way to do it in most cases though.

But just to be clear, I'm not advocating for the whole sale emptying of categories containing black and white photographs. I'm proposing the slow transfer of the information about what type of photograph it is to SDC data in conjunction with phasing out the more pedantic, less useful categories once that happens. Although I'm not going to propose specific categories to get rid of right now because I'd like to at least establish a baseline level of acceptance for the general idea first. People can, and should, figure out what categories to phase out if or when this is approved though. Adamant1 (talk) 03:41, 8 March 2025 (UTC)[reply]

I mostly agree with the principle here, with one exception: I think it is no problem at all that "black and white photograph" is used as a synonym for "monochrome photography" and includes sepia prints, as long as we are consistent about that. Categories like this are already wildly overly split, and I'd hate to have a new set of "sepia this" and "sepia that" to sort through when I'm actually interested in the subject matter, not the medium.
My own inclination is that "black and white photographs" should just be a "tag" or a flat category, completely orthogonal to subject matter, but that fight seems long since lost. - Jmabel ! talk 04:44, 8 March 2025 (UTC)[reply]
I certainly agree with upmerging as much as possible. In the vast majority of cases, it's not useful to subdivide categories in that way. (This seems like one of these cases where SDC could be really useful - being able to filter any category or search results by basic parameters like B&W/color, image size, and license.) Pi.1415926535 (talk) 06:07, 8 March 2025 (UTC)[reply]
I support the overall direction here. Being able to search (thanks to SD) for "only B&W pictures of <subject>" would be more helpful than browsing overcrowded categories. More tags could indicate "sepia", "photograph", "line art" (is also B&W), "greyscale", "blueprint". "Category:Black and white portrait photographs of standing women at bust length" are not helpful, because it mixes too many and partly contradictory statements: "B&W", "portrait at bust length" and "standing woman". We probably have 10x as many images that also fit those criteria, but they are not yet categorized that way: For that reason, I suggest to keep the categories for now, and first populate the SD. --Enyavar (talk) 17:06, 1 April 2025 (UTC)[reply]
 Oppose For SD there is no category page. It also can't be used with petscan. @TheImaCow, you don't need to navigate +34,000 photos, you could use either
  • its subcategories or
  • the deepcategory (or incategory) search parameter along with a search term or petscan
to find what you're looking for. Prototyperspective (talk) 00:35, 14 March 2025 (UTC)[reply]
Hmm… "super pedantic"?, seriously? -- Tuválkin ✉ ✇ 00:44, 14 March 2025 (UTC)[reply]

 Support the idea, I have no comments about the concrete implementation. Category:Black and white photographs contains +34,000 photos, which is useless for navigation, and it does not make sense to mirror our complete category tree to include "Black and white photographs of <existing category>". Note that there are also countless black&white photographs, which do not have that fact reflected by existing categorisation, so it might be possible to automatically find and tag such untagged b&w images ~TheImaCow (talk) 02:11, 11 March 2025 (UTC)[reply]

Many of those 34K images were categorized as black & white using a gadget like "Cat-a-lot". Maybe restricting those from dishing out pointless categories would be a better option. Alexpl (talk) 18:37, 13 March 2025 (UTC)[reply]
Are you seriously suggesting that editorial workflows you personally dislike should be made impractical by crippling existing tools? Could people who dislike SDC suggest the same?, (without being imeediately blocked?) -- Tuválkin ✉ ✇ 00:42, 14 March 2025 (UTC)[reply]

Set a default language for SDC data

[edit]

Whenever you try to add an Monolingual text statement to an image you have to scroll past 200+ languages just to get to English which is an awful, awful UI experience that only discourages people from adding monolingual text statements.--Trade (talk) 14:40, 15 March 2025 (UTC)[reply]

@Trade: I always get English offered right at the top. I wonder if there is a preference thing involved. Do you just get a simple linear list (I don't. I get some common languages at the top, then a breakdown by regions). FWIW I user Firefox on a PC. - Jmabel ! talk 16:48, 15 March 2025 (UTC)[reply]
My issue is with the breakdown by region. I dont feel that method is very user friendly Trade (talk) 17:47, 15 March 2025 (UTC)[reply]
You need to place babel boxes with the languages you speak on your user page to have these languages on the top. GPSLeo (talk) 16:56, 15 March 2025 (UTC)[reply]
It's not about being on top. I just dont want 200+ languages that i wil never use on Commons cluttering up the page for no reason
Doesnt matter anyways. My PC decided to logout while i was away from it so all my work in SDC is lost now since the browser closed Trade (talk) 17:20, 15 March 2025 (UTC)[reply]
I do have to wonder if having languages like "German" hidden at the very middle of the list while the top is filled with constructed languages that nobody on Commons even uses when editing. Like why? --Trade (talk) 17:40, 15 March 2025 (UTC)[reply]
As for last, having to find languages by their native spelling is extremely jarring. Like, every single category on Commons related to the German language uses the english spelling. And yet this specific part of Commons uses "Deutsch" which is nothing like how it's called on the rest of Commons. Idk it just makes me not wanna ever touch SDC when it's so jarring to the design and norms of the rest of Commons. Like, it cant decide whether it wants to be a part of Commons or it's own thing which just happens to be transcluded on media files.--Trade (talk) 17:52, 15 March 2025 (UTC)[reply]
The search for a language to add works with all languages for me. I can type in french, francais or französisch and always get the same result. GPSLeo (talk) 07:42, 18 March 2025 (UTC)[reply]

Flagging and filtering of structured content edits

[edit]

Hi - my name's Sam and I'm the Product Manager for the Moderator Tools team. We're currently scoping some work based on the Task prioritization Community Wishlist focus area. There are two wishes in this focus area regarding identifying and filtering Structured Data content on Commons. The idea would be to flag edits which are structured data changes in venues like Special:RecentChanges and Special:Watchlist, so that you could filter for only these edits, or filter them out of those views. I wanted to get a wider pool of opinions on the value of making this change - would you find such a filter useful for any of your workflows? Is there anything we should be aware of if we were to implement these suggestions? Thanks in advance, Samwalton9 (WMF) (talk) 18:37, 17 March 2025 (UTC)[reply]

Please add the ablity to toggle bot and human edits separately (mainly due to multichillbot and schlurcherbot). All the Best -- Chuck Talk 20:58, 17 March 2025 (UTC)[reply]
Agree. I'd want to filter out bot edits to SDC, but not human edits to SDC.
It would be even better if I could specify exactly what users (bot or otherwise) were filtered. E.g. I'd really like to be able to filter out Emijrpbot but not DPLA bot. - Jmabel ! talk 01:00, 18 March 2025 (UTC)[reply]
Thanks for sharing - this makes sense. I think if this was, theoretically, added as a filter in RecentChanges, you would be able to filter both on this and bot/non-bot edits. I'll make sure I keep this in mind if we moved forward with this. Samwalton9 (WMF) (talk) 09:29, 18 March 2025 (UTC)[reply]
Filtering by specific human user might also be useful. For example, there was recently a decision to rename the category tree regarding humans and gender (i.e. "Female humans" > "Female people"). As a result large numbers of categories and files were moved by a particular human user. It so happened that I had some affected categories on my watchlist and consequently my warchlist was flooded with those moves. There's also a limit to how many new edits the watchlist can display — 255 I think? —, so that I was unable to see any edits on my watchlist other than the ones related to the mass moves. Nakonana (talk) 17:18, 18 March 2025 (UTC)[reply]
Yes please. There was also recent question about hiding SDC bot edits where my answer was that they can hided by adding CSS rule to hide rows with BotSDC-tag (see Commons_talk:Structured_data#Hide_SD_edits ). So request would be to be able to hide automated bot SDC edits (and if possible select which bots would be hided, mut even if filter would be for all bot SDC edits it would be great) --Zache (talk) 01:09, 18 March 2025 (UTC)[reply]
The tagged edits can already be hidden like every other tag in the regular watchlist settings. I think we should have three main tags for every edit "Wikitext edit", "SDC edit" and "Caption edit". The watchlist and recent changes should then allow free configuration on what to show based on the user type (bot, user, anon, (auto)patrolled) for every tag separately. GPSLeo (talk) 07:35, 18 March 2025 (UTC)[reply]
How do you get specific tags hidden in the standard watchlist? Keith D (talk) 20:04, 18 March 2025 (UTC)[reply]
There is a Tags button to the right of the Filter changes bar. It opens a menu to select tags and there is the option to exclude the selected tags.  REAL 💬 ⬆   20:11, 18 March 2025 (UTC)[reply]
I do not get a Filter changes bar. Keith D (talk) 21:43, 18 March 2025 (UTC)[reply]
I use Vector legacy (2010) theme. I don't know if that changes anything. Here is what I see File:Tags filter in Wikimedia Commons watchlist 18 March 2025.png  REAL 💬 ⬆   22:03, 18 March 2025 (UTC)[reply]
I use Monobook skin which does not appear to have these options. Keith D (talk) 22:37, 18 March 2025 (UTC)[reply]
I also use Monobook. Are you telling me that you don't see any options to filter at Special:Watchlist? —Justin (koavf)❤T☮C☺M☯ 22:54, 18 March 2025 (UTC)[reply]
Yes. Here is what I see. Keith D (talk) 23:28, 18 March 2025 (UTC)[reply]
I see a "Show" button there. Maybe it opens the filter menu  REAL 💬 ⬆   23:34, 18 March 2025 (UTC)[reply]
The Show button just runs the selected query to give you the watchlist lines. Keith D (talk) 23:38, 18 March 2025 (UTC)[reply]
@Keith D The tags menu shows up when you click the search bar in monobook. All the Best -- Chuck Talk 00:08, 19 March 2025 (UTC)[reply]
Have not got a search bar, only search in left hand pane which takes you to Special:Search page, see screen shot Keith D (talk) 02:09, 19 March 2025 (UTC)[reply]
@Keith D It's likely that you have the "Use non-JavaScript interface" preference selected in the 'Recent changes' tab in Preferences. Samwalton9 (WMF) (talk) 14:29, 19 March 2025 (UTC)[reply]
The "Use non-JavaScript interface" preference is not selected in the 'Recent changes' tab but is in the 'Watchlist' tab. Keith D (talk) 17:42, 19 March 2025 (UTC)[reply]
Yes that works, but much prefer the existing one for general use. Which is the one this task was raised for rather than have to use tags, filters etc. Keith D (talk) 17:56, 19 March 2025 (UTC)[reply]

Add "publication titles" as an exception to "Category names"

[edit]

I think, it has been at least a convention that categories of publications (including but not limited to books, magazines, pamphlets...) are given titles in their original names in the original writing scripts. But this is not explicitly mentioned in Commons:Categories#Category names, so it should be added.

Older discussion: Commons:Village pump/Proposals/Archive/2019/08#Category titles with scripts other than Latin. RoyZuo (talk) 10:40, 30 March 2025 (UTC)[reply]

It looks like at least subcats of Category:Magazines of China by name and Category:Magazines of Russia by name use Latin script and are mostly in English. So is that actually true? --Adamant1 (talk) 21:21, 30 March 2025 (UTC)[reply]

Move File:Flag of the Syrian revolution.svg to Flag of Syria.svg

[edit]

al-Sharaa had just made this flag the permanent one. SpinnerLaserzthe2nd (talk) 17:26, 31 March 2025 (UTC)[reply]

Consensus for "de minimis items should not be represented by depicts"

[edit]

I wrote this in Special:Diff/1014791147/1014791524, but do we have consensus for it? I think so, but I could be wrong.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:06, 31 March 2025 (UTC)[reply]

In fact, a "depict" statement is diametrically opposed to COM:De minimis. If someone is plausibly claiming a depiction of something in a photograph, then this something cannot be De minimis, as the latter is based on a total insignificance of the something for the image. So, you either have a depiction of an object or an incidental, minimalistic inclusion of it, but not both at the same time. Regards, Grand-Duc (talk) 22:44, 31 March 2025 (UTC)[reply]
@Grand-Duc: Thanks. May I take that a "support" !vote?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:56, 31 March 2025 (UTC)[reply]
So many items have no depicts at all. Isn't some info better than none? Jerimee (talk) 23:08, 31 March 2025 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=1016050817"