Commons:Village pump

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

  Welcome to Commons   Community Portal   Help Desk
Upload help
  Village Pump
copyright • proposals
  Administrators' Noticeboard
vandalism • user problems • blocks and protections
↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
This project page in other languages:

বাংলা | Alemannisch | العربية | asturianu | авар | Boarisch | bosanski | български | català | čeština | dansk | Deutsch | Ελληνικά | English | Esperanto | español | فارسی | français | galego | עברית | hrvatski | magyar | íslenska | italiano | 日本語 |  | 한국어 | Lëtzebuergesch | македонски | मराठी | Nederlands | norsk bokmål | occitan | polski | português | русский | slovenčina | slovenščina | српски / srpski | suomi | svenska | ไทย | Türkçe | 中文(简体)‎ | 中文(繁體)‎ | Zazaki | українська | +/−

Welcome to the Village pump

This Wikimedia Commons page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. For old discussions, see the Archive. Recent sections with no replies for 3 days may be archived.

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 a waste of your time. One of Wikimedia Commons' basic principles is: "Only free content is allowed." This is just a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read the 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


Centralized discussion

See also: Village pump/Proposals • Archive

Template: View • Discuss • Edit • Watch
A village pump in Cork, Ireland [add]



If there is anyone who would like to know what it was like growing up during the blitz in London drop me a line I was originally a Gael then moved to London so that my Pappa could work at Bletchley Park then on from there I warn you I can chat the hind leg off a donkey! — Preceding unsigned comment added by Roberta Adair-Denham (talk • contribs)

Copyright status of a photo of a public domain painting[edit]

@Anne-Sophie Ofrim: OTRS received a request for either removal of, or rescaling to low resolution of the following image: File:Birkebeinerne på Ski over Fjeldet med Kongsbarnet (cropped).jpg

That image is a cropped version of:

File:Birkebeinerne på Ski over Fjeldet med Kongsbarnet.jpg

which asserts the underlying art is public domain and furthermore :

The official position taken by the Wikimedia Foundation is that "faithful reproductions of two-dimensional public domain works of art are public domain".
This photographic reproduction is therefore also considered to be in the public domain. In other jurisdictions, re-use of this content may be restricted; see Reuse of PD-Art photographs for details.

I think it is clear that the public domain nature of the painting means that any editor can take a photo, and upload it as public domain.

Does it also mean than an editor can find a photo taken by someone else (which asserts copyright) and use it as public domain, on the basis "faithful reproductions of two-dimensional public domain works of art are public domain"?

I think the answer is yes, but I want to make sure before responding to the person asserting copyright ownership.

Second, would it be appropriate to reduce the resolution, even if we believe that we are legally entitled to use the photo?--Sphilbrick (talk) 15:34, 4 October 2014 (UTC)

For agents: OTRS ticket 2014100210006534--Sphilbrick (talk) 16:25, 4 October 2014 (UTC)

If by "can", you mean that Commons policy permits it, then I believe the answer is yes. (Parts of the Commons community unfortunately decided that it would be a good idea to push through a policy stating that Commons should ignore actual laws using a vote – which of course isn't how policy is made around here, but it's how this one was made.) If you mean that they can legally do it considering that this is a photographic reproduction created in Norway, then I would say no. Given that the uploader of the cropped version appears to be Norwegian, I think it's up to her to decide what level of risk she is willing to accept before the complaint is addressed. LX (talk, contribs) 17:19, 4 October 2014 (UTC)
Just wanted to add that "File:Birkebeinerne på Ski over Fjeldet med Kongsbarnet.jpg", which is the original photograph showing the painting in its three-dimensional frame, is definitely not permitted on the Commons if the copyright holder did not consent because {{PD-Art}} does not apply to three-dimensional objects. I've tagged it with {{Non-free frame}}. Similarly, if the photograph had shown the painting at an angle hanging on a wall, that would also not be covered by PD-Art. — SMUconlaw (talk) 18:48, 4 October 2014 (UTC)
"When to use the PD-Art tag" got overwhelming support in that poll, and I'm confident we'd get the same overwhelming support today. Why should we have a policy unsupported by the WMF or a supermajority of Commons editors?--Prosfilaes (talk) 21:43, 4 October 2014 (UTC)
Which makes it a prime example of why policies shouldn't be decided through voting. LX (talk, contribs) 09:28, 5 October 2014 (UTC)
Not unless someone gives some evidence that this policy shouldn't exist.--Prosfilaes (talk) 23:24, 5 October 2014 (UTC)
In this case, there were significant objections preventing the policy from being passed based on a true consensus, so instead the discussion was cut short in favor of a simple headcount. Voting only takes into account what people want (usually: as many illustrations as possible), not whether what they want is legal or based on sound arguments. LX (talk, contribs) 13:15, 6 October 2014 (UTC)
No, it would not be appropriate to reduce the resolution. If the uploader is concerned, then we should act on that, but that we can use copies of 2D public domain art is strong, highly agreed-upon, policy.--Prosfilaes (talk) 21:43, 4 October 2014 (UTC)
Another version exists and was replaced in this article by the original uploader. The original uploader is User:Electristan and is not an eager contributor (and has not contributed to norwegian Wikipedia i.e. probably not Norwegian). The upload does not say who the photographer were. Does Sphilbrick have any information about why the complainant assumes the photograph is taken by him/her? The painting is available to the public in a public place. --  Dyveldi    10:55, 5 October 2014 (UTC)
As noted on File:Birkebeinerne på Ski over Fjeldet med Kongsbarnet.jpg, it is claimed to be ©: O. Væring. The person writing in is a representative of O.Væring.--Sphilbrick (talk) 16:01, 5 October 2014 (UTC)
Thanks Sphilbrick. The photographer O. Væring died in 1906 and left a firm behind. The Norwegian National Library has quite a few photograpies freely avaliable to the public by O. Wæring. Judging the ages of this photography can't be done by the age of the photographer O. Væring or the age of the firm (they also had a lot of photographers working for them). The original picture is depicted here and has a quite different frame. At Norwegian Wikipedia we now wonder if this photograpy is a photography of a reproduction. If the company O. Væring has taken the photography they should be able to provide an accurate date/year and where the photograpy was taken and if this is i photography of a reproduction or not. They should also be able to identify why this photography belongs to them (is downloaded from their nedsite etc?). If this is a photography of a privately owned reproduction taken by a private person I most certainly do not know the copyright status. --  Dyveldi    17:50, 5 October 2014 (UTC)
Without knowing the history of the piece at Holmenkollen Skimuseum and what claim there is in the OTRS Ticket, it is a bit difficult to say if it is legal or not to publish it here. The original painting is old and "falt i det fri" (protected for 70 years after the creator died) in Norway, that is approx public domain or perhaps more like a CC-by-sa with some limits on how you can use it, like a kind of very limited nd-ish or what you would call ideal rights. You can resample, but not if that degrade the original painting or the creator. It is also an open discussion if resampling is legal if it does not add any artistic value, but lets not go down there. If you take a photograph of the original without adding any artistic value the photo is what we call "fotografi" or "photography" and not a "fotografisk verk" or "photographic artwork". Such a photography has protection, but it is somewhat limited compared to the original creator. It can not limit or change the rights of the original creator or his artwork. When a photo is old (50 years from the creation or 15 years after the creator died) it will be public domain, and not have any further protection. If that copy is not made as a photo/-graph it would not have any protection at all. A scan of a photograh would neither have any additional protection. If the photo is made as part of the photographers job at a firm the firm acquires the rights, but then the protection only runs for a very limited timespan 50years from the first publication creation of the photo. If you acquire a legal copy of a photo that has "falt i det fri" you are free to use it any way you please, as long as the original photo is "falt i det fri". So the question is; is this photo of a reproduction, is the reproduction of an original, and when did that happen.
The company O. Væring is known to do scan of old books and republishing those scans. If that has happen here I do not know, but the company should produce some hard facts about who made the photography and when. In short O. Væring must substantiate their rightful claim, otherwise it is likely that what they have is just a claim on a photo made to create a reproduction that has "falt i det fri".
I would say go with the official position taken by the Wikimedia Foundation and let O. Væring send a take down notice, then they must substantiate their claim. In the mean time somebody should check the painting/reproduction at the Holmenkollen Skimuseum. Perhaps check some other sources too. Jeblad (talk) 13:16, 5 October 2014 (UTC)
you might want to review Commons:The_Commons_Log/2009#National_Portrait_Gallery_copyright_dispute; w:National Portrait Gallery and Wikimedia Foundation copyright dispute. NPG and others have a view, and WMF has another. i would also change the license to PD-art/PD-100 Slowking4Farmbrough's revenge 12:13, 7 October 2014 (UTC)
I have asked some of the involved people about this painting but so far there is no reply. Jeblad (talk) 09:38, 15 October 2014 (UTC)

Correct. We should keep the file in question, delete the one with the frame, and use the NPG case as a guide.--Elvey (talk) 02:16, 10 October 2014 (UTC)

October 05[edit]

Suspend the Upload Wizard[edit]

I propose tu suspend the Upload Wizard temporarily because it's current interface causes massive serious systemic inaccuracies in file description, and there is no adequate reaction to reports on the feedback page.

  • the "location" box doesn´t distinguish object location and camera location and presents the imported or entered object location by a template intended for camera location.
  • the "location" box doesn't allow to enter the heading (of camera location)
  • the "date" field don't allow to distinguish what does the entered date mean (date of taken, date of last edit/modification of the image, date of the first publication etc.). The date copied automatically from EXIF is not presented in {{According to EXIF data}} template to allow to take account of possible incorrect setting of the camera.
  • the link "Add location and more information…" and the textbox "Other information" are misleading and cause that some users write the detailed description into this field (i.e. outside the {{Information}} template) instead into the description field. The "description" textbox is disproportionately small which made this confusion bigger.

