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/03.

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]

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]
Hi, I emailed oversight-commons@lists.wikimedia.org on April 7th, and I didn't get any answer. Yann (talk) 18:56, 15 April 2025 (UTC)[reply]
@Yann At least I did not got an email from you on April 7th. Only your mail from today. Raymond (talk) 19:31, 15 April 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]
 Support - --Ooligan (talk) 15:37, 1 May 2025 (UTC)[reply]
 Support MGeog2022 (talk) 11:41, 18 April 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]

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,002 6
Wikinews 40 0
Wikiquote 5 0
Wikisource 180 0
Wikiversity 30,633 0
Wikivoyage 133 0
Wikipedia 117,207 1,946
Wiktionary 103 0
Special wikis 635 0
Grand total 151,938 1,952

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
s:ar:MediaWiki:Licenses GFDL 4,041 0 0 s:ar:Special:FileList GFDL-only 2021 N/A
w:bar:MediaWiki:Licenses GFDL 1,152 318 0 w:bar:Special:FileList GFDL-only (not recommended) (latest GFDL-only file a bit unclear because of dual license). 2023 2017
b:de:MediaWiki:Licenses GFDL 3,539 669 0 b:de:Special:FileList GFDL-only (not recommended) 2024 2018
v:de:MediaWiki:Licenses GFDL 2,904 43 0 v:de:Special:FileList GFDL-only 2024 2009
b:he:MediaWiki:Licenses שימוש חופשי עם קרדיט 1,708 87 2 b:he:Special:FileList GFDL-only (not recommended) 2024 2021
w:ko:MediaWiki:Licenses GFDL 14,539 1,366 0 w:ko:Special:FileList GFDL-only (only if not possible to upload to Commons) 2025 2014
b:nl:MediaWiki:Licenses GFDL 20 12 0 b:nl:Special:FileList GFDL-only 2023 2006
s:pl:MediaWiki:Licenses GFDL 129 41 0 s:pl:Special:FileList GFDL-only 2024 N/A
w:ro:MediaWiki:Licenses GFDL 117,792 515 0 w:ro:Special:FileList GFDL-only (only meant for documents - Appears to be "good", see note below) 2025 2017
w:ta:MediaWiki:Licenses GFDL 9,005 528 0 w:ta:Special:FileList GFDL-only 2025 2015
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

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 575 17 ar:User:MGA73/GFDL (Latest GFDL upload 2020):
w:az: w:az:Category:Fayl:GFDL 14,854 1,252 375 az:User:MGA73/GFDL (Latest GFDL upload March 2023):
w:bs: w:bs:Category:GFDL slike
w:bs:Category:Screenshot Wikipedije		 5,520 155 5 bs:User:MGA73/GFDL (Latest GFDL upload 2020):
w:de: w:de:Category:Datei:GFDL 129,648 15,623 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,629 503 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,141 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,588 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):
  • Crossed out because 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		 26,444 1,711 81 lt:User:MGA73/GFDL (Latest GFDL upload May 2023):
w:mk: w:mk:Category:ГЛСД-слики
w:mk:Category:ГЛСД-слики-with-disclaimers		 9,392 473 11 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)

Crossed out because they need a permission.

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,620 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 213 5 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,850 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 82,943 1,957
1,930		 List is updated April 27 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]

List of GFDL date issues per year

[edit]

Update 4: Based on earlier lists I made a list of the files sorted per year. It shows that the GFDL files are mostly uploaded in 2019.

Year 2018 2019 2020 2021 2022 2023 2024 2025 Total
Files with date issues 122 1,212 329 261 18 9 2 2 1,955

I have excluded files from mk.wiki because they need a permission via COM:VRTS and files from lij.wiki because they have a wrong license. It is not possible to get an exact number without checking all files manually. Sometimes there is no good source and author so it is unclear if the license is valid. --MGA73 (talk) 17:29, 9 April 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]

 Question Hello User:Omphalographer, User:The Squirrel Conspiracy, User:Abzeronow, User:Glrx and User:Clindberg, can you help me out a bit here please? We all agree that it is not good if new files licensed GFDL keep showing up. But it would be a big help if you could comment on a few questions:

  1. Should a ban be written explicit like on Commons:Licensing#GNU_Free_Documentation_License or is it enough that the license have been removed from MediaWiki:Licenses (the page that generates the dropdown with licenses users can chose during upload)?
  2. Should it be on ALL ~860+ wikis or is it okay if wikis where uploads are impossible or where no uploads have been made for years are excluded for example?
  3. Are there any wikis you would think is okay to include or any wikis you would like to exclude?

I have tried to add and update lists above that I thought you might find relevant. Please let me know if you need any other info. --MGA73 (talk) 06:08, 7 April 2025 (UTC)[reply]

I admire the effort you have put into this issue, but the question for Commons is much simpler. Commons is a separate project, and the decision has been to not accept post-2018 GFDL licenses. What other projects accept is up to those projects; Commons does not control them, and they do not control Commons. Commons no longer accepts post-2018 GFDL-only content. What is in a dropdown box, years since last upload, or which wiki are irrelevant. Glrx (talk) 03:24, 8 April 2025 (UTC)[reply]
Thank you. I agree that Commons decide what to do and sometimes we change our mind :-) The purpose of Commons is to host free files and an important part of that is to host files for all WMF-wikis. The reason I raised the question about a ban on other projects is that someone suggested that our choice should depend on what other wikis do. --MGA73 (talk) 05:07, 8 April 2025 (UTC)[reply]
To those that worry that new files will be uploaded if we change the date I made a list in #List of GFDL date issues per year and it shows that very few files have been uploaded since 2021. --MGA73 (talk) 17:32, 9 April 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]
Instead of changing colours, I came up with these svg, with a clearer subject (🌹) than the sunset image (which is kinda symmetrical).
Extended content
90 degrees
<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <style> text { font: bold 32px sans-serif; dominant-baseline: middle; text-anchor: middle; } marker#arrowhead { fill: yellow; stroke: blue; stroke-width: 1; } </style> <defs> <marker id="arrowhead" markerWidth="4" markerHeight="4" refX="4" refY="2" orient="auto"> <polygon points="0 0, 4 2, 0 4" /> </marker> </defs> <text x="50" y="50">🌹</text> <text x="150" y="50" transform="rotate(90, 150, 50)">🌹</text> <text x="100" y="100" fill="white" stroke="black" stroke-width="2px">90°</text> <line x1="70" y1="50" x2="129" y2="50" stroke="blue" stroke-width="5" marker-end="url(#arrowhead)" /> </svg>
180 degrees
<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <style> text { font: bold 32px sans-serif; dominant-baseline: middle; text-anchor: middle; } marker#arrowhead { fill: yellow; stroke: blue; stroke-width: 1; } </style> <defs> <marker id="arrowhead" markerWidth="4" markerHeight="4" refX="4" refY="2" orient="auto"> <polygon points="0 0, 4 2, 0 4" /> </marker> </defs> <text x="50" y="50">🌹</text> <text x="100" y="100" fill="white" stroke="black" stroke-width="2px">180°</text> <text x="150" y="150" transform="rotate(180, 150, 150)">🌹</text> <line x1="70" y1="50" x2="152" y2="50" stroke="blue" stroke-width="5"/> <line x1="150" y1="50" x2="150" y2="129" stroke="blue" stroke-width="5" marker-end="url(#arrowhead)" /> </svg>
270 degrees
<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <style> text { font: bold 32px sans-serif; dominant-baseline: middle; text-anchor: middle; } marker#arrowhead { fill: yellow; stroke: blue; stroke-width: 1; } </style> <defs> <marker id="arrowhead" markerWidth="4" markerHeight="4" refX="4" refY="2" orient="auto"> <polygon points="0 0, 4 2, 0 4" /> </marker> </defs> <text x="50" y="50">🌹</text> <text x="50" y="150" transform="rotate(270, 50, 150)">🌹</text> <text x="100" y="100" fill="white" stroke="black" stroke-width="2px">270°</text> <line x1="50" y1="70" x2="50" y2="129" stroke="blue" stroke-width="5" marker-end="url(#arrowhead)" /> </svg>

