Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
Help deskVillage pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: 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.


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?



Update padlock icons that Wikimedia Commons use to the ones that the English Wikipedia uses[edit]


Full-protection-shackle-block.svg - Full protection

Semi-protection-shackle.svg - Semi protection

Move-protection-shackle.svg - Move protection

Cascade-protection-shackle-double-chain-link.svg - Cascading protection

Upload-protection-shackle.svg - Upload protection

--Majora (talk) 02:07, 30 January 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The pad lock icons that Wikipedia uses are actually somewhat more descriptive on the image itself of what type of protection has been put into place. Even a user that does not know the meaning behind a particular protection name, the Wikipedia padlock icon gives away somewhat of a hint. The current old style(what Wikipedia used to use), only differentiates the padlock icons of different types of protection by color. Not only is that not much descriptive, it could also be deceiving to a color blind person. The updated Wikipedia padlock design has somewhat little bit taken care of this issue as well, a majority of the low level padlocks are black in color (thus causing no issues to color blind people).Aceing Winter Snows Harsh Cold (talk) 06:45, 19 December 2018 (UTC)

It's not clear at all to me what exactly what you are proposing here. Please give links and/or examples: Which set of files should be used instead of which other set of files for which purpose? Thanks, --El Grafo (talk) 09:25, 19 December 2018 (UTC)
The English Wikipedia changed to use the icons in Category:Page Protection Padlock Redesign (2018) to denote levels of page protection. GMGtalk 11:51, 19 December 2018 (UTC)
Wikipedia:Wikipedia:Village_pump_(proposals)/Archive_155#Proposal/RFC:_Redesigning_page-protection_padlock_icons_to_be_more_accessible.--BevinKacon (talk) 00:01, 20 December 2018 (UTC)
Thanks for the clarificatiopns, GreenMeansGo and BevinKacon. TBH, I never even noticed we had different padlock icons for different purposes cat Commons. I guess I wouldn't mind if somebody wanted to implement the new ones here. --El Grafo (talk) 09:27, 20 December 2018 (UTC)
Well we can't really implement these exact ones. We could adapt them, but using letters derived from English meanings is problematic on an multi-lingual project where many users don't even speak a language in a Latin script. GMGtalk 11:24, 20 December 2018 (UTC)
Is it possible that they would only appear if a user has set their standard language to "English"? And even though people say that Wikimedia Commons is "a multilingual project" for all intents and purposes it's still primarily an English language project, even if you change your settings to "Vietnamese" or "Chinese (Traditional - Taiwan)" you would still see "Category:" And "File:" Rather than "Thể loại:" Or "Tập tin:" As they would appear at "w:vi:Tập tin:Bao-Dai-Thong-Bao.png" but if you were to click on the blue part of "Tập tin này từ Wikimedia Commons. Trang miêu tả nó ở đấy" it will bring you to "File:" yes, you can add multilingual descriptions and things like the MediaWiki Upload Wizard are in more than one language but the de facto language of Wikimedia Commons is still in English and if these padlocks are more descriptive for us English speakers (who make up the majority of this project as all policy conversation is conducted in this language) then it would be beneficial to the largest demographic on the project, what harm would that cause? Sure, it's chauvinistic, but it's still beneficial at large. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:03, 21 December 2018 (UTC)
Well, I'm not sure it makes sense to make a change intended to increase accessibility for the visually impaired, and in doing so, make the site less accessible for anyone who doesn't speak English. Having said that, only four of them are based on letters, so it shouldn't be too difficult to find more culturally universal symbols to replace them. GMGtalk 11:32, 21 December 2018 (UTC)
I agree 100% (one-hundred percent), and those padlocks could also be used on Wikidata and other multilingual Wikimedia projects, maybe someone here reading this could create them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:02, 21 December 2018 (UTC)
We definitely need to get rid of the letter initials if these locks are used in multilingual environments. XYZtSpace (talk) 23:23, 29 December 2018 (UTC)
  • Symbol support vote.svg Support, good idea.   — Jeff G. please ping or talk to me 14:32, 22 December 2018 (UTC)
  • Symbol support vote.svg Support. Vulphere 08:47, 23 December 2018 (UTC)
  • Symbol support vote.svg Support - Alexis Jazz ping plz 12:13, 29 December 2018 (UTC)
  • Symbol support vote.svg Support - I could be wrong but I believe EN was the first to update theres with everyone else following after (I remember participating in the discussion and also remember discussing the colours), I prefer the new ones over the old ones and would've supported this regardless of EN. –Davey2010Talk 14:51, 29 December 2018 (UTC)
  • Symbol support vote.svg Support Full-protection-shackle-block.svg, Semi-protection-shackle.svg, Move-protection-shackle.svg, Cascade-protection-shackle-double-chain-link.svg, Upload-protection-shackle.svg, (for the future: Template-protection-shackle-brackets.svg, Pending-protection-shackle-double-ticks.svg, Create-protection-shackle.svg, Extended-protection-shackle-check-mark.svg, Office-protection-shackle-WMFlogo.svg). I don't support those with Latin letters, as they are almost meaningless for most users. 4nn1l2 (talk) 20:24, 31 December 2018 (UTC)
  • Symbol support vote.svg Support same as 4nn1l2, no preference on icon used, just no letters.--BevinKacon (talk) 23:01, 7 January 2019 (UTC)
  • Symbol support vote.svg Support, nice but I preferred the "Proposed design" below. --B dash (talk) 10:41, 10 January 2019 (UTC)
  • Symbol support vote.svg Support; I would prefer the proposed designs except for the full protection padlock, for which I'm not sure and don't really mind either way. Jc86035 (talk) 08:48, 13 January 2019 (UTC)
  • Symbol oppose vote.svg Oppose I prefer the current ones, less cluttered and more expressive. Some of the suggested alternatives below do offer some (multilingual) advantage. (I've also changed the header to say "English Wikipedia", because Wikipedia overall hasn't settled on the proposed icons.) Nemo 15:31, 13 January 2019 (UTC)
@Nemo bis: you mean the current ones from English Wikipedia or..? Because the current ones here are just the exact same lock with different colors. (nearly useless for the color blind I imagine..) I wouldn't call that "expressive". - Alexis Jazz ping plz 01:28, 14 January 2019 (UTC)
  • Symbol support vote.svg Support I prefer any of the new designs to the old ones because I think they are easier to identify as locks. Blue Rasberry (talk) 01:15, 29 January 2019 (UTC)
  • Symbol support vote.svg Support Bidgee (talk) 02:22, 29 January 2019 (UTC)
  • Symbol support vote.svg Support, without letters, as above. Strakhov (talk) 17:11, 29 January 2019 (UTC)
  • Symbol support vote.svg Support ok for me. (thanks Alexis Jazz for ping on french village pump) Tomybrz Bip Bip 20:06, 29 January 2019 (UTC)

Update padlock discussion[edit]

Type of protection Current design Proposed design Suggested alternatives
Full protection
Fully protected
A symbolic representation of a padlock, gold in color with a grey shackle. On the body is a white capital letter F.

A symbolic representation of a double padlock, gold and silver in color with a grey shackle.  A symbolic representation of a padlock, gold in color with a grey shackle. On the body is a white 🚫 sign.

