Commons:Village pump

From Wikimedia Commons, the free media repository
(Redirected from Commons:Village Pump)
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
Village pump in Rzeszów, Poland [add]




Oldies[edit]

W.W.11[edit]

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)

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)

muy graciosos

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)

OK, so since nobody seems to have strong feelings against this: Who can edit Special: pages? Do I have to make a request at COM:AN? Or file a bug report/feature request? --El Grafo (talk) 07:55, 21 October 2014 (UTC)

Found with Special:AllMessages and luck under u, do you mean MediaWiki:Uploadtext? The talk page is MediaWiki talk:Uploadtext for a local change here (edit request + admin). –Be..anyone (talk) 00:52, 25 October 2014 (UTC)

October 14[edit]

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]

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: http://ganglia.wikimedia.org/latest/?r=custom&cs=10%2F14%2F2014+00%3A00+&ce=10%2F16%2F2014+14%3A00+&m=cpu_report&s=by+name&c=Video+scalers+eqiad&h=&host_regex=&max_graphs=0&tab=m&vn=&hide-hf=false&sh=1&z=small&hc=4 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 - https://commons.wikimedia.org/w/index.php?title=Special:Search&search=-incategory%3AMedia_without_a_license%3A_needs_history_check%20-hastemplate%3ALicense_template_tag%20-hastemplate%3APD-Layout%20-hastemplate%3AGNU-Layout%20-hastemplate%3ACC-Layout%20-hastemplate%3Ano-license%20-hastemplate%3Adelete%20-hastemplate%3ASpeedydelete&fulltext=Search&profile=images (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)

North Wales' largest nature society is Cymdeithas Edward Llwyd, a totally non-profit society, with some funding from the Welsh Government. Their website (and bulletines) arm is called Llên Natur. Can you take a look at this site, please, where they have a pilot run of Welsh terms for around 50 ladybirds. You will need to type the word 'buwch' in the space provided. This will bring up a feed / list of ladybirds, together with images from Commons within the Llên Natur website. Clicking on each image brings up the licences and attribution. Does this comply with the licencing terms? We need to get this water-tight, as there are possibly another 13,000 term / images to follow. Llywelyn2000 (talk) 11:50, 21 October 2014 (UTC)

  1. Copy and paste into the search box didn't work. I had to select the placeholder text and delete it. The result "feed" was displayed in an iframe and was very inconvenient to access.
  2. I cannot tell you for sure whether a back-link to commons on each image is sufficient. I know that some users of the German community believe it isn't. If you want to play safe, you have attribution next to each image. The huge amount of licenses permitted on Commons doesn't even make it easier.
I regret that I cannot be of help here in the extend I would like to be. -- Rillke(q?) 17:05, 21 October 2014 (UTC)
Many thanks! Any one else with other thoughts? Llywelyn2000 (talk) 07:33, 22 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)

User:86.161.188.107[edit]

Yesterday, User:86.161.188.107 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)
Is it really incorrect? "subjects" and "topics" have overlapping meanings in English, and the sentences mean about the same to me.--Prosfilaes (talk) 06:33, 21 October 2014 (UTC)
You may be right, Prosfilaes. I took "subjects are presented" to mean something like "persons are presented to be investigated", but after verifying this in the Oxford dictionary (I'm not a native speaker of English) I found it to mean "a person or thing". So I'm guessing nothing needs to be changed after all. Thanks! Also thanks to SMUconlaw for pointing me in the direction of VisualFileChange, which I'm sure I will put to (some other) good use soon! Mark in wiki (talk) 07:38, 21 October 2014 (UTC)
You're most welcome. — SMUconlaw (talk) 09:08, 21 October 2014 (UTC)
As a native speaker, "Dutch subjects" would normally only mean "People who are Dutch citizens" - not even people who are in the Netherlands, but the word subject also means "topics". "Dutch topics" would normally mean "topics that are related to the Dutch", and not include any topics that were related to a specific Dutch citizen. That being said, it does not need to be corrected, as it is really close enough, particularly if some of them are about citizens and some about topics, as that would be a nightmare to sort out. Delphi234 (talk) 19:19, 24 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)

