Commons:Village pump

Shortcut: COM:VP

Community portal
Help desk Village pump
Administrators' noticeboard
vandalismuser problemsblocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{section resolved|1=--~~~~}} may be archived; for old discussions, see the archives.

Please note

  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page

Search archives


Water pump next to the church in the town center of Doel. Doel, Beveren, East Flanders, Belgium. [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch


NC-ND is allowed?Edit

Or ... what's going on? Can anyone explain? Ed [talk] [en:majestic titan] 01:53, 11 November 2016 (UTC)

Pinging Ritchyblack. Ed [talk] [en:majestic titan] 02:10, 11 November 2016 (UTC)
Free Art License is conformant. He's welcome to offer any other license in addition. - Jmabel ! talk 04:42, 11 November 2016 (UTC)
whenever you (Personal attack removed) want to stop the hybrid license nonsense, go for it. using the SA or NC ND to force email for reuse terms is particularly clever. or maybe an FAQ for the periodically incredulous. Slowking4 § Richard Arthur Norton's revenge 01:49, 12 November 2016 (UTC)
wow, kids is a personal attack? hillarious. stop the madness. or get laughed at. Slowking4 § Richard Arthur Norton's revenge 02:13, 22 November 2016 (UTC)
Shouldn't there be wording to state that the end user can re-use the image under either license? I don't delve into the dual licensing stuff much, but it seems like the use of such a template couldn't force an end user to re-use under both licenses? Huntster (t @ c) 21:45, 13 November 2016 (UTC)
Deletion If these media are actually licensed with NC-ND, then they must be removed from here. The uploader can relicense them to make them more free but we cannot host them. —Justin (koavf)TCM 21:52, 13 November 2016 (UTC)
That's not true as I understand it. So long as the end user has the option of a free license to use, any number of other licenses (free or otherwise) can be included with the image. That's my whole question here: that template, and any others like it, need to make it clear that the end user can choose which license to use, and that they don't have to abide by both (or more) licenses. Look at some of the templates in Category:Multi-license license tags, for example, which do it correctly. Huntster (t @ c) 00:05, 14 November 2016 (UTC)
I would agree with you if there was more evidence this is confusing. I didn't think there was, but it is concerning that one of the most prolific Wikipedia editors of all time is confused by it. That said, even templates like {{Dual-gfdl-cc-by-sa-any}} don't make this point explicitly. If we must mandate clarification, I'd start with templates like that first. Storkk (talk) 10:12, 14 November 2016 (UTC)
Can we come up with standard text that says something like "You can choose one or both of the following licenses: "? Also, can an admin unprotect this? Ed [talk] [en:majestic titan] 18:48, 15 November 2016 (UTC)
This should be a variant on {{FAL or cc-by-nc-nd}}, for just the specific BY-NC-ND version. Reventtalk 17:33, 16 November 2016 (UTC)
don't know why you would want to undo the protection by banned users. how about a survey of protection and unprotecting as appropriate? Slowking4 § Richard Arthur Norton's revenge 02:16, 22 November 2016 (UTC)
@Slowking4: I'd just like to make it clear that you can choose one of the licenses. That's not clear at all right now. Ed [talk] [en:majestic titan] 01:27, 25 November 2016 (UTC)
hey, it is perfectly clear to me. it's the license purists who wonder at this hybrid nonsense. see also Commons:Deletion requests/User:Fir0002/credits why you won't go to CC for the future, and mark historical i don't know. and why an historical hybrid license is protected, i don't know. it is all very confusing and tl;dr. maybe an admin will wander in and fix the old license of someone who hasn't uploaded in 2 years. maybe a few more FAQ's are in order. Slowking4 § Richard Arthur Norton's revenge 01:48, 25 November 2016 (UTC)
@Slowking4: I'm glad that it's clear to you. It isn't to me and I suspect others, hence my request to unprotect the page so I can address it. Thanks! Ed [talk] [en:majestic titan] 19:18, 25 November 2016 (UTC)
It was also apparently unclear to Koavf just above. Would you describe him as a license purist or a clueless noob? Storkk (talk) 19:50, 25 November 2016 (UTC)
i will let you sort yourselves into which category you belong. all those people who voted keep hybrid licenses can fix their FUBAR. or the people venting unproductively on VP. clearly you cannot harangue the uploader since they are long gone. and i don't want to hear it. Slowking4 § Richard Arthur Norton's revenge 00:50, 26 November 2016 (UTC)
@The ed17: Before even considering messing with users' custom license templates, please consider gauging support for a change in templates like {{Dual-gfdl-cc-by-sa-any}}. I think the unprotection you requested is premature. Storkk (talk) 10:42, 26 November 2016 (UTC)
@Storkk: I would simply like the opportunity to add "Choose one of the following:" to the confusing license header. I'll be happy to start a discussion on other related templates when I have time, but this should be an incredibly uncontroversial action to prevent confusion. We're here to facilitate re-use, not confuse people. :-) Ed [talk] [en:majestic titan] 09:21, 29 November 2016 (UTC)
While you and Justin have indeed professed to being confused by this custom user license template, you have not demonstrated that we have enough of a problem, in my opinion, to unilaterally override the licensing choices of a user who could reply (if they were still here) that they were simply following well-established practices as indicated by templates such as {{Dual-gfdl-cc-by-sa-any}}. So no, I will not be unprotecting that template until there has been strong community consensus demonstrated that some kind of {{Dual license}} boilerplate is required for all dual licenses. I would certainly support adding clarifying wording to, e.g. Commons:Reusing_content_outside_Wikimedia/licenses except that it is already in the second bullet point. Storkk (talk) 10:47, 29 November 2016 (UTC)
@Storkk: Are we misunderstanding each other? In what way is clarifying that you can choose one of the templates "unilaterally overrid[ing] the licensing choices of a user"? I'm legitimately surprised that you are actively advocating to confuse users when there's an unequivocally easy solution. You'll note, I'm sure, that those dual-license templates don't actually link to Commons:Reusing content outside Wikimedia/licenses, so I don't see how that solves the issue. :-) Ed [talk] [majestic titan] 02:39, 5 December 2016 (UTC)
@The ed17: the choice of how to format and present the licensing was his. If you override it without his input and without a clear consensus to do so, I would call that "unilateral". I am struggling to understand why you think the previously mentioned Template-namespace templates are not confusing while these are, or why you are otherwise refusing to start there. Storkk (talk) 10:13, 5 December 2016 (UTC)
@Storkk: These templates are meant to facilitate reuse, not confuse readers. Of course the other templates are confusing as well, but there's no clear place to start a discussion. It would seem like this issue applies to far more than just one template, so would this page not be suitable? Ed [talk] [majestic titan] 22:21, 7 December 2016 (UTC)
@The ed17: Sure, this page is fine. Storkk (talk) 22:34, 7 December 2016 (UTC)

New tool to transfer files from enwp to Commons - MTC!Edit

I've created a new tool, MTC!, to transfer files from the English Wikipedia to Commons. It's only the second release, but it works reasonably well, so I'm advertising it for a public beta. Please let me know if you find any bugs. Thanks, FASTILY 23:20, 20 November 2016 (UTC)

Nice tool, I'm gonna try that tool which seems to be better than CommonsHelper. Anyway, does this tool support bot passwords or OAuth? If not, this would be a problem, both in security and logging in. For security, I don't know if you knew this incident that happened recently, but a hacker group named OurMine hacked accounts with elevated rights (like sysop) in enwiki. Even Jimbo's account was hacked. So it seems that they could hack an account even with a strong password. In response to this, the WMF made 2fA (or two-factor authentication) available for admins, crats, oversighters, and checkusers. I am not sure if 2fA is working with third-party tools, but if not, then this would be a pain for users who have enabled 2fA who wants to try your tool. I think it would be great if your tool would support either bot passwords or OAuth. Thanks, Poké95 12:20, 21 November 2016 (UTC)
If you use a strong password and if you don't use the password on multiple sites there should be no issue or pwnage. --Steinsplitter (talk) 12:29, 21 November 2016 (UTC)
Yeah, but still a problem for those who have enabled 2fA already. They might not able to login to MTC! properly due to the complication of 2fA. Poké95 12:59, 21 November 2016 (UTC)
@Pokéfan95: Thanks for your interest! OAuth is not supported, but BotPasswords should work just fine. If you don't want to use BotPasswords, then you can always create an alternate account just for use with third party tools. -FASTILY 01:46, 22 November 2016 (UTC)

But please don't upload too much sh*t. Some files should better be deleted in enwp and never transferred.--Kopiersperre (talk) 11:05, 23 November 2016 (UTC)

Don't know why you would want to transfer files from english to commons, given the recent proposal to Commons:Village_pump/Archive/2016/10#Proposal_to_halt_all_unsourced_cross-wiki_transfers. Slowking4 § Richard Arthur Norton's revenge 14:49, 23 November 2016 (UTC)
There's a huge backlog of properly-licensed images at en:Category:Copy to Wikimedia Commons. clpo13(talk) 16:29, 23 November 2016 (UTC)
I'm sorry a backlog is not an argument. what specific steps will be taken to review, and put back images deleted? given the fact that the automated transfer process is noted to be a problem? for example here is another image without a url source File:C.J. "Gus" Loria, X-31 Pilot.jpg what will you do to see it is not deleted? Slowking4 § Richard Arthur Norton's revenge 14:45, 24 November 2016 (UTC)
The tool can verify such issues. I do not think it makes sense to completely ignore en.wikipedias freely licensed content that was mainly uploaded before commons existed. Streamlining the process with checks would help eliminate problems. It would be better system of manually doing everything (probably incorrectly too). It would also create a review backlog to verify the transfers unlike manual where we have no way to track the cross-wiki transfer. -- とある白い猫 ちぃ? 20:11, 30 November 2016 (UTC)
@Slowking4: The problem with the possible deletion of such an image (which is certainly, based on my experience with NASA images, a PD work) is just as existent with any other transfer method. The 'solution' is to hunt down the source in NASA archives, and that applies to many old direct uploads to Commons as well. Reventtalk 12:56, 4 December 2016 (UTC)
@Revent: You make it sound like we improve our standards over time... -- とある白い猫 ちぃ? 14:57, 4 December 2016 (UTC)

November 21Edit

November 25Edit

Thumbnails of large imagesEdit

Hi, Currently thumbnailing of very large images, like File:Map of Hindoostan, 1788, by Rennell.jpg, does not work due to a confirmation setting to prevent potential performance issues. In phab:T147992, MarkTraceur asks for a community consensus about changing this setting. What do you think? Regards, Yann (talk) 09:57, 29 November 2016 (UTC)