RoyZuo (talk) 17:04, 25 April 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]

I think the redirect from File:Flag of Syria.svg works better than a move, though we might now want to rename File:Flag of the Syrian revolution.svg as File:Flag of Syria (2025-) (or something similar) and have both File:Flag of Syria.svg and File:Flag of the Syrian revolution.svg redirect to that. FWIW, I would advocate an equivalent approach for any country: it is best that File:Flag of FOO be a redirect, so that everywhere that it simply refers to a geographic area and not a regime, a sister project can always know that if that country's flag changes, the image will be updated accordingly. Meanwhile, if you are referring to a regime, even the present one, or to the flag itself you can make sure that the image will not change in the future by using the more specific name. - Jmabel ! talk 22:50, 1 April 2025 (UTC)[reply]
@Jmabel: for reasons of grammar, "File:Flag of the Syria (2025-)" should read "File:Flag of Syria (2025-)".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:11, 2 April 2025 (UTC)[reply]
Typo, now fixed. Thanks, @Jeff G.. - Jmabel ! talk 19:19, 2 April 2025 (UTC)[reply]
I would be fine with Jmabel's proposed move. I'd wait a few more days to see if there is any more feedback on it (for or against) before I'd pull the trigger on the move. Abzeronow (talk) 19:39, 2 April 2025 (UTC)[reply]
I've moved the file to File:Flag of Syria (2025-).svg per discussion. Abzeronow (talk) 20:57, 4 April 2025 (UTC)[reply]
Panam2014 (talk) 01:29, 6 April 2025 (UTC)[reply]
File has been moved. Abzeronow (talk) 01:46, 6 April 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]

per recent discussion on my talk page, we currently have two project pages that contradict one another on this. Jerimee pointed me to Commons:Structured data/Modeling/Depiction which flat-out contradicts Commons:Depicts#What items not to add. I, for one, am firmly on the side of the latter, but I think the exchange on my page may be quite worth reading. - Jmabel ! talk 22:54, 1 April 2025 (UTC)[reply]

I skim-read the first link of yours and the talkpage exchange. @Jmabel, could you please clarify the "flat-out" contradiction you saw? I do not see much difference between Commons:Depicts#What items not to add and the section Commons:Structured data/Modeling/Depiction#Suggested best practices. The sentence there reading "The primary purpose of depicts (P180) statements on Commons is to identify, in a structured way, the items clearly visible in a media file." feels quite clear to me. Regards, Grand-Duc (talk) 00:55, 2 April 2025 (UTC)[reply]
Mostly the "parts of a bigger item" thing in Commons:Depicts#What items not to add. But I guess you are largely right, with only one example the guidance in Commons:Depicts is so vague it could be compatible with tagging every picture of a male adult human with man (Q8441) as well, and for that matter with putting room (Q180516) on every image that has nave (Q188714), restaurant kitchen (Q121039140), or bathroom (Q190771). Do we really want that? The one given example doesn't really explain why it stops at black hole (Q589), either. By the same logic, what about astronomical object (Q6999), or even Geraldine Somerville (Q235572)? I increasingly feel like we have no useful guidance at all. - Jmabel ! talk 19:33, 2 April 2025 (UTC)[reply]
Do we really want that? In short, yes. Somerville isn't visible though, so not Somerville. Jerimee (talk) 19:40, 2 April 2025 (UTC)[reply]
"mark as prominent"
anything not the main subject, dont mark. anything else, mark. RoyZuo (talk) 13:17, 2 April 2025 (UTC)[reply]
The guides "Suggested best practices" and "Depicts" don't say anything about limits. That is true. But I don't think we should infer from these guides, that every detail in pictures needs to be tagged (see my examples above). In the millions of images that prominently depict specific streets/buildings, the road asphalt that regularly takes 25-50% of the images does not need to be tagged, regardless of its "prominence" in a picture. It can be tagged, of course, but I think our guides should be edited to discourage users from systematically tagging incidental generic items (road asphalt, trees, cars, humans) in images that are focused on other topics. Right now, when I search for "road asphalt"; I'm getting the results I want: mostly close-ups and asphalt-laying. If a user begins to systematically tag 80'000-8'000'000 images that incidentally depict roads and plazas, I'm less sure that the search will continue to be helpful.
On another note, refraining from tagging SD "out of fear"?? The worst that can happen is being reverted, is it not? While I think that tagging far-away background trees is counter-productive, those things are certainly done in good faith. Could SD be used for improper purposes, like pushing certain content for SEO? Probably, but this is not up to debate here. --Enyavar (talk) 16:30, 2 April 2025 (UTC)[reply]
anything not the main subject, dont mark [as prominent]. anything else, mark This is the answer. With regard to the appropriate specificity of P180 statements, these 10 words are sufficient most of the time. Simple and to the point. Jerimee (talk) 19:18, 2 April 2025 (UTC)[reply]
Thanks for this question Trade - this is also my major concern. And, as Jmabel pointed out above, the existing SDC documentation is somewhat ambiguous. Jerimee (talk) 18:51, 2 April 2025 (UTC)[reply]
 Support. depicts (P180) should be limited to subjects which are substantially present in, and relevant to, an image. It should not be used to tag every single perceptible entity in an image, and particularly not ones which are only barely visible, or whose presence is entirely incidental to the image. If we want to play "I Spy" and start tagging every object which is present at all within an image, that should be described with a different (new?) Wikidata property so as to not pollute results for P180. Omphalographer (talk) 18:46, 2 April 2025 (UTC)[reply]
