Commons:Village pump

From Wikimedia Commons, the free media repository
Jump to: navigation, search

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


Turkey Beypazarı district Hırkatepe Village pump. [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch


Flickr license verification request[edit]

Can I do a request for a license verification of a Flickr photo here in the Village pump ? I uploaded a CC0 image from Flickr, and since Upload Wizard doesn't have a option under the Flickr section for selecting Flickr-CC0 license, the file needs to be verified by someone with authorization to do so. It concerns this file: File:Sunset at the beach near the harbor of Scheveningen, The Hague (2015).jpg. If there is an other, more convenient way to get through this process, please let me know. I red some of the archived discussions on the matter of Flickr Public Domain licenses, but couldn't distill from it the correct way how to go about with it in practice. --oSeveno (talk) 14:14, 19 September 2016 (UTC)

Do you have any doubts that the person who posted the image on Flickr is a photographer? Ruslik (talk) 14:27, 19 September 2016 (UTC)
I have no doubts about the poster being the photographer, but as I understand it, all photographs on Commons from Flickr need to be confirmed that the license is that what I post when files are uploaded. Or did the Commons policy change ? --oSeveno (talk) 15:50, 19 September 2016 (UTC)
A license review can be requested by adding a template to the description page. For a bot review of a flickr file (if the file has not been modified), the template "Flickrreview" can be added. For a human review, the template "LicenseReview" can be added. -- Asclepias (talk) 14:53, 19 September 2016 (UTC)
All I think that is needed is that the Commons bot can confirm I uploaded a Flickr file with the correct license. (CC0) --oSeveno (talk) 15:50, 19 September 2016 (UTC)
OSeveno - You can use the Flickr2Commons to upload images (even those under this licence), The only ones that shouldn't be uploaded are Public Domain Mark] (and a few others) but CCO and Creative Commons Attribution 2.0 Generic etc are fine, Cheers, –Davey2010Talk 16:41, 19 September 2016 (UTC)
Thanks Davey2010, I am going to look into that option. --oSeveno (talk) 17:11, 19 September 2016 (UTC)
You're welcome :), Forgot to add but F2C is here if you didn't know, Thanks, –Davey2010Talk
I'll just note that UploadWizard has built-in functionality to "Share images from Flickr", which handles this license automatically and correctly. It was not used here, because unfortunately it is only available for administrators and license reviewers here on Commons. Relaxing these restrictions would presumably require community discussion. Matma Rex (talk) 17:48, 19 September 2016 (UTC)

Pictogram voting comment.svg Comment Adding the template {{flickrreview}} to the license tells the bot to review the file... it should be able to correctly handle CC-0 images. Reventtalk 03:43, 26 September 2016 (UTC)

Disabling Commons:Upload Wizard blacklist issues[edit]

When an upload in UploadWizard is blocked by a TitleBlacklist entry, we give the user an option to report the failure as a false-positive. These reports go to Commons:Upload Wizard blacklist issues. As far as I can see, no one ever responds to them, and rightfully so, because every single one is wrong. Should we disable the ability to submit them in UploadWizard? (It's a simple configuration change.) Matma Rex (talk) 17:54, 19 September 2016 (UTC)

  • Support disabling - The entire page hasn't been archived since 2011 and by the looks of it there's not one person whose responded, IMHO I believe pages like this are helpful and should stay as there could easily be a problem however as I said no one ever checks the page nor responds so it's rather pointless having this around, I think I can safely say we all have far better things to be doing with our lives than patrolling through that crap everyday of the week!. –Davey2010Talk 03:55, 20 September 2016 (UTC)
  • Support disabling makes sense. --Steinsplitter (talk) 05:56, 20 September 2016 (UTC)
  • I'm guessing certain user groups are excluded from the blacklist filters? I was trying to purposely trigger the blacklist filter so I could see what the notice looked like. But I'm guessing my user group is excluded, I couldn't get it to trigger using the filename DSC07143.JPG. I was trying to see what the notice looked like to see if we refer the users to documentation on properly naming files etc. Offnfopt(talk) 07:30, 20 September 2016 (UTC)
  • Support disabling Offnfopt(talk) 10:39, 20 September 2016 (UTC)

OK, looks like agreement to me… Phabricator task: phab:T146417. Matma Rex (talk) 14:30, 26 September 2016 (UTC)

Big purge of old images?[edit]

I notice a pattern:

  1. Old file got transfered to Commons
  2. Lot's of bots work on it and empty out one of more template fields
  3. Someone tags it as {{no source}} without looking very closely
  4. Admin just deletes it after 7 days

All these steps have a small mistake in them, but together they form a very destructive pattern currently getting a lot of old files deleted. @Jcb: & @Ellin Beltz: for plastering my userp age and @Basvb: for objecting on it. Multichill (talk) 18:01, 20 September 2016 (UTC)

I notice a pattern too. User doesn't fill in templates; user gets upset when file is tagged, user reverts tag, user doesn't fix problem, user complains. But seriously it would be of more help if you made sure files you worked on were done when you close them, especially after taking off tags and tossing them back into the system unfixed. For the image which I just noticed of this type File:V-2-Nederlands.jpg, I reviewed the entire history: It was imported by BotMultichill... without a valid source. All the bot fixes thereafter didn't break anything, the file template was incomplete on upload. There is no reason to complain about the system not working when it was the uploader in this case who didn't provide a source. The system is working fine to remove images without source. Ellin Beltz (talk) 18:07, 20 September 2016 (UTC)
If there is a proper source and everything checks out, the files can be kept or restored if necessary. If there is no proper source and the status of the files cannot be determined without said source, deleting them is correct. --Rosenzweig τ 18:10, 20 September 2016 (UTC)
Most likely a lot of these files are ok (PD-old), but don't have the source mentioned or mentioned on the wrong place. Part of the issue is that these files don't really have an involved uploader or are curated by their uploader. This is because they were uploaded long ago on other projects and moved by a bot (and we can't expect the file movers with 100.000s of moves to fix all these 100.000s of files (in a short timeframe)). The way you describe that the files should be handled is indeed a valid way in theory, but in practice nobody will try to restore these files after they are deleted, because nobody will know what exactly the files do contain. Basvb (talk) 18:28, 20 September 2016 (UTC)

Maybe giving some specific examples will help here: sources get removed, same, 3, and the example Ellin Beltz mentioned. I'm wondering what the criteria where for the blanking of these images their sources? In the first two cases there is a source described in the description (in this particular case a long discussion can be held on whether we can take files from that source, but that is a DR discussion), at least one of 4 steps mentioned by Multichill should find that out, preferably all 4 steps should be able to do so. @Ellin, this issue is on processes, not on specific persons. Note that the first step Multichill mentions is the one he performed. A lot of these files are used somewhere and can be kept without much of an issue (the 3rd example is a 1400-1700s image), deleting these files simply results in a loss of information. These files have been moved to Commons because local wikis moved all their files (eg. nlwiki) and uploaders in some cases even give valid information, but not according to our structures (information template), which are much more recent compared to when these files were uploaded. I think we (those involved/interested in the process) should try to ensure that these kinds of files are not deleted on this scale. How we best do that is open for debate, fixing the 1st step is not going to solve the issue (step is long past), some clarification on the second step is welcome, and being more careful/less strict in step 3 and 4 is probably the short term solution. Basvb (talk) 18:24, 20 September 2016 (UTC)

"Transferred from nl.wikipedia" (or any other wikipedia) is not a proper source when the original uploader is obviously not the author of the file. We need the original source from where the original uploader took the file when uploading to nl.wikipedia. --Rosenzweig τ 19:02, 20 September 2016 (UTC)
In that case I think we should focus on performing step 3 and 4 a bit more carefully, if one is going to tag a file as having no-source I believe that (especially for older files) we can expect the one tagging the file to take into account source information provided outside of the correct information-template fields (for example a "source = xxx" in the description). Another thing would be to have these images from another wiki in an: incorrect source provided instead of the regular no source provided maintenance category. Anyway, removing files where valid sources are provided, just not on exactly the correct location, especially when these are old and in use (thus clearly in scope) files shouldn't be happening and especially not on this scale. Basvb (talk) 19:55, 20 September 2016 (UTC)
The book " Wonderen van het heelal" (ed. circa 1915) was written by G.J. Vries and G.C.J. Vosmaer ([1]). The name G.J. Vries is a very common combination in Dutch names and a query in Google produces too many results; On the other hand, G.C.J. Vosmaer doesn't seem to have published after 1935. His first publication I could find dates from 1880 (his PhD thesis). ([2]). Therefore, it's safe to conclude that he was born before 1858. It's likely that he died before 1946 but this is not conclusive. JoJan (talk) 16:19, 22 September 2016 (UTC)
It probably would have helped if the word "source" would have been anywhere in the description and not the Dutch equivalent "bron" (which was used in two of your examples). Not everybody will realize what this word means. --Rosenzweig τ 20:43, 20 September 2016 (UTC)
A very interesting example is the now deleted File:Red ribbon.gif, this file was uploaded by a file transfer bot in 2007. This is before all our information template structures were really common. In the description there is a clear source mentioned. That source being File:Red ribbon.jpg, and in that source also clearly the original source is mentioned. However as the files were duplicates (different filetype) the .jpg got deleted. And, maybe because of that, or maybe even just because the source was not in the proper information template field the .gif was also deleted. This all while valid sources were provided, just not on the completely correct location. Basvb (talk) 18:43, 20 September 2016 (UTC)
Thanks for that example. Worrying. -- (talk) 18:54, 20 September 2016 (UTC)
Try any of these red ribbons in Category:AIDS red ribbon... The ones which remain have sources & licenses. The one which was removed did not. It's not worrying, it's "housekeeping." Ellin Beltz (talk) 20:10, 20 September 2016 (UTC)
The original file did have a source, a link to [3]. The link is dead, so there could be some discussion on whether that source is valid enough (we can't currently verify it, that is however quite common for older files and the internet). Anyway, the file is not a plain deletion imo, but worth a good discussion. Basvb (talk) 20:56, 20 September 2016 (UTC)
I suggest everyone lay off marking old uploads of U.S. Federally funded artworks or photographs with the "no source" template, which virtually guarantees deletion after 7 days, these actions are damaging our Commons project mission. If you have a concern, then raise a deletion request which might have more chance of getting noticed. In the case of posters or images from, they are public domain unless clearly produced by a commercial source. @Basvb: please undelete the jpeg, you can add as a current official source at, which justifies the PD-USGov-NIH template. It's worth noting that exists, and were anyone to make the effort to search the archive of NIH web pages there, they can find the original source at - so I suggest that's added too.
In the discussion of solutions rather than blame, I suggest we again have the perennial discussion about auto-archiving sources, adding links automatically to our more treasured files would be a great start and avoid some of the unnecessary deletions which seem based on inevitable linkrot rather than valid copyright violations. -- (talk) 07:55, 21 September 2016 (UTC)
Auto-archiving sources would be an outstanding thing. Reventtalk 02:52, 26 September 2016 (UTC)
  • I agree with Multichill that there is a serious issue here, both a systemic one and a behavioural problem, one that can damage this project's reputation for the hosting of public domain archive media. For public domain images that have been transferred from other projects many years ago (in the example it was 2009), there should be care to retain as much information with the image as possible everytime there is "housekeeping". I have complained directly about the actions of OgreBot 2 here, and received replies I still find unconvincing, considering that these unthinking automated actions are resulting in the deletion of public domain material. I also find it hard to understand why marking very old files with 'no source' templates, then doing nothing to see if the public domain license was there for good reason when it was uploaded in good faith on another project, by users that may have retired but have an excellent history of contributions, is somehow justifiable or a "good thing". What's needed here is a bit more intelligence in the process, and from those operating it, to ensure we make every reasonable effort to preserve public domain material, rather than blindly follow procedures we made up more recently than these images. If you are in danger of within 7 days causing perfectly valid public domain media that has been here for 7 years to be deleted from Commons, then you are at fault, not an uploader who has been inactive since 2009, not Multichill for creating a bot 7 years ago, not the handful of community members who are willing to look at these cases and waive a red flag. As a quick fix, perhaps we should automatically add an extra 7 days to the normal deletion notice period for every year the file has been here on Commons. At least then in these examples we would have 8 weeks to notice there was a problem and discuss it. -- (talk) 18:54, 20 September 2016 (UTC)
I think it's an assumption that user's are not trying to find sources for images. I don't hit "no source" without a good valid try to find a source for the image, without searching the file history, and I do attach quite a few sources to unsourced images as I'm going along. I'm not happy to be told that people who are not looking over my shoulder while I'm working are making unsubstantiated allegations about what I do or don't do. I am also not pleased to be told I'm not being intelligent, or not making a reasonable effort, "blindly following" and so on. How about just discussing the issues without the extras?? Ellin Beltz (talk) 20:10, 20 September 2016 (UTC)
So let's discuss the issue and ignore the extras. Do you think the current processes work perfectly fine, or do you see these issues as well? You indicated that the fault (often) lies with the uploader for not providing correct sources ("when it was the uploader in this case who didn't provide a source" on File:V-2-Nederlands.jpg (BTW, the uploader did provide sources there, but in Dutch and a bit vague in the description, but lets do that discussion in the DR)). I believe that if we are that strict we will lose lots of valid material, we can't expect the uploaders from 10-15 years ago to still be around to fix their material according with our standards, which have changed a lot over this time. On the other hand we have big backlogs and loads of images with valid concerns surrounding their permission and source info which should be dealt with. Basvb (talk) 21:05, 20 September 2016 (UTC)
When a file that an article is using is tagged for possible deletion, does the talk page of that article get a message? Jim.henderson (talk) 18:58, 20 September 2016 (UTC)
No, what we have right now is totally naff. Non-Commons re-users will not see any notices. The original uploader of the image is not notified, only the person that transferred it to Commons or the person that most recently overwrote the file. -- (talk) 19:03, 20 September 2016 (UTC)

We still have 300k files in Category:Media missing infobox template which do not have a proper source in proper place. Also most file transfer bots I have seen can not match many of the templates and styles used on each wiki with Commons templates, often resulting in missing data. I was often frustrated by how hard it is to digout the original description in wikipedia which is often deleted soon after transfer. (In my opinion files should be transferred with the full edit history through page export/import) Old files and transfered files can not be held to the same standards as the new uploads, but to the standards at the time of the upload. --Jarekt (talk) 02:06, 21 September 2016 (UTC)

File history can be transferred now. I can see how to do it and not cause any problems with current images. However it needs sysop tools, which rules me out. Maybe you could raise a work request? -- (talk) 03:02, 21 September 2016 (UTC)

Oh, the word has a sexual, scatological sense. In my rustic colonial innocence I took it as meaning "imprudent" which indeed is how this deletion by bot process appears to me. Probably most of those pictures have nobody actually watching them on a watchlist, so a more prudent method would be better. At a minimum, notify the talk pages of the using articles, and delay deletion by a certain number of weeks per year since the file was originally uploaded. Perhaps additional measures, such some kind of notification per Commons category, would also be appropriate. Jim.henderson (talk) 18:58, 22 September 2016 (UTC)

My advice would be:
0) put in a list all file in Category:Media missing infobox template that are not used, in another on those that are used in ns0.
1) for those that are used but not in ns0 or that are not used at all list them by date of upload (pre-2007, 2007, 2008...). Than send a polite message to all uploaders of early cats here and say that at least the oldest ones would be soon erased, unless info is provided;
1bis) crunch the number if there some effect.
2) for those that are used in ns0, send a bot in ns1 on every wiki (at last those where we have contacts or share sysop or whatever) asking for help with infobox templates (a file useed in this article is missing...). Just that. Language by language, the one you can. It is a surgical low-intensity approach. No menace of erasing, just ask for help.
2bis) crunch the number if there some effect.
3) Send a message to all general and project village pumps summarizing the effort so far. Ask again for help. Expert users can help. Don't menace deletion.
3bis) crunch the number if there some effect.
4) At the point, start with the deletion of oldest unused picture, date by date. Proceed manually.
4bis) crunch the number if there some effect. Check if the rythm is ok (the number of files in the category is decreasing) and stop If you arrive to the recent ones (e.g. post 2014),
5) Send a message to all general and project village pumps summarizing the effort so far.
6) At the point, start with the deletion of oldest used picture, date by date. Proceed manually.
6bis) crunch the number if there some effect. Check if the rythm is ok (the number of files in the category is decreasing) and stop If you arrive to the recent ones (e.g. post 2014),
If after a linear, organized cycle of work you reached an original target (e.g. 50000 files), just stop and let the natural rythm of the platform handle the job.
that's the idea (tailor it if necessary)
But whatever is the strategy, please don't just take a bunch of random files here and there and throw them to the deletion procedures. it does not solve anything. If it did, the situation wouldn't be so bad, IMHO.--Alexmar983 (talk) 05:26, 23 September 2016 (UTC)
There's plenty that could be done to handle these better. If no volunteers wants to invest the, fairly significant, time needed to do this well and automate some of it, then perhaps someone would like to consider a WMF grant proposal? It would be an excellent investment of some grant money. -- (talk) 13:10, 23 September 2016 (UTC)
Another one? I am contacted/suggested for a lot of grant lately :D But seriously as I always say in this type of discussion, if you want to be Batman I can be Robin. Happy to share all my expertise.--Alexmar983 (talk) 05:51, 24 September 2016 (UTC)