Semi protection
Silver padlock
A symbolic representation of a padlock, dark grey in color with a grey shackle.
A symbolic representation of a padlock, dark grey in two colors with a grey shackle. A symbolic representation of a padlock, dark grey in two colors with a grey shackle. A symbolic representation of a padlock, dark grey in two colors with an account icon in two shades and a grey shackle.
Move protection
Green padlock
A symbolic representation of a padlock, green in color with a grey shackle. On the body is a black right arrow.
Cascading protection
Turquoise padlock
A symbolic representation of a padlock, turquoise in color with a grey shackle. On the body is a white symbol representing a chain link.
A symbolic representation of a padlock, turquoise in color with a grey shackle. On the body is a white symbol representing a chain link with two links.
Upload protection
Purple padlock
A symbolic representation of a padlock, purple in color with a grey shackle. On the body is a white up arrow above a horizontal line.
The following icons are not used on Commons but included in the table in case other wikis want to adopt them/harmonize padlock icons:
Template protection
A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a white capital letter T.
A symbolic representation of a padlock, magenta in color with a grey shackle. On the body are curly brackets. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a puzzle piece. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a tilted puzzle piece. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a puzzle piece.
Creation protection
Blue padlock
A symbolic representation of a padlock, light blue in color with a grey shackle. On the body is a white plus sign.
Pending changes protection
White padlock
A symbolic representation of a padlock, blue-grey in color with a grey shackle. On the body is a white check mark.
A symbolic representation of a padlock, blue-grey in color with a grey shackle. On the body are double ticks.
Extended confirmed protection
Dark blue padlock
A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is a white capital letter E.
A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is a check mark. A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is an account icon.
Protection by office action
Black padlock
A symbolic representation of a padlock, black in color with a grey shackle. On the body is a white circle.
A symbolic representation of a padlock, black in color with a grey shackle. On the body is the WMF logo.
  • @GreenMeansGo, Donald Trung: Added office action padlock with WMF logo. The T for template could perhaps be replaced with {{? For full maybe two locks that overlap. Even with just the letters though it's an improvement. - Alexis Jazz ping plz 12:13, 29 December 2018 (UTC)
  • Added double padlock for full protection. - Alexis Jazz ping plz 13:20, 29 December 2018 (UTC)
  • Oh that looks really nice actually. For free we also have en:File:Generic-protected-shackle.svg and File:Semilock.png. Looks like they were designed but never used. I think it was suggested at one point to use the "no" sign, as in like...the red (/) on a no-smoking sign for full. Not sure what we could use for ECP. GMGtalk 13:23, 29 December 2018 (UTC)
  • @GreenMeansGo: maybe two arrows pointing in opposite directions? (to symbolize wide, extended) Or a little clock or stopwatch, but I'm not sure that would fit. - Alexis Jazz ping plz 13:32, 29 December 2018 (UTC)
  • I really don't know. Arrows might be confusing vis a vis the arrow on the move protection. It'd be a lot easier if we could use numbers, but we run into the same problem as letters. GMGtalk 14:05, 29 December 2018 (UTC)
  • @GreenMeansGo: this is the one you are referring to. I'll make an updated version and put it in the table. XYZtSpace (talk) 23:28, 29 December 2018 (UTC)
  • Ah ha! Yes, bingo. I wasn't crazy. I could've swore I'd seen it before. Thanks a bunch. GMGtalk 01:03, 30 December 2018 (UTC)
  • Added some template alternatives that were already here. - Alexis Jazz ping plz 15:09, 29 December 2018 (UTC)
  • Nice. I like any of the grey shackles puzzle pieces. I assume jigsaw puzzles are fairly cross cultural in meaning. So we really only need a clever idea for ECP. GMGtalk 15:37, 29 December 2018 (UTC)
  • @GreenMeansGo, Donald Trung: added more alternatives (removed File:Template Protection (Redesign2).svg which looks out of place). What do you think about the double tick for pending changes so the single tick could be used for extended confirmed? For template protection, I prefer the curly brackets but any of the puzzle pieces also work for me. - Alexis Jazz ping plz 15:56, 29 December 2018 (UTC)
  • @GreenMeansGo: added a padlock inspired by File:Semilock.png. I think the "account" icon in the semi-protection lock is rather unclear. I had no idea what it was until I read the upload comment. - Alexis Jazz ping plz 16:45, 29 December 2018 (UTC)
  • I personally like the slash semi too. GMGtalk 02:11, 30 December 2018 (UTC)

Pictogram-voting-question.svg Question We don’t have extended-confirmed here, do we?—Odysseus1479 (talk) 01:05, 30 December 2018 (UTC)

  • Well crap, it's not in Commons policy. I guess I just assumed it was turned on by default in media wiki. GMGtalk 02:11, 30 December 2018 (UTC)
  • Umm...embarrassing question: Nick or Yann, is extended confirmed protection even enabled on Commons? GMGtalk 03:00, 30 December 2018 (UTC)

Reckon that all of the padlocks are now made both language and script neutral, right? I don't see anything which could be seen as exclusively Anglophone in the new proposed designs. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:28, 31 December 2018 (UTC)

  • Umm...Wait. Can a local project opt out of office actions? That doesn't seem right, even if it isn't included in local policy. Office actions aren't subject to local consensus. GMGtalk 11:48, 31 December 2018 (UTC)
  • @GreenMeansGo: Of course, we can not opt out. I guess the reason it is in the not used on Commons section of the table is mainly that we do not have an equivalent of en:Template:Pp-office. Not sure we would need one though, as even the one on en.wp is completely practically unused. --El Grafo (talk) 09:35, 1 January 2019 (UTC)

Full protection lock[edit]

There is obviously consensus here to update the padlocks of semi, move, cascading, and upload protection to the ones used by the English Wikipedia at this time. The only complaints that appear above are regarding the use of Latin letters. This only really affects the full protection padlock of which there is moderate consensus to implement since most people didn't really mention it either way. I'm fully prepared to implement the changes now as this has been opened long enough for everyone to have their say but I wanted to leave this here to see if any of the previous commentators have an opinion on the alternatives to the full protection lock. If no one comments the original request passes, in full, regardless. The ones used by enwiki will be put into place and that includes the full protection lock with the "F". I'll leave this open for a little bit to get some feedback before I implement the change. --Majora (talk) 05:32, 29 January 2019 (UTC)

In that case I oppose the "F" full protection lock.
  • I prefer Full-protection-shackle-double.svg personally but would also support Full-protection-shackle-block.svg if the double lock isn't going to happen.
  • For cascade protection, I prefer Cascade-protection-shackle-double-chain-link.svg but will also accept Cascade-protection-shackle.svg if that's not going to happen.
4nn1l2 supports Full-protection-shackle-block.svg and Cascade-protection-shackle-double-chain-link.svg, BevinKacon said "same as 4nn1l2". Davey2010 supported "the new ones" which I think includes at least Cascade-protection-shackle-double-chain-link.svg. (if Davey2010 doesn't respond I'll search the page history..)
Pinging @Aceing Winter Snows Harsh Cold, Jeff G., Vulphere, Davey2010, 4nn1l2 do you have any preference/changed your mind? - Alexis Jazz ping plz 06:21, 29 January 2019 (UTC)
Pinging @B dash, Jc86035, Bluerasberry, Bidgee do you have any preference/changed your mind? - Alexis Jazz ping plz 06:21, 29 January 2019 (UTC)
@Majora, Alexis Jazz: I prefer Full-protection-shackle-double.svg or Full-protection-shackle-block.svg over the "F" full protection lock due to the latin "F". For cascade protection, I'm with Alexis, 4nn1l2, Bevin, and Davey because Cascade-protection-shackle-double-chain-link.svg more clearly depicts a chain.   — Jeff G. please ping or talk to me 06:53, 29 January 2019 (UTC)
@Majora, Alexis Jazz: I prefer Full-protection-shackle.svg for Full protection and agree with Jeff G. Cascade-protection-shackle-double-chain-link.svg better depicts the chains, Thanks, –Davey2010Talk 10:09, 29 January 2019 (UTC)
  • Thinking about it now I suppose F only makes sense on EN because it's English, As noted below If it was German, Polish or Bulgarian Wikipedia then it would be (V)oll, (P)ełny and (п)ълен respectively.... so I support Full-protection-shackle-block.svg instead as not everyone here is English and would have no idea what "F" would stand for, Thanks, –Davey2010Talk 14:07, 29 January 2019 (UTC)
F stands for "Full" in English, so it is comprehensible for those with some English knowledge. According to Google Translate, German and French languages use "voll" and "pleine" for "full" respectively. I guess other languages use other words for "full" which do not necessarily start with the letter "F". I don't mention the languages which do not use the Latin script at all (including Persian, Arabic, Indic, Chinese, Japanese, Korean, etc). Is choosing a padlock with an F letter the best option in an International environment like Commons? I think we should have spread the word to other language variants of VP (such as Forum, Bistro, Café and such). 4nn1l2 (talk) 11:19, 29 January 2019 (UTC)
  • I'm with 4nn1l2. Hash mark and unstylized chains. The F lock is a non-starter, and replacing the Latin letter I presumed was mostly a settled issue. GMGtalk 11:31, 29 January 2019 (UTC)
  • Prefer Full-protection-shackle-block.svg. The two lock design looks too different. Blue Rasberry (talk) 12:23, 29 January 2019 (UTC)
  • Prefer Full-protection-shackle-block.svg as well. The double lock sign seems confusing that it can be full protection or semi-protection. --B dash (talk) 13:28, 29 January 2019 (UTC)
  • Thanks for pinging me. :) I prefer the double lock icon for full protection. The reason for this is that full protection can be considered somewhat unique to the other forms of more used protections. In full protection only admins can edit pages where as in other forms of confirmed protection there are a much larger set of users that can edit the page. For confirmed protection, the image depicted inside the padlock gives clues to who is allowed to edit that page. There is a issue with full protection with this. The letter "F" really would only symbolise the name of the protection that is being used, and not much info about the users that are allowed to edit that specific page. This would pose a slight problem to users that are new to Wikicommons/Wikimedia who probably would not know the meaning behind full protection. The double padlock icon for full protection would be a lot more descriptive in showing that very high leveled users are only allowed to edit that specific page.
A better solution to a full protection pad lock would be a image similar to that user and key logo that Windows 98 era of Windows used to use for the admin account logo. However we would have to make a free equivalent variant of that, plus make the image small enough to fit inside the padlock icon. That would be to much to do and would be very difficult, thus forget about that and I suggest as above that the double padlock logo should be used for the full protection padlock logo.
I would also like to say on a side note, there are issues where creation protection can be used. Example of these can be rouge unessasary spam non-upload pages. Realistically speaking, this page was created obviously in a similar manner of how, Wikipedia pages in the Wikipedia domain were created on Wikipedia. Thus, repeat offenders who repeatedly create a spam page can be stopped by creation protection. I could be wrong and might be mixing up salted red-link pages with creation protection. Aceing Winter Snows Harsh Cold (talk) 21:07, 29 January 2019 (UTC)

Well that garnered responses much more quickly than I thought it would. Ok. File:Full-protection-shackle-block.svg it is. As well as the alternative cascading option. I'll go ahead and make the changes. --Majora (talk) 02:01, 30 January 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Exhibitionist uploads[edit]

I regularly see uploads low quality amateur porn which doesn't serve any educational purpose. It is usually a man masturbating and uploading a video of it, with no contributions to other projects. It seems plausible that there is some offsite collusion, although I don't know where. This has been an ongoing issue for a while. See these accounts in just the past couple of days:

Don't get me wrong. I believe sexual content is necessary. But these uploads are disruptive; Commons is not an amateur porn site, and it drives users away when they see their uploads in the same place as useless amateur porn.

As such, I believe we should add a CSD category for amateur porn with no educational value from non-contributors. Just like COM:CSD#F10, the keywords are non-contributors and low to medium quality. Magog the Ogre (talk) (contribs) 22:06, 24 December 2018 (UTC)

Spam is a worse problem, especially as several pron warriors lurk on this project. Amateur glamour stuff should go through deletion like any other file. The problem with "no educational value" is that every week I see perfectly valid files, including in scope nudity and sexuality related material, having speedy tags, wrongly, with this claim.
PS Christmas is not the right time to raise policy proposals. -- (talk) 23:03, 24 December 2018 (UTC)
We have deletion requests for a reason, but what constitutes "spam" because my impression is that everyone seems to have their own opinion on it, someone who imports a lot from the same website is "a spammer" then you would be considered one too as you're bombarding Commons with external links and Wikipedia doesn't care if that link is to a GLAM so why would Commons? I think that "spam" is too vague of a term to actually enforce here because anything less than negative of something could be seen as "promotional". Anyhow the deletion request system is the best option because I can see people abuse {{Speedy}} for basically anything, in fact regarding porn deletion requests there seems to be a user who just writes "{{vd}} Worthless, poor quality, redundant and out of scope." At every DR that contains a penis even if it is in use or of high quality, now imagine if people like this had a policy they could abuse. DR's are also more transparent than speedy deletions ans though I agree that most of the bad quality images of porn aren't fit for this project, allowing careless deletion could do more harm than good. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:01, 25 December 2018 (UTC)
  • I would support this for images that might be "revenge porn", such as the images discussed in "Commons:Deletion requests/Files uploaded by Hakunamatata12345678" where both files seem to have been sent through WhatsApp-Messenger half a decade ago, I highly doubt that anyone would send photographs of their own penis through WhatsApp-Messenger and then post them to the Internet, if it's likely that a nude or dickpic is uploaded by someone who isn't the author then this could be a form of cyberharassment and this should be speedy'd as the content is potentially harmful for the depicted individual. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:22, 25 December 2018 (UTC)
  • Pictogram voting comment.svg Comment Deleted. Such files can always be speedy deleted as copyvios and/or vandalism. I am not sure a new deletion reason is necessary. Regards, Yann (talk) 12:05, 25 December 2018 (UTC)
  • @Yann:, I agree that no new rules would have to be established for this, but it could be an expansion of harassment rules as according to "w:en:Revenge porn" does have special legal ramifications other than merely a copyright violation, and I think that we should treat people who post revenge porns/pornography (such as unauthorised dickpics) to Wikimedia Commons should be treated as people who post legal threats. A couple of years ago someone I know went through a divorce and his ex-wife posted his nudes online, let's just say that he now has full custody over their children and she has a restraining order against her so "revenge porn" can have legal effects. I just hope that the poor man whose penis was uploaded wasn't harmed by those images. But Wikimedia Commons fals under the safe harbour provision of the DMCA anyhow so I don't think that "revenge porn" constitutes a special threat to the project other than "regular copyright violations", but we should be weary of it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:18, 25 December 2018 (UTC)
  • IMO, "revenge porn" falls into the same attack images category like racist or other harmful intent, but in this case, it is a bit less obvious to recognize, compared to mere exhibitionism. Regards, Yann (talk) 12:24, 25 December 2018 (UTC)

Pointing your camera 45 degrees down, from your face to your crotch is a nude selfie, so should be should be speedy deleted as F10.--BevinKacon (talk) 16:49, 28 December 2018 (UTC)

No, that's not a nude selfie. That's just a dickpic (or a..vagpic?). - Alexis Jazz ping plz 10:49, 29 December 2018 (UTC)
  • Symbol oppose vote.svg Oppose with an exception for confirmed socks (which you suggest is the problem here). Send it to DR the first time. If a video of the same masturbating man is uploaded the day after deletion, even if it is a new (but similar in terms of content and quality) video, use G4. - Alexis Jazz ping plz 10:49, 29 December 2018 (UTC)
  • Symbol oppose vote.svg Oppose A little while ago I went and browsed sexual content on Commons, and I must say that we barely have any. It is therefore very surprising how such files can be deleted without a Deletion Request discussion for at least two or three weeks. The way I see this sexuality and food would be a good analogy, both are aspects of life that are essential for the species, so we should have about the same amount of media give or take 5%. Currently we do not approach anything close to that. ℺ Gone Postal ( ) 08:14, 21 January 2019 (UTC)

Make the "more upload options" proposal apply to all user accounts with autopatrol flag[edit]

7 days, no opposition, enough support to show that that community is fine with this. Good enough for me. I'll add this to the already open phab ticket. --Majora (talk) 02:05, 28 January 2019 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Pinging everyone who responded to the original proposal: Pinging @Koavf, GreenMeansGo, Yann, Donald Trung, .

Also see phab:T214003 and User talk:Alexis Jazz#upload by url.

Due to an interpretation of words that I personally don't really see in the original proposal, only users in the autopatrolled user group are now getting the extra options. Patrollers and bots, who also have the autopatrolled flag and are thus autopatrolled users, are not getting the additional options. An admin could simply add them -all 687 of them- to the autopatrolled group, but that'll probably cause some muscle strain. Don't ask me to explain this, because I hardly understand it. But it's easier to nod and say yes in this case. - Alexis Jazz ping plz 17:12, 20 January 2019 (UTC)

Proposal: more upload options for autopatrolled things[edit]

Proposal: make the previous proposal apply to all users and all user accounts and all people and in fact all beings who have, carry, possess, own and/or are the legal guardian of a working autopatrolled flag, autopatrol bit, autopatrol user right or are autopatrolled by magical intervention. (sorry, gotta cover my bases this time..) Offer void in Nebraska outside Wikimedia Commons.

  • Symbol support vote.svg Support - Alexis Jazz ping plz 17:12, 20 January 2019 (UTC)
  • Symbol support vote.svg Support, didn't we just vote on this before? Why is the "Autopatrolled" user group removed from "Patrollers" anyhow if they're not the same? Because I can remember a Village pump discussion a few years ago that resulted in all "Patrollers" and other "higher user groups" having the "Autopatrolled" user group removed from them, maybe it's time to stop removing it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:52, 20 January 2019 (UTC)
  • Symbol support vote.svg Support Wut? GMGtalk 18:39, 20 January 2019 (UTC)
  • Symbol support vote.svg Support Obviously. Yann (talk) 18:52, 20 January 2019 (UTC)
  • Symbol support vote.svg Support Just common sense Abzeronow (talk) 21:50, 20 January 2019 (UTC)
  • Symbol support vote.svg Support, of course.   — Jeff G. please ping or talk to me 22:11, 20 January 2019 (UTC)
  • Symbol support vote.svg Support - no brainer tbh. –Davey2010Talk 21:38, 25 January 2019 (UTC)

Discussion: more upload options for autopatrolled things[edit]

@Donald Trung: the autopatrolled flag was added to the patroller group, making the autopatroller group redundant for patrollers. Admins, for example, are not in the autopatrolled group either. We voted on autopatrolled users, which I take as anyone with the autopatrolled flag, but in this case was interpreted to mean the autopatrolled user group.

I told you not to ask me to explain it, I suck at this. - Alexis Jazz ping plz 18:02, 20 January 2019 (UTC)

We did and we didn't just have a RfC on this. You must separate user groups from user rights. User rights are assigned to groups and then the group is granted to individual editors. Technically any right can be assigned to any group and there are a lot of rights as can be seen in the interface for some of the global groups which can actually be manipulated by stewards instead of having to get the devs involved. There was obviously a slight confusion between the difference between groups and rights and in the last RfC the question that appeared to have been raised was to add the upload_by_url right to the autopatroller group. That is the way I read the proposal, that is the way I closed it, and that is the way the devs are implementing it. I did not read it as add upload_by_url to any and all accounts that have the autopatrol flag. Since the current implementation of the original RfC is proceeding as I originally interpreted it we would need to verify consensus to add any additional flags to any additional groups. Bureaucratic red tape, I know. But this way the devs know exactly what we are asking for when it comes to user rights. --Majora (talk) 18:19, 20 January 2019 (UTC)
And before anyone asks why I didn't ask what the "correct" interpretation of the original RfC should have been before I closed it, I did. I was told my interpretation was correct, although that might have been due to the confusion between groups and rights again. --Majora (talk) 18:48, 20 January 2019 (UTC)
Yes, I either read or assumed (doesn't matter, can't remember) you meant all users with an autopatrol flag. I was unaware you were differentiating there between users with the flag and users in the group. I thought your only question was if the proposal meant the extended uploader group would become obsolete, to that I answered "correct", unaware you meant more. - Alexis Jazz ping plz 19:55, 20 January 2019 (UTC)

Does Wikimedia Commons have the snowball clause ("COM:SNOW"?) so the developers could quickly add this to the "Patrollers" user group and "other autopatrollled users"? Or is there a minimum amount of time that this has to remain open. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:58, 21 January 2019 (UTC)

This has been opened for 24 hours on a holiday weekend in the United States where a great number of contributors live. There is absolutely no reason why this has to be done immediately. Both groups have lived without the ability to upload by URL for years and years. A few more days isn't going to hurt them. The phab ticket isn't going to go anywhere. My personal opinion is that RfCs should be open for a minimum of 7 days to give the greatest number of people the opportunity to comment. --Majora (talk) 17:16, 21 January 2019 (UTC)
And if any patroller asks about it, those who ask can be added to the autopatrolled group for a few days by any admin. - Alexis Jazz ping plz 22:09, 21 January 2019 (UTC)
@Donald Trung: Commons:Village pump/Proposals/Archive/2018/07#Speedy deletions: Selfies was closed as "done" in 6 days, by the proposer, that's the fastest one I can think of. - Alexis Jazz ping plz 22:17, 21 January 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Drop security support for IE6 and IE7[edit]

Also see phab:T27707 and Commons:Village pump/Technical#How to propose a change to the MediaWiki software?.

It appears that all we can do is vote to hopefully get a local exception. I will also create this proposal on some other wikis.

When a photo has HTML code in the EXIF metadata like "<a>Photo by me</a>", it can't be uploaded to Commons. For example, The reason for that is because Internet Explorer 6 and 7 (Microsoft dropped support for IE7 entirely in April 2016) don't understand they should render such files as images. The image file is perfectly valid and all, no harm, but IE6 and IE7 are not very smart.

As long as these are listed on mw:Compatibility#Browser support matrix, which will be forever because no procedure exists to propose a change to that list, we will continue to suffer from the flaws of these Microsoft products. While MediaWiki as a software product may continue to support a dead browser, we could end that support locally. - Alexis Jazz ping plz 16:55, 25 January 2019 (UTC)

Proposal: Create a local exception for Commons to skip useless security checks for IE6 and IE7 exploits that hamper uploads.[edit]

  • Let’s not mix matters up. Not upgrading from Windows XP to a newer version can be due to low-end or aging machine and using it with Windows XP instead of installing a Linux flavor can be made necessary by existing workflow needs (that was my own personal story until very recently) — but none of that excuses or explains the use of IE6 or IE7. Anyone who’s still using Windows XP today must be resourceful enough to have changed to another browser long ago (my last continued use of MSIE was in 2003 and even that only due to corporate imposition). As for upgrading from desktop to mobile, well, that’s really like going from this to this and call it an improvement. -- Tuválkin 22:46, 25 January 2019 (UTC)
  • Symbol support vote.svg Support Legitimate uploads under a free licence useful for educational purpose should not be blocked due to anything other than extrordinary reason. If somebody were to write a clone of Firefox 1.0 which refuses to open images that start with a vowel, we would not block those (I hope). ℺ Gone Postal ( ) 19:55, 25 January 2019 (UTC)
  • Symbol support vote.svg Support Abzeronow (talk) 20:51, 25 January 2019 (UTC)
  • Symbol support vote.svg Support - I agree we shouldn't stop people uploading just because of their browser, For instance prior to laptops I was using a Playstation PSP and the internet broswer (Opera Mini I believe) was shite but there was nothing I could do about it - Not all devices allow browser changes so as I said people shouldn't be turned away all because their device isn't top of the range brand spanking new etc etc. –Davey2010Talk 21:53, 25 January 2019 (UTC)
  • I'm sure WMF will reject this. Don't waste your time. Bye. (I won't respond to remarks here. Also, NOTE: This comment is made 100% on a personal capacity.) — regards, Revi 21:56, 25 January 2019 (UTC)
  • Symbol support vote.svg Support -- Tuválkin 22:46, 25 January 2019 (UTC)
  • Symbol support vote.svg Support - too old browser. Rudolphous (talk) 05:13, 26 January 2019 (UTC)
  • Symbol support vote.svg Support It is worrying that the official line from the WMF is "go away, we are not touching this", when it is entirely fixable. Trapping and blanking blacklisted EXIF elements is easy to specify and should be relatively trivial to roll out. Even if this were not implemented to action at upload time, an API error trap could flag the issue and tools could separately do the stripping. -- (talk) 09:30, 26 January 2019 (UTC)
  • Symbol support vote.svg Support Please let files be uploaded to Commons easily. Look at Commons:FAQ#What does the upload error This file contains HTML or script code that may be erroneously interpreted by a web browser. mean? This is a common issue which continues to frustrate uploaders (i.e. potential content creators). I have one serious question: Why does Flickr, a professional website about images which WMF seeks advice from its designers, allow uploading files with HTML on their metadata, but Wikimedia Commons does not? 4nn1l2 (talk) 23:42, 26 January 2019 (UTC)
  • Comment: why should Commons support a full Frankenstein production line of EXIF markup? I mean, the mission of Commons is to host images and the text needed to explain and attribute them. It seems like there are a huge number of ways to have programs secretly store records of who did what with the camera and the image editor and so on when, all done sort of on the downlow, supposedly to track down child porn makers and more realistically people who record police shootings. (Bad things happen to them, always) But for our purposes, we don't need anything hidden in the image file per se; we can just have a text markup everyone can read, and a flat image in a verified EXIF-free format, and if someone really *wants* the EXIF then it could always be added to the file on the fly at the moment it is downloaded. So I don't see a need to have the metadata in the image at all, and certainly not a need for HTML that would appear to guide that metadata out of the realm of mere "information" and into the realm of "links", which is to say, I would suspect it might be subject to all kinds of extra threats and punishments for "taking a person to a site" rather than just "saying where it is", as if there were a difference. On the other hand ... is WMF afraid that damaging these magic links by turning them into mere text without the holy markup might expose them to lawsuits that they "damaged attribution"??? If I had a magic wand that could turn all the believers of censorship and copyright into chocolate ice cream I would eat real well tonight. Wnt (talk) 03:09, 27 January 2019 (UTC)
    • EXIF data is important for a large variety of reasons, it could indicate the device type or location and it can be used to better use a file due to the various factors that play in how the photograph was taken. Even if one would ignore the numerous ways that such metadata is vital for many parties, EXIF data can also be telling of authorship and the deletion requests where I've seen users point out faulty or inconsistent EXIF data exposing it as a copyright violation are numerous, EXIF data and other forms of metadata aren't trivial, they're vital. We need more data, not less. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:47, 27 January 2019 (UTC)
  • oppose As a point of principle we should be supporting the widest browser set possible. In this case I'm not sure the feature we would be adding support for is particularly desirable.Geni (talk) 19:39, 27 January 2019 (UTC)
    • In this case please start a proposal to block uploads of images with a name starting with a vowel. My planned browser will not be able to display them. ℺ Gone Postal ( ) 20:12, 27 January 2019 (UTC)
      • Let me know when you've built it and we will have a look. (PS pls include native support of dirac).Geni (talk) 21:11, 28 January 2019 (UTC)
  • IE6 is already unsupported by MediaWiki: it's in the lowest grade of support. While I agree that no efforts or resources of our copyleft projects should be spent supporting such proprietary relics, I'm not sure this specific trade-off in favour of IE6/IE7 users is a significant cost we should seek to remove. Can we solve the problem in an easier way, e.g. by making flickr2commons and friends "sanitise" such EXIF? Nemo 21:15, 27 January 2019 (UTC)
  • Weird I cannot speak to the technical costs, but it seems that the WMF position is that executing this would take one or more staff people a lot of work ("it'd probably take a few months to do"), which seems like this is a US$50,000 problem. The counterarguement from the community perspective is that we are creating a barrier for many contributors to engage in Wikimedia editing for the benefit of the minority of users who have not updated their browser since 2016, with there being a claim that some non-Microsoft browsers since 2003 are new enough. There is the claim that our traffic reports show no traffic from these non-compatible browsers. Obviously no one wants to break the wiki, and wiki discussion is not necessarily a way to arrive at security truth, but it seems like we have a case where there is a community problem with a seemingly easy technical solution which might be a major security risk. Someone should publicly articulate that security risk, right? Blue Rasberry (talk) 12:34, 29 January 2019 (UTC)
Phab:T27707 is an articulation of the security risk, and everything written there is CC-BY-SA, so can be copied and reused. -- (talk) 13:07, 29 January 2019 (UTC)
  • Symbol support vote.svg Support Looks sensible to me. Yann (talk) 13:37, 29 January 2019 (UTC)
  • Symbol oppose vote.svg Oppose The proposal makes no sense. Commons supplies images to other Wikimedia projects, so how would Commons having an opt-out, but other projects not, work? I have not seen anyone quote browser usage stats that actually apply to Wikipedia page views, vs views of some tech website. The proposal (and discussion on the other forum) are loaded with inflammatory language, and reflect a First-World tech-user viewpoint. Do we have any stats on how common it is for a JPG to have HTML embedded in the EXIF? I suspect we have all wasted more of our short lives on this mess than it deserves. By all means ask the developers for a fix/work-around, but the proposal here is pure political games IMO. -- Colin (talk) 14:42, 29 January 2019 (UTC)
Your reasoning makes no sense. Replied in the discussion section. - Alexis Jazz ping plz 06:22, 30 January 2019 (UTC)
  • Symbol support vote.svg Support This seems like a bug in the browser. We shouldn't ban uploads to work around bugs in minor browsers. That said, though, if this proposal doesn't pass and you want to upload a specific image, surely you can edit the EXIF? Here is a site that does it online: --GRuban (talk) 15:41, 29 January 2019 (UTC)
GRuban, yes, but that's a massive undertaking for thousands of images and causes FlickreviewR to fail, forcing human license reviewers to spend time on them. - Alexis Jazz ping plz 06:22, 30 January 2019 (UTC)

Discussion: Drop security support for IE6 and IE7[edit]

{{atop|status=Proposal passes|result=Closed by Jdforrester (WMF) because such exemptions may not be voted on by contributors. See this edit. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:37, 25 January 2019 (UTC))

@Donald Trung: Thanks for undeleting. I'm actually reopening this. Jdforrester (WMF) may be a Lead Product Manager, but on Commons, he's ultimately nothing but an autoconfirmed mortal. @Jdforrester (WMF): you can't delete proposals you don't like. You can apply for the mop, but as it stands, you don't have a mop. So you can't mop up threads you don't like.
We can vote on this. If this proposals passes and WMF decides to ignore us, that'll be different matter. You shouldn't silence us at this stage. @Gone Postal: you wanted to comment I think? - Alexis Jazz ping plz 19:49, 25 January 2019 (UTC)
@Alexis Jazz: Please read m:Limits to configuration changes. This farce of a proposal is a massively disrespectful waste of fellow volunteers' time. Please, withdraw it. Jdforrester (WMF) (talk) 19:52, 25 January 2019 (UTC)
@Jdforrester (WMF): I see a farce alright. Developers who are hell-bent on supporting dead browsers without any way to propose a change to that policy. That's a farce alright! We can vote on this, even if you'll ignore us. We should work together, but your stance makes that impossible. - Alexis Jazz ping plz 20:04, 25 January 2019 (UTC)
@Alexis Jazz: Also, in a personal capacity, I very much do have the mop, as you put it. Obviously as I'm professionally engaged here I'm not going to involve myself personally, but please be more aware when you dismiss others' points of view. James F. (talk) 19:57, 25 January 2019 (UTC)
So you should have used your administrator account. You can't expect me to search for alternative accounts. But this only makes it worse. - Alexis Jazz ping plz 20:04, 25 January 2019 (UTC)
Let's not place admins on a pedestal, or are you referencing that only admins can close discussions here? His actions were done as a Wikimedia developer 👩‍💻, an actual admin who administrates the software we use. But now that we're on this discussion anyhow, @Jdforrester: would there be a way that those files could be imported without breaking browser support? Maybe by letting people who use those browsers not be able to view those files if that is technically possible. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:38, 25 January 2019 (UTC)
@Donald Trung: "or are you referencing that only admins can close discussions here?" indeed, I don't see any scenario in which a valid proposal (which means: something that can be voted on, not vandalism or a question that may be moved to the help desk) would be closed by a non-admin. Let alone deleted. That would be reserved for vandalism. Jdforrester actually turning out to be an admin only makes his action worse. - Alexis Jazz ping plz 20:59, 25 January 2019 (UTC)
@Alexis Jazz: I've already told you that the discussion was not deleted, please stop using that term. Nick (talk) 21:03, 25 January 2019 (UTC)
Technically speaking nothing is actually ever "deleted" on Wikimedia websites, just hidden from general view, you ("User:Nick") could view "deleted" files, but this is just a comment on semantics so everyone could ignore this comment. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:12, 25 January 2019 (UTC)
@Nick: if I removed your comment from this thread, you'd say I deleted it. - Alexis Jazz ping plz 21:46, 25 January 2019 (UTC)
@Alexis Jazz: No, I wouldn't. That's mainly because I know the difference between blanking and deletion of content. Nick (talk) 21:51, 25 January 2019 (UTC)
This is a serious breach of trust, being an act of apparent censorship, and is sufficient for a desysop request. Jdforrester is misusing their sysop privilages, and taking actions as a WMF employee that they should be held to account for under their ordinary sysop account. This means they no longer care to use their ordinary account and clearly do not need those privilages. A desysop vote would give plenty of space for Jdforrester to account for this action and how they believe it follows the Administrators policy.
I am away from my normal desktop, could someone please raise this on AN for pre-desysop discussion? Thanks -- (talk) 20:19, 25 January 2019 (UTC)
Please let's assume some good faith here, imagine if making such major changes to the MediaWiki software 👩‍💻 by exempting a single Wikimedia Wiki would force the developers to place it on a different development cycle or could potentially break compatibility or something. All I see is an expert bloke who develops the software we use as his job giving his expert insight into the matter and closed a thread in a rather unorthodox way. There is no need to attack either Jdforrester (WMF) the Wikimedia employee or Jdforrester the human being, let's discuss this all as adults, I'm sure that Jdforrester had good intentions with his edit. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:32, 25 January 2019 (UTC)
There was no administrator tool use involved, so there's nothing to request a de-sysop over, so no, no AN pre-desysop discussion I'm afraid. James removed a section, Donald Trung restored it. Bold, Revert, Discuss in action. Nick (talk) 20:34, 25 January 2019 (UTC)
@Donald Trung: realistically, to do this the useless security check would be made optional in the software so it could be disabled locally on any wiki. Which will actually be a great feature for MediaWiki, and Jdforrester should be thankful the community brings up these issues. - Alexis Jazz ping plz 21:10, 25 January 2019 (UTC)
I don't understand why it's apparently so important to the MediaWiki devs to keep supporting such outdated browsers and insecure. Google, for instance, stopped supporting IE6 in 2010 and IE7 in 2011 for its web apps. Surely it would be better to tell users still using those browsers to suck it up and upgrade instead of presenting them with a degraded experience and hamstringing the rest of us. clpo13(talk) 20:36, 25 January 2019 (UTC)
I suspect it's because Wikimedia Foundation wants to keep projects accessible to users with donated second hand IT equipment, as can be the case in developing countries. Nick (talk) 20:44, 25 January 2019 (UTC)
That's a fair point, which I hadn't considered. Still, even Windows XP can use IE8. clpo13(talk) 20:46, 25 January 2019 (UTC)
@Clpo13: Not to mention you'll be better off using Firefox. And if at all possible, install something like Ubuntu. IE8 support ended in January 2016. Actually April 2014 for IE8 on Windows XP. Firefox support on Windows XP ended in June 2018. Google Chrome support for Windows XP lasted until April 2016. The last Opera version appears to be from August 2016. Searching for what browsers might actually still be supported on Windows XP, I found Which linked an article with a title that's just brilliant: If You’re Still Using IE6 You Are A Problem. But really: if we disable this useless security check, is that going to cause people who still use IE6 or IE7 from collecting as much malware as will fit in their memory? I don't think so. They are vulnerable to everything and their mother, and files that get uploaded here are still scanned by a virus scanner, policed by the community and processed by the thumbnailer before being served on most pages. - Alexis Jazz ping plz 21:38, 25 January 2019 (UTC)
This is a rather extreme measure taken against Jdforrester (WMF) who was acting in good faith, could we please try to discuss this topics without resorting to emotion now?

As Jdforrester (WMF) is blocked now, could we address the technical issues why this thread was removed now? But as Jdforrester can still edit with his “personal account” I still want to ask him the technical motivations as to why a local exemption to this cannot be discussed. Supporting internet browsers is important and in order to let as many people as possible access the free knowledge we create here. But as Alexis Jazz stated on Phabricator ”According to @matmarex this is an issue in IE5-7. MS dropped support for IE7 entirely in April 2016. IE8 was released in 2009. According to, as of May 2012, estimates of IE7's global market share were 1.5-5%. According to the market share is now 0.16%.” which means that the MediaWiki software is supporting an unpopular unsupported internet browser, of course as was stated above donated second-hand equipment to developing countries would run these, but even on Windows XP Microsoft Internet Explorer 7 isn't the latest version of the Internet Explorer series of web browsers. Can browser support for these browsers not simply be tweaked to ignore these exceptions? From what I can tell these images cannot be uploaded because a line of code in their EXIF data tricks IE6 and IE7 into believing it is a security concern.

Another question, imagine even if the Wikimedia Commons community would vote to (locally) drop support for these ancient browsers, would the Wikimedia developers actually be forced into making this exception? Or is this closer to a non-binding (advisory) referendum? It could just show the developers that some of their choices are hurting content creators, but could they actually implement these changes without also hurting the (very, very few) people who use Microsoft's Internet Explorer 6 and Internet Explorer 7 web browsers? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:48, 25 January 2019 (UTC)

"imagine even if the Wikimedia Commons community would vote to (locally) drop support for these ancient browsers, would the Wikimedia developers actually be forced into making this exception?" No. The developers, the wmf and the security team control the software, as you control images (commons) and articles (wikipedia). The communities provide input, no more. If you want to force something, you should become part of one of those three groups and convince the rest of the group. —TheDJ (talkcontribs) 23:28, 25 January 2019 (UTC)

Pictogram voting comment.svg Comment, as I just saw -revi's comment "I'm sure WMF will reject this. Don't waste your time. Bye. (I won't respond to remarks here. Also, NOTE: This comment is made 100% on a personal capacity.)" where the suggestion is made that the Wikimedia Foundation will reject this, wouldn't it be better if this discussion be closed? I deliberately closed this proposal after restoring it because having a proposal that goes nowhere (with good intentions) could only add bitterness. Although if a WMF developer could respond to this proposal it would be most welcome, as it would showcase that the community isn't actively being ignored. --Donald Trung 『徵國單』 (No Fake News 💬) ([[Commons:WikiProject Numismatics|WikiProject Numismatics]] 💴) (Articles 📚) 22:54, 25 January 2019 (UTC)

  • Establishing a consensus here is fine. It helps other groups focus on the issue, and consider alternative solutions, such as allowing upload to the WMF server, but filtering blacklisted elements from the EXIF before publishing to live. -- (talk) 23:49, 25 January 2019 (UTC)
  • I think it's good to have this proposal open. If the Commons community were to reject it, it would show the WMF and WMF developers that they are doing the right thing. If we accept it, they should start scratching their heads.
    On a technical note: The thumbnailer already strips nearly all text from the metadata, only the "copyright" field is retained. Technically, MediaWiki could generate a thumbnail and check the first kilobyte of the thumbnail instead of the first kilobyte of the uploaded file. If the WMF is truly concerned with supporting dead browsers, they could disable downloading of original files (as opposed to thumbnails) for IE6 and IE7 users. Note that anything that isn't the original file is a thumbnail in this context, this 1500 × 2359 image is a "thumbnail". This may all sound very convoluted, and it isn't the easiest of solutions (the easiest solution is the one proposed!), but it's infinitely less convoluted than anything Jdforrester suggested. - Alexis Jazz ping plz 00:11, 26 January 2019 (UTC)
  • Question: What security checks do modern browsers do to ensure that the EXIF cannot execute malicious code? How confident are we that these checks are universal across all browsers with significant current usage? -- King of ♠ 03:43, 30 January 2019 (UTC)
@King of Hearts: browsers use the MIME type. For files on your computer, the magic number and/or file extension could be used. Wikimedia takes care of using the right MIME type, files with a bad magic number of file extension are not allowed to be uploaded. IE6 and IE7 are essentially dumb in that they scan the first 255 bytes of any file for occurences of HTML tags and when found treat the file like HTML, including javascript. Presumably this was done as a workaround for webservers that were misconfigured. A workaround that really never should have existed in the first place. - Alexis Jazz ping plz 06:22, 30 January 2019 (UTC)
  • Colin above:

“The proposal makes no sense. Commons supplies images to other Wikimedia projects, so how would Commons having an opt-out, but other projects not, work? I have not seen anyone quote browser usage stats that actually apply to Wikipedia page views, vs views of some tech website. The proposal (and discussion on the other forum) are loaded with inflammatory language, and reflect a First-World tech-user viewpoint. Do we have any stats on how common it is for a JPG to have HTML embedded in the EXIF? I suspect we have all wasted more of our short lives on this mess than it deserves. By all means ask the developers for a fix/work-around, but the proposal here is pure political games IMO.”

— Colin in his vote
Because you're the expert when it comes to proposals. Still harboring a grudge over the GFDL thing? Which also only applies to Commons. Netmarketshare is not "some tech website". Later I also found the version-specific information on According to that, 0.8% uses IE6 and 0.2% uses IE7. But this proposal doesn't even ban those browsers (which their users could upgrade, less outdated browsers like Firefox, Chrome and IE8 are available for Windows XP) from Wikimedia projects. It merely skips a redundant check as the files are still scanned by a virus scanner and policed by the community and possibly bots. You ask for stats on "how common it is for a JPG to have HTML embedded in the EXIF". The question should be where the stats are on how common it is for a JPG to have malicious code embedded that is triggered by this behaviour in IE6 and IE7. Except even the answer to that question is largely irrelevant, because any security measure that is aimed exclusively at IE6 and IE7 is a huge joke. It's like installing smoke detectors in a house that's already on fire. If this check didn't exist and we were to propose implementing it today for some dead browsers, breaking uploads in the process, nobody in their right mind would support that. The proposer for such a thing may even have his mental sanity being questioned, and rightfully so. - Alexis Jazz ping plz 06:22, 30 January 2019 (UTC)
According to Brion on phab:T27707#4915179, IE6-8 on Windows XP fail to work anyway due to lack of SNI. So there goes any "but what about the third world" argument. Only IE7 on Vista is affected. Who the hell still runs Vista? No no no no correction: who the hell runs Vista, period? The answer is absolutely nobody, because after may 2018 it's market use on Wikimedia dropped below 0.1% and can't even be accurately measured anymore. And from that <0.1%, only the fraction that actually also uses IE7 counts. 0.00041789% of users in December 2018. Vista users can install IE8 or IE9. - Alexis Jazz ping plz 07:09, 30 January 2019 (UTC)
Do you think it is possible for you to communicate without making personal attacks and insults? The analytics show IE6 usage is 1.2% on 2018-09-30. That is a heck of a lot of people, if the stats are to be believed. Also, see Usage share of web browsers for why user-agent detection is not particularly reliable. But fundamentally, the proposal I opposed was "Create a local exception for Commons..." which makes no sense, as I said. Wrt how often JPGs have HTML EXIF, you have't answered the question. So basically, you are wasting everyone's time on a "problem" you haven't even quantified. The number of people/images with HTML EXIF represents people/images that can't be uploaded at present -- how many are we talking about. You say we should instead be worried about how common malicious code is? This represents a misunderstanding of security. On Monday there may be nobody using a given exploit, say. On Tuesday, your local NHS hospital computers are infected with ransomware. All it takes is one malicious file. Anyway, I'm unwatching this as life is too short for such nonsense. -- Colin (talk) 11:34, 30 January 2019 (UTC)
Colin, "it is possible for you to communicate without making personal attacks and insults?" You are the expert here... Alexis' analysis above and below is quite useful, so if you don't have anything useful, you better shut up. Regards, Yann (talk) 12:07, 30 January 2019 (UTC)
Yann, since you pinged me, where is your useful contribution to this discussion? Why do you even ask "if you don't have anything useful" when my post supplies information and asks perfectly valid questions? Why are we proposing this when we don't even know how much it bothers anyone? How would a Commons exemption work? The stats should be taken with a pinch of salt. However, the charts on that website seem broken since May last year for Windows versions. There is a tablular form which shows Vista at between 0.2% and 0.3% in the last few months. This page estimates 30 million unique devices accessed just en/de/fr Wikipedias each day. 0.3% of that is 90,000 Vista users every day. And 1.2% of that is 360,000 IE6 users every day.These are not small numbers. Unlike the number of JPGs this proposal is aimed at, which appears to be an imaginary number. I don't know if we can trust those user-agent numbers or any other numbers proposed here. Now, please don't ping me about this silly proposal again. -- Colin (talk) 13:01, 30 January 2019 (UTC)
30 million? Actually 23.3 million on avarage, but who's counting. 0.0004% Vista users with IE7 makes.. 93 users who actually aren't affected because Wikimedia serves files with the correct MIME type, file signature and extension. Oh, and their house is on fire. There's that. You know damn well there are no statistics for what you're asking, because how would one even collect those? We know the phabricator ticket was opened in 2010, so this already caused problems back then. We can search the exact error message, which will not show every instance of a user running into this, giving us 39 results. Most users probably won't even bother reporting it and just turn away and any reports that do not mention the exact error message in English are not found this way. - Alexis Jazz ping plz 13:28, 30 January 2019 (UTC)
I agree with Yann here. As for the reported IE6 usage, I can think of two explanations. One, it's falsified by some users for shits 'n giggles. Two, they are actual IE6 users who use a proxy that strips the S from https. What they do is not supported and their security is out of the window for too many reasons to explain. The 4 per million users, actually less when you subtract those who are not logged in, using IE7 on Windows Vista are also screwed, but not by this exploit, at least not on Wikimedia as it wouldn't be exploitable here anyway, with or without the security check we are discussing. - Alexis Jazz ping plz 12:43, 30 January 2019 (UTC)
  • Ghouston said:
“It's a bit hard to find information about this problem online, since it affects browsers that became obsolete in 2009 when a newer version of IE was released. Perhaps Microsoft even patched the bug in the old versions, if they supported them for several years afterwards?

I found an article which describes the problem and gives some interesting information. It only affects the browser when the user goes directly to the file, as in downloading, like It doesn't affect images when embedded in HTML pages.

Also, if the file extension, MIME type, and file signature (the first few byes of the file) are all in agreement, the browser won't do it's crazy scanning thing. I don't know what file extensions it accepts. It may be possible to disable the check for the problem is the file extension is good.

This is surely a bug that nobody would bother actually trying to exploit. Why go to the effort, when the chance that one of the users of these old browsers will actually visit the direct link of your file is practically zero? And all you can do is Wiki actions, which are reversible anyway.”
As Wikimedia serves the correct MIME type anyway, file extensions are restricted to a whitelist and invalid file signatures are also rejected, this exploit is basically not exploitable. Even if you were crazy and wanted to take advantage of basically nothing with this exploit, you couldn't. - Alexis Jazz ping plz 07:09, 30 January 2019 (UTC)

Discussion: Implementing changes without dropping support?[edit]

@:, I saw that you proposed implementing a change that would not necessarily have to force us to end supporting these ancient browsers left by a civilisation long passed, could someone from the Wikimedia Foundation confirm that this work around is possible? And could community members implement these without the help of the Wikimedia Foundation? That way everyone could leave this discussion pleased. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:47, 26 January 2019 (UTC)

You don't need someone from WMF to tell what's possible; WMF writes only a minuscule minority of our code. The EXIF could be sanitised when it's uploaded, sure, but if we did so in MediaWiki core we would be spending more resources on Internet Exploder rather than less. The easy way out it to implement a workaround in some upload methods, whichever are most likely to need it (if we find them; see above). Nemo 21:23, 27 January 2019 (UTC)
Yes, of course it's possible. It's not even technically a hard thing to write a Use Case for, which could then pin down how much programming and test time it would take to implement. Subscribe to Phab:T27707#4915036 if you want to track this happening off-wiki, though I recommend you do not write anything on that task, as the CoC could get you permanently banned from all projects if you appear "non positive" in any undefined subjective way as judged by a body that acts behind closed doors.
As for not needing the WMF to tell us what is possible, the "official" strategy here was to shut up the community, as, I guess, us volunteers have such massive egos that some of us believe we should have a voice and be able to reach a consensus for what improvements and changes should happen on our the WMF's project. -- (talk) 12:41, 29 January 2019 (UTC)

Fix SVG upload to remove bad SVG previews and to integrate SVG Checker into the workflow[edit]

The Problem: The standard workflow creates false previews of SVG files that aren't validated, resulting in buggy SVG uploads and user frustration. Workflow:

  1. Choose to upload an SVG file for use on wikipedia.
  2. When you've chosen a "Source filename" it shows a graphic preview of the file that you wish to upload. This preview is not accurate- it is using the browser to render the SVG file, which is not how Wikimedia renders SVG files into PNGs for use on wikipedia. The file is also not validated by wikimedia at this point.
  3. Your only option is then to execute the upload, which puts the file in the wikimedia server and initiates wikimedia PNG conversions that wikipedia uses for the Web site.
  4. Some minutes or hours later, your SVG has been converted to PNG files that are live on wikipedia and maybe full of rednering bugs.

The Solution: The workaround is to verify your file first using c:Commons:Commons SVG Checker. That tool shouldn't be a secret people need to find- it should be integrated into the workflow.

I think the best fix is to replace the file preview that appears after "Choose File" with a "Validate and Preview SVG" button instead, then have that button open the SVG checker on a new browser tab for the chosen file. This way wikipedia won't be showing false previews, the very useful svg checker functionality will be integrated into the workflow so people can find it, and people can still work as they do now without using the SVG Checker if they don't need it (e.g. for a typo fix).

Thoughts?--Efbrazil (talk) 23:22, 30 January 2019 (UTC)

One consideration is file size. In order to carry out validation, an actual upload must take place; and for some files this can introduce a very significant delay into the procedure. For instance, File:Turgot map of Paris - Norman B. Leventhal Map Center.jpg is 35,690 × 28,030 pixels for an actual file size of 853.45 MB, which at 8 Mbit/second would take around a quarter of an hour to upload. True, this is a JPEG and not a SVG - but SVGs can be large too, such as maps where the textual content (place name labels, etc.) has been done in the form of a path element. The uploader may not understand why, having selected the file for upload, they are then unable to fill in the rest of the form for some minutes. --Redrose64 (talk; at English Wikipedia) 10:36, 5 February 2019 (UTC)
Yep, that's why the upload for the SVG Checker is optional in the proposal. The keys are not showing the bad preview, and exposing svg checker as an option.--Efbrazil (talk) 18:19, 7 February 2019 (UTC)

Proposal to run a bot to archive every external link using the Internet Archive on Wikimedia Commons[edit]

(Prior discussion Commons:Bots/Work requests#Internet Archive preservation of external links.)

The Wayback machine already works on most major Wikimedia websites.

Dear fellow contributors,

I am proposing to let a bot run on every file on Wikimedia Commons and other relevant pages which utilise external links and archive these links using the Internet Archive for future reference in the same way it is currently done on many other Wikimedia websites. This will allow for license reviewers and re-users to have a point of reference files from external sources as linkrot may obfuscate their original licenses and make it harder to verify them.

For a good (current) example where a changed source page is affecting the license of formerly free files please see "User:Alexis Jazz/DWDD archief". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:13, 5 February 2019 (UTC)

Votes (archiving external links)[edit]

  1. Symbol support vote.svg Support, obviously as the proposing agent. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:13, 5 February 2019 (UTC)
  2. Symbol support vote.svg Support This seems useful. --Yann (talk) 11:39, 5 February 2019 (UTC)
  3. Symbol support vote.svg Support Good idea. - Alexis Jazz ping plz 11:54, 5 February 2019 (UTC)
  4. Symbol support vote.svg Support, I hope they can handle the traffic.   — Jeff G. please ping or talk to me 12:27, 5 February 2019 (UTC)
  5. Symbol support vote.svg Support - Sounds like a great idea!, Although somewhat unrelated I run this tool all the time at EN (which can replace all dead and alive links with WebArchive) - As noted above given licences can and do change I would support this little gem. –Davey2010Talk 20:34, 5 February 2019 (UTC)
  6. Symbol support vote.svg Support. Archive should be done within minutes. This is also useful for Iranian websites which publish content, but occasionally remove them within hours (sometimes at the behest of "censorship office"). For example see File:Pir Shalyar 20190202 06.jpg which no longer can be license-reviewed. Neither Google cache [1] nor Bing cache [2] nor Internet Archive [3] could save the work in time. File:Mahnaz Afshar 20190201 01.jpg is another example which was fortunately saved using Google cache. In this case the problem was apparently violation of dress code. 4nn1l2 (talk) 08:43, 6 February 2019 (UTC)
  7. Symbol support vote.svg Support Common sense idea. This also will help prevent DRs and "no source" tagging. Abzeronow (talk) 14:52, 6 February 2019 (UTC)
  8. Symbol support vote.svg Support This consensus helps to ensure that later housekeeping or bot maintainers can more easily handle complaints, related to what is likely to affect millions of files. Where there are specialized issues, such as "hot" websites where the quoted source is at risk of being taken down, these may need bot tasks negotiated that periodically rerun. For very large stable collections, like Geograph or the British Library, these can run relatively slowly as background maintenance, and it hardly matters whether a new upload waits to have its links added to WBM for a few months. -- (talk) 12:03, 9 February 2019 (UTC)
  9. Symbol strong support vote.svg Strong support yes please. --Jarekt (talk) 12:59, 12 February 2019 (UTC)
  10. Symbol support vote.svg Support and for robots sites [4] go to -- Slowking4 § Sander.v.Ginkel's revenge 14:12, 12 February 2019 (UTC)
  11. Symbol support vote.svg Support This would be a good prevention of linkrot. De728631 (talk) 20:53, 12 February 2019 (UTC)

Discussion (archiving external links)[edit]

How should this best be implemented? Is the page "User:Fæ/Wayback" developed by a good model? Personally I propose "[EXTERNAL LINK] (ARCHIVE, retrieved: DD-MM-YYYY)". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:13, 5 February 2019 (UTC)

@Donald Trung: "{{Wayback|url=http%3A//|date=20150316101047}}" (implemented as "archive copy at the Wayback Machine (archived on 16 March 2015)" on File:143, Sverige, Stockholm, Roslagsbanans depå (Trainpix 122696).jpg) is standardized and looks nicer, you can discuss on Template talk:Wayback if you disagree.   — Jeff G. please ping or talk to me 12:38, 5 February 2019 (UTC)
@Jeff G.: indeed, that looks way better, and having a standard template for Internet Archive Wayback Machine links would also make it easier to be consistent. Face-smile.svg I honestly wasn't aware of the existence of "{{Wayback}}", this would make implementing the above proposal easier as well. Face-grin.svg --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) ill have (Articles 📚) 12:48, 5 February 2019 (UTC)
Though some earlier wayback additions were the links only, and others like Fortepan have the WBM link added as part of a specialized collection template, the largest collection so far, the Portable Antiquities Scheme uploads are using the preexisting wayback template. See File:BUCKLE_(FindID_187883).jpg or File:Cavalry Soldiers rehearse live-fire exercises with Lithuanian partners 141118-A-QS211-838.jpg for examples of how this looks. -- (talk) 11:57, 9 February 2019 (UTC)

I do not understand the proposal. Are we voting on something that will be done on the Wayback-homepage? --Schlurcher (talk) 12:47, 10 February 2019 (UTC)

@Schlurcher:, this proposal is so that all external links could be backed up using the Wayback Machine using a bot, this would create a snapshot of the external website which future people could use to confirm the licenses of files. For example I import a photograph from (example website) but then this website disappears a year later, a license reviewer then tries to confirm the license but can't, now this image will have to be deleted because its free license can’t be confirmed (see “COM:PCP”), now if this external website was backed up using the Internet Archive this file would not have to be deleted. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:04, 10 February 2019 (UTC)
@Donald Trung: or you could use some examples that actually happened: Commons:Village pump#License reviewers and admins help is needed ASAP (we got lucky with that one and everything could be reviewed in time), Category:Images from and Category:Photographs by Agencia Brasil. - Alexis Jazz ping plz 21:36, 10 February 2019 (UTC)

Speedy revision deletion tag for overwritten files[edit]

There is currently no standard way to ask administrators to delete a specific revision of a file (revision deletion) that's been uploaded in violation of Commons:Overwriting existing files. Such revisions are typically copyright violations (and even if they're the overwriter's own work, there is normally no licensing statement for the specific revision), so history splitting is hardly ever a viable option.

One way to request deletion is to write a message on the administrators' noticeboard. That gets the job done, but starting a section on a discussion board that's on a lot of people's watchlists for routine housekeeping isn't exactly a streamlined process. Starting a deletion discussion is also possible, but is even more process heavy and too slow to be fit for this purpose. Another way to do it is {{speedy}} with a custom message, but with overworked administrators, that can lead to more than just individual revisions being deleted. It would be better to have a more specific tag.

I believe that we should have a tag similar to {{Non-free frame revdel}} for this purpose. We could call it something like {{Overwritten revdel}}. It should put files into a separate subcategory of Category:Candidates for revision deletion, e.g. Category:Overwritten files requiring revision deletion. The tag should be limited to cases where the revision to be deleted is completely different from the original revision. Furthermore, the revision to be deleted should either be a copyright violation or lack the information necessary to enable history splitting. LX (talk, contribs) 19:29, 5 February 2019 (UTC)

Votes (overwritten revdel)[edit]

Symbol support vote.svg Support as per above discussion. --Yann (talk) 07:58, 6 February 2019 (UTC)

Discussion (overwritten revdel)[edit]

Pictogram voting comment.svg Comment The maintenance category already exists. I even put some files in it half a year ago. We don't need a tag (which is only more cumbersome to remove), someone just needs to watch that category. - Alexis Jazz ping plz 19:36, 5 February 2019 (UTC)
I don't oppose the general idea, but I don't think a tag is needed. Administrators just need to made aware of the category. - Alexis Jazz ping plz 13:19, 6 February 2019 (UTC)
Sometimes you need to explain the reason of revdel. Tags can be useful in this case. 4nn1l2 (talk) 13:28, 6 February 2019 (UTC)
For the cases that need that, I think a message could be left in the edit comment or upload comment. But I won't oppose a tag. - Alexis Jazz ping plz 15:21, 6 February 2019 (UTC)
Comment - I would support this - I've always been surprised there's no sort of policy on this, Me and Alexis have both photoshopped a few images here together (I believe 2?) and only 1 was revdelled which was only because I asked an admin to do it otherwise it wouldn't have been, Anyway I would support this. –Davey2010Talk 20:30, 5 February 2019 (UTC)
By the way, Media with unacceptable data in old versions awaits some reasonable procedure for some 1½ years. Incnis Mrsi (talk) 20:34, 5 February 2019 (UTC)
Fact of the matter is that if it is not listed on Commons:Admin backlog it is never going to be looked at. I doubt many admins even know those categories exist. --Majora (talk) 04:29, 6 February 2019 (UTC)
Pictogram voting comment.svg Comment I would also support this.   — Jeff G. please ping or talk to me 07:15, 6 February 2019 (UTC)

Do we want to bot-copy descriptions to captions?[edit]

Structured Data on Commons released its first feature last month: media files can now have captions in different languages. Captions are quite close to descriptions, except that they are structured by language. It is technically possible to bot-copy descriptions to captions (e.g., [5], [6] were copied using pywikibot). There is a potential copyright issue here, in that captions are CC-0, which perhaps could be avoided by only copying short descriptions (say, under 200 characters) where they are sufficiently short/simple that they can't be copyrighted (as per WMF legal). Do we want to do that for all files, or are there other concerns that need addressing? Thanks. Mike Peel (talk) 21:15, 8 February 2019 (UTC)

Wait...why...are captions licensed under something different than almost the entire rest of almost every other project? (This might be a stupid question, I'll admit.) GMGtalk 21:20, 8 February 2019 (UTC)
@Keegan (WMF) can probably answer this better than me, but in general I understand it's because facts/short captions can't be copyrighted along the same lines as {{PD-simple}}/{{PD-ineligible}}. It matches what Wikidata uses, and there's some rationale on Wikidata. Thanks. Mike Peel (talk) 21:37, 8 February 2019 (UTC)
Indeed, captions are to be CC0 in order to work with the licensing for the rest of the structured data project, which is based on Wikidata's CC0. Captions are the Commons equivalent of a Wikidata label, meant to be pulled from the API with other data from other structured statements and fields once they are available. More information about why the database is CC0 is available in Mike's link. Keegan (WMF) (talk) 22:36, 8 February 2019 (UTC)
Ah. Stupid question confirmed. I've been poking around WD for a little while now and I honestly hadn't realized it was licensed differently. GMGtalk 23:06, 8 February 2019 (UTC)
Captions are stored on Wikidata and Wikidata is CC0 by design. So they have a different license. --Majora (talk) 21:38, 8 February 2019 (UTC)
No. WMF legal have given no guarantee of immunity against claims of damage from breaking moral rights. The idea that 200 characters cannot have a copyright holds no water. -- (talk) 21:34, 8 February 2019 (UTC)
No thank you. I'm not a big fan of this caption system to begin with. I'm not a big fan of storing data where it can't be controlled directly by the community that deals with it. --Majora (talk) 21:38, 8 February 2019 (UTC)
@Majora: The data is held on Commons (in the commons wikibase installation), not on Wikidata. Thanks. Mike Peel (talk) 21:46, 8 February 2019 (UTC)
Ah. Well they should probably make that more clear to people who haven't been following along with its development since I was under the impression it was stored elsewhere. I'm more neutral on this idea then. --Majora (talk) 21:48, 8 February 2019 (UTC)
@Majora: I have added a section in the FAQ answering this − hope that helps: Commons:File_captions#Where_are_captions_stored?. Jean-Fred (talk) 13:55, 11 February 2019 (UTC)
  • I Symbol support vote.svg Support this, short descriptions are everywhere on Wikimedia Commons and as we have 51.000.000+ (fifty-one-million plus) files on Wikimedia Commons without any captions this will do a large part of the work and save a lot of volunteers' time. It's a shame that we can't import all file descriptions but within the current restraints what Mike Peel is suggesting is the best option. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:37, 8 February 2019 (UTC)

GA candidate.svg Weak support Only if limited to short descriptions. Some descriptions are quite long and detailed, and there's nothing wrong with that - there is a lot of valuable information available for some images. But the captions have a different purpose as the "Commons equivalent of a Wikidata label", as Keegan wrote, the "one-line explanation of what this file represents", as the caption description says. So, even if not considering possible licensing issues, long descriptions should not be copied to captions. With a rule like "only the first sentence (text before the first full stop) and only if this sentence is not longer than 200 characters", I think it might be a possible approach. Gestumblindi (talk) 23:37, 8 February 2019 (UTC)

I'm just not sure this would work. For example, this caption is comparatively meaningless. This caption is equally so if only the first sentence is provided. GMGtalk 00:52, 9 February 2019 (UTC)
@GreenMeansGo: The first one would need human clean-up (currently in the description, after this proposal both in the description and the caption). The second one is 614 characters long, so the limit of 200 characters I proposed above would mean it wouldn't be copied over. (We could partially copy descriptons, but as you say that probably doesn't help.) Thanks. Mike Peel (talk) 11:08, 9 February 2019 (UTC)
  • No. Lots of crap in descriptions, liabled to just reproduce the crap. Arbitrary example: File:Terrible Trail, The Meek Cutoff - Flickr - brewbooks.jpg - Jmabel ! talk 00:58, 9 February 2019 (UTC)
    @Jmabel: So how do we clean the descriptions up? The example you've given is ~730 characters long, so over the 200 character cut-off I was suggesting. Thanks. Mike Peel (talk) 11:08, 9 February 2019 (UTC)
    I didn't spend a bunch of time searching for a precise example before posting, I was just trying to illustrate the sort of thing I meant, but here:
    The only way to clean this up is for someone to do the hard work of cleaning this up. I do that a lot on photos I think are of historical interest or likely to be used; otherwise, frankly, when dealing with other people's photos I usually stick to cleaning up categories and usually don't go near the descriptions unless they are actively inaccurate. (Would normally have fixed that "Elliot Bay" one, but I'm leaving it right now as part of making my point.) - Jmabel ! talk 16:11, 9 February 2019 (UTC)
  • Pictogram voting comment.svg Comment The idea is not bad in itself, but note that there is a kind of inadequacy between the fact to notice to the uploader about the license of the structured content, and the fact to copy the content that they did not deliberately put in the structured content area. There is something a little hypocritical in that, it is like we say : "be aware that the structure datas are under CCO, but anyway, and without you agreement, we will copy your CC-BY-SA 3.0 contribution to this CC0 field." Christian Ferrer (talk) 05:48, 9 February 2019 (UTC)
+ I have serious doubt that all the descriptions are simple enough to be exempt from copyright protection, example File:Gashnian 20170306 18.jpg, I don't think we can move this text that is originally licensed under BY to CCO. Christian Ferrer (talk) 06:09, 9 February 2019 (UTC)
@Christian Ferrer: That caption is 646 characters long, so the maximum length of 200 characters I suggested at the start would exclude that one from being copied. Thanks. Mike Peel (talk) 11:08, 9 February 2019 (UTC)
This text could be limited to the first 200 characters, it wouldn't be less copyrightable IMO. Christian Ferrer (talk) 11:18, 9 February 2019 (UTC)
@Christian Ferrer: My suggestion was that if the description is over 200 characters, then it wouldn't be copied at all. I wasn't suggesting only using parts of descriptions. Thanks. Mike Peel (talk) 11:24, 9 February 2019 (UTC)
@Mike Peel: yes I understood, I say only that a 200 long characters text may also have a copyright. Example my own comment that you are currently reading and that is under CC-BY-SA 3.0. Who can say that this comment is CC0? Christian Ferrer (talk) 12:06, 9 February 2019 (UTC)
Though it's true that the persons who are writting descriptions are certainly less creative than I'm trying to be right now.... :) Note that I do not oppose, I simply speak. And it's true that a lot of descriptions are very simple, even too much simple sometimes, lacking of useful infos. Christian Ferrer (talk) 13:54, 9 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose I would like to have a separate description in the structured data, where the old descriptions can be copied. If the Captions should be bot-filled, then with the title of the image. --GPSLeo (talk) 10:05, 9 February 2019 (UTC)
    @GPSLeo: You mean at Commons talk:Structured data? Feel free to start such a discussion. Thanks. Mike Peel (talk) 11:08, 9 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose A note of nit picking but unfortunate reality here, in follow up to my earlier "no". If I see any of my batch upload projects where this is being done, I plan to mass revert on copyright grounds per COM:L, unless the text is specifically and unambiguously released as CC0 at source. This includes metadata such as titles, descriptions or captions. Anyone populating CC0 captions has the burden of proof to ensure that the text has been correctly released. The claim at the start of this thread that this statement may make copying text of certain lengths into captions okay, is misleading. Keegan (WMF) (talk · contribs) does not write for WMF Legal and does not claim to be a lawyer or a legal academic, so please avoid quoting what they write as if it has legal weight for the WMF, or is a meaningful legal opinion that unpaid volunteers could use to protect themselves from future claims of damages. If anyone wishes the WMF Legal department to publish an opinion that could be taken into a courtroom, then ask them for one in writing. -- (talk) 14:42, 9 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose concerns (raised above). --Steinsplitter (talk) 14:44, 9 February 2019 (UTC)
  • Pictogram-voting-question.svg Question @Mike Peel: is it possible to insert a caption in wikitext? Like {{Information|Description={{Caption:en}} or whatever. - Alexis Jazz ping plz 16:48, 9 February 2019 (UTC)
    • @Alexis Jazz: Not yet, I'm hoping that's coming later this year. @Keegan (WMF) may want to comment on this. Thanks. Mike Peel (talk) 19:07, 9 February 2019 (UTC)
      • @Mike Peel: In that case I oppose as well. Don't want to see information being duplicated. That will only lead to things like this. When captions can be inserted with wikitext, another vote would be welcome. - Alexis Jazz ping plz 19:25, 9 February 2019 (UTC)
      • @Alexis Jazz: So to clarify, you would be happy with moving descriptions to captions, but not copying them? Thanks. Mike Peel (talk) 19:36, 9 February 2019 (UTC)
        • @Mike Peel: To clarify, I completely oppose it when you would be exactly duplicating descriptions. For shortened descriptions this wouldn't apply as those are not exact copies. I'm not sure yet I will be happy with moving descriptions considering the other issues that were brought up in this thread. I don't immediately oppose that though, but as long as the captions can't be inserted using wikitext, I think a proposal is actually premature. - Alexis Jazz ping plz 19:42, 9 February 2019 (UTC)
  • I don't quite think it's appropriate to add to captions while the giant white box is getting in the way of users' access to the file description. First it needs to be hidden, reduced, floated to a side or whatever. Nemo 17:09, 9 February 2019 (UTC)
    • @Nemo bis: Are you suggesting to enable the "Compact Captions" gadget by default? - Alexis Jazz ping plz 17:43, 9 February 2019 (UTC)
      • I'm not a fan of collapsing. Whatever the vertical size, it's harmful if it pushes down the information template/the description while taking the whole width of the page (usually for nothing). Nemo 22:01, 9 February 2019 (UTC)
  • Regretful Symbol oppose vote.svg Oppose. I don't think it's legal. It's true that common phrases and similes are not covered by copyright, as they are seen as the building blocks of the language, capable of being reused and repurposed in many different transformative ways. Also in cases where there's a substantial chance there was coincidental independent creation. But, regettably, neither of those grounds apply here, for a systematic programme of extraction and licence-washing of individuals' contributions that are specific to particular contexts, being taken for the exact same purpose and exact same context; for some contributors cumulatively amounting to tens of thousands or even hundreds of thousands of words. One cannot argue that a taking on such a scale and so systematic is just incidental. If the descriptions are licensed CC-BY-SA one can't just wave that away and claim that they can be reissued CC0. Therefore, regrettably, IMO the existing descriptions cannot be reused unless they have been licensed CC0, or are directly derived from sources that are PD or CC0. Jheald (talk) 22:26, 9 February 2019 (UTC)
@Jheald: You entered 5 tildes instead of 4. - Alexis Jazz ping plz 22:32, 9 February 2019 (UTC)
Thx. Fixed. Jheald (talk) 22:42, 9 February 2019 (UTC)
  • Mike Peel, I'm confused how the captions can be CC0 if created automatically from a non-CC0 licensed work or a public domain work. The CC 0 legal code requires the "affirmer" to "voluntarily elect" to apply CC0 terms to "his or her Copyright and Related Rights in the Work". If the work is already in the public domain (for example, deemed not eligible for copyright) then there is nothing for which CC0 applies and the PD mark would be more appropriate. If one's work is under copyright, nobody else can put the work under CC0 terms on your behalf. -- Colin (talk) 12:35, 10 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose I'm too worried about the copyright. Even for short descriptions. A single tweet would rarely be copyrightable. But if you collect thousands of tweets from one person, it becomes another story. @Mike Peel: I also find it very worrying that when users enter captions now, they are not informed about the CC0. This means all the captions that have been entered so far are licensed as BY-SA 3.0, not CC0. - Alexis Jazz ping plz 17:24, 10 February 2019 (UTC)
  • Symbol support vote.svg Support However lets do it after captions are properly marked as CC0. I would also start with short captions with clearly identifiable language. Short text (less than 5-10) words likely falls under {{PD-text}} and I do not trust templates like {{en}} to be correct. --Jarekt (talk) 13:35, 12 February 2019 (UTC)

Sample set[edit]

@Mike Peel: Can I suggest processing a batch of, say, 1,000 randomy-chosen images, and writing the proposed captions to a gallery page(s) in user space? Then we can all review them, and look for anti-patterns to avoid. You'll need to strip wikicode, for instance - or skip anything that uses it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:15, 9 February 2019 (UTC)

@Pigsonthewing: See User:Mike Peel/Captions for some examples. They are randomly selected, and the code only looks for labels marked with {{en}} and doesn't strip out any wikicode or HTML yet (that work would be done ahead of a bot proposal). Thanks. Mike Peel (talk) 19:55, 9 February 2019 (UTC)
Good idea, interesting. Almost should be ok, indeed, but a few cases are more debatable such as File:Distant County Hall - - 896433.jpg and the other files coming from Geograph project. @Clindberg: hello, have an opinion about the fact to apply a CC0 license to descriptions not under CC0 at their origin? Christian Ferrer (talk) 20:42, 9 February 2019 (UTC)
@Christian Ferrer: I don't think there is any way to safely apply CC0 to licensed description text. Short phrases are not copyrightable, but entire sentences could be, depending on the wording. If it's just bare factual information like date and place and subject there is probably no copyright, but I would think it would be possible for some descriptions (even short ones) to be copyrightable. Carl Lindberg (talk) 21:28, 10 February 2019 (UTC)
@Mike Peel: Thank you. Most look good. On images like File:Ishiguro Koreyoshi - Kozuka with Chrysanthemums - Walters 5112783.jpg and File:Zoophytes- 1. 2. Fongie Actinie. (Nouvelle-Irlande.); 3. 4. Fongie à gros tubrcules. (Vanikoro.); 5.- 9. Tubinolie rouge. (Nouv-Zélande.) (NYPL b13624459-1267199).jpg, the |title= should be captured, before, or instead of the description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:51, 9 February 2019 (UTC)
It's probably worth skipping audio files, too. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 9 February 2019 (UTC)
There are some line like ''Abstract/medium:'' 1 negative : glass ; 5 x 7 in. or smaller , with no filename. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:51, 9 February 2019 (UTC)
File:Beach handball at the 2018 Summer Youth Olympics – Girls Preliminary Round – RUS-ASA 29 (cropped 2).jpg didn't go well either. (caption: "lang=en") - Alexis Jazz ping plz 21:04, 9 February 2019 (UTC)
@Pigsonthewing, Alexis Jazz: Yes, there are improvements that can be made here. This was code that I wrote in 5 minutes, and as I said it just checks for {{en}} and the character limit I suggested at the start of this discussion. You can see the code at [7]. I can improve it if needed to do what you're suggesting and more - but I am only going to do that for code that I can then actually use to make edits here. Thanks. Mike Peel (talk) 21:45, 9 February 2019 (UTC)
@Mike Peel: I'd say: work on the caption-wikitext-inclusion thing first. There was opposition against captions in general from the start because nobody wants duplicated data and having to fix typos in two places. You have to learn how to walk before you can run. - Alexis Jazz ping plz 21:54, 9 February 2019 (UTC)
@Alexis Jazz: It's up to the structured data on commons team to sort out the ParserFunction/Lua access to the captions, I can't do anything to help with that. On the other hand, we have captions now, so we can start to use them, and that's a good step forward. Copying the description to the captions is a start, then we can figure out including them in {{Information}}, {{Wikidata Infobox}}, and elsewhere, as the next step. Thanks. Mike Peel (talk) 22:06, 9 February 2019 (UTC)
@Mike Peel: I disagree about the order. Get caption-wikitext-inclusion working first so duplicate descriptions/captions can be avoided. If you were to start copying now, it'll just create a mess when caption-wikitext-inclusion becomes available but the descriptions/captions are no longer in sync because users have edited one but not the other. - Alexis Jazz ping plz 22:22, 9 February 2019 (UTC)
Do you have any evidence that doing that is planned? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:32, 9 February 2019 (UTC)
Users edit descriptions all the time. You're saying they will stop doing that if descriptions are copied to captions to avoid them becoming desynchronized? - Alexis Jazz ping plz 17:20, 10 February 2019 (UTC)
No; I'm asking you what evidence you have, that "Get caption-wikitext-inclusion working " is planned. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:51, 13 February 2019 (UTC)
  • Within the example set are seven files from the Portable Antiquities Scheme, we are current approaching 500,000 files from there. All the metadata is CC-BY-3.0, and so none may be reused as CC0. -- (talk) 22:43, 9 February 2019 (UTC)
  • Within the set are nine files from the Fleuron project, the batch made for an interesting image processing experiment of 250,000 files. The metadata relies on a Gale database, where the database rights are reserved. Clearly, systematically extracting any part of data and republishing as CC0 would break the expectation of limiting reuse, effectively by creating a new CC0 database with no attribution being preserved back to Gale. -- (talk) 22:57, 9 February 2019 (UTC)
  • Within the set are a significant number of files from Flickr, where the sources are not released as CC0. The licenses at source, such as the frequent default of CC-BY-2.0, must be presumed to apply to the metadata including the given titles and descriptions. Recasting these as CC0 cannot be supported as being compliant with their original releases. -- (talk) 23:10, 9 February 2019 (UTC)
    • I can't reply to any of these as the comments are too vague to let me investigate them, plus I am not a copyright lawyer. Mike Peel (talk) 23:16, 9 February 2019 (UTC)
      • Not expecting a solution, raising as very large collections which illustrate why auto population of CC0 captions is a non starter. Something that seemed obvious to me when captions were rolled/driven out without copyright issues being properly discussed. -- (talk) 23:28, 9 February 2019 (UTC)
      • "Not expecting a solution" - so that was entirely pointless then. Mike Peel (talk) 23:33, 9 February 2019 (UTC)
        • "illustrate" does not equal "pointless" unless you are unable to let evidence change your viewpoint. -- (talk) 10:46, 10 February 2019 (UTC)
    • I remain to be convinced that a simple, factual description like "A silver hammered penny of Edward the Confessor, minted in Southwark between 1042 and 1044. Moneyer: Wulfwine." can be copyrighted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:30, 9 February 2019 (UTC)
      • Looking at its source page at the BM, I suspect that such a caption reflects exactly the sort of knowledge and judgment and choice of expression that represent scholarship that can be protected by copyright, especially if the proposition is to similarly take 10,000 more such descriptions.
        None of the information given "of Edward the Confessor", "minted at Southwark", "between 1042 and 1044", "moneyer: Wulfwine" is obvious just from looking at the image. Even the term "silver hammered penny" represents a judgment, and a choice of description.
        I think you are on quite treacherous ground, to assert that there is no copyright here. Jheald (talk) 00:20, 10 February 2019 (UTC)
  • Pictogram voting comment.svg Comment Look at Text & Data Mining; This is not exactly the same thing but somewhat a bit similar topic in the extend that we talk about structured datas. Christian Ferrer (talk) 06:00, 10 February 2019 (UTC)
  • Note that some captions have already been manually copied from the descriptions by users who are not the descriptions authors. Christian Ferrer (talk) 07:52, 10 February 2019 (UTC)
    • Yeah, this is a good point Christian and gets at the deeper issue here. Even if a bot wouldn't be right for this task, we could easily semi-automate it to allow for rapid-fire manual checks for meaninglessness or other problems. But the real issue is that even if we do neither, it is deeply intuitive to simply copy/paste the existing descriptions, and will likely be done on a large scale, even if it is done piecemeal and manually across the entire project.
      Now I don't claim to be the most experienced user in the history of Commons, but I've been generally aware and even slightly involved in the ongoing discussion about structured data. I had no idea whatsoever that captions were licensed differently than descriptions until this discussion. The reason for that is probably that there is no indication whatsoever either in the upload wizard or on the file pages that these are licensed differently. That's a problem, and on such a copyright savvy project as Commons, it's a little surprising that we've implemented a system where users are shadow-licensing their content with no notification or explanation. The implication of that is that these contributions aren't actually licensed under CC0, because no notification means no license. GMGtalk 13:50, 10 February 2019 (UTC)
      • "WE" have not implemented this. We, the community, have not agreed anything about captions. The rationale that some discussion on a Phabricator task can replace a Commons community consensus is bizarre and simply a convenient fiction to justify a WMF desired change. The problem with literally mass ripping metadata from Wikimedia Commons and pretending that it has no copyright, has always been a foundational and extremely obvious logical conflict with the structured data proposals. But hell, who am I, I just have opinions based on years of creating content on this project, but as I've never been paid for it, my voice can be safely marginalized. -- (talk) 13:59, 10 February 2019 (UTC)
        • Well, even if we didn't implement it, we need to fix it, because without any type of notification whatsoever, the entire enterprise is basically just copyfraud. I mean, it's possible that I'm missing something obvious here, but it seems pretty straightforward. GMGtalk 14:10, 10 February 2019 (UTC)
          • Kind of missing the point. We, the community, do not own it. We do not get to say how it works. It is not ours to "fix", so why try? Frankly apart from being annoyed, I have been given zero incentive to care about this change, or to help with using this badly thought out and badly implemented "feature". The single option I have been given is to hide it from my view rather than remove it until it might be acceptable. Somehow that has been politically spun as being positive.
            Consequently, maybe we need a legal case, or a "WMF copyfraud" bad PR incident, to get the WMF to care when we ask for a change, or we politely suggest that the WMF properly tests major changes before rolling them out on what they think is "their" project. -- (talk) 14:30, 10 February 2019 (UTC)
  • Note that we can also try to go further by steps, there is mainly two types of content here : the "own works" and the content coming from external sources, you can begin with the "own works" :
1/ send a mass message to all the "own works" uploaders (or to all users), and notice to them that we are starting to copy the descriptions to the captions for the files tagged as "own work", and that there is a license change for the text coming from the description, and that they can object if they wish, and then you will proceed to an announced date
2/ or proceed all "own works" without sending any messages, assuming that there are normally no copyright infringements in the "own works" descriptions
3/ create maintenance categories such as Category:Media with captions or/and Category:Media without captions or/and Category:Media from external sources without captions, ect, ect...

That is just ideas, I don't know if it is the good way. Christian Ferrer (talk) 18:08, 10 February 2019 (UTC)

Fix the captions licensing[edit]

As we have seen in the proposal above, file captions are licensed as CC0. However, users who enter captions are currently not informed about this. At all. They also copy descriptions to captions, but descriptions often have a different license. In general, we can assume all captions that have been entered so far by users who are familiar with Commons are licensed the same as the proposal I'm writing now and all wikitext here: Creative Commons BY-SA 3.0. (lawyers may want to debate this, but for regular Commons users this is nitpicking) Captions that were entered by users with few edits, sadly no.

The Commons community in general has limited leverage over these development decisions, but we do have some. So here is a proposal, without hurting the developers too much, as they are given a choice. The proposal is this: one of the following should be done:

1. Delete all file captions that have been entered so far from the database. Inform the user clearly that the captions they enter will be released as CC0, similar to the message above the "Publish changes" button when editing wikitext. Also, create a system that will prevent users from mass copy-pasting file descriptions to file captions. Considering the license difference, they will generally need to rewrite the description in their own words for the file caption.. at least.


2. Delete all file captions from IP-users and users with few edits, as they may not be sufficiently aware of wikitext licensing. Change the license for the remaining file captions and future captions to Creative Commons BY-SA 3.0.


3. The developers disable captions for now, have WMF legal actually look at the whole thing and enable it again with permission from legal in whatever form legal deems appropriate.

So they have three options. A complicated one if they must have CC0, a more simple one if they switch to BY-SA 3.0 or they battle it out with legal. This vote is not for which option the developers should pick. This proposal is merely saying the developers have to pick one of them. - Alexis Jazz ping plz 22:48, 10 February 2019 (UTC)

Voting (fix the captions licensing)[edit]

  • Symbol support vote.svg Support, obviously. - Alexis Jazz ping plz 22:48, 10 February 2019 (UTC)
  • Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 22:59, 10 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose I don't think we should be deleting captions because of this issue. Option 2 if we had to do that sounds the least disruptive though. Honestly, WMF is not going to stop captions, that would be a waste of thousands of dollars to them. Abzeronow (talk) 23:16, 10 February 2019 (UTC)
  • Symbol support vote.svg Support, I was not aware of the different license. This is an issue. --Schlurcher (talk) 09:09, 11 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose all three options. Go discuss things at Commons_talk:Structured_data#CC0_licensing_mockups first. Mike Peel (talk) 12:54, 11 February 2019 (UTC)
  • Symbol oppose vote.svg Option 1, Symbol oppose vote.svg Option 2, Symbol support vote.svg Option 3, note that I am against any form of deletion, only if the legal department of the Wikimedia Foundation believes it to be necessary could I (very, very reluctantly) support it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:38, 11 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose There are few things that are more annoying than deletion of your work. If I do a sloppy job researching some file license and it gets deleted than I am the only person to blame. However if I was adding many captions and someone deleted all my work because I was not properly notified that my edits were CC0, I would be very pissed. I think lack of proper notification at the rollout of a new product is much less of an issue than deletion of someone's work. That said I hope proper CC0 marking of captions is added soon. --Jarekt (talk) 13:23, 12 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose not broken do not fix. Slowking4 § Sander.v.Ginkel's revenge 14:07, 12 February 2019 (UTC)
  • Symbol support vote.svg Support Of course it's broken. To deny otherwise is equivalent to closing your eyes and going "La la la, copyright can't touch me, la la la". One thing Brexit should have taught everyone by now, is that asking everyone to "believe harder" is not a good way to handle reality. -- (talk) 14:37, 12 February 2019 (UTC)
  • Symbol support vote.svg Support This project is a disgrace. Jürgen Eissink (talk) 02:10, 14 February 2019 (UTC).

Discussion (fix the captions licensing)[edit]

  • Pictogram voting comment.svg Question Wouldn't it just be easier to modify one of the interface displays, say MediaWiki:Wikibasemediainfo-entitytermsforlanguagelistview-caption, to read Captions (Note: All captions written in this box are released under the Creative Commons CC0 1.0 Public Domain Dedication). That way what is happening is clear to everyone who sees that box? --Majora (talk) 22:54, 10 February 2019 (UTC)
    Well I boldly tried it. Unfortunately interface displays apparently can't use wikimarkup. So the small tags actually displayed and the external link did not format. Still a possibility to fiddle with one of the interface messages to make sure people know what they are doing when they use the captions box. --Majora (talk) 23:03, 10 February 2019 (UTC)
    @Majora: I'm not sure how that would look, but perhaps that could be part of the solution. But that message would also need to be translated in many languages. And it would still leave us with the captions that have already been entered. And I'm guessing some users will ignore the message and copy descriptions anyway, so something should be put in place to prevent that. Informing users about the captions license will be needed, whichever path is chosen. - Alexis Jazz ping plz 23:14, 10 February 2019 (UTC)
    Well I'm working on the beta cluster to see if I can get anything that actually looks proper. We can always use the translations of MediaWiki:Wikimedia-copyrightwarning if I can get the actual formatting correct. --Majora (talk) 23:18, 10 February 2019 (UTC)
    Don't think this is going to work, unfortunately. There just isn't enough options to change that would make this doable and the only option that would be viable doesn't want to display URLs in any readable fashion. Oh well. --Majora (talk) 23:32, 10 February 2019 (UTC)
  • @Abzeronow: the developers can pick any of the three options they like. The third option is to take it to legal. If legal says they don't have to delete anything, well, that's fine. - Alexis Jazz ping plz 23:25, 10 February 2019 (UTC)
    • This might be a dumb question, but why not a fourth option to change license of wikitext to CC-0 instead of CC-BY-SA? Abzeronow (talk) 23:30, 10 February 2019 (UTC)
      • We can't retroactively change a non-CC0 license to CC0 without the permission of the copyright holders. That would be voiding their copyright. --Majora (talk) 23:32, 10 February 2019 (UTC)
        • Also it would be quite the feat. Few wikis have changed their license. English Wikinews has (is now CC BY), and Wikidata is obviously CC0. It's not impossible, but it would only be valid for new contributions. Go figure, we haven't even updated to Creative Commons 4.0 yet. Another issue are imported descriptions, like those from Flickr. - Alexis Jazz ping plz 23:44, 10 February 2019 (UTC)
          • Obviously, Commons should live up their name and going forward change to CC-0. I guess some sort of permission and/or fair use rationale will have to suffice in the meantime though. Abzeronow (talk) 17:09, 11 February 2019 (UTC)
Here's an actual alternative to deleting current captions.

Mass-deliver an electronic letter to the talk pages of everyone who created a file caption before the Creative Commons 0 (Zero) license is launched and inform them that they can opt into releasing their file captions with the Creative Commons 0 (Zero) license or otherwise they will be deleted. This opt in system could also work for Mike Peel's proposal above for {{Own}} files. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:55, 11 February 2019 (UTC)

Alternatively, every file caption added before a certain date could be could have a "{{Caption before March 2019}}" license or something template added to them stating that the caption is released under a different license. Nah, bad idea as these file captions can still be edited and changed and others could be added confusing re-users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:55, 11 February 2019 (UTC)

"Delete all file captions from IP-users and users with few edits, as they may not be sufficiently aware of wikitext licensing. Change the license for the remaining file captions and future captions to Creative Commons BY-SA 3.0." This is a very odd proposal, this applies to literally all licensing on Wikimedia Commons and it would make no sense to delete their contributions if they are going to be released under the same license as the rest of the website is. This is like saying "let's delete all Wikipedia articles by new users and IP-users because they might not be aware of what license they might be using", not everyone is Marco Verch and I highly doubt that the users with few edits and IP-users thought that they would retain full copyright © for their additions. Also this wouldn't "change" the license but retain it because as far as anyone us concerned all text (including file captions) on Wikimedia Commons is Creative Commons BY-SA 3.0. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:15, 11 February 2019 (UTC)
Pictogram voting info.svg Info There is already a patch just needing to be reviewed, for adding the license information for structured data to the footer --GPSLeo (talk) 11:22, 11 February 2019 (UTC)

  • Pictogram voting comment.svg Comment We need to do something. I'm inclined to say we should disable the entire thing for now regardless until we figure out what that is. If there's anything I have a strong opinion about it's that we should abandon the notion that we are currently dealing with captions that are licensed under CC0, because they're not. We don't currently know what the licenses actually are, but presumably some proportion of them are not freely licensed and are creative enough to qualify under copyright protection.
I've tried to think of a few scenarios of "where do we go from here", and I struggle to answer that in any way that doesn't look like manually reviewing all current captions, sending out mass messaging to obtain active CONSENT, and deleting the remainder. But when I look at that level of mess, I struggle to justify anything other than deleting the whole lot under PCP and restarting the project from scratch.
Now that's a massively crappy solution that wastes several weeks worth of work and doesn't really make anybody happy. But...I legally appropriate notification of licensing terms is really Commons 101 stuff. In a situation where we're looking to do this structured data thing over the entire foreseeable future, maybe it's not all that bad to call it a good test run, do a thorough post mortem, and learn from our mistakes. GMGtalk 12:45, 11 February 2019 (UTC)
Of course it's a massively crappy solution. When I proposed on the Village Pump that the change was reversed, several voters said the equivalent of "oh, let's run this for a month and see how it goes before voting again". I hesitate to say "I told you so", because that sounds like I won something when actually we are all losing volunteer time, good faith and new users. -- (talk) 13:14, 11 February 2019 (UTC)
@Donald Trung: asking consent afterwards would, while ugly (but this whole operation is never going to get pretty..) be an acceptable solution. I'm not sure it'll be worth it though. For users who have entered many self-written (not copy-pasted..) captions it could be interesting. But to realize all this.. I'm afraid starting from scratch will be better. Cut our losses and get it right next time. - Alexis Jazz ping plz 16:21, 11 February 2019 (UTC)

Symbol oppose vote.svg Oppose all three options. Go discuss things at Commons_talk:Structured_data#CC0_licensing_mockups first.”

— Mike Peel (talk) 12:54, 11 February 2019 (UTC)

@Mike Peel: implementing a license notification after going live is entirely unacceptable (seriously.. why did you think that would be okay?) and doesn't do anything to resolve the license issues around captions that have already been entered. - Alexis Jazz ping plz 16:13, 11 February 2019 (UTC)

@Alexis Jazz: To be honest, I assumed that the notification was there and that I'd just accepted it at some point. My suggestion is to discuss things with the people working on this first, and then put together a proposal, not the other way around. Mike Peel (talk) 16:22, 11 February 2019 (UTC)
@Mike Peel: what those people think doesn't really matter. Believing really hard something isn't copyvio doesn't magically make it public domain. Captions without any CC0 license notification can't be live. Period. They need to fix the legal issues, then they go live. Not the other way around! - Alexis Jazz ping plz 16:29, 11 February 2019 (UTC)
Yeah, they're really two separate issues: how we fix the fact that we aren't providing notification currently (the discussion at COM:SDC), and what to do with the past contributions that were not provided notification (this discussion). Solving one, even if done quickly and smartly, doesn't really address the other at all. GMGtalk 16:32, 11 February 2019 (UTC)
Pinging @WMF Legal:, they should've been involved with this from the start so this ugly, ugly mess could've been avoided. Any caption I in my individual capacity have created on Wikimedia Commons falls (irrevocably) under the Creative Commons 0 (Zero) free license. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:36, 11 February 2019 (UTC)
Any caption I in my individual capacity have created on Wikimedia Commons falls (irrevocably) under the site's Creative Commons Attribution-ShareAlike License, version 3.0.   — Jeff G. please ping or talk to me 14:31, 12 February 2019 (UTC)
Well Jeff, I hope you're willing to file a takedown notice over it, because from the looks of things, it seems that much of the community is content to sweep the whole thing under the rug, retroactively license them however we please, and pretend like nothing ever happened. GMGtalk
Good approach. It is very straightforward to issue the WMF with a takedown and it sets a nicely referenceable precedent. -- (talk) 16:00, 12 February 2019 (UTC)

Wikidata RfC related to the inclusion of Wikimedia Commons categories[edit]

Everyone is invited to give their opinion whether or not Wikidata should allow for the inclusion of items with only a Wikimedia Commons category, this request for comment was started to help the Structured Data on Wikimedia Commons programme and could be found on Wikidata at "Wikidata:Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion)". Note that this request for comment is on Wikidata so following that link will take you off Wikimedia Commons (as if this website is a wikidrug Face-smile.svg). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:23, 12 February 2019 (UTC)

Whitelist for Flickr accounts belonging to federal agencies of the United States[edit]

As discussed here, Is there a way we can whitelist Flickr accounts belonging to U.S. federal agencies? It seems many of these accounts are defaulted to "All Rights Reserved" despite U.S. copyright law.--TriiipleThreat (talk) 22:50, 12 February 2019 (UTC)

That would be a question for Zhuyifei1999 who maintains the Flickr checking bot. --Majora (talk) 22:56, 12 February 2019 (UTC)
I could add that if there is consensus that the flickr accounts are entirely uploading image from their employees. --Zhuyifei1999 (talk) 23:52, 12 February 2019 (UTC)
I would Symbol support vote.svg Support such a whitelist.   — Jeff G. please ping or talk to me 23:00, 12 February 2019 (UTC)
  • Symbol support vote.svg Support, the uploaders probably don't select the correct licenses. I know of a few contributors who import from Flickr who contacted several American government agencies to change their licenses on-Flickr despite already being technically free. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:17, 12 February 2019 (UTC)
    @Donald Trung: What methods and verbiage are working for them? Perhaps we can work together.   — Jeff G. please ping or talk to me 23:57, 12 February 2019 (UTC)
  • Symbol support vote.svg Support a whitelist. Which accounts to put on it will require some discussion. @Zhuyifei1999: I can't remember if your bot already does this, but can it for example automatically insert {{PD-CAGov}} for images from Category:California Department of Fish and Wildlife? - Alexis Jazz ping plz 01:57, 13 February 2019 (UTC)
    I don't think it's a good idea to whitelist categories, only accounts. --Zhuyifei1999 (talk) 14:28, 13 February 2019 (UTC)
    @Zhuyifei1999: that's what I meant, insert {{PD-CAGov}} into images from - Alexis Jazz ping plz 14:49, 13 February 2019 (UTC)
    Then no, not currently. --Zhuyifei1999 (talk) 14:52, 13 February 2019 (UTC)
  • I obviously Symbol support vote.svg Support the whitelist as the nominator. @Alexis Jazz: there is a flickr group for official U.S. government photostreams, although its membership is private and I can’t be sure if every official federal photostream is a member, but it maybe a good starting point. Other than that, this may have to just be a running whitelist that keeps expanding as we come across federal accounts.--TriiipleThreat (talk) 13:33, 13 February 2019 (UTC)
    • Comment: The group also contains state, and local government photostreams so if we do get access to its membership, we still may have to weed through the members.--TriiipleThreat (talk) 13:39, 13 February 2019 (UTC)
      • @TriiipleThreat: what do you need access for? - Alexis Jazz ping plz 14:52, 13 February 2019 (UTC)
        • @Alexis Jazz: I think it would be a good idea to see if we can get access to the list of members of the flickr group. From there, we can add the federal members of the group to the whitelist. I just suggested it to make the initial list a bit easier to compile than hunting down accounts individually from scratch.--TriiipleThreat (talk) 15:19, 13 February 2019 (UTC)
FBI top secret info

I also found that this photo was actually taken in area 51. I knew they weren't from here. - Alexis Jazz ping plz 15:57, 13 February 2019 (UTC)

  • @Alexis Jazz: LOL, thanks. This minus the state and local accounts should be a good jumping off point. Edit: I added a few others from the previous discussion. Also I struck out some state and local accounts.--TriiipleThreat (talk) 16:33, 13 February 2019 (UTC)

Create a separate list for Flickr accounts that require an additional human review[edit]

Note: Zhuyifei1999 (who maintains FlickreviewR) has stated this is technically possible.

Flickr is a rich source of images for us. Because some Flickr users are known for license laundering or have other issues that can't be overcome, Commons created Commons:Questionable Flickr images. Once on this list, tools downright refuse to upload anything from these photographers. And images get deleted blindly because authors are on the list, regardless of the actual reason they were listed.

Unfortunately, this list grew to also include many accounts that accidentally uploaded something that doesn't adhere to our strict rules. Or made some mistakes while also having good, properly licensed own work. For an example, look at A perfectly usable and correctly licensed photo of the town hall in Bradford. Can't upload it with any tool, because Paul Stumpr has also taken photos of magazines and a cardboard Fred Flintstone. Another example: Russian Orthodox Church in Antwerpen. This photo was deleted because the account is on the "bad authors" list. The account is on the bad authors list because of this incident and while images from this account appear to require a human review, photos that were taken with a Canon EOS 5D Mark II or iPhone 4 are fine.

If this proposal passes, tools should ignore the new list or merely warn the uploader without blocking the upload. FlickreviewR should tag the images for human review while also still providing its own review. (in case the license changes before the human reviewer gets to it) For the accounts that are placed on this list, the admin that adds the account should also provide a description of what the license reviewer needs to look out for with that particular Flickr account. - Alexis Jazz ping plz 23:38, 9 February 2019 (UTC)

Create a list for Flickr accounts that require an additional human review: votes[edit]

Create a list, independent from Commons:Questionable Flickr images for Flickr accounts that do have properly licensed images that are within our scope but require a human review.

  • I would Symbol support vote.svg Support this as blacklisting should be a last resort and not a first resort (like Wikipedia's already do with "spam" websites which are useful and educational but get blacklisted because of one assumption of bad faith or incident. A lot of Flickr accounts have thousands of good images with hundreds of bad ones, most importers won't check the blacklist first and excluding good content over trivial reasons that could be handled by a handful of volunteers should not be an option. Post Script: You could copy this comment and any other comment I make to the actual proposals village pump when you're going to present your ideas as I'd rather not "vote" twice. Face-wink.svg --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:46, 10 February 2019 (UTC)
Donald Trung's vote copied from User:Alexis Jazz/Proposal incubator per his request. - Alexis Jazz ping plz 16:18, 15 February 2019 (UTC)
  • Symbol support vote.svg Support as proposer. - Alexis Jazz ping plz 16:18, 15 February 2019 (UTC)
  • Symbol support vote.svg Support Abzeronow (talk) 16:33, 15 February 2019 (UTC)
  • Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 17:32, 15 February 2019 (UTC)
  • Symbol oppose vote.svg Oppose will just create another backlog, when you don't even need tools to upload from Flickr. If an image is that valuable, it can be uploaded manually. See backlog Category:License review needed. Will also create more admin deletion work, when users abuse it.--BevinKacon (talk) 10:32, 16 February 2019 (UTC)

Create a list for Flickr accounts that require an additional human review: discussion[edit]

Discuss details for this proposal here.