As much as I don't want depicts (P180) to devolve into free tags, I think "what is relevant to an image" varies significantly from user to user. At the present moment, I think searches are more likely to suffer from insufficient results than they are from low relevance results. Jerimee (talk) 19:06, 2 April 2025 (UTC)[reply]
How exactly does this proposal stop people from tagging "what is relevant to an image"? They can still do that if this is approved, just not excessively and/or to an absurd degree. --Adamant1 (talk) 20:41, 2 April 2025 (UTC)[reply]
With regards to "relevant to an image" - what I'm trying to get at here is that some images, particularly photos of notable events or other dramatic occurrences, may incidentally contain entities which are entirely irrelevant to the action which is central to the image. For example, File:05 28 20 South Minneapolis (51177808789).jpg does not, in my opinion, meaningfully depict Chevrolet Tahoe (Q910928). Even though one such vehicle is clearly visible in the foreground, it's incidental to the photo in such a way that the photo isn't a usable depiction of it. Omphalographer (talk) 20:43, 2 April 2025 (UTC)[reply]
Um. I don't want to have check with Omphalographer each time I see a Tahoe to know if the Tahoe depicted is a meaningfully depicted Tahoe. An image can mean more than one thing. I appreciate the example. I wish I had a better reply. Jerimee (talk) 14:14, 3 April 2025 (UTC)[reply]
" depicts (P180) should be limited to subjects which are substantially present in" The fact that the "Prominence" tag exists means that objects that are not prominent are still meant to be tagged. Trade (talk) 04:31, 3 April 2025 (UTC)[reply]
"Mark as prominent" exists for all structured data properties. It's not unique to depicts (P180). Omphalographer (talk) 05:10, 3 April 2025 (UTC)[reply]
I would consider "Mark as prominent" for depicts to mean "This image could reasonably be used as a depiction of this subject."
Side note: at the time SDC was first being discussed, I had proposed a parallel "Mark as incidental." I still think that would have saved us a lot of grief, because if we'd done that at the outset, the obsessive inclusionists could do their thing, but we could have an easy mechanized way to keep this cruft out of searches. - Jmabel ! talk 18:01, 3 April 2025 (UTC)[reply]
When was SDC first discussed? Jerimee (talk) 19:08, 3 April 2025 (UTC)[reply]
Just a idea that popped into my head: can't we have two statements, one being the current depict, reserved for the main motifs of the imagery? Another could be a contains for everything that is clearly identifiable (for instance, in the bus image above, the vehicle ID and the magnolia would be OK, but "contains: cypress" not, as it's only a pyramidal tree that could be also another kind). Regards, Grand-Duc (talk) 19:36, 3 April 2025 (UTC)[reply]
Technically it should be no problem to enable the deprecated rank from Wikibase on Commons. It would only need some UI changes. GPSLeo (talk) 19:43, 3 April 2025 (UTC)[reply]
I was thinking the same thing: preferred rank and deprecated rank seems like "out of the box" functionality that fits the bill. Just change the names to prominent and incidental. Jerimee (talk) 21:05, 3 April 2025 (UTC)[reply]
Just because it makes sense to carry deprecated statements on Wikidata doesnt mean it does on Commons Trade (talk) 11:45, 5 April 2025 (UTC)[reply]

I'm kind of interested in what people think of the depicts statements in The Last Supper (Q128910). Is anyone seriously looking at The Last Supper because of the pieces of bread on the table or care at all about them? To me it's like adding "depicts=bridge" to the Mona Lisa because there's a tiny bridge in the background. Nobody is searching for or looking at the Mona Lisa because of the bridge. --Adamant1 (talk) 23:42, 3 April 2025 (UTC)[reply]

Two things, A) somebody has definitely written a monogram about the bridge in Mona Lisa, B) there is a bridge in Mona Lisa?! Jerimee (talk) 06:28, 4 April 2025 (UTC)[reply]
Is it really that hard to believe someone might be curious about what the food on the table is supposed to be? Trade (talk) 11:46, 5 April 2025 (UTC)[reply]
Regarding The Last Supper (Q128910), A) someone has definitely written a monogram about the bread in The Last Supper, B) I'm pretty sure I've heard entire sermons about the bread at the The Last Supper, and even from multiple denominations of worship. Useful statements can be made. Jerimee (talk) 06:40, 4 April 2025 (UTC)[reply]
Weirdly, the bread in at the Last Supper may be significant on at least two counts.
  1. The origin of Christian Communion would be that bread.
  2. There is a widespread theory that the Last Supper would have been a seder; if it was, the bread as depicted by Leonardo would be wrong, since it would have to have been matzoh.
That said, the relevant "depicts" is already present in the Wikidata item. Are we really saying we should repeat all of the depicts values in a Wikidata item for a painting when we show a reproduction of that painting? - Jmabel ! talk 18:45, 4 April 2025 (UTC)[reply]
I wondered that too - though if File:Supper depicts Q123 should Q123 depict bread? I guess I think the depict statements should like autosync or something? I don't know. (Thanks for Last Supper facts btw.) Jerimee (talk) 18:56, 4 April 2025 (UTC)[reply]

Some broader questions

[edit]

I am not sure how we can even determine whether de minimis content should be marked when we don't seem even to have consensus on what is the purpose of SDC "depicts".

When "depicts" was introduced, I asked some questions that were never answered. I'm not going to reiterate them all here, but here are some that I think are crucial if we are going to clarify policy:

  • What is the purpose of "depicts"? Is it for search by humans? Is it to train AI? Something else?
  • Are end users intended to be able to reasonably skim the "depicts" for a given file, or is it basically data written by human editors for the benefit of tools (presumably including search tools), and any value to end users is expected to be via those tools?
  • How does the goal of "depicts" (as against its technology) differ from the goal of categories?

A further remark: if we really do want "depicts" tags at various levels of specificity for the same object, then the human effort involved in tagging multiple items up the "instance-of" and "subclass-of" hierarchy seems to me to be wildly disproportionate to the effort involved in stating rules about what tagging of this sort we would want done and having a bot do the tagging. - Jmabel ! talk 19:51, 2 April 2025 (UTC)[reply]

