Open main menu

Commons:Village pump/Proposals/Archive/2018/02

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Proposal to increase the minimum requirements of activity for the administrators

This section was archived on a request by: Zhuyifei1999 (talk) 00:56, 11 March 2018 (UTC)

Modern Art by David Adam Kess

Visual arts education is the area of learning that is based upon only the kind of art that one can see, visual arts—drawing, painting, sculpture, and design in jewelry, pottery, weaving, fabrics, etc. and design applied to more practical fields such as commercial graphics and home furnishings..

looking for support to keep my educacional art in wikimedia....thanks and gracais

Commons:Deletion requests/Files in Category:Modern Art by David Adam Kess

have a great day to the community of wikimedia....


— Preceding unsigned comment added by David Adam Kess (talk • contribs)
@David Adam Kess:
This is the wrong place. Please answer in the deletion request. Regards, Yann (talk) 12:46, 14 February 2018 (UTC)
You should be able to demonstrate the educational value of your art and make a case why they're within scope on the deletion request page, the fact that this is here is wholly my fault, I informed this user in a wrong manner. --Donald Trung (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:30, 14 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:55, 11 March 2018 (UTC)

Flooder permission

Would people be open to the idea of flooder right? It would be hiding a person from recent changes because they do repetitive tasks. For example, people do a ton of stuff through visual file change and it would flood it, temporarily. It would be helpful for people who patrol special:RecentChanges but don't want to see repetition. For technical issues, it would mean admins can grant it to themselves, and bureaucrats grant to others, in a similar vein to translation administrator right. Thoughts?

Artix Kreiger (talk) 20:28, 14 February 2018 (UTC)

This is what the bot flag is for. -- (talk) 20:29, 14 February 2018 (UTC)
@: I tried to get that for User:JeffGBot, but was denied. :(   — Jeff G. ツ please ping or talk to me 06:43, 15 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:54, 11 March 2018 (UTC)

Upload issue: Summary header gets inserted twice

I mean =={{int:filedesc}}==. For example visible at File:Mursi Warrior.jpg. --Palosirkka (talk) 20:14, 24 February 2018 (UTC)

This is a bug: phab:T187302. --Steinsplitter (talk) 21:05, 24 February 2018 (UTC)
Thanks for the link. The bug is quite annoying. The line appears twice if it is at the start of what is submitted. I use the standard upload form with c/paste (not the wizard) and quite often derivativeFx and the duplication of the summary heading is so consistent that I've now started removing it from the form before I hit upload, thus leaving just the one that gets generated (when I remember). If it does get duplicated and I forget, a bot does usually come along and fix it later, though. -- Begoon 21:20, 24 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:53, 11 March 2018 (UTC)

What can we do to help User:Onan peyon & User:Onanpeyon140499

A quick goolge shows he is a photographer but because all his uploads are claimed to be 'own work' we can not tell which ones he took. He seems to be able to upload image here, just as easily as he can to his Instagram and Sinar Hoickon Photo Star accounts etc. However, we find it more time consuming to just keep deleting them. This is a futile waste of both his and our time. I and User:Alexis Jazz are thinking that some of our suggestion here on Commons:Upload Wizard proposals would help prevent the flood of these and similar copyvios. --P.g.champion (talk) 18:13, 25 February 2018 (UTC)

This seems barely like a proposal and a bit more like a question.
Those Upload Wizard proposals are not likely to help in this case. This is an issue similar to File:Stars selfie.jpg. If photographers don't want to or are unable to insert CC-licensing on their website or social media accounts and they have no (public) business email address, they are essentially not welcome here. Even if they somehow did get to OTRS, OTRS has a backlog of 37 days (according to COM:OTRS) which is exactly 30 days more than it will take to delete an image with {{No permission since}}. - Alexis Jazz 18:51, 25 February 2018 (UTC)
Yeah, but we can undelete it after. If they email OTRS to document that they are the same person as such-and-such account elsewhere, the OTRS people can do a reusable verification of identity: they don't need to do this for each individual photo. - Jmabel ! talk 20:10, 25 February 2018 (UTC)
If a photographer has some social media account they don't want to (or can't) add CC information to and a free email address that isn't publicly listed on the social media account* there is (as far as I can tell) nothing OTRS can do. No upload wizard can fix that.
*and they shouldn't, I'm still waiting for the money of my Nigerian royal uncle to clear so I can make some payments for my basement full of viagra
- Alexis Jazz 21:50, 25 February 2018 (UTC)
Just asking up-loaders on the Wizard if 'they' took the photograph or crafted the diagram by ticking a box would help, as in these two case, I've just found: User talk:Gregorybarry. Can't link to the images themselves because User:Túrelio was quick off the mark and had them deleted within 'minutes' of me finding them. I am find loads of files like these – every time I review. Remember too, I am only quickly skimming through. There must be many more that I miss. So, what are we talking about. I would say copyvios occur in over 1:150 up-loads. Surly this justifies some improvements to Wizard? --P.g.champion (talk) 22:28, 25 February 2018 (UTC)
It does, but if Onan Peyon registers with Commons that won't help. - Alexis Jazz 22:36, 25 February 2018 (UTC)
So, let us take one step at a time. Nothing will ever be fool-proof. Surgical nurses count every instrument and swab out and every one back in but some patients still find they go home with more than they expected. Even the USAF loose a thermonuclear bomb from time to time. This is no reason to ignore the need to improve WC protocols.--P.g.champion (talk) 23:10, 25 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:53, 11 March 2018 (UTC)

God has joined Commons!

"This file and any 3D objects depicted in the file are both my own work."

As you can see on the description page of the picture, it's true. The other image the user has uploaded was a copy of File:Img-20170123-wa0001.jpg (top image on so there would seem to be no question we are dealing with God here.

The actual proposal is to reconsider the wording of that template. Perhaps change "3D objects" to "virtual 3D objects". And maybe consider not even allowing it for photos, or at least not offer it as an option for photos by default. In a rare case where this template would actually apply to a photo, edit it in after the upload. - Alexis Jazz 22:03, 25 February 2018 (UTC)

Also looks like the chip-set in his phone is claiming copyright – that could be confusing. Is it possible for owners to reset it? --P.g.champion (talk) 22:39, 25 February 2018 (UTC)
@P.g.champion: You are brilliant. Jeff tried to speedy it. I wonder how many images we have lost over the years to this bullshit. - Alexis Jazz 11:00, 26 February 2018 (UTC)
Just remove the template, and add a friendly message to the uploader. Regards, Yann (talk) 06:31, 26 February 2018 (UTC)
@Yann: Have fun cleaning up pages and informing a couple of users each day:
I prefer just getting this fixed. - Alexis Jazz 09:01, 26 February 2018 (UTC)
Alexis Jazz: Most of these are either out of scope, missing permission, or both. One is already deleted. The rest is already fixed. Please don't make a mountain out of a molehill. Regards, Yann (talk) 09:35, 26 February 2018 (UTC)
@Yann: I don't. Some fairly simple changes can be made to stop all of these errors. It will take the developers a few hours at most but more likely about 10 minutes. You prefer to just notify hundreds of users for years and fixing pages until after many years somebody finally realizes: why didn't we just fix this when we found out it was broken? - Alexis Jazz 10:16, 26 February 2018 (UTC)
@Alexis Jazz:, I've filed a task to have the engineers take a look. To keep our relationship healthy, I'd like to kindly ask you to please don't estimate time on the behalf of engineers. It sets unrealistic expectations. (humor) CKoerner (WMF) (talk) 15:48, 26 February 2018 (UTC)
@CKoerner (WMF): Thanks! I actually do have some idea of how long it takes to implement certain features - assuming the code isn't a complete mess - but admittedly I exaggerated the amount here. The point was simple though: if we clean pages, warn three users each day and assume we spend a little over 3 minutes per user we will spend 10 minutes each day or 60 hours a year or 300 hours in 5 years. More than 12 days, 24/7. I think it would be safe to assume that what I propose can be done in less time than that, making it worth it. ;-) What I proposed really can be done in 10 minutes, I know it - but Bobby Tables may end up running amok when you work that quickly. So, it's better to take more time indeed. - Alexis Jazz 16:28, 26 February 2018 (UTC)
This section was archived on a request by: Zhuyifei1999 (talk) 00:52, 11 March 2018 (UTC)

Proposal for alt tags