--ŠJů (talk) 19:32, 6 October 2014 (UTC)

  • Symbol oppose vote.svg Oppose on the grounds that UploadWizard really does make uploading easier. -mattbuck (Talk) 20:22, 6 October 2014 (UTC)
  • Pictogram voting comment.svg Comment if you suspended wizard until it was fixed, it might never happen. there is the option to use the old uploader, but it's even worse. seriously, one of these decades, someone needs to update upload tools - they are a major pain point. Slowking4Farmbrough's revenge 12:20, 7 October 2014 (UTC)
  • Symbol oppose vote.svg Oppose UploadWizard is much better (in my opinion) for inexperienced users than the alternatives. I usually like to use Basic upload form but it is not for everybody. ŠJů, I agree that the issues you are talking about are annoying but I see them as a documentation problem. Commons:Upload Wizard feedback forum seems to be geared towards new users asking simple questions, not ideas about major improvements. Those should probably go into bugzilla with other improvement suggestions: bugzilla:47561, bugzilla:49443, bugzilla:66877, bugzilla:67327 or other 219 bugs and improvement requests listed there. --Jarekt (talk) 14:37, 7 October 2014 (UTC)
    If the page is titled "feedback", I suppose it should be a feedback page and not a counselling page. The first sentence on the page is: This page is a place for you to tell the Wikimedia developers what issues you encounter when using the Upload Wizard interface. However, the feedback is not really functional, i.e. Upload Wizard is a zombie now because it has no operator which is able to fix even such simple problems. --ŠJů (talk) 15:59, 7 October 2014 (UTC)
    The basic upload form is very much easy (if the user want to upload the file only and ignore all rules). However, the basic upload form enables also to enter a complete, correct and logically structured and precise description. Upload Wizard helps and enforces to select a valid license (maybe, even too obtrusively) but in other aspects, it supports incomplete, chaotic and fragmented description and doesn't enable and doesn't lead to enter a complete and ordered information. --ŠJů (talk) 16:10, 7 October 2014 (UTC)
  • Symbol oppose vote.svg Oppose, but Symbol support vote.svg Support an "Upload Wizard Wishlist for improvement". Pictogram voting comment.svg Comment For example, a licence for my own photographs of antic artist's work, obviously fallen in public domain, is still missing ! --Salix (talk) 17:00, 7 October 2014 (UTC)

An Upload Wizard Wishlist for improvement, does that exist somewhere? It should. We need a collection of user ideas, experiences, inspirations for a better Upload Wizard. Better categorization help wizard. Better file descriptions. Triggers for personality rights warnings. A dialog for geolocation/coordinates metadata. Integration with commons-wikibase. Video uploads triggering subtitle gadgets. Upload files from flickr, panoramio, geograph, youtube, with licence check. etc. pp. --Atlasowa (talk) 13:12, 7 October 2014 (UTC)