When invented the idea for depicts statement was to work the same as categories as they where invented to replace categories. I think this should still be our long term plan and therefore we should use them as we are currently using categories. GPSLeo (talk) 20:08, 2 April 2025 (UTC)[reply]
"I think this should still be our long term plan and therefore we should use them as we are currently using categories" The problem is that it's extremely tedious to setup due to the amount of subcategories that Commons have developed over the years
Not to long ago i had to waste 20min simply to copy paste the various subcategories to AC/DC and even then i still had to wait longer for the tool to slowly load the images before i could even start it Trade (talk) 04:45, 3 April 2025 (UTC)[reply]
It's also very important to understand that Structured data on Commons does not function like the Commons category system, currently does not intend to, and it does not have the same clear hierarchy and division.
https://commons.wikimedia.org/wiki/Commons:Structured_data/Modeling/Depiction#Level_of_detail Jerimee (talk) 14:18, 3 April 2025 (UTC)[reply]
Jmabel asked three questions about SDC depicts. They are good questions. I thought I might hazard hesitant answers.
  1. To indicate what objects are present in a general literal sense. Depicts is a visual metaphor, and for image files the meaning is straightforward: what can plainly be seen in its typical form. As if one were to describe the contents to a person without sight in a formal setting (Heinlein's Fair Witness). Abstract concepts such as "admiration" and "order" are permitted, but to be used sparingly, typically with qualifiers, and only when exceptionally prominent. Objects that can be inferred but are not present should not be listed; an audio file of a car horn depicts horn, alarm, signal, but not vehicle. Trivial "I Spy" type depiction statements of objects clearly visible are not forbidden. Constraints on what is permitted for depicts (P180) should require consensus, documentation, and a waiting or transition period — so as not to disrupt or discourage SDC contributors and SDC tools. The goal is to advance human understanding via tools (library science).
  2. Both. But more via tools. Human readability is desirable. But this is a specialized system of notation; unfamiliar users will not be able to skim it.
  3. Structure is a form of accessibility and provides a myriad of benefits. Our category system is merely a form of hierarchical free tagging, right? depicts (P180) is part of SDC, and the goal of SDC is data retrieval, data aggregation, and data manipulation. If nothing else, SDC differs from categories in that the structure is defined in a formal manner. Those formal definitions help us better cooperate such that our contributions are more generally useful for everybody.
Notes: This reply could be improved with formatting; sorry about that. These answers are my opinion, and are meant to encourage others and are not meant to dispute. SDC is useless without consensus; I care more about guidelines being established than the particulars of the guidelines. I edited this reply.
--Jerimee (talk) 16:46, 3 April 2025 (UTC)[reply]
categories have one fundamental problem: it's unclear how that category is related to the image (let's simplify our discussion to just image here without considering all other types).
when i tag something Category:Musée du Louvre, it could mean, the image:
  1. is a photo of Musée du Louvre
  2. is taken inside Musée du Louvre
  3. is a view of somewhere else from Musée du Louvre
  4. is produced by Musée du Louvre
  5. is owned by Musée du Louvre
  6. is sourced from Musée du Louvre
  7. depicts an exhibition (anywhere in the world) of items in the collection of Musée du Louvre
...
my understanding is that sdc is to solve this problem, by specifying how exactly a wd item, or any value, is associated with the file.
now we set "statements", which is usually property Pxxx = item Qxxx (or a non-item value) for file Mxxx.
this makes the relation clearer, which has two uses:
  1. by becoming better machine readable, it enables easier data analysis (mining, big data, whatever)
  2. also because of that, weak AI or strong AI can understand and use the files more easily.
depicts, is the #1 relation listed above. RoyZuo (talk) 18:27, 5 April 2025 (UTC)[reply]
it's unclear how that category is related to the image That's not true in the sense or to the extent that you claim. Usually it's clear by how the category is named (or at least/sometimes by the chain of categories). For example, a file in Category:Moon from Earth is a file showing the Moon from the Earth (could technically be a photo or an artwork depending on the cats above but these can be subcateogized or filtered accordingly via the deepcategory in the search).
when i tag something Category:Musée du Louvre, it could mean, the image usually there are subcategories and if not, you can create them. Also this is partly an advantage, don't just look for downsides – this is actually useful if you were looking for files. Moreover, SD also aren't unambiguous – just maybe a bit lesser so if they were used as intended and actually used (especially the latter is not the case) – e.g. it can be a photo or drawing. Also there are many categories for which is there no SD item. But the take-away is: what you said can also be solved via subcategories. Moreover, machines may use this but humans can't really since there are nothing like category pages (which btw is a further reason the SD are so incomplete and full of false data) and categories are also machine-readable and queryable. Maybe SD have some unique applications and uses but then I think they'd better be set via machine vision making use of the categories to detect what is actually depicted, making them far more reliable, accurate, and complete. Even then I wouldn't see it as replacement of categories and just about making what is in the categories more selective for machines and scripts. Prototyperspective (talk) 18:41, 5 April 2025 (UTC)[reply]
If the files have the relevant SDC properties - a big "if" - many categories could be replaced with a saved search. For example Illustrations by John R. Neill could be defined/retrieved as either
instance of (P31) → illustration (Q178659)
AND
illustrator (P110) → John R. Neill (Q45111)
or perhaps
instance of (P31) → book illustration (Q998555) OR instance of (P31) → illustration (Q178659)
AND
illustrator (P110) → John R. Neill (Q45111) OR creator (P170) → John R. Neill (Q45111)
More (amateurish) examples at User:Jerimee/search_links, and doc at https://www.mediawiki.org/wiki/Help:Extension:WikibaseCirrusSearch Jerimee (talk) 20:44, 5 April 2025 (UTC)[reply]
Interesting but only addresses one part – and then it's not yet like category pages and only something that could be used for such if something was built. Prototyperspective (talk) 22:58, 5 April 2025 (UTC)[reply]
category is often a worse method for these purposes than sdc.
these two letters, one is written by someone and the other is addressed to that person. i am certainly not creating subcats to record this nuance. RoyZuo (talk) 16:38, 25 April 2025 (UTC)[reply]
what Roy said! Jerimee (talk) 18:12, 25 April 2025 (UTC)[reply]
excellent - what Roy said Jerimee (talk) 20:22, 5 April 2025 (UTC)[reply]

Extra clear instructions for attribution

[edit]

All too rarely are files from Commons attributed to their creator in accordance with their license. I've noted that instructions for attribution have been discussed multiple times before, and that "Use this file" provides an adequate text string for attribution.