Alt tags are not used often on enwiki. To increase use, I propose we add an alt field to Template:Information. Then, when you click the Use this file button, the alt tag would be included. While captions can vary based on what you are using the image for, the alt tag will be the same no matter what you are using it for, since you are describing the image. I think this will increase the use of the alt tag. Thoughts? Kees08 (talk) 01:48, 19 February 2018 (UTC)

Proposal to explain the official view of Commons regarding photos on coffins in the de minimis policy

It's quite common for a photo to be placed on a coffin, but it's not clear to me if Commons considers that photo in a photo of a coffin-with-photo to be DM or not. In more clear words: I mean the case where somebody makes a free photo of a coffin, but there is a photo placed on top or near of the coffin which can be seen as well and which is nonfree. I would find it useful if the de minimis policy would deal with this. - Alexis Jazz 00:12, 23 February 2018 (UTC)

I don't think we should add that in the policy. It depends very much on the original picture, and how the photo of the coffin is taken. We should just use common sense (and if you are the photographer, do not focus on the original). Regards, Yann (talk) 04:14, 23 February 2018 (UTC)
I agree with Yann. Generally such photos are de minimis, but the uploader can also decide to blur it or mask it in a similar way. --Ruthven (msg) 10:16, 23 February 2018 (UTC)
Alright. But perhaps a note in some form could be added. I personally feel it is generally disrespectful to remove/blur the photo from such images. In a similar image that shows a photo in the image with similar size and focus but where the subject is a book signing instead of a funeral, I don't have many issues with removing or blurring the photo. It is quite common for photos to be placed on or near a coffin and photos taken of coffins are typically in scope. I think we should be slightly more lenient in allowing them as DM. I'd be OK with making the {{De minimis}} template a requirement for that. My point is that if we are just as strict on these coffin photos as we are on (for example) photos of book signings, it could be hard for Commons to continue hosting funeral photos. I believe we already are more lenient on this subject and I would like to see some sort of note on this in the policy. I agree no universal ruling could be developed, I'm not asking for that. - Alexis Jazz 11:00, 23 February 2018 (UTC)
I agree that picture is less likely to be within the scope of DM. I added DM to it anyway because it's not the main focus of the image (to me) and to inform anyone who wants to reuse it. If somebody nominates that file for deletion I won't strongly defend it: it is not used and we have similar photos of the same funeral that focus less on the coffin photo. So from an educational point of view, we don't really need it in this case. - Alexis Jazz 11:00, 23 February 2018 (UTC)

Merge the function of two templates

Can we import the unique functions of {{PeopleByName}} into {{Wikidata person}}, they duplicate a lot and it would be best to just have one template to add to a new biographical category. Wikidata person can become {{wikidata person|Q2092869|McGillivray|Perry}} By adding the sortkey function of PeopleByName to wikidata_person. We can skip the adding of "M" and "F" and import the gender from Wikidata. PeopleByName adds a sortkey on the fly "McGillivray|Perry|M" and one or two categories currently missing from wikidata_person. They both generate categories based on Wikidata information on the fly, as opposed to typing them in, so that when Wikidata is corrected the categories are automatically updated, the categories aren't really there when you hit the edit button. Wikidata_person was recently updated with functions from other templates and was originally based on template:Creator. The template wikidata_person and the information at Wikidata have recently improved image search on Google by including more biographical data in the categories, especially for people with commons names. Google Image distinguishes better John Smith, the baker from John Smith, the barber. RAN (talk) 19:09, 23 February 2018 (UTC)

@Richard Arthur Norton (1958- ): Or there's {{Wikidata Infobox}}. ;-) I've now added support for all of {{PeopleByName}} using info entirely from Wikidata, see [4] for an example of it in action. So if the category has a sitelink on Wikidata, and the relevant info is in the Wikidata entry (sex or gender (P21), given name (P735), family name (P734) at least, date of birth (P569) and date of death (P570) for the full set), it should just do everything by adding {{Wikidata Infobox}}. If there are any problems, please let me know and I'll look into them. Thanks. Mike Peel (talk) 22:45, 23 February 2018 (UTC)
@Richard Arthur Norton (1958- ): P.S. if the category isn't linked to the Wikidata entry, then you need to make an edit like [5] to link it. Category:Willard Dickerman Straight should work now. ;-) Thanks. Mike Peel (talk) 23:08, 23 February 2018 (UTC)
Excellent work. {{Wikidata Infobox}} is more vertical and {{Wikidata person}} is more horizontal, each good in their own way. Are you going to update {{Wikidata person}} also with your category and sort key changes? {{Wikidata Infobox}} now performs all the functions you would need when you create a new category. Now when Wikidata is updated, the categories will be adjusted, we have over 10,000 records where we have only the year of birth for a person, and roughly half of them are off by a year. They are generally calculated from the person's age in an obituary, when the exact birth is unknown. RAN (talk) 23:22, 23 February 2018 (UTC)
Thanks. :-) I'm not planning on editing {{Wikidata person}}, but you can see the code I wrote to do the {{PeopleByName}} include at [6], maybe @Jarekt: would like to incorporate it in {{Wikidata person}}. Personally, I'd like to merge that template into {{Wikidata Infobox}} at some point, as I think the latter is formatted better and it also works with categories that aren't about people, but we need to discuss that. With regards vertical and horizontal, personally I don't care, but I think we should standardise on one of the two and use that uniformly in categories. Thanks. Mike Peel (talk) 23:34, 23 February 2018 (UTC)
RAN, {{PeopleByName}} and {{Wikidata person}} are quite different. {{PeopleByName}} is meant to be substituted and {{Wikidata person}} does not. Also adding extra parameters to {{Wikidata person}} would make it much harder to use, as it's main feature is that it does not take any inputs other than item ID. I do not want to add surname and given name categories as they are added only if such categories exist. The code would have to be constantly checking that. I also do not like gender based categories, like Category:Men by name and would prefer not to use them. --Jarekt (talk) 05:36, 24 February 2018 (UTC)
Then why do we have {{PeopleByName}} and why do people add it to categories? We need to be consistent so when people look at a list everyone they are looking for is included. If we should not have gender specific categories, then we should get consensus to delete/retain them. If the surname category does not exist, it takes about 7 seconds to make it a subcategory of Category:Surnames and the red link is now blue. {{wikidata person|Q2092869|McGillivray|Perry}} is no needed, Mike Peel cleverly coded the sort key based solely on the Wikidata Q number in {{Wikidata Infobox}}, the vertical version of the category infobox. Men by name and Women by name, honestly no one actually uses it to search for a person, it is there more for web crawlers than actual human utility. RAN (talk) 05:49, 24 February 2018 (UTC)

Don't notify a user if their edit on a user talk page is undone by the owner of the talk page

When an edit on a wiki is undone, it usually means you've done something wrong. Or someone else before you did and your edit was part of the rollback as well. It makes sense to notify the user so they can try to figure out what they did wrong, or see if they need to re-add an edit that was collateral in a rollback.

Some users have a habit of using the "undo" function as a way of a "got it, archive to nowhere" button. Which is perfectly fine except the user who made the edit or made the DR for a file that the user uploaded gets a useless notification that their edit was reverted. For new users who are not familiar with this practice this could also lead to confusion - have I done something wrong? Should I not have nominated that file for deletion?

Notification for an undo/rollback on a user talk page is always useless. If it's a user saying "got it, archive to nowhere" there is no need to notify. If a user has done something very wrong on a user page, a message should be left on the talk page of the offending user to explain what they did wrong. That is if it's not taken straight to the vandalism board. The undo notification is useless for either case.

An alternative is to create an extra "got it, archive to nowhere" button. I think that'll just add to the clutter so disabling the undo/rollback notification when an edit on a talk page is undone by the owner of the talk page makes more sense to me. But I would be happy with either way. - Alexis Jazz 04:56, 24 February 2018 (UTC)