October 21[edit]

Insignia copyright status questions[edit]

I have some questions regarding the copyright status of the following files: File:Iceland-police-national-commissioner.gif, File:Iceland-police-commissioner.gif, File:Iceland-police-assistant-commissioner.gif, File:Iceland-police-1997-with-id-number-5.gif, File:Iceland-police-1997-with-id-number-4.gif, File:Iceland-police-1997-with-id-number-3.gif, File:Iceland-police-1997-with-id-number-2.gif, File:Iceland-police-cadet-insignia.gif, and File:Iceland-police-1997-with-id-number.gif. These files were all uploaded to Commons as {{insignia}} using the {{attribution}} for the licensing. The source for each of these images is given as kaldi.is/icelandic-police-2008.htm; this website, however, does not appear to be the copyright holder of these images accordiong to kaldi.is/kaldi-copyright.htm. It's not clear if the website uniforminsignia.org listed in that copyright notice is the actual copyright holder and they claim here to license the images on their website per CC BY-NC-ND 4.0. It seems strange to me the original copyright holder is not either the Icelandic Police or the Icelandic Government, so perhaps the insignias were recreated based up the images found on pages 54 and 55 of this pdf. Is this licensing rationale OK? Should these images be considered non-free content? Should they be considered public domain? Thanks in advance - Marchjuly (talk) 02:18, 21 October 2014 (UTC)

Watchlist broken?[edit]

Does anyone else experience strange things with the watchlist? Instead of showing only the latest change, mine is displaying all recent changes to watched pages. Now busy pages like the QI candidates show up a gazillion times, making the watchlist practically unusable. This does not happen on Wikipedia (en or de). I've switched off the HHVM beta feature, but nothing changed. --El Grafo (talk) 19:04, 21 October 2014 (UTC)

PS: Tested Firefox 32.0.3, Midori 0.4.3 and Konqueror 4.13.3 on Linux Mint 17 --El Grafo (talk) 19:20, 21 October 2014 (UTC)
Yes, I seem to be experiencing that too. Also, I just tried to upload a file but the throbber has been spinning around for a really long time to no avail. Before that I tried the UploadWizard and that didn't work either. (I'm using Mozilla Firefox 33.0.) I tried the upload with Chrome 38.0.2125.104 m and didn't have any problems. — SMUconlaw (talk) 19:11, 21 October 2014 (UTC)
  • Same problem here with Chrome. Kelly (talk) 19:21, 21 October 2014 (UTC)
    • Somehow my preference regarding this has been re-setted. Special:Preferences#mw-prefsection-watchlist under Advanced options, Expand watchlist to show all changes, not just the most recent can be de-activated again and then it'll be back to normal. -- Rillke(q?) 19:51, 21 October 2014 (UTC)
      • Strange, but that solved it for me. Thanks, Rillke! --El Grafo (talk) 19:58, 21 October 2014 (UTC)
        • Not strange, it was probably caused by this changeset in response to bugzilla:35785. We're not the only people taking by suprise, see this changeset. Multichill (talk) 20:04, 21 October 2014 (UTC)
          • Indeed. The default for MediaWiki has changed and all users with the option not set, got the new default. -- Rillke(q?) 20:18, 21 October 2014 (UTC)

✓ Done This changed in accident: I've just deployed a configuration patch that fixed this. Cheers, Hoo man (talk) 20:45, 21 October 2014 (UTC)

"Select images from Flickr" (Upload Wizard)[edit]

Is this option working at the moment? It seems to identify the filename, but then never actually acquire the image itself -- just spin, with a little 'doing things' icon. (Firefox 33.0 / Windows 7). Is everybody else getting this, or does it work for some people?