Not that I'm aware of, so we sould probably just go ahead and create one. I'd add "doesn't support derivative works of files already at Commons" to that. There are also severe performance issues:
"[…] The Upload Wizard is pretty much in a perpetual state of brokenness. It isn't broken for everyone all the time, but I don't recall a time since it was introduced that we went more than a few days without people reporting enigmatic problems with indefinitely spinning wheels and unhelpful error messages, and nobody responsible for its introduction seems to want to take responsibility for responding to feedback or making sure it works properly. […]"
LXin multiple replies at Commons:Upload Wizard feedback
I think that pretty much nails it. Don't get me wrong: Developing the UploadWizard was a much needed step forward and I very much appreciate it. But it appears that, at some point, whoever was working on it left for a coffee break and never came back. --El Grafo (talk) 14:11, 7 October 2014 (UTC)
Symbol support vote.svg Support I think it is a good idea to start a Wishlist for improvement page (here, at bugzilla , all future phabricator system) which keeps track of all reported issues, their bug IDs, etc. --Jarekt (talk) 14:37, 7 October 2014 (UTC)
It's worth noting that the Upload Wizard is very much on the Multimedia team's radar, particularly with the move towards Structured Data.
The very first thing that they're doing, even in Berlin this week as we speak, is working on the design of an abstraction layer API for all the file metadata UW should be able to write. They then plan to re-engineer the whole of the back-end of UW to go through this new abstracted API layer, which in turn will initially write wikitext, but in the future will be adapted to write wikidata.
So a list of the things that UW doesn't get right at the moment could be very valuable.
Associating different dates with the different contributions (and different works, potentially) that go to make up the final file certainly seems to be on the radar. But it could be worth keeping an eye on the draft API as it continues to develop, to make sure the modelling of the important metadata cases really is sufficiently flexible. Jheald (talk) 15:03, 7 October 2014 (UTC)
Pictogram voting comment.svg Comment While the Multimedia team has stated that UploadWizard is one of our priorities right now, in reality we've mostly been in "handle critical bugs" mode, which sadly means that poorly-defined and hard/impossible-to-reproduce bugs fall by the wayside. We need a lengthy, sustained time to focus on fixing the wizard, and we are unlikely to get it while there continues to be bignasty political issues surrounding Media Viewer and other projects, which bring our attention to them pretty strongly. I'll see if I can't bring myself to work on some improvements in my spare time, but I've been super drained lately, and I'm making no promises. --MarkTraceur (talk) 16:46, 7 October 2014 (UTC)
I am really astonished that someone has not just deleted Media Viewer as a really bad idea instead of letting everyone continue to complain about it. Delphi234 (talk) 17:17, 7 October 2014 (UTC)
I agree with LX that the Upload Wizard is pretty much in a perpetual state of brokenness. Not your fault individually, but saying that work has to down on the MV is a poor excuse from the WMF for not fixing the UW. Regards, Yann (talk) 18:00, 7 October 2014 (UTC)
Thanks for you comment, Mark. Is there anything that we (the community) can do to facilitate this? Would the Wishlist proposed above be of any use? Btw, naive suggestion: Since the UW seems to be a core part of the initial stages of the Structured Data initiative, wouldn't it be wise to postpone the structured data part a bit and have some of the people working on it focus on fixing the existing bugs in the UW first? --El Grafo (talk) 08:25, 8 October 2014 (UTC)
@El Grafo: I see why you might think that - actually the idea at first was quite the opposite. Given there are so many difficult problems to solve relating to storing metadata in templates, we decided that any major overhaul of the interface would wait until we had a high-level API set up for metadata storage. Now, that's becoming a reality soon(ish), but we can still work on fixing other parts of the wizard - chunked uploading and Firefogg support come immediately to mind. --MarkTraceur (talk) 14:50, 8 October 2014 (UTC)
  • Symbol oppose vote.svg Oppose ŠJů's suggested changes. The upload wizard interface is already quite complicated, adding a bunch of additional UI for edge cases will make it less usable, not more. Also here are my responses to the individual complaints: Kaldari (talk) 17:38, 7 October 2014 (UTC)
    • the "location" box doesn´t distinguish object location and camera location and presents the imported or entered object location by a template intended for camera location.
      That is correct and the intended behavior. 100% of imported locations are camera location. In the rare cases where someone enters a location manually, it usually just indicates the general location of both. If someone wants to use an object location template, they are free to add that in the other information field. Good UIs are designed for common use cases, not edge cases. Kaldari (talk) 17:38, 7 October 2014 (UTC)
      "100% of imported locations are camera location" – that's really a big untruth, mistake and ignorance. UploadWizard is used by WikiLovesMonuments and many other templates and projects which exported object location parameters massively (in tens of thousands cases) to the file pages using UploadWizard location parameters. If such usage is considered as unexpected and undesirable, UploadWizard developers needed to notice and fix this discrepancy long ago. However, they close their eyes or make useless excuses instead. --ŠJů (talk) 17:28, 12 October 2014 (UTC)
      @ŠJů: Could you please describe this problem more specifically? I've helped organize several WikiLovesMonuments events and never had any problems with the output from UploadWizard. Could you provide an example of the problem you are referring to? Kaldari (talk) 01:55, 14 October 2014 (UTC)
      @Kaldari: You personally believe that "100% of imported locations are camera location." However, monument lists contain 947,257 monuments with coordinates. Of course, the coordinates imported from object lists are object locations and cannot be camera locations. However, all object-coordinates parameters transferred from the lists to the images through UploadWizard lat and lon parameters are incorrectly presented as camera location. Commons is contaminated with tens of thousands inaccurate and confusing false camera locations. Such amount devalues the images which are localized properly with a real camera location including heading. The only defence against it is to stop transfer of the parameters, However, also in the Upload Wizard form, the title of the coordinates field is insufficient and unclear, doesn't declare clearly that it should be camera location only, doesn't support the heading as integral and standard part of camera location. The Wizard should help to fill the description properly - but instead that, it thwarts a correct description. --ŠJů (talk) 02:54, 14 October 2014 (UTC)
    • the "location" box doesn't allow to enter the heading (of camera location)
      Entering such a heading is not necessary or desired (see previous response). Kaldari (talk) 17:38, 7 October 2014 (UTC)
      Having heading information with you geo location is always desirable, since this is how we know which way is camera pointing. Camera GPS units support it (I have one for Nikon camera), {{location}} template supports it and the tools to display it on the maps support it. --Jarekt (talk) 18:14, 7 October 2014 (UTC)
      Is "not necessary or desired"? An unfounded, unskilled and irresponsible alibi only. No need to defend defects of the tool! --ŠJů (talk) 17:28, 12 October 2014 (UTC)
      I thought you were talking about field headings, not a template parameter. Regardless, that hardly seems like a reason to disable UploadWizard. None of the other upload interfaces support that field either. Kaldari (talk) 01:55, 14 October 2014 (UTC)
      We are talking about camera location always. Camera heading is a standard parameter of camera location - camera coordinates without camera heading is an incomplete entry. I supposed, you had seen {{location}} template ever? --ŠJů (talk) 02:54, 14 October 2014 (UTC)
    • the "date" field don't allow to distinguish what does the entered date mean (date of taken, date of last edit/modification of the image, date of the first publication etc.). The date copied automatically from EXIF is not presented in {{According to EXIF data}} template to allow to take account of possible incorrect setting of the camera.
      The date field already specifies what date it is for. If someone wants to add additional dates, they are free to do so in the description or other information fields. Having the date parameter polluted with several types of dates is a bad idea, IMO, and will make metadata extraction difficult. If you would like it to use the {{According to EXIF data}} template, please file a bug for that as it should be trivial to add (and certainly not a reason to turn off the Upload Wizard). Kaldari (talk) 17:38, 7 October 2014 (UTC)
      The date field already NOT specifies what date it is for. Especially when Upload Wizard imports different dates (EXIF date when photo was taken or the upload date) without distinguish them properly! --ŠJů (talk) 17:28, 12 October 2014 (UTC)
      That's a good point that imported EXIF dates don't necessarily match the purpose of the date field. I would suggest filing a bug for that as well. Kaldari (talk) 01:55, 14 October 2014 (UTC)
    • the link "Add location and more information…" and the textbox "Other information" are misleading and cause that some users write the detailed description into this field (i.e. outside the {{Information}} template) instead into the description field. The "description" textbox is disproportionately small which made this confusion bigger.
      How are those fields misleading? They describe their intended purpose accurately. The other information field even offers examples. What would you suggest to call them instead? Kaldari (talk) 17:38, 7 October 2014 (UTC)
      I agee with you that a few wishlist items are not the issue here. As noted above, I've spent some time tending to messages at Commons:Upload Wizard feedback, since the developers don't, and I feel those who take their time to provide feedback deserve a response, even if I can't really do anything. I've been watching it since Commons:Usability ideas and issues/Commons:Usability issues and ideas was inexplicably co-opted for this much more narrow focus (and then very quickly abandoned). I also tend to the help desk and upload help desk. As also noted, I'm not particularly fond of the Upload Wizard. My main concerns, though, are:
      • Very frequently reported freezing uploads with a lack of progress monitoring, timeout handling or recovery attempts. Just spinning wheels with no way to move backwards or forwards.
      • Speaking of moving backwards or forwards: The Upload Wizard is a wizard in name only. Show me one reputable UI guideline that doesn't mention a back button when discussing the wizard paradigm.
      • Absolutely ridiculously terrible error handing. Never, ever, ever show a user something like "<api-error-unknownerror>". Never ever assault users with cartoonishly nerdy gobbledygook about "stashes," "tokens" and "internal" errors.
      • Too little control over the way it works in the hands of those who understand and care about the consequences of what might look like minor details to outsiders. With the Commons:Upload process, Commons administrators had a lot of control over what options were presented, how they were described, and what the consequences of choosing one over the other would be. Most of the things ŠJů mentions shouldn't be things we should have to go to developers to tweak. We shouldn't have to wait several months to have 'free screenshot' added to licenseTagFilters.
      • Lack of (proper) support for key use cases like uploading files from Flickr/Panoramio etc. and derivatives of other files on Commons.
      LX (talk, contribs) 00:15, 8 October 2014 (UTC)
    • "The upload wizard interface is already quite complicated, adding a bunch of additional UI for edge cases will make it less usable, not more." I agree that it's not a good idea to bombard the average Wikipedia user who only wants to upload a picture of a cat s/he's taken with stuff s/he'll never use. But on the other hand, look at what happend with mobile uploads: The whole thing was dumbed down so much, it wasn't useable for anything but self-taken kitten-pics. People used it for other stuff anyway and the whole thing had to be shut down because we couldn't handle the mess it was creating (and we're still cleaning up). The UW is capable of doing more stuff beyond the kittens, but there are still many common cases that are not supported – and I'm not talking about power-user stuff here. Take the (maybe slightly more experienced but still) average Wikipedia user who wants to upload a collage of files from Commons for the infobox of a city article. There's no support for derivative files like that in the Wizard, and since derivativeFX isn't working anymore, there isn't any external help either. So more often than not, people just upload it as "my own work" and then get upset when it gets deleted because the authors of the original files were not credited. If adding stuff like this or the other feature requests from above makes the UI too cluttered, one could always put it into an "advanced" section that's only shown on request. --El Grafo (talk) 08:06, 8 October 2014 (UTC)
  • Pictogram voting question.svg Question Where can I provide the attribution/credits info in Upload Wizard? Why people think my useless username is a valid pseudonym of me? Jee 07:20, 8 October 2014 (UTC)
    This is a good candidate for a feature request - adding an "attribution for own works" field to the UploadWizard preferences tab. Bugzilla is still the place :) --MarkTraceur (talk) 17:10, 8 October 2014 (UTC)
  • Symbol support vote.svg Support - The UploadWizard is a good idea, but severely hampered by too much presumption of cases, and such horrible ideas as using time of upload as the default date of an image. It also has some severe performance issues - I have often tried to use it as a batch uploader, only for it to fail after the third image or so - and seems to have been abandoned by its developers. Let's step back, take a couple weeks fixing it, then put it back. Adam Cuerden (talk) 14:55, 8 October 2014 (UTC)
  • Pictogram voting comment.svg Comment The Multimedia team decided today to work more heavily on UW in the next month or so - we'll be starting with fixes to Firefogg support this week and continuing to work on stash and chunked uploading backends, as well as handling more errors, continuing our refactoring, and hopefully making some UI improvements. Keep the suggestions coming :) --MarkTraceur (talk) 17:10, 8 October 2014 (UTC)
  • Pictogram voting comment.svg Comment A couple of suggestions:
    • For the filename and description textboxes, provide the usual toolbar that allows special characters (e.g., diacriticals) to be entered.
    • Explain more clearly what sort of information should be put into the "other information" field. (I've not used it because I don't know what it's for.)
    • Ensure that file extensions like ".jpg" appear in lowercase rather than uppercase.
SMUconlaw (talk) 18:29, 8 October 2014 (UTC)
While uppercase file extensions are annoying, it is really unimportant, and I would not want a script to change them. My recollection is that DOS only allowed uppercase file names, and this is a left over from that. Delphi234 (talk) 04:13, 10 October 2014 (UTC)
This would be for new uploads, not existing ones. Also, I assume you're not suggesting that it's necessary to cater for backwards compatibility for DOS? That was many, many generations of operating systems ago. — SMUconlaw (talk) 10:41, 11 October 2014 (UTC)
@MarkTraceur: Could you please throw out the default date that gets used? Unless you've literally just taken the picture, the UploadWizard always gives the wrong date. Adam Cuerden (talk) 03:22, 9 October 2014 (UTC)
That is true, but there really is nothing reliable that could be done - cameras are often not set to the correct date or time. Best thing is to just manually change the date to the correct date, or just leave it as the upload date - which actually is reliable, as it is put there by the server. Delphi234 (talk) 04:13, 10 October 2014 (UTC)
  • Symbol oppose vote.svg Strongest possible oppose. I'm flabbergasted that this discussion is even happening. You're seriously proposing that we shut down the upload wizard (and thus, effectively, uploading by human beings). Because sometimes files end up with the wrong date? That's insanity. If the rationale was that it enabled mass copyright violations, I could just about understand, but I'd still vehemently oppose on the grounds that the project needs uploading to be easy in order to survive, and problematic uploads are an inevitable side effect of that. The solution is to improve it as best we can, but even if it can't be improved, we don't just throw the baby out because the bathwater isn't perfect! HJ Mitchell | Penny for your thoughts? 22:45, 8 October 2014 (UTC)
I'm flabbergasted some one here, an admin, nonetheless, thinks that the upload wizard is the only way a human can upload files to Commons. I think I used UW once or twice, only to be annoyed at the puerile clippy-style “user experience”: Interface that treats you like a dimwit and bugs that need you to be a brainiac to overcome. In contrast, all other ways to contribute content I ever used (Vicuña, DerivativeFX, Special:Upload, Commons:Upload, Flickr2Commons, and more) are well documented and work as expected. Am I not human, HJ Mitchell, or are you wrong? -- Tuválkin 17:01, 9 October 2014 (UTC)
Well, in my opinion, suggesting to turn off the UW would indeed be something very strange to support, as all our uploading help pages for new users are currently based on uploading via the UploadWizard. It's like suggesting to make Cologne Blue the default skin for all users.    FDMS  4    19:34, 9 October 2014 (UTC)
I'm far from the most prolific contributor, but I recently uploaded around 200 photos, using the wizard to upload small batches of images with similar or identical names/decriptions/etc. If I'd had to do that one-by-one, I don't think I would have bothered, and I'd wager that most people are not that masochistic. HJ Mitchell | Penny for your thoughts? 22:16, 9 October 2014 (UTC)
  • Symbol oppose vote.svg Oppose All of these "errors" occur on files uploaded the old fashioned way. Enhancements to the Upload Wizard are needed, but that's no reason to make it harder to upload images. - PKM (talk) 23:12, 8 October 2014 (UTC)
    The main problem are not the errors themselves (they could be fixed very simply) but the fact that the feedback is is absolutely non-functioning, nobody is able or willing to correct even such clear and simple errors. --ŠJů (talk) 17:28, 12 October 2014 (UTC)
  • Symbol oppose vote.svg Oppose I see no reason to pull out the foundation of something because you don't like the rather minor errors that it produces. There are better things to spend our time arguing about, as this is not one of them. Kevin Rutherford (talk) 18:53, 9 October 2014 (UTC)
  • Symbol oppose vote.svg Oppose Its more easy upload 30 images in same time --Wilfredo R. Rodríguez H. (talk) 17:25, 16 October 2014 (UTC)

October 08[edit]

{{Information}} display error[edit]

How on EARTH did this happen? - note that the second line of the "author" parameter has somehow jumped to the start of the template - how does that even happen? Adam Cuerden (talk) 14:53, 8 October 2014 (UTC)

Someone probably needs to do a bit of a review of the Creator template and check if there's a surplus /div. I have seen similar things happen due to that sort of slip up. -- (talk) 15:01, 8 October 2014 (UTC)
There is probably wikitext that the parser needs to interpret in that template. There might indeed be something unbalanced as Fae notes. But, you probably shouldn't be using a * list to do this. Wiki lists have to make a lot of assumptions about stuff that follows it, and where ever assumptions get made, they get broken (by highly complex or perhaps broken templates for instance). This is a rather common problem with wiki lists. —TheDJ (talkcontribs) 21:32, 8 October 2014 (UTC)
It is one of unsolved issues we have with all infobox templates for as far as I was playing with templates, see for example Template:Artwork/testcases where whole infobox gets messed up with innocent looking simple wikitext. The thing that messes things out is using bullets lists and creator templates. May be someone fixes it at some point but in the mean time I would advice to just change wikitext until it works. --Jarekt (talk) 14:22, 9 October 2014 (UTC)
@TheDJ: The problem is that I can't very well avoid it; it's cropping up in a bunch of quite old uploads as well. And very strangely - why does File:First_colored_senator_and_reps.jpg work, but File:First_colored_senator_and_reps.png is buggy?
And this is, technically, an attribution issue: it changes something that was properly attributing me as someone who should be credited on reuse into something that makes my work an afterthought, and there is nothing I can do to either protect against it (I think I have over three-hundred restorations featured on en-wiki; checking all of them is impractical), or to know if it's happened - I can't check every file I've uploaded every week to see if someone's added a creator template. Adam Cuerden (talk) 09:57, 14 October 2014 (UTC)

Massive copyright violation by Flick User Ashur Rikah[edit]

Hi! I just realized that the above Flickr user made multiple copyright violations. A lot of material from Wikimedia Commons especially from the Featured Pictures isused. The user pretends to be the creator of the photographs. The following photos of mine are affected:

I would strongly encourage other users on Commons to take a look on his foto stream if own photos are affected. For me it is the worst possible behaviour to pretend the work of others as own work. I've already made an abuse notice on [1]. If you like, you can do the same, probably the account of the user will be deleted. --Tuxyso (talk) 20:57, 8 October 2014 (UTC)

  • Tuxyso Have you contacted Flickr, as this might be the best way to handle the situation, as it's obvious flickrwashing. Kevin Rutherford (talk) 01:37, 17 October 2014 (UTC)
    • I did, Kevin as written in the lines above. I made an abuse notice but up to now nothing has happened. Any suggestions? --Tuxyso (talk) 06:44, 17 October 2014 (UTC)
      • Ah, I didn't see that link. I guess if worse comes to worse, you could always ask the opinion of the legal team to see if they want to get involved, and then go from there. I did once come across someone who was claiming our images as his own and issued rather weak takedown notices. I tried complaining to his ISP, but they got back to me after a week because I was not the author of the images in question, even though he had many of our images on his site advertising his photography wares. Unfortunately, this sort of thing keeps on happening, so I would definitely suggest going to Legal if nothing comes out of this. Kevin Rutherford (talk) 01:01, 18 October 2014 (UTC)
      • Also, I suspect that all of their images are taken from other sites, so that might not be a bad idea to add if anyone files a complaint. Kevin Rutherford (talk) 01:04, 18 October 2014 (UTC)

promoting Commons:Upload tools at Special:UploadWizard[edit]

What do you think about adding a link to Commons:Upload tools next to the back to the old form link at Special:UploadWizard? I noticed (e.g. at Commons:Upload Wizard feedback) that even some more experienced users don't know that we have several alternative options for uploading that may suit their needs better than UW or the old forms. --El Grafo (talk) 08:34, 13 October 2014 (UTC)

Okay, but I do not trust that those wizards and tools actually/still work. Special:Upload never failed to do what I want. –Be..anyone (talk) 11:27, 13 October 2014 (UTC)
Well, at least Vicuña works very well for me. Much more convenient than Special:Upload (especially when you want to upload several files at once) and much more stable than UploadWizard. I haven't used Commonist for some years, but it appears to still have a rather large userbase. The KIPI-Plugin for Digikam works quite well for the usual tasks, but it's not yet up to Vicuña when it comes to more advanced features. Can't say anything about LrMediaWiki since I don't have Lightroom. --El Grafo (talk) 15:40, 13 October 2014 (UTC)
Adding a link would not do any harm, it could only help those who are not satisfied with the Upload Wizard. Yann (talk) 10:56, 14 October 2014 (UTC)

October 14[edit]

Somebody better protect the rest of the images used in w:Jennifer Lawrence[edit]

Twice now someone(s) have made lovely but widely disparaged stolen images of w:Jennifer Lawrence visible from that article by altering other images on Commons. Regrettably it seems necessary to protect all of the images used in that article, probably for three months or so, because the others (e.g. [2]) will surely get the same treatment if you don't. Wnt (talk) 01:58, 14 October 2014 (UTC)

✓ Done All 4 images full-protected for 6 months. INeverCry 03:10, 14 October 2014 (UTC)

Wikipedia Monument, 3D printing AMF format and Bugzilla help request[edit]

So w:Wikipedia Monument is being built in Poland. While we still don't know it it is freely licensed, it we can make it so, Commons:File_types states that the free format for 3D models is *.AMF and that it is not currently supported. And unlike most other formats, it doesn't appear to have a Bugzilla request tied to it. So if anyone would be so kind and to file a Bugzilla request to allow MediaWiki/Commons to host AMF files, it would be a step towards one day being able to print such Wikipedia Monuments all over the world :) --Piotr Konieczny aka Prokonsul Piotrus Talk 06:11, 14 October 2014 (UTC)