I agree the notification for rollback/undo is disruptive for many wiki practices. I always disable it. It tends to encourage edit wars too, so I wouldn't oppose a feature request to disable it for all users on Commons. Would somebody miss it and why? --Nemo 14:41, 24 February 2018 (UTC)
I know of a good few editors who have disabled revert notifications for that very reason. They feel that the 'red-mist' these messages can inspire may make them more likely to edit-war or respond rashly, so they prefer to just rely on the watchlist because they feel that results in more sedate, considered responses. At least a couple of them, which I recall, have also said it's been "the best thing they ever did with notifications" or something similar. I can see their point, too, but I think it should remain a matter of personal choice for those like Jeff below, who prefer to receive them. I leave them switched on myself. -- Begoon 16:04, 24 February 2018 (UTC)
@Alexis Jazz, Nemo bis: Use of rollback against community translated templated user talk page messages on one's user talk page that are not clearly mistaken or self-generated (that is, constructive edits) is actually misuse per COM:RB (as such implies that the original messages were vandalism), and could result in loss of the rollback permission via COM:AN or the action of a single Administrator. I certainly want to be notified if someone else rolls back my such messages, but I don't care so much when someone undoes them, which action would just be antisocial and obfuscatory.   — Jeff G. ツ please ping or talk to me 15:10, 24 February 2018 (UTC)
Antisocial and obfuscatory to remove a templated message which one has read? Sometimes I can do nothing but shake my head at the things I read here. -- Begoon 15:56, 24 February 2018 (UTC)
I don't think that's what Jeff meant. If you edit the page and remove the message that way to perform the "archive to nowhere" I doubt anyone would have any problem with that. That will not send a notification and is also not tagged as "undo". And "undoing", at least from the outside, really seems like making something like it was never done. I know you don't mean it that way, but it can come across like that. Especially to users who are not familiar with how "undo" gets used here. - Alexis Jazz 17:13, 24 February 2018 (UTC)
Yeah, well that may be a fair point - I suppose I'd rather not trigger a notification in those circumstances and potentially upset or confuse someone. That covers "antisocial", in a way, and a couple of extra clicks is no issue. But hang on, now I'm being even more "obfuscatory" aren't I, by doing it quietly? My head is shaking less, but it's not completely still yet... -- Begoon 17:32, 24 February 2018 (UTC)
Ideally you would also enter "Got it, thanks" in the edit summary. Perhaps it's possible to create a script that saves a few clicks and keystrokes to do that. - Alexis Jazz 17:43, 24 February 2018 (UTC)
Ideally, yes, and I shall henceforth do it just like that. I do still have to say, though, that equally ideally folks would try not to throw around terms like "Antisocial and obfuscatory" and use some common sense - but we'll see how that goes... -- Begoon 17:52, 24 February 2018 (UTC)
Regarding Alexis' idea itself, it's maybe not altogether a bad idea, but I suspect that doing this solely for "own talk page reverts" might be difficult to "sell" as a concept in a feature request. It might be viewed (or "brushed off") as an overly complicated solution to a debatable problem. Nothing to stop someone asking, though... -- Begoon 16:14, 24 February 2018 (UTC)
If some people here would say "Yeah, makes sense" that would be a great support for a feature request. If everyone here is more like "meh", I don't see it happening. - Alexis Jazz 17:13, 24 February 2018 (UTC)

Change to text of Commons:File renaming policy

"Files with copyright issues should NOT be renamed until copyright issues are resolved. There is no reason to rename a file if it is going to be deleted on copyright grounds."


"Files that do not appear to comply with Commons policy should not be renamed and instead be nominated for deletion if they haven't been already, speedy where applicable. When a file was nominated for deletion but the file mover deems this nomination to be unlikely to result in actual deletion, the file can be moved." - Alexis Jazz 13:37, 28 February 2018 (UTC)

  •   Oppose Though renaming while a DR is open is considered poor practice, there are times when it is reasonable to do so, such as when the title may be defamatory. For this reason I would rather see the section changed to be weaker, it's stating a norm not a policy. The proposal wording does not specify which policy is the one not being complied with. It reads as if any file needing to be renamed would be deleted. -- (talk) 13:52, 28 February 2018 (UTC)
"It reads as if any file needing to be renamed would be deleted." I don't see this. Can you elaborate?
I will clarify what triggered this proposal. It was File:Faith Hill on the Jumbotron (3972893368).jpg. I nominated it as it didn't even state which stadium this was so it seemed to be just a file for Faith Hill. After a comment in the DR I did some research, improved category/description and blurred Faith Hill. It is now a useful image, but it is no longer "Faith Hill on the Jumbotron". The renaming request was however denied because there was a open DR.
This means I would have to wait for the DR to be closed before I can have this file renamed. That could have taken weeks or even months and I could easily forget all this in that time. In this case as I've just learned I can close uncontroversial DRs myself I have done that. But it would be very reasonable to just rename the file. - Alexis Jazz 14:40, 28 February 2018 (UTC)
  •   Support Contrarily to , files can violate any number of Commons policies and guidelines which can lead to deletion. Typically, these include COM:L, COM:SCOPE, COM:TOO, COM:PRP, COM:FOP, COM:CRT, and the requirement in many source country licensing templates to have a corresponding template indicating the file is also free in the US. The majority of good faith DRs lead to deletion, and renaming a file subject to one of them can cause confusion in which the redirect is deleted but the renamed file survives, or a bluelink redirect to a deleted file is left in a DR. This proposal removes copyright as the single named specific reason not to rename, to the exclusion of all others.   — Jeff G. ツ please ping or talk to me 14:21, 28 February 2018 (UTC)
If a file fails to be deleted as a result of a move that is a software problem and a bug report should be made. Of course, there are more reliable ways of making this happen. - Alexis Jazz 14:40, 28 February 2018 (UTC)
Huh? "Contrarily to [me]" seems unrelated to what I wrote above. There are many policies related to deleting files, why anyone would think that I was denying this seems weird. -- (talk) 15:11, 28 February 2018 (UTC)
I don't know for what reason Jeff said it, but "The proposal wording does not specify which policy is the one not being complied with." can imply there must be one specific policy the file does not comply with in order to refuse a rename. I don't see the point of that, if a file is not copyvio but it is out of scope, why would you bother renaming it? - Alexis Jazz 15:20, 28 February 2018 (UTC)
@: What I meant by "Contrarily to " was that you were opposing, meaning you were for the status quo, which specifies only copyvios can prevent renaming. I also do not understand your conclusion "It reads as if any file needing to be renamed would be deleted" - can you please explain that conclusion and what led to it? — Jeff G. ツ please ping or talk to me 18:55, 28 February 2018 (UTC)
@Jeff G.: Fixed your signature.. I really suspect that what we have here is a case of The dress. You read the same thing I read, Fae and Steinsplitter are reading something completely different. It's nearly impossible for us to figure out on our own what they are reading. - Alexis Jazz 19:45, 28 February 2018 (UTC)
I am not for the status quo and I am against this proposal, these are not mutually exclusive. Criteria 4 of FR would be better removed entirely. A red flag that policies or guidelines are badly written is the inclusion of "deems" when the "deemer" has no defined authority. It would be nice to see proposals that reduce our bureaucracy. Most users and, based on their actions, many administrators, find the current guidelines and policies hard to follow or are not interested in following them as written. -- (talk) 19:56, 28 February 2018 (UTC)
@: I get your point but I don't fully agree. The "deemer" in this case is a file mover. (or admin etc) They are not asked to make a ruling on the deletion of the file. It merely asks them to use some common sense (I'm aware sense ain't common but you get my point) to determine that if they move a file despite the fact there is an open DR for it, they are making a constructive edit.
If your point is that moving a file that the file mover suspects will be deleted anyway for whatever reason is so stupid it should not require being pointed out in the guidelines I understand that. I will be happy to support a proposal to remove criteria 4 or replace it with "Never forget to use common sense when trying to determine if a file should be moved." or something like that. - Alexis Jazz 21:43, 28 February 2018 (UTC)
@Steinsplitter: Can you or anyone else please explain to me what the issue is that Fae has? And why a request to rename a file that is out of scope should be carried out but a rename for a copyvio should not? - Alexis Jazz 17:03, 28 February 2018 (UTC)
See Fae's oppose, he explained it very well. --Steinsplitter (talk) 17:21, 28 February 2018 (UTC)
If this is a joke I don't get it. I had already replied to that. I did read it. I don't get it. I ask for somebody (Fae or anyone who understands it) to explain it. Maybe I'm reading it wrong. Maybe you and Fae are reading the proposal in a way different from me and Jeff. Maybe it needs to be reworded yet again. But "per Fae" does not help me to do that.
It's like I just walked into the Twilight Zone. - Alexis Jazz 17:34, 28 February 2018 (UTC)
  • Fae explained and I now understand the confusion, so this proposal is no good. @Steinsplitter: how do you feel about getting rid of criteria 4 (the thing we discussed) altogether? - Alexis Jazz 01:31, 1 March 2018 (UTC)

Proposal to bot-deploy Wikidata Infobox