For example, little Mr. Long-toes here gives us this:

Charles J Sharp, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia Commons

I think this text should be generated in an instantly visible place as well, for example:

Size of this preview: 800 × 533 pixels. [...]
Attribution: Charles J Sharp, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia Commons

Is this something that we, the community, would support?

Sinigh (talk) 11:54, 5 April 2025 (UTC)[reply]

 Support. RoyZuo (talk) 18:12, 5 April 2025 (UTC)[reply]
 Support. Jerimee (talk) 20:45, 5 April 2025 (UTC)[reply]
 Support per above and Commons:Village_pump#Copyleft_enforcement_-_concern_about_stretching_of_a_guideline etc. I think it is a good idea to make it more clear that reuse require better attribution. I think the template should provide a suggestion as default. --MGA73 (talk) 13:38, 7 April 2025 (UTC)[reply]
Support: per above. Also, CC licenses are being recognized by copyright authorities globally, such as in Russia where free licenses were recognized in 2014 (coinciding with liberalizing uses of architecture there). A few years before, according to Britannica, there was a ruling in 2008 by a Federal Appeals court in which free licenses "are enforceable under copyright law because they 'set conditions on the use of copyrighted work.' In the event that the conditions are violated, the license disappears, resulting in copyright infringement as opposed to the lesser violation of breach of contract." JWilz12345 (Talk|Contributions) 13:57, 7 April 2025 (UTC)[reply]
 Support It may not be enough, but at least it's a step in the right direction. --Cart (talk) 14:16, 7 April 2025 (UTC)[reply]
 Support --Adamant1 (talk) 15:09, 7 April 2025 (UTC)[reply]
 Support --Wilfredor (talk) 15:54, 7 April 2025 (UTC)[reply]
 Support I support this in principle but it only works if we entirely ban custom licenses and author templates they are not conform with Commons:Machine-readable data. On the exact wording: It also needs to include a link to the file page. GPSLeo (talk) 17:04, 7 April 2025 (UTC)[reply]
Has anyone done a formal review of what users put in custom license templates? If not, someone should. I suspect there are some common use cases - like requests to be attributed under a specific name, or contact information for commercial licensing - which can be addressed in a standard fashion, rather than having everyone do their own thing. Omphalographer (talk) 07:26, 8 April 2025 (UTC)[reply]
  • Am I seeing right that the only difference is the word "attribution" in red? That is not remotely sufficient. "Failure to provide this attribution can incur legal penalties to the reuser, including heavy fines" needs to be added. Ikan Kekek (talk) 18:18, 7 April 2025 (UTC)[reply]
    • "Fines" seems the wrong term. "Fines" are paid to a government, not to the plaintiff in a civil suit. - Jmabel ! talk
    • The other (and more important) difference would be to place this prominently on the file page, rather than have it be something you have to click to see. - Jmabel ! talk 20:10, 7 April 2025 (UTC)[reply]
      "Fees" then. --Cart (talk) 20:16, 7 April 2025 (UTC)[reply]
      Fees or damages, yes. Money. Also,
      I totally agree with Jmabel on the importance of the warning being placed prominently on the file page. Ikan Kekek (talk) 23:22, 7 April 2025 (UTC)[reply]
      And to be fully clear, I  Support any notice that serves to make it more obvious to reusers what their responsibilities are and what consequences could befall them if they fail to credit their source properly. Ikan Kekek (talk) 21:26, 8 April 2025 (UTC)[reply]
      If you open a file in the Media Viewer there is already a generated attribution text as plain text and HTML but it is hidden behind a download button. In the implementation the text should definitely not be in red but aligned with the general style. GPSLeo (talk) 20:36, 7 April 2025 (UTC)[reply]
      Yeah, no red. I was just getting annoyed with several news outlets that only had "Wikimedia Commons" under CC BY photos, so I went a little crazy in my suggestion. Positively unhinged.
      As for the wording, don't y'all think we should go for something more concise and direct? For example, "If you use this file, you must attribute the author / you must include this information:" Doesn't have to be that, but you see what I mean.
      Whatever we decide on, we don't want informaton about attribution, fees etc. to appear when no attribution is needed. "Use this file" always provides a credit line, even when the file is PD. Sinigh (talk) 22:05, 7 April 2025 (UTC)[reply]
      And the good guys actually read this and do the right thing, even if they don't have to. (Right now I'm a bit in love with Shipping Australia.) This is what we are striving for. --Cart (talk) 22:38, 7 April 2025 (UTC)[reply]
 Support with Cart's fees.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:06, 7 April 2025 (UTC)[reply]
 Support -- Infrogmation of New Orleans (talk) 00:11, 8 April 2025 (UTC)[reply]
 Support. The Stockphoto gadget is a step in the right direction, but it's kind of clunky and easy to overlook - and doesn't show up at all on mobile devices! We can do better. Omphalographer (talk) 07:33, 8 April 2025 (UTC)[reply]
  •  Support. A step in the right direction. I would be careful about including things like "Failure to provide this attribution can incur legal and/or financial penalties to the reuser". Licences and use-cases are complex, so it is not a good idea to provide legal advice.--Commander Keane (talk) 09:34, 8 April 2025 (UTC)[reply]
  •  Oppose this seems to be a reaction to this complete communication disaster. I am not against correct attribution and will change to support this if we're not effectively scrapping the CL-TR-Guideline as a result: This approach here is going to add scary warning templates TO ALL FILES regardless of the problematic licenses. Images contributed under a CC4 license do not invite costly legal battles and should not be scary. And even most images contributed under CC1-CC3 license do not cause the respective uploaders to involve enforcement agencies... also no reason to scare people about fines & fees. My point is that: Images from those uploaders who do employ enforcement agencies to directly send large invoices to re-users, still require additional attention, and the easy-to-overlook warning label proposed above is of no help for those cases. --Enyavar (talk) 12:31, 8 April 2025 (UTC)[reply]
     Comment My suggestion was by no means a reaction to that or any other currently ongoing discussion. I have not participated in or even read it. I also advised against adding any legalese. My suggestion only attempts to address a frequent issue (unattributed works that require attribution when used), by adding clear instructions immediately below files, since they unfortunately seem to need it. Sinigh (talk) 13:44, 8 April 2025 (UTC)[reply]
     Comment The main problem, of course, is that not even professionals seem to have a clue on using free non-PD images. We need to make it obvious that you need to check what the licence requires from you. If we can tell the actual requirements in a good way that covers everything that isn't an obvious corner case, then good.
    The second problem, however, is that requirements can be complicated. I haven't figured out any watertight advice, other than to let a lawyer check the actual licence. Is the attribution line actually constructed so that it takes into account any place where requirements may be stated? How can we extract an attribution line from user templates? What if an attribution line is specified, but placed in the description field (by a non-author uploader)?
    –LPfi (talk) 12:09, 10 April 2025 (UTC)[reply]
    The proposal is just an attribution, I don't think there is a need to over think it. It may reduce copyright infringement cases, but it can never prevent them all and that is the best we can do. As you say, only a lawyer can interpret the licence and give thorough advice and it is up to reusers to find the correct attribution (and meet all of the other conditions). Of course, Commons can strive to extract the correct attribution - we should do that anyway. The attribution line makes it somewhat more obvious to reusers that the file has licence conditions, hopefully they will see the creativecommons.org link and actually make their way to the deed. Commander Keane (talk) 12:46, 10 April 2025 (UTC)[reply]
    Just thinking about it, it is essential to call it "Credit:" rather than "Attribution:" to avoid confusion with the term in the licence summary. Commander Keane (talk) 12:55, 10 April 2025 (UTC)[reply]
     Agree. I also agree that this shouldn't be made more complicated than it needs to be. The Stockphoto gadget always provides a credit line, with the addition of "Attribution not legally required" when applicable (which I didn't notice before). This new feature could work the same way. What works there should work here. Sinigh (talk) 13:45, 10 April 2025 (UTC)[reply]
 Comment I would support having the design team to redesign the file page to provide users with clear attribution instructions. The current UI is not user-friendly for those who just want to download a picture, leaving them confused about how to give attribution. Some people just attribute to "Wikimedia Commons" or "Wikipedia". --0x0a (talk) 10:31, 14 April 2025 (UTC)[reply]