Piotrus: Feel free to create a Bugzilla account and create the request. See --AKlapper (WMF) (talk) 11:40, 14 October 2014 (UTC)
Before that, a COM:RFC should probably be held …    FDMS  4    14:20, 14 October 2014 (UTC)
Note, there's two separate things that could fall under such a request, and should not be conflated. First there's the feature request for the ability for MediaWiki to show a preview on the description page for such a file. Second there is the ability to upload such files on commons. Both of these things are independent of each other. Making MW be able to preview such files requires development effort, and thus either someone needs to be convinced to do it, or somebody needs to volunteer to do it (And you should probably file a bug about that). However, All that's needed to allow uploads of such a file is an RFC on commons showing there is community consensus to allow it. If preview functionality isn't created, uploads would just have a generic icon (e.g. like w:File:Taiwan_map.jpg9-smaller-corrected-empty.psd. I have no idea how that file exists, but it would be like that one). Historically commons hasn't liked the idea of allowing uploads for formats that can't be previewed, but from a technical perspective, the two are totally separate concerns. Thus if you don't care about preview ability, all you need to do is get the rest of commons to agree that allowing such files without preview is a good idea. Bawolff (talk) 01:20, 15 October 2014 (UTC)

A3 scanner in shop outputs PDF. What format should I upload ?[edit]

Hello This is my first use of Wikimedia so I am a novice.

Based on information available from public conferences, I drew a sketch of the comet nucleus of 67P/Churyumov–Gerasimenko. This is for the French Wikipedia that, unlike the English one, does not allow the use of ESA photos.

I drew on A3, too big for my home A4 scanner. I used white paper with à 9b pencil and charcoal which seem adapted to a setting in space with a black background.

So I scanned in a shop and the output is a greyscale PDF from a 200 DPI scan. This scanner gives no other filetypes. The filesize is 1,39 Mo If I open this with Sumatra, do the Windows copy ctrl+A, ctrl+V then paste into Paintbrush, I can get a JPEG of 215Ko or a far-to-big 8Mo in PNG.

As this sketch is intended for a small side panel, is the JPEG option the best ? However, I'm hoping that others may improve the drawing and update it to take account of new scientific information. Should this influence my upload choice ?

Will the drawing be automatically compressed to take account of its much smaller size when appearing on a Wikipedia page ?

Thankyou for any suggestions ! — Preceding unsigned comment added by Paul Wi11iams (talk • contribs) 16:51, 14 October 2014‎ (UTC)

Hi Paul, and thanks for wanting to contribute!
You can technically upload the PDF as is. Based on your description, it's probably not suitable for permanent storage of this type of file, but it will allow others to examine the file and determine the best way to convert it. One fairly easy to way to convert PDF files is to open it in GIMP. Just open it like any other file ("File/Open"). You'll get an import dialog where you can enter the resolution. If the scan was done at 200 DPI, that's probably a good value to use. Then you can export it to JPEG or PNG. PNG is better if you want others to improve on your work, since JPEG compression is destructive, and more visibly so after multiple consecutive open-and-save cycles. The file you upload should be as large and of as high a quality as possible. 8 MB is actually not unreasonable. Low-resolution versions will be generated server-side, so people reading Wikipedia don't have to download the full version unless they choose to. Cheers, LX (talk, contribs) 21:12, 14 October 2014 (UTC)
Thank you LX.
Before seeing your advice, I temporally uploaded the JPEG
non-figurative representation of 67P comet nucleus
. With some artistic help, I'm going to improve the drawing, and then will do a new upload following your advice. Hoping that in this reply, my syntax is right. There's a lot to learn!
Paul Wi11iams (talk) 09:00, 15 October 2014 (UTC)

Castes division inside Commons[edit]

This is not the first time that I need to ask for a sysop solve a problem that another sysop created, and is always the same, no answers or threads, as this (and you can see both happening), why sysops are liable to errors, while we down here, no? Why they can use the tools as they want, and we cannot even request to fix a misuse of the adm tools??