Hello Yann, I see no need for this (also that performance issue a community issue here). 66 MiB should not be to expect for end users, as we can see the old file you overwritten with the same MP gets rendered. There are also some other ways for this: Template:Compressed version (naming bit unlucky) and Template:Archival version. User: Perhelion 10:37, 29 November 2016 (UTC)
FYI, the issue is not 66 MB (we have many images above that), but the 182.99 Megapixel. Regards, Yann (talk) 10:43, 29 November 2016 (UTC)
PS: Yes the image has 183 Megapixel, so I guess you want a limit of 200 MP? As we can see the 183 MP seems not (alone) the limit? There is also Template:InteractiveViewer for Template:Large images.
The developers (or someone) should call first what is the actual limit, instead of ask us first what should be the actual limit. As we can see (mentioned by Zhuyifei1999) there are some images exceeding on "theoretical limit" by above and beyond. User: Perhelion 10:51, 29 November 2016 (UTC)

File:Royal Albert Hall - Central View Square.jpg is bigger both in megapixels (238.61 Megapixel) and filesize (84.29 MB) and thumbnails fine. Indeed the File Description page for that contains links to smaller versions such as 33% which use the thumbnailer. The thumbnailer will refuse to generate a 50% thumb as this is too large.

So I don't think the problem is or should be the size of the source JPG but the size of the generated thumb. I absolutely support the ability for Commons to host large JPGs and this map is an excellent example of highly educational large images. -- Colin (talk) 11:29, 29 November 2016 (UTC)

Yann, I think the correct spelling is Hindustan. Jee 12:18, 29 November 2016 (UTC)

Hi Jee, I know that the modern spelling is Hindustan. ;) Here I just copied the original title of the map. Regards, Yann (talk) 12:21, 29 November 2016 (UTC)
Oh! Then OK. I never know such a spelling existed. ;) Jee 12:37, 29 November 2016 (UTC)

Yann, MarkTraceur, I note that Benh has just nominated at Feature Picture Candidates the image File:Paris, mairie du 10e arrdt, hall 04.jpg. This is 450 megapixels and 151 megabytes. There are no problems generating thumbnails. (Btw, the image is intended to be viewed with a special 360 panoramic viewer). So I wonder what the bug was with Yann's image. I see now the image has a new version that works. Perhaps Yann's version was corrupted in a way that upset the thumbnailer. -- Colin (talk) 21:05, 6 December 2016 (UTC)

It's probably a progressive JPEG. A standard JPEG is broken up into 8x8 blocks and can be thumbnailed one block at a time; a progressive JPEG needs to be completely decoded before it can be compressed. --Carnildo (talk) 02:18, 7 December 2016 (UTC)

What do we need this guideline for?Edit

It might be interesting to see that we can upload a nude photo of someone taken in a bathroom without knowing if she is really consent with her photo on the net. This is while the most related guideline, i.e. Commons:Photographs of identifiable people, says consent of the model should be provided. If it's so, why can't we delete such photos referring to the guideline? What do we need the guideline for? Pinging User:MichaelMaggs for attention. --Mhhossein talk 13:31, 29 November 2016 (UTC)

Hi, thanks for the ping. I see that the DR was quite extensively argued, and that the conclusion was not one you agree with: perhaps because it was based on US law/practice which is very different from that of your own home country. If you believe that COM:IDENT ought to be modified, do make a specific wording proposal on the discussion page. --MichaelMaggs (talk) 14:11, 29 November 2016 (UTC)
What part of the official guideline do you believe mandates the use of model consent for images of nudes? Note that "Violet Sparks" is the name of a drag queen, and highly unlikely to be a real name. -- (talk) 13:47, 29 November 2016 (UTC)
User:MichaelMaggs: You're welcome. No, I'm not arguing based on my home country's law rather I'm using the guideline as a ground. Do you say that per US law, photos of identifiable people taken in private can be published on the net without the subject'd consent? --Mhhossein talk 10:33, 30 November 2016 (UTC)
This has been argued to death and you are using a strawman argument here. The point of contention in the DR you referenced was not whether photos of people in private places can be published without their consent, but whether we could assume that consent was given in this particular case. --Sebari – aka Srittau (talk) 10:44, 30 November 2016 (UTC)
"whether we could assume that consent was given in this particular case" is a self made criteria already fabricated by you. No law, no policy and no guideline allows us to make such an assumption. --Mhhossein talk 10:49, 30 November 2016 (UTC)
It's not a criterion, but it's what the discussion was about. To be honest, I don't see the point discussing this further with you, since you keep on arguing the same points over and over, even if it is explained why your assumptions and interpretations are wrong. --Sebari – aka Srittau (talk) 11:06, 30 November 2016 (UTC)
Leaving the discussion will be kind of you, as you insist on ignoring the explicit parts of the guideline related to our discussion. Thanks.--Mhhossein talk 12:21, 30 November 2016 (UTC)

Mhhossein -- This is fairly obviously a carefully-posed picture, not a candid snap. I slapped a personality-rights template on it (something which definitely should have been done before!), which should resolve most valid issues. On Commons, model-releases are necessary for commercial re-use of images involving identifiable people, or possibly for age verification in some cases, but not ordinarily for images such as File:Violet Sparks 2350.jpg... -- AnonMoos (talk) 19:33, 30 November 2016 (UTC)