Lovell Telescope 
radio telescope at Jodrell Bank Observatory, Cheshire in the north-west of England
The Lovell Telescope
Upload media
Instance ofradio telescope,
parabolic reflector
Part ofJodrell Bank Observatory,
European VLBI Network
Named after
Location Cheshire East, Cheshire, North West England, England, UK
  • Jodrell Bank Centre for Astrophysics
Heritage designation
Service entry
  • 2 August 1957
Significant event
  • 250 ft
  • 5 GHz
  • 4,560 m² (primary mirror)
official website
53° 14′ 10.5″ N, 2° 18′ 25.74″ W
Authority control
telescopio Lovell (it); Télescope Lovell (fr); Telescopi Lovell (ca); Lovell-Teleskop (de); Telescópio Lovell (pt); 洛弗尔望远镜 (zh); 洛弗爾望遠鏡 (zh-hk); Telescópio Lovell (pt-br); Лавелівський телескоп (uk); Lovell Telescope (nl); 洛弗爾望遠鏡 (zh-hant); радиотелескоп имени Б. Ловелла (ru); Lovello radioteleskopo (eo); ラヴェル望遠鏡 (ja); Telescopio Lovell (gl); تلسكوب لافيل (ar); 洛弗尔望远镜 (zh-hans); Lovell Telescope (en) радиотелескоп в обсерватории «Джодрелл-Бэнк» (Чешир, Северо-Западная Англия) (ru); teleskop radio di Britania Raya (id); radio telescope at Jodrell Bank Observatory, Cheshire in the north-west of England (en); مقراب راديوي في المملكة المتحدة (ar); Radiotelescopio (it); radiotelescopio no Observatorio Jodrell Bank, en Cheshire (Inglaterra) (gl) Lovell Telescope, Radiotelescopi de Jodrell Bank, Radiotelescopi Lovell, Telescopi Mark IA, Telescopi de 250 peus, Telescopi Mark I (ca); Téléscope Lovell, Telescope Lovell (fr); 250 ft telescope, Radio Telescope at Jodrell Bank, Mark I telescope (en); радиотелескоп Ловелла, 250-футовый телескоп, радиотелескоп в «Джодрелл-Бэнк», Марк-1 (ru); Sir Bernard Lovell Telescope (it); Locell Telescope (gl)

{{Wikidata Infobox}} displays a small box containing basic information drawn entirely from Wikidata, such as the one on the right for Category:Lovell Telescope. It is inherently multilingual - change the language you're browsing Commons in, and the info in the box will be shown in that language. It works in commons categories (and also galleries) that have a Commons sitelink on Wikidata, and it's been designed so that it should work for any subject (with a special switch to handle humans, including auto-categorisation through {{PeopleByName}}). It also sorts out interwiki links for categories linked to a Wikidata category item (through auto-including {{Interwiki from wikidata}} when needed). Suggestions for improvements and reports of bugs are welcome on the template talk page.