Sysops have to protect their own? They are not suppose to protect the whole community as one? The problem stills there, is a crystal clear problem, and no one tried to solve, in the other hand a lot of "normal" volunteers as block in the same period. Rodrigo Tetsuo Argenton (talk) 19:51, 14 October 2014 (UTC)

This is being addressed here, it is just that nobody seems to be buying your version of this incident. --Dschwen (talk) 22:00, 14 October 2014 (UTC)
Someone opened the history? That's the point, if this was not a sysop mistake you will run to solve, if this is a sysop issue, no one cares. Rodrigo Tetsuo Argenton (talk) 22:47, 14 October 2014 (UTC)
IF you had given the The right page for people to look at they would find the edit war staring you vs the rest of the world. Béria L. Rodríguez msg 22:56, 14 October 2014 (UTC)
You blocked this page: Página Principal, so or mistake, you choose the wrong page to block, not me, and that's the only thing that I'm saying since the begging, and that's the point, sysops make mistakes and others do not fix, by any how. Rodrigo Tetsuo Argenton (talk) 23:02, 14 October 2014 (UTC)
No ones "blocks" a page, Rodrigo, if you want to be beleived as the "only one doing manteinance in Commons" (as you claimed in the AN) at least use the proper names. And I'm still waiting for a apology for your offenses towards me. Béria L. Rodríguez msg 00:39, 15 October 2014 (UTC)
Locked/blocked/protected. Close enough. On a multilingual project it is often necessary to figure out what someone was trying to say. But spelling "believed" wrong, and "maintenance", now that is inexcusable (just kidding). Delphi234 (talk) 21:06, 15 October 2014 (UTC)

Restrict overwriting of files?[edit]

I'm not making a formal proposal just yet, but I'm just wondering how feasible it would be to restrict overwriting of files so that it was part of a use right. Perhaps it could be incorporated into the filemover right or perhaps we could create a separate right? There should perhaps be an exemption for uploaders overwriting their own uploads. There has been vandalism recently involving the overwriting of widely used images with obscene or explicit images, and this is hardly the first time. Indeed, it is a tactic that has been commonly used by long-term vandals. Before I make a formal proposal, though, I'd like a little feedback—are there obvious issues with the idea? Are there easier solutions (an abuse filter, perhaps?)? Thanks, HJ Mitchell | Penny for your thoughts? 23:22, 14 October 2014 (UTC)

Autoconfirmed users should be enough, even so, we need to see how many overwriting contribution of not autoconfirmed volunteers is bad to take a action, we could lost some contributions if we restrict that. Rodrigo Tetsuo Argenton (talk) 23:31, 14 October 2014 (UTC)
What possible reason could somebody who has made fewer than 10 edits or had an account for fewer than four days have for overwriting a file uploaded by somebody else? The only reason I can think of for files to be overwritten at all is for retouching, and in my experience only experienced editors would normally retouch an image uploaded by somebody else. Meanwhile, for any troll with a little patience, the autoconfirmed restriction is nothing more than minor inconvenience, and far too easy to game. HJ Mitchell | Penny for your thoughts? 00:04, 15 October 2014 (UTC)
This would seem an overreaction to what is rarely a serious problem. The recent instance of vandalism was quickly resolved thanks to an experienced Commons administrator, and would not be an issue now apart from some soapboxing going on in the usual venue.
Harry, if you want to discuss this properly, I suggest raising it at a time when it is not being used for lobbying and petty politics. -- (talk) 23:56, 14 October 2014 (UTC)
It's comparatively rare, but when it happens, it's a serious issue, and it's the sort of thing that brings Commons into disrepute. Of course I'm interested in discussing properly, which is why I raised it here rather than acknowledging the silliness on Jimbo Wales' talk enwiki talk page. HJ Mitchell | Penny for your thoughts? 00:04, 15 October 2014 (UTC)
I respect the fact that there probably is something on this to discuss and review current processes, so I agree it ought to be the subject of a discussion and worth a proposal to the community Smile fasdfdsfoiueire.svg. At the same time, it would be better done during a period of calm and when we can put real numbers and a couple of solid case studies up as a foundation for a proposal. If the reality is that potentially damaging/defamatory/unlawful images get uploaded this way just a couple of times a year, and when they do the statistics tell us that admins respond within minutes of receiving a complaint, then that process might be hard to beat compared to permanently battening down the hatches against all newcomers (even if only in a relatively mild way). -- (talk) 07:41, 15 October 2014 (UTC)
I frequently come across files that have not been overwritten by vandals, but by good-faith users thinking "hey, my image of this subject looks nicer, let's replace it". There should be either a very clear warning or the ability to modify someone else's upload should be indeed restricted to patrollers/rollbackers/filemovers.    FDMS  4    08:10, 15 October 2014 (UTC)
I concur with this. Overwriting others' files should be limited to trusted users, not just anybody. This isn't just because of Miss Lawrence, but in general as FDMS says, we get a lot of people who upload over old files with things which are completely different. -mattbuck (Talk) 09:29, 15 October 2014 (UTC)

This is already the case (That is, it is already the case that overwrite is restricted to autoconfirmed users). There are three relavent user rights: reupload, reupload-own, and reupload-shared. reupload is normal overwriting. It is restricted to auto-confirmed users on commons (And people in the non-automatic Confirmed group). reupload-own is for overwriting your own files. It is available to all logged in users. Last of all, reupload-shared doesn't apply on commons, but on other projects its limited to admins, and controls who can upload a file locally with the same name as one on commons. (These rights all more or less the same for all Wikimedia projects. Exceptions being wikis that have disabled local uploads, private wikis, and read only wikis (fishbowl) have different user rights settings for these. enwikibooks, ruwiki, ckbwiki, ukwikivoyage fawiki and meta also has a specific uploader group. svwikisource is also slight different. Bawolff (talk) 01:39, 15 October 2014 (UTC)

p.s. Actually, I just discovered that normal uploading is restricted to autoconfirmed users. This seems really odd to me given the nature of commons. It might make sense on wikipedia, but uploading is pretty much the main activity on commons - people create an account here for the express purpose of uploading files. Bawolff (talk) 01:39, 15 October 2014 (UTC)
I find the newcomer experience confusing. I support editathons and I'm always taken back at the experience for newcomers. It is easy to forget that long term contributors normally have a host of special preferences and tools changing the look and feel of the system. I have advised new users on image uploading, so I feel a bit of a wally not knowing that they have to make a standard 10 edits before uploading anything. -- (talk) 07:48, 15 October 2014 (UTC)
@Bawolff: I'm pretty sure autoconfirmed on Commons is not required to upload files here. We have plenty of newbies where the first (and often only) contribution is a file upload (example). Maybe it's autoconfirmed on any Wikimedia project? --El Grafo (talk) 09:06, 15 October 2014 (UTC)
Autoconfirmed is not required to upload; see Special:ListGroupRights#user. LX (talk, contribs) 09:34, 15 October 2014 (UTC)
I fail at reading. Sorry about that. Bawolff (talk) 10:49, 15 October 2014 (UTC)

If we go this road, we should perhaps whitelist image updates made through certain bots -- eg CropBot, RotateBot, etc. These tools are very much part of the workflow required for raw images being pulled in from the Commons:British Library/Mechanical Curator collection on Flickr. Jheald (talk) 16:38, 15 October 2014 (UTC)