I request SVG containing xhtml element can be uploaded

[edit]

Hello,

I work since 3 days to improve chi2 graphes without using Javascript because commoms refuses upload of SVG containing JavaScript.

I have found a solution based on CSS and input tag of xhtml but commons refuses to upload this SVG because it contains "http://www.w3.org/1999/xhtml" namespace !!!

In FAQ I found some explanations indicating that this namespace is not accepted in SVG without saying WHY !

First of all, xhtml is accepted in SVG, it is only refuse by Commons Wikipedia not by SVG.

Can this restriction for xhtml in SVG be removed to allow great improvements in graphes design ?

You can find improved SVG file on https://github.com/schlebe/SVG-Images/blob/main/Chi-square_Density.svg

I added <input> CheckBox to hide/show some curves and to hide/show some points on curves.

Can Wikipedia improve this situation ?

Best regards

Schlebe (talk) 18:50, 9 April 2025 (UTC)[reply]

No, and it's for essentially the same reason - the XHTML namespace includes elements and attributes like <script> or onclick="…" which can be used to execute scripting content. While I'm sure you have good intentions, scripting content (even in SVGs) presents a risk to users; we can't allow it to be included in files. Omphalographer (talk) 23:05, 9 April 2025 (UTC)[reply]
Just for information, my SVG file doesn't contain <script> or any other events using script. My SVG contains only <div> and <input> html tags !
I understand your explanation but I don't understand the second NO that indicate that it is impossible for Wikipedia to improve this situation.
It's just a matter of willpower !
Wikipedia can certainly check if uploaded file contains script code or prohibited html tags and accept all files that are conform to check process ! Schlebe (talk) 08:19, 17 April 2025 (UTC)[reply]
You can also show directly SVG view on CodePen on https://codepen.io/schlebe/full/gbbOrYK Schlebe (talk) 06:30, 17 April 2025 (UTC)[reply]

Call statistics - Pageviews Analysis

[edit]

In the German Wikipedia there is a link in the footer for the retrieval statistics. I would like to see this for all pages on Commons as well. (Example (de.wp), Example (Commons User Pages)) (see also) Molgreen (talk) 15:43, 13 April 2025 (UTC)[reply]

I think that's already sort of available? Maybe you need to activate it somewhere in settings or gadgets, but I have a link called "Page information" in the right sidebar which leads to this page, and at the bottom of that page in the section "Information on external/private servers", there's a link to page analytics. Nakonana (talk) 16:46, 13 April 2025 (UTC)[reply]
I don't know if that's the issue but the right sidebar is not available on mobile or is it? Prototyperspective (talk) 17:07, 13 April 2025 (UTC)[reply]
On mobile, there are three vertical dots next to the pencil symbol for editing. If you click those dots, you'll see the link to "Page information" (unless that's something you need to activate in your settings). Nakonana (talk) 17:11, 13 April 2025 (UTC)[reply]
Clarification: "on mobile browser". The situation might be different on the mobile app. Nakonana (talk) 17:13, 13 April 2025 (UTC)[reply]
There are no vertical dots next to the pencil symbol for editing for me when using Android or am I missing something? Maybe a screenshot would help. Prototyperspective (talk) 18:12, 13 April 2025 (UTC)[reply]
File:Screenshot of tools menu on Wiki Commons in mobile Firefox browser.png. I'm using the Vector (2022) skin, if that's relevant. It might be a gadget (maybe MoreMenu or ExtraTabs2) that you need to activate in your settings to see the dots. Nakonana (talk) 18:32, 13 April 2025 (UTC)[reply]
I don't see that button. Thanks for the screenshot. Does it also display if you're logged out? Most visitors of Commons on mobile aren't logged in. Prototyperspective (talk) 18:40, 13 April 2025 (UTC)[reply]
No, it's not there when logged out. Nakonana (talk) 19:00, 13 April 2025 (UTC)[reply]

Do we need a policy against AI generated comments in discussions

[edit]

Recently the number of comments in discussions they are generated using AI tools dramatically increased. I want to discuss if we need a policy against this. The main reason against such comments from my view is that they make the comments unnecessarily long and it is often unclear if the person who posted the comment really understands what they wrote. In many cases the reason for using such tool might be the insufficient knowledge of English language. Therefore I would suggest that we encourage people writing in their native language if they are not comfortable with English and then the user reading the comment can use a tool to translate the comment knowing that and how it was translated. GPSLeo (talk) 17:48, 13 April 2025 (UTC)[reply]

