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


Village pump in Rzeszów, Poland [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch


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)
i would say it is about culture, which is more specific and stronger than competence. We have to start to think that when possible if you know nothing about a specific topic or language, you don't start a deletion procedure of a file related to those aspects. The main goal should be learning and sharing information, not doing. But in the meantime an efficiency approach is one of the card to play. At least from my experience with backlogs. Some users just don't want to go to the specific projects or stay focused in a field. they want simpler scheme where they can "push the bottom". They exist, so you try to reduce the negative effects of their approach. There are also positive effects, they can really work hard, but you have to regulate them. Guide the flow.--Alexmar983 (talk) 08:55, 29 September 2016 (UTC)
yes, it is a toxic culture, from a callous disregard for the for the work of others, not seen in competent people, along with a passive acceptance by the majority. it is a dysfunctional process of stripping information, and automatic deletion by box-checking, rather than image curation with research. it is backlog reduction by summary deletion, rather than metadata improvement. this will not change as you see below, but happily, the attention span of the toxic individuals is short, so the semi-professionals can route around the censorship. Slowking4 § Richard Arthur Norton's revenge 15:58, 29 September 2016 (UTC)
you're nasty! :)--Alexmar983 (talk) 06:35, 30 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)
@Slowking4: If you are having a repeated problem with that, you should probably start using (or tell the people you are working with to start using) the {{OTRS pending}} template, so that the files won't be deleted after seven days. You and Prosfilaes also need to both stop the insults. Seriously. Reventtalk 19:00, 30 September 2016 (UTC)
  • You know that we do similar politic for old-scans?
We wait for someone claim the authorship of the file, and until them, we simply keep it.
2 cents. -- Rodrigo Tetsuo Argenton m 22:29, 29 September 2016 (UTC)

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)

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)
(I will reply to this properly soon, sorry about the delay. I'm just bumping so that the thread doesn't get archived.) Matma Rex (talk) 19:01, 30 September 2016 (UTC)

September 23[edit]

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)
thank a lot for driving away another contributor. there are less bitey ways to correct species names. but why bother when you can edit war. Slowking4 § Richard Arthur Norton's revenge 15:23, 29 September 2016 (UTC)

September 24[edit]

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]

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)