I would not like to see any change. While it is relatively rare to have a legitimate reason to overwrite a photograph (someone finds a higher resolution version), the images that I work with mostly are temporal charts that need to be updated every time new data is available (there are two kinds, ones with a date range in the title that do not get updated, and ones without a date range, which are used to display current data). There are thousands of these that need to be updated, and I would not like to see any restriction on anyone being able to update them with new data. Some of them new data is available every week, some every month, some every year. New ebola data is available about every two days now. Delphi234 (talk) 20:43, 15 October 2014 (UTC)
I pretty often have a legitimate reason to overwrite a photograph. Typically, I initially upload the photo exactly as it came from my camera. Then if I need to do a slight rotation, crop, color correction, etc. I upload that over the original image. This makes it possible for someone to get the original if they want to do their own derivative original (e.g. want to do a different color correction, etc.) but provides the most useful version for ordinary users. A few years back, I was uploading to two different file names, but this seems a better scheme. - Jmabel ! talk 00:33, 16 October 2014 (UTC)
I think everyone should have reupload-own, obviously. But someone else's image? I've seen a lot of problematic uses of that. For example: a user has a cropped image of a boy's face from a Roman mural on his userpage, gets blocked, then a few days after someone reuploads a bigger segment of the mural showing a crop of the entire boy, who is naked, and they go around implying the user is a pedophile in multiple public forums. Backed up by the fact that even the Wayback Machine version of the user page will then display that way! Because it uses the last current image. More commonly though, we end up with maps that are constantly being "updated" where "update" means (a) correcting errors and (b) advancing the date that the map represents. The result of that is that we never generate accurate maps for any given date, except by accident and as intermediate revisions. Most often when an image is altered it should get a new name - reusing the old one is really almost the same as an author-requested deletion (though yes, it's better not to need the magic wand). Wnt (talk) 02:00, 16 October 2014 (UTC)
To represent a map for a given date, that date needs to be included in the file name. And it can be revised as often as needed to correctly reflect that date. That is one of the examples that is used on the overwriting files page. See also Commons:Ownership of pages and files. As a collaborative project, we need to encourage replacing others images. I have created maybe a thousand new, but time sensitive images, and I certainly want them all to be updated with new data as it becomes available. And now I am working on translations, and I depend on native speakers to add new translations and correct errors in those images, but over-writing the image. Some of them I have done with only three languages, one I am working on now will have 137 languages, but we have about 267 languages now, and we need to be able to have all of those languages added, and in the same image, using <switch>, is by far the best way to do that. Most of the images I am working with are from the Category:Translation possible - SVG, and were (probably) all created by someone else. So yes, some one else's image. Delphi234 (talk) 03:20, 16 October 2014 (UTC)
We aren't suggesting it be impossible to reupload over others' files, just that it not be a right people are immediately given on Commons. Making it autoconfirmed only would solve most of the issues we encounter with vandalism or changing images completely. -mattbuck (Talk) 07:16, 16 October 2014 (UTC)
It is already autoconfirmed only. I think what is being proposed here is an even higher bar than autoconfirmed, such as autopatrolled. And I don't think I'm a fan of that – I definitely do want a lot of people to help out with things like Category:Images with borders and I don't want their help to result in thousands of redundant versions with and without border. I don't really see how restricting overwriting solves the problem of vandalism (like the kind discussed in the original proposal). It isn't really much harder for a vandal to upload the same file under a new name and put it into the same article. The only difference I see is that this would show up on watchlists in local projects, so perhaps the solution to these kinds of problems is to make file overwrites show up in watchlists on local projects when a user is watching the page the file is used in. Something similar is already done for Wikidata, so that can't be too hard. darkweasel94 08:08, 16 October 2014 (UTC)
I am proposing a higher bar than autoconfimed, but not an insurmountable one—I envisaged that any sensible editor with a good reason to want to overwrite files would be given the applicable right (and anybody who's already been granted any right by an admin would probably meet those criteria). My intention is not to prohibit overwriting, but to make it just a little bit more difficult so that it's only done by people who actually know what they're doing, and thus prevent vandalism and misguided-but-well-intentioned overwrites. HJ Mitchell | Penny for your thoughts? 19:50, 16 October 2014 (UTC)
@Darkweasel94:, regarding your question It isn't really much harder for a vandal to upload the same file under a new name and put it into the same article, well actually yes it is. You vandalise a wikipedia page with an image like that, it gets reverted swiftly because it shows up in their watchlists, the page gets protected, we get notified and the user is blocked. You upload a new version of a file, it won't show up on the wikipedia watchlist, and they can't do anything about it beyond remove the image completely. As for Commons, most likely no one here even notices it happens before the wikipedians grab their pitchforks and torches. -mattbuck (Talk) 20:47, 16 October 2014 (UTC)
@Mattbuck: What if we made image changes show up on other project watchlists. Wikidata did a bunch of stuff to optionally make wikidata edits show up on other project watchlists, we could probably do something similar with commons files. Bawolff (talk) 17:07, 17 October 2014 (UTC)

What about "Pending overwrites"? Experienced users could then review the updates for their uploads or reject them if they are vandalism or otherwise inappropriate. Of course there would have to be a special page for it like w:Special:PendingChanges.    FDMS  4    14:25, 16 October 2014 (UTC)

Ugggh. No. The whole problem with these files is that nobody pays any attention to them, so the change would remain "pending" forever. Wnt (talk) 14:33, 16 October 2014 (UTC)
I agree. When you upload a new version you do so for the sole purpose that it will immediately appear. If there is an error in it the version can easily be reverted by anyone. Delphi234 (talk) 16:30, 16 October 2014 (UTC)
  • I have sometimes come across photos which have been overwritten by other completely different photos, where the user who overwrote the photo neither provided an edit summary nor edited the file information page. In that case, we also have copyright problems: the source and licence of the new upload are unknown. --Stefan4 (talk) 14:34, 16 October 2014 (UTC)
    • Actually, this is no different than creating a derivative work. Even if what you upload is completely original, and all your work, and not that of the original uploader, you are constrained to use the original license, and can not change that. If you want to change the license, or if the work you are uploading is PD, for example, but the original was not, you have to change the title and upload it as a new file. Sometimes people note in the description who contributed to the various different uploads, I do not, and just let the upload history show who created each version. Delphi234 (talk) 16:22, 16 October 2014 (UTC)
    • But the upload widget that I use does not permit uploading a new version without providing an edit summary. This will appear in the upload history, but not in the file edit history, which only has an entry that a new version was uploaded on that date. Delphi234 (talk) 16:27, 16 October 2014 (UTC)
      • Special:Upload's "wpDestFile=somefilename&wpForReUpload=1" option doesn't require me to license the new file under the same licence as the old file. If I overwrite someone's photo of a building with a better photo of the same building, it can therefore not be assumed that the new photograph is licensed under the same licence as the original photograph. The source of the new photograph also needs to be documented. --Stefan4 (talk) 18:43, 16 October 2014 (UTC)
        • It has a warning to include license information, but no information that is supplied is ever used, and is just discarded. The warning needs to be removed or replaced with a notice that the same license will be used and if you are not content with that you need to upload it as a new file name. You could edit the license to change it, but that would not be appropriate. If you are replacing a photograph of a building with another photograph of the same building, it is better to give it a new file name. Replacing a photo is more for removing a watermark, removing a frame, rotating, or replacing with a better resolution of the exact same photograph, for example. Delphi234 (talk) 18:57, 16 October 2014 (UTC)
          • If something is provided in the edit box on that page, it shows up as the edit summary. If there is a source and licence there, then fine, the file can be kept (after it has been split). I agree that it is a bad idea to overwrite photographs with other photographs, but the problem is that people nevertheless are doing this once in a while. And when they fail to provide a source and licence for the new file, the new file will just have to be deleted. --Stefan4 (talk) 19:55, 16 October 2014 (UTC)

The line that says If you do not provide suitable license and source information, your upload will be deleted without further notice. Thank you for your understanding. can be removed, as it is meaningless. I think there used to be windows for license and description, but if filled out were not used, and have now been removed. Delphi234 (talk) 19:07, 16 October 2014 (UTC)

A source and licence need to be provided (but is typically trivial unless you are overwriting in an improper way). --Stefan4 (talk) 19:55, 16 October 2014 (UTC)
There is rarely any source involved - when you rotate an image, the image is the source. But I often update the source information if it is either missing or if I get the data for the image from a different source. I am doing a series of over a hundred population charts, and my data is from the UN DESA, while all of the original charts are from UN FAO. The data I am replacing was from 2005, and the new data is from 2012, so that information also is updated.
But I would like to see a firm policy that the license used can not be changed when a new version is uploaded. Delphi234 (talk) 20:18, 16 October 2014 (UTC)
Right, that's what I wrote: the source is typically trivial. As for the licensing, this would have to be stated on the upload form. For example, when you contribute text, you see MediaWiki:Wikimedia-copyrightwarning directly above the "save" button. If the text hadn't been there, your text presumably wouldn't have been licensed. --Stefan4 (talk) 20:32, 16 October 2014 (UTC)
So how about changing the notice to: Your upload will use the existing license. If you wish to change the license, you will need to upload as a new file. If source information has changed or needs updating, please do so. Thank you for your contribution. Delphi234 (talk) 20:44, 16 October 2014 (UTC)
It would be a good idea to add something along those lines, yes. That message should of course only be shown when overwriting a file, not when uploading files under a new file name. --Stefan4 (talk) 20:48, 16 October 2014 (UTC)
Correct. I suspect this is a mw:Mediawiki issue, though. Delphi234 (talk) 21:00, 16 October 2014 (UTC)
If you wish to change the license – why should anyone want to do that? Any less restrictive license would mean a copyvio, and most crops aren't copyrightable. I guess only a very small number of overwrites are complicated retouches, and this exact wording would rather encourage new users to overwrite with different images of the subject in my opinion. I would prefer something like Only use this feature for uploading slightly improved versions or map/diagram updates! Please upload other derivative works or different images under a different name. See Commons:Overwriting existing files for the official guideline.    FDMS  4    21:48, 16 October 2014 (UTC)
It is inappropriate if different versions of the same file are licensed under different licences as it is difficult for users to identify the licence of specific versions. Also, many files are licensed under a licence which requires you to "share alike", so changing the licence may often not be allowed under copyright law. --Stefan4 (talk) 22:27, 16 October 2014 (UTC)
So just delete the red line as meaningless, and somewhere state the fact that the license can not be changed. An exception, of course, is File:Test.svg, which clearly states that the licensing information is not likely to be correct. An example of wanting to change the license is, all of the files I create are PD, but if I come across one like File:Temporal evolution of the 2014 West African Ebola outbreak.svg, I can either update the file using current data, and using the existing license, or I can create a new file with a PD license. For other editors, all of their files might be say CC 4.0, but any of the PD files they update would be PD. In this case the file I created used nothing from the original file, and was not created the same way. Considering we already have a plethora of these, I really did not want to create yet another one. But now I want to extract the original file and rename it something like "2014 West Africa Ebola outbreak from 25 March 2014 to 2 July 2014", as it is highly interesting to see the early development of the outbreak, which is lost now that we are above 9000 cases. But I also have data from January to March, so will probably just create a new file called something like "2014 Ebola Outbreak from January through June". Delphi234 (talk) 23:04, 16 October 2014 (UTC)

User:Delphi234 -- unfortunately, your "no license change on uploading new version" policy does not anticipate all legitimate possibilities. For example, on File:Shield-Trinity-Scutum-Fidei-English.svg another user tried to convert a previous PD PNG image of mine to SVG, and uploaded the SVG file under Cc-by-sa-3.0, but unfortunately made a mess of the conversion. So I completely redid the vector conversion from scratch, and licensed my SVG upload as PD, and don't see any problem with that... AnonMoos (talk) 12:40, 18 October 2014 (UTC)

Except that now we have that user's work that has been licensed under CC-BY-SA-3.0 on a page that claims it is PD. Since the license goes with the page, not the image, uploading a work by a different author or different license over the old attaches false license claims to the old one.--Prosfilaes (talk) 19:01, 18 October 2014 (UTC)
Yes, their work, even though it might be useless, is still their work, and uses their license, so if you want to use that name for your work, and use a different license, you first have to rename that file. It is just impossible to keep track of if each person who creates a new version wants to use a different license - or if anyone wants to use a different license. Delphi234 (talk) 00:41, 19 October 2014 (UTC)
Since that particular file is an SVG, if you use <text> for the various text, it can be translated into other languages, and you can leave off the "-English" from the file name. Otherwise I would just revert your upload and use the file name File:Shield-Trinity-Scutum-Fidei-en.svg, which is a more standard file name for a file that is in a particular language (en), and place a "superseded by" template on the other file, that was not done well, linking to your new file. Delphi234 (talk) 02:06, 19 October 2014 (UTC)
Whatever -- "<text" tags cannot be used in the SVG source because RSVG text rendering has a long history of inconsistent, ever-changing, and sometimes-crappy rendering of such text in such contexts (consult the upload history of File:Simple inverse relationship chart.svg). Second, the original 25 October 2009 upload of File:Shield-Trinity-Scutum-Fidei-English.svg has no reason to exist as a separate file. If it was a separate uncorrected file, it would have to be deleted. Third, considering that I was the author of the original PostScript source code and original PNG image which the other user had attempted to converted to SVG, I did not feel the slightest inclination whatsoever to upload my correct functional SVG under a new name, nor did I feel bound by the earlier license, since I created my SVG completely from scratch, without consulting the earlier broken SVG file. Fourth, the original uploader has not objected to the license change -- he came back to the page after I uploaded the file to change his attribution name (see here) but did not object to or revert the license change. If there's a technical CC terms violation worth bothering about, then the only solution is to delete the original 25 October 2009 upload of the SVG, but that doesn't mean that I was wrong in changing the license after I uploaded my version... AnonMoos (talk) 10:24, 19 October 2014 (UTC)
There are definitely issues with <text>, but it is still a useful feature. There are over 5000 images that use it, and as a result can be translated into other languages, and over 200 images that have been translated into other languages using <text> and <switch>. I do agree that a cleaner approach would have been to just delete the inadequate svg file (reason: to allow uploading a better version using the same file name but a different license). Delphi234 (talk) 17:09, 19 October 2014 (UTC)
I use "<text" tags for basic functional captions whose exact appearance isn't critical (see File:Genji chapter symbols groupings of 5 elements.svg etc.). However, through long experience, when the exact size, spacing, and shape of text is an essential part of an SVG graphic's correct appearance, then text must be converted to paths, because that's the only way to be sure that things will work consistently from month-to-month (sometimes the only way to be sure that the appearance of the image is what you want it to be in the fist place). Anyway, the different language Shield of the Trinity graphics do not conform to a basic name + two letter language code filename schema, partly because they are not in fact identical except for having different-language text -- the shape of the triangular graph changes in different images due to the need to accommodate differently-proportioned captions in different languages. (Also, some of the images have the translation of the Latin phrase "Scutum Fidei" into the language of the image included in the filename.) I don't see much real advantage to be gained by attempting to impose an artificial uniformity at this late date... AnonMoos (talk) 17:48, 19 October 2014 (UTC)

Better watchlisting[edit]

I think that one of the big issues here is the watchlist, which was not designed for the scale of this project. It was mentioned above that an admin will revert such an action once it's reported, and that's great, but it requires that someone notices it to begin with. I would bet that most of the files on Commons are watched by their uploader (whose account is likely dead) and no one else. We need some way that we can watch files more widely. I have 82,000 pages on my Commons watchlist, which is enough that I can't edit the raw watchlist anymore, but even if most of those were files, it's not even 0.3% of the files on Commons. Ideally we would have a way to watch entire categories at a time, and all subcategories down to a specified depth. Notifications of additions to those categories would be helpful too. -mattbuck (Talk) 09:42, 15 October 2014 (UTC)

Yes. It would be lovely if we could come up with a cleverer software solution to this sort of thing. The watchlist format works reasonably well on Wikipedia, but as you say, it wasn't designed for something on the scale of Commons. And a lot of people only contribute to Commons to upload images that they want to use on other projects, so they're unlikely to check their Commons watchlist; global watchlists might help with that (I think that's in the pipeline, but needs SUL to be finalised first). HJ Mitchell | Penny for your thoughts? 14:38, 15 October 2014 (UTC)
Hmm. I haven't heard anything about global watchlist (Other than people asking for it for the last 10 years). I'd wait for official, definite plans before believing its actually happening. For reference, showing cat changes in watchlist is bugzilla:7148. Global watchlist is bugzilla:3525. The fact that those are 4 digit bug numbers should say something.
On commons (AFAIK), there is no, non-user script way of even getting a list of recent file over-writes. Would having a Special page, like Special:ListFiles, but for overwrites only, be useful? (The way I imagine it, it would have a column for the old version of the image, a column for the new version, and some extra details (person who overwrote, date). If it gave a side by side comparison of new vs old version, it would be easy to see at a glance many of the inappropriate overwrites, since significant visual changes are almost always inappropriate, and there's only very roughly about 600 overwrites a day) Bawolff (talk) 15:16, 15 October 2014 (UTC)
Symbol support vote.svg 1 An overwrites special page sounds like a useful improvement to page patrol tools. Smile fasdfdsfoiueire.svg
It would also be great if user watchlist editing on-wiki were to allow for editing of much larger watchlists. I have been unable to edit mine without creating special scripts for the last two years, with 554,404 pages on my list today. Mostly due to being useful to keep an eye on batch uploads for a month or two after they are done. -- (talk) 05:57, 16 October 2014 (UTC)
Is there a way to configure/use the w:WP:Abuse filter to provide a list of all changes on Commons which (a) reupload a file, done (b) by a newly registered user, on (c) a file which is in-use on other projects, and (d) categorized prior to the edit as a living person (either the image on Commons or the article on the other project)? I don't have the access to play around with that thing, but my guess is that there are obstacles to some of the cross-wiki aspects or integration of image changes, but maybe some of this is possible or could be readily coded. Wnt (talk) 14:40, 16 October 2014 (UTC)
It can be done with a database query, though optimising how to go about it might take some thought. It's not necessarily an extension of the Abuse filter, though it might capitalize on it; it sounds more like a regular report that a minor bot might put out on a weekly or daily basis, and something for Commons:Bots/Work_requests to discuss, probably. Use on other projects is quite easy to pull out of the commonswiki database (global links), along with edit file version histories which can be filtered to files with recent changes.
Update I knocked out test queries along these lines. On my Wellcome Image uploads there are 40,000 files at the moment and this query shows that only 0.02% of images have new files uploaded over the original ones during the month of October, being valid crops or higher resolution uploads. The second example is a query on all Commons images and shows that just 6 files were overwritten in the ten minutes before midnight on 16th October 2014. -- (talk) 01:26, 17 October 2014 (UTC)

Here's an attempt of doing (enwiki) BLP images:
Interestingly enough, the performance of this query seems to vary greatly depending on which SQL server you connect to (when I did sql commonswiki_p originally, it appears that doesn't have the cl_from index on the enwiki categorylinks, but sql enwiki_p has the needed indexes on both commons and enwiki tables). Also tool labs seems to be missing the index on the log_action field across the board. For some reason, the query also filesorts the logging table. Not sure why, but that's why I have an explicit log_timestamp limit. Bawolff (talk) 01:29, 17 October 2014 (UTC)
Could someone look at repairing the commonswiki tables? The global links should be there for consistency, it would make this sort of reporting a bit conceptually easier too... Smile fasdfdsfoiueire.svg -- (talk) 01:35, 17 October 2014 (UTC)
Globalimagelinks lives on the commons database canonically (By which I mean, on the real wikis, globalimagelinks table is on the commons database server). The issue on tool labs is doing the cross wiki categorylinks to enwiki doesn't really work properly from the commons server. I have no idea if that's intentional (Could be to improve performance on the expectation that people aren't going to do cross wiki queries on the commonswiki mirror, maybe? To be honest, I was pleasantly surprised that doing a cross wiki query even worked at all). Anyways, way out of my area. (Ping User:MPelletier_(WMF)?). Bawolff (talk) 01:55, 17 October 2014 (UTC)
Here's an attempt at also including Wnt's newbie criteria. Note that once you limit to people < 500 edits, the number of overwrites goes down quite a lot. There's only 7 in the last 24 hours. Bawolff (talk) 02:05, 17 October 2014 (UTC)

Playing further with the query - Here is all overwrites for images used in an enwiki BLP in the month of October, where the person overwriting is not the same as the uploader, the person overwrting has < 100 edits on commons, and < 200 edits on wikipedia. With this restrictive a criteria, there's only 54 such overwrites in the month of October, about half of which are file:Jennifer_Lawrence_at_the_83rd_Academy_Awards_crop.jpg, and most of the rest also having been reverted. Bawolff (talk) 02:42, 17 October 2014 (UTC)

Report created at User:Fæ/BLP overwrites. Set to refresh every 15 minutes (which means it only changes on-wiki if there are new changes, so handy for page patroller watchlists). -- (talk) 06:08, 17 October 2014 (UTC)
Hmm, there's a lot of extra space in the Link column. Maybe that column could include the log_comment (upload summary) field too. Bawolff (talk) 06:41, 17 October 2014 (UTC)
✓ Done -- (talk) 06:58, 17 October 2014 (UTC)
Update As this seems a popular solution for finding suspect BLP photo changes, I have upped the check rate to once every 5 minutes rather than every 15 minutes, i.e. on average a patroller watching the report would know about an image to check within 2.5 minutes of the upload. The runtime seems low enough if this is considered an important report, though if someone from WMF ops advises me otherwise I'll tweak the rate back down again. The on-wiki page is only changed if a new image change is found, so you would only see these at a rate of something like once a day. Smile fasdfdsfoiueire.svg -- (talk) 19:44, 17 October 2014 (UTC)

October 15[edit]

Monobook TWINKLE help[edit]

This error text:

Error: at line 1: Uncaught ReferenceError: twinkleConfigExists is not defined

keeps showing up in right corner of every single page I load on Commons.

See: User:Cirt/monobook.js.

Is there a problem with User:Kanonkas/twinklefluff.js ?

Any idea how to fix it?

-- Cirt (talk) 00:17, 15 October 2014 (UTC)

You can try to add
var twinkleConfigExists = true;
to the beginning of your monobook.js. Ruslik (talk) 18:51, 15 October 2014 (UTC)
That seems to have fixed it, thank you! -- Cirt (talk) 19:58, 15 October 2014 (UTC)

October 16[edit]

Creation of derivative versions of videos[edit]

For me it looks like our servers are unable to create the smaller versions of new uploaded videos (since a few hours). Also a manuell reset of the trancoding don´t work for me (example: File:Suillia - 2014-09-22.webm). Can anybody proof this finding? --Pristurus (talk) 08:59, 16 October 2014 (UTC)

Cache? Delphi234 (talk) 16:23, 16 October 2014 (UTC)
1080p transcodes just got enabled (bugzilla:71705). I think the video scalers are just a bit overloaded for the moment while they catch up with making HD versions of all the big videos on commons. For reference the video scalars certainly look busy: and Special:TimedMediaHandler is full of 1080p transcodes. Will probably resolve itself once the backlog is cleared. Bawolff (talk) 16:58, 16 October 2014 (UTC)
The first file without proper transcoding File:Capturing-structure-and-function-in-an-embryonic-heart-with-biophotonic-tools-Movie1.ogv was uploaded on 10:22, 14. Okt. 2014. Until now I can not see any new successful transcoded derivatives. --Pristurus (talk) 11:49, 17 October 2014 (UTC)
Well, File:Motoraki_2013.webm was successful. Bawolff (talk) 16:53, 17 October 2014 (UTC)
Thanks, issue seems to be solved, as far as I can see all recent derivatives are proper built now. --Pristurus (talk) 16:26, 18 October 2014 (UTC)--
The scalers are more or less caught up as of about 16:00 utc (Still perhaps slightly busier than normal). Bawolff (talk) 17:55, 18 October 2014 (UTC)

October 17[edit]

CatScan2 is down means that many maintenance tasks can not be performed[edit]

CatScan2 is taken off-line, see notice due to issues with Wikimedia Labs. Apparently this popular tool crashes a lot when run within Wikimedia Labs environment, and has to be manually restarted. User:Magnus Manske running and maintaining the tool for years is apparently on strike until Wikimedia Labs have capability to restart tools automatically. I do not know about others, but a lot of regular maintenance tasks I do on Commons rely on CatScan2 and will not be possible without it. For example Category:Media without a license: needs history check has files that do not have licenses and have to be looked at. We need CatScan2 to divide the group into new uploads that never had a license and old files that somehow lost their license template, so we can tag the first group with {{no license}} template and manually fix the second group. There are many other maintenance tasks that rely on CatScan2, which for the time being will become much harder or impossible to run. Anybody knows how to fix issues with Wikimedia Labs, to get it started again. --Jarekt (talk) 14:47, 17 October 2014 (UTC)

Tool labs can't auto-restart the webservice? That's just silly. (What was wrong with just using a single Apache server anyways...). You can do something somewhat similar using the search feature - (If you want to limit it to a specific category, stick incategory:CAT_NAME_HERE at the end of the search). Bawolff (talk) 15:52, 17 October 2014 (UTC)
Bawolff, thanks for pointing out this search feature. I did not know about being able to search for presence or absence of templates. Is there a documentation of this and other search features? Or some interface to build the search strings? I will also need a way to convert the search output into a gallery, so I can use VisualFileChange tool. As for CatScan2 I do not know anything about Wikimedia Labs environment, but I do have a lot of respect for User:Magnus Manske technical abilities (he wrote the original versions of most Gadgets we use and many toolserver tools). So when he claims that he is not able to get auto-restart the webservice to work I would tend to trust him. If there is a better way to run his tools on Wikimedia Labs, can we start a clone somehow? It sounds to me he has more fun at writing new tools than on doing day-to-day maintenance on the old ones (none of his gadgets, a like cat-a-lot or HotCat, are maintain by him). But we still need those tools. --Jarekt (talk) 20:13, 17 October 2014 (UTC)
There's a handy "learn more" link when you run a search. It explains the options. Smile fasdfdsfoiueire.svg
If the search could easily export JSON results to bots, that would be super duper. I do use the API to do something with the old search engine (it's how I track down prospective matches to image identities before/during batch uploads), but I'm not sure it's well explained. -- (talk) 20:31, 17 October 2014 (UTC)
You can use list=search. It just takes a search string as a parameter, however it interprets that string the same way as the normal search (ie mw:Help:CirrusSearch), so you can do all the same stuff. Bawolff (talk) 12:24, 18 October 2014 (UTC)
A very handy tip, thank you. Hopefully the webstart issue can be fixed soon, as with others I have quite a few existing script to do handy stuff that rely on Catscan behind the scenes, I'd probably just do a little less rather than bother to rewrite them all. -- (talk) 06:55, 19 October 2014 (UTC)
Nothing new that the webservice (and the sub submitting service grid) is unstabe on toolslabs. It is very annoying to restart webservice by hand if crashed, and it is very annoying to restart or kill broken jsub jobs by hand if crashed... --Steinsplitter (talk) 07:05, 19 October 2014 (UTC)

October 18[edit]

Using images on an external website[edit]

A university in Wales wants to use around 50 images from Commons (of various licences); what wording do they use on their site? Is 'Images from Wikimedia Commons', with a link, sufficient? Or do they need to include a licence; if so which one? Can someone point me to a discussion page please? Llywelyn2000 (talk) 10:16, 18 October 2014 (UTC)

Since Wikimedia Commons is a community project and allows a bunch of different licenses and the files are presumably by different authors, every re-user will have to add credit for each single image. If the page Reusing content outside Wikimedia does not sufficiently answer your questions, please return here. -- Rillke(q?) 11:21, 18 October 2014 (UTC)
Many thanks. This seems plausible / possible / doable with only 50 images, but they wish to illustrate their on-line dictionary with images (maybe 50,000 or so). Can they not take the credits automatically as metadata in their feed? Llywelyn2000 (talk) 15:49, 18 October 2014 (UTC)
There is a metadata API now but depends on well-structured file description pages and requires that the file names have been recorded/preserved. I recommend to at least quickly read through the output of the API before using it. -- Rillke(q?) 16:26, 18 October 2014 (UTC)
Many thanks. Llywelyn2000 (talk) 12:12, 19 October 2014 (UTC)

October 19[edit]

File:RVO-Star.jpg and the (somewhat more modified File:RVO-Star (KCVO).jpg [edit]

The work these were based on, File:GCVO star.jpg was CC-licenced. These works were relicensed to public domain, and removed credit, and are thus, of course, complete copyright violations. Adam Cuerden (talk) 09:17, 19 October 2014 (UTC)

Hi Adam, I think changing the license would solve the issue. Why didn't you ask the uploader? Regards, Yann (talk) 10:14, 19 October 2014 (UTC)

October 20[edit]

Fictional historic flags[edit]

I know anyone can upload anything to Commons and name it without any consulting. Wikimedians are here to fix the wrong names or wrong graphics (as I sometimes did). However, what to do with fictional flags seeming to be historic? This and this are very probably modern proposals by Wikimedians. It should be reflected in file names. Here we can discuss the new names and decide whether to add the files to this category. All proposed flags were removed from it. Perhaps if all files in the category are proposals, it can be subcategory of Category:Special or fictional flags. Hosmich (talk) 07:28, 20 October 2014 (UTC)

I have found another proposed Ming flags: File:Ming Dynasty Flag (1368~1644).png, File:明 Ming Flag.gif. Accuracy of years is weak IMO, but it can be discussed here. Another Ming flag was probably deleted, it was yellow triangle with red curly borders.
Hosmich (talk) 07:36, 20 October 2014 (UTC)
Hosmich -- there's a category Category:Variations on flags of China for China-specific "special or fictional flags". Anyway, I think it's most important that each image's description page specify exactly what the image is, by means of {{Fictitious flag}} or similar. That's probably more useful than trying to adjust other flag categories to keep out proposed flags... AnonMoos (talk) 08:39, 20 October 2014 (UTC)


Yesterday, User: added over 50 files to Category:University of Birmingham, all of which were already in more specific sub categories. Can someone revert those edits, please? Andy Mabbett (talk) 14:29, 20 October 2014 (UTC)

I noticed that Túrelio has sorted this out. — SMUconlaw (talk) 18:04, 20 October 2014 (UTC)

Incorrect translation[edit]

A quick search reveals that this description in Dutch: "Bioscoopjournaals waarin Nederlandse onderwerpen van een bepaalde week worden gepresenteerd", is present in no less than 2622 images in the Wikimedia Commons. In at least 1475 instances this is incorrectly translated as "Newsreels in which Dutch subjects of a certain week are presented". This should of course be: "Newsreels in which Dutch topics of a certain week are presented". I don't have the means to change this 1475 times. Could anyone be of assistance please? You may either show me how to do a search and replace, or do it for me. Thanks in advance. Mark in wiki (talk) 15:17, 20 October 2014 (UTC)

You can install VisualFileChange, which adds a link to your "Tools" menu on the left side of the screen called "Perform batch task". Then navigate to the category containing the files you wish to alter, click "Perform batch task", and choose the "Custom replace" option. — SMUconlaw (talk) 17:54, 20 October 2014 (UTC)

Introduction to Wikidata[edit]

At Lydia's request, I've written a short introduction to Wikidata (another one!), from a Commons perspective:

Commons:Structured data/Short introduction to Wikidata

It's a bit more detailed than what we had before, and maybe gives a bit more of an idea of what any templates dealing with Wikidata may have to contend with.

Do let me know what you think, and what could or should be done to make it clearer or more informative, on the talk page.

Thanks, Jheald (talk) 15:46, 20 October 2014 (UTC)