I also think they shouldn't be used for that purpose but comments in discussions they are generated using AI tools dramatically increased I've never seen just one. Prototyperspective (talk) 18:13, 13 April 2025 (UTC)[reply]
@GPSLeo: I certainly often use translation tools myself at times to get a first draft when replying to a question in a language such as Portuguese, where (having near-fluent Spanish) I read it well, but write it poorly and (especially) tediously. I almost always find myself editing the AI output before posting, and I certainly understand quite well what I post. I wouldn't want a policy that said I should not do this.
That said, I agree that people should not post machine translations that they cannot even read, especially without also posting the original.
@Prototyperspective: I don't get what you mean to say by I've never seen just one. Meaning, anywhere you've seen one you've seen several (my initial understanding, but not sure why that would be worth your remarking), or something else? - Jmabel ! talk 20:16, 13 April 2025 (UTC)[reply]
I don't think the user was talking about posts using machine translation but rather chatGPT, if that's not the case it could be clearer and is using faulty terminology. And I meant I haven't even seen one such post here, at least none that was not quickly removed as offtopic/vandalism. Prototyperspective (talk) 20:51, 13 April 2025 (UTC)[reply]
I think it should be a guideline, but not policy to write in your native language rather than chatgpt responses. There is a lot of nuance in user conduct discussions, and a single mistranslation could be the difference between a contributor in good standing and a block for personal attacks. All the Best -- Chuck Talk 21:02, 13 April 2025 (UTC)[reply]
Just for clarification: I used the word policy not in the sense of a Commons policy but as a synonym for rule. I also think it does not need a new page of this but we could add this to an existing policy/guideline. GPSLeo (talk) 10:42, 14 April 2025 (UTC)[reply]
"AI" is a bit of a buzzword but I think we are talking about a ChatGPT scenario over a Google Translate one, both use AI to some extent I guess. For ChatGPT I asked it Generate a keep vote for a Wikimedia Commons file deletion discussion and its first output was Keep – The file appears to be within Commons' scope and meets the relevant licensing and sourcing requirements. It provides educational or historical value and contributes to the understanding of the subject. Unless clear copyright issues or COM:SCOPE violations are present, there's no strong reason for deletion. If used, this is a problem and it should be discouraged. Trying in your best in any language at any skill level is much preffered. Commander Keane (talk) 09:24, 14 April 2025 (UTC)[reply]
  •  Comment If necessary we have also the possibility to mention it as a subsection of existing policies/guidelines, e.g. we could talk about that in Commons:What Commons is not. However I tend to be opposed because a potential issue is the lacks of potential evidence that a text have been AI generated. E.g. myself I write "so badly" that I can not image that one think my text have been AI generated, however if in a good day I write a very good sentence who will be competent to affirm my sentence have been AI generated and on what criteria? it can even be an open door to some additional disputes. Each user is responsible of their edit and of the content they add, AI generated or not, uncivility and copyright issues aside, that sound fine and sufficiant to me. Christian Ferrer (talk) 11:51, 14 April 2025 (UTC)[reply]
    I suggest moving Commons:Talk page guidelines to Commons:Discussion guidelines and making a note in the Communication good practice section that says: "You should avoid adding tool-assisted comments from services like ChatGPT, and declare when you do. Native language and understanding is fine." Commander Keane (talk) 08:38, 15 April 2025 (UTC)[reply]
    It sounds good to me. Christian Ferrer (talk) 11:31, 15 April 2025 (UTC)[reply]
Beim letzten Satz beißt sich die Katze doch in den Schwanz. Ich selbst benutze häufig deepl oder halt google, um englisch zu formulieren. Englisch lesen ist idR kein großes Problem, Schreiben jedoch sehr, insbesondere, wenn es in der Diskussion über rein technische Aspekte hinausgeht. Lasse ich den automagischen Übersetzer werkeln, bin ich durchaus in der Lage, das Ergebnis zu kontrollieren und Quatschübersetzungen zu korrigieren. Schreibe ich, wie jetzt ganz absichtlich, deutsch, kann ich mich denn darauf verlassen, dass mich der geneigte Leser per Übersetzungstool richtig versteht? Smial (talk) 11:48, 15 April 2025 (UTC)[reply]
Yes ;-) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:27, 15 April 2025 (UTC)[reply]
The translation by Google did even get the idiomatic cat biting in its tail and made the fitting "catch-22" from it. Nevertheless, I'll still mostly stick to the local Lingua franca English, even though I'm German, too. Regards, Grand-Duc (talk) 12:30, 15 April 2025 (UTC)[reply]
I think the key is to write in a language where you at least can be confident what you are saying!
FWIW, on Help desk especially, if I am reasonably sure I can provide a useful answer in the language of the questioner, I'm going to try to do that. - Jmabel ! talk 18:02, 15 April 2025 (UTC)[reply]

"Removing templates from image pages" abuse filter: enable tagging or warning

[edit]

In the description of "Removing templates from image pages" abuse filter, a note says "Removing warn until false positives go down. A lot of issues with category related templates. The tag "blanking" also seems inappropriate. A throttle may not be good for this filter since people working with categorization tend to do a lot of similar edits at a relatively fast rate.". As can be seen in the list of abuse filters, that's currently true: if the filter is triggered, it has no consequences at all. According to that filter's description page, "Of the last 377,416 actions, this filter has matched 52 (0.01%)". I think this number is small enough to tag or warn when the filter is triggered, so all cases can be reviewed and undone when neccesary. Some template removals can have a serious impact (for example, removing or replacing a license or license review template, by a vandal IP user). MGeog2022 (talk) 11:35, 18 April 2025 (UTC)[reply]

 Support, as proposer. MGeog2022 (talk) 11:36, 18 April 2025 (UTC)[reply]
 Support --Adamant1 (talk) 10:42, 19 April 2025 (UTC)[reply]
What I have seen in the last month is that warnings do not really help. Therefore I would suggest to make this a blocking filter for IP users and the warning for not autoconfirmed users. GPSLeo (talk) 10:34, 20 April 2025 (UTC)[reply]
+1 MGeog2022 (talk) 14:31, 20 April 2025 (UTC)[reply]
 Support As a regular at com:FILTERT, warnings won't work, the action should be disallow for all non auto confirmed users. Noting here that the filter (like all commons filters) will need to be rewritten for temporary accounts. All the Best -- Chuck Talk 19:25, 20 April 2025 (UTC)[reply]