Thanks for the comment AnonMoos. A question: What happens if that "carefully-posed picture" were meant to be printed on a magazine cover and were not mean to be published on the net? Where did you find that claim? When some photo is posted on commons it might be used for commercial' re-use. --Mhhossein talk 12:19, 1 December 2016 (UTC)
If someone outside Commons uses commercially a photograph which he doesn't have the right to use commercially, then that's usually a matter between the photographer and/or photographic subject and the mis-re-user -- Commons itself is not generally directly involved. Personality rights apply to the even most boring prosaic humdrum photos of living identifiable people. And paid models ordinarily do not have any control over where photos will appear. Any current magazine cover of a remotely prominent magazine will end up being on the Internet anyway... AnonMoos (talk) 12:57, 2 December 2016 (UTC)
Are you serious? Every one is allowed to freely use files on Commons for commercial goals! It's an established fact in our project. How could you say that the model is a paid one? Please discuss based on policies or guidelines. --Mhhossein talk 17:36, 2 December 2016 (UTC)
Everyone has the right to re-use Commons images for commercial purposes as far as copyright goes. However, there may also be NON-COPYRIGHT RESTRICTIONS which may further constrain what would be allowed by copyright alone. See Commons:Non-copyright restrictions, which declares itself to be an "official guideline"... AnonMoos (talk) 23:28, 2 December 2016 (UTC)
Good, then the pics should be deleted per official guideline: "Some non-copyright restrictions, for example defamation or child pornography laws, might make it illegal to host certain images on Commons. Such images are of course not allowed, whether they have a free license or not. The most important such restrictions are personality/privacy laws which do not allow photographs of identifiable people which were made in a private place, unless the depicted person gives permission." Clearly, we have no permission from the depicted person. --Mhhossein talk 11:35, 3 December 2016 (UTC)
  • Are you then suggesting that by that logic virtually all formal portrait photographs should be deleted, since they are typically taken in private places (photographer's studios, for example)? There is no reason to think the subject of this photo did not give permission for use of the photo. The issue isn't whether we have a written permission on file, but whether we believe such permission exists. And, unlike copyright, this isn't a matter where slight doubt is sufficient to say no. Commons doesn't have nearly as extreme a precautionary principle over personality rights as we do over copyright. - Jmabel ! talk 16:16, 3 December 2016 (UTC)
Not exactly. I'm suggesting that per COM:BLP, "personality/privacy not allow photographs of identifiable people which were made in a private place, unless the depicted person gives permission." There's no reason to think that such permission exists unless you can show it, albeit not by guessing or speculating, but by providing links to the permission. --Mhhossein talk 14:55, 4 December 2016 (UTC)
And how does that not apply to virtually every portrait photo we have? - Jmabel ! talk 18:20, 4 December 2016 (UTC)
I don't know/care, although they might also fall under this category. Per COM:BLP#Examples, and other parts of the guideline, "Nudes, underwear or swimsuit shots, unless obviously taken in a public place – even if the subject's face is obscured," typically need consent. --Mhhossein talk 04:58, 5 December 2016 (UTC)
  • @Kaldari: Could I have your feedback on this discussion please? Thanks. --Mhhossein talk 17:40, 2 December 2016 (UTC)

Mhhossein, please stop trying to wrongly influence our decisions. Carl Lindberg has explained you in very detailed words and in several places why these images are OK here. Thanks, Yann (talk) 18:06, 2 December 2016 (UTC)

And I explained why he was wrong every where. Sorry, you were unable to answer my question at the TP. Please let the discussion progress without being disturbed. --Mhhossein talk 18:10, 2 December 2016 (UTC)
@Mhhossein: I don't think anything is going to be accomplished here. If you have suggestions for tightening the consent guidelines, please propose them at Commons talk:Photographs of identifiable people. If you think the guidelines were wrongly interpreted or not applied, please create a new deletion discussion. I agree that this photograph is potentially in violation of the guidelines, but there are some mitigating factors. For example, the image is publicly published elsewhere by someone who appears to be a professional model photographer, so there is at least a plausible claim that consent can be assumed. Such discussions, however, belong at Commons:Deletion requests, not here. Kaldari (talk) 18:40, 8 December 2016 (UTC)
But please note that any DR has to provide new arguments. Considering the lengthy discussions at at least four different places, I doubt there will be any. --Sebari – aka Srittau (talk) 18:48, 8 December 2016 (UTC)
Sebari: I agree with about a requirement of a arguments.--Mhhossein talk 19:26, 8 December 2016 (UTC)
Kaldari: Please note that we had a DR on this. I invited you to the discussion because you had closed a similar discussion. --Mhhossein talk 19:29, 8 December 2016 (UTC)

Scripted & automated tasks on human accountsEdit

Thrice now my requests for higher access for my bot has been declined. We as a community should reach a decision on the matter because this is ridiculous.

Protected pages, bulk update of OTRS requests, bulk admin actions are all in the domain of bots. Not humans. There is a very disturbing trend of "just use your human account with higher access for bot tasks" as well as a number of bulk scripts that are regularly used by human accounts. Unauthorized use of bots like this should be discouraged (or even blocked/banned) not encouraged/required.

If we will not allow bots to freely update pages, I feel we should retire the bot flag.

  • I WILL NOT use scripted/automated bulk tasks under my human account.
  • I WILL NOT edit protected pages leftover from a routine bot task.
  • I WILL NOT manually process bulk OTRS permission requests where the ticket applies to multiple files already uploaded to commons.
  • I want to get stuff done without wasting my time on routine trivial tasks a bot can handle.

You LET bots upload files but you do NOT let bots update OTRS tickets in bulk.

-- とある白い猫 ちぃ? 15:39, 29 November 2016 (UTC)

If there are good and well defined reasons included in the bot request for the sysop rights to be applied, then it would be accepted. As far as I could work out, the reasons given appeared fairly ad hoc, rather than for well defined tasks that required the rights. I suggest rethinking your approach to the job you want to do, so that the request reads as specific and limited. -- (talk) 15:45, 29 November 2016 (UTC)
What you are asking is impossible. The very nature of bot use involves large number of files which means broad definitions which is turned down for being ad-hoc. If I identify a very limited scope then I am told to make the edits manually since it isn't that many files.
First I requested the global ability to edit protected pages (primarily to deal with protected double redirects on over 700 wikis), this was declined on the grounds of "no problems". Then I requested an admin flag here on commons to deal with protected pages on commons (for a number of tasks) which I withdrew when people opposed on the basis of "unnecessary" and "no higher access to bots".
Lastly, I merely requested OTRS permission which adds no special privileges. All the bot would gain would be to tag OTRS tickets. I am told to do them by hand or modify the commons abuse filter. This has a very specific and limited use. If we do not wan't bots to deal with routine tasks, what is the point of the bot flag.
-- とある白い猫 ちぃ? 15:46, 29 November 2016 (UTC)
Well, thank you for telling us what you are going not to do, but as in your previous requests I'm still missing a strong argument why we have to join the ultimate workflow of yours against all commons sense. Especially OTRS ticket additions should be noticed by the uploader on his watchlist, so using a bot flag here is a no-go for me. --Krd 18:17, 29 November 2016 (UTC)
@Krd: I am asking you to handle the manual labor for me since you decided this is not something the bot should do. It is a task my bot can perform within seconds which you do not allow. Your opinion is the law here. At the very least JUSTIFY your position. Give a strong reason why bots are not allowed in editing protected pages or bulk update OTRS tags. This is a routine non-controversial task. We never required strong arguments for bot tasks before. Why are you demanding it?
For example, please explain to me why the uploader needs OTRS tagging in their watchlist? Why would they not need to see re-categorization and other routine tasks? Why explicitly OTRS? If the files aren't tagged with the permissions license, they will be deleted as the permission known to the OTRS ticket isn't communicated to the file description page.
-- とある白い猫 ちぃ? 19:34, 29 November 2016 (UTC)
  • The bot in question is user:タチコマ robot. The declined request for bot admin rights is at Commons:Administrators/Requests/タチコマ robot. とある白い猫 I appreciate your interest in doing tasks with a bot. I hope that you understand that there has to be some regulation. Right now, I do not see either on the bot's page or in the request a description of what the bot will do. Can you point to at least 1-3 sentences of description of why you want the bot to have admin rights? Do you think this is too much to ask? It seems reasonable to me to request an explanation before rights are given. Is there a misunderstanding here? Blue Rasberry (talk) 18:37, 29 November 2016 (UTC)
    • @Bluerasberry: My bot has two roles. First is double redirects. The other is find and replace tasks. It has been processing these for years. The bot processes hundreds of thousands of pages for routine tasks per year. The bot cannot edit protected pages or update OTRS template in bulk. I don't want to go through hundreds of thousands of pages manually to identify the 2-3 protected pages and then perform a routine edit. Likewise I do not want to make 40 individual edits on OTRS tagging. The problem here is that I am unwilling to engage in manual labor that the bot can handle trivially. This is the purpose of bots. -- とある白い猫 ちぃ? 19:34, 29 November 2016 (UTC)
    • Just to clarify the lists on my plate are User:タチコマ robot/list(Ticket:2016112810007364 - 40 files) and User:タチコマ robot/list2(ticket:2016112110010603 - 35 files). -- とある白い猫 ちぃ? 19:54, 30 November 2016 (UTC)
とある白い猫 I still am not sure I understand. I see at Special:Contributions/タチコマ_robot the bot is already doing all sorts of tasks, and this use has been approved for a long time. If I understand correctly, that bot is not allowed to do those same tasks on protected pages, even though the task it does has nothing to do with the cause for page protection. Can you give an example of what you want the bot to do with OTRS templates? Is it already doing OTRS template work, or is this a new task and something that is restricted to admin bots? I regret asking you to do a manual example, but if need be, can you do one OTRS replacement to demonstrate what it is that you want the bot to do? I am not aware of what might be restricted to admins for OTRS templates. Thanks. Blue Rasberry (talk) 21:47, 30 November 2016 (UTC)
@Bluerasberry: Certainly, the bot is incapable of editing protected pages. Just like how ordinary users cannot edit protected pages. Pages are protected for all sorts of reasons but mainly for abuse (such as repetitive vandalism) or the risk of abuse (such as files used on main pages that are temporarily protected). If these pages happen to be in a group of files that are being updated, the bot will simply skip the protected pages. As per the Commons:Administrators/Requests/タチコマ robot decision, the bot will not edit protected pages. I have reviewed the ticket:2016112110010603 which grants us the ability to freely license the 35 files mentioned in the OTRS ticket. In this case, the bot would replace the {{OTRS pending}} template with {{PermissionOTRS}}. Only users with a global "OTRS Member" permission can modify this tag. "OTRS Member" permission does not offer any special access beyond that. The idea here is for the bot to perform a thankless repetitive task so that I do not have to. While the bot preforms those, I can focus on other tickets instead. -- とある白い猫 ちぃ? 02:42, 1 December 2016 (UTC)
とある白い猫 Okay, that checks out. You as a human will manually read OTRS tickets, and once you have made a human decision, then you will use the bot to automatically update the templates on a set of files. The problem you have had is that only accounts with the "OTRS Member" userright can edit these files, so since your bot has neither that or admin rights, then your bot has been unable to do this tedious task.
You have a record as an experienced and trusted user and have admin status on Commons. Your bot is approved to run, and you are a person who has had advanced rights, and you have described an appropriate bot function which requires advanced rights.
I looked again at Commons:Administrators/Requests/タチコマ_robot. If I understand correctly, Krd opposed the granting of rights because it is "not shown why manual bulk tasks cannot be done with the main account". I see a collection of tedious tasks waiting for this bot, including User:タチコマ robot/OTRS/2016112810007364, and as I understand changing the templates in this list is a noncontroversial thing to do and I also feel that it would be tedious to update these 40 files by hand. This seems like bot work to me, and the bot cannot do this or similar updates for sets of files without advanced rights.
Krd, it sounds like you had a concern about limits on the bot. Would you approve this bot to update OTRS templates on Commons as described here? What about this task makes you hesitate to support the granting of rights? Blue Rasberry (talk) 16:22, 1 December 2016 (UTC)
@Bluerasberry: That pretty much sums up what I hope to achieve. The two different OTRS tickets I have at the moment have 40+35=75 files total for the time being. -- とある白い猫 ちぃ? 19:46, 1 December 2016 (UTC)
とある白い猫 I might be offline for a few days but unless someone raises an objection, I advocate for your bot to get the userright. I read the previous opposition and I think the problem was that people wanted a clearer statement of what tasks the bot would do. If you were imagining that the bot would do anything controversial then speak up, but otherwise, this all seems routine and acceptable. You have my support. If I lose this thread ping me again. Sorry for the bureaucracy but you know how it goes here, and I will continue to advance the approval process. Blue Rasberry (talk) 23:19, 2 December 2016 (UTC)
@Bluerasberry: Not much happened sadly. -- とある白い猫 ちぃ? 16:11, 7 December 2016 (UTC)
So could I please have any response here? Aside from Krd whom rejected the notion of giving OTRS access to the bot. I do not understand the reason of this push back. I have bulk tickets to close positively. -- とある白い猫 ちぃ? 12:11, 9 December 2016 (UTC)

Governance of page protection rightsEdit

I am disappointed that several of our most active administrators have pre-agreed to re-raise two deletion requests, and ignore other files, by using a sysop-only protected discussion page. I raised an objection to this behaviour last week and it was brushed off as a "drop in a bucket". This use of the protection right is not an exception to COM:Protection policy.

It is strange and disturbing to see several administrators pre-agree with the original closing administrator [1] "I propose, and Revent and Jcb agree, that I open a new DR for each of the two, with the DR comment written as above. If you agree, after I post the DRs, you and the three of us will not comment on the DRs and will let them run their course entirely in the hands of our colleagues."

The outcome is a pre-agreed certainty, as any closing admin would have to have the chutzpah to go against the covert self-selected group decision, where only invited administrators could participate. Unfortunately behaviour like this makes a nonsense of the intent of deletion requests being an open consensus discussion.

It is worth noting that the new deletion nominations failed to mention this background, which if there was nothing to hide, they would have as there is long discussion, evidence and analysis on the admin-only protected discussion.

I suggest that an administrator, or 'crat, close the re-opened Deletion Requests without action, and invite those that have an interest in seeing these two files deleted, make a new presentation, openly and fully presenting the prior analysis and discussions that were held away from open talk pages.

I welcome opinions, including the administrators that took part in this effectively closed "pre-agreement", Yann, Jcb, Revent and Jameslwoodward who may want to explain why side-stepping open discussion was in the best interests of the Commons community and the correct use of sysop rights. -- (talk) 21:00, 29 November 2016 (UTC)

@Fae: Frankly, I was displeased by Jcb creating his 'private' discussion page, and if you look at it you'll see that my main input there, for most of the files, was to simply repeat what I had previously said at UDR, explaining why most of the various files were clearly ok. I suspect that, based on comments I have seen, none of the other participants were particularly happy about it, but as Jim pointed out such private discussions can happen off-wiki as well, so doing it on a talk page is actually a bit 'more' transparent... it's a talk page in Jcb's user space, so he has every right to ask that only certain people edit it (though using protection to enforce that was out of scope of the tool, IMO).
There was no 'agreement' to delete the images... the agreement was to allow the rest of the community to consider them at DR without us taking part, after we had tried to nail down the factual issues. I think not mentioning the previous discussion was in fact an attempt to not bias that discussion... saying we will not take part, and then pointing out where we had talked about them, would be rather counterproductive, and if a closing admin was unaware of the previous discussion then he would not be overruling it. Jim's DRs mentioned the actual factual information about the files themselves, without the previous drama, and the scope of DR is to determine the status of the works themselves, not to sort out who was right or wrong in previous actions. Your edits to those DRs in fact make it less likely, IMO, that any closer will impartially look at the status of the works themselves.
If you think that it is my opinion that both images should be deleted, you are mistaken. Reventtalk 21:26, 29 November 2016 (UTC)
The problem began when an involved admin decided to disallow the DRs and to speedy close them. Every step from there was avoidable if the first error would not have taken place. Jcb (talk) 22:14, 29 November 2016 (UTC)
Just to be clear on this point, you are blaming Yann for forcing you to make a discussion page protected against the community agreed policy that governs your sysop rights? That seems, surprising as a justification. -- (talk) 22:20, 29 November 2016 (UTC)
does not surprise me at all: it is always the other editor's fault. the vandals made be become an asshole. fundamental lack of ownership of behavior. Slowking4 § Richard Arthur Norton's revenge 17:39, 30 November 2016 (UTC)

I think Fae has this whole situation wrong. Certainly there is no pre-agreed deal here. I proposed to Jcb, Revent, and later to Yann that I open a new DR with specified language precisely because the four of us disagreed rather forcefully about the images. The four of us have agreed not to comment at the DR in order to leave our colleagues the opportunity to make a decision without our disagreement coloring it.

Although I agree that the protected discussion was probably not a great idea, there is nothing in the rules that would have prevented us from having a private discussion by e-mail, so I did not take Fae's original complaint to me very seriously. As it is, having the discussion on Jcb's sub page means that all of the discussion is on the open record here, rather than being on private e-mails. .     Jim . . . . (Jameslwoodward) (talk to me) 23:01, 29 November 2016 (UTC)

No exception has been put forward, the protection policy is not advisory. It states "This page is considered an official policy on Wikimedia Commons. It has wide acceptance among editors and is considered a standard that everyone must follow."
If you feel this is too much, then make a proposal to change it. In the meantime all administrators are required to comply with it. -- (talk) 23:08, 29 November 2016 (UTC)
hey, i think it's great that they chose to disclose the decision they pre-agreed to. just let us know if you all want to keep the files. let's dispense with DR and the folks can just let us know which files they choose to delete, dispense with any discussion. and i see the doubting of sources of low risk items continues.
"Protected "User:Jcb/temp": To prevent drama, talk page is open " you may delude yourself that misusing page protection prevents drama, but rest assured, this is why commons has such a low reputation. the childish behavior tends to undermine what little credibility you may have had. the mass upload tools work just fine on english. Slowking4 § Richard Arthur Norton's revenge 03:31, 30 November 2016 (UTC)
@Slowking4: Just to be clear, who exactly are you criticizing? Jcb, for protecting the page (which I agree was out of scope for protection), or the rest of us for engaging in the discussion without wheel-warring by unprotecting the page? Reventtalk 08:28, 5 December 2016 (UTC)
that is a blanket condemnation. you can count yourself in. when you countenance open abuse of admin tools, then you are complicit in the conduct against policy. either desysop the disruptive admin, or you are part of the problem. and personalizing the negative feedback is part of the problem also - just to be clear. Slowking4 § Richard Arthur Norton's revenge 19:46, 7 December 2016 (UTC)

November 30Edit

Clarification of the Precautionary Principle for 100+ years old photographsEdit

I have been chasing up on some deletions of old photographs where there has been confusion on the use of the terms "anonymous", "unknown" and "publication" in various national copyright acts, some of which have no clear statements about works with unknown artists (or orphan works). It is a truism that almost any old photograph with an unknown photographer can be put up for deletion, and using the weak arguments that we have not "proven" a specific date of publication or we cannot "prove" that the photographer is unknown (which puts aside that we have been unable to "know" the photographer and instead demands proof of a negative) can easily result in losing what is almost certain to be public domain material. The consequence of these types of weak deletion arguments is that we invest significant volunteer time in debating obscure copyright law over the meanings of these words, rather than focusing on whether reasonable effort has already been made to determine copyright, which is all that is ever legally required to host images on Commons.

I propose the following clarification to Commons:Precautionary principle:

For photographs demonstrably 100 years old or more, where reasonable effort has been unable to determine the name of a photographer or a claim of copyright, the default presumption is that the level of doubt is not significant that reproductions and scans of photographs are in the public domain.

This clarification puts Commons and the Wikimedia Foundation as the project's host, at no legal risk, so long as whenever challenged with a reasonable assertion of copyright, photographs are reviewed in a timely manner, or taken-down as a precaution.

I am proposing this on the Village Pump rather than on the policy talk page, as the level of interaction there has been almost non-existent for past proposals. Thanks -- (talk) 10:17, 30 November 2016 (UTC)

To have any sensible discussion you also have to take account of geography. In Europe all postcards without an authors name on it are considered orphan works and we have a European law covering this: This is the Anonymous-EU license, used for an enormous amount of uploads. As this is mostly local content the US license is irrelevant. In the past some American Wikimedia busybodies have deleted some of this EU content based on US law concerns, without bothering to look at the usual practice. Its legal in Europe and there is no legal risk. Once a work can be attributed to an author it is no longer anonymous. Anyway there where no records kept by the postcard editors. They used the work of local photografers or send someone to the region to take pictures. (And then cleaned the old archives for space) An archive of for example Nels postcards would be of great value to historians but it does not exitst.Smiley.toerist (talk) 22:58, 30 November 2016 (UTC)

  • Symbol support vote.svg Support as proposer. -- (talk) 10:17, 30 November 2016 (UTC)
  • Symbol support vote.svg Support, with the modification that we should design and require a template that points out this fact, instead of just using some existing PD-old template. (Also, I think this should be a formal RFC.) --Sebari – aka Srittau (talk) 10:38, 30 November 2016 (UTC)
  • Symbol support vote.svg Support though we should also have a solution for image from European National Archives from the range 70-100 years old that don't list an author for example. (Clearly PD-anon-EU of course but still, EU copyright law is confusing so I rather take away as much beans as possible :p) Natuur12 (talk) 14:18, 30 November 2016 (UTC)
100 is slightly arbitrary, however it is easy to remember. As per Srittau's suggestion if we have a general template explaining the no-copyright-known equivalent, this can say it applies to apparent 100+ year old photographs, but also encompasses a couple of other situations where any risk is well below our community understanding of "significant" doubt. Plus the template could provide a help link for anyone with copyright information to supply and does not want to spend time understanding how deletions work etc. -- (talk) 14:26, 30 November 2016 (UTC)
  • Symbol oppose vote.svg strongly oppose adding to Commons:Precautionary principle. I have no strong opinion wrt adding it to the correct place which is Commons:Licensing#Material in the public domain. A "principle" is "a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning." Thus our guidelines and policies on what material we host are derived from that principle, and others such as The Definition of Free Cultural Works. Let's keep it simple: "The precautionary principle is that where there is significant doubt about the freedom of a particular file, it should be deleted." That's all we need to say. The specifics of how to handle 100-year-old files goes in guidelines and policy pages that build on that principle. -- Colin (talk) 17:10, 30 November 2016 (UTC)
  • Based on Carl's comments below, I change my vote to also oppose the text in any location. It's clearly one of those "for every complex problem there is an answer that is clear, simple, and wrong" situations. Any guidance would need to be country-specific at the very least. -- Colin (talk) 20:23, 9 December 2016 (UTC)
Please read m:Polls are evil for why discussion is far more important than jumping feet first into a poll. -- Colin (talk) 17:10, 30 November 2016 (UTC)
  • Symbol support vote.svg Support --Yann (talk) 17:24, 30 November 2016 (UTC)
  • Symbol oppose vote.svg Oppose I'm with Colin here. This might be a good policy, but not as an amendment to the precautionary principle. - Jmabel ! talk 20:37, 30 November 2016 (UTC)
  • Symbol support vote.svg Support 100 years is a conservative line. , you recently started a discussion to ask about drawing a line in time, and it came to agreement that 100 was a good place, right? Can you link to that older discussion? I am not sure that I understand Colin. It sounds like the objection is confusion about the word "principle", and if that is a loaded term which has more meaning than only the text in the body of the page, then the title of the page could be changed from "precautionary principle" to "precautionary policy" or any other neutral term. "Precautionary principle" is a cliche term with a history of use, and personally, I think that many users will recognize the meaning of that term and understand that it has a special meaning and is not really a principle at all. Still, Commons is a multilingual platform, and perhaps the title should use simple English without any cliche. In that case "principle" might not be the right term for the content of that policy. We do not even have a "principle" designation in Commons - it is not a term which applies to anything here. Blue Rasberry (talk) 21:57, 30 November 2016 (UTC)
User:Bluerasberry there is no confusion in my mind or on Commons as to what "principle" means. I suggest you look at the place where I suggest this amendment might reside, and you will see that it obviously fits in another policy page which deals with specific examples that derive from our principle. The suggestion by Fae should have been done as a discussion rather than a poll, where the community together would come to a consensus as to how to clarify our position. Polls are evil. -- Colin (talk) 22:24, 30 November 2016 (UTC)
Okay, that seems reasonable. I think this is where I am -
  1. Post the statement to Commons:Licensing#Material in the public domain (or propose to do so). One place is as good as another, and this place seems like a repository for all the rules
  2. In Commons:Precautionary principle, change " The precautionary principle is that where there is significant doubt about the freedom of a particular file..." to "The precautionary principle is that where there is significant doubt about the freedom of a particular file..." We have a system for determining "significant doubt", and it seems to all be at Commons:Licensing#Material in the public domain. By making this change, we preserve the text that is well supported but also make room in a more appropriate forum for more development. I think that typical readers of that policy will want to know how we determine significant doubt, so it seems fair to connect that phrase to an explanation.
Blue Rasberry (talk) 23:08, 30 November 2016 (UTC)
I think this discussion should stick to adding a clause to the COM:L section where it fits. The precautionary principle applies to far more than whether an item is in the public domain so linking "significant doubt" to that section of COM:L is not appropriate. The point of a principle is that it is just a principle. How we determine "significant doubt" is not fully described in policy or guideline. The above proposal is an example of a presumably common issue for which some community consensus can be agreed. There are many other cases where "significant doubt" must be determined on a case by case basis and community consensus at DR. The link suggestion you propose, where "typical readers of that policy will want to know how we determine significant doubt" is unhelpful as we deliberately don't want to attempt to describe every determinate of "significant doubt". Trying to do that might lead to someone saying "This isn't one of the policy cases of significant doubt". -- Colin (talk) 09:11, 1 December 2016 (UTC)
Colin I agree that we "deliberately don't want to attempt to describe every determinate of 'significant doubt'", but right now, some determinants exist on another published page and other ones exist in the minds of Commons users. None of the policies and guidelines are perfect, so in cases where we have some published guidance, then I think we should link to it for the sake of helping people who do not already have the culture of the matter in their minds.
If we use an odd term, like "significant doubt", then I think it is fair to connect that term with the best information community has published on the topic. As I mentioned before, I am ready to acknowledge Wikimedia Commons Commons:Policies and guidelines because we gave those terms meanings here. I am not ready to hold another class of concepts, "principles", in a special higher regard because we have not come to any agreement that "if something is a principle, then we keep it simple, and do not link it to further explanation". I do not agree that "significant doubt" is a universally understood concept and I think that either it can be explained on that page, or that it is fine to link to an explanation elsewhere.
I would support the addition of whatever disclaimers are necessary to emphasize that your concerns are serious - "not fully described", "must be determined on a case by case basis", no one should use the stated rules as an authority over community consensus, and I would even agree to warnings like "this guidance is confusing and problematic", because even good text is so difficult to interpret. Still, we should present the best that we have. Blue Rasberry (talk) 14:14, 1 December 2016 (UTC)
Bluerasberry, with respect, the Precautionary Principle has been around since 2008, added by MichaelMaggs, and the community has not felt the need to alter it much nor have any problem with trying to fit it into concepts from Wikipedia. To be honest, this proposal never should have suggested changing that page and in fact the proposed sentence should contain a link on "the level of doubt is not significant" to the PP. So this is becoming a distraction and I'd rather leave fussing about exactly what words to use to those who nominate, review and close our deletion reviews on a regular basis. -- Colin (talk) 15:31, 1 December 2016 (UTC)
  • Symbol support vote.svg Support you cannot prove a negative, the wording has always bothered me. --Richard Arthur Norton (1958- ) (talk) 01:19, 1 December 2016 (UTC)
  • Symbol oppose vote.svg Oppose The global solution to a regional specific problem is just too glib- we have a vast archive of images that we want and have a duty display, and we are failing to understand that law in some countries is interpreted in a different way. I'm with Colin here.--ClemRutter (talk) 11:41, 1 December 2016 (UTC)
  • Symbol oppose vote.svg Oppose 100 years is too small, a photographer who take a photo at 20 year old and died at 80 years old, the photos is then protected until 30 years more after the "100 years" has passed. + unknown is not the same as anonymous, an anonymous publication is made with evidences, without those evidences no one can say a publication was anonymous. Christian Ferrer (talk) 12:35, 1 December 2016 (UTC)
  • Symbol support vote.svg Support I have suggested this in several places. However, I agree that PRP may not be the place for it and that this may not be the place for the final discussion on such an important topic. And we certainly need a new template, much as {{PD-Art}} codifies our use of the Bridgeman decision.
Christian, I agree that there is a reasonable chance that a hundred year old image is still under copyright. I have been using 120 years as the period beyond which we could assume, without a significant doubt, that the copyright had expired. And, of course, by stretching hard you could argue that almost any photograph might possibly still be under copyright (10 year old takes photo in 1845 and lives to be 111). However, I think that at 100 years we are so far back that the likelihood of a problem approaches zero -- it is certainly less than the likelihood of a problem with any image uploaded by an unknown person as "own work" when we assume good faith.
More broadly, we often deal in uncertainties here. We approve OTRS messages that purport to be from the copyright holder if they feel credible. We accept claims of "own work" all the time. I can't prove that most of the images I have uploaded are, in fact, "own work" and the same is true of almost all the "own work" images we accept. We accept them because it is policy to "assume good faith" and because we believe the risk is low. So we are frequently balancing the risk of a problem against the reward of keeping an image. .     Jim . . . . (Jameslwoodward) (talk to me) 14:00, 1 December 2016 (UTC)
And I suppose their is less of a problem now with the frequent use of take down notices. Most are accepted and the material deleted, problem solved and no risc as long as sufficient provenance research is done. It is fairly theoretical anyway. Once the author is dead, it is very unusual that the descendants know that this picture is taken by their father. Certainly if it is an ordinairy picture among the many.Smiley.toerist (talk) 14:24, 1 December 2016 (UTC)
  • Symbol support vote.svg Support clarification but Symbol oppose vote.svg Oppose adding it to Commons:Precautionary principle. --Jarekt (talk) 15:39, 1 December 2016 (UTC)
  • Symbol support vote.svg Support the abuse of Precautionary makes this necessary. if certain people would refrain from abusing "source missing", this would not be necessary. shifting the burden upon long gone uploaders tends to undermine the credibility of commons. Slowking4 § Richard Arthur Norton's revenge 02:12, 2 December 2016 (UTC)
  • Symbol oppose vote.svg Oppose adding this to COM:PRP, but Symbol support vote.svg Support documenting this in general. Any further clarification as to what the community considers to be 'significant doubt', so as to minimize the disparity between different closes based upon the opinion of 'who closes it', it is a good thing, but the PRP itself should remain as simple as possible. Reventtalk 08:44, 5 December 2016 (UTC)
  • Hrm. I think, in general, we often do assume that photos are published in the era they were taken, unless there is documentation or indication otherwise (photo came from a photographer's private archive, for example, or from heirs of the artist). I think the unpublished situation for photos is more of a theoretical doubt, not a significant doubt, in terms of COM:PRP, most of the time. Assuming anonymity is a lot harder though, for me. Orphan works suck, but that doesn't help someone if they use a work from here and it turns out the original publication was in fact attributed. You do need to have some evidence that a photo was published anonymously in many cases. Sometimes there is a name, so it's definitely not anonymous, and we just don't know life dates. And the 100-year limit on its face may not comply with U.S. law -- if truly unknown, then the U.S. term is the earlier of 95 years from publication or 120 years from creation, so 120 would be a safer limit if we are going to assume anonymity. Yes, if we assume publication it would only be 95 years, but that's a double assumption then -- if we are going to have a fixed cutoff, we may want to be more on the conservative side there. 100 years is really not long enough to assume that a 70pma term has expired (might be better for 50pma countries). I think that is why we have never had an explicit cutoff -- a "sensible" line can change a lot based on the laws in the country of origin, and their specific terms. For the U.S., photos that old are usually published and therefore OK, so this is more a country of origin issue. It might be hard to make a generalized rule though that is good for all countries. Carl Lindberg (talk) 17:28, 9 December 2016 (UTC)
  • Symbol oppose vote.svg Oppose - 100 years as a general rule is way too short. Many countries have a PMA+70 rule, so that a picture easily still can be copyrighted if it's 100 years old. Also there are even countries with a longer copyright, e.g. PMA+100 in Mexico. Jcb (talk) 17:45, 9 December 2016 (UTC)
    • Just as a side mention, I think 80pma is currently the longest actual effective terms (Spain for the most part and Colombia). There are some countries which are transitioning to longer terms by just putting a freeze on expirations until they get there (Mexico as mentioned, Cote D'Ivoire, Jamaica just recently), but their effective terms are lower since they are in transition. For example, Mexico was 30pma until 1982, and the increases to 50pma, 75pma, and 100pma were all non-retroactive I believe, meaning the actual cutoff line there is died before 1952 -- so basically 64pma this year, 65 pma next year, etc. It will be a while before those longer terms have actual meaning. (Mexico also had a registration requirement before the 1950s so even then a lot of works became PD anyways.) But 70pma is very common, and 100 years is a bit short for that, I agree. Carl Lindberg (talk) 20:15, 9 December 2016 (UTC)

Not in PRP?Edit

Hi, I noticed that several people agree with the proposal above, but said "not in the Commons:Precautionary principle". @Jarekt, Jmabel, Colin, ClemRutter: So where do you propose to add this?

To be clear, I think the above discussion should stick to whether we agree or not with the principle, and then discuss here where do we add this agreement if it reaches a consensus. Regards, Yann (talk) 20:34, 1 December 2016 (UTC)
For the record, I also think that COM:L is a better place (maybe with a reference in PRP), but in the end I don't think that it matter much. What matters is the rule. Details can follow later (per Yann). --Sebari – aka Srittau (talk) 20:37, 1 December 2016 (UTC)
Pretty much with Sebari on this (and I do think this probably deserves an RFC). I can go either way on the proposal, but I don't want to see Commons:Precautionary principle start to get cluttered up with a bunch of specific rules. - Jmabel ! talk 01:45, 2 December 2016 (UTC)
@Clindberg: As the person here I respect most on copyright matters, do you have any comment on this? - Jmabel ! talk 01:48, 2 December 2016 (UTC)

Pre 1923Edit

We are in year 2016 as of this post. 100 years prior would be 1916. We treat content before 1923 as in the PD under {{PD-old-auto-1923}}. This is a matter to consider based on the laws and regulations when we reach 2023. Like many I expect a massive change in copyright law by 2019 based on the age old pattern. If such a massive change does not happen, that alone is a massive change. -- とある白い猫 ちぃ? 19:15, 2 December 2016 (UTC)


For reference, I created Category:Deletion requests of old files with unidentified authors, where we can collect these kinds of DRs. --Sebari – aka Srittau (talk) 13:53, 6 December 2016 (UTC)

Proposed special page: File pages without filesEdit

Hello.I propose creation of a special page titled "File pages without files" Includes any file page created by mistake or redircts in file namespace and be:

  1. local includes only local pages
  2. Global (here) consists of: a section for local files and a section for commons files

This helps to delete the unhelpful pages.I do not know how I suggest this in any technical website but I think it's a useful proposal.Thank you --ديفيد عادل وهبة خليل 2 (talk) 16:14, 1 December 2016 (UTC)

This could be worthwhile, and it probably can be implemented if there is interest. Some thoughts:
  • Commons has some File pages which are intentionally left without files and protected (example: File:Untitled.jpg).
  • There are many redirects in the File namespace, since we rename files all the time. I don't think a list of them all would be very interesting. (We don't have a special page for this, but you can view them using the API: [2].) If anything, I would be curious to see pages which are redirects and also have an uploaded file, since that would clearly be a mistake.
  • I don't understand what you mean with the local/global distinction? For what it's worth, on wikis that use Commons as file repository, pages in File namespace without a file are quite common (e.g. for files that are "featured" locally, but uploaded to Commons – example: pl:Plik:!-tylewice-wiatrak-windmill-abri-2013.jpg), so I'm not sure if the proposed special pages would be useful outside of Commons.
Matma Rex (talk) 21:35, 1 December 2016 (UTC)
I don't think a special page is necessary. I have a quarry query to identify just this issue. Unfortunately it does not work just yet as the query takes more than 30 mins (current limit). I will try to resolve this issue. -- とある白い猫 ちぃ? 19:18, 2 December 2016 (UTC)
Isn't that a bit complicated? Something like
SELECT page_title FROM page LEFT JOIN image ON page_title=img_name WHERE page_namespace=6 AND page_is_redirect=0 AND img_name IS NULL LIMIT 20;
seems to work and returns some files in Category:Commons prohibited file names. Haven't tried it without a limit. Multichill (talk) 20:19, 2 December 2016 (UTC)
I wanted to limit sizes to with the complicated query so that the join is over minimum number of rows. It keeps exceeding the 30 minute limit so I get nothing back. :( -- とある白い猫 ちぃ? 23:22, 2 December 2016 (UTC)
What I have currently User talk:とある白い猫/Sandbox 2. -- とある白い猫 ちぃ? 18:08, 3 December 2016 (UTC)
The query is simple to write, but if you change LIMIT 20 to something more practical, it will take hours to run because it has to scan all the file pages in existence (some 35 million of them). I don't actually see how to do this performantly. Matma Rex (talk) 13:21, 5 December 2016 (UTC)
@Revent: :P -- とある白い猫 ちぃ? 18:12, 3 December 2016 (UTC)

I run Multichill's query with limit of 100 DISTINCT files and tried few other queries and they returned:

  1. Files in Category:Commons prohibited file names
  2. about 20 file description pages without files, which I deleted
  3. file redirects that someone is proposing to delete, like File:Villa Vassilieff @ Montparnasse @ Paris (30836586630).jpg
  4. image subpages, like File:Red-billed toucan at Birdworld 01.jpg/Series
  5. ~560 false alarms, like File:War Memorial, Nelson Square, Bolton (3).JPG or File:War Memorial, Tealing - - 1628939.jpg or files where img_name should not be null. Most of those have filename starting with "War Memorial".

--Jarekt (talk) 16:46, 6 December 2016 (UTC)

2016 Community Wishlist SurveyEdit

Just a quick reminder that the 2016 Community Wishlist Survey is running (currently in the voting phase). There is a CentralNotice banner campaign promoting it, but many users have those hidden… I have not seen many of you who are active here comment on it yet. Voting ends on 12 December.

You're most likely to be interested in the following categories (but also check out the rest on the home page):

The survey is used for prioritisation of work by Community Tech and other WMF teams. You can see the status of the most-supported proposals from last year on 2015 Community Wishlist Survey/Results. Matma Rex (talk) 21:10, 1 December 2016 (UTC)

To make it more fun (in case some of us are not really willing to click the links by hand to get an idea of what this is about), here are the full lists:
  • 1 Searching for images in nested categories
  • 2 Semi-automatic photo description and categorization tool
  • 3 Improve load time of RenameLink gadget
  • 4 Tool for mass downloading files
  • 5 Upload wizard for uploading artwork
  • 6 Use computer vision to propose categories
  • 7 View slider to compare two images
  • 8 VisualFileChange category processing improvement
  • 9 Allow hiding chosen versions of images on File page
  • 10 Backup of Commons files
  • 11 Category browsing without multimedia viewer
  • 12 DerivativeFX alternative
  • 13 Easier file description
  • 14 Implement Internet Archive BookReader in Commons & Wikisource
  • 15 Make categories sortable
  • 16 "MediaChanges" feed to track pages where images are used
  • 17 Multi-description tool
  • 18 UploadWizard: Allow providing image information (categories/description) while still uploading
  • 19 Rapid category creation
  • 20 Recent uploads patrol webapp
  • 21 Search images by OCR
  • 1 Transcode audio files to MP3
  • 2 Notifications for when your image is used
  • 3 Pick a thumbnail for an article's associated page image
  • 4 Position Maps & Media Viewer
  • 5 Reduce size of Play Button in Videos
  • 6 Slideshow support
  • 7 Support KML files for geodata
  • 8 Support SVG interactivity and animation in Media Viewer
  • 9 View location of all images with coordinates on a map
  • 10 Add DNG support (auto conversion to jpeg, Upload, Download)
  • 11 3D models
  • 12 360 Photo support
  • 13 Allow bulk uploads
  • 14 Increase file size limits
  • 15 Allow variants of an image to be derived from a single SVG
  • 16 Apple Photos sharing extension for Commons
  • 17 Computer vision
  • 18 Crowdsourcing handles to Wikimedia Commons content
  • 19 Default alt text in image file
  • 20 Also display images from subcategories
  • 21 Imagemap highlighting
  • 22 Display rectangular part of the image as parameter of File and compatible with ImageNote
  • 23 LaTeX-style referencing for images and equations
--Gryllida 23:50, 1 December 2016 (UTC)
Still nothing about upgrade from Categories to Keywords/Tags ? --- [Tycho] talk 18:01, 3 December 2016 (UTC)
Tycho, maybe I misunderstand, what you are meaning, but see Commons:Structured data and subpages. — Speravir – 21:53, 3 December 2016 (UTC)

December 02Edit

Moving forward on the commonscat linking to commons gallery thingEdit


Please see here. Could someone please give this a go and give some feedback here? Many thanks.

Convenience links:

Anna Frodesiak (talk) 23:48, 2 December 2016 (UTC)

  • We discussed linking galleries to categories. Are you now proposing (per the title of this section) to link categories to galleries? - Jmabel ! talk 00:00, 3 December 2016 (UTC)
  • The suggestion is to put something like
    ( function ( mw, $ ) {
    	'use strict';
    		a = $( '#mw-normal-catlinks > ul > li > a' ).clone(), // main a only, not the added cruft
    		see = $( '<div style="border: 1px solid #aaa; padding: 5px;">' +
    			'For more images, you may want to see:<ul></ul>and subcategories.</div>' );
    	if (( mw.config.get( 'wgNamespaceNumber' ) === 0 ) && $( '.gallery' ).length && a.length ) {
    		$( 'ul', see ).append( a );
    		a.wrap( '<li></li>' ); // wrap after append, because the elements need parents
    		$( '#mw-content-text' ).prepend( see );
    }( mediaWiki, jQuery ));
    in MediaWiki:Common.js. --Unready (talk) 00:34, 3 December 2016 (UTC)
I had problem with twinkle but can you repairs? Murbaut (talk) 02:22, 3 December 2016 (UTC)
  • To be clear over what this is about: Wikipedia Commons category links often end up at Commons galleries that contain only a few images. In those cases the link should go to the main category. Anna Frodesiak (talk) 05:03, 3 December 2016 (UTC)
    I'm not certain that's clearer. The suggestion from Commons redux was to put something like
    at the top of the mainspace pages with galleries. (In this example, on Vending machine in mainspace.) Content generated dynamically by templates is infeasible, because a template, including invoked Lua modules, cannot know the categories of a page. The options are:
    1. Users double-enter the categories, once at the top of the page in a template and later to actually categorize the page. Double-entry seems problematic to me because of the extra maintenance.
    2. A bot double-enters the categories, running periodically to clean up any mismatches. This option is still extra maintenance, except it relies on a bot.
    3. Generate the list dynamically after the parser has rendered the page and the categories are known. That's what the JavaScript above does, styling aside.
    If the intention is something else, then the requirement needs to be stated clearly: what link on what page pointing where. --Unready (talk) 05:38, 3 December 2016 (UTC)
    Thank you and huge kudos to Unready for continuing this here. I am so, so out of my depth with code and all that sort of thing, that I would be much more comfortable letting others iron out details here while I watch. I hope that is okay. Anna Frodesiak (talk) 11:37, 3 December 2016 (UTC)
    I'm not really championing the effort, just explaining my suggestion. --Unready (talk) 21:43, 3 December 2016 (UTC)
    Fair enough. :) Anna Frodesiak (talk) 23:18, 3 December 2016 (UTC)

For the record: Unready has kindly created code and is explaining it. Anna is totally and hugely 100% championing this idea. Whether or not someone can champion their own idea is another matter. :) Anna Frodesiak (talk) 23:18, 3 December 2016 (UTC)

Pictogram-voting-question.svg Question Why can't we force the category view in the first place? Most galleries are rubbish anyway. --Hedwig in Washington (mail?) 13:05, 4 December 2016 (UTC)
  • Because some aren't rubbish. I gave examples in the original discussion of several that I'd worked long and hard on. I don't have the list handy, but here are two: Romanian Orthodox churches in Bucharest, Seattle and the Orient. These are not "rubbish". Certainly the former is something where we very much ought to have a lot more pages like it. For example, I'd really like one place to go to see visual examples of the various species in a genus. - Jmabel ! talk 18:25, 4 December 2016 (UTC)
  • My personal summary of the previous discussion: If you want to eliminate galleries in the mainspace, what do you want the purpose of the mainspace to be? --Unready (talk) 21:04, 4 December 2016 (UTC)
  • Hi, I agree with Hedwig: when search for "Foo", we should get "Category:Foo", not the gallery "Foo". Some galleries are useful and nice (see John Ruskin and Mohandas K. Gandhi), but there are a tiny minority. Regards, Yann (talk) 00:13, 5 December 2016 (UTC)
    Isn't that just a matter of setting the "Advanced" search options to "Category" instead of "(Gallery)"? --Unready (talk) 02:27, 5 December 2016 (UTC)
"Champion" as a management term means more than simply being in favor of something. Here is the process I suggested elsewhere previously, slightly paraphrased.
  1. Be sure that the code does what people want. People can put it in their personal js temporarily to test. If people don't want it, want something different, or have alternate solutions, we need to know.
  2. Ask for comments on a more concrete proposal as an RfC on Commons:Village pump/Proposals. The proposal should probably put any styling in Common.css. If the proposal is accepted, the admins implement it.
We're at step #1, so does it meet requirements? Are there different requirements? Are there even any requirements? --Unready (talk) 21:04, 4 December 2016 (UTC)
Wait a sec. Is this code thingy for individuals to put in their individual pages to set their preferences for where commonscat goes? Does this have anything to do with changing where links end up, i.e. at gallery or main cat?
I thought this was about some sort of bot that could go around and add a box to the top of all galleries that says "This is only a gallery. For a complete list of all images in this category, please click here."
Or maybe a bot can figure out if a gallery contains a scarce few images or hasn't been modified in ages, and at the same time, the cat has tons of images, then the Wikipedia commonscat link could automatically be changed to go to the cat rather than the gallery? Anna Frodesiak (talk) 23:39, 4 December 2016 (UTC)
The code would go in MediaWiki:Common.js, but people can and should test it in their personal js. There is no bot. As I say above, a bot is not the way to go. --Unready (talk) 01:14, 5 December 2016 (UTC)
Okay, I have no idea what MediaWiki:Common.js compared to personal js. I'm staying out of this. My brain is way, way too tiny in this regard. Don't try to explain it to me. That would be like trying to explain physics to a hamster. You boffins sort it out. :) Sorry to butt in. Best, Anna Frodesiak (talk) 02:06, 5 December 2016 (UTC)

Is this going to stall out again? Does anyone care? Anna Frodesiak (talk) 05:55, 10 December 2016 (UTC)

@Anna Frodesiak: can we have a proposal on Commons:Village pump/Proposals per Unready's suggestion above? This is a UI change and someone may not like it. Btw: since this isn't a crucial UI feature for logged-in users, I believe this should be implemented as a gadget instead for ease of disabling. --Zhuyifei1999 (talk) 06:10, 10 December 2016 (UTC)
At this point, based on a lack of responses, I'd have to say not a single person has tried it to see if it's what anyone wants to do. Given some of the discussion above, I'm not even certain there's agreement on what the requirements are. --Unready (talk) 07:52, 10 December 2016 (UTC)

December 03Edit

Railway coachEdit

Oviedo railway coach june 1999 79.jpg
Taken during a Spanish 1999 trip.(other pictures: Category:Spain slide scan june 1999) I suspect Oviedo. Wat kind coach is this?Smiley.toerist (talk) 15:03, 3 December 2016 (UTC)
(a little bit unrelated question) What brand and type of slide film was that? --- [Tycho] talk 18:05, 3 December 2016 (UTC)
I started taking pictures with Kodachrome, later on I switched to Kodak elite, wich was had a faster return. Kodakchrome could only be developed with a special proces by special Kodak facilitities. I suspect this was Elite film.Smiley.toerist (talk) 21:51, 3 December 2016 (UTC)
It is certainly Oviedo above the train station. I recognize the building behind.Smiley.toerist (talk) 11:16, 4 December 2016 (UTC)

December 04Edit

Possibility of marking the pages as a "in progress" and users as "exist"Edit

Helo.I suggest Possibility of marking:

  1. the pages as a "in progress":I think that Commons is the most site needs to this because the large number of deletions and speedy deletion requests
  2. users as "exist":I think that Commons is the most site needs to this because the warnings about the violation images

This is useful in a lack of inconsistencies in the work, and Obviates Template:In use.Thank you --ديفيد عادل وهبة خليل 2 (talk) 09:09, 4 December 2016 (UTC)

I am not sure why "in progress" label is necessary. Commons is for images/files only and they are uploaded just in one step. You are probably confusing Commons with Wikipedias. I also do not understand what you mean by "exist" in relation to a user? Ruslik (talk) 16:10, 4 December 2016 (UTC)
@Ruslik0:Any page in any project may need some time to work on.e.g:Page needs a lot of time to complete, or to respond to requests Page.I see that it marked by the user to prevent other users from working on it until the first ends.Any user can be a existing (can read and reply to messages) or not I suggest the possibility of knowing the user state.Thank you --ديفيد عادل وهبة خليل 2 (talk) 07:15, 6 December 2016 (UTC)

December 05Edit

Tech News: 2016-49Edit

18:06, 5 December 2016 (UTC)

Please review a license editEdit


Could anybody please check whether I was right or wrong with this edit? Regards, Grand-Duc (talk) 19:15, 5 December 2016 (UTC)

December 06Edit

Coyau's deathEdit

Greetings, we have just been informed that Coyau has died. Many of us knew him; for those who did not, he was a prolific contributor on Wikidata, Commons and Wikipedia, as well as on the French-speaking Wikisource and Wiktionary. A commemoration will be held in Paris later this week, further information will follow. -- Pyb et Ash_Crow (talk) 12:08, 6 December 2016 (UTC) (for translation Rama (talk) 13:01, 6 December 2016 (UTC) )

My condolences. :-( --Steinsplitter (talk) 13:23, 6 December 2016 (UTC)
We have lost a potential photographer! Biswarup Ganguly (talk) 14:57, 6 December 2016 (UTC)

Roman numbers or Roman numeralsEdit

I recently added a few more under Category:Roman numerals andsuddenly noticed this:

I have been using "number" and "numeral" indistinctly. This should be harmonized: Which is the right one?, or, if both are good, which is the better? -- Tuválkin Tuvalkin 20:29, 6 December 2016 (UTC)

"Numerals" refers to the symbolic form, so it would be "Roman numerals". Both "1000" and "one thousand" are the same "number" but "1000" and "M" are not the same "numerals". -- Colin (talk) 20:48, 6 December 2016 (UTC)
Thank you! (And this will cause an unglorious spike in my editcount: A good example of how number of edits is not a useful metric for valuable activity, as I could have done it right at first in a single edit.) -- Tuválkin Tuvalkin 21:12, 6 December 2016 (UTC)

December 07Edit

Does anyone recognize the artist's signature on File:Campos de concentracion4.jpg? It does not seem to be the same as the uploader's user name, but I can't figure of what it it actually is to see if the image is in the public domain or not. There are three other files in this upload: File:Campos de concentracion.jpg, File:Campos de concentracion 2.jpg, and File:Campos de concentracion 3.jpg Imedeiros (talk) 00:47, 7 December 2016 (UTC)

DEM L316 in DoradoEdit

File:DEM L316 in Dorado.jpg was deleted at 00:17, 28 August 2012, for copyright concerns, see Commons:Deletion requests/File:DEM L316 in Dorado.jpg. Now the exact image has returned as File:DEM L316- Supernova Remnants Deconstructed (Two supernova remnants in the Large Magellanic Cloud galaxy.) (2941492404).jpg. Should the page histories be merged? --Marshallsumter (talk) 18:33, 7 December 2016 (UTC)

This is not the same image. Ankry (talk) 21:36, 7 December 2016 (UTC)
The persistent link for File:DEM L316- Supernova Remnants Deconstructed (Two supernova remnants in the Large Magellanic Cloud galaxy.) (2941492404).jpg takes you to the same image File:DEM L316 in Dorado.jpg, but I see what you are referring to File:DEM L316- Supernova Remnants Deconstructed (Two supernova remnants in the Large Magellanic Cloud galaxy.) (2941492404).jpg is out of focus. The date of release for both images is November 15, 2005. --Marshallsumter (talk) 22:53, 7 December 2016 (UTC)

Help using Python's requests library to upload using MW:API:UploadEdit

Perhaps a Commons Upload API guru who can help lurks here, I realize it's a long shot, but I've already asked at IRC and on the API mailing list to no avail. If anyone has had any success with this, I would greatly appreciate if they could tell me where I'm going wrong with User:Drudgebane_Storkksbot/ I am not the only person who is having the identical difficulties (cf. 1, 2). I am not trying to do this using a ready-made bot framework. FWIW, I get the identical errors using analogous code with Julia's requests.jl module. Storkk (talk) 18:48, 7 December 2016 (UTC)

Have you tried Attempt #3 without headers=headers (or headers with only UA set)? Content-Disposition should be part of the request body, and not the request header, in which case the request is not understandable. Also Content-Type should have some boundary settings not present in your headers. These are my guesses. --Zhuyifei1999 (talk) 19:24, 7 December 2016 (UTC)
Thanks, Zhuyifei1999 - we have a new error, and one that I wasn't expecting at all... After loggin in, Attempt #3 without headers=headers gives "error":{"code":"mustbeloggedin","info":"You must be logged in to upload.","*":"See for API usage"}. Same with just the UserAgent. I really don't know what's going on now. Trying an old attempt afterwards (without logging in again) gives the old errors again, no mention of login issues. I will update User:Drudgebane_Storkksbot/ Storkk (talk) 19:43, 7 December 2016 (UTC) ... it actually does log me out. WTF? Storkk (talk) 20:42, 7 December 2016 (UTC)
@Storkk: don't try to invent the wheel yourself. Just use pywikibot and save you and us a lot of time. Multichill (talk) 22:02, 7 December 2016 (UTC)
Thank you for your advice Multichill, however I am not trying to do this using a ready-made bot framework. I want to understand why it doesn't work. Actually getting the files uploaded is somewhat secondary, and the backup plan if all else fails is still not to use a bot framework, but to try to upload from url. Storkk (talk) 22:27, 7 December 2016 (UTC)
Compare: "I am working on building my new dining room table and I'd rather not buy a prefabricated one... I am having a real problem with dovetail jointing." How I read your answer: "Go to IKEA already!". Storkk (talk) 22:39, 7 December 2016 (UTC)
@Storkk: I just ran on my own laptop and I see the reason. Do check_login twice, the second right after the first, and you'll see what's wrong (poke me if not) :P --Zhuyifei1999 (talk) 02:14, 8 December 2016 (UTC)
(I just uploaded a random file with this) --Zhuyifei1999 (talk) 02:20, 8 December 2016 (UTC)
Thank you so much, Zhuyifei1999! All due to my misunderstanding of how cookies work (never done HTTP stuff before). I thought that I needed to keep copying the response cookies to make sure the session didn't get lost somehow, but effectively this was causing the error. Setting cookies once seems to work a charm. I will go put some working python examples (and perhaps Julia) onto MW:API talk:Upload. Thanks again! Storkk (talk) 11:11, 8 December 2016 (UTC)

Getting special photography equipmentEdit

I don't know if this is widely known here, but I just learned about a WMF rapid grant opportunity for photography and videography equipment. The general approach is that a chapter or other affiliate group can request up to US $2,000 for equipment that will be shared among the group. It requires a practical plan for what will be accomplished, but if you've been wishing that you could do a particular project (Panoramic photos? Stereoscopic images? Underwater videos?) and can't do it because it requires some specialized equipment, then you might be able to team up with others in your area to get a grant. There are also larger sums of money available through the other grant programs.

See m:Grants:Project/Rapid for more information. I'm not involved in the grants, but I've met a couple of the people on that team, so feel free to ping me if you need help figuring out who to contact there. Whatamidoing (WMF) (talk) 22:08, 7 December 2016 (UTC)

December 08Edit

Panorama templateEdit


I'm duplicating an issue I raised on the template talk page since the audience is probably larger here.

We currently have issues with correctly conveying an immersive panorama (360 or even full spherical 360x180°) to the viewer. They are presented with an equirectangular view which is misleading and is not what shall be viewed.

It's a bit frustrating because I feel we don't miss much to provide a much better experience. I'd like to have a template for that:

  1. it shall be based on the current panoviewer, which is based on Pannellum
  2. because it's based on pannellum, it would allow any framing and offer the possibility to drag right from the frame to move the point of view.
  3. it shall fall back to a plain picture if the browser doesn't support it.

And in very short, it should be handled like how Facebook handles 360 panorama in the webpage and app (we have to keep in mind that wikipedia is viewed on mobile devices app too)

So my questions :

  1. Is anyone capable of writing such a template quickly?
  2. if not, I can try. In that case, can we use raw html in templates? I remember raw html could be enabled or disabled and I doubt it's enabled on Commons or wikipedias.
  3. In case it would be necessary, where can I get special access to wikimedia's servers to fine tune tools or plugin? I don't want to harass the maintainer of Panoviewer.

Maybe this should be handled by MediaWiki software itself. Any clue to where I shall ask for help?

Thanks for your help - Benh (talk) 10:49, 8 December 2016 (UTC)

I run into the same message on Commons_talk:Templates#Panorama_:_template_with_raw_HTML and Commons_talk:Featured_picture_candidates#360_Panorama_template. I think it is a better practice have discussion in a single place and maybe invite people on other forums to join. By the way, the discussion about Pannellum like viewer can be found on several (overlapping) phabricator tasks. It might be good for those familiar with the matter to review those discussions and add to them if needed. --Jarekt (talk) 13:14, 8 December 2016 (UTC)
Yes I'm sorry. Though a long time contributor, I'm not so used to the best practices and etiquette, and thought I'd try to broaden the reach for my request. Thank you for pointing me to there. I'll have a look. - Benh (talk) 13:32, 8 December 2016 (UTC)

Exif metadata and searchEdit

Hello Commons. About a month ago the Search team at the Wikimedia Foundation updated search to enable searching for files by metadata properties. You can search for files by file size, type, width, and more.

There’s more metadata we can expose, perhaps via tags in Exif metadata. [7] The English Wikipedia article covers many of the general tags. There are more comprehensive listings of EXIF tags elsewhere online. [8] [9]

So, the questions we have for you: Would it be helpful to expose Exif tags to search for Commons? How could you see it be used? If it would be useful, what tags would you consider the most useful and a priority?

A related question. For folks following along with the structured data project, would you see this search feature as useful? Is it duplicating efforts?

Thank you for your time and please let me know if you have more questions. CKoerner (WMF) (talk) 18:07, 8 December 2016 (UTC)

I would like the assumption that the EXIF data is well formatted to not be a constraint. When I use the wiki database to check through EXIF headers, I find lots of interesting things buried away in ways that it probably should not. The ability to search as much as possible of the EXIF data for wildcard matches would be great, and this could for example help greatly with finding files with unexpected copyright statements in description fields, colour profile data intended for printers rather than screens leading to poor on-wiki display, files with different types of date statements that may conflict with the date chosen for information, or discovering files with odd EXIF elements showing the files may have other compressed files hidden within it, potentially indicating misuse of the Commons site as a host for nefarious purposes.
I have no idea if there are technical challenges, but having the EXIF available as a long text string that can be used in handy simple search or regular expression searches, would be a lovely feature for the Commons advanced search capabilities. -- (talk) 18:20, 8 December 2016 (UTC)
It's a bit trickier since a lot of EXIF data are not textual - e.g. coordinates, or camera settings, or photometric data. That's where intersection with structured data comes in - what we did essentially with file metadata is implement kind of micro-structured-data on top of ElasticSearch/Cirrus. We could keep going in that direction, but that would also mean we intersect more and more with structured data use case. Which may be ok, I don't know - we'd like to hear opinions on that. Also, it means we need to target specific fields - unlike Wikidata, ES solution requires predefined fields (it's one of its weaknesses) and then we'd need to have the list of such fields. We could as a preliminary step to extract all known text fields into a big text blob and make that searchable, but it may make it a bit weird - it would not distinguish between image description and camera make, for example. Maybe there are better ideas for how to do it, let's think about it. --Smalyshev (WMF) (talk) 19:16, 8 December 2016 (UTC)
It isn't just EXIF tags we might be interested in, but also XMP and IPTC data. The EXIFTOOL (already used by MediaWiki) provides an excellent means to extract this data from most media file types. There are a variety of output formats possible from that tool. One problem is the tags are somewhat structured into groups and sub-groups so individual tags might be included in several groups and may even appear to contradict at times. The duplicates are a minority, thought, and for most tags, the simple "Name: Value" pairing that EXIFTOOL outputs could be extremely useful. Note that without an up-to-date version of EXIFTOOL, many tags (especially MakerNotes) are impossible to interpret, but once interpreted they are valuable. While the names are suitable for exact-match searching, whether any given tag is present or not is highly variable and at the whim of the camera manufacturer, the editing software used, and the export options made when generating a JPG. Some basic software (like Paint) simply strip out all EXIF. Also note that some tags make sense as a number rather than as text (e.g. exposure length, aperture, ISO, exposure compensation). One might be interested in high-ISO images and choose ISO > 800.
I would think that analysing images for dodgy embedded files (other than thumbnails, which are standard) would be part of the upload tool.
Is there any reason why one could not include all the tags that EXIFTOOL extracts by default, and then have a page that documents those which most people may find it useful to search for. Unfortunately, it will not be possible to search images and find all photos taken by Sony cameras or with a 80mm f/2.8 SAM lens because many many photos will simply lack that data. -- Colin (talk) 19:13, 8 December 2016 (UTC)
  • I believe Metadata from Exif etc., is stored in some kind of PHP-formatted array in a single database field. Transferring that into some kind of text blob doesn't sound like much progress. I'd consider if there's a better way of storing that data that retains the structure, and allows querying individual fields by the API as well as search. Maybe it could go in the Wikidata-on-Commons database, although you can also ask if it should be editable or not. Note that there's some bizarre stuff in there, like multiple megabytes of OCR'd text in certain scanned text files. --ghouston (talk) 23:29, 8 December 2016 (UTC)

Probably a good idea to add at least one that was originally requested: Bare minimum required Exif:

Basic stuff:

  • Upload date "fileuploaddate: > 19/12/2015" (Sortable)!!!
  • Videos and audio were seemingly left out:
    • Audio duration
    • Video Duration
    • Video Frame / audio bitrate (if even possible)

A better solution would be as probably something like a "Special:Exif" that indexes and collates all fields in an easy way to navigate, and would be pretty important if something like this treasure trove ever comes to commons:

If such a special page is made, then only the most important ones would need to be added to the default search, too many options is always a bad thing.

December 09Edit

October results of Commons:Photo_challengeEdit

Gardening: EntriesVotesScores
Rank 1 2 3
Image Baddesley Clinton Scarecrow 2.jpg Gardening in London.jpg Beetroot sowing.jpg
Title Scarecrow at Baddesley Clinton Gardening_in_London Old gardener sows beetroots in Estonia
Author DeFacto Ibex73 Maasaak
Score 15 11 11
Water Supply Infrastructure: EntriesVotesScores
Rank 1 2 3
Image Hong Kong China Water-supply-01.jpg Water tower Mittweida.jpg Old wash house Marmeaux France.jpg
Title Supply of drinking water in Hong Kong Water tower near Mittweida, Saxony, Germany Marmeaux, old wash house in Burgundy, France
Author Cccefalon Kyriondaniel Ibex73
Score 26 21 16

Congratulations to Cccefalon, Kyriondaniel, DeFacto, Ibex73 and Maasaak. Please check out this month challenges: Holidays and Appliances. -- Jarekt (talk) 04:37, 8 December 2016 (UTC)

Commons' app for androidEdit

Hi everyone my name is Gustavo Woltmann, I am an assistant in a publishers office. Just thinking if there is an app made for Commons applicable for ios and android users? If there is, can you send me the name of the app so I can start downloading it? Many thanks. — Preceding unsigned comment added by Gustavowoltmann01 (talk • contribs) 06:57, 09 December 2016 (UTC)

Please, see Commons:Mobile_app. Ruslik (talk) 20:22, 9 December 2016 (UTC)

Hoar frost on trees?Edit

In my opinon most (if not all) of the images in this category (and its subcategories) are not hoar frost but rime (deposit of ice due to freezing fog) or even simply crystallized snow; usually hoar frost do not form ice deposits on trees and vertical objects but only on horizontal surfaces such as ground, roofs and so on. Hoar frost is possible on vertical objects only when they are made of metal or other materials that lose quickly their superficial temperature; a rarer kind of hoar frost (advection hoar frost) may however form ice deposits on trees but the amount of frost is generally tiny.--Carnby (talk) 13:45, 9 December 2016 (UTC)

This probably needs to be addressed at COM:CFD. lNeverCry 02:12, 10 December 2016 (UTC)

French book on horses with Commons picturesEdit

Hi, A book about horses with many pictures from Commons is going to be published in France in January 2017. For details, see Commons:Bistro#Remerciements aux photographes de chevaux qui ont mis leurs travaux sur Commons. Yann (talk) 23:33, 9 December 2016 (UTC)

December 10Edit

discussion of possibly problematic categoriesEdit

It's been suggested that this discussion maybe should have been here instead, so providing a pointer for the broader community: Commons:Administrators' noticeboard/User problems#Massive creation of questionable categories. Beeblebrox (talk) 04:01, 10 December 2016 (UTC)

New NASA animated gifsEdit

I hear they're awesome! Can we mass upload them? Is someone already working on this? Anna Frodesiak (talk) 05:52, 10 December 2016 (UTC)

When the file will be reviewed?Edit

Hi, I am new user. I had upload file on 24 November but it did not have any review. I am worried about i did something wrong since the others pass the review instantly. When the file will be reviewed?Cpcam065099 (talk) 09:06, 10 December 2016 (UTC)

Hi Cpcam065099, thank you for asking here. I'm not an admin, but checked your claim and can confirm that currently correctly states (.ko) as licence. I added {{LicenseReview}} to help admins finding it while knowing admins are few and busy here. :) --.js ((())) 09:33, 10 December 2016 (UTC)