Also, can anyone remind me who actually gets to use this option? IIRC, it's not available for new users, but I can't remember who does get to use it.

Thanks, Jheald (talk) 23:02, 21 October 2014 (UTC)

All users with the upload_by_url user right should see the "Add files from Flickr"-button. According to Special:ListGroupRights, these are users who are members of the Administrator, Image reviewer, or GWToolset user groups. -- Rillke(q?) 23:42, 21 October 2014 (UTC)
Load denied by X-Frame-Options: https://commons.wikimedia.org/w/api.php does not permit framing.
Error: Permission denied to access property 'document'
https://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=false&lang=en&modules=ext.uploadWizard.apiUploadFormDataHandler%2CapiUploadHandler%2Cevents%2CformDataTransport%2CiFrameTransport%2Cpage%7Cjquery.arrowSteps%2Cvalidate%7Cmediawiki.api.category%2Cparse%2Ctitleblacklist%7Cmediawiki.feedback%7Cmediawiki.libs.jpegmeta%7Cschema.UploadWizardErrorFlowEvent%2CUploadWizardFlowEvent%2CUploadWizardStep%2CUploadWizardTutorialActions%2CUploadWizardUploadActions%2CUploadWizardUploadFlowEvent%7Cuw.EventFlowLogger%2Cbase%7Cuw.controller.Deed%2CDetails%2CStep%2CThanks%2CTutorial%2CUpload%2Cbase%7Cuw.model.Description%2Cbase%7Cuw.ui.Step%2CThanks%2CWizard%2Cbase&skin=vector&version=20141021T180751Z&*
Line 12
Looks like they turned off API X-Frame-Option SAMEORIGIN header on their server responses and didn't fix Flickr Upload so that it's using ordinary AJAX-requests, yet. -- Rillke(q?) 23:53, 21 October 2014 (UTC)
The upload request is the culprit. You are most likely able to find the files you attempted to upload in your personal stashing area shortly after attempting to upload them. From there you can publish them (in case you need a particular file transferred *now*). I will forward this bug to bugzilla ASAP. -- Rillke(q?) 00:03, 22 October 2014 (UTC)
Got it. Thanks! Jheald (talk) 01:10, 22 October 2014 (UTC)
Reported as Bug 72340. -- Rillke(q?) 00:32, 22 October 2014 (UTC)
Yes check.svg Resolved

WTF is going on with the panes (monobook)[edit]

I've been noticing quite a few interface errors recently. On COM:AN/U Fæ inserted a wikitable and that somehow moved the left pane into the main pane, with search et al below the text. When I just looked at COM:VP the logo and top stuff shows in the right place, but the left pane is otherwise blank until below the main pane text. Then on COM:QIC I've noticed it keeps bolding and going about 2-3 text sizes bigger halfway through the discussion section (no template errors, no fixed place). This has been happening on two different PCs, running different versions of Firefox. -mattbuck (Talk) 23:54, 21 October 2014 (UTC)

See 3 threads above, "Watchlist broken?" Might be dev's playday. SCNR. --Túrelio (talk) 07:03, 22 October 2014 (UTC)

Now it's got even worse. Suddenly all the tool-links for patroling-work (such as Quick Delete: no-permission, no-source, copyvio, nominate for deletion) have disappeared. If you guys want to prevent us from maintaining Commons, fine. You have won. --Túrelio (talk) 07:21, 22 October 2014 (UTC)