Maybe an exception could be made so non-autoconfirmed users can remove templates from the files uploaded by themselves. MGeog2022 (talk) 11:01, 26 April 2025 (UTC)[reply]
Sorry, I was mistaking autoconfirmed users for autopatrolled users. Not all autoconfirmed users can be automatically trusted, but the abuse prevention doesn't need to be disallow, if the template removal edits are marked in a way that they can all be patrolled later. MGeog2022 (talk) 14:58, 26 April 2025 (UTC)[reply]
Not all autoconfirmed users can be automatically trusted. Well, maybe more than I think. Perhaps it's highly unusual that a vandal becomes autoconfirmed before detected. Many people here know it much better than I do, for sure. MGeog2022 (talk) 15:01, 26 April 2025 (UTC)[reply]
Self uploaded files are the main case of this as people remove deletion templates from their uploads without addressing the problem. GPSLeo (talk) 15:50, 26 April 2025 (UTC)[reply]

Clarity of "Threshold of Originality" and "Freedom of Panorama" in architecture

[edit]

Clarity is needed around the interaction between the principle of Threshold of originality and Freedom of panorama in the area of architecture. The two principles can be in conflict. Editors need certainty. The architecture section of the ToO in particular needs attention. It consists of nothing but 10 images. The only guide offered is "Images which have been kept because of lack of originality or de minimis". One is left to guess which of the 10 images are covered by de minimis (half of them?) and which by "lack of originality". Why is de minimis even involved here? An architectural image can be (A) de minimis and "original", (B) de minimis and "lacking originality", (C) not de minimis and "original", (D) not de minimis and "lacking originality". Each of these four possibilities needs a rule: must be deleted / may be kept. Then there is FoP Situation in different countries. These rules make no reference to ToO at all. What is the interplay between the two? If, for example, the rule in Azerbaijan says that there is no FoP and the it is "Not OK, non-commercial only", then an editor should be able to rely on that clear, unambiguous guide. Instead, it would appear that the NoFoP/Az rule rule may be trumped by ToO if the building "lacks originality". Is that indeed the case? If so, why does FoP/Az not draw attention to that exemption to the general FoP rule and give examples of how it is to be implemented? Finally, who is the arbiter of "originality"? It all seems highly subjective and not at all helpful to editors. Laurel Lodged (talk) 12:58, 21 April 2025 (UTC)[reply]

For more examples (and to see the argumentation for keeping/deleting particular images) you can also check out Category:FOP-related deletion requests/kept, Category:FOP-related deletion requests/undeleted, Category:FOP-related deletion requests/deleted, as well as Category:Threshold of originality-related deletion requests/kept, Category:Threshold of originality-related deletion requests/withdrawn, Category:Threshold of originality-related deletion requests/undeleted and Category:Threshold of originality-related deletion requests/deleted. It will still all be subjective, though, because we can't look into the judges' heads who decide on such cases irl. (And even the judges will make subjective judgments in some way; even if backed up with particular law-based argumentation, they still have to weigh which law would be more relevant for a particular case due its particular circumstances.) Nakonana (talk) 13:21, 21 April 2025 (UTC)[reply]

This is not a proposal. Please take this to the corresponding talk pages or COM:VPC. --AFBorchert (talk) 14:51, 21 April 2025 (UTC)[reply]

Done Laurel Lodged (talk) 19:22, 21 April 2025 (UTC)[reply]

Flag galleries

[edit]

There are many galleries with flags. Many of them are absolutely usable even if currently incomplete like Flags of municipalities of Angola or similar. But there are other galleries with a scope that would result in tens or thousand files being added to the gallery like Gallery of Flags in 3:2 or Flags of country subdivisions. And there are galleries they could be useful but are currently used as political battleground and sandbox by IP users like Sovereign-state flags or with totally unclear definition Flags of stateless nations. Some of these pages where once clearly defined like Flag map of the world (original page) but at some point got expanded without prior discussion and no clear concept again primarily by IP users.

We need some way to deal with this. I think we should definitely delete the overly broad or unclear scoped galleries and restore the useful galleries to a version where they had a clear scope. Then we should protect them from IP edits. GPSLeo (talk) 10:52, 27 April 2025 (UTC)[reply]

 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:29, 27 April 2025 (UTC)[reply]
 Support doing somthing, but I think normal DRs and protection should do the trick. All the Best -- Chuck Talk 03:36, 28 April 2025 (UTC)[reply]
 Support. Gallery pages about flags should be used for specific collections of the flags of closely related entities, e.g. flags of nations, flags of states or provinces within a country, etc. Collections of unrelated flags like "flags in 3:2" are handled adequately by categories; rollups like "flags of country subdivisions" are too broad. Additionally, I'd note that we have a whole mess of year-by-year flag galleries which are completely unmaintainable and which, in most cases, barely change from year to year. I'd propose that we get rid of most of those as well - collections of historical flags at specific, stable points in time could be useful, but we certainly don't need one for every single year. Omphalographer (talk) 21:15, 28 April 2025 (UTC)[reply]
I could definitely see some value in a gallery of national flags for a period (certainly longer than a year), but part of what would make it valuable would be precisely to note the changes in that period, whether it is Canada moving away from incorporating the Union Jack in its flag, the U.S. adding stars as it added states, the many changes of flags during the decolonization of Latin America or Africa, or the adding and dropping of Communist symbols from flags. - Jmabel ! talk 03:18, 29 April 2025 (UTC)[reply]
Couldn't you just do that with a regular gallery for flags of a country without it being based on a time period ("by year" or otherwise) though? Like what's the point in having a gallery specifically for flags over time when the same thing can be done with a regular one? --Adamant1 (talk) 03:39, 29 April 2025 (UTC)[reply]
You could for any one country, but it wouldn't show patterns like the wave of decolonization or the fall of Communism in Eastern Eruope. There is definitely value in a visual representation of such things, and Commons galleries are a good tool for showing it. - Jmabel ! talk 17:44, 29 April 2025 (UTC)[reply]
A timeline of changes to flags in a region could also be a great idea for a gallery. But what I meant there were collections along the lines of "flags of Europe in 1815" (i.e. post-Congress of Vienna), where there's a substantial difference from modern flags, not only in the designs of the flags but also in the nations represented. Omphalographer (talk) 18:37, 29 April 2025 (UTC)[reply]
  •  Comment There are three separate problems being discussed here: 1) Galleries where the majority of images that should be in that gallery are non-free, and therefore won't be on Commons for the foreseeable future. 2) Galleries that don't seem to serve a clear purpose or provide a benefit separate from a category covering the same content. 3) Galleries as a venue for ethnic/geopolitical edit warring and vandalism. I'm not sure if the 'a gallery for every year, most of which are substantially similar' concern is an issue or not (apart from issue 3). In my opinion, we should be getting rid of galleries where issue 1 or 2 are the issue. For issue 3, that's a behavioral issue that should be addressed through the page protection and blocking policies. The Squirrel Conspiracy (talk) 21:54, 29 April 2025 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=1027229954"