Since I started it just over a month ago, we've had a very positive village pump discussion about it, and it's now been manually added to over 1,000 categories across a wide variety of topics by a number of editors. We can continue to manually deploy it, but as it just relies on the existence of a Wikidata entry with a commons sitelink, we could also bot-deploy it to categories that have such a sitelink. We could either do that for all categories that have such a sitelink (which would be circa 2 million, as that's how many times P373 is used on Wikidata) - obviously, in steps, not all at once! Or we could pick category trees to add the box to, and do it one topic at a time. We can avoid categories that use other approaches (such as {{Wikidata person}}, add it alongside other templates that offer similar functionality (e.g., {{Authority control}}) and/or we can replace them with this one.

What does everyone think? I can write the bot code and start a bot request, if that's what we want to do, but we need to discuss it here first as this is a broad, and fairly fundamental, topic.

(pinging those that participated in the previous VP discussion: @Strakhov, DarwIn, Jheald, Pigsonthewing, Jmabel, Incnis Mrsi @ערן, Christian Ferrer, Rama, John Cummings, Jeff G. @Llywelyn2000, Donald Trung)

Thanks. Mike Peel (talk) 22:54, 25 February 2018 (UTC)

  Support I like it. Useful, low-impact, and promotes Wikidata. Sebari – aka Srittau (talk) 23:13, 25 February 2018 (UTC)
  Support Very useful, Mike is the right person to do it. John Cummings (talk) 23:20, 25 February 2018 (UTC)
  Support It provides good information in a nice, standardized format. Currently, information on category pages are ad hoc and, as far as my experience goes, may be outdated. I am happy this possibility is being put forward, as I believe it really helps. I also like the maps a lot. Mike, full support to your bot request! --Joalpe (talk) 23:38, 25 February 2018 (UTC)
  Support - Jmabel ! talk 23:52, 25 February 2018 (UTC)
  Support, of course. I would also like to see discussion of merging with other templates: {{Wikidata person}}, {{Authority control}}, {{Object location dec}}, et al. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:14, 26 February 2018 (UTC)
  • I like it and I think Mike Peel did great. I have concerns with replacing templates that already use wikidata codes, because of some potential issues I shared with Mike Peel. Leaving aside that, I   Support bot-adding {{Wikidata infobox}} to categories not using "...wikidata person, wikidata place, authority control, objet location ..." right now. Merging them it's desirable in the medium term, but we can wait to see how the deployment develops, we are not in a hurry after all. strakhov (talk) 01:57, 26 February 2018 (UTC)
  Oppose Warning: Default sort key ", Henri" overrides earlier default sort key "Demonchy, Henri". - Alexis Jazz 02:41, 26 February 2018 (UTC)
@Alexis Jazz: This one is now fixed. Thanks. Mike Peel (talk) 11:07, 26 February 2018 (UTC)
  Support - it will translate into every language under the sun, it's useful, compact, without drawing attention to itself. Great stuff! Llywelyn2000 (talk) 06:19, 26 February 2018 (UTC)
  Support The sort key issue has to be fixed, but I don't think it should not prevent the deployment. Regards, Yann (talk) 06:23, 26 February 2018 (UTC)
  Support Generally this is good idea and would be nice to see short additonal info on the topic based on Wikidata using this template. We should take care when depoloying the issue Alexis pointed above - either skipping pages that contain keys for now with the bot, or merge it with the template as parameter. Eran (talk) 06:34, 26 February 2018 (UTC)
  Oppose, supporters cut short this discussion but came here now. Incnis Mrsi (talk) 06:56, 26 February 2018 (UTC)
  Support with reservations. You may carefully proceed with deployment, but may not refer to this proposal as to sanction to override objections mounted for each particular case (such as classes of objects where sorting is important). Incnis Mrsi (talk) 11:18, 26 February 2018 (UTC)
@Incnis Mrsi: This was about whether we should have local copies of the Q-numbers. I thought this discussion had run its course, particularly since using the sitelinks is computationally cheaper than using local qids, but we can continue it if you'd like - I'd suggest at Template talk:Wikidata Infobox rather than my talk page. Thanks. Mike Peel (talk) 11:13, 26 February 2018 (UTC)


Full list

Warning: Default sort key "Hinojo, Àlex" overrides earlier default sort key ", Àlex".
Warning: Default sort key "Ganivet, Angel" overrides earlier default sort key "Ganivet, Ángel".
Warning: Default sort key "Berchmans, Emile" overrides earlier default sort key ", Émile".
Warning: Default sort key "Palicki, Adrianne" overrides earlier default sort key ", Adrianne".
Warning: Default sort key "Agatha of Sicily" overrides earlier default sort key ", Agatha".
Warning: Default sort key ", Alejo" overrides earlier default sort key "Vidal-Quadras, Alejo".
Warning: Default sort key "Barbazán, Andrés" overrides earlier default sort key "Barbazán Ferreiro, Andrés".
Warning: Default sort key ", Antoine" overrides earlier default sort key "Charial, Antoine".
Warning: Default sort key "Lockwood, Belva Ann" overrides earlier default sort key "Lockwood,".
Warning: Default sort key "Lovell" overrides earlier default sort key "Lovell, Bernard".
Warning: Default sort key "Medialdea, Bibiana" overrides earlier default sort key ", Bibiana".
Warning: Default sort key "Könberg, Bo" overrides earlier default sort key ", Bo".
Warning: Default sort key "Nocedal, Candido" overrides earlier default sort key ", Cándido".
Warning: Default sort key "Hamilton, Carl B." overrides earlier default sort key "Hamilton, Carl".
Warning: Default sort key ", Claude" overrides earlier default sort key "Vulpian, Claude".
Warning: Default sort key "Vulpian, Claude" overrides earlier default sort key ", Claude".
Warning: Default sort key "Perea, Daniel" overrides earlier default sort key "Perea y Rojas, Daniel".
Warning: Default sort key "Feijo, Diogo Antonio" overrides earlier default sort key ", Diogo".
Warning: Default sort key ", Dominique" overrides earlier default sort key "Teixier, Dominique".
Warning: Default sort key "Teixier, Dominique" overrides earlier default sort key ", Dominique".
Warning: Default sort key "Lynden-Bell, Donald" overrides earlier default sort key ", Donald".
Warning: Default sort key "Carlsson Löfdahl, Emma" overrides earlier default sort key "Löfdahl, Carlsson, Emma".
Warning: Default sort key "Baquedano, Enrique" overrides earlier default sort key ", Enrique".
Warning: Default sort key "Ravilious, Eric" overrides earlier default sort key ", Eric".
Warning: Default sort key "Möller, Erik" overrides earlier default sort key ", Erik".
Warning: Default sort key "Flyborg, Eva" overrides earlier default sort key ", Eva".
Warning: Default sort key "KALILI, EVA" overrides earlier default sort key ", Eva, Ewa".
Warning: Default sort key "Sabatini, Francesco" overrides earlier default sort key ", Francesco".
Warning: Default sort key "Cubas, Francisco de" overrides earlier default sort key ", Francisco".
Warning: Default sort key "Granados, Francisco" overrides earlier default sort key ", Francisco".
Warning: Default sort key "Dibnah, Fred" overrides earlier default sort key ", Frederick".
Warning: Default sort key "Coppede Gino" overrides earlier default sort key ", Gino".
Warning: Default sort key "Gaensly, Guilherme" overrides earlier default sort key ", Guilherme".
Warning: Default sort key "Sabanci, Guler" overrides earlier default sort key "Sabancı,".
Warning: Default sort key "Rohr, Hans Christoffer" overrides earlier default sort key "von Rohr, Hans".
Warning: Default sort key ", Henri" overrides earlier default sort key "Demonchy, Henri".
Warning: Default sort key "González, Ignacio" overrides earlier default sort key "Gonzalez Gonzalez, Ignacio".
Warning: Default sort key "Mundebo, Ingemar" overrides earlier default sort key ", Ingemar".
Warning: Default sort key "Gardner, Isabella Stewart" overrides earlier default sort key ", Isabella".
Warning: Default sort key "Mayor Oreja, Jaime" overrides earlier default sort key ", Jaime".
Warning: Default sort key "Ertsborn, Jan" overrides earlier default sort key ", Jan".
Warning: Default sort key "Pateau, Jean" overrides earlier default sort key ", Jean".
Warning: Default sort key ", Joaquín" overrides earlier default sort key "Almunia, Joaquin".
Warning: Default sort key "Rucoba, Joaquín" overrides earlier default sort key ", Joaquín".
Warning: Default sort key "Klabo, Johannes Hosflot" overrides earlier default sort key "Klæbo, Johannes".
Warning: Default sort key "Ortega Lara, José Antonio" overrides earlier default sort key "Ortega, José".
Warning: Default sort key "Ortega y Gasset, José" overrides earlier default sort key "Ortega, José".
Warning: Default sort key "Urioste Velada, Jose" overrides earlier default sort key "Urioste, José".
Warning: Default sort key "Imaz, Josu Jon" overrides earlier default sort key ", Josu".
Warning: Default sort key "Guerra, Julio" overrides earlier default sort key ", Júlio".
Warning: Default sort key "Klein, Lori" overrides earlier default sort key ", Lori".
Warning: Default sort key "Cabello Lapiedra, Luis Maria" overrides earlier default sort key ", Luis, Luis María".
Warning: Default sort key ", Manuela" overrides earlier default sort key "Carmena, Manuela".
Warning: Default sort key "Arnholm, Maria" overrides earlier default sort key ", Maria".
Warning: Default sort key "San Gil, Maria" overrides earlier default sort key ", María".
Warning: Default sort key "Conde, Mario" overrides earlier default sort key ", Mario".
Warning: Default sort key "Azevedo, Militao Augusto De" overrides earlier default sort key ", Militão".
Warning: Default sort key "Iceta, Miquel" overrides earlier default sort key ", Miquel".
Warning: Default sort key "Cornwell, Patricia" overrides earlier default sort key ", Patricia".
Warning: Default sort key "Vega, Paz" overrides earlier default sort key ", Paz".
Warning: Default sort key "Jerald, Penny Johnson" overrides earlier default sort key ", Penny".
Warning: Default sort key "Gahrton, Per" overrides earlier default sort key ", Per".
Warning: Default sort key ", René" overrides earlier default sort key "Fontès, René".
Warning: Default sort key "Haddad, Roger" overrides earlier default sort key ", Roger".
Warning: Default sort key "Abascal Conde, Santiago" overrides earlier default sort key "Abascal, Santiago".
Warning: Default sort key "Macfarlane, Seth" overrides earlier default sort key "MacFarlane, Seth".
Warning: Default sort key "Marthe, Tamara" overrides earlier default sort key "Shy'm, Tamara".
Warning: Default sort key ", Sol" overrides earlier default sort key "Sanchez, Sol".
Warning: Default sort key ", Teodoro" overrides earlier default sort key "Gascon, Teodoro".
Warning: Default sort key "Acketoft, Tina" overrides earlier default sort key ", Tina".
Warning: Default sort key "Le Guin, Ursula K." overrides earlier default sort key "Kroeber, Le Guin, Ursula".

So that needs to be sorted first anyway. If it does get sorted, I'm not entirely sure. It feels like it doesn't nicely fit in the layout. I'm also not sure I will find it useful. Perhaps some good examples can convince me.
Another issue I have is that this error occurs on 71 category pages out of 1078. That's 6.59% of all category pages yet this bug was not spotted. This thing needs way more thorough testing before deploying it on two millions pages. - Alexis Jazz 07:14, 26 February 2018 (UTC)
Alexis Jazz: This list is useless. Please create a maintenance category instead. Regards, Yann (talk) 09:06, 26 February 2018 (UTC)
You tell me I "make a mountain out of a molehill" in response to my perfectly sane proposal and you call a useful list (you can't easily search for these errors) useless. With this list you can more easily pinpoint all possible causes for this issue. If you want a list that also links the category in question, no problem, you would have only had to ask.
So far I have been (and will be, at least for some time) constructive on this wiki. But you create vandals. You treat people this way while being an administrator, you make people want to break this wiki. - Alexis Jazz 10:31, 26 February 2018 (UTC)
@Alexis Jazz: Thanks for catching this error; this part of the code was only added very recently. The ones with the missing surnames should now be fixed (I added an extra if statement to avoid auto-categorising these). The others, I'd appreciate feedback on - they are due to mismatches/errors in data here and on wikidata, so they can be resolved individually by an edit here or on Wikidata, or I can remove the defaultsort code from this template, I'm happy with either approach. Thanks. Mike Peel (talk) 11:07, 26 February 2018 (UTC)
Very good. I see for example Category:Ángel Ganivet indeed still shows the error due to the difference between "Angel" and "Ángel" and it takes a human to figure out which is right. What are the implications of removing the defaultsort code from the template? Will this cause problems, either now or at a later time? What is the reason this code is currently part of the template?
I think the infobox should not be added when it can cause this error which requires a human to fix it. If allowing these inconsistencies to exist is a bad idea (and I suspect it is) you could perhaps generate a list of the categories where this error occurs. (or add a hidden cat to those categories) When (human) users feel like it they can make the data consistent and enable the infobox. - Alexis Jazz 11:27, 26 February 2018 (UTC)
@Alexis Jazz: Defaultsort was added through the use of {{PeopleByName}} (see the discussion at #Merge the function of two templates above). I've now copied that code into this template, which gives more customization options. I've added a "defaultsort=no" parameter that, if set, will hide the defaultsort from this template and add the page to Category:Uses of Wikidata Infobox with defaultsort suppressed for tracking purposes. The plan would be that the bot would set that if it detects a conflicting defaultsort already in the category. How does that sound? Thanks. Mike Peel (talk) 22:06, 26 February 2018 (UTC)
@Mike Peel: That sounds good, I think some more implementation is in order.   — Jeff G. ツ please ping or talk to me 00:12, 27 February 2018 (UTC)
  Support Very much agreed with Sebari. Rama (talk) 09:11, 26 February 2018 (UTC)
+1, also helps editors focus on non-duplicative work to improve our metadata. --Nemo 11:21, 26 February 2018 (UTC)
  Support Obviously, tread gently. Move slowly into new areas of categories for new types of things. Be aware that these may reveal issues, that will then need adaptations to resolve. But in general, I support; and I have great confidence from what I've seen so far, that the team behind this (namely Mike!) are indeed very sensible and highly responsive. Widespread infoboxing will add greatly to the informativeness of category pages for all, as well as making Commons far more multilingually friendly. If it also adds an incentive for editors to add more sitelinks from Commons categories to items on Wikidata, that would be a valuable thing just in itself. Jheald (talk) 13:59, 26 February 2018 (UTC)
  Neutral Changing my vote from oppose to neutral. I just don't know if I will find these useful personally. Maybe I will, I just can't think of any case right now where I would wish there was an infobox. If there would be an option to somehow disable these infoboxes just in case I don't like them, I would change my vote to support. I do mean actually disabling them, not just hiding, because something could happen that somehow slows down page loading. Hiding won't help in that case. - Alexis Jazz 14:14, 26 February 2018 (UTC)
@Alexis Jazz: Hiding's the best I can do, I'm afraid. If you add "#wdinfobox { display: none;}" to User:Alexis Jazz/common.css, that will hide the infobox. Thanks. Mike Peel (talk) 22:17, 26 February 2018 (UTC)
Thanks. I will stick with the neutral vote, simply because I am personally not sure I will be using it. Maybe it'll grow on me, who knows. My support won't be needed for this anyway so it makes no real difference. - Alexis Jazz 10:41, 27 February 2018 (UTC)
  Support I was skeptical at first and resisted the early iterations because I had my own fave infobox format that used a horizontal format. Now this is my preferred. It replaces the 6 items I would use to create a new category, each requiring me to fill in information by hand. It also helps catch incorrect people by supplying their short descriptions from Wikidata. So when you see an image of a guy wearing boxing gloves and the infobox says he is a politician, you know to double check that two people have the same name and are being mixed up. Or if you see a contemporary photograph and see that the person lived in the 1800s. RAN (talk) 14:54, 26 February 2018 (UTC)
  •   Support   — Jeff G. ツ please ping or talk to me 00:12, 27 February 2018 (UTC)
  •   Support, this work would be too tedious for human volunteers anyhow. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:15, 27 February 2018 (UTC)
  • Comment. I do not have a strong opinion either way (I guess mild support would be the best expression of my attitude), but I think the discussion participants should be aware of an argument which is often brought up in these discussions but so far has not been brought up here. The argument is that so far the Wikidata community was not able to consistently fight vandalism, and it is not uncommon to have vandalism to stay hours even in the most popular Wikidata items such as countries and for days in less popular items. These instances of vandalism will be translated via the template and will not show on any watchlists.--Ymblanter (talk) 10:05, 27 February 2018 (UTC)
  •   Support, but not for categories connected to P31 Q4167836 items without P301.--Jklamo (talk) 15:17, 27 February 2018 (UTC)
  •   Support Changing my vote again, to support as I found a use case: Category:Saint Catherine. Saint Catherine? Who? What? Is it a city? Is it a person? Is it a church? Is it a school? Airport? Hospital? Sport club? Lake? Painting? All of the above? An infobox would be welcome here. Although the category itself is probably just a mess, but still. - Alexis Jazz 19:24, 27 February 2018 (UTC)
    @Alexis Jazz: more such cases can be found (esp. ambiguous toponyms, such as Lez River. But lending an unconditional support to these botmasters you will be responsible for many thousands cases of wikidata-driven mess and irritating visual clutter projected to pages over objection of local editors – it comes instead of few hundreds cases of grossly ambiguous categories. Incnis Mrsi (talk) 08:43, 28 February 2018 (UTC)
Um, if I support eating meat (instead of being a vegetarian) I will be responsible for millions of animals being slaughtered and incredible animal cruelty all around the world every day. I will be solely responsible for all that because I support it. And because I support lighting some fireworks on the Fourth of July, I am responsible for tens of thousands of people who get seriously injured every year in accidents all over the world. And imagine the implications of having the wrong stance on gun control.. I must be a very bad man. - Alexis Jazz 11:14, 28 February 2018 (UTC)
  •   Support, but cautiously. I've added this template to a few categories (mostly places), and when it works it's magical. It interacts slightly poorly with some other templates, though, so I'd start by adding it to categories whose pages contain only parent categories and work up from there. --bjh21 (talk) 19:13, 1 March 2018 (UTC)
  •   Oppose for implementation reasons only. Striking oppose per threaded discussion. I'm normally not fond of adding more content to categories than is necessary to identify it, but this concept is so good for internationalisation that I have to drop my objection. Adding them manually, therefore, sounds like a great idea. But how is a bot supposed to know what's what? Sounds like you're adding it to a category that merely has a link to a Wikidata item; what if a category has a link as a means of clarifying something else, e.g. "Place X is a town in Galicia"? You wouldn't want to end up with the Galicia (Spain) data just because someone included a link to d:Q3908, its data page. Nyttend (talk) 11:50, 3 March 2018 (UTC)
    • @Nyttend: The bot would only add it to pages that have a commons sitelink on Wikidata, not just a link to Wikidata. That's the same sitelink that causes the interwiki links to appear in the left-hand bar. So for Galicia, it would add the infobox to Category:Galicia (Spain) as that's what is sitelinked - not any other page that happens to link to Q3908. Thanks. Mike Peel (talk) 14:05, 3 March 2018 (UTC)
      • Mike Peel, so you mean that it wouldn't get added unless the data page's "Commons category" section linked to the category in question? If that's the case, no complaints. Nyttend (talk) 16:21, 3 March 2018 (UTC)
        • @Nyttend: It's the 'Commons' link under 'Other sites' on the right (the other one is a property, not a sitelink), and it's only if that points to a category. But basically, yes. Thanks. Mike Peel (talk) 16:27, 3 March 2018 (UTC)
          • Okay, since it's merely doing it with pages that are already linked to the Wikidata record, you've shown my objection to be baseless. Thank you :-) Now that I understand it, I can see that it should be simple to implement. Nyttend (talk) 19:03, 3 March 2018 (UTC)
  • Note Given the support here (thank you all!), I've drafted the bot code and started a bot request at Commons:Bots/Requests/Pi bot 1 to ask for feedback on the code and any potential technical issues. Of course, this discussion is still running, and the bot run won't start until this discussion reaches a conclusion. Thanks. Mike Peel (talk) 23:57, 3 March 2018 (UTC)

Portraits of Wikimedians

A proposal: each positively contributing Wikimedian has right to keep one photo of self on Commons, not necessarily used on any wiki page within Wikimedia. Sufficient conditions for “positive contributions” should be one C-class (at least) article or few dozens good essential edits (not just spelling/grammar fixes). Here was a portrait of the guy who wrote Anumantharayan Kottai. Not really a huge contribution, but let’s stop, at last, this vandal deletionist DoS attack by the infamous troll condoned and even overtly supported by certain elements among legitimate Commons users. Which Wikimedia members does the community respect: those who build something, or those who destroyed others’ works and made provocations during their career? Incnis Mrsi (talk) 19:27, 16 February 2018 (UTC)

So you want to modify COM:INUSE? I'm perfectly fine with allowing personal images if they are used on user pages for identification purposes. That has long standing agreement and I'm all for that. I also for making exceptions. This particular case seems like a tad much though. If I'm getting everything right you are talking about Lalwilson007 who has all of four edits to Commons and a total of 16 edits across all projects. Tying it to article ratings is also not really going to work as those are not monitored and completely subjective based on the whims of whomever rates the page. I understand the DENY aspect of trolls. And to be honest, I'm not really all that comfortable with someone else taking over their requests. But that doesn't mean we should stop all such requests. Else the trolling can cause a lot more damage the other way. In short, if a legitimate user brings this to the attention of the greater community I'm not quite sure I'd agree with your point of view here. The photo wasn't even in use and it doesn't appear that the person has edited any project since May of last year. Again, I'm all for making exceptions but not really in this case. Blanket changes to policy like this are probably not the best option here. If you come up with a more tailored approach I'd probably support. Sorry. --Majora (talk) 19:46, 16 February 2018 (UTC)
  • Oppose. If a personal photo is not used in any wiki, what possible purpose does it serve then? --P 1 9 9   21:19, 16 February 2018 (UTC)
    If a photo is described correctly and categorized, then it can be found. It can be used now to make some impression of Wikimedia contributors and their diversity. Moreover, it will be of great use for future wiki archeologists (we can’t be sure whether deleted Wikimedia files or pages will be kept in databases indefinitely). Which purpose serve files, for example, from this category? Have they necessarily to be arranged in a gallery to be deemed useful? Incnis Mrsi (talk) 21:37, 16 February 2018 (UTC)
  •   Support, coincidently I wrote User:Donald Trung/Proposal on how to deal with personal images a couple of days earlier to propose here. --Donald Trung (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:24, 17 February 2018 (UTC)
  • How would you know, when looking at a photo, if it's the only one? There are already a lot of unused personal photos of Wikimedians, often large collections of them, which seem to be considered in-scope, e.g., if they are taken at a Wikimedia event, photos like File:Wikimania 2013 by Béria Lima 39.jpg, to pick a random example. --ghouston (talk) 03:14, 18 February 2018 (UTC)
    Mistakes due to incomplete information can happen. Had we a good-quality photo of Lal wilson J, I wouldn’t consider deletion of a portrait of him an indignified treatment of a Wikipedia contributor. But while nobody can present any evidence that Lal wilson J attended events extensively covered by Wikimedia, we should deem this photo very probably was unique. Incnis Mrsi (talk) 09:27, 18 February 2018 (UTC)
  •   Comment The amount of personal images uploaded to commons in a given day and not in use, or connected to a user page with no edits outside of that user page, in essence using commons as a webhost for personal files vastly outweighs the amount of personal files uploaded by active contributors regardless of the metric of "active" -- Sixflashphoto (talk) 19:41, 20 February 2018 (UTC)
    @Sixflashphoto: you appear to get the point missed by P199. Indeed, a vanity-only user may upload a portrait, set up a user: page and, if that page is not blatantly promotional, this portrait will linger indefinitely. Whereas a portrait of Lal wilson J was deleted on the INUSE technicality thanks to the troll’s activity. Incnis Mrsi (talk) 20:24, 20 February 2018 (UTC)
I agree with P199. If a personal file is uploaded by a user who is not active in any project it should be deleted. We are not and should not be a social media site. I nominate a lot of personal files for deletion, I just don't nominate any in use in any project. Personal files from vanity uploaders are not within the scope of the project. Really a lot of this could just be soled by carefully checking a DR before closing it as Delete. For instance say someone uploades a file having no contributions and not connecting the file to any project whilst within the week starts making a large amount of good edits to a project and connects the file to the User page. The nominator was not wrong for nominating the image (but should withdraw the nomination if new facts are presented) but the file should still be kept. As far as Lalwilson007, this user has 16 total edits across all projects-on en:wp only 3 were in the mainspace and on commons 1 file was not a photo of a person. The 2 photos of a person are not in use. This is not the hill to die on. Your other 2 case studies are better. -- Sixflashphoto (talk) 20:52, 20 February 2018 (UTC)
Meh, or apply commonsense, stick to being Mellow, and not delete everything it is possible to delete, especially when an inactive user seems to have always acted in good faith and the releases are correct. I'm pretty good at guesstimates, I'd say we were talking about perhaps 0.03% of the images on Commons might be described this way. If anyone wants to seek out media to delete, how about focusing on copyvios that are a problem that is a thousand times larger? -- (talk) 21:07, 20 February 2018 (UTC)
  • Oppose as written, but agree that it would probably be sensible to introduce a new CSD criterion (i.e. F10) which would allow for:
F10: deletion of personal images either unused or used only by a single user's namespace (in any number of projects), if that user is not also autoconfirmed in at least one project. This would be a minimum threshold, obviously, and others may be suitable for DR rather than CSD, but the objective criterion combined with existing definitions of "personal image" would likely cut down on a lot of the social media-style content we see uploaded on a daily basis. It also operates under the assumption that the autoconfirmed user right is implemented on most, if not all, projects (I believe it's a MediaWiki default, but could be wrong). — Rhododendrites talk |  00:50, 21 February 2018 (UTC)
@Rhododendrites: It appears to be a WMF default, please see the last paragraph of m:Registered user.   — Jeff G. ツ please ping or talk to me 02:21, 21 February 2018 (UTC)
Most projects define an autoconfirmed account as "existing" for four days. No edits required. I'm not entirely sure that is a good threshold here as it requires nothing more than an account on one of the projects that give out autoconfirmed that way. --Majora (talk) 02:40, 21 February 2018 (UTC)
  •   Oppose the actual policy is fine IMO Christian Ferrer (talk) 18:36, 21 February 2018 (UTC)
    The actual policy is a disgrace for “obscure” Wikimedians, a loophole for vanity mongers, and a boon for trolls. An irresponsible approach; especially sadly to see it from a Commons admin. Incnis Mrsi (talk) 19:19, 21 February 2018 (UTC)
  •   Oppose yet more deletion drama - don't trust DR? don't want a consensus? "this" is a disgrace? i guess we have different views of what commons should be ashamed. Slowking4 § Sander.v.Ginkel's revenge 14:07, 23 February 2018 (UTC)
  •   Comment @Incnis Mrsi: I would suggest something different. No strict "1 picture" limit, but a FUP. Users who have contributed a lot could have more non-educational images than new users. In addition: if a user decides to upload a photo of themselves, they must (also) upload one photo on which we can see the user is aware of Commons. This could be achieved in various ways, for example the user could write "Commons" on their hand and make a selfie which includes that hand, or we could agree on some hand gesture. But there is an infinite number of ways. I don't want another Ameily Radke. Admittedly this won't make any difference for existing images. - Alexis Jazz 18:38, 23 February 2018 (UTC)
    Alexis’s concern about “… es vato” pictures is grounded on personality rights and privacy. I advocate another cause, namely, to stop disparaging and disrespectful treatment of genuine Wikimedia contributors—who have hence a low probability to commit deliberate privacy violations and hoaxes. Whereas photoshops uploaded—with unspecified sources—by blatantly promotional zero-merit accs are frequently kept by certain sysops. Incnis Mrsi (talk) 18:58, 23 February 2018 (UTC)
    Partially. I may not have been completely clear, but if there would be a photo included on which it is made clear the person pictured is aware of Commons (or, for example, a photo exists of a Wiki meeting that also shows the person) that would make the pictures of that user ineligible for deletion, within a FUP. So it also achieves part of what your goal is, it just offers no solution for all the images from abandoned accounts uploaded so far. To be honest I'm not sure how useful it is to have those images around. I see no reason to delete them (they are not removed from the WMF drives, they still take up space) but I can't think of any good reason to keep them either. May I ask: why should such images be kept? If there is a good reason (for example, if the trolls are partisan when nominating abandoned pictures) I may support your proposal. - Alexis Jazz 19:27, 23 February 2018 (UTC)
  • Perhaps 1 unused personal photograph per 100 or 1000 edits? Anyhow I would   Support this as the policy needs updating. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:26, 6 March 2018 (UTC)
  •   Oppose changes to policy. Commons:Project_scope clearly states that "The uploading of small numbers of images (e.g. of yourself) for use on a personal user page of Commons or another project is allowed as long as that user is or was an active participant on that project." and I think that policy is sufficient. I would not have closed Commons:Deletion requests/File:Lal wilson J.jpg as "Delete", but I was not the one closing it. I assume it was deleted because it was not in use and did not meet requirements of the policy. However If someone wanted to actually use it, I think it would be fine to re-upload. --Jarekt (talk) 16:52, 3 April 2018 (UTC)
  •   Oppose the policy change. It's true that a well-categorized photo can be found without being on a user page, but if categories are the only place it exists, it seems like its usefulness is so limited that it's not worth bothering with. If this were to become policy, then image patrollers would have to waste their time perusing people's contribution histories to decide if their contributions are "good enough". It also creates an unnecessary gray area—I can foresee deletion requests where people are debating whether or not a user has made enough positive contributions. This is a silly thing for us to waste time on, especially since the user could just take 5 seconds to put the image on a page, and the whole discussion would become moot. –IagoQnsi (talk) 15:16, 12 April 2018 (UTC)

Proposal to stop Special:Upload and Special:UploadWizard from adding headers to file description pages automatically

The first annoying header uses code "== {{int:filedesc}} ==", which evaluates in English to "Summary". It only makes sense to have it if you have other headers.

The second annoying header uses code "== {{int:license-header}} ==", which evaluates in English to "Licensing". Licensing should be in the information or other template's Permission parameter.

This proposal builds on the work of multiple authors of COM:VP#Upload automatically adding section headings, including @Nyttend, Begoon, Perhelion, and is related to phab:T187302, wherein @ noted a lack of consensus for addition of such headers the first place.   — Jeff G. ツ please ping or talk to me 13:56, 28 February 2018 (UTC)

By "headers", I mean section headers or headings.   — Jeff G. ツ please ping or talk to me 19:02, 28 February 2018 (UTC)

Headers proposal !voting

  Support It's rather unclear to me where I'm supposed to stick my {{Trademarked}}, {{De minimis}}, license etc anyway. I think it looks better when those are in the permissions field of {{Information}}. - Alexis Jazz 14:44, 28 February 2018 (UTC)

  Oppose, at least in respect of Special:UploadWizard. The Upload Wizard constructs its own wikitext, and I think it's perfectly reasonable that it should include these headings, since doing so is in keeping with common practice on Commons. I'd need to investigate the behaviour of Special:Upload a little more to have an opinion on it, but I think it should be possible to use it in a way that causes the created page to contain precisely the text typed (or pasted) into a single text area. --bjh21 (talk) 16:39, 28 February 2018 (UTC)

@Bjh21: but these common practices are only common because that's what the upload pages do. We cannot make Y common practice because X is common practice. - Alexis Jazz 17:08, 28 February 2018 (UTC)
True. In that case my argument is simply that there's insufficient rationale given for causing a change in common practice. --bjh21 (talk) 17:43, 28 February 2018 (UTC)
@Bjh21: I am not proposing a change in how humans construct file description pages, only in how two pieces of automatic software do it. I think it is already acceptable for humans and other pieces of automatic software to avoid the section headers and put licenses in the permission fields.   — Jeff G. ツ please ping or talk to me 19:00, 28 February 2018 (UTC)
  •   Support unless you're using some setup that automatically adds headers. For example, if you're using Special:Upload and you don't specify a license in the free-text area, but you pick a license from the dropdown, it automatically adds a "Licensing" header, and in that case, the "Summary" header is useful. Surely it's not that hard for the system to detect whether the system is doing something. And if I understand rightly from Bjh21, the UploadWizard automatically has section headers, so that makes sense. But bjh21, I always paste my content directly into the Special:Upload box (I write it up in a Notepad file, and when I'm done I paste it in), and I'm always still getting the header. It's now impossible to avoid. Nyttend (talk) 22:55, 28 February 2018 (UTC)
  •   Oppose, these headers make it quite easy for novice users (especially for the UploadWizard), but if users with more non-conventional licenses and descriptions then this be able to be optionally removed, but not by default. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:55, 1 March 2018 (UTC)
@Donald Trung: A user who uses the Upload Wizard never even sees these headers? - Alexis Jazz 01:25, 1 March 2018 (UTC)
  •   Oppose I like structure. That's why we have categories. I'm not keen on huge undemarcated blocks of text. But licensing is not only highly important, it is critical to Commons. That's why it should have its own visible paragraph on the page, with an appropriate section header, rather than being buried in the information about location, description, photographer, source etc. I don't see a compelling case to change what we do, because I suggest it is helpful. Rodhullandemu (talk) 18:32, 1 March 2018 (UTC)
  •   Oppose I find useful the "edit" and "edit source" options this header displays ...when I need to fix something in the {{Information}} template. They come in handy. I'm used to embedding permission/licensing templates in {{Information}}, though. strakhov (talk) 18:39, 1 March 2018 (UTC)
  •   Support There is a long history behind these useless sub-headings. We can see in the documentation of Template:Information that "license" was initially placed in "permission". But when people started to use custome license tags which are big, some people in Commons didn't like it. They decided to move it outside the template "information" and "permission" is remained for uses like OTRS and other markings. This makes the permission parameters split into two places and less informative to re-users. Who knows what the difference between "permission" and "license" with entirely different information in two different places? Fortunately I'm using cusom upload templates and place all licensing information (license, other non-copyright warnings, FOP and any other information) in one place "permission". Jee 06:51, 2 March 2018 (UTC)
    @Jkadavoor: Right, the licenses available for selection by users using these tools should not be so big as to require placement outside the "permission" field.   — Jeff G. ツ please ping or talk to me 10:31, 2 March 2018 (UTC)
  •   Oppose I find much better to separate legal information (license, trademark, FoP template, etc.) outside of the description. The headers could be displayed or hidden automatically with CSS when we will have structured data, but keep them for now. Regards, Yann (talk) 08:27, 2 March 2018 (UTC)
  •   Oppose - the license does not belong to the permission field. Did you know that is disappears when using the script for an OTRS tag if the license is there? The permission field is for permission information. - Jcb (talk) 08:35, 2 March 2018 (UTC)
    @Jcb: That would be a bug in the script for an OTRS tag.   — Jeff G. ツ please ping or talk to me 08:47, 2 March 2018 (UTC)
    If you want to place license out side of "information template", please place the OTRS permission, license review, etc. too below it. Please don't put related information scattered into several places so that reuser need to be a gymnastic to club all these pieces of information. We have plenty of license tags with OTRS and/or license review merged with it. Jee 09:36, 2 March 2018 (UTC)
    I did not write the scripts, but the current situation (already for years) is that if you apply an OTRS received or PermissionOTRS tag with the script from the 'tools' menu, that the tag lands in the 'permission' field. Jcb (talk) 09:41, 2 March 2018 (UTC)
    @Jcb: I reported your 08:35 statement above in a bug report at MediaWiki talk:Gadget-PermissionOTRS.js#Removal of old contents of "permission" field.   — Jeff G. ツ please ping or talk to me 10:08, 2 March 2018 (UTC)
    (Edit conflict) I know. That's why I wrote above "there is a long history behind these useless sub-headings." It was not thus in the beginning; but introduced later without knowing the copyright requirements that TASL (Title, Author, Source and License) should be clubbed together to provide ideal attribution. Only recenty we started to take care of proper attribution. Many of us feel that current "information template" is inadequate and started using Template:Credit line to override this limitation. But it is difficult to inject that template in all our pages; the better solution is to keep "TASL" together in information template. Jee 10:19, 2 March 2018 (UTC)
  •   Support you can already do almost all what you want with the current template (or with one of its derivatives). No need of any header. Furthermore there is no TOC in files page, no need of different sections, even for a structural page concern. If the current template is not sufficient or not visually good, then develop it. Christian Ferrer (talk) 17:31, 2 March 2018 (UTC)
  •   Oppose, i see no harm. --Steinsplitter (talk) 17:44, 2 March 2018 (UTC)
  •   Oppose, per Yann and Steinsplitter. -- Tuválkin 15:51, 3 March 2018 (UTC)
  •   little oppose, if there's a way to make it possible in another way on mobile (I don't like the unofficial app, as I'm a fan of MobileFrontend view) I may consider support. --Liuxinyu970226 (talk) 13:01, 12 March 2018 (UTC)
  •   Oppose I prefer file pages with clearly delineated description and license sections. --Jarekt (talk) 16:28, 3 April 2018 (UTC)
  •   Oppose, very helpful --Schlurcher (talk) 03:29, 5 April 2018 (UTC)
  •   Support, in Special:Upload. I know I've been caught by the automatic adding of those headers before. It would be great if this more advanced form worked in a more predictable way. I have to abstain from any change one way or the other for Special:UploadWizard because I'm not as familiar with it, though I am inclined to vote to remove the automatic headings from there as well. ~ PaulT+/C 04:01, 16 April 2018 (UTC)

Headers proposal discussion

No, I've not. In fact this is the tool that, after to have generate all the appropriate templates and links, lead me to Special:Upload basic, I've not the choice. But my problem is minor, I just have to remove the header that is too much. It's really not much to do. Christian Ferrer (talk) 05:13, 2 March 2018 (UTC)
  •   Comment - This whole discussion seems to have been prompted by a couple of comments by Nyttend and myself to the effect that we didn't think Special:Upload (the manual form) should be adding the int:filedesc heading to every upload, because it's, you know, the manual form, and folks who use it really expect just what they put in the freeform field to be used, just as it used to be. Like Nyttend, I copy/paste wiki-text and having this unavoidable automatic addition is a bit inconvenient sometimes. At that point we were only talking about one thing that just started happening, just with the manual form. Somehow that has expanded to a discussion about the wizards, where licenses should go, OTRS scripts and all sorts of other things. It's all very interesting, if somewhat tangential to the point that seems to have initiated it... -- Begoon 16:45, 2 March 2018 (UTC)