Monobook does not more work as expected even here (sidebar pushed down to a position below the content.). :-(  –Be..anyone (talk) 08:20, 22 October 2014 (UTC)
Disabling the HHVM beta test fixed the problem on this page for me. –Be..anyone (talk) 08:29, 22 October 2014 (UTC)
This page still fails (for me) with Monobook + HHVM on Chrome, ?useskin=vector is okay. Presumably that's an unrelated problem.Be..anyone (talk) 15:04, 22 October 2014 (UTC)
For the missing maintenance links, I and Steinsplitter are in charge. It was for about 2 hours: From 06:00 to 08:00 UTC. Everything else should be probably tracked in Bugzilla. Next time, I will provide better instructions. -- Rillke(q?) 10:55, 22 October 2014 (UTC)
Quick Delete-tools are back. Thanks. Seems, I just hit this window. --Túrelio (talk) 12:24, 22 October 2014 (UTC)
Idem for me here, and on Vector too. Yann (talk) 11:10, 22 October 2014 (UTC)
[…] going about 2-3 text sizes bigger halfway through the discussion section […] – same for my talk page (vector skin, with and without HHVM). Text starts getting bigger here and moves left into the sidebar here. Also the page footer ("This page was last modified on …") has moved up into the content area on some pages. Or the other way round: the content area (white background surrounded by blue line as opposed to the light grey of the sidebar/footer area) extends all the way down to the bottom of the page. This seems to happen only at longer pages like the village pump; most file pages look fine. --El Grafo (talk) 13:47, 22 October 2014 (UTC)
+1 For me it is on vector and (but only) some site on Wikipedia and Commons. User: Perhelion (Commons: = crap?) 17:47, 22 October 2014 (UTC)

October 22[edit]

Photographs in a scientific journal[edit]

Hi all. We have developed a test for assessing empathy in scientific studies. The test includes seven photographs from Wikimedia Commons. We hope that the development of the test will be published in a scientific journal in near future. However, scientific journals are not available for everybody (cf. share alike rule). Therefore, I would like to inquire if we follow the share alike (and other) rules if we publish the photographs, the license information, and a short (ca 200 words) abstract of the article in our website, which is available for everybody. I would appreciate your help. — Preceding unsigned comment added by Mlindema (talk • contribs)

Hi Mlindema,
AFAIK, if you just include an unmodified CC-SA...-licensed work into something (here: your publication), the Share-Alike-component of the included work has no effect on the larger something. The Share-Alike-component comes into effect when you create an adaption[2] of the CC-SA..-licensed work.[3]. IANAL. --Túrelio (talk) 06:32, 22 October 2014 (UTC)
Also: IANAL. But that's how I understand it as well: If you just use the unchanged pictures within another work, it's sufficient to name the author and the license is was published under. --El Grafo (talk) 11:28, 22 October 2014 (UTC)
More: IANAL, but any CC SA might be not okay for Cc-by-nc-sa icon.svg CC-BY-NC-SA, but NC (non-commercial) licenses are not used (= not permitted) on commons. –Be..anyone (talk) 15:27, 22 October 2014 (UTC)

Many thanks!

Best promo videos[edit]

I'm in need of a couple of short videos, promoting Wikipedia and its sister projects, to show at an event. It's surprisingly hard to find them!

We have lots of videos in, but many, while no doubt useful for their educational content, are not the kind of things to show to a lay audience - either the quality is not high enough, or the content is too specific.

I'm looking for things with impact, like File:Open Letter for Free Access to Wikipedia - three months later, MTN responds.webm

Suggestions, please! Andy Mabbett (talk) 12:39, 22 October 2014 (UTC)

Category: Instructional videos on using Wikipedia. –Be..anyone (talk) 03:14, 24 October 2014 (UTC)
Thank you; I already located the haystack, and am asking for suggestions as to where I might find the needles. Andy Mabbett (talk) 18:02, 24 October 2014 (UTC)

Wikidata phase 2[edit]

RfC now open as to whether we would like to ask for this now to be activated for Commons. Jheald (talk) 14:37, 22 October 2014 (UTC)

October 23[edit]

Upload Wizard problems[edit]

Upload Wizard fails

Last few days I am having trouble uploading 100kb+ PDF files using Upload Wizard. As you can see in the image, the wizard finish uploading but never shows the button to proceed to the next screen. I know, I was able to upload this kind of files in the spring, so it is something that broke since then. I was also not able to upload the file with Vicuna since vicuna do not seem to be able to handle PDF files (see here) or basic upload form due to the size (Error: "The connection to the server was reset while the page was loading."). Any idea what is wrong with Upload Wizard and if there is a workaround. I will look into pywikipediabot. --Jarekt (talk) 03:50, 23 October 2014 (UTC)

Does anything appear in your browser's JavaScript error console when loading the page? Could you run the upload wizard with the debug option enabled (just add "?debug=true" at the end of the web address after "Special:UploadWizard" and then reload the page)? --AKlapper (WMF) (talk) 06:50, 23 October 2014 (UTC)
I am getting
"JQMIGRATE: Logging is active" load.php:10332
 "Validation error against schema UploadWizardFlowEvent: Unrecognized property: quantity"
in Firefox JavaScript error console, when using "?debug=true". --Jarekt (talk) 07:06, 23 October 2014 (UTC)
As you are a power user, you may try User talk:Rillke/bigChunkedUpload.js. It also allows creating new pages and it shows raw server responses in case of errors. -- Rillke(q?) 09:42, 23 October 2014 (UTC)
Thank you for letting me know. --Jarekt (talk) 04:22, 24 October 2014 (UTC)
Just FYI, just because the progress bar says "Finished", that doesn't necessarily mean that it actually has finished. The progress bar in UW has very little credibility. So perhaps waiting a bit longer will help. You can also look at the error console or look at your system's statistics on how much data is being transmitted for clues on what is going on. darkweasel94 10:02, 23 October 2014 (UTC)
The problem is now Pictogram voting keep.svg Fixed. See Commons:Village_pump#Much_fix.2C_very_working.2C_such_deployment.2C_wow --Jarekt (talk) 04:22, 24 October 2014 (UTC)

WMF code deployment problems[edit]

Could someone from WMF development please provide an official summary of why code deployments have been so disruptive to Commons over the past week? I am sorry to say that a series of unexpected problems with watchlists, basic page layout, missing tools, broken upload process are bound to reduce the trust and confidence unpaid volunteers have for WMF support of this project. Wikimedia Commons is a mature flagship project, one that should not be used as an experimental test-bed.

This would seem a good time for the WMF to recognize recent non-successes, and explain what changes are being made to avoid similar issues in the future. Thanks -- (talk) 10:10, 23 October 2014 (UTC)

While I can understand that not all possible problems on Commons (or other projects) can be anticipated, what the community and especially the maintainers really can expect is a project-wide pre-announcement about every code deployment, shortly before it goes live, which should include a direct-link to the related dev's talkpage (not Bugzilla, please), where unexpected adverse-effects could be recorded. --Túrelio (talk) 10:20, 23 October 2014 (UTC)
Deployments happen to commons every Tuesday (and have for quite some time now. More than a year). If I gave you list of every dev involved, you'd probably have about 50 names each week. I'm not sure how useful that would be to you. BWolff (WMF) (talk) 18:02, 23 October 2014 (UTC)
To expand on that, I'll take this opportunity to explain how code deployments work to commons. The process is something like: Someone writes code. That person then submits code for review. Automated unit tests run (Occasionally they catch things, realistically automated tests only help so much. These are the phpunit, parser and quinit [javascript] tests). If the automated tests pass, someone else manually checks that the code is ok ("merges") code. This code is then present in the current alpha version of MediaWiki, and put on http://commons.wikimedia.beta.wmflabs.org/wiki/Main_Page for testing. More automated tests run (So-called browser (or Selenium) tests, however these tests have quite varied coverage, and honestly are missing a lot of things). Every Thursday a snapshot of the current alpha of MediaWiki is taken. This snapshot is put on mediawiki.org, test.wikipedia.org, test2.wikipedia.org, and the test wikidata site. Some people hopefully test things manually at this point, in particular people who use mediawiki.org give it a lot of early testing. After 5 days, if nothing has exploded, this snapshot is put on all non-wikipedia projects (including commons). This process is repeated every week (Sometimes US holidays mess with the schedule).
As far as what is deployed: You can see the equivalent of Recent changes for dev stuff at https://gerrit.wikimedia.org/r/#/q/status:merged,n,z (Keeping in mind the rule that the cut off for things appearing on commons is either last thursday or 2 thursday's ago. Also keeping in mind that not everything developer related is used on commons, so some things may be irrelevant). There is a deployment schedule posted to wikitech-l each week (Most recent [4]). You can also view on wiki at wikitech:Deployments. wikitech:Deployments also lists so-called "SWAT" deploys, which is code changes that need to be deployed faster than the standard weekly deploy. Last of all, in serious situations, sometimes things are deployed outside SWAT windows (e.g. If the site is broken, or for important config changes). These (and basically anything else that can happen to the servers) is listed at wikitech:Server Admin Log.
Last of all, the full list of changes being deployed each week is available on mediawiki.org - mw:MediaWiki_1.25/wmf4/Changelog is the changes for last Tuesday. There were 285 of them. meta:Tech/News/Latest tries to distill that into important changes explained without technical jargon. Many communities have that posted automatically to their VP's. Commons could request that be posted here each week if they wish to be more informed. If people still feel there is insufficient communication, I could try making a weekly post highlighting changes I think particularly affect commons, if people feel that would be helpful and would want to read it. However keep in mind the issues that started this thread were accidents. Nobody wakes up in the morning saying, I want to totally break the site. Just looking at the change summary for all the changes that caused the issues we're discussing, I would not have guessed they would have caused the problems they did (Except perhaps the watchlist one, we kind of dropped the ball there). Sure there are probably things that could be done to make sure the same mistakes don't happen again (e.g. Browser test for flickr upload, a unit test for filebackend to make sure abbrvThreshold is in sync), but I wouldn't have been able to guess before it happened, what would have happened. Bawolff (talk) 19:20, 23 October 2014 (UTC)
You could state exactly what issues you are having and how to reproduce them. That would certainly help to debug the issues. --Glaisher (talk) 11:05, 23 October 2014 (UTC)
I think Fæ is talking about things like #Watchlist broken? and #WTF is going on with the panes (monobook) in general. --El Grafo (talk) 11:19, 23 October 2014 (UTC)
And include the following thread "Videos invisible". --Túrelio (talk) 15:54, 23 October 2014 (UTC)
«Reduce the trust and confidence unpaid volunteers have for WMF support of this project», ? Why, how it can be reduced that which is already nill? -- Tuválkin 15:44, 23 October 2014 (UTC)
A bit unfair mate, there's good folks working for us and doing their best inside the WMF dev team so let's not make it seem like world war III. Smile fasdfdsfoiueire.svg -- (talk) 16:30, 23 October 2014 (UTC)
Yeah, you’re right — I was being over-gloomy. But whatever good people doing good work in the WMF it is still not enough, less than it should be, and apparently getting worse as time passes. Sad face.svg -- Tuválkin 02:41, 24 October 2014 (UTC)

Here's a summary of recent issues that I am aware of, and what the current status of them is:

  • Some tools missing from sidebar - Caused by local js changes, should be fixed
  • bugzilla:72330 - enhanced watchlist preference turned on for all users - Was an accident. The default was meant to change in MediaWiki, but not in Wikimedia's config. Should be fixed now.
  • bugzilla:72340 - flickr upload broken in UploadWizard - Caused by changes in API, where formatted output (format=jsonfm) started to share code with the normal page output stuff, and as a result inherited its click jacking protection. This interfered with an old part of upload wizard that works around limitations in IE6. Status: Problem identified, being discussed in gerrit. patch merged waiting deployment (Will probably happen later today) - Fixed
  • bugzilla:72345 - Text randomly going into different "panes" of the skin for people using HHVM option. Problem identified as, a memory leak in HHVM causes the Tidy extension (Thing that fixes when users make html mistakes) to fail after all the servers memory is exhausted. Status: I believe people are working on the underlying cause, but I'm unsure what exactly is happening with this.
  • Misic upload wizard problems reported on VP that aren't related to the flickr issue: No idea what's going on here (update: Possibly fixed, see Mark's comments in later section. Its hard to say for sure because reports on VP are vague)
  • bugzilla:72429 Videos not showing up: Don't know, but plan to investigate this next. Issue found, patch merged waiting deployment (Will probably happen later today) Fixed
  • bugzilla:72389 Files from commons with names between 140-159 letters (bytes technically) long do not show up when used on other projects. Caused by an accidental config change while an unrelated config change was being made. Status: Fixed as of last night.

Did I miss any? Please let me know. As for trying to prevent occurrences of such things in the future, I think that's something that should be more broadly discussed within the developer community. BWolff (WMF) (talk) 18:02, 23 October 2014 (UTC)

Thanks Brian, it is useful. I appreciate that. Regards, Yann (talk) 19:22, 23 October 2014 (UTC)

Videos invisible[edit]

All OVG videos are no longer visible in any browser (IE not tested). I see a brief flash of the media player, which then promptly disappears. -- [[User:Edokter]] {{talk}} 14:49, 23 October 2014 (UTC)

Issue should be fixed later today. BWolff (WMF) (talk) 18:41, 23 October 2014 (UTC)
Yes check.svg ResolvedFix deployed

Is there a problem with video upload?[edit]

I have been trying to upload videos (less than 20 mb) from different computers running Windows 8.1 and Windows 7 and on Firefox and Chrome's latest stable versions. Can someone help here? --Subhashish Panigrahi (talk) 16:08, 23 October 2014 (UTC)

What happens when you try and upload it. Does it fail both when using Special:Upload and when using Special:UploadWizard? Bawolff (talk) 17:25, 23 October 2014 (UTC)

October 24[edit]

HotCat issue[edit]

I'm used to HotCat removing the media needing categories cat when I add a proper cat. This is what I just got instead, which I had to fix by hand. I was working on Category:Media needing categories as of 20 January 2012. INeverCry 01:06, 24 October 2014 (UTC)

Disabling HHVM seems to have fixed the issue. INeverCry 02:06, 24 October 2014 (UTC)
This is really not the sort of thing HHVM should affect. Bawolff (talk) 02:21, 24 October 2014 (UTC)
Yep, must've been some temporary unrelated issue. I re-enable HHVM and HotCat is fine. INeverCry 02:39, 24 October 2014 (UTC)

Much fix, very working, such deployment, wow[edit]

Multimedia team today released four major fixes:

  • Flickr uploads in UploadWizard working again after an HTTP header problem
  • Chunked uploading now working again after a race condition issue
  • Firefogg now works with multiple file selection after a silly, silly mistake in the code
  • TimedMediaHandler no longer sets a zero-height on every file page's video display div

So, to sum up: You can upload things again, and watch videos. Nonessential functions of Commons, I know, but it's all part of the service. Thanks for flying Wikimedia Air :) --MarkTraceur (talk) 01:20, 24 October 2014 (UTC)

Oh, and I should remind you, if you have further issues with any multimedia type products, feel free to bother me on-wiki, get our mailing list at multimedia@lists.wikimedia.org, or even pester us on IRC at Freenode's #wikimedia-multimedia --MarkTraceur (talk) 01:21, 24 October 2014 (UTC)
Thanks for fixing chunked uploads. It resolved this problem. --Jarekt (talk) 04:24, 24 October 2014 (UTC)

Facebook using the smallest thumbnail from Commons for preview[edit]

ExampleBlownThumbnail@fb(fromWMCommons).png

At the right a screenshot showing an example of what has been happening in Facebook these last weeks when an url from Commons is pasted on a post or comment. The optional embbeded remote site “preview banner” is created, as before, but seems that now the smallest thumbnail linked from the filepage is selected, and that is in turn enlarged to illustrate the said preview — resulting in a badly degraded image that doesn’t do justice to the photographic quality of so many items here in Wikiemdia Commons.

In contrast, when a direct link is pasted instead, (as in the comment of the screenshot), a much better quality (and even bigger size) preview image is possible. That is deterimental to the project, as a filepage gives visitors and possible reusers a lot more of information about the file in question, including its direct url, while the opposite (going from direct url to filepage) is not evident for those not familiarized with Commons.

I hope this can be fixed WM-side: Showing our best side in Facebook is paramount, and shabby grainy blurry thumbnails is not the face we want to show in this very important social network. (I hope it takes less than 4600 € to fix, too!) -- Tuválkin 03:30, 24 October 2014 (UTC)

Is there an attribution or backlink for this CC-BY-SA image on FB? I can't check it, everything FB resolves to 127.0.0.1 on my box. –Be..anyone (talk) 06:57, 24 October 2014 (UTC)
When I paste a link to this file on Facebook, there are two arrows in the top left corner of the preview allowing me to switch between a larger size thumbnail and the one you do not like *before posting*. The bigger size thumbnail was default for me. -- Rillke(q?) 08:50, 24 October 2014 (UTC)

internetarchivebookimages[edit]

Hello, do you know this: https://www.flickr.com/photos/internetarchivebookimages. They are all free (At this time 2,619,833 items).--Havang(nl) (talk) 09:14, 24 October 2014 (UTC)

@Havang(nl): Project page at Commons:Internet_Archive/Book_Images_collection. Nobody has done very much with it or them yet, but you're welcome to take it on. Jheald (talk) 19:20, 24 October 2014 (UTC)
Some of these may not be public domain. I clicked on one image categorized as 1839 which turned out to be the year the magazine was founded, not 1933 which was the year the image was published and past the 1923 cutoff. Rmhermen (talk) 19:54, 24 October 2014 (UTC)

Image of a network address written on a machine[edit]

I'm trying to illustrate the early days of networking, from the 80's. One of the common things I recall from this era was that many devices, including printers and hosts, often had a piece of tape stuck to the front with it's network address written on it. Does anyone know of such an image? Thanks! Maury Markowitz (talk) 13:00, 24 October 2014 (UTC)

Servers and printers are still labelled with their host and or IP address. Or how would you find the proper machine a a datacenter that has thousands and thousands of servers? That is also very useful to assist a person remotely by asking the person whatever is written on the label.
An example File:WikimediaServersOct07_3.JPG Hashar (talk) 20:07, 24 October 2014 (UTC)

NASA sounds[edit]

Hello.

NASA has published some sounds here : https://soundcloud.com/nasa

--ComputerHotline (talk) 16:08, 24 October 2014 (UTC)

WLM and countries with no FoP[edit]

After nominating for deletion numerous 2014 WLM uploads of modern Ukrainian monuments (and many from earlier WLMs), I've considered the need for a warning of some kind during WLM, on Commons and on wikis of countries with FoP restrictions and/or no FoP, telling uploaders to upload modern images locally if possible, and only images of older PD monuments to Commons. Otherwise we end up alienating uploaders when their uploads are tagged and deleted for "no FoP", and flooding Commons with FoP copyvios. Thoughts and ideas? INeverCry 22:20, 24 October 2014 (UTC)

I never did that before and don't intend to do it again, but today I visited 13 days of recent deletion requests. There were dozens (or hundreds) of "no FoP in Ukraine", and all with individual years to make your point. Kudos, Be..anyone (talk) 23:35, 24 October 2014 (UTC)

October 25[edit]