Unfortunately this discussion appears to be having no impact on the behaviour of administrators who enjoy using the 'no source' template. This public domain 1912 document was marked for deletion within 7 days by Jcb earlier today: Routebeschrijving Anglo Dutch Reliability Trial 1912.jpg.

Does anyone have any suggestions for how policy or guidelines could change to put an end to this pattern that puts our validly public domain material under threat of deletions? -- (talk) 01:26, 24 September 2016 (UTC)

Dunno. We could create a pre-warning template to be used with old files, to be posted in local wikipedia at Wikiprojects. This way they can at least save it locally if it's used, that's how they survive many times. Or they can find the right source, the problem is mainly cultural, we clearly need less procedure and more knowledge of topics in this case. That's also what makes real long-term quality. Also, I would suggest to create some automatic lists with oldest unused files, so maybe they can erase those first, with at least a lower impact.
Also for some cases of "rigid" commons deletion procedures please take a look in m:NonFreeWiki, a proposal to create a new fair-use wiki to host almost all of the non-free content currently hosted on all the other wikis and then stop all local uploads.--Alexmar983 (talk) 06:03, 24 September 2016 (UTC)
"I see deletionist" "In you're dreams?" "....No" "all the time, they're everywhere ... "
The problem is that back there we didn't had the obligation of sourcing the work and some Wikipedias also didn't adopt this policy, and this actual obligation should not be applied in the old files.
We should assume god faith, and see as "free" the old ones without the source (or if the it came from one of those wikis).
A bit of that images spread in internet, and we cannot prove that they are or not the originals... PD it's easier, and if you don't have time to check, you also may not have time to delete it...
So, we should change our posture for those, in a case that someone claim the copyright of some image, then we act, not the opposite, for this particular cases. Probably 90% of those without the template and without source are free.
Deletions like this: Commons:Deletion requests/Files in Category:Bowl of Hygieia are comply harmful for the community. As we develop and create a lot, based in some files, than you are discarding contribution based on nothing, you are preventing something that do not happen.
We can create a special disclaimer, explaining that the image is without source, it's unusual, that it is a old file and we could not attest the source, if you help find the source, or contact the volunteer it will be wonderful, however use with careful.
Deleting like crazy, pressing two buttons, will not help the community,
And a small reminder, Commons it's not a repository for other wikis, if are not in use in wikis, this do not matters at all, this a mediatheque for the whole society, Wikipediacentrism let it out of here, pleas.
-- Rodrigo Tetsuo Argenton m 21:30, 25 September 2016 (UTC)
"ns0" refer in my case to all wikis, so it is more correct to say "wikimediacentrism". wikimediacentrism has a practical role in many cases, not ideological. If these images without source come from local wikipedia, considering the support of those local wikipedias in order to fix the problem when possible is a sensible move. Also, statistically if a file is not used on any wikimedia project after so many years, it is quite often not the best one available anymore, or largely out of scope (and our project have a very large variety of scopes, that's the point). Considering that the core idea is not to delete unused file for sure but to discuss their deletion with order, it is reasonable assumption to organize the sorting of thousands of files according also to this aspect. When you try to minimize the damages, making assumption is a necessary step. If stating principles would solve practical problems, of course things would be much smoother. But does it?--Alexmar983 (talk) 12:38, 26 September 2016 (UTC)
"statistically if a file is not used on any wikimedia project after so many years, it is quite often not the best one available anymore, or largely out of scope": I think that's just wrong. Consider for example Category:Seattle and the Orient, scans I did from a 1900 book. Most of these are not in any other wiki. If I'd done this earlier and been less clear about source (or if the source info had been lost along the way), would you want them deleted? Clearly US, clearly pre-1923. - Jmabel ! talk 15:57, 26 September 2016 (UTC)
statistically what I said it is correct. And no I don't want them deleted. As you can read, I want that in case of many deletion procedures (which are not compulsory per se), their procedure starts before the one of a used file. In the case, I will oppose to the deletion. Because the same overall perspective that tells you to start to revise an unused and old file before the others, suggest you also to look at the category of the files. Because if you accept a file of one source, this assumption is valid also for the unused one of the same source. It wouldn't have any consistency otherwise. I was just starting here with one of the simplest step, the one that if applied statistically reduce the damages more than the other. This reminds me when I listed on itwiki in 2011 orphan articles from 2004-2006 and I said, "please before erasing a newly published article, could you just take a look here?" I was right, a huge percentage above avarage were deleted but noone cared at the time. The most important goal for some users was to prove there was something "rigid", which there wasn't. Not from my side, statistics based on experience are not rigid, they are neutral. BTW it was a strategy proved effective in a lot of quality festivals about articles and files in the following months. Actually it helped reducing the amount of excessive deletions in many areas for a while (I am not a deletionist). Rigid people erase whatever they want in any case, but when focusing on those groups they were busy in areas where there was less stuff worth saving so we had more time to save it when necessary. But there were some inclusivists who were so "rigid" they didn't even get it. they just attacked the concept. --Alexmar983 (talk) 16:52, 26 September 2016 (UTC)
Refer to Commons:Undeletion_requests/Current_requests#Commons:Deletion_requests.2FFiles_in_Category:Bowl_of_Hygieia. -- (talk) 21:44, 25 September 2016 (UTC)
@Fae: Since you cannot see it... the original content of the file page. for the original file File:Bowl hygeia.jpg, which was deleted in 2009, was "Bowl of Hygeia: The symbol of Pharmacy". That's indication, at all, of where the image came from. The original uploader was active until a year ago (or, ~5 years after the file was deleted) and never modified the file page after the original upload. While in this example, the image is (IMO) probably simply PD as an ancient symbol with no original authorship, many such files indeed have no determinable information, but they should often be considered 'grandfathered'. Reventtalk 03:18, 26 September 2016 (UTC)
Years ago I did an analysis on copyviol on itwikipedia. It turned out that we have something like 50000 articles created by IPs or few-edits-users. A sampling of hundreds of them made me discovered that at least 10% were probably copyright violations. So 5000 highly possible copyright violation under our nose (more or less), undetected for years. Nothing happened. Funny thing is, you have these people that jump to the face for a similar sentence (even with a clear source where it comes from is provided) but they don't care at all when this big picture emerges. Even funnier, I collected a list of violations done by "expert" sysops. I never asked for their deletion, it is much more interesting to show to newbies "tortured" for a similar sentence just to "put things in perspective". It's fun, newbies like it very much. But the perspective is that we, on every wikimedia projects, have thousands of violations that are much more risky than other ones. Our main duty should be to find the most critical ones, whilst pushing a button for procedural reason is not solving anything, it's a "shortcut for conscience". If a critical copyright violation emerges, knowing that you spent hours of time to erase some of the pictures described here, IMHO it does not look like if you're smart, at least it does not to a lot a third parties.
BTW, if it were to me with these old files I'd be for the parce sepulto approach. But with a clear grave. There might be in some cases a risk of copyviol above the average, something that didn't emerge mainly because the very same copyright owner didn't care after so many years. We put a warning that does not imply deletion. Just to be clear: this is much more than a lot of local wikipedias are doing to deal with their real dust-covered probable copyviols. If they don't care and are still operational, I think we can survive as well. If we manage to find an efficient way to monitor copyright of all new files, than we can start to clean the attic.--Alexmar983 (talk) 13:09, 26 September 2016 (UTC)
threats of deletion, or automated deletion will not improve the metadata of images. it is not about efficiency, it is about competence. you have people not fit to hold a position of responsibility, telling other people what to do in seven days. and incapable of doing a risk analysis: they are the risk. Slowking4 § Richard Arthur Norton's revenge 00:02, 28 September 2016 (UTC)

Proposal - a statute of limitations for the precautionary principle[edit]

The key issue with the examples of deletions of files which are believed to be public domain but lack a source, is the element of reliability of Wikimedia Commons as a host for reusable images if very old images are going to be deleted on a technicality. I propose a simplistic approach of setting a time limit for deletions on the basis of no source, so that any file which was uploaded before the time limit is by default considered to have no significant doubt as to the release, unless new evidence is presented. In simple terms, if Commons contributors, reusers and the general public have had a large number of years to challenge a file and have not been interested, then the doubt must be considered insignificant unless new evidence is presented. This shifts the burden of evidence from the uploader (who is often absent after several years) to the contributor requesting deletion.

Here's a form of words to consider adding to the Precautionary principle:

  • Files uploaded or transferred to Wikimedia Commons more than 5 years ago declared as public domain but fail to have a verifiable source, default to having no significant doubt as to their public domain status. Any files suspected of being copyright violations that have been hosted longer than this are not eligible for speedy deletion, but must be nominated using the normal deletion request process where the new evidence as to significant doubt must be documented.

-- (talk) 16:18, 26 September 2016 (UTC)

  • Symbol oppose vote.svg Oppose As a public domain reviewer (Commons:WikiProject Public Domain/PD-Art review) I see quite a few times where people uploaded images as PD, but withouth them actually being PD. As with any other part of COmmons, it is the one who uploads the images that always needs to prove that they do "good". We should not force people questioning authenticity to have to investigate it as well, only those who wants to keep it should. There's a reason PRP exists, and it is the exact opposite of what this proposal is for - to ensure our reusers that we do everything we can to make sure that all content actually is free, and not just "this has been here 5 years,. it may or may not be free, we don't know beause we aren't checking this file due to age". 5 years is not "long ago enough", if such a thing would be introduced. Just my 2c... Josve05a (talk) 16:27, 26 September 2016 (UTC)
  • Symbol oppose vote.svg Oppose I think the proposal confuses a few areas and amending COM:PRP is not the place. Instead it seems more that the Commons:Criteria for speedy deletion should be amended. If these files are being deleted based on File #5 "Missing essential information", which normally gives only 7 days grace, then perhaps this (and some other) speed criteria could be amended to say that files on Commons for X years cannot be speedy deleted merely for lacking paperwork. Provided the admin team and others who participate at DR are happy with the consequential increase on their burden, then that might be a reasonable approach. Speedy deletion is always a pragmatic concern to ease the load where files are obviously unsafe and likely merit no further examination. If we had infinite resources then it wouldn't exist and all files would be examined. So policy concerning what should and should not be hosted, such as COM:PRP, are quite separate from procedural steps that we as a community decided to take for pragmatic reasons.
COM:PRP is policy for all deletion, and isn't concerned with speedy/slow. The comment about about "shifts the burden of evidence from the uploader .. to the contributor requesting deletion" is unsafe legally and I think confuses the "evidence" that the file is free with "evidence" of significant doubt. Surely it has always been up to the person creating a DR to explain why there is significant doubt, otherwise the DR is without merit. But the legal burden, to demonstrate the file is free, has always on the uploader (and on any re-user of our content) to satisfy us (or themselves, when re-using) that the content actually is freely available.
Commons is only useful where our medial is reliably determined to actually be free. If unsourced files have been ignored for 5 years, that doesn't say much about our reliability. -- Colin (talk) 17:11, 26 September 2016 (UTC)
  • Symbol support vote.svg Support there needs to be curbs on the behavior of deletionist admins, since they will not discipline themselves. i am sick and tired of apologizing to GLAMs for their deleted files, which get deleted after 7 days and then undeleted when the otrs gets reviewed, meanwhile disrupting the editathon. let the admins clean up some of the metadata, before deleting any more. make no mistake, the reputation of commons can not get any lower: it is as a "cultural buzzsaw". Slowking4 § Richard Arthur Norton's revenge 23:52, 27 September 2016 (UTC)

White Man Contemplating Pyramids by Richard Misrach[edit]

File:White Man Contemplating Pyramids.jpg
White Man Contemplating Pyramids by Richard Misrach
How can this image be public domain? I don't see any reference to an OTRS ticket or any explanation for it's supposed public domain status neither on the picture page itself or in the edit comments of the file. TommyG (talk) 21:21, 20 September 2016 (UTC)
  • Seems unlikely to me. Uploader Djkeddie seems to have uploaded a lot of Princeton Art Museum images that were deleted on just that basis. I'd suggest either taking it up with the uploader or simply nominating for deletion. I don't see anything here that needs the broad forum of the Village pump. - Jmabel ! talk 23:28, 20 September 2016 (UTC)
I uploaded a number of images that the Princeton University Art Museum itself classifies as in the public domain. However, after some back and forth with OTRS they wanted documentation the art museum was unwilling to provide. Given that those images were deleted. By all means mark this one for deletion as well. My apologies for the trouble.Djkeddie (talk) 14:34, 21 September 2016 (UTC)

I have marked this photograph for deletion. See Commons:Deletion requests/File:White Man Contemplating Pyramids.jpg. I suggest avoiding all images where the copyright symbol is used in the catalog, others may be fine to upload based on the original artist's death date, for example -- (talk) 01:50, 24 September 2016 (UTC)

September 21[edit]

Rotating Images[edit]

(Automatic translation) Hello, by chance someone will know if there is some kind of code so that images can be rotated directly from the projects? (Wikipedia, Wikibooks, Wiktionary, etc.), without having to rotate from Commons (ie, without having to upload a new version of the file and rotated) Thanks in advance and sorry for machine translation. Miguu (talk) 04:52, 21 September 2016 (UTC)

  • Assuming the rotation you want is a multiple of 90 degrees, and that it would always be correct for the image in question, Commons is where to do it. No need to re-upload: request it with the {{Rotate}} template. - Jmabel ! talk 18:08, 21 September 2016 (UTC)
Jmabel Yes, but the problem is that the rotated image will be displayed in all places in which it is used, I just want to be displayed rotated in place where needed, something like the code image pixels when you link, but in degrees of rotation / orientation of the image.
Is there any way to make this possible?. Miguu (talk) 01:11, 22 September 2016 (UTC)
It is possible to rotate images using CSS, but the browser has to support that feature. If the browser doesn't support it the image won't appear rotated. The number of users this affects would probably be a small percentage, but to make sure everyone has the same experience I think an alternative solution is best. Having a modified version uploaded would be best to make sure the experience is consistent. Just curious but what is a example case of when a image would need to get used in its original state and a rotated state? Offnfopt(talk) 01:54, 22 September 2016 (UTC)
Not only that, it also has no effect on downloads of the images for instance. —TheDJ (talkcontribs) 11:16, 26 September 2016 (UTC)

Corrupted previews of File:La Peñuela, Zinacantepec, Estado de México.jpg[edit]

Does anybody know why previews of the photo look this way and how to fix it? Only the full resolution version looks as expected. Isn't it a bug in MediaWiki? --jdx Re: 09:06, 21 September 2016 (UTC)

I'm not sure what programs are used behind the scenes to generate thumbnails, so can't do tests or answer the question of why. But I uploaded a modified image, converted to RGB instead of CMYK, resaved and uploaded and all seems good now. Offnfopt(talk) 09:44, 21 September 2016 (UTC)
FYI this is how Firefox displays the photos: File:Comparison of photos.png (I will nominate this file for speedy deletion in a week or so). The original is on the right and has very saturated green. --jdx Re: 14:27, 21 September 2016 (UTC)
@Bawolff: May this be an issue caused by the old version of ImageMagick used on Wikimedia servers? Or is the latter not true anymore? — Speravir_Talk – 15:57, 21 September 2016 (UTC)
Possibly the same issue as phab:T141739. Matma Rex (talk) 17:01, 21 September 2016 (UTC)
BTW found in Help desk: Cf. first versions of File:Bernadotte-aktionen. Danske Røde Kors busser kører gennem Odense d. 17. april 1945 på vej til Sverige med danske fanger fra tyske koncentrationslejre (7392607518).jpg. — Speravir_Talk – 17:26, 21 September 2016 (UTC)

Quality maps and ortophotos freely licensed[edit]

HI. I found that es:Ministerio de Fomento de España licensed (official bulletin) released nine months ago the content digitally available published by the es:Dirección General del Instituto Geográfico Nacional with a free license "compatible" with CC BY 4.0 they say.

This would include a huge amount of content (MTN25 and MTN50 Mapa Topográfico Nacional, and even aerial photographies of PNOA (Plan Nacional de Ortofotografía Aérea), and more stuff). Terms are:

“1. Conforme a la Orden FOM/2807/2015:, por la que se aprueba la política de difusión pública de la información geográfica generada por la Dirección General del Instituto Geográfico Nacional (IGN), esta licencia de uso ampara el uso comercial y no comercial, la reutilización, la redistribución, la modificación y la generación de productos y servicios de valor añadido a partir de los productos y servicios de datos geográficos digitales del IGN.”
“2. El usuario titular de la licencia se compromete a citar al Instituto Geográfico Nacional (IGN) mediante la fórmula: «© Instituto Geográfico Nacional» como origen y propietario de la información geográfica suministrada ante cualquier exhibición o difusión de ella, o de parte de ella o de cualquier producto que, aun siendo de forma parcial, la incorpore o derive de ella.”
“-Si se tratara de Ortofoto o MDT5 (PNOA®), la mención se sustituirá por: «PNOA cedido por © Instituto Geográfico Nacional».

- Tratándose de datos LiDAR, la mención se sustituirá por: «LiDAR-PNOA cedido por © Instituto Geográfico Nacional».
- En caso de datos SIOSE®, la mención se sustituirá por: «SIOSE cedido por © Instituto Geográfico Nacional».

- Tratándose de CartoCiudad®, la mención se sustituirá por: «CartoCiudad cedido por © Instituto Geográfico Nacional».”

I want to ask if this is ok for Commons. And if it is... A new specific template would be required and I need help with that. Strakhov (talk) 16:54, 21 September 2016 (UTC)

  • Looks to me like this meets our requirements; pretty similar to CC-BY. Does anyone think otherwise? - Jmabel ! talk 18:10, 21 September 2016 (UTC)
  • If it does than we need to create a license template. May be {{Attribution-IGN}}? --Jarekt (talk) 18:53, 21 September 2016 (UTC)
    • Yes, though the third condition means we'll need variants, either via different templates or via a parameter. - Jmabel ! talk 19:24, 21 September 2016 (UTC)
    • Yes, that's it. One template with parameters or 5 "potential" templates ("IGN", "PNOA via IGN", "LiDAR-PNOA via IGN", "SIOSE via IGN" and "CartoCiudad via IGN"). Strakhov (talk) 19:18, 22 September 2016 (UTC)

September 22[edit]

Follow list[edit]

I keep track of all the files I uploaded with the follow system. Today two of my files where renamed. There are redirect links from the old name to the new name. As usual I removed the follow mark from the link to avoid double counting. Unfortunately I didnt notice that I dont have a follow mark on the file with the new name. As there is no history of changing follow marks, I cant cant find the renamed file to put a mark on it. As I follow 8590 files uploaded over a period of ten years I cant easily find the missing files.

  • Is something changed so that the follow marks are not kept with a rename?
  • Is there a history of renamed files on 22-9-2016?Smiley.toerist (talk) 12:42, 22 September 2016 (UTC)

Update: The two files are in fact on my follow list: File:Calle Redes, Seville 001.jpg, File:Calle Abad Gordillo, Seville 001.jpg, but the name change doesnt trigger an entry on the recent notification list. That why I was confused. Before you got two entries on the recent modification list: The creation of the new redirect link and the rename itself.Smiley.toerist (talk) 12:51, 22 September 2016 (UTC)

What is wrong here?[edit]

Is this Mural in the General National Archive in the Dominican Republic or Colombia? --Jos1950 (talk) 17:58, 22 September 2016 (UTC)

Jos1950 why Colombia? And this should be discussed here: File talk:DO AGN Mural inside of the General National Archive in Santo Domingo, Dominican Republic.jpg. -- Rodrigo Tetsuo Argenton m 04:27, 23 September 2016 (UTC)
Because Category:Archivo General de la Nación is the one in Colombia. More interesting: who painted that mural and when? I would expect it to be copyrighted and I don't know whether Dominican freedom of panorama extends to meeting rooms. If it did, that would be unusual. --rimshottalk 06:40, 23 September 2016 (UTC)
Well, type (don't need to press enter) at google "Archivo General de la Nación", you will see that Mexico, Argentina, El Salvador, Uruguay, Venezuela, Republica Dominaca, Perú... have one.
In Brazil, freedom of panorama is very extensive, some panels as this could be okay. -- Rodrigo Tetsuo Argenton m 23:03, 23 September 2016 (UTC)

Category changes in Wizard...[edit]

I now realise the changes in how to add categories in the Wizard Upload, and s h i t this is horrible! First I was staring the page trying to find the "add category", it's not intuitive put more than one category in that space, specially when your category have 6 words... Second, I was trying to put a name after to facilitate the search like: Category:Wikimedia Movement|W, and now this do not work! And if you are typing, and for some reason, you remove the attention of the box, the whole sentence disappears!!! o.O

After years, the Upload basics now is better again to put categories, holly mother, tks for the attention, I had to take this off my chest. -- Rodrigo Tetsuo Argenton m 23:11, 22 September 2016 (UTC)

PS:And if the category is a red link, it keep giving a warning blocking the contribution, seriously, I'm back to basic. 23:34, 22 September 2016 (UTC)

Thanks for your feedback. I work on this "s h i t", UploadWizard that is, in WMF's Multimedia team. The change you mention happened nearly a year ago (phab:T112764) and so far I think it was mostly appreciated. Let me reply to each point separately:
  • "First I was staring the page trying to find the "add category", it's not intuitive put more than one category in that space, specially when your category have 6 words..." Hmm, this is a fair point. Do you think it would be helpful to add a placeholder text there? (quick mockup: [4] [5]) If not, do you have any other suggestions?
  • "Second, I was trying to put a name after to facilitate the search like: Category:Wikimedia Movement|W, and now this do not work!" I don't think category sortkeys were ever intentionally supported (although they might have worked accidentally), but I was under the impression that they are discouraged for files? Why does the sortkey need to be different from the file name for your file? Commons:Categories only documents using sortkeys for subcategories.
  • "And if you are typing, and for some reason, you remove the attention of the box, the whole sentence disappears!!!" The field only accepts input that is a valid category name, and in that case it definitely does not disappear. It's an unfortunate interaction that "Wikimedia Movement|W" (with the non-working sortkey) is invalid :/ I think this is still more intuitive in the general case than allowing the input to remain, and then be discarded later because it is invalid. I guess another alternative would be displaying an error message.
  • "And if the category is a red link, it keep giving a warning blocking the contribution" It keeps giving a warning, because in most cases adding files to a non-existent category is a mistake. But it does not block the contribution, you just have to click "OK" in the pop-up dialog to confirm you want to do that? I know that some users prefer to upload the files first, and create the category later, and this is definitely supported.
Matma Rex (talk) 19:28, 23 September 2016 (UTC)
Matma Rex I was very frustrated about this, however I did not wrote that it is a shit, I wrote that is horrible... ;)
I was looking my recently uploads, none of them used multiple categories, normally because the specificity of them... and I'm more editing already uploaded images, so maybe because of that I didn't felt the changes.
  • The main problem is when we have something like "Projeto Commons da Faculdade Cásper Líbero (JO/2016)" or "Image overwrites by Jan Arkesteijn for independent review", the placeholder solution maybe not gonna work, as it will probably disappear in those cases... Putting "Category or Categories:" could reinforce the idea of plural, or give to lines to write, but I don't know. And this is more for old idiots, as me, that was used to have the "add category" button, I can see this as problem, but not that big and not a general issue, as this is a similar tool used in other websites. One thing that could be implemented is the FB example, you type your friend, he writes it above, as a confirmation, could be good.
  • We discourage, however for maintenance purpose in some cases I had to do it, for example the category "Projeto Commons da Faculdade Cásper Líbero" is the one that I was working. In this case, students are responsible for one monument, and they have to produce 20 photos of them. We can see whole work of single student crossing categories, but is not that easy as we are talking about 170 students, and 20 photos per student. The sortkeys was a solution to agglutinate the files of the students, without using subcategories, because for this case, is not that necessary, and was easier to see the whole thing. This is not a general problem, but I don't see why we can't do it in Wizard...
  • I don't know, but this is like that for how many characters? It's just for | and /?
  • The red link part was the worst one, first I typed and nothing happens, I retyped, and retyped, and them, I cancelled the upload, do all it again, retyped, and them someone call me at FB, I changed the tab, and them it appears... because now you have to remove the attention or press enter to generate the red link.. nothing different from the past version, but it was intuitive, as we removed the mouse clicking in add new category, and we did not realise the system.
Students of this project also had difficulties to create a red link category, it's not intuitive, and we can't obligate every contributor to realise how it work.
To click okay I had to click 3 times to go... I don't remember why, but something prevented the first tentative, them I put one blue link, and tried again... I could press something wrong, however, this is already red, we have a a giant phrase down there (One of the categories lacks a description page. Are you sure you typed the name correctly?), I don't see the necessity to put one more gate, could be good for preventing mistakes, but this deteriorates the experience of contributing here, and we can fix mistakes latter... One more thing, you are assuming that we are making a mistake, you could assume that we are creating something new... One of the categories lacks a description page. You'll create a new one or it's just a mistype? Coming back to the confirmation phrases, we could put one small "new?" in red ones, to grab the attention of the volunteer.
Thanks for your time, and for the contribution, I was rude, I'm sorry for that, but this was a sum of bad experiences in just one moment.-- Rodrigo Tetsuo Argenton m 22:47, 23 September 2016 (UTC)

September 23[edit]

Commons:Fan art[edit]

Is this a valid edit? I don't know too much about fan art. --jdx Re: 06:59, 23 September 2016 (UTC)

  • I'd say that's accurate. If a given author, band, etc. OKs fan art, it's still fan art. - Jmabel ! talk 15:52, 23 September 2016 (UTC)
    That is the common definition of fan art, so yes. Copyright wise an OK by the author is not generally broad enough for our purposes, so little changes on that front. Jo-Jo Eumerus (talk) 18:39, 23 September 2016 (UTC)

Max upload size?[edit]

What is the max upload size (for various methods)? I have videos from 60 to 800 mb, and the large ones fail to upload. What does it mean on the file page "Transcode status", the files was already in webm 480 format when uploaded - has it been re-encoded again? That lowers the quality, I would say. --Janwikifoto (talk) 11:59, 23 September 2016 (UTC)

You should be able to load 4GB files; Commons:Maximum file size. Whichever method you use, the larger files will fail unless you are using chunked uploading and even then may have failures due to operational issues or the file being detected as problematic once in the process of being 'assembled' at the server side. As for transcoding, this is to make the video available in a number of (lower quality) sizes, if your original is in webm, it should stay unchanged. -- (talk) 12:33, 23 September 2016 (UTC)
I have used Commonist, as I am able to set copyright template with that. THe doc says it fails over 100 mb, so no gb there. The Upload Wizard has no description of sizes. I use mobile data, so I can not "play and test" several hundred mb woth of billed data traffic. Hard documented facts would be preferred. No, I am not going to use chunked upload, it will create too much work for me, to learn. --Janwikifoto (talk) 12:40, 23 September 2016 (UTC)
I have reported the issue to the GitHub repo where the code is maintained. On the other hand, Commons:Maximum file size is the "hard documented fact" regarding maximum file size. UW should be quite straightforward to use. And for non-chunked uploads, I'm sorry, HTTP isn't designed to upload large files in a single request ([6]). And AFAIK uploading 100MB+ files to commons without chunked uploading is technically impossible because of the max request body size restriction set somewhere. And as for your rationale of mobile connection not suitable to "play and test", well, you're of "play and test" without chunked uploading, as any disconnection/failure in the process force you to restart from the first byte, wasting more traffic than with chunked uploading. --Zhuyifei1999 (talk) 13:05, 23 September 2016 (UTC)
Thanks for reporting the issue.
As a rule of thumb based on my 2 million uploads, if your files are greater than 40MB, you can guarantee regular failures in a large upload. I would say it's worth using chunked uploading for any file over 20 MB. I believe the standard upload wizard does handle chunked uploading, though I don't know where this is documented in the help pages.
P.S. don't use mobile data for uploads. It would be worth having a chat with your local library, university or school to see if you can save up your upload projects and use their broadband connection. It may even give them ideas for local open knowledge projects. -- (talk) 13:14, 23 September 2016 (UTC)
I use the Commonist for my regular uploads from less that 1 MB to 100 MB and the VicuñaUploader for more than 100 MB upto more that 1 GB. Biswarup Ganguly (talk) 15:03, 23 September 2016 (UTC)
I've used chunked uploading for 'many' files, including images over 100MB... it works quite well, though the way to create a 'new' upload with it is less than obvious. Reventtalk 02:56, 26 September 2016 (UTC)
@Janwikifoto: As Fæ says, UploadWizard uses chunked uploading (you do not need to learn anything, it happens automatically) and can happily handle files up to the maximum size, 4 GB – this is documented at Commons:Chunked uploads. I have also heard good things about VicuñaUploader if you prefer a desktop tool, although I never used it myself. Matma Rex (talk) 18:52, 23 September 2016 (UTC)

How to assert right of integrity[edit]

Is there a recommended statement to add to images that I have uploaded to make it clear that the original descriptions should not be changed? As in this discussion, I am unhappy that another editor has made statements that the plants I photographed in a botanical garden are mislabelled in that botanical garden. (Of course, there is a taxonomic issue here, but it is not relevant, since taxonomic opinion is just that, an opinion (and I say that as a professional botanist).) If there is no neat way to stop people from maligning the botanical gardens and their staff, then I will make a decision not to upload any more images from such institutions. In practice, I think that would be a pity, because those gardens are likely to yield photos of quite a number of rare plants for which we do not yet have photos, and the wikipedias could potentially benefit from such images. Nadiatalent (talk) 21:51, 23 September 2016 (UTC)

  • Sorry, you cannot lock down the descriptions here on Commons. Just like Wikipedia, people can edit. I have no idea who is correct about this particular plant, but User:MPF is correct to state that a dispute over the filename is not a reason to delete. I've seen plenty of images uploaded with mis-identifications by the uploader, and we need to be able to correct those. Just for example, I recently encountered a picture of Everett, Washington whose uploader identified it as Seattle. Part of the point of a wiki is to be able to correct things like that. I'd suggest that if you wish to upload photos in a way that no one else can edit the comments in your master, you might consider a site like Flickr or Panaramio rather than a rather open wiki like Commons.
  • On the other hand, if the facts are in dispute, the person who made the edit should not be able to choose unilaterally to have only their view of the matter in the description. - Jmabel ! talk 23:34, 23 September 2016 (UTC)
    • @MPF:
    • I'm not very strong in botany, so I could be completely off-base here, but if I understand the edit User:MPF is asserting that C. arizonica var. glabra is a synonym for Cupressus glabra, and that that is what we see here. this would seem to be one of an almost infinite number of disputes about biological taxonomy, in this case over whether this is considered a varietal or a distinct species. In that case, while there may be a disagreement here, there is nothing in the labeling that could clearly be considered wrong; at most, it's incomplete. - Jmabel ! talk 23:46, 23 September 2016 (UTC)
  • Pictogram voting comment.svg Comment Commented in the DR. Jee 03:56, 24 September 2016 (UTC)

September 24[edit]

Category language confusion[edit]

Hi, folks. I have a problem finding the appropriate name for a category. I want to provide pictures from the green houses of the recently abandoned botanical gardens of Saarland University.

  1. Do I mark the garden as "abandoned" (or similar) in the category name (as far as I know it is the first botanical garden in Germany that a university has given up on, Karlsruhe supposedly being the next to follow)
  2. Do I use a German or an English language label, given that I need the following two super-categories:

Thanks for any insights you can provide. --chris 17:55, 24 September 2016 (UTC)

  • Category name shouldn't mention "abandoned", since we'd presumably use the same category if we got older photos from before it was abandoned.
  • I'd stick with English. I'm actually a little surprised that Category:Universität des Saarlandes uses German, since there would be an obvious English-language name (Saarland University), and category names normally use English in such a case. - Jmabel ! talk 02:29, 25 September 2016 (UTC)
Thanks a lot. Shouldn't then the university category be moved? --chris 06:16, 25 September 2016 (UTC)
Addendum: After having another look it seems most, if not all German university categories use the German label as if it was a proper name, e.g. Category:Technische Universität München, even in combination with other English labels, which I find very confusing: Category:Alumni of Technische Universität München. So we apparently can't just move one cat. This has potential for a nice and extensive discussion x) --chris 06:28, 25 September 2016 (UTC)

Category:People by name et al. as flat list?[edit]

Hi, I currently have a little dispute with Raimundo Pastor. In my eyes the categories Category:People by name, Category:Men by name and Category:Women by name are "flat list" cats. So: Any people should be in Category:People by name, every man should be in Category:Men by name and every woman should be in Category:Women by name. Since a while I'm busy checking a lot of people cats and adding those and other missing cats. Its now the first time somebody reverts and disagrees these edits. Whats the opinion of the others. Should i.e. Category:María Teresa Torras in Category:People by name and Category:Women by name although it is in Category:Women of Spain by name, or not? --JuTa 21:12, 24 September 2016 (UTC)


La idea principal de las categorías es su posibilidad de organizar los contenidos por medio de características objetivas para poder buscar información. Organizándolo como una estructura arborescente, desde categorías más generales, que se subdividen en categorías más específicas. Por eso Category:Women of Spain by name es una subcategoría de Category:Women by name, esta a su vez es una subcategoría de Category:People by name by gender, y esta a su vez es otra subcategoría de Category:People by name by gender, etc. Lo mismo se consigue con la categoría Category:Men of Spain by name. Esto permite disponer de localizadores más específicos y ganar en calidad a la hora de buscar contenidos.

Si se mantiene Category:People by name como único buscador de personas, se corre el peligro de que sea tan grande (entran todos los seres humanos) que en la práctica no sirva para localizar a nadie. Puedo entender que se use como identificador en Wikidata, pero no como una categoría en Wikipedia o en Wikimedia Commons, ya que no aporta nada. Un cordial saludo:--Raimundo Pastor (talk) 10:57, 25 September 2016 (UTC)

  • Por lo general, Vd. tiene razón, pero creo que esto es uno de las pocas excepciones. Hemos decidido hace años crear y mantener unas pocas categorías planas. Sí, son grandes. Grandísimas. Y es OK. Por gran parte, beneficiaron bots, no usarios humanos. Pero, según los operadores de los bots, son útil. Favor de dejarlos y no revertir. - Jmabel ! talk 14:54, 25 September 2016 (UTC)
OK, I will create new Category:Men by name by country and Category:Women by name by country and sort them under Category:People by name by country and not anymore under (Wo)men by name. Then any catscan and similar dont get anymore confused by such subcats. And furtheron all 3 cats (1, 2, 3) can and should be handelded as flat categories in future. regards. --JuTa 19:13, 27 September 2016 (UTC)

September 25[edit]

Two versions of same painting[edit]

I notice that Wikimedia Commons has both File:Edvard Munch - Melancholy (1892).png scanned at 1,409 × 949 pixels, and File:Munch Melankoli 1892.jpg, which appear to be the same painting scanned at 4,000 × 2,682 pixels. Assuming that they are in fact the same, should the lower-resolution scan maybe be replaced with a redirect to the other? I don't know what the policy is on that sort of thing: if a change is appropriate please do it, it not then never mind. -- 23:00, 25 September 2016 (UTC)

See COM:Dupe. Since they are the same scan, from the same source, I'll mark the lower resolution version as a duplicate. --ghouston (talk) 23:35, 25 September 2016 (UTC)

September 26[edit]

Help of a New Zealander is needed[edit]

What does "manuka" mean in the English description of File:Kiwi feeding mason bay nz.ogv? Does it mean "a piece of land where mānuka shrubs grow"? --jdx Re: 13:48, 26 September 2016 (UTC)

Try to ping someone active in w:Category:Wikipedians_in_New_Zealand or w:Category:User_mi: User:Kiore, User:Ingolfson, User:Akld guy, User:Kiwi128, User:Nurg (these names I saw active on enwikipedia in the last month, for example). Or ask directly on w:Wikipedia:New Zealand Wikipedians' notice board.--Alexmar983 (talk) 14:18, 26 September 2016 (UTC)
@Jdx: @Alexmar983: Manuka is a type of tree, as the en:Leptospermum scoparium article says. It starts as a shrub and can grow into a tree of substantial height. 'Manuka' is NOT used to refer to a piece of land. The description means that the kiwi is feeding amongst the manuka trees. The description is badly worded. The kiwi feeds on insects in the ground and the manuka trees are not related to its diet. The film has simply captured images of a kiwi that happens to be feeding in an area where there are manuka trees. Akld guy (talk) 19:40, 26 September 2016 (UTC)
The file appears to have been uploaded by a user who is not a native speaker of English and he/she may have used an idiom "feeding in manuka", meaning "feeding in an area where manuka trees grow", that is used in his language but is not appropriate in English. I will change the wording in the next day or two. Akld guy (talk) 21:06, 26 September 2016 (UTC)
@Akld guy: Thanks for explanation. In Polish translation I have already used phrase "żerujący pomiędzy krzewami manuki" which almost exactly means "is feeding amongst the manuka trees" – I have used "shrubs" (Polish "krzewami") instead of "trees". --jdx Re: 03:47, 27 September 2016 (UTC)

Tech News: 2016-39[edit]

18:07, 26 September 2016 (UTC)

September 27[edit]


Hello.Is this talk true? Thank you — Preceding unsigned comment added by ديفيد عادل وهبة خليل 2 (talk • contribs) 2016-09-27 13:26:58 (UTC)

Looks iffy: The licensing tag goes around the notion of photography of a 2D original, but is nowhere said how is this recent 2D orinal artwork in Public Domain in the first place. -- Tuválkin 13:50, 27 September 2016 (UTC)
IMO this would only be a valid licence if the copyright in Jordan expires with the death (murder...) of the artist. --Magnus (talk) 13:57, 27 September 2016 (UTC)

Contrast in thumbnails vs original[edit]

I asked this before, but I don't remember the solution, because each time I think I solved all known cases of it. Look at File:Harriet_Quimby_054.png then click on the original and see how the contrast is optimized. The previous solution was to reopen in GIMP and save with GAMMA settings checked. Is there a way to automate getting the thumbs to have the right contrast without opening and resaving in GIMP? --Richard Arthur Norton (1958- ) (talk) 16:31, 27 September 2016 (UTC)

Not after upload, but if you have a bunch not yet uploaded, you can add the gAMA chunk using ImageMagick's convert (with +gamma .454555) or pngcrush (with -g 45455) from the command line. Storkk (talk) 10:40, 28 September 2016 (UTC)

September 28[edit]

Hillary Clinton in a wikiquote banner[edit]

It's not a technical matter, but still I am informing local projects, I can also link it here File talk:Bandeau wikiquote.jpg. Clinton or not Clinton, If anyone is good with graphics maybe (s)he can easily upload a more balanced version including more women or non-white or scientist or whatever. Nelson Mandela, Marie Curie, Mother Teresa... name one. Faces people can recognize but with much less "sociopolitical tension".--Alexmar983 (talk) 11:22, 28 September 2016 (UTC)