Why not just remove the banner from wikiquote? Regardless of who you put on the banner there will almost always be someone that doesn't agree with that choice or wish for someone else. You're better off letting individuals pictures stay in their own domain (i.e. articles about those individuals). Offnfopt(talk) 12:10, 28 September 2016 (UTC)
If a wikiquote wants that specific banner, fine with me. I think it was used because it's one of the few ones with that style. It is in fact better than "File:Bandeau wikiquote2.jpg". Itwikiquote has a nice banner too but with mainly Italians, so it's too local. In any case it was popular because it is effective for wikiquote (and wikisource, it's used for the author index on itws). I mean it was a nice, balanced style, I like it too. It's used because it's good. But if we had a version without Clinton would be better. Someone will never agree, ok. But there are people on whom we can all agree 99.99%, bcause they are part of history. He should have focused on some of those.--Alexmar983 (talk) 12:24, 28 September 2016 (UTC)
I would recommend getting a consensus first on the wiki where the banner would be used. After it has been agreed who would be on the banner (and ideally even found some image(s) to use for the edit), then you could make your banner request at the Graphic Lab. Offnfopt(talk) 13:10, 28 September 2016 (UTC)
I linked the file talk from all those wikis. I wasn't going to ask the Graphic Lab directly. I just though it should be discussed at least, than if they are ok with it, let's stick with Hillary. In any case, creating a new banner of a similar quality is also a possible strategy, they can choose later to replace it. I think we discussed enough here.--Alexmar983 (talk) 13:19, 28 September 2016 (UTC)

Covers of books[edit]

I don't known it, for this reason I wonder it: you can upload to Wikimedia Commons freely covers of books if the author is alive and without authorization in OTRS? I ask it for the files uploads by Carlos Marianidis. It is highly likely that the user is the author of these books because he uploaded a cover in 2015 from a book published en 2016 (File:Nocturno 48, Editorial Libros & Libros, Bogotá, 2016.jpg). --Metrónomo's truth of the day: "That was also done by the president" not an excuse. 15:56, 28 September 2016 (UTC)

  • I'm not sure I understand exactly what you are asking ("I don't known it, for this reason I wonder it" is very unclear English, at least to me, then it's followed by what is grammatically a statement but is followed by a question mark. (Si Vd. es hispanohablante, creo que sería más fácil si Vd. escribe en español.) My take on File:Nocturno 48, Editorial Libros & Libros, Bogotá, 2016.jpg: OTRS would certainly be a good idea, but in this case I'm so close to certain that the uploader is the author of the book that I myself would never start a deletion request in such a case. - Jmabel ! talk 04:40, 29 September 2016 (UTC)
When a book has artwork on the cover, this is rarely the direct work of the author, and may have a different copyright to the book text. Any OTRS statement would have to take account of that. -- (talk) 04:44, 29 September 2016 (UTC)
In File:Nada detiene a las golondrinas, Ediciones El Naranjo, México 2015.jpg you can read "Adriana Campos, ilustración" ("ilustrated by Adriana Campos") and in File:Las Cuatro Estaciones.jpg say "ilustrado por Sandra Lavandeira". The drawings are the work of different authors, as you can read here. --Metrónomo's truth of the day: "That was also done by the president" not an excuse. 10:51, 29 September 2016 (UTC)
De todas formas yo quería preguntar algo más general. ¿Para subir una portada a Commons es suficiente que lo haga el autor del libro (que generalmente es solo autor del texto) o se necesita algún permiso extra? Como el autor de las ilustraciones, el fotógrafo (si hay una fotografía) o la editorial que lo publicó. Las cláusulas del contrato con la editorial no los conocemos. --Metrónomo's truth of the day: "That was also done by the president" not an excuse. 12:29, 29 September 2016 (UTC)
Ah. Typically, OTRS from the publisher would suffice, since they need to have all the copyrights in line; I suppose ideally we would have OTRS from artists for individual design components. I agree that technically the author of the text doesn't have all the permissions, and I suppose someone could nominate this for deletion & it would succeed. I personally am not such a stickler where it is pretty clear that someone this connected did the upload: it's hard to imagine that the author was acting without at least the implicit consent of all involved. - Jmabel ! talk 16:49, 29 September 2016 (UTC)

Image maps are not updated[edit]

The maps linked from {{location}} template should show "this and other nearby images on: OpenStreetMap - Google Earth". However, updating of these maps (indexing of new images) ceased cca on 2016-09-12 04:05. Images from the last 16 days are not displayed. This service has always fails and delays, but over two weeks is too much IMHO.

However, the template documentation and the Commons:Geocoding page linked from the template don't contain more information about this tool/service and about contact to its operators/administrators. I think, the {{location}} template should contain an embedded message template which should inform about possible fails and limits of the service. --ŠJů (talk) 17:28, 28 September 2016 (UTC)

Updating seems to be renewed now. --ŠJů (talk) 02:54, 1 October 2016 (UTC)

September 29[edit]

Century categories[edit]

I have a question regarding the categories that spans long time periods and where the inclusion criteria may span several categories.

What is the criteria for a category like Category: 21st-century men of Norway? Is it the active period (for when the person was notable), date of birth? Which century category would a hypothetical Norwegian male person born in 1960, active as a politician from 1990 to 2010 and diseased in 2015 be placed in? Wouldn't this be both a 20th and 21st century man and should he be placed in categories for both centuries? Toresetre (talk) 17:25, 29 September 2016 (UTC)

As it is a part of the category tree of "people in 21st century", only images of Norwegian men that were made in 21st century should be included. Ruslik (talk) 19:07, 29 September 2016 (UTC)
No, the category is "21st-century men", not "21st-centry images of men". It's subcategories are categories of people. I.e. the first explanation is right - every of the subcategories should be placed to both centuries if appropriate. --ŠJů (talk) 10:09, 30 September 2016 (UTC)
Your explanation makes no sense. People typically do not belong to a single century. And the category has "people in 21st century" as its top category. Ruslik (talk) 19:56, 2 October 2016 (UTC)


Need review of sources and edit histories:

Xb2u7Zjzc32 (talk) 01:03, 30 September 2016 (UTC)

September 30[edit]

Possible jpeg rendering or import bug[edit]

I have noticed a few of my uploads in the past week appearing corrupt in thumbnails and sub-sizes after upload but not at the source nor when viewed at full size. These corruptions do not look like the normal digital corruptions I see from truncated uploads, which would normally have a grey area in the lowest part of the image. Instead these are odd striations, looking more like the failure I would see with a software bug or a faulty camera CCD. The numbers are very low, i.e. down at around 0.1%, however the same problem can be seen when importing jpegs from different sources. Worryingly I don't know of a automatic way of discovering these, though SHA1 comparisons may work, but this would be expensive in bandwidth for large batch uploads. The uploads are done as uploads by urls via the Commons API, rather than the files being downloaded to my local computer.


Anyone experienced this in the past week, or is it a known problem? -- (talk) 10:40, 30 September 2016 (UTC)

Both images used CMYK color instead of the preferred RGB color. There was a recent post about the same issue, if you convert the pictures to RGB color it resolves the issue. Offnfopt(talk) 10:53, 30 September 2016 (UTC)
Thanks. I've subscribed to Phab:T141739 and added these examples. I'm not going to fix any more of these, I'll leave them broken as the Commons system should be able to cope and even detecting the problem is a bit of a nightmare for batch upload projects. -- (talk) 11:08, 30 September 2016 (UTC)

Grants to improve your project[edit]

Greetings! The Project Grants program is currently accepting proposals for funding. There is just over a week left to submit before the October 11 deadline. If you have ideas for software, offline outreach, research, online community organizing, or other projects that enhance the work of Wikimedia volunteers, start your proposal today! Please encourage others who have great ideas to apply as well. Support is available if you want help turning your idea into a grant request.

I JethroBT (WMF) (talk) 19:52, 30 September 2016 (UTC)


WP:ENGVAR is probably well-known here. A policy that takes the sensible line that no English language version is favoured over another, but that we do need to avoid language ping-pong and edit-warring, so that we value stability over particular choices of spelling.

What is the equivalent for Commons? Does Commons need a similar statement?

Specifically, why rename Category:Machine vices (British English) to Category:Machine vises (US English) for no other reason than "Spelling 'Machine vices' is British English" ? Similarly other parts of the existing tree at Leg vices [13], Woodworking vices [14] and Hand vices [15]. Andy Dingley (talk) 21:42, 30 September 2016 (UTC)

@Andy Dingley: No. The closest is Commons:Language policy. —Justin (koavf)TCM 02:33, 1 October 2016 (UTC)
Commons:Naming_categories#Language is quite helpful. Categorization remains a major weakness in Commons, but moving to a Multilingual Categories + Tags system looks like it will wait until Wikidata forces it to happen by the back-door. -- (talk) 06:28, 1 October 2016 (UTC)
Sorry, I have added a subcategory “Bench vises” under the category ”Vises” and then, somewhat later, I saw some other subcategories having the spelling "vices" (Hand vices, Leg vices, Woodworking vices.) I renamed these categories giving them an equal spelling and I replaced all the files. I did not know that there was not an Wiki guide line about the prefered spelling in cases of spelling variants British / American English. Anyway it looked logical for me to do so. I am sorry if I unknowingly have irritated somebody. --Elgewen (talk) 08:49, 1 October 2016 (UTC)
PS [16]
[17] --Elgewen (talk) 08:52, 1 October 2016 (UTC)
  • So if a number of categories are long-term stable under one spelling, you add a new category, choose to introduce a different spelling, then the "needed" action is to rename all of the pre-existing categories to match your new one? Andy Dingley (talk) 19:12, 1 October 2016 (UTC)
  • Category:Vises has long been under that name, and it couldn't be under Category:Vices, because that category means something else. It was a bit ham-handed how it was handled, but the subcategories should have matched the name of the category, and even if there was agreement to move the main category, it couldn't have simply been moved to the British spelling. This is probably the best solution all around.--Prosfilaes (talk) 22:32, 1 October 2016 (UTC)
  • We have never had any policy that international variations must be kept consistent up and down a category tree. Andy Dingley (talk) 20:56, 2 October 2016 (UTC)
  • We've usually worked to reduce the amount of variation up and down a category tree. Commons:Naming categories says "A single name by given subject: we should not use different names to label a single subject. In particular, translations in other languages, or language variants are not an acceptable way to specify subdivisions of the main subject." so the idea is not unheard of.--Prosfilaes (talk) 11:06, 3 October 2016 (UTC)

October 01[edit]

August Commons:Photo challenge results[edit]

Firefighters and firefighting equipment: EntriesVotesScores
Rank 1 2 3
Image CAL FIRE Super Huey-N488DF.jpg Two Calera Firefighters.jpg Feuerschiff im Golf von Finnland in St. Petersburg. IMG 9266WI.jpg
Title CAL FIRE UH-1H Super Huey Two Calera, Alabama firefighters pause during a battle against a residential housefire on April 27, 2016 Feuerschiff im Golf von Finnland in St. Petersburg. Russland.
Author Tequask 31813D Kora27
Score 13 9 8

Congratulations to Tequask, 31813D and Kora27.

Underwater photography: EntriesVotesScores
Rank 1 2 3
Image Sea Turtle with Remoras - Marsa Alam, Egypt - August 9, 2011.jpg Christmas Tree Worm, Thailand, Spirobranchus giganteus.jpg Diver Silhouette, Great Barrier Reef.jpg
Title Sea Turtle with Remoras - Marsa Alam, Egypt Christmas Tree Worm, Thailand, Spirobranchus giganteus Silhouette of scuba diver with the sun behind.
Author GiorgioGaleotti TimSC TimSC
Score 12 12 10

Congratulations to GiorgioGaleotti and TimSC.

Please vote for September Commons:Photo challenge images here. --Jarekt (talk) 04:22, 1 October 2016 (UTC)

October 02[edit]

deleted files[edit]

Hello , i just wanted to ask if its possible by any mean to dowload/view deleted files , i m curious to see some of them , please help — Preceding unsigned comment added by Uchiha itachi007 (talk • contribs) 06:48, 02 October 2016 (UTC)

No it is not. That's why they are deleted, that they can no longer be viewed.--Bjs (talk) 10:44, 2 October 2016 (UTC)
More precisely: administrators have access to deleted files and can view them and, given proper reasons, undelete them. If you have a specific need to know what is in a particular deleted file -- for example, if you need to know whether it matches a particular file you have found elsewhere on the net, or if you suspect it has potential to be used to one of the Wikipedias where policies on non-free use are looser -- feel free to ask your specific question, as long as you understand that no one is required to follow up on it. - Jmabel ! talk 16:06, 2 October 2016 (UTC)

Fop Belgium[edit]

Could someone undelete File:De Wand schildering.JPG, as this is now allowed?Smiley.toerist (talk) 08:26, 2 October 2016 (UTC)

✓ Done. --Túrelio (talk) 08:30, 2 October 2016 (UTC)

October 03[edit]

Commons License Template statistics[edit]


Hi, I was just preparing some slides for my talk at WikiConference North America, and thought I will share some statistics.

Comments and corrections are welcome. --Jarekt (talk) 12:18, 3 October 2016 (UTC)

License selection[edit]

Would someone have a moment to look at this image. I got an warning about the license, and I'm not quite sure what license to place on it. The uploader marked it here as public domain. Thanks. Magnolia677 (talk) 12:22, 3 October 2016 (UTC)

You need to change the author to "Roger Puta" not "Marty Bernard". In the process of searching for Roger Puta I came across this template {{RogerPuta}}. Not sure myself what needs to be done, may need to contact a OTRS member to see what options there are (or maybe you'll get lucky and one will see this post). Offnfopt(talk) 12:43, 3 October 2016 (UTC)